简介
本文档介绍可导致损坏的数据帧注入到统一计算系统(UCS)交换矩阵(由接口循环冗余校验(CRC)或帧校验序列(FCS)错误计数器识别)的关键软件缺陷。
注意：本文档不介绍如何隔离CRC注入点。
背景信息
在UCS环境中，CRC错误可能会产生很大影响。必须优先处理此类错误原因的隔离和缓解。
影响取决于问题发生的点，问题可能扩展到多个机箱并影响以太网和存储连接。
虽然物理组件故障(尤其是电缆和小型可插拔(SFP))是最常见的原因，但已知软件缺陷也可能导致CRC错误。
这些缺陷导致不同组件之间的信号强度较低，从而导致帧损坏。
您可以参考的一个关键概念是眼高，它是测量物理层组件之间信号完整性的指标。如果信号电平降到特定电平以下（不同组件），则发送或接收的帧可能会损坏。
思科建议您已审查FlexPod常见性能问题，特别是帧和丢包问题，以确定UCS交换矩阵和/或上游交换机中未完成CRC错误的来源。
本文档适用于FlexPod部署，但所提及的部分适用于非FlexPod UCS环境。
CRC相关缺陷的指示
如果您在UCS环境中有Twinax布线，则更可能受到一个或多个这些缺陷的影响，因为大多数缺陷都用于基于Twinax的布线。
只有光缆的环境仍然可能遇到问题，因为适配器和UCS I/O模块(IOM)之间可以插入CRC错误。 但是，这仅限于特定服务器，在出现上行链路或服务器端口问题时不会影响多个服务器或机箱。
如果UCS Manager中端口的禁用/启用似乎停止了接口错误，而没有进一步的操作（如电缆交换或重新拔插），则必须进一步检查，以验证软件缺陷是否是问题的根本原因。
如果在端口突然摆动/重新启动后发现CRC错误，则这些缺陷可能是原因。
用于检验眼高的命令
CRC相关软件缺陷的关键指示是一个或多个端口的低眼高值。
用于检查此情况的常用命令有：
基于Nexus 5500的交换机：
show hardware internal carmel eye
UCS 6200交换矩阵互联：
connect nxos a
show hardware internal carmel eye
exit
connect nxos b
show hardware internal carmel eye
exit
显示良好眼高(200 mv)的输出示例：
UCSB-5-A(nxos)# show hardware internal carmel eye
+-------+------------+-------------+------------+----------------------------+--+--+--+--+--+--+--+--+--+--+
| Port | Eye Height | Eye Width | Raw values | Time measured |St|20|21|22|23|24|25|26|2E|2F|
+-------+------------+-------------+------------+----------------------------+--+--+--+--+--+--+--+--+--+--+
Eth 1/1 | 200 mv | 796 mUI | 40/ 33 | 08/31/2016 16:48:52.345248 |a9|ee|82|00|00|6e|82|00|88|00|
fi0 | 200 mv | 843 mUI | 40/ 36 | 08/31/2016 16:48:52.350360 |00|00|00|00|00|00|00|00|00|00|
fi1 | 200 mv | 859 mUI | 40/ 37 | 08/31/2016 16:48:52.355470 |00|00|00|00|00|00|00|00|00|00|
在这些平台上，如果值为：
- 在50mV以下，发现它会触发CRC错误
- 50 - 100mV，它可能导致CRC错误并建议缓解
- > 100 mV，它不能导致CRC错误
以上命令不适用于6332、6454或6324交换矩阵互联
UCS 2200 IOM模块：
connect local-mgmt a or connect local-mgmt b
connect iom x
show platform software woodside sts (Note: The HI number/s for the servers that you need to check)
dbgexec woo
kr_geteye HIxx
Ctrl-C to exit dbgexec mode
显示良好眼高(125 mV)的输出示例：
woo> kr_geteye HI31
[serdes] reg: 64/40h = 42ch
check_kr_status: HI31: up (kr_retries=0)
sent SPICO interrupt(20, 0, 49)
Vertical eye result 0x14
sent SPICO interrupt(20, 0, 49)
Horizontal eye result 0x28
HI31: 125.0 mV, 0.6250 UI (NORM)
UCS 2300 IOM模块：
connect local-mgmt a or connect local-mgmt b
connect iom x
show platform software tiburon sts (Note the HI number/s for the servers you need to check)
dbgexec tib
kr_geteye 0 HIxx
Ctrl-C to exit dbgexec mode
显示良好眼高(156 mv)的输出示例：
tib> kr_geteye 0 HI31
Start eye measurement HI31...
bottom: -73.5 (mV), top: 82.7 (mV), height: 156.2 (mV)
left: -0.34 (UI), right: 0.33 (UI), width: 0.69 (UI)
total time = 0.119456 sec
在这些平台上，如果高度值为：
- 在90 mV以下，发现它会触发CRC错误
- > 90 mV，它不能触发CRC错误
缺陷
交换矩阵互联
在交换矩阵互联端口（例如上行链路和服务器端口）上可以看到此缺陷。
它已在UCS基础设施2.2(3a)中修复，有关其他固定版本，请参阅漏洞搜索工具。
CSCuw36398观察铜缆上的CRC错误
在交换矩阵互联端口（例如上行链路和服务器端口）上发现此缺陷
它固定在UCS基础设施2.2(7b)中。 有关其他固定版本，请参阅漏洞搜索工具。
IOM和适配器
IOM主机接口(HIF)和适配器背板接口之间出现此缺陷。
此后发现这可能是由机箱背板问题引起的。如果发现此问题，请向思科TAC提交服务请求。
IOM HIF和适配器之间会出现此缺陷，这会影响各个服务器。
正在调查中。
C系列
在独立C系列固件2.0(9c)中修复。 有关其他固定版本，请参阅漏洞搜索工具。
此Bug的触发条件与通常的看法相反，即活动Twinax由于其活动电源传输而不太可能导致CRC问题。
Nexus 5500
虽然严格来说不是UCS Bug，但由于Nexus 55xx上游的普及，UCS设置中仍经常出现此漏洞。有关固定版本的详细信息，请参阅漏洞搜索工具。
解决方法/缓解
有关具体详细信息，请参阅每个Bug的版本说明，但如果您发现眼睛高度较低的证据，那么关闭/不关闭端口是合理的。
如果出现IOM/适配器眼高缺陷，可以重置接口中的DCE。如果适用，导航至Server > Adapter > DCE Interface > Reset Connectivityy。
然后，必须检查输出，以查看眼睛高度是否已增加到良好值，以及CRC计数器是否已不再增加。
需要多个襟翼（通常最多5个）来充分增加眼高。
如果在多次链路抖动后眼高无法恢复，则组件可能出现硬件故障。
当您摆动端口时，请注意，这可能会触发UCS Manager的浅层发现。
在正常情况下，浅层发现并不影响数据平面，但是，已知的缺陷会影响B200-M4刀片(有关最常见的缺陷，请参阅CSCut61527)。浅层发现可以转变为深层发现，从而触发主机操作系统重启。
思科建议您查看UCS Manager版本的版本说明，了解其他适用缺陷。
除手动端口摆动作为被动恢复步骤外，UCS Manager 2.2(4)及更高版本中的UCS基于策略的端口错误处理还可用于在出现CRC错误时禁用NIF端口。虽然此操作可以快速限制CRC错误的影响，但可能会中断流量，因此默认情况下不启用，如果启用，则必须小心。
UCS Manager会为CRC错误生成故障，并且此类故障可通过XML API或简单网络管理协议(SNMP)进行监控。
反馈