簡介
本檔案將說明一些主要軟體缺陷，這些缺陷可能會導致損毀資料訊框注入整合運算系統(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)中修復。 請參閱Bug Search Tool以取得其他修正版本。
IOM和介面卡
在IOM主機介面(HIF)和介面卡背板介面之間觀察到此缺陷。
後來發現這可能是由機箱底板問題造成的。如果您觀察到此問題，請與Cisco TAC開啟服務請求。
在IOM HIF和介面卡之間可看到此缺陷，這將影響單個伺服器。
目前正在調查。
C系列
已在獨立C系列韌體2.0(9c)中修復。 請參閱Bug Search Tool以取得其他修正版本。
此錯誤的觸發條件與通常的判斷相反，即活動Twinax由於其活動電源傳輸而不太可能引起CRC問題。
Nexus 5500
雖然嚴格來說它不是UCS漏洞，但由於Nexus 55xx上游的盛行，在UCS設定中仍經常出現該漏洞。請參閱Bug Search Tool以瞭解固定版本的詳細資訊。
解決方法/緩解
如需特定詳細資訊，請參閱每個錯誤的版本說明，但如果您發現低眼睛高度的證據，則連線埠關閉/不關閉是合理的。
在IOM/介面卡眼睛高度缺陷的情況下，可以重置介面中的DCE。根據情況導航到Server > Adapter > DCE Interface > Reset Connectivity。
然後，必須檢查輸出，以檢視「眼睛高度」是否已增加至正常值，以及CRC計數器是否不再增加。
需要多個翼（通常高達5個）以充分增加眼睛高度。
如果多次鏈路擺動後眼睛高度沒有恢復，則可能是元件的硬體故障。
擺動埠時，請注意，這可能會觸發UCS Manager的淺層發現。
正常情況下的淺層發現不是影響資料平面，但是，存在影響B200-M4刀片的已知缺陷(最常見的缺陷請參閱CSCut61527)。淺層發現可以轉變為深度發現，從而觸發主機作業系統重新啟動。
思科建議您檢視UCS Manager版本的發行說明，瞭解其他適用的缺陷。
除了作為被動恢復步驟的手動埠抖動外，UCS Manager 2.2(4)及更高版本中的UCS基於策略的埠錯誤處理還可用於在出現CRC錯誤時禁用NIF埠。雖然此類操作可以快速限制CRC錯誤的影響，但它可能會中斷通訊流，因此預設情況下不會啟用它，如果啟用它，請務必小心。
UCS Manager會為CRC錯誤生成故障，此類故障可通過XML API或簡單網路管理協定(SNMP)進行監控。
意見