Unidirectional Link Detection Protocol
Hi guys I have an interesting issue this week. I just Move My core Switch from one Location to another and for no apparent reason some users within the network reported connection issues to hosts , Half of the newtork went down and then all of a sudden connection restored but quickly lost again.
Remember the network was having 2 x Core and then two distribution switches and all the access switches had a resiliance connectivity and are running STP, HSRP, VTP. I was able to access one of the core switches and connectivity to other core was intermitent A very quick trip to the distribution point andconsole cable connection into the core switches revealed the issue.
The two switches 6500 has 2 x 1Gb EtherChannel configured on either end, connected by fibre connections. One side of the connection reported that both links were active in the Etherchannel. The other side had one link as down and the logs showing that the connection had left the EtherChannel.
The exact reason for this is still unknown but this type of issue occurs, where one side sees the link as up but the other sees it as down, is called a unidrectional Link failure. To solve the matter immediately , I shut down the faulty link at the end replace GBIC . As soon as this was done
everything returned back to normal operations and timed out pings came back to replies.
This highlighted an issue with the Etherchannel configuration on the switches however.
I have an advise from network forums to use a mode of desirable on either side of an Etherchannel connection, rather than forcing the Etherchannel up. The on mode forces a port to join an Etherchannel without any sort of Etherchannel protocol negotiation taking place. Using the desirable keyword instead of the on keyword means that the switch uses the Port Aggregation Protocol (PAgP). When using PAgP the switch learns of partner interfaces on other switches that support PAgP and dynamically groups its interfaces into an Etherchannel.
In the situation I mentioned above this happened when an interfaces from the etherchannel stopped seeing PAgP packet (when we were moving our core Switch) . and it is quiet possible for one switch to move the interface into stand-alone mode and pass traffic across a broken link, as it was still seeing this link as up. In order to help in these type of sitations Cisco developed the Unidirectional Link Dection protocol.
UDLD is a Layer 2 (L2) protocol that works with the Layer 1 (L1) 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. When you enable both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.
By enabling UDLD in aggressive mode when a port on a bidirectional link that has a UDLD neighbor relationship established stops receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port is disabled, whihc avoids loops in the newtork inorder to prevent spanning tree loops, nonaggressive UDLD is fast enough to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default spanning tree parameters).
here are commands to enable UDLD
To configure aggressive mode only one more keyword is required
SWA(config-if)#udld port aggressive
IN cisco 6500 series switch periodically transmits UDLD packets to neighbor devices, If the packets are echoed back within a specific time frame and they are lacking a specific acknowledgment (echo), the link is flagged as unidirectional and the LAN port is shut down. Devices on both ends of the link must support UDLD in order for the protocol to successfully identify and disable unidirectional links. By Default UDLD is locally disabled on copper LAN ports