Loops in an STP-enabled network - How?

Question

I've got a question about STP/RSTP (it applies to both, but I'll just say STP). If I connect several switches and the STP algorithm eventually creates a loop-free environment, then how can a single new switch cause a loop?

Let's look at an example scenario: Let's say I have 50 switches, and a user buys a cheap switch without STP (or an attacker turns it off), and connects two ports on the cheap switch to each other (creating a loop). If this cheap switch is then connected to a single port on one of my switches (this port is on Switch 1, and it has PortFast but not BPDU Guard enabled), and the cheap switch starts sending broadcast frames, those broadcast frames enter my switched network, which is a loop-free environment. So how can they cause a loop? The frames must eventually terminate on one of my switches (because STP creates a single logical path for frames), so they can't circle around from the last switch that they reach (Switch 50) to the first switch (Switch 1) through which they initially entered my switched environment.

The only answer I could come up with is that they can't cause a loop, but they can take down the network. They do it in 2 ways:

1. They drown out all traffic, so no other frames can be forwarded, because the rogue, cheap switch's broadcast frames take up all of the available bandwidth.

2. Because the rogue switch's user frames take up all available bandwidth, both all other user frames and the BPDU frames of my switches as well get drowned out. This includes the BPDU Hellos, so eventually the Max Age timer expires, and the switches must recalculate STP. While the STP calculations are going on, all user frames (including the broadcast frames of the rogue, cheap switch) are filtered. While the STP calculation is going on, they still keep trying to enter my switched environment, and after the STP calculation is done, they can do so a second, third, etc. time, taking down the network again.

Or is it the case that the switches' CPUs get so busy, they don't even have an opportunity to keep track of the Max Age timer's expiry? If that's true, then the only answer is 1).

Can someone please help me understand this? Is there actually a way to create a loop in an STP-enabled environment, or is the harm done in the 2 ways I describe?

Have a nice weekend. Attila

Answer 1

a user buys a cheap switch without STP (or an attacker turns it off), and connects two ports on the cheap switch to each other (creating a loop)

This is the bane of any network admin's job. ("The Stupid User"™) This is a situation standard spanning-tree will not detect. Some vendors will detect this as a "self-looped port" -- when the switch receives its own BPDU on the same port. The network will see that BPDU because the unmanaged switch will forward that broadcast frame to every other port. When it's sent on the looped pair, it comes back on the other side, thus appearing as two new received broadcasts that will flooded to every other port. (i.e. the uplink port, as well as the looped pair again.) So the network sent a single broadcast BPDU, and it came back twice.

(It'll actually continuously come back as it keeps crossing the looped ports. This is the "broadcast storm" part of the problem. Most managed switches have some level of storm suppression -- all the way up to turning the port off. Unmanaged switches rarely have any such logic.)

Answer 2

STP bridges can only detect loops by receiving BPDUs. Any switch not participating in STP and not forwarding BPDUs (forwarding them violates IEEE 802.1D/Q) can create loops that go undetected, subsequently causing a broadcast storm and bringing down the network.

BPDU guard doesn't help as no BPDUs enter the switch on the interface facing the loop.

Simply put: for STP/RSTP/MSTP to work correctly, all switches need to participate. Cheap switches that do forward BPDUs (actually violating IEEE standards) can be tolerated, but they might be blocked completely when participating in a loop.

There are other mechanisms that may be able to deal with or at least mitigate remote loops: commonly some proprietary loop detection sends probe frames and when they are received back, the interface is disabled. Broadcast frequency or bandwidth limitation contain a broadcast storm somewhat: the looped broadcasts still drown out desired broadcasts (like ARP) but unicast is only impacted marginally.

If you fear that users connect unauthorized equipment you should consider a) establishing an organizational policy to prohibit that and b) enabling appropriate detection or access methods on the switch, e.g. limit end ports to a single MAC addresses, MAC whitelisting, or 802.1X.