On Thu, 29 Mar 2012 06:40:29 +0000 Rene Romijn r.romijn@deli-ict.nl wrote:
Ok, do a final one for .1.3.6.1.2.1.47.1.2.1.1.4 (ENTITY-MIB::entLogicalCommunity). You don't need to paste the output, since it will likely be a bunch of community strings.
Are all these strings the same, and are they all the SNMP community of your device? If so, I think I know what the problem could be.
I have paste i little part of the command:
iso.3.6.1.2.1.47.1.2.1.1.4.93 = STRING: "@stg93" iso.3.6.1.2.1.47.1.2.1.1.4.94 = STRING: "@stg94" iso.3.6.1.2.1.47.1.2.1.1.4.95 = STRING: "@stg95" iso.3.6.1.2.1.47.1.2.1.1.4.96 = STRING: "@stg96" iso.3.6.1.2.1.47.1.2.1.1.4.97 = STRING: "@stg97"
It goes from @stg1 to @stg128
Are those actual community strings that were reported, or are they prefixed by your switch' community?
I'm guessing your Gbe2c switch supports the MSTP protocol, and this is how it reports spanning tree groups (since the BRIDGE-MIB is only adapted to a single spanning tree). I quickly googled Gbe2c and found they have a proprietary MIB to map VLANs to spanning tree groups.
Nevertheless, it seems Gbe2c doesn't use multiple BRIDGE-MIB instances to add per VLAN-information in the same manner as Cisco does. I think maybe the best way for NAV to work around this is to limit itself to doing it the "Cisco way" only if the device reports a Cisco enterprise ID.
Even if we do fix it like that, NAV will not be able to get a proper list of STP blocking ports on your Gbe2c switches. That would require an implementation of their proprietary MIB, and I have no Gbe2c device to test on. NAV should, however, be able to get a proper switch port listing for your switch.