I want to get MAC address of machines directly connected to a switch using SNMP. I am querying dot1qTpFdbPort for this. But this returns all the MAC addresses learned by switch which includes machines which are not physically connected to this switch but are learned by switch.

How do get MAC addresses of only those machines which are physically connected to ports on switch?

My goal is to figure out all the machines which are physically connected to a switch.

I am using a non cisco switch. But I want to implement a generic method for all boxes.

 [root@dani ~]# snmpwalk  -c public -v 2c **sysDescr**
 SNMPv2-MIB::sysDescr.0 = STRING: **3Com Baseline Switch 2928-SFP Plus**
 Software Version 5.20 Release 1101P10
  • Please review this Q&A, the only thing lacking from that discussion is rejecting uplinks from the results. Rejecting uplinks requires us to know something about how you're managing the infrastructure... i.e. are you using LLDP on all other switches? If so, then it's not so hard to eliminate infrastructure uplinks in your results Nov 20, 2014 at 12:24
  • I am going to run this as part of my network discovery tool which finds a physical connection map between switches and hosts. This is going to run at customer's networks. Only access I can get is SNMP RO community string. Thanks for mentioning about determining uplinks way.
    – Subhash
    Nov 20, 2014 at 13:07
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Jan 5, 2021 at 1:58

3 Answers 3


There is no way for a switch to determine whether the device plugged in to a particular port is an 'end host' or a second switch with many end hosts. You could, guesstimate, that if multiple MAC addresses are learned on a single port, then that port is connected to another switch. But that leaves you open to misidentifying a connection to another switch with only one other host behind it as a host (and not an actual switch).

You would have to depend on some extra configuration on the switch, to identify whether the port is connected to an end-host, and if so, pull the MAC address table for that interface.

For example, if you pull a list of all the interfaces, and determine which of them are marked as "Portfast" (or "Edge" ports, for non Cisco gear). That is almost a guarantee of that particular interface being connected to an end host (just almost, see below comments by MikePennington and others), and then when you pull the full MAC address table, filter it to just 'store' the data on the portfast/edge ports.

  • 1
    FYI "portfast" is not always indicative of user ports; some engineers advocate portfast on all ports Nov 20, 2014 at 18:20
  • @MikePennington, to clarify, I believe the point is to use portfast on all client/customer facing ports (along with BPDUGuard), whether they are access ports or trunk ports. If you provide an trunk port to a client device without portfast enabled and are running RST on your network (or possibly MST depending on configuration), then you will most likely result in a situation where your network will take as long as CST to converge rather than the faster RST timers.
    – YLearn
    Nov 20, 2014 at 19:44
  • @MikePennington, there are always exceptions ;) I changed the wording of that phrase to indicate its not a guarantee. But, I think we can all agree that in most networks, a "portfast" interface is going to typically (99% of the time) mean an end host. If a Portfast idealist happens to be in charge of the network, and intentionally set all his ports to Portfast, then surely when Subhash explains how his application works, that particular idealist will clue in that his network is the exception case.
    – Eddie
    Nov 20, 2014 at 20:13
  • I had to go ask on that old thread why portfast towards switches... I recognize the poster so I know he's got a valid reason for saying that, I just don't know what it is.
    – cpt_fink
    Nov 21, 2014 at 5:57

This information is very dated.


Quick search revealed a LLDP-MIB in the Cisco SNMP Object Navigator. The above link makes me question which switches, if any, actually support this object. Perhaps it's worth a look... It may only get your local switch information, not neighbor info. You could guesstimate as other posters stated above by using SNMP to determine if a port is in trunk mode and combine that with the number of learned MAC addresses per interface to improve your odds.



A switch only knows which port a MAC address is behind. Not whether there are other switches between it and the host with that MAC address.

You could filter the port/mac data you gather to ports with MAC addresses counts below a threshold. The downside of that approach is that some MACs may not appear in your data at all (e.g. unmanaged switch on someones desk, VM setups that result in one host having multiple MACs) or may appear more than once (if the total devices behind a switch is less than your threshold).

A more subtle approach would be to gather the MAC/port data from all your switches to produce a list of MAC addresses behind every switchport. Then look for the shortest list that contains each MAC address. This will represent the switchport closest to the device (occasionally you may get duplicates if a switch has only one port in use but it shouldn't be too hard to resolve these manually). If you find a lot of MACs with the same closest switchport you probablly need to gets someone to investigate what is on the end of it.

Your Answer

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

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