RFC 5171

Cisco Systems UniDirectional Link Detection (UDLD) Protocol

📅 published April 2008, from ietf

Okay bestie, here's the title block so you know who's behind this 💖

  • Network Working Group 🌸
  • Request for Comments: 5171
  • Author: M. Foschiano, Cisco Systems
  • Category: Informational
  • Date: April 2008
  • Obsoletes and Updates: nothing is listed in the title block 🦋

Status of This Memo ✨

This memo provides info for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈

IESG Note 🙈

The IESG says this RFC is not a candidate for any level of Internet Standard, and the IETF doesn't know whether it's fit for any purpose. It especially points out that the decision to publish wasn't based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor chose to publish it at their own discretion, so readers should be careful about evaluating its value before implementing or deploying anything. See RFC 3932 for more information 💅

Abstract 🦋

So this doc is about a Cisco protocol that can detect and disable unidirectional Ethernet links, whether they're fiber or copper 🔥 These happen when things like fiber strands get mis-wired, interfaces glitch, or media converters act up. It works at Layer 2, alongside the Layer 1 fault detection that IEEE 802.3 already has.

It also explains the protocol's objectives and applications, the premises it was built on, and its architecture and deployment issues. Basically it's a possible starting point for future standardization 🧚

Table of Contents

1. Introduction ....................................................2
2. Protocol Objectives and Applications ............................3
3. Protocol Design Premises ........................................4
4. Protocol Background .............................................4
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 ...........................................10
8. Comparison with Bidirectional Forwarding Detection .............11
9. Security Considerations ........................................11
10. Deployment Considerations .....................................11
11. Normative References ..........................................12
12. Informative Reference .........................................12

1. Introduction ✨

Today's Ethernet switched networks often lean on the Spanning Tree Protocol (STP), which is defined in the IEEE 802.1D standard [1]. STP builds a loop-free topology so traffic can get from a source to a destination, using the Layer 2 packet info the switches learn and what they know about the status of the physical links along the path 💖

Things get messy when mis-wirings or hardware faults make the path act up and cause forwarding anomalies 😭 The simplest example is a bidirectional link that stops passing traffic in one direction. That breaks one of the biggest assumptions high-level protocols make, which is reliable two-way communication between peers.

The UDLD protocol is there to detect anomalous conditions in the Layer 2 communication channel. It relies on the mechanisms IEEE defined in the 802.3 standard [2] to properly handle the physical layer stuff 🎀

2. Protocol Objectives and Applications 🌸

The UniDirectional Link Detection protocol (usually just called "UDLD") is a lightweight protocol. It can detect and disable one-way connections before they cause dangerous situations like Spanning Tree loops or other protocol malfunctions 🚨

Its main goal is to advertise the identities of all the capable devices attached to the same LAN segment. It also collects the information received on each device's ports to figure out whether Layer 2 communication is happening the right way 👑

Picture an extensive fiber cabling plant where incorrect patching makes a switch port's RX fiber strand connect to one neighbor port while its TX strand connects to another. The port can look active because it's receiving an optical signal on its RX strand 👀 The problem is that this link doesn't provide a valid communication path at Layer 2 (and above), so it's not actually usable.

Now imagine that wrong fiber connection happening on multiple ports to make a fiber loop. Every device in the loop could send packets directly to a neighbor, but it wouldn't be able to receive from that neighbor 💀

That scenario is pretty extreme, but it shows how a lack of mutual identification between neighbors can lead protocols to assume that the sender and receiver are always properly matched during a transmission. Another equally dangerous wrong assumption is that not receiving protocol messages on a port means there are no transmitting protocol entities at the other end of the link 🙈

UDLD was built to fix some of those assumptions made by other protocols. Its big job is helping the Spanning Tree Protocol work properly so dangerous Layer 2 loops don't get created. It's been available on most Cisco Systems switches for several years now, and it's part of lots of network design best practices 💅

3. Protocol Design Premises 🧚

The current UDLD implementation is based on these considerations and presuppositions:

  • The protocol would have to run in the control plane of a network device so it's flexible enough to support upgrades and bug fixes. The control plane speed would ultimately be the limiting factor for how fast the protocol can detect faults (CPU speed, task switching speed, event processing speed, etc.). Meanwhile, the transmission medium's propagation delay at 10 Mbps speed (or higher) would be considered a negligible factor 🔥
  • Network events usually don't happen with optimal timing. They happen at whatever speed the software or firmware controlling them runs at. (For psychological and practical reasons, developers tend to pick round timer values instead of working out the optimal value for the software architecture in use. Software bugs, coding oversights, slow process switching, and implementation overhead can all affect control plane responsiveness and event timings too 😩) That's why it was deemed necessary to adopt a conservative protocol design that keeps false positives during detection to a minimum 🫶
  • If a fault were discovered, it was assumed the user would want to keep the faulty port down for a predetermined amount of time to avoid unnecessary port state flapping. That's why a time-based fault recovery mechanism was provided. (Alternative recovery mechanisms aren't implicitly precluded by the protocol itself, though 🍓)

