Cisco Systems UniDirectional Link Detection (UDLD) Protocol
RFC 5171

 
Document Type RFC - Informational (April 2008; No errata)
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 5171 (Informational)
Telechat date
Responsible AD Russ Housley
Send notices to foschia@cisco.com
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.
Show full document text