Hi,
I just face another problém with uplink detection. I tried to follow documentation about troubleshooting topology, but it yielded no results.
I check switchport report of both connected devices and there it is showed in the columnt labeled as connected to.
I also check cdp and it also report it correctly.
I also found another problém when it displays an actual uplink, but with empty from device (which seems to me quite strange). In other case an uplink is showed only on one device but not the other.
Is there any limit about number of uplinks? (I have more then ten uplinks on one box)
Brgds
Mat
-----Original Message----- From: nav-users-request@uninett.no [mailto:nav-users-request@uninett.no] On Behalf Of Morten Brekkevold Sent: Thursday, March 27, 2014 3:09 PM To: nav-users@uninett.no Subject: Announcement: NAV 3.15.7 released
For those of you who wish to continue running NAV 3.15 for while, the seventh maintenance release of this series is now available for download at Launchpad: https://launchpad.net/nav/3.15/3.15.7
This release fixes 12 reported issues:
* LP#1251211 (portadmin wishlist: option to reset active interface whene changing vlan) * LP#1285601 (Switch ports on non-existant VLANs on Cisco switches don't appear as switch ports in NAV) * LP#1287700 (SeedDB will readily accept serial numbers with trailing spaces) * LP#1289219 (affected displays no information on nodes not in topology) * LP#1289320 (Submitting invalid alert subscription forms cause crash instead of error message) * LP#1291956 (LDAP auth against MS AD broken since NAV 3.14.1592653) * LP#1291978 (User supplied login name is not escaped in LDAP search filters, causing possible injection vulnerabilities) * LP#1292513 (sysname/reverse dns lookups are inconsistent or lacking after a bulk import) * LP#1293621 (missing cascade in table accounttool) * LP#1295092 (Only modules and power supplies on first member are collected from stacked HP 2920) * LP#1297200 (powersupplywatch crashes when there are more than ~1024 devices to poll) * LP#1297767 (Django exposes sensitive data like: username/password)
Please report further bugs at https://launchpad.net/nav/+filebug
A binary package for Debian Wheezy has been made available in our APT repository, as usual.
Happy NAVing everyone!
-- Morten Brekkevold UNINETT AS
On Thu, 27 Mar 2014 14:38:36 +0000 "Martin.Jaburek@cah.cz" Martin.Jaburek@cah.cz wrote:
I just face another problém with uplink detection. I tried to follow documentation about troubleshooting topology, but it yielded no results.
I check switchport report of both connected devices and there it is showed in the columnt labeled as connected to.
I also check cdp and it also report it correctly.
I'm sorry, but I'm failing to understand what your exact problem is, based on this description. Could you be more specific, please?
I also found another problém when it displays an actual uplink, but with empty from device (which seems to me quite strange). In other case an uplink is showed only on one device but not the other.
Where are you looking? /ipdevinfo? Can you provide a screenshot?
Is there any limit about number of uplinks? (I have more then ten uplinks on one box)
No.
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?
Mat
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Monday, April 07, 2014 3:11 PM To: JABUREK Martin Cc: nav-users@uninett.no Subject: Re: Problem with uplink detecion
On Thu, 27 Mar 2014 14:38:36 +0000 "Martin.Jaburek@cah.cz" Martin.Jaburek@cah.cz wrote:
I just face another problém with uplink detection. I tried to follow documentation about troubleshooting topology, but it yielded no results.
I check switchport report of both connected devices and there it is showed in the columnt labeled as connected to.
I also check cdp and it also report it correctly.
I'm sorry, but I'm failing to understand what your exact problem is, based on this description. Could you be more specific, please?
I also found another problém when it displays an actual uplink, but with empty from device (which seems to me quite strange). In other case an uplink is showed only on one device but not the other.
Where are you looking? /ipdevinfo? Can you provide a screenshot?
Is there any limit about number of uplinks? (I have more then ten uplinks on one box)
No.
-- Morten Brekkevold UNINETT
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?
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
On Thu, 10 Apr 2014 12:00:24 +0000 "martin.jaburek@cah.cz" martin.jaburek@cah.cz wrote:
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.
NAV will traverse the path of each VLAN individually, starting at the determined root router port for that VLAN. NAV does not get root information from STP, but has detected which subnet prefix(es) are routed on that VLAN, and uses this to detect the root router port.
On the device connected to that router port (or on the same device, in the case of an L3 switch), NAV will descend further on all trunks with the current VLAN allowed, and non-trunks having this as their native VLAN.
STP information is only used to find STP blocked ports. STP blocked ports will not be traversed by the detector, only registered as blocked on the VLAN that is being detected.
Or if we have different allowed vlans from one side and the other side?
You mean a mismatch in the list of allowed vlans on each side of a trunk? That would be logged as an error.
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.
Do you mean to say there are _no_ uplinks listed whatsoever, or that there are uplinks where the port name is unavailable?
I'm not sure about rules you apply for uplink detection, maybe the log will help
What is the actual uplink of DEVICE_003?
According to your log, most VLANs are attempted traced through Gi0/24 on DEVICE_003, but most of them seem to be STP blocked on this port.
If this is the actual uplink, but it is STP blocked on all VLANs, NAV will not set a direction for the port/VLAN combination, it will set the port/VLAN combination as blocked. If there is no information about directionality of the link, nothing will be listed in the uplinks list.
-
martin.jaburek＠cah.cz -
Martin.Jaburek＠cah.cz
-
Morten Brekkevold