Detecting multiple hosts behind a single managed switch port

Discussion in 'Cisco' started by Matt, Aug 22, 2006.

  1. Matt

    Matt Guest

    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?

    Matt, Aug 22, 2006
    1. Advertisements

  2. 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.)
    Walter Roberson, Aug 22, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.