Spanning-Tree LoopGuard and UDLD

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 ?

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.


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.gillies 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!

Hello Marcelo

Remember that Alternate/Blocked ports do not send any BPDUs, but they do receive them and can process them. In this case if you get a unidirectional link failure as described in the lesson, the alternate port will stop receiving BPDUs, and will go into the forwarding state as a result.

I hope this has been helpful!


But what about FlexLinks?

Hello Dmitriy

FlexLinks is another method of dealing with L2 loops. You can find out more information about it at this lesson:

I hope this has been helpful!


Hi Rene,

Thanks for the great article. I keep finding conflicting information on UDLD Normal and Aggressive mode and I was hoping you or someone could give me a clear answer.

On this Cisco Community forum:

Peter states that both UDLD operation modes will disable the link. Here is a quote from his post - “So the difference between the normal and aggressive modes relates to the difference in handling an implicit uni-directional link event. If an uni-directional link is detected explicitly, the port will always be err-disabled, regardless of the normal/aggressive mode.” He cites U.S. Patent 6765877 and after briefly skimming it, he appears to be correct.

Then on this Cisco Document:

It lists the error conditions that will cause UDLD in Normal mode to err-disable a port. Does this only relate to Nexus devices? Meaning, UDLD Normal mode operates differently on Catalyst and Nexus devices?

I’m getting more and more confused reading about this topic and I’m hoping someone can clear the air for me.

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 state this (pun intended), it seems to indicate this in this document:

Specifically it says:

If the port does not see its own device/port ID in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional.

This echo-algorithm allows detection of these issues:

  • Link is up on both sides, however, packets are only received by one side.
  • Wiring mistakes when receive and transmit fibers are not connected to the same port on the remote side.

Once the unidirectional link is detected by UDLD, the respective port is disabled and this message is printed on the console:

UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled

Port shutdown by UDLD remains disabled until it is manually reenabled, or until errdisable timeout expires (if configured).

All of the above is regardless of the mode of operation. This corresponds to the explicit method of detection.

In the following section of the same document, it describes implicit detection, which is where the mode of operation kicks in:

Here it states:

UDLD can operate in two modes: normal and aggressive.

In normal mode, if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state.

In aggressive mode, if the link state of the port is determined to be bi-directional and the UDLD information times out while the link on the port is still up, UDLD tries to re-establish the state of the port. If not successful, the port is put into the errdisable state.

Aging of UDLD information happens when the port that runs UDLD does not receive UDLD packets from the neighbor port for duration of hold time. The hold time for the port is dictated by the remote port and depends on the message interval at the remote side. The shorter the message interval, the shorter the hold time and the faster the detection. Recent implementations of UDLD allow configuration of message interval.

The above statement only refers to a case where there is a timeout and UDLD info is not received. This describes the implicit detection, and this is where the mode of operation has meaning.

The documentation does not clearly state that the mode of operation plays no role when explicit detection is observed. However, in the document you shared above (Troubleshoot Uni-Directional Link Detection Errors on Nexus Switches), the examples stated correspond exactly with the patent.

Short of actually performing these tests in a lab, I believe that the Cisco documentation for both IOS and Nexus does agree with the patent, although I do believe that it could have been written more clearly.

I hope this has been helpful!


1 Like

Hello 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 and explicit detection determines the action taken based on UDLD operating mode?


Hi Jonathon

I think the main confusion is the fact that Cisco doesn’t make a clear distinction between explicit and implicit detection, and it doesn’t even use that terminology.

I’ll let Rene know so he can take a look and see if he can modify the content to more clearly describe explicit and implicit detection.

Thanks again!


1 Like

Hello Jonathon,

I saved this for now in my list of content to check/update. I’ll take a look and improve it.


1 Like