Spanning-Tree LoopGuard and UDLD

Hello Renne,

Does UDLD will work from cisco 4500 to a 3rd party switch (IBM g8264)

-I configured the cisco 4500 on a normal mode and on the other side, the port is also on the normal mode
-tried to filter the mac address for udld but the port is still operational.

Do you think that when udld is deployed on cisco with a non cisco equipment, will they still use the udld mac address you mentioned or it is cisco proprietary?

Thank you.

Hi Don,

Good question…officially UDLD is a Cisco proprietary standard but there is a RFC for it:

The MAC address should be the same, it’s in the RFC.


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 Don,

It’s possible, some hardware has something like FEFI to detect a link failure so it can take both links down.


Hi. Four questions to help clear my mind when you have a moment.

  1. Is there any benefit to configuring UDLD on links between switches that are copper based?

  2. If configuring loopguard within an environment on what ports is it recommended to be configured on?

  3. Can you elaborate why loopguard doesn’t protect against miswiring?

  4. What are the ramifications of the following - Protection against STP failures because no BPDUs are sent - where you mention that it is not fixed with UDLD, is it then just relying on normal spanning-tree convergence measures (in otherwords a loop would not form)?

Many thanks.


Hi Thomas,

  1. Nope, once something happens on either side…the link will go down. There’s no separate transmit or receive connect with copper links. One topic that is related that you might like is BFD:
  1. 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.

  2. Loopguard works based on BPDUs (L2 information). If a loopguard enabled non-designated interface doesn’t receive BPDUs anymore then the interface will be in a blocking state. Loopguard doesn’t know why or how BPDUs went missing, it just acts upon missing BPDUs. Protocols like UDLD are used as a “keepalive” to ensure that L1 is working (a working physical interface that can transmit and receive).loop-inconsistent blocking state instead of moving through the listening, learning, and forwarding states.

  3. UDLD only helps to have a working link between two switches, that’s it. When something is wrong with the link, UDLD will bring it down. When it does, STP can do its job to create a loop-free topology. It’s also possible that there is no loop in the topology anymore one one of the physical links fails.


Thank you for the detailed replies Rene. One thing I am a little stuck on - for item #2, why in the example do we need to enable loop guard globally on switch A, the root switch which only has designated ports? I guess it doesn’t hurt anything, but please confirm it is not really technically needed?

Hi Thomas,

No problem. Technically, we would only have to enable it on the switches that have blocked ports, you could skip Switch A. Just in case, it’s not a bad idea to enable it globally on all switches with fiber links (in case another switch becomes root or if port roles change).


Cisco does encourage the use of UDLD and loop guard together (because each has gaps the other protects against).

Additionally, loop guard does not work on shared links or in situations where the link has been unidirectional since the link-up. In the last case, the port never receives BPDU and becomes designated. Because this behaviour could be normal, this particular case is not covered by loop guard. UDLD provides protection against such a scenario.
As described, the highest level of protection is provided when you enable UDLD and loop guard.

This is about 2/3 of the way down this page:

Hello Rene, my confusion regarding Loopguard, is when a switch is not receiving bpdus anymore on a alternate/blocking port. I understand that a blocking port does not receive bpdu until moves to forwarding state.

Can you please clarify this statement:" switch C is not receiving anymore bpdus in its alternate port" scnd paragraph below third picture.

Hi Rene,

" When a switch is sending but not receiving BPDUs on the interface "

Correct me if i am wrong, DP on root bridge only send BPDUs but seldom receive BPDUs -
if we configure loopguard on the root bridge, by the theory above - won’t all DPs on root bridge become inconsistent ?


You are correct. Cisco recommends that loopguard not be enabled on Designated Ports. Root Bridges, by definition, have nothing but DPs. Therefore, loopguard should not be enabled on it.

Specifically, Cisco says:
Loop guard must be enabled on the non-designated ports (more precisely, on root and alternate ports) for all possible combinations of active topologies


19 posts were merged into an existing topic: Spanning-Tree LoopGuard and UDLD

Hello Rene,
Could you please let me know your suggestion (your recommendation steps) on what to look for to troubleshoot the UDLD when the port goes into Err-disable mode.
I have a fiber link that always goes in error disable mode (UDLD) and it works fine when I enabled it for about a 4 hours and then goes in err-disable mode again?
Thanks in advance.

Hello Wisam

Take a look at this very comprehensive Cisco documentation that describes troubleshooting UDLD. Although it is for Nexus switches, the logic is the same concerning IOS devices as well. Take a look, try to apply the troubleshooting principles to your situation and let us know what the results are so that we can help you out in more detail.

In general, such problems are at the physical layer, so changing patch cords, SFP modules or even ports on either end are good tests to determine where the problem exists.

Let us know your results and we’ll talk again!

I hope this has been helpful.


Hello Lagapides,
Thanks for your reply, but I am unable to see the document.


My sincere apologies, I forgot to add the link. You can find the document here.


If a port is in blocking state, it doesn’t forward traffic however, is it still forwarding BPDU packets ?

Hi Ray,

A blocked port will not forward any BPDUs, it’s only listening for them.

One exception is if you use bridge assurance:

Hope this helps!


So one switch with the interface connecting to another switch via an interface that’s in blocking never receives BPDU ??

If we have loopguard enabled on such interface wt would happen ? As such port is sending BPDU but never recieves BPDU ?