Cisco UDLD Configuration: Normal vs Aggressive Mode

A unidirectional link - where one side receives traffic but the other does not - is one of the most dangerous failure modes in a switched network because it is invisible to Spanning Tree. The blocking port that should prevent the loop stops receiving BPDUs, ages out its STP information, and transitions to forwarding, creating a loop that fills the network with endlessly cycling frames. Cisco's Unidirectional Link Detection (UDLD) closes that gap by verifying at Layer 2 that neighbor identity is seen in both directions. This guide explains how UDLD works, the difference between normal and aggressive mode, and the configuration commands that protect fiber links.

The reason unidirectional faults matter more on fiber than on copper is simple physics. A duplexed copper link that loses a pair typically drops link entirely, and the switch reacts to a down interface immediately. Fiber is different: the transmit and receive paths are separate strands, and they often traverse separate patch panels, separate connectors, and separate optics. A technician who pulls one strand, bumps a connector, or swaps the pair at one end leaves the link up in the eye of the interface state machine while traffic flows in only one direction. Nothing in the interface counters necessarily changes, so the fault can persist silently until Spanning Tree reacts to the missing BPDUs - usually by doing exactly the wrong thing.

Why STP Alone Is Not Enough

STP relies on receiving BPDUs. When a fiber pair fails in one direction only, the switch at the receiving end of the failed direction stops getting BPDUs while the link stays administratively up. After the maxAge timer (up to 20 seconds), the port moves from blocking to forwarding and a loop forms - exactly the scenario UDLD prevents.

The mechanics of that transition are worth tracing. A blocking port that stops hearing the root bridge assumes the topology changed and begins the listening/learning/forwarding sequence. But the topology did not change - the other side of the link is still forwarding. The result is two forwarding paths between the same two segments, and a Layer 2 loop. Broadcast frames circulate forever, the MAC table flushes continuously, CPU climbs, and every device in the broadcast domain suffers. On a redundant campus topology with several blocked links, the same logic can fire on more than one port at once, which makes the outage both sudden and broad.

UDLD runs before that failure point. It is not a replacement for STP; it is a Layer 2 health check on the physical link that STP assumes to be working.

How UDLD Works

UDLD is a Layer 2 protocol that works with Layer 1 auto-negotiation. Each port sends UDLD frames carrying the device and port IDs it sees; a port that stops seeing its own device/port ID echoed back from the neighbor concludes the link is unidirectional and disables the port:

UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled

UDLD also catches swapped fiber pairs - receive and transmit fibers connected to the wrong ports on the far side.

The protocol works like a mutual handshake. Each UDLD frame lists the identity of the ports that the sender has heard from. When switch A hears switch B, A includes B's identity in its own frames. If B ever stops seeing its own identity echoed in A's messages - because A's frames are no longer reaching B - B concludes the link cannot be bidirectional and disables the port. Note that a port is only flagged when UDLD has previously confirmed it as bidirectional: a port that never completed the handshake is treated as undetermined rather than failed, so a port with no UDLD-capable neighbor at the far end does not get shut out of hand.

Two additional checks run alongside the state machine. First, echo verification: if the neighbor's UDLD message lists the local port's own identity as something the neighbor heard from a third device, the wiring is inconsistent and UDLD flags the link. Second, the auto-negotiation check: if the port's link negotiation mode changes unexpectedly in a way that suggests a physical fault, UDLD can disable the port even if the state machine has not yet timed out.

Normal vs Aggressive Mode

• Normal mode: if UDLD information ages out while the port state was already determined bidirectional, no action is taken and the port is marked undetermined. Normal mode blocks only the one port that stopped hearing the neighbor.
• Aggressive mode: if UDLD information ages out while the link is still up, the switch actively re-probes the neighbor; if the port cannot re-establish a bidirectional state, it is placed into errdisable. On a truly unidirectional fiber link, aggressive mode blocks both ends, which is what you want for point-to-point fiber.

The practical difference shows up in which end of the failure you are standing on. In normal mode, only the port that lost its neighbor is affected - the other end keeps forwarding. In aggressive mode, both ends are disabled once the retry sequence fails, so the link is wholly removed from the forwarding topology. For point-to-point fiber links between switches, aggressive mode is the correct choice because it guarantees that a broken link is taken out of service at both ends, which is exactly the outcome you need to keep the loop from forming.

Aggressive mode carries a well-known risk that should be stated plainly: if a CPU is overloaded and UDLD messages are delayed long enough to age out, an aggressive port can errdisable itself even on a perfectly healthy link. That is why the message interval and the errdisable auto-recovery timer deserve attention in any deployment, and why raising CPU load (storm control, CoPP, a broadcast storm) is a common precondition for a spurious UDLD shutdown.

