The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
The Invisible Catalyst Switch
By stretch | Thursday, April 15, 2010 at 3:55 a.m. UTC
If you've ever looked at a packet capture from a Cisco Catalyst switch with a default configuration, you know they produce a good amount of ambient noise out of the box. CDP, STP, DTP, keepalives - these are all turned on by default and, combined, generate a significant amount of traffic. This isn't a bad thing; most of these protocols are enabled for good reason (DTP being the evil, evil exception). But it does give rise to an interesting question: can we make a Catalyst switch absolutely silent and transparent to connected devices?
Turning off CDP
We'll start out with an easy one: globally disabling Cisco Discovery Protocol (CDP).
S1(config)# no cdp run
This prevents CDP packets from being broadcast out all interfaces every 60 seconds.
Turning off DTP
Cisco's Dynamic Trunking Protocol (DTP) allows switches to automatically form trunks among themselves. It is, for some reason, enabled on all switch ports by default. To disable it, we configure all ports for static access mode and issue the command switchport nonegotiate to completely disable DTP. (Incidentally, this is also considered a best practice for production devices.)
S1(config)# interface range f0/1 -24 S1(config-if-range)# switchport mode access S1(config-if-range)# switchport nonegotiate
Turning off STP -- Wait, What?!
For the purpose of our experiment only, we need to disable spanning tree. Do not do this on a production device. STP is your friend.
S1(config)# no spanning-tree vlan 1
Turning off Ethernet Keepalives
While sniffing a link on a Catalyst switch, you may have noticed "LOOP" packets being sent from the switch to itself every ten seconds. These are Ethernet keepalives, and they can be disabled under interface configuration.
S1(config)# interface range f0/1 -24 S1(config-if-range)# no keepalive
Layer 2 Protocol Tunneling
At this point, our switch should be completely silent. But it's not quite transparent, yet. Going one step further, we can enable layer 2 protocol tunneling (not to be confused with Layer 2 Tunneling Protocol) to enable the pass-through transport of L2 protocols which would normally terminate at the switch.
S1(config)# interface range f0/1 -24 S1(config-if-range)# l2protocol-tunnel S1(config-if-range)# l2protocol-tunnel point-to-point
Our interface configurations should all now look like this:
S1# show running-config interface f0/1 Building configuration... Current configuration : 291 bytes ! interface FastEthernet0/1 switchport mode access switchport nonegotiate no keepalive l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld end
...and now we have a completely silent, transparent switch! In effect, a switching hub.
We can verify that CDP is passed through the switch so that all other connected switches appear to be reachable via a single interface:
S2# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
S3 Fas 0/13 120 S I WS-C3550- Fas 0/13
S4 Fas 0/13 120 S I WS-C3550- Fas 0/13
Posted in Switching
Comments
April 15, 2010 at 4:04 a.m. UTC
I don't understand when this would be useful outside of a testing environment, since it seems like it would cause some problems on a production environment where you would need this. Can someone fill me in on what I'm missing since I know that Jeremy knows his stuff.
April 15, 2010 at 4:14 a.m. UTC
The point of the post was to make a intermediary switch more invisible. Its quite common for SP's to do this to prevent people from snooping what type of hardware they are connecting too.
L2PT is also pretty neat to offer to a customer as they can pass layer 2 info (CDP) across the SP network and see their own device at the other end.
April 15, 2010 at 4:16 a.m. UTC
1) It may be desirable from a service provider's point of view, to provide transparent connectivity through CPE or datacenter gear.
2) It's a great way to screw with coworkers. =)
April 15, 2010 at 5:27 a.m. UTC
You forgot the incredible wisdom in defaulting Catalyst switches to VTP server...also wonderfully evil with its 'VLAN bomb' goodness.
April 15, 2010 at 11:06 a.m. UTC
I really hope never to be a coworker of stretch ;)
April 15, 2010 at 1:53 p.m. UTC
If you're trying to attach a switch to a device that limits MACs, such as a cable model, this would be helpful. For example, my cable modem only allows two devices on it, if I try to plug my switch into it without turning all the crap off I can't put a second device on because the modem sees the noise as a second device.
Sean
April 15, 2010 at 4:29 p.m. UTC
Security is a typical reason to quiet the "noise" of a switch or router. These protocols are great for the network guys, but when you are pen testing you typically recommend shutting this stuff off. I always do, and if there is a debatable reason to leave some of these functions enabled, use CoPP, and only enable cdp on up/downlinks etc.
April 15, 2010 at 6:52 p.m. UTC
Stretch, While setting switchport nonnegotiate on all switch ports is best practice setting a port to access mode also disables DTP so "nonnegotiate" is not totally necessary. On the other hand if the port is set to trunk mode you need to use switchport nonnegotiate to disable DTP. Check it out via a capture. Nick
April 15, 2010 at 7:35 p.m. UTC
Nice stretch but my question is: we can use this when we dont't have HUB and need to have someone?
Thanks
April 16, 2010 at 6:52 a.m. UTC
I think it's better to use wireshark filters.
April 17, 2010 at 3:58 a.m. UTC
@Sean I must thank you. I think you just explained to me why I could never get my cable modem to work across a VLAN to a vm.
April 22, 2010 at 7:40 p.m. UTC
DTP is evil? I'd have guessed we'd say that about VTP.
Other than possibly lengthening the time to bring up a link, and being generally unnecessary, what's so bad about DTP?
VTP operates independently of DTP, right?
June 5, 2010 at 1:01 p.m. UTC
VTP does operate independently of DTP.
DTP is evil - this is because the default state (dynamic desirable) will negotiate a trunk connection with any device plugged in, if able, allowing it access to every vlan.
Hence best practice is to set mode access and noneg.
June 7, 2010 at 8:14 a.m. UTC
Eder: No, the switch will still act as a switch, not a hub. In order for all packets to be flooded to all ports in a VLAN you must also configure the vlan as an rspan-vlan:
vlan 123 remote-span
Jonesnco: Whether it's VTP server or client doesn't matter. If a newly connected VTP client has a higher serial in its local config (and domain and passwords match, of course) then the client will spam this new config out. Yes, clients can update servers in VTP.
May 11, 2011 at 12:29 a.m. UTC
Just as a follow-up to this. I have 2960s, both Lan Lite and Lan Base, (updated to 12.2(55)SE, and neither one seems to support the l2protocol-tunnel functions.
My 3560E and 3750E switches seem to support it fine though.
August 27, 2012 at 6:25 p.m. UTC
So how the CDP packets pass through a switch if the protocol tunneling was not configured? I'm working on a network right now and I see CDP for some Cisco Voice servers showing up on an upstream switch. There are however, CDP packets for other devices that are not being passed... to the upstream switch...