Skip to main content

Cisco Systems UniDirectional Link Detection (UDLD) Protocol

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5171.
Author Marco Foschiano
Last updated 2018-12-20 (Latest revision 2007-04-09)
RFC stream Independent Submission
Intended RFC status Informational
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 5171 (Informational)
Action Holders
Telechat date (None)
Responsible AD Russ Housley
Send notices to (None)
Internet Engineering Task Force                            M. Foschiano 
Internet Draft                                            Cisco Systems 
Category: Informational                                      April 2007 
Expires: October 2007                                                   
        Cisco Systems UniDirectional Link Detection (UDLD) Protocol 
Status of this Memo 
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
   The list of current Internet-Drafts can be accessed at 
   The list of Internet-Draft Shadow Directories can be accessed at 
Copyright Notice 
   Copyright (C) The IETF Trust (2007). 

Foschiano                                                     [Page 1] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   This document describes a Cisco Systems protocol that can be used to 
   detect and disable unidirectional Ethernet fiber or copper links 
   caused for instance by mis-wiring of fiber strands, interface 
   malfunctions, media converters' faults, etc.  It operates at Layer 2 
   in conjunction with IEEE 802.3's existing Layer 1 fault detection 
   This document explains the protocol objectives and applications, 
   illustrates the specific premises the protocol was based upon and 
   describes the protocol architecture and related deployment issues, to 
   serve as a possible base for future standardization. 
Table of Contents 
   1. Introduction..................................................3 
   2. Protocol Objectives and Applications..........................3 
   3. Protocol Design Premises......................................4 
   4. Protocol Background...........................................5 
   5. Protocol Architecture.........................................5 
      5.1 The Basics................................................5 
      5.2 Neighbor Database Maintenance.............................5 
      5.3 Event-driven Detection and Echoing........................6 
      5.4 Event-based versus Event-less Detection...................6 
   6. Packet Format.................................................7 
      6.1 TLV Description...........................................9 
   7. Protocol Logic...............................................10 
      7.1 Protocol Timers..........................................11 
   8. Comparison with Bidirectional Forwarding Detection...........11 
   Security Considerations.........................................12 
   IANA Considerations.............................................12 
   Deployment Considerations.......................................12 
   Changes from the Previous Version...............................12 
   Normative References............................................12 
   Author's Address................................................13 
   IPR Notice......................................................13 
   Full Copyright Notice...........................................14 

Foschiano                                                     [Page 2] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
1. Introduction 
   Today's Ethernet-based switched networks often rely on the Spanning 
   Tree Protocol (STP) defined in the IEEE 802.1D standard [1] to create 
   a loop-free topology that is used to forward the traffic from a 
   source to a destination based on the Layer 2 packet information 
   learned by the switches and on the knowledge of the status of the 
   physical links along the path. 
   Issues arise when due to mis-wirings or to hardware faults the 
   communication path behaves abnormally and generates forwarding 
   anomalies. The simplest example of such anomalies is the case of a 
   bidirectional link that stops passing traffic in one direction and 
   therefore breaks one of the most basic assumptions most high-level 
   protocols depend upon: reliable two-way communication between peers. 
   The purpose of the UDLD protocol is to detect the presence of 
   anomalous conditions in the Layer 2 communication channel, while 
   relying on the mechanisms defined by the IEEE in the 802.3 standard 
   [2] to properly handle conditions inherent to the physical layer. 
2. Protocol Objectives and Applications 
   The UniDirectional Link Detection protocol (often referred to in 
   short as "UDLD") is a light-weight protocol that can be used to 
   detect and disable one-way connections before they create dangerous 
   situations such as Spanning Tree loops or other protocol 
   The protocol's main goal is to advertise the identities of all the 
   capable devices attached to the same LAN segment and to collect the 
   information received on the ports of each device to determine if the 
   Layer 2 communication is happening in the appropriate fashion. 
   In a network that has an extensive fiber cabling plant, problems may 
   arise when incorrect patching causes a switch port to have its RX 
   fiber strand connected to one neighbor port and its TX fiber strand 
   connected to another. In these cases, a port may be deemed active if 
   it is receiving an optical signal on its RX strand. However, the 
   problem is that this link does not provide a valid communication path 
   at Layer 2 (and above). 
   If this scenario of wrongly connected fiber strands is applied to 
   multiple ports to create a fiber loop, each device in the loop could 
   directly send packets to a neighbor but would not be able to receive 
   from the same device to which it is sending to. 

