NAV says no cam table support for many switches

[Morten Brekkevold]

We've received several reports about missing machine tracker data for
switches. Looking at the OID compatibility profile of these switches, one
sees that NAV has decided these switches are not compatible with the
macPortEntry OID (dot1dTpFdbPort), which contains the cam table (or bridge
table, if you will).

Having getDeviceData's OID-tester re-classify these switches seems to have
no effect, as it still says the switch does not answer the macPortEntry
query. A switch without an accessible bridge table is not worth the
plastic it is contained in.

Further investigation reveals that only Cisco switches are affected, and
that these switches either do not have a VLAN 1, or that there are no
entries in the bridge table for VLAN 1.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1812189&group_id=107608&atid=648170]

[Morten Brekkevold (mbrekkevold)]

Originator: YES

When a Cisco switch is queried for dot1dTpFdbPort, it will return the
mac-port mappings for VLAN 1. If the string '@20' is appended to the
community string of the request, the switch will return the mac-port
mappings for VLAN 20. Cisco switches have a BRIDGE-MIB instance for each
active VLAN, and this is how to retrieve it (it is termed "community string
indexing" by Cisco).

getDeviceData will know that a Cisco switch supports many instances of
BRIDGE-MIB, and will try to extract a list of active VLANs before OID
testing begins. If there is no useful reply from macPortEntry using an
unmodified community, it will modify the community according to the list of
known VLANs and attempt the same query until a useful reply is found.

Yet, the logs show that getDeviceData's OID-tester gives up further
testing of macPortEntry as soon as it figures no useful answer was received
when using an unmodified community.

[Morten Brekkevold (mbrekkevold)]

Originator: YES

Prior to NAV 3.2, the OID tester would use community string indexing for
any OID that it got no answer from when using an unmodified community
string. NAV 3.2 introduced an optimization that only began community
string indexing for OIDs from the BRIDGE-MIB, since these are the only OIDs
where this is useful and applicable.

The change that introduced this was committed by me, and it seems that a
single missing line in this patch makes sure gDD actually won't know which
MIB an OID came from, and therefore will not use community string indexing
for anything.

*smacks self on forehead and bangs head against the desk*

[Morten Brekkevold (mbrekkevold)]

Originator: YES

Fixed in r4251, should be part of NAV 3.3.1.