UDLD单向链路检测原理以及故障恢复

单向链路检测（UDLD）

 

 

UDLD（UnDirectional Link Detection，单向链路检测）是一个二层协议，当一个单向连接存在时，它通过光纤或者以太网双绞线电缆来检测关于电缆侦听的物理配置。所有的连接设备必须支持UDLD，这个协议成功地定义和禁用了单向连接。当UDLD发现一个单向连接时，它提醒并禁用被影响到的端口。单向连接可以引起多种问题，包括生成树拓扑结构。

UDLD的配置

UDLD是Cisco的私有二层协议，用于检测链路的单向问题。如果物理层是up，但链路层是down，这时候就需要UDLD去检测链路是否真的已经up。当AB两端都配置好UDLD后，A给B发送一个包含自己port id的UDLD帧，B收到后会返回一个UDLD帧，并在其中包含了收到的A的port id，当A接收到这个帧并发现自己的port id也在其中后，认为这条链路是好的。反之就变成err-disable状态了。假设A配置了UDLD，而B没有配置UDLD，A给B发送一个包含自己port id的帧，B收到后并不知道这个帧是什么，也就不会返回一个包含A的port id的UDLD帧，那么，这时候A就认为这条链路是一个单向链路，自然也就变成err-disable状态了。

在全局模式下使用如下命令：

udld {aggressive | enable | message time message-timer-interval} message timer 默认下60秒，减少message timer提高检测的速度，但是会增加CPU负载

使用no udld {aggressive | enable | message}命令禁用UDLD ，UDLD默认情况下禁用。

UDLD的两种工作模式，一种是默认的normal模式，当监测吉比特接口出现了故障，它会监测到单向性链路，防止出现问题。如果某个端口连接正确没有故障，但只是传输是单向的，udld不会监测到单向链路，因为第1层机制没有问题，它也不会非法这个端口。（In normal mode, UDLD detects unidirectional links due to misconnected interfaces on fiber-optic connections.）

另一种模式是aggressive，模式下，当出现一下情况时，它会监测到单向链路，它将非法端口： 
* 一个光纤吉比特端口或双绞线链路中，其中一个端口不能发送或接收数据包 
* 一个光纤吉比特端口或双绞线链路中，其中一个端口断了而其他端口是活动 
* 一个光纤线缆的一头连接错误 
（In aggressive mode, UDLD also detects unidirectional links due to one-way traffic on fiber-optic and twisted-pair links and due to misconnected interfaces on fiber-optic links.）

这个命令只在光纤接口起作用，使用接口命令来在其他类型的接口上开启UDLD。

可以使用如下命令来恢复单向链路检测shutdown的接口：

1. udld reset 开启所有被shut down 的接口

Switch# udld reset
1 ports shutdown by UDLD were reset.

2. 顺次使用 shut ，no shut 命令

3. 全局模式下使用 no udld enable 然后使用udld {aggressive | enable}来重启UDLD

4. 接口模式下使用no udld port然后使用udld port 或者 udld port aggressive来重新开启特定接口的UDLD

Switch(config)# interface gigabitethernet0/1
Switch(config-if)# no udld port

Switch(config)# interface gigabitethernet0/1
Switch(config-if)# udld port

5. 使用 errdisable recovery cause udld 和 errdisable recovery interval interval 全局命令自动恢复UDLD error-disabled state

使用show udld 来检查配置情况

 

更多详细解释：

http://blog.ine.com/2008/07/05/udld-modes-of-operation/

 

UDLD (Unidirectional Link Detection) is Cisco proprietary extension for detecting a mis-configured link. The idea behind it is pretty strighforward – allow two switches to verify if they can both send and receive data on a point-to-point connection. Consider a network with two switches, A and B connected by two links: “A=B”. Naturally, if “A” is the root of spanning tree, one of the ports on “B” will be blocking, constantly receiving BPDUs from “A”. If this link would turn uni-directional and “B” would start missing those BPDUs, the port will eventually unblock, forming a loop betwen “A” and “B”. Note that the problem with unidirectional links usually occurs on fiber-optical connections and is not common on UTP (wired) connections, where link pulses are used to monitor the connection integrity. 

The confusion about UDLD is that Cisco provides quite unclear description of the feature operations be it on CatOS or IOS platform. So here is a short overview of how UDLD works.

1) Both UDLD peers (switches) discover each other by exchanging special frames sent to well-known MAC address 01:00:0C:CC:CC:CC. (Naturally, those frames are only understood by Cisco switches). Each switch sends it’s own device ID along with the originator port ID and timeout value to it’s peer. Additionally, a switch echoes back the ID of it’s neighbor (if the switch does see the neighbor). Since some versions of CatOS and IOS you can change UDLD timers globally.

2) If no echo frame with our ID has been seen from the peer for a certain amount of time, the port is suspected to be unidirectional. What happens next depends on UDLD mode of operations.

3) In “Normal” mode, if the physical state of port (as reported by Layer 1) is still up, UDLD marks this port as “Undetermined”, but does NOT shut down or disable the port, which continues to operate under it’s current STP status. This mode of operations is informational and potentially less disruptive (though it does not prevent STP loops). You can review the “undetermined” ports using CLI show commands when troubleshooting the STP issues though.

3) If UDLD is set to “Agressive” mode, once the switch loses it’s neighbor it actively tries to re-establish the relationship by sending a UDLD frame 8 times every 1 second (surpisingly this coincides with TCP keepalives retry values used by FCIP on Cisco MDS storage switches  . If the neighbor does not respond after that, port is considered to be unidirectional and brought to “Errdisable” state. (Note that you can configure “errdisable recovery” to make switch automatically recover from such issues)

4) UDLD “Aggressive” will only brings link to errdisable state when it detects “Bidirectional” to “Unidirectional” state transition. In order for a link to become “Bidirectional”, UDLD process should first hear an echo packet with it’s own ID from a peer on the other side. This prevents link from becoming errdisabled when you configure “Aggressive” mode just on one side. The UDLD state of such link will be “Unknown”.

5) UDLD “Aggressive” inteoperates with UDLD “Normal” on the other side of a link. This type of configuration means that just one side of the link will be errdisabled once “Unidirectional” condition has been detected.

To complete this overview, remember that UDLD is designed to be a helper for STP. Therefore, UDLD should be able to detect an unidirectional link before STP would unblock the port due to missed BPDUs. Thus, when you configure UDLD timers, make sure your values are set so that unidirectional link is detected before “STP MaxAge + 2xForwardDelay” expires. Additionally, notice that UDLD function is similar to STP Loopguard and Bridge Assurance feature found in newer switches. The benefit of UDLD is that it operates at physical port-level, whereas STP may not be able to detect a malfunctioning link bundled in an Etherchannel. This is why you normally use all features together – they don’t replace but truly complement each other.