以下面這句話來開始本次故障處理過程：
“春天來了，又到了萬物復甦的季節，隨着溼潤季節的來臨，萬物開始騷動”
昨天下午客戶通過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，向網絡發送了大量的廣播包，是想幹啥？難道它已經開始騷動了麼？