NAV says no cam table support for many switches about nav HOT 3 CLOSED

(by 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.

from nav.

(by 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

from nav.

(by mbrekkevold)
Originator: YES

Fixed in r4251, should be part of NAV 3.3.1.

from nav.