SNMP Mac-Address Table – Unable to Fetch Mac-Address Table via SNMP

mac addresssnmp

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.

Best Answer

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

Edit:

This is how to poll Q-BRIDGE-MIB for mac-addresses from the only non-Cisco I have, a DLink DGS-3200. I'm not using [community@vlan] for non-Cisco switches. You're correct that this indexing only applies to Ciscos. I expect any non-Cisco switch, which supports Q-BRIDGE-MIB to work the same way.

Polling sysDescr to document the switch under test

[mpenning@tsunami ~]$ # Demo from a DLink DGS-3200 switch
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.2 sysdescr
sysDescr.0 "DGS-3200-10 Gigabit Ethernet Switch"
[mpenning@tsunami ~]$

Walking dot1qVlanStaticName: List Vlans and their text names

[mpenning@tsunami ~]$
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.4.3.1.1
BRIDGE-MIB::dot1dBridge.7.1.4.3.1.1.1 = STRING: "default"
[mpenning@tsunami ~]$

dot1qFdbDynamicCount: Number of mac addresses known

[mpenning@tsunami ~]$ 
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public  172.16.1.2 .1.3.6.1.2.1.17.7.1.2.1.1.2
BRIDGE-MIB::dot1dBridge.7.1.2.1.1.2.1 = Counter32: 17
[mpenning@tsunami ~]$

dot1qVlanCurrentEgressPorts: bitmap of ports in the vlan

[mpenning@tsunami ~]$ 
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.4.2.1.4
BRIDGE-MIB::dot1dBridge.7.1.4.2.1.4.2562.1 = Hex-STRING: FF C0 00 00
[mpenning@tsunami ~]$

dot1qTpFdbPort: All MAC Addresses learned

The mac-addresses show up as a string of six decimal digits in the indexes to dot1qTpFdbPort. Note that I have a downstream switch connected to this switch on port 1/5...

[mpenning@tsunami ~]$ 
[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public 172.16.1.2 .1.3.6.1.2.1.17.7.1.2.2.1.2
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.101.22.202.65 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.189.7.134.128 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.13.189.7.134.129 = INTEGER: 5
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.29.161.205.83.70 = INTEGER: 9
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.48.27.188.167.215 = INTEGER: 2
BRIDGE-MIB::dot1dBridge.7.1.2.2.1.2.1.0.192.183.110.158.29 = INTEGER: 3

... more entries here
[mpenning@tsunami ~]$

dot1dBasePortIfIndex: Map values from dot1qTpFdbPort to an ifIndex

[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.26 .1.3.6.1.2.1.17.1.4.1.2
dot1dBasePortIfIndex[1] 1
dot1dBasePortIfIndex[2] 2
dot1dBasePortIfIndex[3] 3
dot1dBasePortIfIndex[4] 4
dot1dBasePortIfIndex[5] 5
dot1dBasePortIfIndex[6] 6
dot1dBasePortIfIndex[7] 7
dot1dBasePortIfIndex[8] 8
dot1dBasePortIfIndex[9] 9
dot1dBasePortIfIndex[10] 10

ifName: Map values from ifIndex to an ifName

[mpenning@tsunami ~]$ snmpbulkwalk -v 2c -c public -OXsq 172.16.1.26 ifName
ifName[1] 1/1
ifName[2] 1/2
ifName[3] 1/3
ifName[4] 1/4
ifName[5] 1/5
ifName[6] 1/6
ifName[7] 1/7
ifName[8] 1/8
ifName[9] 1/9
ifName[10] 1/10
ifName[5121] System
[mpenning@tsunami ~]$

ORIGINAL:

There is a mistake in your OID, you're using 1.3.6.2.3.1.17.4.3.1.1; however, dot1dTpFdbAddress is 1.3.6.1.2.1.17.4.3.1.1.

The difference is changing some octets, below...

OID Incorrect: 1.3.6.2.3.1.17.4.3.1.1   <--- Not this
OID Corrected: 1.3.6.1.2.1.17.4.3.1.1   <--- Use this
                     ^ ^
                     | |

MAC Address – Importance of Local vs Globally Unique Addresses

Not every device has a globally unique MAC address, and I'm not sure why you think that. Some layer-2 protocols (in particular the IEEE LAN protocols) use MAC addressing, but some use other addressing or no addressing at all. Of those that use MAC addressing, some use 48-bit MAC addresses, and some use 64-bit MAC addresses, but all are LAN (layer-2) protocols.

A vendor can buy an OUI from the IEEE, and they can assign the MAC addresses in its OUI as it sees fit. A vendor that makes ethernet, token ring, Wi-Fi, etc. NICs can reuse the same MAC address on all those. Some vendors reuse MAC addresses in different regions of the world.

If you mean the reason for the U/L bit in the OUI, that was part of the original specification. End-users can set that bit and assign MAC addresses in a way that works for them.