Customers have sent us comments that Intermapper won't show certain kinds of equipment properly. We have investigated, and found a bug in the SNMP implementations of certain vendors. To find out if your equipment is susceptible to this bug, you may follow this procedure.
Intermapper uses Get-Next-Requests to retrieve data. To be more efficient, it sends several OIDs in each query. When we use the net-snmp "snmpgetnext" to retrieve single variables, the results come back properly. When we queue up multiple OIDs in a request, they come back wrong.
First, download net-snmp from http://net-snmp.org. net-snmp is a highly-reliable, open-source snmp query tool and agent for Unix and Windows. Install net-snmp as described in its documentation.
Then use net-snmp's command-line tools to send Get-Next-Request queries to the device in question. For example:
# request ipAdEntAddr first, then ipAdEntifIndex
[richb@jig ~]# snmpgetnext IPADDRESS COMMUNITY ipAdEntAddr ipAdEntifIndex
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = IpAddress: 127.0.0.1
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = Wrong Type
(should be INTEGER): IpAddress: 127.0.0.1
# other order: ipAdEntifIndex, then ipAdEntAddr
[richb@jig ~]# snmpgetnext IPADDRESS COMMUNITY ipAdEntifIndex ipAdEntAddr
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 = Wrong Type
(should be IpAddress): 1
In the examples above, snmpgetnext requests two variables from the device at IPADDRESS, using the SNMP Read-only community string of COMMUNITY (you should substitute your values as needed). In the first case, the entity's address comes before the ifIndex in the query. Note that both responses have the value 127.0.0.1 (the latter is incorrect). In the second example, the ifIndex precedes the entity's address, and the result is "1" (again, the latter is incorrect).
If you see results like this, contact the vendor of your equipment to explain this problem and ask if a new release of firmware has fixed it.
