Spanning-Tree LoopGuard and UDLD

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


1 Like

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 ?

1 Like

Hi Ray,

This is no problem. Without loop guard, if a non-designated port stops receiving BPDUs then it goes through the listening > learning > forwarding state.

When you enable loop guard then a non-designated port that receives no BPDUs goes into a inconsistent state instead of going through the listening > learning > forwarding state. It does not affect designated ports.


1 Like

I think the statement is misleading in your article about UDLD Aggressive mode

Your article states:
Aggressive is a better solution. When it loses connectivity to a neighbor it will send a UDLD frame 8 times in a second. If the neighbor does not respond the interface will be put in err-disable mode.

However, Cisco Switch Textbook states:
UDLD messages are sent out once a second for 8 seconds.

Or am I missing something?

Hello Ben

Yes you are correct. The statement is verified in the following Cisco documentation.

I will let Rene know to correct it.

Thanks for catching that!


@benjamin.gillies95 Thanks Ben, this is an error indeed. Just fixed it.


Hey Rene, you mentioned that:

“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”

A few question to clarify, correct me if I’m wrong:

  1. Interfaces that are in the ALTERNATE role will not send BPDUs but only receive, so how this rule apply here?

  2. “Both uplink fast and backbone fast are transparent to the loop guard. When max_age is skipped by backbone fast at the time of reconvergence, it does not trigger the loop guard.” Cisco documentation.
    Can you explain please?

Regarding UDLD:

  1. Figured out how UDLD actually works from Cisco documentation, but I can’t understand how UDLD timers work.
    Message interval specifies how often UDLD probes are sent
    Timeout interval specifies how long the entry will remain in the udld cache of the switch.

The thing that I don’t get here is that the ‘message interval’ is 15 secs by default and ‘timeout’ interval is 5 seconds by default. So if the entries are removed after 5 seconds, it means that the switch will get a new probe 10 seconds after the cache was cleared, Why won’t it trigger the echo mechanism?

  1. Cisco in their documentation says that whenever a new neighbor is detected or an out-of-sync message comes in: “,it restarts the detection window on its side of the connection and sends echo messages in reply”.

What is the duration of the detection window?

Hello Inon

Yes you are correct. The statement should more readily read “When a port stops receiving BPDUs, then LoopGuard will place the interface in the loop-inconsistent state and block all traffic” This prevents the port form subsequently transitioning to a designated role and a forwarding state that can potentially create a loop. (I’ll let Rene know).

Essentially what is being said here is that loopguard does not affect the functionality of uplinkfast or backbonefast. In the case of backbonefast, the max_age is disregarded. The max_age is the time the port will wait before going to the forwarding state (without loopguard) or the time the port will wait before going to the loop-inconsistent state (with loopguard). With backbonefast, this max_age timer is set to 0 and loopguard is not enabled at all.

According to Cisco (see documentation below), the default message interval is 15 seconds while the detection time, hold time or timeout interval, whatever you want to call it, is three times that value which is 45 seconds. If three message intervals elapse, only then will the ageing of the cached UDLD information occur.

You can find out more about this at the following Cisco documentation:

I hope this has been helpful!



When an intergace in in blocking sate, does it send bpdus? What if its a real cut on the entire link between sw2 and sw3? IS it going to get into the loop-inconsistent state?


Hello Rafael

During the blocking state, the port will be able to receive BPDUs and process them. However, if there is a disconnection of the entire link, such that the cable is cut or a cable is removed, then the ports on either end will be down completely, so they won’t be in any STP state. STP states exist only on ports that are active, that is, that have an active connection to them.

I hope this has been helpful!



the mac address in the first SW3 config section is wrong for UDLD. Should be 0100.0ccc.cccc. In the next section it is correct.

mac access-list extended UDLD-FILTER
 deny   any host 0100.0ccc.0ccc
 permit any any



Hi Lukas,

You are correct, I just removed it. Thanks!


Hi guys,

How is possible one Designated port linked with an alternate/blocked port work with UDLD, once the alternate port doesn`t send frames? How are the UDLDs frames exchanged between these ports? Is there any implicit policy that permits only UDLD frames and block other else?

Thank you!