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.