Technical Webinar

UDLD
2019

CONFIDENTIAL | Copyright ©2019 Rockwell Automation, 1

Inc. |
UDLD Operation
Why do we need UDLD ?

During normal operation, STP blocks port on C , to avoid the loop A – B – C.

On link B-C , port B is set as “Designated Port” and port C as “Blocking Port”.
Although traffic is now interrupted on link B-C , port B keeps sending BPDUs to C , so that C knows
that B is still there. The port is blocked while C sees BPDUs from B on that link.

Refer to : www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html
Why do we need UDLD ?

Now, consider what happens if the link B-C fails in the direction of C.
C stops receiving traffic from B, however, B still receives traffic from C .
C stops receiving BPDUs on the link B-C, and ages the information received with the last BPDU.
This takes up to 20 seconds, depending on the maxAge STP timer.
Why do we need UDLD ?

Once the STP information is aged out on the port, that port transitions from the blocking state to
the listening, learning, and eventually to the forwarding STP state. This creates a forwarding loop,
as there is no blocking port in the triangle A-B-C. Packets cycle along the path taking additional
bandwidth until the links are completely filled up. This brings the network down. This is one of the
reasons why STP alone is not enough : we need UDLD to prevent this situation.
How does UDLD work ?
• UDLD is a Layer 2 (Data Link) protocol that works with the Layer 1 (Physical) mechanisms to
determine the physical status of a link.
• At Layer 1, auto-negotiation takes care of physical signaling and fault detection. UDLD
performs tasks that auto-negotiation cannot perform, such as detecting the identities of
neighbors and shutting down misconnected ports.
• UDLD works by exchanging protocol packets between the neighboring devices. In order for
UDLD to work, both devices on the link must support UDLD and have it enabled on respective
ports.
How does UDLD work ?
• Each switch port configured for UDLD sends UDLD protocol packets that contain the port's own
deviceID, and the neighbor's device/port IDs seen by UDLD on that port. Neighboring ports
should see their own deviceID (echo) in the packets received from the other side.
• If the port does not see its own deviceID in the incoming UDLD packets for a specific duration
of time, the link is considered unidirectional.
• This echo-algorithm allows detection of these issues:
- Link is up on both sides, however, packets are only received by one side.
- Wiring mistakes when receive and transmit fibers are not connected to the same port on
the remote side.
How does UDLD work ?
• Once the unidirectional link is detected by UDLD, the respective port is disabled and this
message is printed on the console:
- UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled
- Port shutdown by UDLD remains disabled until it is manually reenabled, or until errdisable
timeout expires (if configured).
UDLD Modes of Operation
UDLD can operate in two modes: normal and aggressive
• In normal mode, if the link state of the port was determined to be bi-directional and the UDLD
information times out, no action is taken by UDLD. The port state for UDLD is marked as
undetermined. The port behaves according to its STP state.
• In aggressive mode, UDLD tries to re-establish the state of the port. If not successful, the port
is put into the errdisable state.
• Aging of UDLD information happens when the port that runs UDLD does not receive UDLD
packets from the neighbor port for duration of hold time. The hold time for the port is dictated by
the remote port and depends on the message interval at the remote side. The shorter the
message interval, the shorter the hold time and the faster the detection.
UDLD Modes of Operation
• It is important to be able to choose the right message interval in order to ensure proper
detection time. The message interval should be fast enough to detect the unidirectional link
before the forwarding loop is created, however, it should not overload the switch CPU. The
default message interval is 15 seconds, and is fast enough to detect the unidirectional link
before the forwarding loop is created with default STP timers. The detection time is
approximately equal to three times the message interval.
• For example: Tdetection ~ message_interval x3 . This is 45 seconds for the default message
interval of 15 seconds. It takes Treconvergence=max_age + 2x forward_delay for the STP to
reconverge in case of unidirectional link failure. With the default timers, it takes 20+2x15=50
seconds.
HW setup
HW Setup
Two Stratix 5700 connected through an unmanaged switch

SW_182 SW_184
10.64.39.182 10.64.39.184

pc
10.64.39.111
Configuration – Express Setup
Example 1

1. After Express Setup , I run „show run“ from CLI. I see that „udld
aggressive“ is enabled.

2. Disconnect cable between SW_184 and unmanaged sw.

Nothing happens with SW_182 : why? Because UDLD must be also enabled
on the interface ( on both SW182 AND SW184 ! ) :
( UDLD must be enabled on all devices in order to work )

Note : if I don‘t do that , then interface Fa1/3 will stay in udld normal mode,
not aggressive . That means that it will not disable the port when cable is
disconnected (as we saw before)
Example 1

3. I press „show UDLD“ from CLI

on SW184.
I see that „udld aggressive“ is
enabled.
I also see Ser. Numbers of both
switches.
Example 1
4. Now both Stratix are connected through an unmanaged switch .
Ping to SW_184 works fine :

5. Disconnect cable between SW_184 and unmanaged sw. Now I expect that UDLD should work.
After ca. 45 sec I see this on SW182 syslog . UDLD has blocked Fa1/3 port on SW182

6. Ping now fails :

Example 1
7. After 30 secs , port 1/3 recovers :

8. I reconnect cable and ping now works again :

Example 1

Why 30 seconds ? I can see it with

command „show errdisable recovery“

I can see here which interfaces are

blocked. In this case there is no UDLD
fault, so no interface is blocked
Example 1

#show errdisable recovery

When UDLD fault occurs , I can see which

interfaces are blocked and time left.

I can see that after 23 secs , port Fa1/3 will

be enabled again.
 Example 1
Now I disable UDLD error recovery using
command :
#No errdisable recovery cause udld

Now the difference is that , after disconnecting

the cable , Fa1/3 stays in down state , it will
not recover as it did before .

Note : reconnecting cable will NOT recover

Fa1/3
Example 1
Now I enable UDLD error recovery using command :
„errdisable recovery cause udld“ . Port will recover after ca. 30 secs
UDLD packets

UDLD address is
01:00:0c:cc:cc:cc

Device ID

Note: mac address differs because each

port has its own MACaddress
Define ACL to filter out UDLD packets
An alternative way to test UDLD is to block packets with address 01.00.0ccc.cccc .

Here I define an ACL based on MAC :

This is the command to enable the filter ( at

the interface level ). When I enable it,
UDLD packets will be filtered out.