6

I'm using SNMP to poll switches for data. I'm trying to retrieve the MAC address table (sho mac address-table) to view what devices are connected to various ports but I seem to have encountered a problem. In all other posts, questions, and guides the general consensus is to use BRIDGE-MIB::dot1dTpFdbTable or another within that MIB. For whatever reason I cannot use this OID on our equipment. It always spits back "No Such Object available on this agent at this OID."

Requesting the parent object snmpbulkwalk BRIDGE-MIB::dot1dBridge appears to give settings and misc. data but no MAC entries are shown. It's the same across all of our equipment such as C3750, C3850, and C4506. Here's some sample output (C3560E, iOS ver. c3560e-universalk9-mz.122-55.SE3):

BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 30:f7:d:4b:c8:0
BRIDGE-MIB::dot1dBaseNumPorts.0 = INTEGER: 6 ports
BRIDGE-MIB::dot1dBaseType.0 = INTEGER: transparent-only(2)
BRIDGE-MIB::dot1dBasePort.25 = INTEGER: 25
BRIDGE-MIB::dot1dBasePort.26 = INTEGER: 26
BRIDGE-MIB::dot1dBasePort.27 = INTEGER: 27
BRIDGE-MIB::dot1dBasePort.28 = INTEGER: 28
BRIDGE-MIB::dot1dBasePort.29 = INTEGER: 29
BRIDGE-MIB::dot1dBasePort.30 = INTEGER: 30
BRIDGE-MIB::dot1dBasePortIfIndex.25 = INTEGER: 10125
BRIDGE-MIB::dot1dBasePortIfIndex.26 = INTEGER: 10126
BRIDGE-MIB::dot1dBasePortIfIndex.27 = INTEGER: 10127
BRIDGE-MIB::dot1dBasePortIfIndex.28 = INTEGER: 10128
BRIDGE-MIB::dot1dBasePortIfIndex.29 = INTEGER: 10201
BRIDGE-MIB::dot1dBasePortIfIndex.30 = INTEGER: 10202
BRIDGE-MIB::dot1dBasePortCircuit.25 = OID: SNMPv2-SMI::zeroDotZero
BRIDGE-MIB::dot1dBasePortCircuit.26 = OID: SNMPv2-SMI::zeroDotZero
BRIDGE-MIB::dot1dBasePortCircuit.27 = OID: SNMPv2-SMI::zeroDotZero    
BRIDGE-MIB::dot1dBasePortCircuit.28 = OID: SNMPv2-SMI::zeroDotZero
BRIDGE-MIB::dot1dBasePortCircuit.29 = OID: SNMPv2-SMI::zeroDotZero
BRIDGE-MIB::dot1dBasePortCircuit.30 = OID: SNMPv2-SMI::zeroDotZero
BRIDGE-MIB::dot1dBasePortDelayExceededDiscards.25 = Counter32: 0
BRIDGE-MIB::dot1dBasePortDelayExceededDiscards.26 = Counter32: 0
BRIDGE-MIB::dot1dBasePortDelayExceededDiscards.27 = Counter32: 0
BRIDGE-MIB::dot1dBasePortDelayExceededDiscards.28 = Counter32: 0
BRIDGE-MIB::dot1dBasePortDelayExceededDiscards.29 = Counter32: 0
BRIDGE-MIB::dot1dBasePortDelayExceededDiscards.30 = Counter32: 0
BRIDGE-MIB::dot1dBasePortMtuExceededDiscards.25 = Counter32: 0
BRIDGE-MIB::dot1dBasePortMtuExceededDiscards.26 = Counter32: 0
BRIDGE-MIB::dot1dBasePortMtuExceededDiscards.27 = Counter32: 0
BRIDGE-MIB::dot1dBasePortMtuExceededDiscards.28 = Counter32: 0
BRIDGE-MIB::dot1dBasePortMtuExceededDiscards.29 = Counter32: 0
BRIDGE-MIB::dot1dBasePortMtuExceededDiscards.30 = Counter32: 0
BRIDGE-MIB::dot1dTpLearnedEntryDiscards.0 = Counter32: 0
BRIDGE-MIB::dot1dTpAgingTime.0 = INTEGER: 300 seconds
BRIDGE-MIB::dot1dTpPort.25 = INTEGER: 25 BRIDGE-MIB::dot1dTpPort.26 =
    INTEGER: 26 BRIDGE-MIB::dot1dTpPort.27 = INTEGER: 27
BRIDGE-MIB::dot1dTpPort.28 = INTEGER: 28 BRIDGE-MIB::dot1dTpPort.29 =
    INTEGER: 29 BRIDGE-MIB::dot1dTpPort.30 = INTEGER: 30
