关于未知单播泛洪故障以及最佳实践

一、故障背景

      一位开发同事用办公后台的测试网段的用一台服务器写了个python脚本持续的向办公前台他自己的PC发udp包，一段时间后这个udp流量打到了整个办公前台二层的接入交换机上，使得整个二层瘫痪。

二、故障原因

       由于测试发出的udp的包比较大，又是循环发送，导致这位开发同事的PC很快被打死，但是udp包是无连接的概念，因此依然会继续发送，一段时间后办公前台的汇聚交换机上这台pc的mac地址先老化，而ARP并未老化。这时这些udp流量达到办公前台汇聚后，可以查arp表查到对应的mac地址，但此时查mac表并找不到对应的接口，那么交换机默认会将这些udp流量向汇聚交换机的所有接口去泛洪，形成未知单播泛洪。由于我们办公前台汇聚用的是cisco4507，其引擎和板卡比较老，整块板卡16个port共享4G背板，等于在所有口流量都被打满的情况下，每个口只能抗250M，而这个UDP流量又比较大，所以导致这台45的所有下联口流量全部被打满，最终整个二层处于瘫痪状态。当然具体泛洪有多种情况，后面部分会详细分析。

三、未知单播泛洪的原理分析

下面通过一组实验来分析未知单播泛洪的原理：

     如上图是我们实验的拓扑，SW1为汇聚交换机，三个网段的网关在SW1上，SW2-SW4接入交换机，交换机互联之间都是trunk。主机共四台，分别位于vlan11、vlan22、vlan33，其中处于vlan 22的有两台主机。实验前，用主机1.1.1.1长ping主机2.2.2.2。

1、未知单播泛洪产生

      将主机2.2.2.2的网线拔掉，此时SW2上2.2.2.2的mac地址消失，汇聚交换机SW1上2.2.2.2的mac地址在mac的老化时间后也消失，但2.2.2.2的arp表象还在（mac、arp表老化时间不同型号的交换机默认时间不同，我们实验中所用交换机的mac和arp的aging time分别为300秒和4小时）。此时未知单播将在SW1向所有接口泛洪。通过对相应接口的抓包我们可以看到泛洪流量如下：

2、哪些接口收到泛洪流量

通过抓包并分析得出以下结论：

• 汇聚交换机SW1由于下联口都是trunk口且没有做任何vlan的修剪，导致所有下联口都会有泛洪流量出去，所以SW1上的三个下联口都可以抓到泛洪流量；
• 接入交换机上，如果有和泛洪流量目的地址同一vlan的才会接受这个泛洪流量，所以SW2、SW3接收了这个泛洪流量，而SW4则没有接收这个流量，如果在SW4上增加vlan 22的话，SW4也会接收到泛洪流量。
• 主机2.2.2.3由于和2.2.2.2处于同一vlan，所以主机2.2.2.3也会收到这个流量，但主机3.3.3.3处于vlan33，不会收到这个流量。

四、出现未知单播泛洪的应急方案

      在监控中发现某汇聚交换机的接口下均出现大量的流量，这时候就要考虑是否出现未知单播泛洪（也可能是广播或者组播的泛洪），此时如果有netflow或者相关sniffer类的网管工具可以比较好的判断出具体未知流量的原因以及对于的源目IP地址，查找到具体源目ip后，有两种应急方案：

1、关闭发包源主机；

2、在目的主机所在的汇聚交换机上clear此arp信息。

五、未知单播泛洪的防护方法

1、接口下storm-control

       这个在防护广播或者组播中比较常见，很多人误以为可以用户防护单播泛洪，但是对于防护未知单播泛洪，这个命令是没有用的。这个命令只是去控制源主机单播往外去发，这时候源主机所在的交换机并无法分辨是未知单播还是正常单播，所以所有的单播都会去抑制，正常的流量也会受到影响，因此我们只能在目的主机所在的二层网络中想办法去抑制未知单播的泛洪。

2、汇聚交换机上trunk口vlan修剪

      在汇聚交换机的trunk口上allow vlan XX，trunk上仅允许接入交换机上有的vlan通过，这样可以使得泛洪仅仅影响到拥有目的主机vlan的接入交换机，减小了影响范围，通过上面的实验测试中也确实可以达到效果。但是在虚拟化时代，基本所有的接入交换机上都会有整个二层的所有vlan信息，所以这种方式并无法在所有环境中适用。

3、Mac、arp表的aging time调整

       在CAT-OS的交换机中，mac aging time是300s，arp的aging time为4h，而在NX-OS中是建议arp aging小于mac的agingtime的，N7K中默认的arp aging time为1500s，而mac的aging time为1800s。因此在CAT-OS中，是否可以调整arp aging time小于或等于mac aging time来避免未知单播的泛洪，并且这个值设置为多少较为合适，需要请思科评估一下。由于修改mac、arp的aging time是否会引起一些其他问题需要思科评估，所以需要非常谨慎，如果在没有其他解决方案的情况下可以考虑。

4、阻止未知单播泛洪

     通过在汇聚交换机的所有的二层接口上配置switchport block unicast，来阻止未知单播在此二层中泛洪，通过上面的实验测试确实可以阻止未知单播泛洪，按照思科的说法这个是最佳实践。但是在一些特殊的网络中，有的时候是需要未知单播泛洪的存在的，所以使用这个方法的时候做好充分的测试和应急回退工作。

后记：笔者在公司中尝试了第四种方案，的确可以有效的阻止未知单播的泛洪，但是也出现了一些副作用，网络中部分的ip phone网络不正常，一些linux主机网络也不正常，至于为什么不正常，具体原因还没有找出来，只是将switchport block unicast命令删除后，网络就恢复了，所以看来第四种方案也绝非最佳实践，因此未知单播泛洪这个问题看来传统的网络是无法完美解决，要用SDN网络来解决了。