Configuring UDLD Globally and Per Port

Enable UDLD on all fiber-optic ports from global configuration:

Switch(config)# udld enable

For aggressive mode on all fiber ports, or per port for copper/fiber point-to-point links:

Switch(config)# udld aggressive
Switch(config)# interface gigabitEthernet1/0/1
Switch(config-if)# udld port aggressive

Two commands that deserve equal billing are the ones that disable UDLD where it does not belong. Enable only on fiber and point-to-point links, and leave UDLD off on ports facing hosts, servers or any device that will never speak UDLD:

Switch(config)# interface range gigabitEthernet1/0/10 - 24
Switch(config-if-range)# udld disable
Switch(config)# udld port disable
Switch# no udld enable

On a fiber link to a device that does not run UDLD, the port stays in the undetermined state - harmless in normal mode, but a genuine risk in aggressive mode if the far end is silent for long enough. Match the mode to the neighbor: aggressive on switch-to-switch fiber, normal or disabled toward non-switch devices.

Tuning the Message Interval

UDLD messages are sent every 15 seconds by default (range 1-90 seconds). A shorter interval detects faults faster but costs more protocol traffic; the hold time is dictated by the remote side's message interval:

Switch(config)# udld message time 10
UDLD message interval set to 10 seconds

The hold time is not configured directly. It is derived: a port holds its UDLD state for roughly three times the neighbor's advertised message interval, so a neighbor sending every 10 seconds ages out after about 30 seconds. That relationship is the reason a single missed message should not cause a shutdown, but three in a row will - and why shortening the interval on one side quietly shortens the detection window on the other. If you tune it, tune it deliberately and on both ends, and keep an eye on CPU utilisation during the change window.

Recovering Errdisabled Ports

When UDLD disables a port it stays down until you intervene. Re-enable it manually, or configure errdisable detection and auto-recovery:

Switch(config)# errdisable detect cause udld
Switch(config)# errdisable recovery cause udld
Switch(config)# errdisable recovery interval 300
Switch# clear errdisable interface gigabitEthernet1/0/1

The distinction between the detect and recovery commands matters operationally. errdisable detect cause udld controls whether the switch actually error-disables the port when UDLD fails; errdisable recovery cause udld controls whether it is automatically brought back after the interval. Turning on auto-recovery without understanding why the port went down simply restarts the loop: the fault is still there, the port comes back, UDLD fails again, and the cycle repeats. Configure recovery so you are not forced into a maintenance window for every transient, but treat a repeated errdisable from the same port as a physical-layer fault that needs a fiber test, not a configuration tweak.

Verifying UDLD

Switch# show udld gigabitEthernet1/0/1
Switch# show udld neighbors
Switch# show udld
Switch# show errdisable recovery

The neighbor table should show a Bidirectional state; anything else means the fiber plant needs attention.

Read the per-interface output in three places: the current operational state, the mode (normal or aggressive), and the timer values. A port in an undetermined state on a link you believe is a working switch-to-switch connection is a finding worth chasing - it usually means the far end is not running UDLD, that the frames are being dropped by an intermediate device, or that the optic is marginal. Cross-check with the transceiver diagnostics on both ends: the same fault that breaks UDLD can show as an out-of-range receive power reading. Our SFP optical transceiver troubleshooting checklist walks through the Rx/Tx dBm values to look for.

UDLD Versus Loop Guard and BPDU Guard

Three features get confused in design discussions, and the difference is worth stating once:

• UDLD verifies the physical Layer 2 link in both directions and disables a port whose neighbor stops hearing it.
• Loop Guard acts on the STP state: if a root or blocked port stops receiving BPDUs without changing state, it moves to loop-inconsistent blocking instead of forwarding. It protects against the same unidirectional fault but at the control plane.
• BPDU Guard protects edge ports from receiving BPDUs at all, and is a different tool for a different problem - a rogue switch on an access port.

UDLD and Loop Guard are complementary: UDLD fixes the link, Loop Guard protects the topology if the BPDU loss happens somewhere UDLD cannot see. Running UDLD in aggressive mode on fiber interconnects plus Loop Guard on the designated links is a common and defensible belt-and-braces design. The port-level protections - PortFast, BPDU Guard and Root Guard - are covered in our Cisco spanning-tree edge protection guide, and the convergence mechanics they interact with are in RSTP vs MSTP explained.

Related articles: Cisco port security sticky MAC, and Layer 1 interface flapping troubleshooting.

原文链接：https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html