一、故障背景

一位开发同事用办公后台的测试网段的用一台服务器写了个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网络来解决了。

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

MySQL性能优化、故障排查及最佳实践秘籍，阿里云数据库专家玄惭的“武功”全记录...
为什么80%的码农都做不了架构师?>>> 文章简介玄惭,真名罗龙九,阿里云DBA专家,负责阿里云RDS线上稳定以及专家服务团队.他经历过阿里历年双11实战考验,积累了7年对阿 ...
Confluence 6 数据中心的 SAML 单点登录最佳实践和故障排除
最佳实践 SAML 授权仅仅在有限的时间进行校验.你需要确定运行你的应用的计算机时间与 IdP 的时间是同步的. 如果你应用中的用户和用户组是通过用户目录进行配置的,你通常希望用户来源目录和你的 Id ...
广播泛洪_这三种类型的报文，交换机会进行泛洪：广播、组播、未知单播
随着互联网的发展,各种应用层出不穷,日新月异,对网络设备的要求也越来越高,对广大设备厂商也提出更多的要求.不过这些事情都与二层交换机没有关系:) ,因为各种应用的数据到达二层交换机时,都只会变成一个一 ...
rational故障_Rational Performance Tester和Citrix故障排除和最佳实践
Citrix Presentation Server的IBMRational®Performance Tester Extension使用Citrix客户端软件的一部分Citrix ICA Clien ...
广播泛洪_一分钟了解交换机四种报文中的三种：广播、组播、未知单播
随着互联网的发展,各种应用层出不穷,日新月异,对网络设备的要求也越来越高,对广大设备厂商也提出更多的要求.不过这些事情都与二层交换机没有关系:) ,因为各种应用的数据到达二层交换机时,都只会变成一个一 ...
Redis最佳实践：7个维度+43条使用规范，带你彻底玩转Redis | 附实践清单
阅读本文大约需要 16 分钟. 大家好,我是 Kaito. 这篇文章我想和你聊一聊 Redis 的最佳实践. 你的项目或许已经使用 Redis 很长时间了,但在使用过程中,你可能还会或多或少地遇到以下 ...
java 批量处理示例_Java异常处理教程（包含示例和最佳实践）
java 批量处理示例异常是可能在程序执行期间发生的错误事件,它会破坏其正常流程. Java提供了一种健壮且面向对象的方式来处理异常情况,称为Java异常处理 . 我们将在本教程中研究以下主题. ...
Java异常处理教程（包含示例和最佳实践）
异常是可能在程序执行期间发生的错误事件,它会破坏其正常流程. Java提供了一种健壮且面向对象的方式来处理异常情况,称为Java异常处理 . 我们将在本教程中研究以下主题. Java异常处理概述异常 ...
@sql 单元测试_SQL单元测试最佳实践
@sql 单元测试 SQL unit testing is a testing method which allows us to test the smallest, atomic programm ...

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