以太網交換機丟包故障處理案例

客戶有兩條接入互聯網線路（路由器A和路由器B），我們設網關分別為1.1.1.1和2.2.2.2，拓撲如下，兩個網段（1.1.1.0 和 2.2.2.0）的主機都接到這兩個交換機（交換機A和交換機B）上。突然有一天，他們發現1網段的主機A（其實是一台網關設備）有巨大的丟包，而主機B卻很正常。因此懷疑是主機A出現了故障。

圖1
解決過程
首先我們不著急解決問題，先思考下在這種網絡環境下，那些原因會引發以太口丟包呢？從下往上看：第一，可能由於硬件問題導致接口上錯誤的幀很多而引起丟包，比如說網線頭子沒做好，接口故障等；第二，最近流行的ARP病毒也可能引起以太網陣發性的丟包或者完全癱瘓；第三，不排除交換機出現故障導致丟包；第四，廣播風暴，類似一種ARP攻擊；第五，IP地址有人無意或者惡意亂改造成暫時的中斷；第六，其他——什麼都想完了我也沒招了。
那麼我們就一個一個來排查。首先，接上主機A的配置口，我們發現設備並沒有提示有任何的IP衝突或者疑似的ARP攻擊信息。那麼我們可以排除第二和第五種可能。第二步，show interface，我們發現主機A的接口上並沒有出現CRC錯誤。我們知道如果網線有問題，或者幹擾非常強的時候，接口上會有很多CRC校驗的錯誤——那麼我們也排除了第一種可能。而我們對比正常接口與不正常接口他們收到的廣播包數量，也可以看到，丟包並不是廣播風暴引起的。
那麼會不會是交換機本身有問題呢？如果是這樣的話，那麼2.2.2.0段的電腦也應該很慢或者根本無法上網才對啊，但是他們沒有異常。而兩個主機互ping是不丟包的！或者交換機的單個端口有問題呢？那麼我們來做個測試：換了n多個端口還是丟包？那麼就不是交換機的問題，排除可能性第三。
最鬱悶的事情就是這樣了：全排除完了居然還有問題。好吧，我們再來看看第六種可能性：其他兩個字就包括了很多內容了，比如說線路有環，外線不通（當然這裏沒有這個問題），設備不兼容（用著用著突然就出問題一般不能是兼容性問題）等等。
那麼還是看我的：我們注意到在換端口的時候，拔掉路由器B的網線後，居然還能看到他的mac地址在交換機上繼續使用。那麼問題可能就出在這裏。
我們來重現一下現象：首先在主機A上，show arp 查看1.1.1.1對應的mac地址，假設它是AAAA.AAAA.AAAA。然後在交換機A上show arl來找到該mac地址對應的端口0/25（但是和客戶確認後我們知道這個端口應該是路由器A(2.2.2.2)）。那麼我們可以認為，路由器B（1.1.1.1）現在是在交換機A的25口掛著的。那麼我們把25口的網線拔掉，驚訝的發現，主機A居然還可以通路由器B，而且不丟包了！再到交換機A上，show arl，AAAA.AAAA.AAAA居然出現在了交換機B的上聯端口上，這說明，交換機B上麵掛著的才是真正的路由器B。而插上路由器A後，主機A又開始丟包。
解決方法與總結
水落石出。原來故障是這樣出現的：網通給客戶提供的兩條鏈路是在局端同一台設備的同一個接口上的，這樣一來，路由器A和路由器B即是同一台路由器，所以他們的mac地址相同。而客戶將兩條線路分別接到不同的交換機上。我們知道運行了STP的交換機如果同時從兩個端口收到相同的mac以後它會認為鏈路有環而將其中一條鏈路阻塞掉，因此，主機A的數據是通過2.2.2.2走的，這時引起的丟包現象就是局端設備轉發機製的問題了，我們避過不論。
至於解決，可以這麼處理：把主機A直接接到交換機B上，這樣一來，由於STP是由開銷來計算阻塞哪個端口，因此交換機隻會阻塞他們之間的端口，這時主機A同樣可以通過相同的mac來找到正確的網關。