-
- IP Multicast Routing Technology Overview
- Configuring IGMP
- Configuring IGMP Proxy
- Constraining IP Multicast in Switched Ethernet
- Configuring Protocol Independent Multicast (PIM)
- Configuring PIM MIB Extension for IP Multicast
- Configuring MSDP
- Configuring Wireless Multicast
- Configuring SSM
- Configuring Multicast Routing over GRE Tunnel
- Configuring the Service Discovery Gateway
- IP Multicast Optimization: Optimizing PIM Sparse Mode in a Large IP Multicast Deployment
- IP Multicast Optimization: Multicast Subsecond Convergence
- IP Multicast Optimization: IP Multicast Load Splitting across Equal-Cost Paths
- IP Multicast Optimization: SSM Channel Based Filtering for Multicast
- IP Multicast Optimization: PIM Dense Mode State Refresh
- IP Multicast Optimization: IGMP State Limit
-
- Configuring the Device for Access Point Discovery
- Configuring Data Encryption
- Configuring Retransmission Interval and Retry Count
- Configuring Adaptive Wireless Intrusion Prevention System
- Configuring Authentication for Access Points
- Converting Autonomous Access Points to Lightweight Mode
- Using Cisco Workgroup Bridges
- Configuring Probe Request Forwarding
- Optimizing RFID Tracking
- Country Codes
- Configuring Link Latency
- Configuring Power over Ethernet
-
- Configuring Autoconf
- Configuring Cisco IOS Configuration Engine
- Configuring the Cisco Discovery Protocol
- Configuring Simple Network Management Protocol
- Configuring Service Level Agreements
- Configuring Local Policies
- Configuring SPAN and RSPAN
- Configuring ERSPAN
- Configuring Packet Capture
- Configuring Flexible NetFlow
-
- Preventing Unauthorized Access
- Controlling Switch Access with Passwords and Privilege Levels
- Configuring TACACS+
- MACsec Encryption
- Configuring RADIUS
- Configuring RADIUS over DTLS
- Configuring Kerberos
- Configuring Local Authentication and Authorization
- Configuring Secure Shell
- X.509v3 Certificates for SSH Authentication
- Configuring Secure Socket Layer HTTP
- IPv4 ACLs
- IPv6 ACLs
- Configuring DHCP
- Configuring IP Source Guard
- Configuring Dynamic ARP Inspection
- Configuring IEEE 802.1x Port-Based Authentication
- Configuring Device Sensor
- Web-Based Authentication
- Configuring Port-Based Traffic Control
- Configuring IPv6 First Hop Security
- Configuring SISF-Based Device Tracking
- Configuring Cisco TrustSec
- Configuring Control Plane Policing
- Configuring Wireless Guest Access
- Managing Rogue Devices
- Classifying Rogue Access Points
- Configuring wIPS
- Configuring Intrusion Detection System
-
- Administering the Switch
- Boot Integrity Visibility
- Performing Device Setup Configuration
- Configuring Autonomic Networking
- Configuring Right-To-Use Licenses
- Configuring Administrator Usernames and Passwords
- 802.11 parameters and Band Selection
- Configuring Aggressive Load Balancing
- Configuring Client Roaming
- Configuring Application Visibility and Control in a Wired Network
- Configuring Application Visibility and Control in a Wireless Network
- Configuring Location Settings
- Configuring Voice and Video Parameters
- Configuring RFID Tag Tracking
- Configuring Location Settings
- Cisco Hyperlocation
- Monitoring Flow Control
- Configuring SDM Templates
- Configuring System Message Logs
- Configuring Online Diagnostics
- Managing Configuration Files
- Configuration Replace and Configuration Rollback
- Working with the Flash File System
- Upgrading the Switch Software
- Conditional Debug and Radioactive Tracing
- Troubleshooting the Software Configuration
Configuring UniDirectional Link Detection
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Restrictions for Configuring UDLD
The following are restrictions for configuring UniDirectional Link Detection (UDLD):
-
A UDLD-capable port cannot detect a unidirectional link if it is connected to a UDLD-incapable port of another device.
-
When configuring the mode (normal or aggressive), make sure that the same mode is configured on both sides of the link.
![]() Caution | Loop guard works only on point-to-point links. We recommend that each end of the link has a directly connected device that is running STP. |
Information About UDLD
UniDirectional Link Detection (UDLD) is a Layer 2 protocol that enables devices connected through fiber-optic or twisted-pair Ethernet cables to monitor the physical configuration of the cables and detect when a unidirectional link exists. All connected devices must support UDLD for the protocol to successfully identify and disable unidirectional links. When UDLD detects a unidirectional link, it disables the affected port and alerts you. Unidirectional links can cause a variety of problems, including spanning-tree topology loops.
Modes of Operation
UDLD supports two modes of operation: normal (the default) and aggressive. In normal mode, UDLD can detect unidirectional links due to misconnected ports on fiber-optic connections. In aggressive mode, UDLD can also detect unidirectional links due to one-way traffic on fiber-optic and twisted-pair links and to misconnected ports on fiber-optic links.
In normal and aggressive modes, UDLD works with the Layer 1 mechanisms to learn the physical status of a link. At Layer 1, autonegotiation takes care of physical signaling and fault detection. UDLD performs tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected ports. When you enable both autonegotiation and UDLD, the Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.
A unidirectional link occurs whenever traffic sent by a local device is received by its neighbor but traffic from the neighbor is not received by the local device.
Normal Mode
In normal mode, UDLD detects a unidirectional link when fiber strands in a fiber-optic port are misconnected and the Layer 1 mechanisms do not detect this misconnection. If the ports are connected correctly but the traffic is one way, UDLD does not detect the unidirectional link because the Layer 1 mechanism, which is supposed to detect this condition, does not do so. In this case, the logical link is considered undetermined, and UDLD does not disable the port.
When UDLD is in normal mode, if one of the fiber strands in a pair is disconnected, as long as autonegotiation is active, the link does not stay up because the Layer 1 mechanisms detects a physical problem with the link. In this case, UDLD does not take any action and the logical link is considered undetermined.
Aggressive Mode
In aggressive mode, UDLD detects a unidirectional link by using the previous detection methods. UDLD in aggressive mode can also detect a unidirectional link on a point-to-point link on which no failure between the two devices is allowed. It can also detect a unidirectional link when one of these problems exists:
-
On fiber-optic or twisted-pair links, one of the ports cannot send or receive traffic.
-
On fiber-optic or twisted-pair links, one of the ports is down while the other is up.
In these cases, UDLD disables the affected port.
In a point-to-point link, UDLD hello packets can be considered as a heart beat whose presence guarantees the health of the link. Conversely, the loss of the heart beat means that the link must be shut down if it is not possible to reestablish a bidirectional link.
If both fiber strands in a cable are working normally from a Layer 1 perspective, UDLD in aggressive mode detects whether those fiber strands are connected correctly and whether traffic is flowing bidirectionally between the correct neighbors. This check cannot be performed by autonegotiation because autonegotiation operates at Layer 1.
![]() Note | Udld is enabled with udld aggressive mode globally. When Rx cable or Tx is cable from switch1 , then the switch1 and switch2 ports will go into Not connected state. They do not go to error disabled state. Also the port does not show any light if you check the physical connection. Switch1 (Tx)__________________(Rx) Switch2 Switch1 (Rx)__________________(Tx) Switch2 |
Methods to Detect Unidirectional Links
Neighbor Database Maintenance
UDLD learns about other UDLD-capable neighbors by periodically sending a hello packet (also called an advertisement or probe) on every active port to keep each device informed about its neighbors.
When the device receives a hello message, it caches the information until the age time (hold time or time-to-live) expires. If the device receives a new hello message before an older cache entry ages, the device replaces the older entry with the new one.
Whenever a port is disabled and UDLD is running, whenever UDLD is disabled on a port, or whenever the device is reset, UDLD clears all existing cache entries for the ports affected by the configuration change. UDLD sends at least one message to inform the neighbors to flush the part of their caches affected by the status change. The message is intended to keep the caches synchronized.
Event-Driven Detection and Echoing
UDLD relies on echoing as its detection operation. Whenever a UDLD device learns about a new neighbor or receives a resynchronization request from an out-of-sync neighbor, it restarts the detection window on its side of the connection and sends echo messages in reply. Because this behavior is the same on all UDLD neighbors, the sender of the echoes expects to receive an echo in reply.
If the detection window ends and no valid reply message is received, the link might shut down, depending on the UDLD mode. When UDLD is in normal mode, the link might be considered undetermined and might not be shut down. When UDLD is in aggressive mode, the link is considered unidirectional, and the port is disabled.
UDLD Reset Options
If an interface becomes disabled by UDLD, you can use one of the following options to reset UDLD:
The udld reset interface configuration command.
The shutdown interface configuration command followed by the no shutdown interface configuration command restarts the disabled port.
The no udld {aggressive | enable} global configuration command followed by the udld {aggressive | enable} global configuration command reenables the disabled ports.
The no udld port interface configuration command followed by the udld port [aggressive] interface configuration command reenables the disabled fiber-optic port.
The errdisable recovery cause udld global configuration command enables the timer to automatically recover from the UDLD error-disabled state, and the errdisable recovery interval interval global configuration command specifies the time to recover from the UDLD error-disabled state.
Default UDLD Configuration
How to Configure UDLD
Enabling UDLD Globally (CLI)
Follow these steps to enable UDLD in the aggressive or normal mode and to set the configurable message timer on all fiber-optic ports on the device.
Enabling UDLD on an Interface (CLI)
Follow these steps either to enable UDLD in the aggressive or normal mode or to disable UDLD on a port.
| Command or Action | Purpose | |||
|---|---|---|---|---|
| Step 1 | configure terminal Example: Device# configure terminal | |||
| Step 2 | interface interface-id Example: Device(config)# interface gigabitethernet 1/0/1 | Specifies the port to be enabled for UDLD, and enters interface configuration mode. | ||
| Step 3 | udld port [aggressive] Example: Device(config-if)# udld port aggressive |
| ||
| Step 4 | end Example: Device(config-if)# end |
Monitoring and Maintaining UDLD
| Command | Purpose |
|---|---|
| Displays the UDLD status for the specified port or for all ports. |
Additional References for UDLD
Related Documents
| Related Topic | Document Title |
|---|---|
|
Layer 2 command reference |
Layer 2/3 Command Reference (Catalyst 3850 Switches) |
Error Message Decoder
| Description | Link |
|---|---|
|
To help you research and resolve system error messages in this release, use the Error Message Decoder tool. |
https://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi |
Standards and RFCs
| Standard/RFC | Title |
|---|---|
| None | — |
MIBs
| MIB | MIBs Link |
|---|---|
|
All supported MIBs for this release. |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Technical Assistance
| Description | Link |
|---|---|
|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
Feature Information for UDLD
Release |
Modification |
|---|---|
Cisco IOS XE 3.2SE |
This feature was introduced. |


Feedback