告警信息莫忽視

編者按： 告警信息是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地址漂移本身是“次生災害”，是另外一個故障導致的結果了。而另外一個故障已經反映在“提示”告警中了。

除了網管人員加強網絡知識的學習以外，為網絡增加監測和自動報警的功能也是一個較好的切入點。

下一步單位準備部署能夠實時監控網絡設備，并能自動報警的服務器，力爭做到提前發現，及時處理告警信息。