“操作回溯”解決網絡故障

網絡環境

我校部分網絡架構和業務分布如圖1所示。

核心交換：銳捷S8606加AC擴展板，承載有線與無線業務。

匯聚交換：華為S7506，承載東西兩棟教學樓的交換業務，與核心交換機通過兩根萬兆光纖聚合鏈接,同時鏈接銳捷桌面云虛擬化系統，六臺服務器提供200點辦公虛擬化支持。華三S5500，鏈接 FTP，DHCP等服務器設備。

接入交換：兩棟教學樓樓層間部署華為S5130。

故障現象

早晨上班不久接到故障反饋：東教學樓A、B兩個用戶的桌面云打開速度慢，“開始”菜單無反應。按照描述，判斷是一般應用層軟件故障，絲毫沒有聯想到網絡問題。筆者登錄銳捷云桌面管理端，對A、B兩個賬戶執行關機，重置系統操作。

沒想到的是，在接下來的一個小時里，反映此癥狀的用戶增加到十幾人，范圍也擴大到兩棟教學樓的多個樓層。此時意識到可能是桌面云服務器故障，判斷此十幾個用戶很可能是集中在某一臺服務器上的。馬上登錄管理后臺查看，結果各服務器CPU和內存使用率一切正常，仔細排查后發現，這些用戶也并非集中在一臺服務器上，推翻了此前的判斷。

故障排查

與同事前往故障現場確認情況，有一典型辦公室六臺設備只有一臺使用正常，其余都出現打開應用軟件速度慢、無法關閉窗口情況。此時，意識到很可能是網絡故障。將焦點集中到接入層交換機上，懷疑私接設備造成環路。測試網絡連通率，在有故障的終端上Ping服務器，丟包率1-2%，未見較大異常。繼續登錄接入層交換機查看了CPU、風扇、溫度等狀態數據，皆一切正常。難道接入層設備沒有問題？于是，繼續登錄匯聚層交換機查看各項數據，果不其然，還是一切正常。

此時，兩棟教學樓的接入層和匯聚層檢查完畢，依然無法定位故障，難道問題出在核心交換機上？同時，用戶C反饋重要線索：今天FTP下載文件失敗。此用戶用的不是桌面云系統，而是實體機，側方印證了故障出現在網絡而非服務器上，很可能就出在銳捷S8606或者H3C 5500上。

圖1 網絡結構

圖2 查看聚合組工作狀況

隨著故障范圍縮小，決定變換思路，按照“操作回溯，現場還原”的原則，回憶之前對網絡所做的各種操作，特別是對核心交換機的操作。時值周一，回憶上周五的操作如下：

1.增加了一個POE交換機直連核心交換機，做了更改VLAN和端口操作。

2.一臺教室用服務器移機到H3C 5500上，也只在該交換機上增加了VLAN和端口。

無論如何也想不通，以上操作簡單可靠，很難隱藏危機。但是依然制定策略如下：Down掉核心交換連接POE交換機的接口；將H3C 5500的VLAN恢復，并將教室用服務器關機。

故障解決

正要行動之際，忽然有人提示：周五下午有工程師過來更換了核心交換機上的一個萬兆聚合模塊。馬上意識到問題可能出在這里，登錄并查看聚合組工作狀況，發現本應是2萬兆的速率居然是1萬兆（如圖2）。

嘗試刪除聚合組，并重新配置，發現速率正常了，故障解除。

后來得知，當初聚合模塊壞了一個，但是并未影響業務，工程師更換模塊后也沒有查看運行情況。猜測可能是新模塊不匹配或是一端設備將其Down掉了。

經驗總結

網絡故障最難纏的就是隱性故障，時通時斷或是時好時壞最撓頭。本次解決故障過程，從應用層反饋故障挖掘到網絡層誘因，又按照從低到高原則，從接入到核心逐層排查，最后沖刺階段按照“操作回溯”方法進行定位，最終解決了故障。