Flexibility when entering ip address in machine tracker

Bug #643544 reported by Vidar Faltinsen
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Network Administration Visualized
Fix Released
Wishlist
Christian Strand Young

Bug Description

When specifying a range of ip addresses in machine tracker optional inputs should be possible:

 * specify ip address/mask in the "from ip" field. to display a ip address range based on mask
   I.e. 158.38.38.15/24 should automatically display the range 158.38.38.0-255

* specify ip address/ in the "from ip" field to show the range for the prefix of this particular ip address
   Since NAV knows the prefix length of the monitored subnets this can effecitively show all machines on the
   input ip address's subnet.
   Ex: since 158.38.38.15 is on the 158.38.38.0/25 prefix entering 158.38.38.15/ will give the range 38.0-127

* specifiy a hostname instead of ip address
   In this case "to IP" does not make sence.
   - but the syntax hostname/ should also give all machines on the machines subnet
   - and hostname/24 should show a /24 range of machines that includes the host.

Changed in nav:
milestone: none → 3.5.7
importance: Undecided → Wishlist
status: New → Confirmed
Changed in nav:
milestone: 3.5.7 → 3.7.2
Changed in nav:
milestone: 3.7.2 → 3.7.3
Changed in nav:
milestone: 3.7.3 → 3.7.4
Changed in nav:
milestone: 3.7.4 → 3.8.1
Changed in nav:
assignee: nobody → Magnus Eide (m-eide)
Changed in nav:
milestone: 3.8.1 → none
Changed in nav:
assignee: Magnus Eide (m-eide) → Christian Strand Young (lizter)
Revision history for this message
Christian Strand Young (lizter) wrote :

If you enter a hostname, should NAV do lookups on A or AAAA records? If the hostname resolves to both an IPv4 and IPv6 address, what then?

Changed in nav:
status: Confirmed → In Progress
Revision history for this message
Christian Strand Young (lizter) wrote :

If the netmask is low, e.g. /16, NAV will have trouble processing the request if "inactive" is enabled. A possible solution to this can be to set an address limit so that if the user tries to request more than, say a /20 net, inactive is disabled. Maybe the user should get a warning saying something like "You request was too large to handle, inactive was disabled".

In the template, it should also be able to tell that "To IP" is not a required field. For example, if you specify only a CIDR-address or a single IP, the field is not needed.

Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

So basically, most of this functionality will be part of NAV 3.9.1, but the two remaining bits are:

1. What to do when searching for a hostname that resolves both to A and AAAA records?
2. Visually disable the "inactive" checkbox when the range is too large, _and_ display a warning about it next to the check box.

Revision history for this message
Christian Strand Young (lizter) wrote :

That is right. Also, as I mentioned, I don't think the part with From IP-To IP is intuitive enough. Only From IP is required when using CIDR. Maybe it should say something like "From IP/CIDR"? So people actually use the new functionality and understand that To IP in that case is optional.

Revision history for this message
Morten Brekkevold (mbrekkevold) wrote : Re: [Bug 643544] Re: Flexibility when entering ip address in machine tracker

> That is right. Also, as I mentioned, I don't think the part with From
> IP-To IP is intuitive enough. Only From IP is required when using CIDR.
> Maybe it should say something like "From IP/CIDR"? So people actually
> use the new functionality and understand that To IP in that case is
> optional.

It may actually be that the entire "From IP"/"To IP" concept should be
deprecated. Since we're introducing more advanced search syntax for the
"From IP" field, we might as well add syntax for an IP range as well.
That way, you can search for e.g.:

  10.0.1.20-10.0.1.50

For those only wanting to search for a single IP, the "from/to"-fields
may appear confusing.

Of course, if we were to go all the way with this, we need a new
blueprint, or at the very least a separate wishlist report.

Revision history for this message
Vidar Faltinsen (faltin-uninett) wrote :

Let us then skip the "To IP" field and leave just one "IP range" field where all the optional input possibilities are included.
I.e:

10.0.1.20
10.0.1.0/24
10.0.1.0/

Also the two interval versions:

10.0.1.20-10.0.1.50
10.0.1.20-50

 For the host version that resolves to both IPv4 and IPv6 I suggest IPv6 is displayed.

Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

I've checked out Christian's changes so far, but have some feedback (also given verbally to Christian):

* More input validation is still needed, as search strings like "1::7-5-1-6" don't produce errors (but also no results). With a little imagination, many seemingly crazy search strings seem to be parsed as valid.
* An explicit message to end-user when a search has yielded no results. ATM, it looks like nothing happened when there are no search results, it looks like one never left the search form.
* An explicit statement of what the end-points of the search string were interepreted to be. When inputting "10.0.62.183/" as a search string, it's nice to know that the results are within the range "10.0.62.0-10.0.63.255".

One thing we didn't discuss in detail is how to support searching for host names instead of IP addresses. Vidar suggests picking an IPv6 address if available, but I'm wary of this. A hostname could potentially resolve to a multitude of IP addresses, both IPv4 and IPv6, and I think its crazy to randomly pick one of these when it is not clear what the user's intention is. I have two suggestions:

either:
* If a hostname resolved to multiple addresses, no default selection should take place, rather Machine Tracker should explicity state that there were multiple matches for the given hostname, and list all the matches as clickable links to new, explicit, Machine Tracker searches.

or:

* Machine Tracker, which today is geared towards simple range searches, should gain the ability to search for disjoint ranges, e.g. one could possibly input a list of IP addresses and matches on any of these will be shown. A hostname resolving to multiple addresses would search for all those addresses (but would be even more complicated if hostname is used in conjunction with a netmask). This would likely be more work.

Revision history for this message
Christian Strand Young (lizter) wrote :

Morten's wishes are implemented and the whole thing uses the IPRange util class created by Morten. Forward resolving of hostnames would have to be a separate request, since this involves some interesting questions and challenges.

Changed in nav:
status: In Progress → Fix Committed
Revision history for this message
Morten Brekkevold (mbrekkevold) wrote :

Good work, I've merged this to the default branch in time for 3.11: http://metanav.uninett.no/hg/default/rev/6ed8507792b8

Changed in nav:
milestone: none → 3.11.0
Changed in nav:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers