After completing this how-to, you should be able to track down the causes of physical topology detection problems in NAV, either solving them or collecting the necessary information to report a problem to the developers.
Warning
This how-to isn’t an exhaustive guide, but covers some of the most commonly experienced issues.
NAV provides several layers of topology information:
The most common issue reported to the NAV developers is that two devices that should be connected in the Netmap are not.
Note
Do not blame Netmap. Not without investigating further.
In such a case, you must first ascertain whether the problem is in Netmap itself, or in the NAV database. It is only a problem with Netmap if what it draws is not consistent with NAV data.
You should see something that looks like this:
As you can see, example-sw is connected to banana-sw, apple-sw, pineapple-gw, dinky-sw and parrot. If there are devices you expect to be listed as neighbors here that are not, your problem is not with Netmap.
First, make sure the missing device is actually being monitored by your NAV installation. Did you remember to add it using SeedDB? If not, add it, and give the topology detector up to an hour to analyze the new information (or you can run it manually, but more on that later). If your device is monitored by NAV, please continue reading.
Before asking questions, you should now dig up at least some debugging information to provide with your questions. You must get the list of neighbor candidates that NAV considered for the involved ports.
Given that you already know that switch A’s port 52 is connected to switch B’s port 13, do the following:
You might then see something like this:
NAV uses several sources of information to detect your physical topology, all collected from SNMP queries against your monitored devices:
The first of these is collected by the ipdevpoll ip2mac job in half-hour intervals, whereas the last three are all collected by the ipdevpoll topo job in 15-minute intervals.
These pieces of information are used to build lists of direct (or next-hop) neighbor candidates for each of the ports in your monitored network.
Whereas protocols like CDP and LLDP, if supported and enabled, can usually provide a pretty precise indication of what a port’s next-hop neighbor is, NAV can usually also detect topology without them.
Note
Also, proprietary protocols, such as CDP, can also be imprecise in heterogeneous networking environments, as CDP packets will be invisible to any man-in-the-middle switch that doesn’t support the protocol.
NAV knows the management IP address of all your monitored devices, and uses ARP/ND data as a means of discovering the Ethernet MAC addresses associated with these (Ethernet addresses of individual ports are also collected on SNMP-enabled devices). Coupled with forwarding tables from your switches, NAV can generate a list of next-hop neighbor candidates for each switch port.
When these collection jobs have run, each uplink/downlink port in your network should have a list of possible next-hop neighbors and which protocol provided each of them.
The navtopology program runs as a cron job once every hour, analyzing the neighbor candidate lists collected by ipdevpoll. It prefers LLDP information over CDP and CAM information, but will otherwise use a very generic algorithm for discerning which of the candidates are true next-hop neighbors.
In a case where you have made changes to which devices are monitored by NAV, you can run the command manually, once ipdevpoll has finished it’s topo job for any new devices. The command navtopology --l2 will run a physical topology analysis, and should be pretty quick.