以下面这句话来开始本次故障处理过程：
“春天来了，又到了万物复苏的季节，随着湿润季节的来临，万物开始骚动”
昨天下午客户通过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，向网络发送了大量的广播包，是想干啥？难道它已经开始骚动了么？