Hi,
I can understand, that it is trying to determine the topology based on vlans.
How do you handle the situation when we have many vlans with different STP roots? Or some uplinks are limited to a subset of available vlans. Or if we have different allowed vlans from one side and the other side?
I attached navtopology.log. I reduced it to include only three devices oriented messages.
They are connected: DEVICE_003 Te0/1 (role: vlan492 ... ROOT, vlan25 ... ROOT) <-> DEVICE_009 Te2/2 (role: vlan492 ... DESG, vlan25 ... DESG) DEVICE_003 Gi0/24 (role: vlan492 ... DESG, vlan25 ... DESG) <-> DEVICE_001 Gi1/0/9 (role: vlan492 ... ALTN, vlan25 ... ALTN)
DEVICE_009 and DEVICE_001 are then connected through other switches.
On webinterface ipdevinfo/DEVICE_003 there are N/A uplinks.
I'm not sure about rules you apply for uplink detection, maybe the log will help
Brgds
Mat -----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Thursday, April 10, 2014 11:38 AM To: JABUREK Martin Cc: nav-users@uninett.no Subject: Re: Problem with uplink detecion
On Wed, 9 Apr 2014 14:49:11 +0000 "martin.jaburek@cah.cz" martin.jaburek@cah.cz wrote:
As you can see, there is that none statement - and it should be some local interface. Also I attached a picture of directly connected neighbors - there are really a lot of them, but it detected only 3 of them.
All the snapshots are for one switch - switchA. CDP is running on every switch and it reports neighbors correctly.
Any idea, what is wrong?
Warning, wall of text ahead:
If you read the "troubleshooting topology" guide, you know NAV has a physical topology at its base, and a VLAN topology on top of that.
What you see in your attached switch port report screenshot, in the "Connected to" column, is what NAV has detected as the physical neighbor on that port. If the data is based on CDP or LLDP, you will usually see both a neighboring device and the connected port on the neighbor device.
If the data is based on analyzing CAM records, the information about the neighboring port may be empty, since that that cannot be deduced from CAM records. If there is a single link between two devices, and data only comes from CAM, NAV can guess that the two involved ports are connected. If there are multiple links between the two devices, or NAV can only get information from one of the devices, no neighboring port information can be deduced.
Your screenshot from ipdevinfo shows the detected uplinks of switchA. This listing is in fact based the detected downlinks to switchA from other devices (this is because you may be looking at a non-SNMP-enabled device, like a server, so the uplinks can only be determined by looking at data from other devices).
Uplinks/downlinks are determined based on NAV's detected VLAN topology, since direction of the link plays an important role here. When NAV analyzes a VLAN, it finds the VLAN root(s), i.e. the L3 router for that VLAN, and searches for the paths to the access ports of that VLAN. The direction is always down from the router to the access port, and up from the access port to the router.
On of the uplinks are listed as "None to Te1/2 at XXXX". This means that NAV has found from the XXXX device that switchA is the neighboring device on port Te1/2. That information likely comes from CAM data, so XXXX doesn't actually know which port on switchA it's connected to. I would agree that displaying "None" here isn't actually very intuitive; it should probably read "Unknown port at switchA" or just "switchA".
All the ports in your attached switch port report screenshot have an empty "derived" column, meaning that NAV has not detected which VLANs are actually active on these ports. This could either be because the topology detector has failed, or that none of the trunked VLANs can be found in the network behind those ports.
Is there any information in `navtopology.log` that seems suspicious?
-- Morten Brekkevold UNINETT