On Thu, 21 Dec 2017 14:09:50 +0100 Biselx Nicolas nicolas.biselx@epfl.ch wrote:
The Topo job does not work with Cisco VG350/K9 that I introduced in the GW category. I put the debugging and it remains blocked on the discovery of Vlan1. (see the log)
I do not know if I'm missing MIBs or if it's a bug?
Any ideas ?
Just some general comments first:
The topo job hangs while attempting to get the switch forwarding table (the `cam` plugin). I'm not sure why it would need to do this at all, given that this is not a SW or GSW category device. In the "reverse" situation, the `arp` plugin will actually skip any device that is _not_ in the GW or GSW category.
2017-12-21 11:39:18,575 [DEBUG nav.mibs.bridge_mib.multibridgemib] [topo vg-epfl-sec-01.epfl.ch] now querying 'vlan1' ^C2017-12-21 11:42:54,453 [WARNING nav.ipdevpoll] SIGINT received: Shutting down
Given that this appears to hang "indefinitely", how are your SNMP options set in `ipdevpoll.conf` (timeout, max-repetitions, etc)?
Cisco never implemented Q-BRIDGE-MIB, but instead employs their own slow-ass hack for providing community-indexed access to a BRIDGE-MIB instance per VLAN. This does tend to be really slow at times, but there should be results in the end. What is the longest you have had patience to wait for this?
Can you use tcpdump to confirm whether there is any actual SNMP traffic going back and forth between NAV and your VG350?