Network Map Algorithm that Detects Unmanaged Layer 2 Switches?

Question

I've inherited a network spread out over a warehouse/front office consisting of approximately 50 desktop PCs, various servers, network printers, and routers/switches.

The "intelligent" routers live in the server room. As the company has grown, we've annexed additional space and not very elegantly run various lengths of CAT5 thru the ceilings etc. I've been finding various hubs and switches in the ceilings -- none of which is labeled or documented in any way.

Of course, das blinken-lights tell me that someone is connected to these devices, I just have no way of finding out who.

I can run traditional network map tools (there are tons of these things) and it shows me the IP-based things in the network. That's nice, but information I already have. What I need to know is the network topology -- how the switches (bridges) are interconnected etc.. And since they are off-the-shelf linksys unmanaged-types, they don't respond to SNMP so I can't use that...

What's the best/cheapest tool out there that I can use to analyze and detect things like hubs and switches in the network that don't respond to SNMP?

If there's no tool that you're aware of -- what generalized algorithm would you suggest to find this out? My guess would be that I could look at the MAC forward tables for the devices (switches, desktops, etc.) and build a chain that way, but I don't know if it's possible to get that from an unmanaged switch (let alone a hub).

(This patent has some neat ideas but I can't find any software built with it: http://www.freepatentsonline.com/6628623.html)

Thanks!!

Grayce

Answer 1

An idea could be to use a program like 3com network director trial version (or The Dude). Use it to discover all of your workstations and anything else with an IP address.

Wait for a quiet time and unplug each hub/switch ... you'll then at least begin to be able to make a map, the rest will be crawling about following cables. Network administration does mean getting dirty.

Disdainful

Ooh I like that idea. It's disruptive, though, so it means I get to do it late at night or on the weekend... but I think that could work... – Grayce

Yep, it's very disruptive. But hopefully you'll find everything. Usually helps to have another perosn with a mobile phone as well :-). I've had to crawl about some right mucky places at times. – Disdainful

Answer 2

You probably can't explicitly detect unmanaged devices... but you have MAC -> switch port mappings, on your managed ones, right? If so, you should be able to infer the presence of unmanaged switches / hubs with more than one connected client -- I don't know how you'd find a port with only one.

1. Record the MAC addresses of all smart switches and client devices
2. Start from one of your known smart switches
3. For each port on the switch, list the MAC addresses it's forwarding. If it lists one client, it's direct. If it's more than one and none of the addresses are in your known switch MACs, you've got a dumb switch. If it's more than one and one address is in your set of known switches, recurse on this switch.

You probably don't have any accidental loops in your network topology (or your network probably wouldn't work) so you can probably assume a tree structure outside your core.

Janinejanis

I thought about that -- but downstream I have a 'dumb' switch daisy-chained to another dumb-switch -- so I don't have any visibility further downstream... – Grayce

O.O Yup. It's time to get dirty, then ;-) – Janinejanis

Answer 3

You could try to get spanning-tree protocol information out of the smart switches; even unmanaged switches have to participate in this protocol (this doesn't apply to hubs, though).

Gwyngwyneth

Answer 4

I don't think unmanaged switches/hubs will have arp entries - being transparent at the mac layer is their reason for existing.

And I don't think there's a way to get their MAC forwarding tables short of taking them apart and finding a JTAG or other port to talk to them with, which is unlikely to be feasible.

The best idea I can come up with is to pingflood each internal IP in turn, and then while that's going on, try and ping all the other IPs. This will help because you'll only get decent responses from machines that don't share a (now congested into oblivion) link with the one you're pingflooding. Basically you're using the fact that the backplane on the switches is much faster than the interconnects between them to map out which connections are via interconnects and which are via backplanes. This also lets you watch das blinkenlights and figure out which ports are used to connect to which IPs.

Sadly I know of no software that will do this for you.

Belgravia

Answer 5

I've personally had the same issue. Fun. I partially solved the problem by installing new Cisco Catalyst Switches in the main data closet and setting the Smart Ports profile on each port to "Desktop". This limits the port to 1 MAC address.

Any port with an unmanaged hub/switch attached will be automatically disabled the first time more than one device is activated on the unmanaged device.

As I located unmanaged hubs/switches I replaced them with managed switches configured to limit each port to 1 MAC.

If your budget won't allow this, the alternative is to trace each wire visually and manually verify the presence of unmanaged networking equipment.

Stirling

Answer 6

I've been looking into this and I found this old research paper Using VPS Probing to Discover Layer 2 Topology. The theory is that you can use Variable Packet Size (VPS) probing to discover layer 2 switches by the delay they introduce. I haven't had a chance to try it in practice yet.

Update: I found a later version of the paper called Using Simple Per-Hop Capacity Metrics to Discover Link Layer Network Topology

Coats

Answer 7

You can try NetskateKoban, that will give you the map with the number of terminals connected to each port of the managed switch. You can know the presence of unmanged device from there by the vendor name.

We have seen a similar kind of problem, where a network admin had to figure out how many switches (managed/unmanaged) are present. It will give you the location of such places. Try it out... all the best

Mathews

Answer 8

If you haven't already, try HP Openview trial version, and apart of using SNMP, it also uses ARP tables to figure out your topology.

Rodin

Answer 9

You can expect these features in release of AdventNet's opmanager8.0 next month

Angary