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 finish the overview, recall 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 (by default it’s 20+2×15 seconds, though who uses the classic STP with defaults nowdays?)