排除Nexus交換機上的單向鏈路檢測錯誤

簡介

本文檔介紹如何對Cisco Nexus 7000系列交換機上的單向鏈路檢測(UDLD)錯誤消息進行故障排除。

必要條件

需求

思科建議您瞭解以下主題的基本知識：

• Cisco Nexus作業系統(Cisco NX-OS)
• 基本UDLD操作 

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• Cisco Nexus 7000 系列交換器
• Cisco NX-OS版本6.2(10) 

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊 

執行UDLD檢測進程時，埠交換UDLD資料包，包括發起方交換機ID和發起方埠ID。收到UDLD資料包時，交換機將對等交換機ID和埠ID回顯給對等交換機。當交換機交換回聲資料包時，形成雙向關係。 

當交換機未從其UDLD對等體收到預期資訊時，就會出現UDLD錯誤情況。 

本檔案將說明這些UDLD錯誤情況以及如何進行疑難排解：

• Empty-echo
• 傳輸-接收(Tx-Rx)回圈
• 單向
• 鄰居不匹配
• UDLD幀的突然停止 

UDLD錯誤情況

本節介紹各種型別的UDLD錯誤情況以及一些可能的原因。

空白回應 

當交換機A收到來自交換機B的UDLD幀，而預期中沒有交換機A的交換機ID和埠ID的回聲時，就會出現這種情況。 

偵測到空的回應時，UDLD會執行下列動作：

模式	動作
正常模式	錯誤停用連線埠
主動模式	錯誤停用連線埠

然後生成以下系統日誌消息：

2015 Mar 19 11:57:56.155 N7kA ETHPORT-2-IF_DOWN_ERROR_DISABLED Interface Ethernet1/2
 is down (Error disabled. Reason:UDLD empty echo)
2015 Mar 19 11:57:56.186 N7kA ETH_PORT_CHANNEL-5-PORT_INDIVIDUAL_DOWN individual port
 Ethernet1/2 is down
2015 Mar 19 11:57:56.336 N7kA ETHPORT-2-IF_DOWN_ERROR_DISABLED Interface Ethernet1/2
 is down (Error disabled. Reason:UDLD empty echo)

下面是造成這種情況的一些可能原因

• 交換機B上的UDLD雙向關係已超時，因為它未收到來自交換機A的UDLD幀。
• 交換器B收到來自交換器A的UDLD訊框，但並未處理這些訊框。
• 交換器A沒有將UDLD訊框傳送到交換器B。

Tx-Rx回圈

當在傳送幀的同一埠上收到UDLD幀時，會出現這種情況。

偵測到Tx-Rx回圈時，UDLD會執行下列動作：

模式	動作
正常模式	錯誤停用連線埠
主動模式	錯誤停用連線埠

然後生成以下系統日誌消息：

2015 Mar 20 14:52:30 N7kA   %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet17/5
 is down (Error disabled. Reason:UDLD Tx-Rx Loop)
2015 Mar 20 14:52:30 N7kA   %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet17/5
 is down (Error disabled. Reason:UDLD Tx-Rx Loop)

造成此情況的可能原因如下：

• 可能存在佈線錯誤或物理介質問題。
• 中間裝置將幀反射回傳送埠。

鄰居不匹配 

當交換機A上的埠A從已形成UDLD雙向關係的埠以外的埠接收幀時，就會出現這種情況。 

偵測到鄰居不相符時，UDLD會執行下列動作：

模式	動作
正常模式	錯誤停用連線埠
主動模式	錯誤停用連線埠

然後生成以下系統日誌消息：

2015 Mar 21 10:23:05.598 N7kA %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/21
 is down (Error disabled. Reason:UDLD Neighbor mismatch)
2015 Mar 21 10:24:07.065 N7kA %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/21
 is down (Error disabled. Reason:UDLD Neighbor mismatch)

造成此情況的可能原因如下：

• 所討論的UDLD連線埠是連線埠狀態已變更的連線埠通道的成員。
• 兩個埠之間有一個中間裝置，形成雙向關係。

UDLD幀的突然停止

當已形成雙向關係的連線埠在間隔逾時（預設為50秒）時未收到UDLD訊框時，就會出現這種情況。 