Foschiano                                                     [Page 3] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   Albeit the above scenario is rather extreme, it exemplifies how the 
   lack of mutual identification of the neighbors can bring protocols to 
   the wrong assumption that during a transmission the sender and the 
   receiver at the other end of the link match. 
   Another equally dangerous incorrect assumption is that the lack of 
   reception of protocol messages on a port unmistakably indicates the 
   absence of transmitting protocol entities at the other end of the 
   The UDLD protocol was implemented to help correct certain assumptions 
   made by other protocols, and in particular to help the Spanning Tree 
   Protocol to function properly so as to avoid the creation of 
   dangerous Layer 2 loops. It has been available on most Cisco Systems 
   switches for several years and is now part of numerous network design 
   best practices. 
3. Protocol Design Premises 
   The current implementation of UDLD is based on the following 
     o  The protocol would have to be run in the control plane of a 
        network device to be flexible enough to support upgrades and bug 
        fixes. The control plane speed would ultimately be the limiting 
        factor to the capability of fast fault detection of the protocol 
        (CPU speed, task switching speed, event processing speed, etc.). 
        The transmission medium's propagation delay at 10 Mbps speed (or 
        higher) would instead be considered a negligible factor. 
     o  Oftentimes network events tend to happen not with optimal 
        timing, but rather at the speed determined by the 
        software/firmware infrastructure that controls them (for 
        psychological and practical reasons developers tend to choose 
        round timer values rather than determine the optimal value for 
        the specific software architecture in use; also, software bugs, 
        coding oversights, slow process switching, implementation 
        overhead can all affect the control plane responsiveness and 
        event timings). Hence it was deemed necessary to adopt a 
        conservative protocol design to minimize false positives during 
        the detection process. 
     o  If a fault were discovered, it was assumed that the user would 
        want to keep the faulty port down for a predetermined amount of 
        time to avoid unnecessary port state flapping. For that reason a 
        time-based fault recovery mechanism was provided (although 
        alternative recovery mechanisms are not implicitly precluded by 
        the protocol itself). 

Foschiano                                                     [Page 4] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
4. Protocol Background 
   UDLD is meant to be a Layer 2 detection protocol that works on top of 
   the existing Layer 1 detection mechanisms defined by the IEEE 
   standards. For example, the Far End Fault Indication function (FEFI) 
   for 100BaseFX interfaces and the Auto-Negotiation function for 
   100BaseTX/1000BaseX interfaces represent standard physical-layer 
   mechanisms to determine if the transmission media is bidirectional. 
   (Please see [2] sections and for more details.) The 
   typical case of a Layer 1 "fault" indication is the "loss of light" 
   UDLD instead differs from the above-mentioned mechanisms insofar as 
   it performs mutual neighbor identification; in addition it performs 
   neighbor acknowledgement on top of the LLC layer and thus is able to 
   discover logical one-way mis-communication between neighbors even 
   when either one of the said PHY layer mechanisms has deemed the 
   transmission medium bidirectional.  
5. Protocol Architecture 
5.1 The Basics 
   UDLD uses two basic mechanisms: 
     a. It advertises a port's identity and learns about its neighbors 
        on a specific LAN segment; it keeps the acquired information on 
        the neighbors in a cache table. 
     b. It sends a train of echo messages in certain circumstances that 
        require fast notifications or fast resynchronization of the 
        cached information. 
   Because of the above, the algorithm run by UDLD requires that all the 
   devices connected to the same LAN segment be running the protocol in 
   order for a potential misconfiguration to be detected and for a 
   prompt corrective action to be taken. 
5.2 Neighbor Database Maintenance 
   UDLD sends periodical "hello" packets (also called "advertisements" 
   or "probes") on every active interface to keep each device informed 
   about its neighbors. When a hello message is received, it is cached 
   and kept in memory at most for a defined time interval, called 
   "holdtime" or "time-to-live", after which the cache entry is 
   considered stale and is aged out. 

