UDLD (Unidirectional Link Detection) is Cisco proprietary extension for detecting a mis-configured link. The idea behind it is pretty strighforward – allow two switches to verify if they can both send and receive data on a point-to-point connection. Consider a network with two switches, A and B connected by two links: “A=B”. Naturally, if “A” is the root of spanning tree, one of the ports on “B” will be blocking, constantly receiving BPDUs from “A”. If this link would turn uni-directional and “B” would start missing those BPDUs, the port will eventually unblock, forming a loop betwen “A” and “B”. Note that the problem with unidirectional links usually occurs on fiber-optical connections and is not common on UTP (wired) connections, where link pulses are used to monitor the connection integrity.

The confusion about UDLD is that Cisco provides quite unclear description of the feature operations be it on CatOS or IOS platform. So here is a short overview of how UDLD works.

1) Both UDLD peers (switches) discover each other by exchanging special frames sent to well-known MAC address 01:00:0C:CC:CC:CC. (Naturally, those frames are only understood by Cisco switches). Each switch sends it’s own device ID along with the originator port ID and timeout value to it’s peer. Additionally, a switch echoes back the ID of it’s neighbor (if the switch does see the neighbor). Since some versions of CatOS and IOS you can change UDLD timers globally.

2) If no echo frame with our ID has been seen from the peer for a certain amount of time, the port is suspected to be unidirectional. What happens next depends on UDLD mode of operations.

3) In “Normal” mode, if the physical state of port (as reported by Layer 1) is still up, UDLD marks this port as “Undetermined”, but does NOT shut down or disable the port, which continues to operate under it’s current STP status. This mode of operations is informational and potentially less disruptive (though it does not prevent STP loops). You can review the “undetermined” ports using CLI show commands when troubleshooting the STP issues though.

3) If UDLD is set to “Agressive” mode, once the switch loses it’s neighbor it actively tries to re-establish the relationship by sending a UDLD frame 8 times every 1 second (surpisingly this coincides with TCP keepalives retry values used by FCIP on Cisco MDS storage switches . If the neighbor does not respond after that, port is considered to be unidirectional and brought to “Errdisable” state. (Note that you can configure “errdisable recovery” to make switch automatically recover from such issues)

4) UDLD “Aggressive” will only brings link to errdisable state when it detects “Bidirectional” to “Unidirectional” state transition. In order for a link to become “Bidirectional”, UDLD process should first hear an echo packet with it’s own ID from a peer on the other side. This prevents link from becoming errdisabled when you configure “Aggressive” mode just on one side. The UDLD state of such link will be “Unknown”.

5) UDLD “Aggressive” inteoperates with UDLD “Normal” on the other side of a link. This type of configuration means that just one side of the link will be errdisabled once “Unidirectional” condition has been detected.

To complete this overview, remember that UDLD is designed to be a helper for STP. Therefore, UDLD should be able to detect an unidirectional link before STP would unblock the port due to missed BPDUs. Thus, when you configure UDLD timers, make sure your values are set so that unidirectional link is detected before “STP MaxAge + 2xForwardDelay” expires. Additionally, notice that UDLD function is similar to STP Loopguard and Bridge Assurance feature found in newer switches. The benefit of UDLD is that it operates at physical port-level, whereas STP may not be able to detect a malfunctioning link bundled in an Etherchannel. This is why you normally use all features together – they don’t replace but truly complement each other.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

15 Responses to “UDLD Modes of Operation”

[...] I knew enough about UDLD. Petr Lapukhov from Internetwork Expert writes a good explanation about UDLD Modes of Operation. From this writing I found out that udld aggressive is not enabled by [...]

Indeed. So can we accept Cisco’s “best practice” recommendation to implement UDLD Aggressive Mode between point-to-point switch links if we’re running RPVST+ or MST? I confess to having been a bit mystified by Cisco’s documentation of this feature from day one and this only adds to the confusion:

“Most recently, fiber FastEthernet hardware implementations have Far End Fault Indication (FEFI) functions in order to bring the link down on both sides in these situations. On Gigabit Ethernet, a similar function is provided by link negotiation. Copper ports are normally not susceptible to this type of issue, as they use Ethernet link pulses to monitor the link. It is important to mention that in both cases, no forwarding loop occurs because there is no connectivity between the ports. If the link is up on one side and down on the other, however, blackholing of traffic might occur. Aggressive UDLD is designed to prevent this.

At least in my opinion biggest problem with UDLD is it’s inability to recover from fault state. Sure, it disables port in aggressive mode and errdisable recovery re-enables port after configured delay. However recovery is done blindly without checking if UDLD partner has actually come back or not. Port is simply enabled and no further UDLD processing is done on that port until partner has returned and port has changed to bidirectional mode at least once. After that if new fault has occurred it will take port down as expected. For this reason UDLD is fine when not using errdisable recovery or running it in non-aggressive mode. Which also means you’re prepared to always manually fix problem and have off-band management access to all of your network equipment. For automated operations UDLD offers no help making it completely useless for many setups where such monitoring would be needed (dumb fiber transceivers, EoMPLS etc). Based on comments where people claim they use UDLD successfully makes me believe they have never actually tested different fault scenarios and simply assume it will function properly when needed.

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.

I know this post is old but just to clarify, one of the big problems with unidirectional links is the fact that STP loops can form becuase the switch stops receiving BPDUs. If you only have one link to the site in question to begin with, then you aren’t gaining ‘much’ by turning it on anyway. If you do have multiple links that get shut down due to udld, then you have bigger problems.

Please correct me if this is wrong , UDLD “normal mode” will error disable a link if an “Empty Echo” is received .

I had this situation , I enabled normal udld and still some ports get disabled because of the UDLD , I did some research and found that UDLD normal mode can disable the port in case of receiving Empty Echo .

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 link is up and BPDUs Frames is sending but not receiving in this case UDLT detect from bi-directional link to undirectional link and will send 8 times echo message in every one second after not receiving any message from Remote then it will shut it’s port after that you have to reenble port through mannually

Leave a Reply

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.