事情是这样的，公司内部技术部门一般属于一个局域网段，我们当然也不例外。如果部门内部人员太多但是又不方便用VLAN隔离的话，一般使用switch或者hub来进行隔离，这种设备是不隔离广播域的，hub甚至都不隔离冲突域，既然这样，事故很容易就发生了。 我和部门其它3个人共同接在一个hub上，D-Link的设备，可能是低端的switch，不管它了！不知道怎么回事，我们这里的这个hub总是莫名奇妙的出现问题，一下子我们4人都无法正常联网。起初是以为设备坏了，后来网管给换了一台新的，心想这下子可好了，然而没过几天，同样的事故又发生了，又一次叫来网管，折腾了好一阵子，未果！ 下意识感觉到并不是硬件出了问题，就算是上行网线出了问题，网络也不会瞬间挂掉，然后莫名其妙的就好了，因此我感觉是协议出了问题，只可惜网络协议在最开始都是针对最简单的情况，然后大部分的特性都是事后修补的，因此排查问题特别不便，当然这也给了那些CCIE们黄金铸成的饭碗... 还是抓包工具出场比较好，在网络状况恶化的时候，大量的广播包和stp包进入本地主机，很显然，出现了广播风暴。到底在哪里出了风暴呢？为何这种风暴只影响我们4个人呢？上个世纪，为了应对广播风暴，人们提出了STP协议，也就是生成树协议，这个协议有效的防止了广播风暴，原理十分简单，那就是将环路剪断。然而还有一个事实，那就是交换机可以选择不开启STP功能... 哪个交换机会不开启STP，网管难道这么X吗？另外，又有哪个交换机会一会儿开启又一会儿关闭STP呢？...最终，发现把我的虚拟机关掉，网络就好了，开启虚拟机，网络就疯掉了。 原来是虚拟机造成的，这下就好办了，那就是想办法重现问题。于是在家里的几台机器上进行试验，没有任何问题...到了公司，一开虚拟机就又挂了。虚拟机里面到底有什么？ 原来，为了测试OpenVPN，我在虚拟机里面部署了一个bridge，然后将两块虚拟网卡都加入了这个bridge，而这两块虚拟网卡又都是bridge模式的(VMWare中bridge，host-only，nat三种网络中的一种)，要命的是，两块虚拟网卡bridge到了物理机器的同一块物理网卡上，更要命的是，虚拟机中创建的bridge没有开启STP协议！！！ 这样，在虚拟机网桥的两块虚拟网卡和物理主机的那一块物理网卡之间就构成了一个环，广播会从一个物理网卡进入，然后再从物理网卡绕出来... 那为何仅仅影响我们4个人呢？实际上我们部门不同办公区域之间是通过“更高级”的交换机来连接的，这种设备本身就是抑制广播风暴的能力，请注意，所谓广播风暴并不仅仅是环路引起的。因此我们4个人的这个小设备如果出了问题，问题是很难扩散的，但是我们的这个小设备就没有那么厉害了，它很便宜，也很弱小，本人虚拟机只要一开，其它3个人以及小小交换机就都能了活靶子，交换机哪还有处理其它正常数据包的机会啊！ 本次事故的图示如下，以备以后再出现类似问题时排错(红色的粗线表示了一个环路)：
对这个事情做一下总结是有意义的，排查网络问题有几步： 1.先看线缆是不是有问题，比如线皮破损，导体外露，设备掉电等； 2.看直连机器是否畅通； 3.排除软件问题，比如配置失误，先看链路层配置，再看IP层配置 4.玩虚拟机的时候，一定要慎重网络方面的配置，虽然虚拟机是虚拟的，但是它实质上在别人看来是完全真实的 虽然本次事件最终是软件问题导致的，问题深深隐藏在虚拟机中，然而排查问题的时候，切忌先从软件开始排查。 另外，本次事件还有一个疑点，幕后的神秘家伙还没有被揪出来，谁那么神秘呢？原来，当广播风暴爆发的时候，就会有一台神秘的机器(IP是192.168.0.251，我们网段的IP是192.168.0.0/24)发出大量的STP包，是root通告以及拓扑变更包，我们老大问了一圈都问不出这台机器在哪，也没有人知道它在哪里，它确实是存在的，能ping通，还开着telnet 23端口...它在哪？晚上怎么也睡不着，后来感觉正是它探测出了广播风暴，然后发来STP包，希望下游交换机赶紧剪枝！它实际上应该是一台管理者或者监督者，如果我没有猜错，它应该记录了大量的审计记录，然而我可能没有权限证实这一点。