Switch – the difference between ipNetToMediaPhysAddress and dot1qTpFdbPort

mac addressmanagementsnmpswitch

I see the object description of ipNetToMediaPhysAddress from ipNetToMediaTable as the "The media-dependent `physical' address". Putting it simple, does it mean it returns the MAC addresses of all the directly connected nodes/devices?

  • For example,
    snmpbulkwalk -v 2c -c public 10.21.200.201 1.3.6.1.2.1.4.22.1.2
    Polling this OID (1.3.6.1.2.1.4.22.1.2) on a L3 switch-(Ip:10.21.200.201) (Brocade FastIron Sx 800) returns me approximately 1800 entries which is a mixture of both L2/L3 devices and some PCs. But polling the same OID on an L2 switch returns me only four entries: 2 broadcast entries,the previous L3 switch's MAC address and the L2 switch's self MAC address. There are PCs attached to this L2 switch(DLINK DES 3526 model). Why can't I see MAC addresses of the attached PCs on polling the OID for the above switch?

Also can someone throw light on the fine differences between the MAC addresses learned from dot1qTpFdbPort and ipNetToMediaPhysAddress?

Best Answer

Why can't I see MAC addresses of the attached PCs on polling the OID for the above switch?

When you poll 1.3.6.1.2.1.4.22.1.2, you're polling ipNetToMediaPhysAddress, which is the ARP table of the switch. Pure Layer2 switches do not have a large ARP table because they are merely switching instead of routing. Switching does not require an ARP table.

Also can someone throw light on the fine differences between the MAC addresses learned from dot1qTpFdbPort and ipNetToMediaPhysAddress?

  • dot1qTpFdbPort maps the Layer2 mac-address recently learned by the switch to a physical port on the switch.
  • ipNetToMediaPhysAddress polls the ARP table of something. The only things that show up in the ARP table are things which had recent, direct IP-layer communication with the thing being polled. IP-layer communication occurs when packets are routed, or for instance if you ssh directly to a Layer2 switch's management IP.

If you poll ipNetToMediaPhysAddress on a router attached to the Brocade / DLink Layer2 switches, you will see the same dot1qTpFdbPort mac-addresses from the Layer2 switches in that router's ARP table (assuming you did a recent ping sweep of the relevant subnets through the router in question). Also note that if VRRP / HSRP / GLBP are used on the subnet, you should poll ipNetToMediaPhysAddress both FHRP peers, due to potential asymmetric routing.

ARP / Mac Polling Technique

I have to do a lot of polling like this where I map mac addresses / ports found in dot1qTpFdbPort to IP addresses from ipNetToMediaPhysAddress. I always ping sweep (with a tool like nmap... nmap -sP 192.0.2.0/24) through the subnet just before I poll the router / downstream switches with snmp.

[Edit Questions in Comments]

So polling the dot1qTpFdbPort on an L2 switch guarantees that the resulting MAC addresses/ports are the ones directly connected to the L2 switch?

Not quite true... polling dot1qTpFdbPort guarantees that these are the mac addresses learned by the switch, or statically configured on the switch. A few notable exceptions to your statement:

  • If you chain Layer2 switches together (including most FHRP topologies), you'll see mac addresses learned from downstream switches. By definition, macs learned from downstream switches are not directly connected. If you have Cisco switces, cdpCacheTable is very useful for untangling relationships between switches.
  • Some mac-addresses in dot1qTpFdbPort could be owned by the switch itself, instead of being directly connected to it.
  • If you have LACP aggregates in your topology, the vendor might do things like associate mac-addresses with a physical port in that LACP aggregate, instead of learning the mac through the LACP aggregate. Somewhere in the standards I saw discussion about this, but I can't remember where offhand.
  • Some switches have vendor-specific features (often they are security features) which completely remove visibility of mac-addresses from dot1qTpFdbPort. YMMV

All the above means you cannot 100% guarantee that the mac returned by dot1qTpFdbPort is directly connected to the switch. If you take care of these kind of issues in your code, then you shouldn't have problems.

PS: I haven't tried ICMP sweep (ping sweep).Is it really necessary to do ping sweep so as to obtain the complete topology of the network?

Ping sweeps mitigate these two issues:

  • Switch mac-table aging timers vary, but they can be quite low (i.e. 5 minutes). It's not uncommon to see mismatched router ARP and switch mac table timers in a network. Sometimes the ARP and switch mac tables get out of sync. You stand the best chance of matching switch mac table to router ARP table if you ping sweep just before your polls.
  • Some end-points may only receive unidirectional traffic (i.e. a multicast stream). If someone is passively watching or listening to a unidirectional stream, their PC might not refresh the switch mac-address table very often.
Related Topic