<acronym title="UniDirectional Link Detection">UDLD
</acronym> is a Cisco protocol designed to detect and disable unidirectional links in Ethernet (fiber or twisted-pair). In the case of a radio-based Metro Ethernet ring, UDLD goes the extra mile in preventing Spanning-Tree loops and user service interruption.
In this simple network of four switches, Spanning-Tree Protocol is preventing a loop by blocking traffic at switch C. Switch D is not aware that switch C is not accepting traffic, but that's necessary for switch D to operate normally. Switch C is aware of Switch D and is still sending and receiving
<acronym title="Bridge Protocol Data Units">BPDU
</acronym>s at configured intervals. If switch C stops receiving BPDUs from switch B or if the cost of the path through switch B becomes too high, switch C will stop blocking the link from switch D.
Here we have the same simple four switch network, but we've introduced a unidirectional link (I've made it red for emphasis). The major problem with this situation is that switch B is still receiving BPDUs from switch A and sending BPDUs to switch C based on the path information received from switch A. Unfortunately, this leads to a predicament where switches B and C do not know there has been a change in topology. In effect, they are sending all their non-local packets toward switch A, but the packets are never reaching their destination. This causes an outage for users on switches B and C.
With aggressive UDLD configured on the ports between switches A and B, switch A realizes that it is no longer receiving packets from switch B when it fails to receive a hello message within the specified time out interval. UDLD shuts down the port which results in a topology change in Spanning-Tree Protocol. Switch C no longer receives the root path information from switch B and stops blocking the link from switch D. Normal traffic flow resumes and customers are only temporarily affected.
In its default configuration, a port disabled by UDLD must be manually enabled (via
shutdown followed by
no shutdown, for example). You can force the Cisco Catalyst to try and recover the disabled switch periodically by issuing the following command:
Switch(config)# errdisable recovery cause udld
The default recovery time is every 5 minutes.
In a standard twisted-pair Ethernet installation, UDLD is almost never necessary. The chances of having a unidirectional link on a Cat 5 cable must be incredibly low (in 10 years, I've never seen it happen). In a radio-based Ethernet network, a unidirectional link is rare, but very possible. As wind and precipitation buffet a dish on a tower, there is a chance that one side of the radio link will get slightly off-aim. In that case, it's possible for the off-aim radio dish to still receive from the other side of the link, despite not being able to transmit. This condition is rare, but why risk interrupting the service of thousands of users needlessly?