Foschiano                                                     [Page 5] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   If a new hello message is received when a correspondent old cache 
   entry has not been aged out yet, then the old entry is dropped and is 
   replaced by the new one with a reset time-to-live timer. 
   Whenever an interface gets disabled and UDLD is running, or whenever 
   UDLD is disabled on an interface, or whenever the device is reset, 
   all existing cache entries for the interfaces affected by the 
   configuration change are cleared and UDLD sends at least one message 
   to inform the neighbors to flush the part of their caches also 
   affected by the status change. This mechanism is meant to keep the 
   caches coherent on all the connected devices. 
5.3 Event-driven Detection and Echoing 
   The echoing mechanism is the base of UDLD's detection algorithm: 
   whenever a UDLD device learns about a new neighbor or receives a 
   resynchronization request from an out-of-synch neighbor, it 
   (re)starts the detection process on its side of the connection and 
   sends N echo messages in reply. (This mechanism implicitly assumes 
   that N packets are sufficient to get through a link and reach the 
   other end, even though some of them might get dropped during the 
   Since this behavior must be the same on all the neighbors, the sender 
   of the echoes expects to receive after some time an echo in reply. If 
   the detection process ends without the proper echo information being 
   received, under specific conditions the link is considered to be 
5.4 Event-based versus Event-less Detection 
   UDLD can function in two modes: normal mode and aggressive mode. 
   In normal mode a protocol determination at the end of the detection 
   process is always based on information received in UDLD messages: 
   whether it's the information about the exchange of proper neighbor 
   identifications or the information about the absence of such proper 
   identifications. Hence, albeit bound by a timer, normal mode 
   determinations are always based on gleaned information, and as such 
   are "event-based". If no such information can be obtained (e.g., 
   because of a bidirectional loss of connectivity), UDLD follows a 
   conservative approach based on the considerations in Section 3 and 
   deems a port to be in "undetermined" state. In other words, normal 
   mode will shut down a port only if it can explicitly determine that 
   the associated link is faulty for an extended period of time. 

Foschiano                                                     [Page 6] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   In aggressive mode, instead, UDLD will shut down a port also in case 
   it just loses bidirectional connectivity with the neighbor for the 
   same extended period of time mentioned above and subsequently fails 
   repeated last-resort attempts to re-establish communication with the 
   other end of the link. This mode of operation assumes that loss of 
   communication with the neighbor is a meaningful network event in 
   itself and is a symptom of a serious connectivity problem. Because 
   this type of detection can be event-less, and lack of information 
   cannot always be associated to an actual malfunction of the link, 
   this mode is optional and is recommended only in certain scenarios 
   (typically only on point-to-point links where no communication 
   failure between two neighbors is admissible). 
6. Packet Format 
   The UDLD protocol runs on top of the LLC sub-layer of the data link 
   layer of the OSI stack. It uses a specially assigned multicast 
   destination MAC address and encapsulates its messages using the 
   standard SNAP format as described in the following: 
         Destination MAC address            01-00-0C-CC-CC-CC 
         UDLD SNAP format:                   
           LLC value                        0xAAAA03 
           Org Id                           0x00000C 
           HDLC protocol type               0x0111 
   UDLD's Protocol Data Unit (PDU) format is as follows: 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   | Ver | Opcode  |     Flags     |           Checksum            | 
   |               List of TLVs (variable length list)             | 
   |                              ...                              | 

Foschiano                                                     [Page 7] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   The TLV format is the basic one described below: 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   |             TYPE              |            LENGTH             | 
   |                             VALUE                             | 
   |                              ...                              | 
   Type (16 bits): If an implementation does not understand a Type value 
   it should skip over it using the length field. 
   Length (16 bits): Length in bytes of the Type, Length, and Value 
   fields. In order for this field value to be valid, it should be 
   greater than or equal to the minimum allowed length, 4 bytes; if not, 
   the whole packet is to be considered corrupted and therefore it must 
   be discarded right away during the parsing process. TLVs should not 
   be split across packet boundaries. 
   Value (variable length): Object contained in the TLV. 
   The protocol header fields are defined as follows: 
   Ver (3 bits): 
         0x01: UDLD PDU version number 
   Opcode (5 bits):  
         0x00: Reserved 
         0x01: Probe message 
         0x02: Echo message 
         0x03: Flush message 
         0x04-0x1F: Reserved for future use 
   Flags (8 bits): 
         bit 0: Recommended timeout flag (RT) 
         bit 1: ReSynch flag (RSY) 
         bit 2...7: Reserved for future use 
   PDU Checksum (16 bits): 
         IP-like checksum. Take the 1's complement of the 1's complement 
   sum (with the modification that the odd byte at the end of an odd 
   length message is used as the low 8 bits of an extra word, rather 
   than as the high 8 bits.) N.B.: All UDLD implementations must comply 
   with this specification. 
Foschiano                                                     [Page 8] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   The list of currently defined TLVs comprises: 
     Name                   Type      Value format                       
     Device-ID TLV          0x0001    ASCII character string             
     Port-ID TLV            0x0002    ASCII character string             
     Echo TLV               0x0003    List of ID pairs                   
     Message Interval TLV   0x0004    8 bit unsigned integer             
     Timeout Interval TLV   0x0005    8 bit unsigned integer             
     Device Name TLV        0x0006    ASCII character string             
     Sequence Number TLV    0x0007    32 bit unsigned integer            
     Reserved TLVs          > 0x0007  Format unknown.                    
                                      To be skipped by parsing routine. 
6.1 TLV Description 
   Device-ID TLV: 
     This TLV uniquely identifies the device that is sending the UDLD 
     packet. The TLV length field determines the length of the carried 
     identifier and must be greater than zero. In version 1 of the 
     protocol the lack of this ID is considered a symptom of packet 
     corruption that implies that the message is invalid and must be 
   Port-ID TLV: 
     This TLV uniquely identifies the physical port the UDLD packet is 
     sent on. The TLV length field determines the length of the carried 
     identifier and must be greater than zero. In version 1 of the 
     protocol the lack of this ID is considered a symptom of packet 
     corruption that implies that the message is invalid and must be 
   Echo TLV: 
     This TLV contains the list of valid DeviceID/PortID pairs received 
     by a port from all its neighbors. If either one of the identifiers 
     in a pair is corrupted the message will be ignored. 
     This list includes only DeviceID's and PortID's extracted from UDLD 
     messages received and cached on the same interface on which this 
     TLV is sent. If no UDLD messages are received, then this TLV is 
     sent containing zero pairs. Despite its name, this TLV must be 
     present in both probe and echo messages, whereas in flush messages 
     it's not required. 
Foschiano                                                     [Page 9] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
   Message Interval TLV: 
     This required TLV contains the 8-bit time interval value used by a 
     neighbor to send UDLD probes after the linkup or detection phases. 
     Its time unit is 1 second. The holdtime of a cache item for a 
     received message is calculated as (advertised-message-interval x 
     R), where R is a constant called "Ttl to message interval ratio". 
   Timeout Interval TLV: 
     This optional TLV contains the 8-bit timeout interval value (T) 
     used by UDLD to decide the basic length of the detection phase. Its 
     time unit is 1 second. If it's not present in an advertisement, T 
     is assumed to be a hard-coded constant. 
   Device Name TLV: 
     This required TLV is meant to be used by the CLI or SNMP and 
     typically contains the user-readable device name string. 
   Sequence Number TLV: 
     The purpose of this optional TLV is to inform the neighbors of the 
     sequence number of the current message being transmitted. A counter 
     from 1 to 2^32-1 is supposed to keep track of the sequence number; 
     it is reset whenever a transition of phase occurs so that it will 
     restart counting from one, for instance, whenever an echo message 
     sequence is initiated, or whenever a linkup message train is 
     No wraparound of the counter is supposed to happen. 
     The zero value is reserved and can be used as a representation of a 
     missing or invalid sequence number by the user interface. 
     Therefore, the TLV should never contain zero. 
     (N.B.: The use of this TLV is currently limited only to 
     informational purposes.) 
7. Protocol Logic 
   UDLD's protocol logic relies on specific internal timers and is 
   sensitive to certain network events. 
   The type of messages that UDLD transmits and the timing intervals 
   that it uses are dependent upon the internal state of the protocol, 
   which changes based on network events such as: 
Foschiano                                                    [Page 10] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
     o  Link up 
     o  Link down 
     o  Protocol enabled 
     o  Protocol disabled 
     o  New neighbor discovery 
     o  Neighbor state change 
     o  Neighbor resynchronization requests 
7.1 Protocol Timers 
   UDLD timer values could vary within certain "safety" ranges based on 
   the considerations in Section 3. However, in practice, in the current 
   implementation timers use only certain values verified during 
   testing. Their time unit is one second. 
   During the detection phase, messages are exchanged at the maximum 
   possible rate of one per second. After that, if the protocol reaches 
   a stable state and can make a certain determination on the 
   "bidirectionality" of the link, the message interval is increased to 
   a configurable value based on a curve known as M1(t), a time-based 
   In case the link is deemed anything other than bidirectional at the 
   end of the detection, this curve is a flat line with a fixed value of 
   Mfast (7 seconds in the current implementation). 
   In case the link is instead deemed bidirectional, the curve will use 
   Mfast for the first 4 subsequent message transmissions and then will 
   transition to an Mslow value for all other steady-state 
   transmissions. Mslow can be either a fixed value (60 seconds in some 
   obsolete implementations) or a user configurable value (between Mfast 
   and 90 seconds with a default of 15 seconds in the current 
8. Comparison with Bidirectional Forwarding Detection 
   Similarly to UDLD, the Bidirectional Forwarding Detection (BFD) [3] 
   protocol is intended to detect faults in the path between two network 
   nodes. However, BFD is supposed to operate independently of media, 
   data protocols and routing protocols. There is no address discovery 
   mechanism in BFD, which is left to the application to determine. 
   On the other hand, UDLD works exclusively on top of a L2 transport 
   supporting the SNAP encapsulation and operates independently of the 
   other bridge protocols (UDLD's main "applications"), with which it 
   has limited interaction. It also performs full neighbor discovery on 
   point-to-point and point-to-multipoint media. 

Foschiano                                                    [Page 11] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
Security Considerations 
   In a heterogeneous Layer 2 network that is built with different 
   models of network devices or with devices running different software 
   images, the UDLD protocol should be supported and configured on all 
   ports interconnecting said devices in order to achieve a complete 
   coverage of its detection process. Instead, UDLD is not supposed to 
   be used on ports connected to untrusted devices or incapable devices; 
   hence, it should be disabled on such ports. 
IANA Considerations 
   This document has no actions for IANA. 
Deployment Considerations 
   Cisco Systems has supported the UDLD protocol in its Catalyst family 
   of switches since year 1999. 
Changes from the Previous Version 
   Updated as per RFC 4748 and edited as per reviewers' comments. Added 
   a section with a comparison between UDLD and BFD. 
Normative References 
   [1]  IEEE 802.1D-2004 Standard -- Media access control (MAC) Bridges 
   [2]  IEEE 802.3-2002 IEEE Standard -- Local and metropolitan area 
        networks Specific requirements--Part 3: Carrier Sense Multiple 
        Access with Collision Detection (CSMA/CD) Access Method and 
        Physical Layer Specifications 
   [3]  Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 
        draft-ietf-bfd-base-06.txt, March, 2007. 

Foschiano                                                    [Page 12] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
Author's Address 
   Marco Foschiano 
   Cisco Systems, Inc. 
   Via Torri Bianche 7, Vimercate, MI, 20059, Italy 
IPR Notice 
   The IETF has been notified of intellectual property rights claimed in 
   regard to some or all of the specification contained in this 
   document. For more information consult the online list of claimed 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf- 
Foschiano                                                    [Page 13] 

   Cisco Systems UniDirectional Link Detection Protocol     April 2007 
Full Copyright Notice 
   Copyright (C) The IETF Trust (2007). 
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
   This document and the information contained herein are provided on an 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
   This Internet-Draft will expire in October, 2007. 

Foschiano                                                    [Page 14]