編者按: 告警信息是IT 運維工作中所依賴的重要法寶,但在運維工作中也不要忘記故障之間的關聯性。筆者單位近期出現斷網,初期經分析告警信息發現存在MAC 地址漂移,但并未解決問題,之后才確定是環路問題所致。
筆者單位的辦公網最近出現了一次大范圍的故障,在解決故障的過程中,由于筆者水平有限,中間走了一些彎路。其中一些經驗和教訓,希望能給大家一點借鑒。
辦公網的拓撲比較簡單,主要是上互聯網和使用辦公軟件,上網方式是撥號上網,如圖1 所示。
故障第一天,有個別辦公室反映撥號自動掉線,重新撥號后恢復正常,判斷為個別現象,并未引起重視。第二天一早便有多人反映需要反復撥號或者直接撥號失敗,無法上網,出現了大范圍的問題。筆者隨即按照如下順序進行了故障排查。
1.之前出現過因個別無線路由器接反導致的網絡丟包,首先在現場電腦上查看arp-a,未發現異常IP 和MAC 地址。

圖1 單位網絡拓撲圖
2.詢問運營商撥號系統是否正常。運營商答復系統正常,未發現明顯異常。
3.終端機器Ping 豎 井交換機和網關丟包均在5%左右。
4.登錄豎井交換機的Web 管理界面查看交換機CPU 占用率和內存占用率,未發現明顯異常。
5.查看交換機告警。由于平時告警界面經常有一些“提示”類的告警信息,對網絡運行沒有什么影響。鑒于情況比較緊急,筆者直接將告警級別進行了排序,查看是否有重要告警。結果列出了許多“重要”級別告警,顯示出現了MAC地址漂移,如圖2 所示。
6.由于單位沒有處理這種故障的經驗,接下來筆者先查看了所有豎井接入交換機,均出現了MAC地址漂移的告警信息,并且每個交換機都出現了多個發生漂移的MAC 地址。筆者隨即對相應的MAC 地址終端進行了現場查看和比較,沒有發現存在相同MAC地址的終端或其他異常。筆者又將多個發生MAC 地址漂移的終端對應的交換機端口進行了shutdown 處理,問題仍未得到解決。
7.至此,故障處理陷入僵局。筆者經過思考后,重新在Web 界面查看交換機告警,按照時間順序進行排序。這時才發現,在“提示”級別的告警中,存在環路告警:

圖2 告警信息中出現MAC 地址漂移
#Apr 27 2020 14:39:22+08:00 2F-SW LBDT/4/PORTTRAP:OID 1.3.6.1.4.1.2011.5.25.174.3.3 Loop back exists on interface(53)GigabitEthernet0/0/49(none),loopback detec tion status:4,auto loop detection for trap only on VLAN 26.
8.查看所有豎井交換機,均出現環路告警。按照各個交換機的告警信息,除了豎井交換機C,其他均提示為上聯口存在Loopback。而交換機C 則指向自己下聯的擴展交換機C1,在C1 上Loopback 指向了房間R的端口。筆者立即shutdown 房間R 對應的端口,丟包隨即停止了,各撥號上網用戶恢復了正常,MAC 地址漂移告警也停止了。后經查看,房間R 因網線較多,自行接線時誤將上網的交換機接成了環路。
故障雖然消除了,但是通過這次經歷,筆者總結下來一些經驗和教訓:
查看交換機告警不能只關注“重要”或“緊急”的告警,同樣要關注“次要”或“提示”類的告警。
交換機告警是有關聯的,嚴重程度高的告警能夠表明相應的故障對業務的影響程度高,但是故障的解決卻依賴于對告警根源的追溯。這次MAC 地址漂移的告警之所以重要,是因為MAC 地址一旦發生頻繁漂移,勢必導致二層網絡的通信紊亂,但MAC地址漂移本身是“次生災害”,是另外一個故障導致的結果了。而另外一個故障已經反映在“提示”告警中了。
除了網管人員加強網絡知識的學習以外,為網絡增加監測和自動報警的功能也是一個較好的切入點。
下一步單位準備部署能夠實時監控網絡設備,并能自動報警的服務器,力爭做到提前發現,及時處理告警信息。