某醫院院內網絡靜態鏈路聚合的非典型故障檢修1例

吳 丹，孟 娜

由于靜態鏈路聚合自身的缺陷造成交換機無法感知到光纖模塊已損壞，數據繼續經此鏈路轉發就會出現嚴重的網絡丟包現象，影響正常通信工作。該類非典型故障發生概率低且迷惑性強，信息工程人員很難及時判斷并排除故障，勢必會造成正常醫療工作的中斷。筆者將類似非典型網絡故障的排查方法、步驟做一梳理，以期為醫院信息網絡工作人員提供類似故障的處理經驗，并提示網絡維護人員應當結合設備的使用年限定期測試、更換臨界設備，預防類似故障再次發生［1］。

1 靜態鏈路聚合的架構及特點

筆者所在醫院院內網絡經歷過多次升級改造，形成了以2臺H3C 9512E為核心，使用第二代智能彈性架構技術（IRF2）的三層網絡架構［2-4］，各匯聚層連接核心層采用靜態鏈路聚合方式，主干網絡達到萬兆級別，經過多年運行始終保持平穩狀態。但由于靜態鏈路聚合自身的缺陷造成交換機無法感知已損壞的光纖模塊，數據繼續經此鏈路轉發會出現嚴重的網絡丟包現象，從而可能會造成內網通訊中斷。

與故障相關的網絡拓撲結構如圖1所示。（1）核心層：由2臺9512E交換機組成，各有兩塊主控業務板互為冗余，使用IRF2（第二代智能彈性構架技術）對外虛擬成1臺交換機，2臺核心之間通過心跳線相連用于同步配置和數據傳輸［3］。下連設備方式和地址分別是，9512E-1單鏈路連接服務器端匯聚層交換機，服務器地址132.X.X.200、132.X.2.88；鏈路1與鏈路2配置成靜態鏈路聚合模式聯通匯聚層與核心層［4］。（2）匯聚層：采用靜態鏈路聚合實現，匯聚組的創建、成員接口的加入完全由手工來配置，不允許系統自動添加或刪除。靜態聚合模式下的成員端口選中狀態不受網絡環境的影響，穩定性較高［5］。S5800-1上行端口號分別是：①鏈路1上Ten-GigabitEthernet 1/0/25，聚合組顯示XGE1/0/25；②鏈路2上Ten-GigabitEthernet 1/0/26，聚合組顯示XGE1/0/26。（3）接入層：樓層交換機作為接入層使用并按樓層劃分網段，上行單鏈路到S5800-1，下行連接客戶端。該次故障發生的保健樓7層包含客戶端地址136.X.7.7、136.X.7.17，8層包含客戶端地址136.X.8.7。

圖1 網絡拓撲結構

2 靜態鏈路聚合故障排查與分析

最早接到的報修電話是醫院保健樓7層護士站，反映地址為136.X.7.7的客戶端處理和保存醫囑過程緩慢。檢測發現136.X.7.7和136.X.7.17大量丟包，同時8層136.X.8.7客戶端無丟包現象。陸續接到保健樓其他樓層的報修電話反映同樣問題，再次確認8層客戶端業務運行正常，如圖2所示。

圖2 通信故障測試結果

由于正常工作時間各樓層之間數據訪問頻繁，分析故障節點在保健樓，與核心層、服務器無關，開始逐項排查。（1）排查保健樓7層交換機。7層客戶端之間訪問正常，實測上行端口通訊正常，排除故障可能。（2）排查保健樓廣播風暴。查看匯聚層S5800-1的CPU占用率和Ten-GigabitEthernet 1/0/25、Ten-GigabitEthernet 1/0/26端口廣播包的增長情況，排除此項可能。操作如下：①第一步：鍵入代碼display cpu，查看交換機CPU占用率。結果顯示CPU占用率低，不是廣播風暴發生時的情形。如圖3所示。②第二步：鍵入代碼 display interface Ten-GigabitEthernet 1/0/26，查看當前端口狀態。記錄broadcasts（廣播包）前面的數值以備比較。如圖4所示。③第三步：鍵入代碼reset counters interface Ten-GigabitEthernet 1/0/26，清零端口歷史數據。④第四步：鍵入代碼display interface Ten-GigabitEthernet 1/0/26，再次查看Ten-GigabitEthernet 1/0/26的端口狀態。比較前后狀態，發現廣播包數值增長緩慢，綜合判斷網絡中沒有發生廣播風暴。如圖5所示。（3）排查鏈路聚合組中單條鏈路故障。核心層到匯聚層是將鏈路1和鏈路2配置成靜態鏈路聚合實現聯通，正常情況下鏈路1與鏈路2互為冗余且兩條鏈路實現負載均衡，任意一條鏈路發生故障都不會造成網絡中斷，但是靜態鏈路聚合存在一個缺陷既兩端設備互相不交換信息，中間環節出現問題交換機無法感知，若此時繼續由故障鏈路轉發數據，就會有該故障發生的可能［6］。鍵入代碼display Link-aggregation verbose，查看S5800-1交換機的鏈路聚合組端口狀態。顯示兩個上行端口狀態正常，鏈路聚合狀態正常，如圖6所示。

圖3 CPU占用率

圖4 端口狀態

圖5 歷史數據清零后端口狀態

圖6 鏈路聚合狀態

3 故障排除

以上潛在故障點都排除以后，在S5800-1中鍵入命令關閉鏈路1上行端口Ten-GigabitEthernet 1/0/25，強制數據包經鏈路2轉發，此時監測到7層客戶端不再丟包，業務運行恢復正常［7］。同時檢測8層客戶端業務運行正常。對調Ten-GigabitEthernet 1/0/25和Ten-GigabitEthernet 1/0/26的光纖跳線，業務運行正常。確定Ten-GigabitEthernet 1/0/25端口的光纖模塊損壞，更換光纖模塊并啟用Ten-GigabitEthernet 1/0/25端口，故障排除［8］。后期檢測此模塊光通率低于正常值。