Hello, I came across a strange behavior for which I am not certain that it is as expected.
When connecting a Mikrotik switch with bridged interfaces and enabled RSTP on the bridge to a switch that is not running RSTP (or any other loop protection) using two cables the loop that is created does not get detected and traffic gets looped. I tested this scenario with Mikrotik switch which has enabled RSTP connected to another Mikrotik without RSTP as well as to a different vendor.
The same issue occurs when connection a ring of several switches and one of them does not have RSTP enabled - so 10 RSTP switches and 1 non-RSTP switch cause a looped network,
Mikrotik switches are running RouterOS v7.18.2.
From my understanding of the RSTP protocol, if a switch receives his own BPDU it should disable (put as backup port) one of the ports that are in the loop. Would you agree or is this behavior that I am seeing expected?
I also tested the same scenario with a Cisco switch and it did in fact put one of the ports as backup and I had a stable network.
Yes, if a switch sees a BPDU either from itself or another switch that will be used in the topology calculations to determine which path(s) should be blocked.
It depends on how the switch which does not support RSTP handles BPDUs. Devices send BPDUs to the STP multicast MAC address 01:80:C2:00:00:00, this is one of the IEEE 802.1D “MAC Bridge Filtered MAC Group Addresses” so compliant switches should never forward BPDUs between interfaces. As a result you end up with two branches which spanning tree doesn’t see as connected, but are. This is why various vendors developed proprietary loop detection protocols.
The same issue occurs when connection a ring of several switches and one of them does not have RSTP enabled - so 10 RSTP switches and 1 non-RSTP switch cause a looped network,
indeed, layer 2 design can be confusing.
ring topology is not the same thing as lacp pagp mechanism. regardless which stp you are using.
so you should define your back to back links to their appropriate working mechanism.
Well if the non-RSTP switch is smart enough to follow the standard and not propagate the BPDUS onto its other ports the RSTP-enabled switch will never realize that there is a loop and hence no port will be blocked and the loop will occur. Do you know if this switch forwards the BPDUs?
If it doesn’t forward them then that’s why the loop occurs
if it does forward them (for example a mikrotik switch with protocol=none in the bridge settings forwards these frames) then there’s the following consideration: a root bridge’s (your RSTP-enabled switch is the root bridge because it is the only *STP enabled device in the Layer 2 domain) ports are all designated and forwarding. Receiving a superior bpdu will trigger the rstp process all over, a root port will be elected etc. If the bpdu is not superior then it will be discarded and the switch will continue as the root bridge with all ports designated (root bridges dont have . Now the question is what would happen if the bpdu arriving is one originating from the same switch which is the case here: I cant find any authoritative source that specifies a special handling for such a case so I guess the bpdu would just be discarded/unaccounted for (it would make no sense to trigger rstp process) and the loop would go on to exist. That’s why you re experiencing a loop even though the bpdu arrives back. I know for sure that in routeros 6 (not sure about 7) packets with the same src mac address arriving at the switch trigger a warning log message about a potential loop but it is a simple waning and no action is taken unless configured. The loop protect mechanism in routeros would save you in such cases.
Now as for Cisco actually working as intended it’s probably because *STP is enabled there by default so you actually have two switches running STP so they can tell whats going on. I’m looking forward to answers from people with greater experience especially concerning the part of handling identical looped bpdus.
Recent routeros in the bridge stp setting, has an option when STP is set to none to forward reserved.
In which case the bpdu’s appear to pass through transparently.
I think I remember they used to pass through in old versions of routeros.
