Q. Is there a way to force InterMapper to do a sequential traversal of the ifTable? I am missing interface statistics for a fibre-channel interface.
A. Some network equipment will respond incorrectly to SNMP queries for the ifTable and related tables when we try to query only certain entries in a sparse ifTable, rather than trying to query each possible index in turn. The 'IFINDEX-BUG' can be added in the flags = section of a custom SNMP probe header. Adding this flag will instruct InterMapper to work around this situation rather than attempting to be efficient.
When InterMapper initially discovers an SNMP-speaking device, it uses a standard snmpwalk (a series of repeated get-next-requests) to discover and build a master list of the ifIndex for each of the interfaces.
During normal operation, InterMapper uses this master list of interface index values to retrieve the stats for that interface (ifInOctets, ifOutOctets, ifDiscards, etc.) That is, it uses each of the ifIndex values saved in the master list to query the interfaces.
InterMapper's normal polling algorithm uses Get-Next-Requests to retrieve the values. Consequently, InterMapper requests the (desired ifIndex-1) to get the desired information. For example, to get ifInOctets for ifIndex 123, InterMapper will send a get-next-request for this OID:
18.104.22.168.22.214.171.124.1.10.122 <== note the "row" is one lower than 123
With most equipment, this works perfectly, because the equipment returns the OID "after" (that follows) 126.96.36.199.188.8.131.52.1.10.122, which is the value for row 123.
There is some equipment, though, that doesn't follow this rule, and instead, returns a value for some other ifIndex. For example, certain Cisco fiber extenders have this behavior:
- InterMapper wants to retrieve the ifIndex N.
- InterMapper sends request for ifIndex N-1.
- Device responds with information labelled as ifIndex N+63 (which doesn't exist in the master list, so InterMapper does not record the information).
In this case, no traffic will be seen on these interfaces.
The workaround is to use the IFINDEX-BUG flag. This causes InterMapper to issue a get-next-request for the ifIndex that is one greater than the previous row in the master interface list. For example, the master interface list might contain these interfaces:
N1 (ifIndex is 5001234)
N2 (ifIndex is 5001789)
N3 (ifIndex is 5001801)
To get the data for N2 (whose ifIndex is 5001789), the IFINDEX-BUG flag will cause InterMapper to issue a get-next-request for ifIndex 5001235 (= 5001234+1).