排除故障在连结交换机的单向链路检测错误

简介

本文描述如何排除故障在Cisco连结7000系列交换机的单向链路检测(UDLD)错误消息。

先决条件

要求

思科建议您有这些主题基础知识：

• 思科连结操作系统(NX-OS)
• 基本UDLD操作 

使用的组件

本文档中的信息基于以下软件和硬件版本：

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

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

背景信息 

在UDLD检测进程中的端口交换UDLD信息包，包括创建人交换机ID和创建人端口ID。一旦UDLD信息包接收，交换机响应对等体交换机ID和端口ID回到对等体。一旦交换机交换echo数据包，一双向关系形成。 

当交换机不获得从其UDLD对等体的预计信息UDLD错误情况存在。 

本文描述这些UDLD错误情况和如何排除故障他们：

• 空响应
• 传送接收(Tx RX)环路
• UNI方向
• 邻接不匹配
• UDLD帧的突然的停止 

UDLD错误情况

此部分描述UDLD错误情况和一些可能原因的多种类型。

倒空响应 

当switch-a接收从switch-b无switch-a交换机ID和端口ID的预计响应的时，一UDLD帧此情况存在。 

当空响应检测时， 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)

这是此情况的一些可能的原因

• 因为不接收从switch-a的UDLD帧UDLD双向关系计时了switch-b。
  
  
• switch-b接收从switch-a的UDLD帧，但是没有处理他们。
  
  
• switch-a没有发送UDLD帧对switch-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)

这是此情况的一些可能的原因：

• 也许有不正确配线或物理媒介问题。
  
  
• 中间设备反射帧回到发送的端口。

邻接不匹配 

此情况存在，当波尔特switch-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的端口是成员端口更改陈述Port-Channel的成员。
  
  
• 有在形成双向关系的两个端口之间的中间设备。

UDLD帧的突然的停止

形成了一双向关系时的此情况存在，当端口不接收UDLD帧在超时间隔(50秒期间默认情况下)。 

当此情况检测时， UDLD进行这些操作：

模式	操作
正常模式	UDLD指示端口如未确定，并且端口继续作用符合其生成树端口港口状态
积极模式	错误-禁止的端口

排除故障UDLD错误情况

此部分描述您应该完成的通用故障排除步骤，如果遇到UDLD Error-Disabled端口。 

因为UDLD错误指示物理层故障，排除故障在物理层是适当的。当UDLD错误消息被遇到时，请考虑这些问题：

• 错误是否仍然存在，如果小的尺寸可插入的收发器(SFP)替换？
  
  
• 如果电缆被替换，错误是否仍然存在？
  
  
• 如果连接被切换对交换机的，一个不同的物理端口错误是否仍然存在？

有用的命令

请使用此命令为了恢复被放置了到使错误停止的模式由UDLD的所有端口：

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信息

此部分描述您应该收集的输出，在您恢复链路(前如果情况permit)为了提供Cisco技术支持中心(TAC)最好的机会诊断被放置到使错误停止模式的链路的根本原因由UDLD ：

• show tech-support lacp全部(如果失败的接口是链路汇聚控制协议(LACP) portchannel的成员)
• show tech-support模块<x> (其中x是UDLD错误检测)的模块
• show tech-support ethpm
• show tech-support udld 
• show udld内部事件历史记录错误 
• show udld内部事件历史记录信息|grep - 3 - b 3 L2_RX_DATA
• show udld内部事件历史记录以太网<x/y>
• show log日志文件|grep UDLD
• show log日志文件|grep Ethernet<x/y> 
• show processes cpu历史记录
• show interface ethernet <x/y>
• show hardware内部错误模块<x>
• show interface计数器错误模块<x>