BRIDGE-MIB::dot1dTpPortMaxInfo.25 = INTEGER: 1510 bytes
BRIDGE-MIB::dot1dTpPortMaxInfo.26 = INTEGER: 1510 bytes
BRIDGE-MIB::dot1dTpPortMaxInfo.27 = INTEGER: 1510 bytes
BRIDGE-MIB::dot1dTpPortMaxInfo.28 = INTEGER: 1510 bytes
BRIDGE-MIB::dot1dTpPortMaxInfo.29 = INTEGER: 1510 bytes
BRIDGE-MIB::dot1dTpPortMaxInfo.30 = INTEGER: 1510 bytes
BRIDGE-MIB::dot1dTpPortInFrames.25 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInFrames.26 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInFrames.27 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInFrames.28 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInFrames.29 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInFrames.30 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortOutFrames.25 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortOutFrames.26 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortOutFrames.27 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortOutFrames.28 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortOutFrames.29 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortOutFrames.30 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInDiscards.25 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInDiscards.26 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInDiscards.27 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInDiscards.28 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInDiscards.29 = Counter32: 0 frames
BRIDGE-MIB::dot1dTpPortInDiscards.30 = Counter32: 0 frames

I know for a fact that the switch is correctly collecting MAC addresses because via CLI it reports back with this:

All    0100.0ccc.cccc    STATIC      CPU
All    0100.0ccc.cccd    STATIC      CPU
All    0180.c200.0000    STATIC      CPU
All    0180.c200.0001    STATIC      CPU
All    0180.c200.0002    STATIC      CPU
All    0180.c200.0003    STATIC      CPU
All    0180.c200.0004    STATIC      CPU
All    0180.c200.0005    STATIC      CPU
All    0180.c200.0006    STATIC      CPU
All    0180.c200.0007    STATIC      CPU
All    0180.c200.0008    STATIC      CPU
All    0180.c200.0009    STATIC      CPU
All    0180.c200.000a    STATIC      CPU
All    0180.c200.000b    STATIC      CPU
All    0180.c200.000c    STATIC      CPU
All    0180.c200.000d    STATIC      CPU
All    0180.c200.000e    STATIC      CPU
All    0180.c200.000f    STATIC      CPU
All    0180.c200.0010    STATIC      CPU
All    ffff.ffff.ffff    STATIC      CPU
100    001e.4a92.5c59    DYNAMIC     Gi0/24
100    0024.c33c.719d    DYNAMIC     Gi0/24
100    0024.c3a8.9c00    DYNAMIC     Gi0/24
100    b000.b4bf.9798    DYNAMIC     Gi0/24
200    0024.c33c.719d    DYNAMIC     Gi0/24
200    0024.c3a8.9c00    DYNAMIC     Gi0/24
500    0080.7752.bbb6    DYNAMIC     Gi0/1
200    2c27.d720.3e4d    DYNAMIC     Gi0/24
200    3417.eb98.f48e    DYNAMIC     Gi0/24
200    b8a3.8607.a6ef    DYNAMIC     Gi0/24
...

Is there a setting within the configs that I need to add in order to make the data available? Has this OID been deprecated and no longer available?

Solution

There was a minor detail omitted in one of the SNMP implementations displayed in other locations. I didn't recognize it but it's likely because I'm either not familiar enough with SNMP or because of how subtle it is.

When polling for the BRIDGE-MIB::dot1dTpFdbTable OID you must append to the community string which VLAN you're looking for. I had not noticed this in the solution because, well, normally said community strings are generic.

For example:

snmpbulkwalk -v2c -cpublic hostname BRIDGE-MIB::dot1dTpFdbTable will return with a "No Such Instance currently exists at this OID"

snmpbulkwalk -v2c -cpublic@vlan hostname BRIDGE-MIB::dot1dTpFdbTable will return all MAC addresses within this VLAN. Note the added @vlan.

Improve this question
0

1 Answer 1

Reset to default
3

Mike answered this pretty well here >> Using SNMP to retrieve the ARP and mac-address tables from a switch

Please have a read of that and if you still need help get back to me.

There is also some Cisco documentation which points to a different OID tree which could be of some help >> http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/13492-cam-snmp.html#mibvaroid

Improve this answer
2
  • I had tried the first implementation previously but did not realize what I was missing. I'll explain it in my post above
    – Kamikaze Rusher
    Jul 21, 2015 at 17:53
  • I'm surprised though that I never came across any instruction of using @vlan before this solution. I did see it once when running a BULKWALK against a switch as a whole but I assumed it meant which VLANs the SNMP string would be accepted on. No other answer across forums explained nor demonstrated the use of it.
    – Kamikaze Rusher
    Jul 21, 2015 at 18:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.