If you ever used fiber cables you might have noticed that there is a different connector to transmit and receive traffic.
If one of the cables (transmit or receive) fails we’ll have a unidirectional link failure and this can cause spanning tree loops. There are two protocols that can take care of this problem:
- LoopGuard
- UDLD ( Unidirectional Link Detection )
Let’s start by taking a close look at what will happen if we have a unidirectional link failure:
Imagine the links between the switches are fiber links. In reality there’s a different connector for transmit and receive. SW3 is receiving BPDUs from SW2 and as a result the interface has become an alternate port and is in blocking mode.
Now something goes wrong…the transmit connector on SW2 towards SW3 was eaten by mice failed due to unknown reasons. As a result SW3 is not receiving any BPDUs from SW2 but it can still send traffic to SW2.
Because SW3 is not receiving anymore BPDUs on its alternate port it will go into forwarding mode. We now have a one way loop as indicated by the green arrow.
One of the methods we can use to solve our unidirectional link failure is to configure LoopGuard. When a switch is sending but not receiving BPDUs on the interface, LoopGuard will place the interface in the loop-inconsistent state and block all traffic:
Let’s take a look what this looks like on actual switches. I will use the same topology:
Let’s enable loopguard:
SW1(config)#spanning-tree loopguard default
SW2(config)#spanning-tree loopguard default
SW3(config)#spanning-tree loopguard default
Use the spanning-tree loopguard default command to enable LoopGuard globally. I don’t have any fiber connectors so I’m unable to create a unidirectional link failure. I can simulate it however by using BPDUfilter on SW2’s fa0/16 interface. SW3 won’t receive any BPDUs anymore on its alternate port which will cause it to go into forwarding mode:
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree portfast trunk
SW2(config-if)#spanning-tree bpdufilter enable
Here’s what will happen:
SW3#
*Mar 1 00:17:14.431: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port FastEthernet0/16 on VLAN0001.
Normally this would cause a loop but luckily we have LoopGuard configured. You can see this error message appearing in your console, problem solved!
Configurations
Want to take a look for yourself? Here you will find the final configuration of each device.
SW1
hostname SW1
!
spanning-tree loopguard default
!
end
SW2
hostname SW2
!
spanning-tree loopguard default
!
interface FastEthernet0/16
spanning-tree portfast trunk
spanning-tree bpdufilter enable
!
end
SW3
hostname SW3
!
spanning-tree loopguard default
!
end
If you want you don’t have to configure LoopGuard globally, you can also do it on the interface level like this:
SW3(config-if)#spanning-tree guard loop
The other protocol we can use to deal with unidirectional link failures is called UDLD (UniDirectional Link Detection). This protocol is not part of the spanning tree toolkit but it does help us to prevent loops.
Simply said UDLD is a layer 2 protocol that works like a keepalive mechanism. You send hello messages, you receive them and life is good. As soon as you still send hello messages but don’t receive them anymore you know something is wrong and we’ll block the interface.
Let’s use the same topology but configure UDLD this time. Don’t forget to get rid of loopguard first…
SW1(config)#udld ?
aggressive Enable UDLD protocol in aggressive mode on fiber ports except
where locally configured
enable Enable UDLD protocol on fiber ports except where locally
configured
message Set UDLD message parameters
There are a number of methods how you can configure UDLD. You can do it globally with the udld command but this will only activate UDLD for fiber links!
Hello Rene, I filter the mac address on the cisco side just like what you did, but the port on the cisco and port on the IBM is still on udld neighbor state. When we remove the transmit strands on one of the fiber cable on cisco, both links are down. Is there any connection with the FEFI on this kind of situation?
Thanks a lot Rene.
Hi Thomas,
https://networklessons.com/ip-routing/bidirectional-forwarding-detection-bfd/
You should use it on the blocking (alternate) ports but also on root ports, basically any port that could be in blocking mode if the topology changes. You can enable it globally like I did.
Loopguard works based on BPDUs (L2 information). If a loopguard enabled non-designated interf
Wisam
My sincere apologies, I forgot to add the link. You can find the document here.
Laz
Hello Jonathon
This is an interesting point that you bring up and it has given me (and I hope other readers) an opportunity to dig deeper and appreciate the intricate details that engineers have gone into in order to develop and implement these features.
I’d like to point out that according to Peter’s explanation (and the patent), there are two methods of detecting a unidirectional link: explicitly and implicitly. Explicit detection will result in the disabling of the port regardless of the mode of operation. Although Cisco documentation does not explicitly s
... Continue reading in our forumHello Lazaros,
Thank you for such a detailed and helpful reply! I agree and I’m just assuming the Cisco documentation is worded poorly and should state the method of detection when detecting a unidirectional link - implicit or explicit.
The main confusion for me came from several other resources stating that Normal mode would under no circumstances error disable the link.
However, now we both know that to be incorrect and it depends on whether UDLD implicitly or explicitly detects a unidirectional link.
Will Rene be updating the section to mention how implicit
... Continue reading in our forum