广播风暴来袭

领导要给服务器做双网卡bond，无奈之下，做了双网卡绑定。可以参看我bond脚本。当时写脚本时，要填入参数，用salt运行时，添加参数比较麻烦，就进行修改了一下。脚本内自己获取一下网卡参数。

   环境是  两个网卡做bond mode=1   

           服务器上安装的是openstack 组件，一台机器上跑10个vm

上周给10台机器做了一次bond，当时及时的ipmitool reset 机器，没出现什么问题。

有搞openstack的同事告诉我，尽量不要重启服务器，这样的话openstack的服务需要重新检查，当时也没多想，就测试了一下。

昨晚又折腾了10台机器，一次性salt执行，玩过salt的，你懂得。

小case，分分钟的事。 当时没重启系统。过了半小时后，觉的重启系统比较保险，就批量重启了一下。

今天网络的同事发了封邮件，当时没太在意，大体内容如下

昨天晚上11:40到12点15之间，机房产生告警。经过核查，没有发现网络设备的异常log和告警，但可以查看到某网段的服务器端口在此期间均出现流量峰值，从交换机到网段的端口满载，接口统计有大量的广播和组播报文，且上下行流量比例差距较大。监控产生的告警应该都和这个高度相关。告警监控的服务器在某网段，端口会被广播报文拥塞，从而产生大量告警及误告警同时存在。

  不确定广播风暴产生的源，也不确定广播风暴产生的原因 

当时觉得这事有些诡异，没太在意。查到了产生广播风暴的机架和交换机位置。突然提醒了我。

我搞出了一波广播风暴。我日。

分析一下广播风暴的原因：双网口bond  原机器是单网口，非得增加稳定性，搞网口bond。openstack br100原基于eth0 bond之后就变成了bond0，bond之后不重启机器，100台vm无法连接到br100，发送大量广播，这个广播被路由传送出去，就形成了广播风暴。  有什么问题，请不吝赐教。

在bond成功之后，重启服务器就消除了广播。

主要问题是 玩openstack的guys  对网络不是特别熟，而我们只是一个使用者，对openstack没有掌控的权力和能力。出现这个问题，算是正常的。幸亏是在晚上弄的，要是白天，影响生产就不好了。

不论要玩什么，首先要有掌控的能力，再次是最这个东西的原理做深刻的理解，不要只是在表面上。