Re: Detecting multiple hosts behind a single managed switch port
- From: roberson@xxxxxxxxxxxx (Walter Roberson)
- Date: Tue, 22 Aug 2006 21:46:14 GMT
In article <1156277281.682129.260820@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Matt <matt.kaar@xxxxxxxxx> wrote:
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.
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.
Do any other programs come to mind?
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.)
.
- References:
- Prev by Date: Cisco 2924 switch commands for multiple ports
- Next by Date: ACL Help - Two Interfaces and NAT
- Previous by thread: Detecting multiple hosts behind a single managed switch port
- Next by thread: VPN client - growing profile
- Index(es):
Relevant Pages
|
