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.


  1. Hi,

    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...
  2. Actually, connecting the switch to itself, i.e. creating an external loopback is sometimes needed in order to perform certain functions not supported by the switch or port in question.

    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.
  3. @Anonymous: You're absolutely right. With "portfast" you'll create a temporary loop until the STP kicks in. Or, if you're absolutely lucky, you have low-end switch that has no STP support :))

    @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.
  4. "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."

    ...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.
  5. How about a another similar question?

    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.
  6. Both Cisco Catalyst 2960 and 3560 have auto sensing.

    Even the 10/100Mbit ports have auto-sensing Gig is not required. The 2950 and 3550 don't have this feature.
  7. And what if you loop the switch on one port? i.e. creating a loop cable, or a more likely situation, connect a cisco switch with spanning tree to an absolute dumb switch, and the dumb switch is got looped (for example in a meeting room)? Does the STP recognize this as a loop? Does it have enough time for this? If the broadcast storm overwhelms the switch, and the switch will be unable to process incoming BPDU-s among the flood?
    Which outcome is likly? (suppose enough initial broadcast / sec, so the storm can start immediatelly)

    Does someone have experience with this?

  8. 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.

  9. A fun way I found in the past to crash a Cisco 3550 switch was to configure a port with an IP addresses, and loop that port back into the same switch on a layer 2 port. It would crash the switch every time, no matter the spanning tree configuration.
  10. This comment has been removed by the author.
Add comment