Detecting multiple hosts behind a single managed switch port

I'm looking for a tool that can query a list of managed switches (both Foundry and Cisco) via SNMP and return ports on those switches that have more than one end host connected (based on MAC addresses). It would need to filter out ports that are connected to other managed switches in the list as well as ports that are setup as trunk links.

The reason for finding these ports in use by multiple hosts is to eventually get each host on its own port and implement 802.1x access controls on these managed switches.

I've already looked at tools from SolarWinds (their port mapper doesn't scale beyond a single switch), and I'm in the process of looking at Netdisco.

Do any other programs come to mind?

Thanks, Matt

Reply to
Loading thread data ...

This task is a bit tricky because on the Cisco, the MAC address tables are per-VLAN, so you need to enumerate over the VLANs when doing the MAC checking. Unfortunately, the documentation on what replaced SNMP "community indexing" is difficult to find, and which style of community indexing is supported for a given device is not always clear. I don't recall at the moment whether I eventually tracked down the OIDs needed to enumerate the VLANs.

Most VLAN SNMP operations are in the private OID range, so the mechanisms to extract and analyze the information can vary between manufacturers and models.

A couple of other considerations are:

- it is a bit tricky to figure out whether a particular port is an uplink or not. Looking for VLAN trunks -helps-, but if you happen to have legitimate uplinks that are not trunked, then deciding the status of an individual port is not so easy. You cannot use IP address because you are looking at layer 2 and port-based VLANs especially might not have any accessible IP address. You cannot simply use MAC address either, as each port must have its own MAC address (this is required by STP) and there is not necessarily a relationship between the MAC of a switch's management IP and the MAC of its ports, especially if if the switch is big enough to have replaceable line cards. [I did not look into CDP, as we have few devices that use CDP.]

- you can't just take a simple snapshot: MAC addresses disappear from the tables fairly readily, and by chance one might be active while another is not.

I do this kind of analysis in one of my programs, at least for some Nortel/Bay Networks switches. I did not happen to have enough access to a Cisco router at the time to ensure that I got all the details of community indexing right, so it might need to be extended for Cisco. I haven't ever worked with Foundry.

The analysis routine itself was deliberately written to work off of recorded SNMP responses (with no active probes), with driver routines that had just enough intelligence to figure out what kind of device was being talked to and then to walk the appropriate table subset recording the information. This allows regular batch "get in and get out" SNMP snapshots, followed by later liesurely analysis and re-analysis.

Like a lot of network programs, there aren't really many "tricks" to the code: a lot of the work was in figuring out what had to be queried, how to represent it, how to parse the results, how to extract useful information out of the data, and how to present the information in a compact but readable fashion. The sort of code that most competant programmers could produce, given the idea and time enough.

The biggest "trick" in the code is this: Switches and routers *lie*. There are a couple of places where you need to know what they lie about, in order to know why you cannot just do the "obvious" query for the information you want.

Unfortunately, I don't think I can just give my code away -- and as per the above, it would probably need some adaptation for correct handling of Cisco VLANs. I can answer questions based upon what I learned while doing it, though ;-) (If you get really stuck, we do have mechanisms for licensing out software, especially so to R&D organizations.)

Reply to
Walter Roberson Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.