分公司兩臺核心的NE40路由器分別通過兩條MPLS VPN鏈路上聯到合肥的NE80核心路由器,而且這兩臺路由器之間也有通路,這樣的網絡結構保證了在出現一條上聯電路故障的時候,數據流量仍然可以從正常的鏈路流出。因此在很長時間內分公司DCN網絡都是相當穩定的,沒有大規模網絡阻塞事件的發生。
但是有一次當各個部門(不是所有部門)紛紛申告網絡不通的時候,有個奇怪的現象,就是Ping合肥的認證服務器是可以Ping通,但是網絡認證卻無法通過。經過重啟認證服務器、Web接入認證路由器,現象依舊。用Console口連接到有問題的NE40,配合合肥華為工程師排查故障,結果發現上聯端口不正常,發包多收包少。經過緊張的幾小時,嘗試各種方法一直無果之后,有識之士果斷將故障端口關閉,于是流量開始流向正常的路由器,各報障點開始恢復正常。其后過了很多天我們專門利用一個晚上更換了故障板卡,這個問題才得到真正解決,但是前面先恢復網絡再排查故障的經驗已經給我留下了深刻的印象。
類似NE40的雙上聯結構,分公司兩臺S8505也是采取的兩條鏈路分別上聯到一臺NE40。這兩個三層交換機下是分公司最核心的服務器與部分核心終端設備(如114臺席)。理論上來說它們不可能同時完全斷網,但是有一天中午卻忽然收到全部斷網告警,經現場檢查,有一臺8505的一塊主控板告警燈閃(其他狀態燈均正常),兩臺8505之間互聯光路Down,上聯的兩臺NE40分別有告警顯示兩個8505 neigbour掉線。如果說一臺8505設備故障掉線還好理解,但這卻無法解釋另一臺8505為何會離線。
經過漫長的故障排查,重啟設備、換上聯光纖口。將故障設備斷電,都不能有所改觀。最終由于偶然找到了故障的原因。原來這兩臺上聯鏈路配置有問題,每根互聯的光纖兩端不是同組IP地址,一端設備的互聯地址分別與對端非直連的另外一臺設備的互聯地址相對應了(地址形成交叉了),因此實際上這兩臺8505之間的互聯光路就成了關鍵因素,只要這條鏈路出問題,兩組交叉的地址都將無法互訪,而且這也就解釋了我們所見到的奇怪的現象。臨時解決辦法就是,重新建立互聯光路或電路,但最終還是需要修改錯誤的配置才能杜絕這個問題。回顧這次事件我們耗費了相當長的時間才恢復,對我們來說這實在是一次嚴重的教訓。
縣公司有兩臺核心路由器,但是與之前介紹的組網結構不同,這兩臺路由器一臺是負責縣城關的,另一臺是負責各個鄉鎮的。有一次晚上十一點多接到告警,說縣公司下各個鄉鎮支局動力監控信號時斷時續,經檢查,負責城關的路由器正常,但負責鄉鎮的路由器掉包嚴重。開始我們以為是互聯的光路或者電路松了,后來才發現并非如此,這兩臺路由器之間并不是直連的,它們之間有一臺二層交換機,而那臺二層交換機下有端口存在大量垃圾包,明顯是有機器中毒了。也正是由于這些病毒包阻塞了這條關鍵的互聯電路,才使得核心路由器也無法正常運作。
關閉掉問題端口以后,網絡恢復了正常。但是這個故障不得不令我們反思,如果我們組網的時候不是采取這種共享的方式,而是獨立的互聯電路,這個問題會不會避免呢?
綜合以上幾個例子,我們應該認識到,因為核心路由設備如此重要,所以在網絡組建的時候,我們就應該謹慎小心,避免潛在的各種問題。一旦真的發生了不可避免的各類故障,我們也沒必要慌神自亂陣腳,只要冷靜理智,對癥下藥,就不難解決各種問題。