Connecting a switch to itself: does it hurt?
I’ve got an unusual question a few days ago:
Does a loop (cable returning back to same switch) in one switch affect other switches? How can I detect that there is such a problem in a particular switch?
The correct answer to the first question is obviously it depends. To start with, it depends on whether the two ports will be able to communicate. With a crossover (switch-to-switch) cable (and assuming there are no negotiation issues), the physical layer will work correctly. If you’re using a standard RJ-45 patch cable, you’re “out of luck” unless the switch is too smart and has auto-MDI sensing (like the Linksys switches, now well hidden under obscure part numbers like Cisco SRW248G4). In this case, the two ports will become active even connected with a patch cable.
What happens next depends on how smartly you’ve configured the ports. If you haven’t touched the default configuration, the spanning tree (STP) will discover a loop and disable one of the ports. You can identify a disabled port(s) with the show spanning-tree commands.
If you’ve configured spanning-tree portfast on a port but forgot to configure BDPU guard (or maybe you have an older switch or a low-end router with a switch module that does not support BPDU guard), you’ve just created a nice temporary loop in your bridged network. If you want something more permanent, use BPDU filter or a low-end switch that does not support STP
I’ve seen interesting network meltdowns following a layer-2 loop. Broadcasts or multicasts are most likely to be looped, so they will affect the whole network, including all connected workstations.
This article is part of You've asked for it series.
Even if BPDU guard wasn't configured, a loop won't be created. configuring portfast doen't disable spanning-tree completely on the port.
configuring bpdu-filter, on the other hand, will create a loop...
One of the common reasons is VLAN translation and the other one, slightly more obscure, is ability to create MPLS EoMPLS pseudowires on 6500/7600 series, while using "hybrid" L2/L3 environment.
@Marko: There's another use for external loopback - you want to create a single switch out of two switching modules on low-end Cisco routers.
you’re “out of luck” unless the switch is too
smart and has auto-MDI sensing."
...or if you're using a gigabit switch with copper ports.
The terms "MDI" and "crossover" are obsolete with gigabit copper, because there no longer exist discrete pairs for transmit and receive.
Connecting a router to itself?
We used it on our catalyst 6500 in order to put the packet shaping device "inline". We also used it to have vrf-lite communicate between the VRF and global routing table on the same device. Some mac-address and static arp entry have to be entered in order for them to communicate. In the CISCO network virtualization, if the FWSM in transparent mode, and you want to have routing between different VLANs in different VRF, you also need to add the mac-address and static arp entry.
Even the 10/100Mbit ports have auto-sensing Gig is not required. The 2950 and 3550 don't have this feature.
Which outcome is likly? (suppose enough initial broadcast / sec, so the storm can start immediatelly)
Does someone have experience with this?
Balazs
I've seen your scenario more than once where. A hub in a conference room connected to two switch ports will create a loop.
I've also seen a buggy virtual switch in a virtual host do it. Servers hosting VMs need multiple switch ports for redundancy and run simple virtual switches in them that don't do spanning tree. They also have bugs.
Broadcast and multicast gets looped first. On top of that, the CAM tables get flooded: from the perspective of your cisco switch, every broadcast now originates from the correct port, as well as the looped ports, so the looped ports keep accumulating MACs. As a result, even unicast traffic starts to get looped.
If you have BPDU guard, it will eventually kick in and the network will recover.
Few pointers:
- bpdu-guard is a must
- you don't want "errdisable recovery cause bpduguard", since it'll restart the cycle
- consider port-security with a small limit (we do 4 MACs). this prevents the second part of the problem, where the CAM table gets flooded, and it's a fail-safe to the bpdu-guard.
Igor.