網絡故障的幕後黑手-------記隱藏在角落中的那臺TP-LINK

如下面這句話來開始本次故障處理過程：

     「春天來了，又到了萬物復甦的季節，隨着溼潤季節的來臨，萬物開始騷動」

昨天下午客戶經過QQ發來幾張截圖，上面顯示客戶端PING本身的網關，延時抖動大不說，有時還時不時的丟包。很明顯客戶的網絡出現了問題！

爲了排查故障，我今天一大早就趕到了現場。

客戶的網絡架構相對來講比較簡單，整網的網關都在覈心上，核心下聯了幾臺匯聚交換機。

我登陸了一臺問題客戶端所在的匯聚交換機，先經過sh ip int bri查看了一下該交換機上全部的up接口，而後經過sh inter <接口>查看每一個接口的狀態及數據信息，在查看的過程當中發現其中有四個接口入方向上沒有任何流量，而出方向上的流量卻很大，有的流量能達到10幾M，這是什麼狀況呢？

爲了進一步排查，我決定在這四個接口上進行抓包，鏈接好以後，當我打開wireshark，數據撲面而來，瞬間就達到了10幾萬，緊接着達到20萬、30萬……中止抓包，進行分析，發現幾乎全部的數據都是以下圖所示：

居然全是廣播流量，點開其中一條

經過上圖能夠看到這些包的源MAC地址是3883.45c6.22a4。知道了MAC地址就好說了。

再次經過命令查看，發現這個MAC地址是從另外一幢樓過來的，查看文檔，發現另外一幢樓的交換機也是一臺可網管的交換機，謝天謝地！若是是傻瓜的交換機，估計本集到這裏就已經結束了。登陸那臺交換機，定位這個MAC地址，發現是從E1/0/30口上來的。到這裏我只能把全部的情緒都發泄在這個接口上了！用戶說直接shutdown，和我想的同樣。

關閉這個接口以後，我再次抓包，發現此時，接口的流量正常了！再也不是撲面而來廣播包。

找到以前上報故障的幾個客戶端，經過PING檢測，發現此時延遲正常，沒有丟包的現象發生；另外有客戶說打開網頁都有問題，咱們打開網頁，打開視頻網站，網頁打開正常，視頻播放流暢。至此，故障解決。

春天來了，那臺不甘寂寞的TP-LINK，向網絡發送了大量的廣播包，是想幹啥？難道它已經開始騷動了麼？