4. Protocol Background 🌈

UDLD is meant to be a Layer 2 detection protocol that works on top of the existing Layer 1 detection mechanisms IEEE defined. For example, the Far End Fault Indication (FEFI) function for 100BaseFX interfaces and the Auto-Negotiation function for 100BaseTX/1000BaseX interfaces are standard physical-layer mechanisms for figuring out whether the transmission media is bidirectional. (Please see sections 24.3.2.1 and 28.2.3.5 of [2] for more details.) The typical Layer 1 "fault" indication is the "loss of light" indication ✨

UDLD is different from those mechanisms in one big way: it does mutual neighbor identification. On top of that, it does neighbor acknowledgement on top of the Logical Link Control (LLC) layer. That means it can catch logical one-way miscommunication between neighbors even when one of those PHY layer mechanisms has already decided the transmission medium is bidirectional 🙌

5. Protocol Architecture 🦋

5.1. The Basics

UDLD uses two basic mechanisms:

  1. It advertises a port's identity and learns about its neighbors on a specific LAN segment. It keeps the acquired neighbor information in a cache table 💖
  2. It sends a train of echo messages in certain circumstances that need fast notifications or fast resynchronization of the cached information ⚡

Because of all that, the algorithm UDLD runs requires that every device connected to the same LAN segment is running the protocol. Only then can a potential misconfiguration be detected and a prompt corrective action be taken 💅

5.2. Neighbor Database Maintenance

UDLD sends periodical "hello" packets (also called "advertisements" or "probes") on every active interface. This keeps each device informed about its neighbors 📣 When a hello message comes in, it gets cached and kept in memory for at most a defined time interval called "holdtime" or "time-to-live." After that, the cache entry is considered stale and gets aged out 🕰️

If a new hello message arrives while a matching old cache entry hasn't aged out yet, the old entry gets dropped and replaced by the new one with a reset time-to-live timer 🔄 Whenever an interface gets disabled while UDLD is running, whenever UDLD is disabled on an interface, or whenever the device is reset, all existing cache entries for the affected interfaces get cleared. UDLD also sends at least one message to tell the neighbors to flush the parts of their caches affected by the status change. This keeps the caches coherent across all the connected devices 🫧

5.3. Event-driven Detection and Echoing

Echoing is the base of UDLD's detection algorithm 🔥 Whenever a UDLD device learns about a new neighbor, or gets 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 enough to get through a link and reach the other end, even though some of them might get dropped during transmission.)

Since this behavior has to be the same on all the neighbors, the sender of the echoes expects to get an echo back after some time. If the detection process ends without the proper echo information being received, the link is considered unidirectional under specific conditions 👀

5.4. Event-based versus Event-less Detection 🦋

okay so UDLD can run in two modes, normal mode and aggressive mode 💅

in normal mode, the final call at the end of detection is always based on what UDLD actually received in its messages 📨 that could be the good news (proper neighbor IDs showed up) or the bad news (they didn't). even though a timer is involved, normal mode decisions are built on info it gleaned, which makes them "event-based" ✨ if it can't get any info at all (like a total two-way connection loss 💀), UDLD plays it safe using the reasoning from Section 3 and marks the port as "undetermined". so in normal mode, a port only gets shut down when UDLD can clearly tell the link is faulty for a long stretch of time 🫶

aggressive mode is the more dramatic one 🔥 here UDLD will also shut down a port if it loses two-way connectivity with the neighbor for that same long stretch, AND then keeps failing its repeated last-resort attempts to reconnect with the other end of the link. this mode treats losing contact with a neighbor as a meaningful network event all on its own, a sign of a serious connectivity problem 😭 the catch is that this kind of detection can be event-less, and not hearing anything doesn't always mean the link is actually broken 🙈 so aggressive mode is optional, and it's only recommended in certain scenarios, typically only on point-to-point links where no communication failure between two neighbors is admissible 🌈

6. Packet Format 🎀

okay this part is the nitty-gritty bestie 🧚 UDLD runs on top of the LLC sub-layer of the data link layer of the OSI model. it sends its messages using the standard Subnetwork Access Protocol (SNAP) format, and it uses a specially assigned multicast destination MAC address:

         Destination MAC address            01-00-0C-CC-CC-CC

         UDLD SNAP format:
           LLC value                        0xAAAA03
           Org Id                           0x00000C
           HDLC protocol type               0x0111

the UDLD Protocol Data Unit (PDU) is laid out like this 🍓

    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)             |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and every TLV uses this basic format 💖

    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                             |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's what each TLV field does ✨

  • Type (16 bits): if an implementation doesn't 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. for this value to be valid, it should be greater than or equal to the minimum allowed length, 4 bytes. if it's less than that minimum, 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): the object contained in the TLV 💜

now the protocol header fields, which are giving precision 👑

   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 one's complement of the one'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.)  NB: All UDLD
         implementations must comply with this specification.

