Cisco Systems UniDirectional Link Detection (UDLD) Protocol
RFC 5171
Document | Type |
RFC - Informational
(April 2008; No errata)
Was draft-foschiano-udld (gen)
|
|
---|---|---|---|
Author | Marco Foschiano | ||
Last updated | 2018-12-20 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5171 (Informational) | |
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
Network Working Group M. Foschiano Request for Comments: 5171 Cisco Systems Category: Informational April 2008 Cisco Systems UniDirectional Link Detection (UDLD) Protocol Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. Abstract 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 mechanisms. 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. Foschiano Informational [Page 1] RFC 5171 UDLD April 2008 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-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 that high-level protocols typically 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. Foschiano Informational [Page 2] RFC 5171 UDLD April 2008 2. Protocol Objectives and Applications The UniDirectional Link Detection protocol (often referred to in short as "UDLD") is a lightweight 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 malfunctions. 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.Show full document text