UDLD and Loop Guard on EtherChannels
Thumbnail: logo

UDLD and Loop Guard on EtherChannels


When it comes to L2 resiliency and loop avoidance, it is better to plan ahead and be really careful about the design. Especially when we are using EtherChannel on fiber links between two switches, like this:

switchesLet’s say we are running only VLAN 1 between SW1 and SW2 on PortChannel 1 and SW2 is the root of the STP topology (a very small one actually). Now we may have a faulty rx transceiver on  SW1 Giga 0/1: what happens?

If we have configured UDLD aggressive on every switch interface, after about one second, SW1 stops receiving UDLD and then puts Gi0/1 in err-disable mode. But in the same time a really bad thing could happen: with EtherChannels,  STP instance does not use physical port to build up the topology, but uses the whole PortChannel interface instead. But on which physical port are really exchanged BPDUs if STP sees only one logical port?

STP load balancing hashing algorithm chooses the first operational port to exchange control messages, and therefore in this case will be Gi 0/1. So now we have a bad RX fiber on SW1 and we stop getting BPDUs from the root bridge (SW2) and move the whole PortChannel on VLAN1 into the forwarding state.In case of a dual switch topology, we will neve end up in a loop, but what if we have a third node connected in a ring topology with the other two? If UDLD timers are not lower then STP MaxAge + 2xForwardDelay , we could end up in a network meltdown. So here it comes Loop Guard!

When you enable it on a STP interface (Po1 in our scenario), it will prevent the interface to transition into the forwarding when it stops receiving BPDUs from the root bridge and IOS will tell you something like:

 %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Port-channel1 on VLAN01

So when you have PortChannels and fiber links, best practice is to have both UDLD and Loop Guard enabled.

© 2013-2019 Matteo Malvica. Illustrations by Sergio Kalisiak.