and the list of currently defined TLVs is this 🌸

      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 🧚

let's break down each TLV, bestie 💅

Device-ID TLV: this one uniquely identifies the device that's sending the UDLD packet. the TLV length field sets the length of the carried identifier, and it must be greater than zero. in version 1 of the protocol, a missing ID is treated as a symptom of packet corruption, which means the message is invalid and must be discarded 🙈

Port-ID TLV: this one uniquely identifies the physical port the UDLD packet is sent on. the TLV length field sets the length of the carried identifier, and it must be greater than zero. in version 1 of the protocol, a missing ID is considered a symptom of packet corruption, so the message is invalid and must be discarded 🫶

Echo TLV: this one holds the list of valid DeviceID/PortID pairs that a port has received from all its neighbors ✨ if either identifier in a pair is corrupted, the message gets ignored. the list only includes DeviceIDs and PortIDs pulled from UDLD messages received and cached on the same interface this TLV is sent on. if no UDLD messages have been received, this TLV is sent with zero pairs. despite its name 🙃, this TLV must be present in both probe and echo messages, whereas in flush messages it's not required 🦋

Message Interval TLV: this required TLV carries the 8-bit time interval a neighbor uses 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 carries the 8-bit timeout interval value (T) that UDLD uses to decide the basic length of the detection phase. its time unit is 1 second. if it isn't in an advertisement, T is assumed to be a hard-coded constant 🍓

Device Name TLV: this required TLV is meant for the CLI or SNMP, and it typically holds the user-readable device name string 💖

Sequence Number TLV: the purpose of this optional TLV is to tell the neighbors the sequence number of the message currently being sent 🧁 a counter from 1 to 2^32-1 is supposed to track the sequence number. it gets reset whenever a phase transition happens, so it starts counting from one again. for example, that happens whenever an echo message sequence is started, or whenever a linkup message train gets triggered ✨

the counter is not supposed to wrap around 🙅‍♀️

the zero value is reserved, and the user interface can use it to represent a missing or invalid sequence number. so the TLV should never contain zero. (NB: the use of this TLV is currently limited only to informational purposes. 🤓)

7. Protocol Logic 👑

UDLD's protocol logic depends on specific internal timers, and it's sensitive to certain network events 🔥

the type of messages UDLD transmits, and the timing intervals it uses, depend on the protocol's internal state. that state changes based on network events such as:

  • Link up
  • Link down
  • Protocol enabled
  • Protocol disabled
  • New neighbor discovery
  • Neighbor state change
  • Neighbor resynchronization requests

7.1. Protocol Timers ⏰

UDLD timer values could vary within certain "safety" ranges based on the considerations in Section 3. in practice, though, the current implementation only uses timer values that were 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 increases to a configurable value based on a curve known as M1(t), which is a time-based function 📈

if the link is deemed anything other than bidirectional at the end of detection, this curve is a flat line with a fixed value of Mfast (7 seconds in the current implementation) 😬

if the link is instead deemed bidirectional, the curve uses Mfast for the first 4 subsequent message transmissions, and then transitions 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 implementations) 🌸

8. Comparison with Bidirectional Forwarding Detection 🦋

similar to UDLD, the Bidirectional Forwarding Detection (BFD) [3] protocol is intended to detect faults in the path between two network nodes 🫶 but BFD is supposed to operate independently of media, data protocols, and routing protocols. there's no address discovery mechanism in BFD, which is left to the application to determine 🤷‍♀️

UDLD, on the other hand, works exclusively on top of an L2 transport that supports SNAP encapsulation. it 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 ✨

9. Security Considerations 🔐

⚠️ this one is serious, bestie. in a heterogeneous Layer 2 network 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, so that its detection process gets complete coverage. and UDLD is not supposed to be used on ports connected to untrusted devices or incapable devices, so it should be disabled on those ports 🚨

10. Deployment Considerations 🌈

Cisco Systems has supported the UDLD protocol in its Catalyst family of switches since 1999 💜

11. Normative References ✨

okay so first up, the normative references, which are the docs this spec basically needs you to have on hand 📚 💖

  • [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 🦋

12. Informative Reference 🌸

and then there's the one that's just good to know about, not required reading 🧚

  • [3] Katz, D., and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2008. 💜

Author's Address 🎀

the author is Marco Foschiano at Cisco Systems, Inc., in Via Torri Bianche 7, 20059 Vimercate (Mi), Italy 🇮🇹 and you can email him at foschia@cisco.com 💌

Copyright (C) The IETF Trust (2008).

this document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. 🔐

this document and the information in it are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

Intellectual Property 🍓

the IETF takes no position on whether any Intellectual Property Rights or other rights might be claimed over the technology in this document, or whether any license under those rights might or might not be available, and it doesn't claim to have made any independent effort to find such rights. more info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🌐

the IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to ietf-ipr@ietf.org 📬 🫶

📦 where this page comes from