Ethernet Loop : rSTP switch facing dual attachment bridging device

[pascalfr0]

Hi,

We're running  a network with 2 core switches,  and  edge switches with dual attachements to the core (1 giga link toward each core membre).

rSTP is running on all switches interfaces.

core-1 and core 2 have a back-to-back LAG attachment.

One of the core switches is root, the second core switch is the second best choice and appears as the alternate bridge on the edge switches.

Each edge switch has its "root" port forwarding toward core-1 and its "alternate" port toward core-2 in blocking mode.

So far so good, all is running smoothly.

On the edge switches, rSTP is running on every edge interface in 'port fast' mode.

I am wondering what would happen if, by mistake, someone plugged a low-cost switch with no STP  on 2 ports of an edge switch.

=> Will the edge switch detect a loop because the low-cost switch will sent back to him a BPDU that the edge switch originated ?

=> Will the low-coast switch simply drop any BPDU it receives from the Edge switch ... and here we go, ethernet loop and broadcast storm due to double attachment, rSTP on edge switch being of no help in that case ?

I've attached a jpeg (ethloop.jpg) showing the topology, to make my case clear.

[Jon Marshall]

Will the edge switch detect a loop because the low-cost switch will sent back to him a BPDU that the edge switch originated ? 

Yes it should ie. the BPDUs transmitted out of one port by the edge switch would then arrive back on another port on the edge switch.

As soon as the BPDU arrives the port should transition from portfast to a normal port and then RSTP will decide what state that port should be in.

Jon

[Peter Paluch · Accepted solution]

Hello,

=> Will the edge switch detect a loop because the low-cost switch will sent back to him a BPDU that the edge switch originated ?

Yes, if a switch receives a BPDU from itself on a different port, one of the two ports connected together will become Backup Discarding, the other will be Designated Forwarding. However, because the ports on edge switches are running in PortFast mode, the ports will first be unblocked and only then the loop will be discovered. This is in contrast to normal RSTP operation where ports are first blocked, and only after it has been explicitly determined that there is no loop, the ports will become Forwarding. With PortFast ports, there is a tiny window between the ports coming up and then getting blocked, during which a broadcast or multicast storm may develop, and it may be so intensive that the switch will not be able to process its BPDUs anymore.

I should mention that this risk is universally accepted, as it is the best we can do with STP-based networks. Cisco Catalyst switches usually send out a BPDU on a port as soon as the port comes up, even if it is a PortFast port, meaning that the window between port coming up and exchanging BPDUs is rather short. It's not a reliable protection but we can hardly do anything better with STP. Using PortFast in RSTP-based networks is a must, and you just cannot prevent a user from plugging in his/her own switch. You can only detect it's been done afterwards.

=> Will the low-coast switch simply drop any BPDU it receives from the Edge switch ... and here we go, ethernet loop and broadcast storm due to double attachment, rSTP on edge switch being of no help in that case ?

Usually, low-end switches do not drop BPDUs - they flood them just like any multicast frames. However, if the low-end switch truly dropped BPDUs then RSTP would be unable to detect that a switching loop exists, and would not be able to prevent it.

Best regards,
Peter

[pascalfr0]

Thanks, your answer was really helpful and very clear.