用交換機端口信息排故障

在網絡運維中，經常要查看交換機端口，一個看端口狀態，一個看端口信息。端口信息中含有大量的數據信息，包括狀態、地址、帶寬、輸入輸出包、廣播包、錯誤包、CRC包等。認真觀察、分析這些數據信息，有助于解決網絡故障。本文介紹兩個案例，就是通過查看交換機端口信息發現問題，從而找到相應解決方案。

注：本文使用的命令是銳捷交換機的命令，其他品牌的交換機，請使用對應的命令。

故障一：某棟樓匯聚斷網，重啟后2個小時后又斷網，問題是廣播包巨大。

一天早上剛上班，就發現學校的計電樓報斷網了。馬上查看網絡設備監控流量圖，發現確實網絡斷了，且從昨天起已經斷網并自動回復了幾次（如圖1）。

圖1 計電樓流量圖

圖2 匯聚交換機端口13的信息

因已經斷網無法遠程操作，于是讓學院的人把匯聚交換機重啟，重啟后網絡正常，可不到2個小時又斷網了。查看流量圖未發現匯聚交換機流量異常，各端口流量也正常。再次重啟后進入匯聚交換機查看，以前此棟樓有過ARP包異常，sh nfpp arp-guard hosts未發現異常，sh cpu、 sh memory 也正常，sh interfaces gigabitEthernet一個個端口查看，感覺1/13端口廣播包有些異常，廣播數據包感覺有些大（如圖2）。 然后sh int counters summary，發現13及14口的InBroadcastPkts數據比其他端口至少多出一位（如圖3）。

當時正在下大雨，不想到現場抓包，馬上把13、14口關閉。觀察中，到下午14點上班時，計電樓整體網絡正常，因為13、14端口各接一層樓的2臺接入交換機，有近200個信息點，不可能關閉太久。據端口信息判斷故障原因是廣播包太多，而此樓的交換機未做廣播網暴控制。交換機收到廣播、未注冊組播、未知單播3種報文后都會做廣播處理，如果端口沒有開啟風暴控制，端口對收到廣播包的速率將不做限制。當局域網中存在過量這3種數據流時，就會導致網絡變慢和報文傳輸超時機率大大增加，這便是廣播風暴。

廣播風暴控制是通過控制端口接收廣播包的速率，將只允許通過所設定帶寬、每秒允許通過的報文數或者每秒允許通過的千比特數的數據流，超出限定范圍部分的數據流將被丟棄，直到數據流恢復正常，從而避免形成網絡風暴。于是在13、14端口增加使命命令stormcontrol broadcast level 2（銳捷交換機默認是1%），然后把端口打開，再迅速進入相應的接入交換機，對所有用戶端口也增加stormcontrol broadcast level 2，通過 sh in gi及 sh in gi co su不斷查看匯聚交換機的13、14端口只信息，廣播包還在增長中，但速度不快，到下班時計電樓的網絡都是正常的，第二天也是正常的。但感覺stormcontrol broadcast level 2有些太小，把14口改成level 5，隨后幾天繼續觀察，再沒有斷網，用戶也能正常上網。雖然不知道是哪里是什么原因產生了大量的廣播包，但通過廣播風暴控制將此次斷網故障解決了。

圖3 匯聚交換機各端口的進出數據統計

圖4 端口信息顯示有大量的錯誤包及CRC包

故障二：某校區一辦公樓的用戶總是斷網，而此交換機其他端口用戶工作正常，只有一個端口上有大量的錯誤包

學校另一個校區一個新裝修的辦公室內多個用戶反映網絡總是中斷，Ping網關時通時斷，延時大。重啟小交換機問題沒有解決，電腦直接接信息點后還是有網絡中斷現象，而其他辦公室的網絡都是正常的。初步判斷是信息點、網線或相應交換機端口有問題。

進入相應交換機查看，sh cpu、sh memor正常，用 show interface，show interface counter查看，發現對應的端口信息上有大量錯誤包及CRC包（如圖4）。CRC錯包一般是接口、雙工異常、時鐘與MTU中否一致、物理鏈路問題造成的，出現CRC錯包后，首先要排除物理鏈路的影響。

重新撥插了水晶頭，再測試還是有問題，找一個正常端口把有問題的網線插上問題依舊，判斷是網線有問題。把根網線2頭的水晶頭重做并測試正常后，插入交換機，并換到一個正常的交換機端口，再次測試，Ping網關正常，電腦打開網頁也正常了，在交換機新的端口信息上沒有出現錯誤包了。故障原因是此辦公室是新裝修的，網線的水晶頭未做好造成的。

經驗總結

交換機的端口信息提供了大量的信息，包括括狀態、地址、帶寬、輸入輸出包、廣播包、錯誤包、CRC包等，認真觀察、分析這些數據信息，有助于解決網絡故障。第一個案例是發現某些端口有大量的廣播包，通過風暴控制來抑制，從而保障網絡正常運行。第二個案例是發現某個端口有大量的錯誤包、CRC包，通過交叉替換發現是網線水晶頭有問題，重做水晶頭解決問題。在網絡運維中經常要查看交換機端口信息，通過分析這些信息有助于解決網絡故障。