Detecting Switches Connected Behind a Cisco L2 Switch

[jerockwell]

We've had a number of instances where users have connected their own switches behind our access switches and looped the network back to itself causing spanning tree to go crazy or have connected their own switches to build mini-labs on their own.  I'm familiar with bpduguard, loopguard, port-security and the like, but is there a good way to detect other switches which are connected behind our access switches?  Ideally, Something that we could automate (single command and capture output) would be nice.  Things like CDP won't work as the manufacturers of the switches vary and are most often unmanaged (Linksys, Dlink, etc.).  We could ping sweep our access subnets and create a list of any ports which have more than X number of MACs behind them, but that wouldn't scale well unless we scripted something out.  Have any others found a simple solution to detect them?

Unfortunately, Given our environment we must detect and then remediate.  I'd much rather play BOFH and kick them off the network, but... 

[Kyle McKay]

I am not aware of any "tool" that can automatically detect unmanaged switches simply due to the fact that they have no intelligence so to speak - they are do not advertise their presence in any form.

You mention that you are familiar with Port-Security. I think this is your best bet given the described scenario. You could try a configuration such as:

switchport port-security

switchport port-security maximum 1

switchport port-security violation restrict

This configuration will turn on port-security, limit the switchport to a maximum of 1 MAC address and the violation configuration of restrict will send an SNMP trap to the configured server; which will immediately inform you of the presence of an additional MAC address on the switchport. This seems like a good fit for what you are looking for so I would suggest giving it a shot!

Hope this helps you.

[jerockwell]

Unfortunately, I have a need to conduct a discovery to identify situations where we may need to look into additional infrastructure cabling, changing user behaviors to utilize wireless in certain situations, moving adhoc labs into sanctioned spaces, etc prior to enacting any sort of restrictions.

[Kyle McKay]

If those are your requirements you could use a violation mode of "protect".

Protect will flag the administrator via SNMP when a port exceeds or violates its port-security configuration. It will NOT shut down or discard offending traffic. Using this information you could gather which areas/offices have multiple MAC addresses and which may require more investigation.

[Leo Laohoo]

Unfortunately, BPDU guard has one flaw:  If the end device doesn't talk BPDU, then it'll go through.  Hubs, generally, don't talk BPDU.

So the standard protection of BPDU Guard needs to be reinforced with Kyle's recommendation of port security set to a low level.