Below is the diagram of 4 switches, there is STP running on the each of the switches and everything is working fine. Let's say if there is problem (one way traffic) between switch1 and switch3 within PTT cloud (MAN link connection), but the interface for both switchs still remin 'up up' status, How to explain the STP loop for this scenario?
switch1 ---- switch2
switch3 ---- switch4
The diagram is messed up, the 4 switches are ring connection, PTT link a connects between switch 1 and 3, PTT link b connects between switch2 and 4. Now link a has problem with PTT cloud, but couldn't observe from interface status.
what you describe (one way traffic only, send or receive channel down) can indeed cause spanning tree loops and traffic being blackholed, due to unidirectional links. There is a feature called ´UDLD´ (Unidirectional Link Detection) that detects breaks in one side of the cable run, and subsequentially shuts down the interface.
Configuring UDLD is somewhat different for fiber optic and copper cables: if your switches are connected through fiber-optic cables, use the following interface command on the connecting fiber ports:
For copper interfaces, use this command:
udld port aggressive
You also might want to have a look at this document:
The interface will remain up when it is in blocking mode for spanningtree.
Use the command: sh spanning-tree int .. to detect the spanning tree state.
Unidirectional links are a known threat for spanning tree stability. Activating the Unidirectinal link detection on the MAN-interfaces may give some relief:
the reason, why a unidirectional link can cause a STP loop is as follows.
Let us say switch1 is root, all ports forwarding. Now let us assume switch3 does not get any BPDUs from switch1 because of UDL. The port will still be forwarding (no BPDU could mean only hosts attached). But because switch3 needs a new root port, the other port connected to switch4 will be forwarding too.
So a broadcast frame received from switch4 will be forwarded to switch1 and again forwarded towards switch2 and on to switch4.
And there is your loop.
To overcome this situation use UDLD as advised by the other two posts.
Hope this helps
Thanks for your reply.
Let's say the root bridge is switch b, and the blocking port is switch b's port connects to switch d, and now the unidirectional link occurred between switch a and switch c, how to explain the STP loop in this case?
I just would like to confirm the STP loop on the unidirectional loop only occurred when one of the unidirectional link's port is blocking port.
the ports of a root bridge will not be blocking. So your example can not occur.
The UDL is causing the problem because two switches see a different topology. In my example the port to the root bridge (NON blocking) had the UDL condition.
Hope this helps
Sorry, didn't make my point clear. please refer the following example:
Switch A ------------- Switch B ---- Other switches
Now, switch B's port is blocking port, and the link between A and B is unidirectional link, Switch A can send traffic to switch B but couldn't receive traffic from Switch B, for Switch B, can receive and send traffic to Switch A, in this case, will Switch B's port keep in blocking status as it can receive traffic from Switch A although Switch A lost BPDUs from Switch B already? any STP loop will occur?
as long as there are no redundant links no loop will occur. In case you have redundant links you will find a way to get a loop when an UDL is in place.
Hope this helps
I guess your question is: can a loop occur if the unidirectional link is not the link that ought to block the port. The answer is yes. Any failure upstream the port that should block would have the same catastrophic effect because this port would not hear from the root and would thus be unable to block. A port can only block if it continuously receive BPDUs.
On the top of UDLD, two additional features were designed to help this scenario:
-1- loopguard. This feature will prevent the loop if the unidirectional link failure occurs during normal operation (i.e. the port was receiving BPDUs, and suddendtly the failure occurs and prevent it from receiving BPDUs any more). It will not prevent the loop if the problem existed at link up.
-2- the dispute mechanism. This is a very clever mechanism that has been introduced in 802.1D-2004 (and now in 802.1Q-2005 for MST). It is very efficient but only works for RSTP and MST. The idea is that the new BPDU format include the role of the ports. Two ports cannot be designated for the same segment. If a designated port detects another port who pretend to be designated on the segment, it knows there is a unidirectional link failure and blocks in order to prevent any loop (the designated port knows the peer has a problem because it pretends to be designated while having inferior information, this means that the peer does not receive the designated information).
Hope this helps!