偵測到這種情況時，UDLD會執行下列動作：

模式	動作
正常模式	UDLD將埠標籤為未確定，並且埠繼續根據其生成樹埠狀態運行
主動模式	錯誤停用連線埠

排除UDLD錯誤情況故障

本節介紹如何排除故障，以及如何執行在遇到UDLDerror-disabled埠時必須完成的步驟。 

由於UDLD錯誤指示物理層故障，因此有必要在物理層進行故障排除。遇到UDLD錯誤消息時，請考慮以下問題：

• 如果更換小型可插拔收發器(SFP)，錯誤是否仍然存在？
• 如果更換了電纜，錯誤是否仍然存在？
• 如果將連線移動到交換機的其他物理埠，錯誤是否仍然存在？

有用的命令

使用以下命令，以恢復UDLD已置於error-disable模式的所有埠：

N7KA(config)# udld reset

使用以下命令以驗證雙向關係：

N7KA-NORTH-AGG(config-if)# show udld eth 3/4

Interface Ethernet3/4
--------------------------------
Port enable administrative configuration setting: enabled
Port enable operational state: enabled
Current bidirectional state: bidirectional
Current operational state: advertisement - Single neighbor detected
Message interval: 7
Timeout interval: 5

Entry 1
----------------
Expiration time: 39
Cache Device index: 1
Current neighbor state: bidirectional
Device ID: JAF1620ABAB
Port ID: Ethernet3/12
Neighbor echo 1 devices: JAF1617BACD
Neighbor echo 1 port: Ethernet3/4

Message interval: 15
Timeout interval: 5
CDP Device name: N7KB-SOUTH-AGG(JAF1620ABAB)


Last pkt send on: 400096, Aug 6 13:58:52 2014
Probe pkt send on: 400096, Aug 6 13:58:52 2014
Echo pkt send on: 395799, Aug 6 13:58:43 2014
Flush pkt send on: None.

Last pkt recv on: 740333, Aug 6 13:58:52 2014
Probe pkt recv on: 740333, Aug 6 13:58:52 2014
Echo pkt recv on: 730454, Aug 6 13:58:43 2014
Flush pkt recv on: None.

Deep pkt inspections done: None.
Mismatched if index found: None.
Deep pkt inspection drops: None.

使用以下命令驗證物理介面上的錯誤計數器，這些計數器可確定UDLD幀是否由於物理層硬體故障而被丟棄：

RTP-Agg1# show interface ethernet 4/1 | i error|CRC|discard|drop
 0 runts 0 giants 0 CRC/FCS 0 no buffer
 0 input error 0 short frame 0 overrun 0 underrun 0 ignored
 0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
 0 input with dribble 0 input discard
 0 output error 0 collision 0 deferred 0 late collision
 0 lost carrier 0 no carrier 0 babble 0 output discard

使用此命令檢查CPU使用率，該使用率確定CPU使用率高是否阻止UDLD幀的進程：

N7K-A# show system resources
Load average: 1 minute: 0.17 5 minutes: 0.25 15 minutes: 0.20
Processes : 1993 total, 1 running
CPU states : 0.18% user, 0.81% kernel, 98.99% idle 

有用的TAC資訊

本節說明在復原連結之前（如果情況允許）必須收集的輸出。這有助於向思科技術支援中心(TAC)提供診斷UDLD置於錯誤停用模式下的鏈路根本原因的最佳機會：

• show tech-support lacp all (如果故障介面是鏈路聚合控制協定(LACP) portchannel的成員)
• show tech-support module <x>  (其中x是檢測UDLD錯誤的模組)
• show tech-support ethpm
• show tech-support udld 
• show udld internal event-history errors 
• show udld internal event-history msgs | grep -a 3 -b 3 L2_RX_DATA
• show udld internal event-history ethernet <x/y>
• show log logfile | grep UDLD
• show log logfile | grep Ethernet<x/y> 
• show processes cpu history
• show interface ethernet <x/y>
• show hardware internal errors module <x>
• show interface counters errors module <x>

相關資訊

• 思科技術支援與下載