原标题：机房网络未知单播泛洪问题处理
关注我们FOLLOW US
作者简介
冯亚伟
去哪儿网NETOPS
2014年7月加入去哪儿网，拥有丰富的网络运维经验，现负责公司IDC和骨干传输网络的运维工作。
1. 未知单播泛洪产生的原因
数据需要经过逐层的封装，才能在网络中进行传递，需要先封装 IP 头部，IP 头部中的源 IP 地址和目的 IP 地址用于主机到主机的寻址，数据包在网络上传递的过程中源 IP 地址和目的 IP 地址保持不变；然后再封装数据帧头部，其中包含目的 MAC 地址和源 MAC 地址，用于在同网段（链路，广播域）内寻址。数据包每经过一个路由设备转发之后，数据帧中的源 MAC 地址和目的 MAC 地址都会发生变化，源 MAC 地址变为发送路由器的 MAC 地址，目的 MAC 地址变为接收数据包的路由器（或主机）的 MAC 地址。
同网段内主机之间的通信方式：
源主机判断目的主机的 IP 和本机 IP 属于同一网段后，确定两台主机位于同一个网段，即不需要通过网关转发，两台主机就可以直接进行通信。此时，源主机需要获取到目的主机的 MAC 地址。
那源主机如何获取目的主机 IP 对应的 MAC 地址呢？首先查看 ARP 表，ARP 表中记录了 IP 地址对应的 MAC 地址，如果 ARP 表内有相应的条目则可直接使用 ARP 条目记录的 MAC 地址作为数据帧的目的 MAC 地址。
如果 ARP 表内没有对应的条目，则需要通过 ARP 协议（address resolution protocol，地址解析协议）进行地址解析。主机会发送一个 ARP 请求：“谁在使用 IP-1，请告诉我你的 MAC 地址”，使用 IP-1 的主机在收到 ARP 请求后会回应一个 ARP 应答：“我是IP-1，我的 MAC 地址是 MAC-1”，主机在收到 ARP 应答后，会将信息先记录在 ARP 表中，下次就可以直接使用了。当然，该条目是 有老化时间的，不会一直有效。
之后，源主机会将自己的 MAC 地址作为源 MAC 地址，目的主机的 MAC 地址作为目的 MAC 地址封装进帧头中，将数据帧发送出去。
同网段主机的通信需要经过交换机的二层转发。交换机会 学习数据帧头中的源 MAC 地址，将它与接收该数据帧的物理接口进行绑定，生成 MAC 地址表，MAC 地址表也有老化时间，这样当需要转发到某个 MAC 地址的数据帧时，查下 MAC 地址表就知道该从哪个接口发送出去了。如果交换机在转发某个数据帧时其目的 MAC 地址在 MAC 地址表中没有找到，就不能确定该将数据帧从哪个接口发送出去了，那么交换机就会将数据帧从所有包含该网段（通过 vlan ID 或者 trunk 来确定）的接口发送出去，就形成了 未知单播泛洪，该机制保证了数据帧能被目的主机收到，但当网络中有大量的未知单播泛洪时，接口带宽会被耗尽，导致丢包发生，影响正常的网络通信。
不同网段之间主机的通信方式：
源主机判断目的 IP 和本机 IP 不属于同一个网段后，就需要通过该网段的网关（default gateway）进行三层转发来实现源目主机之间的互通，需要先将数据包发送给网关，之后再由网关进行路由转发。首先源主机将本机 IP 作为源 IP，目的主机的 IP 作为目的 IP 封装进 IP 头中，然后将本机 MAC 地址作为源 MAC 地址，网关的 MAC 地址作为目的 MAC 地址封装进帧头中，将数据帧发送给源主机所在网段的网关，数据包经过路由之后，发送到了目的主机所在网段的网关。目的主机的网关在收到数据包后，如果网关的 ARP 表中没有目的 IP 对应的 MAC 地址，则需要发送 ARP 请求解析目的 IP 对应的 MAC 地址，在 ARP 交互过程中，网关会将目的主机的 MAC 地址绑定到对应的交换机接口上，生成 MAC 地址表条目，这样网关获取到目的主机的 MAC 地址以后，将数据帧从对应的接口发送出去， 不会产生未知单播泛洪。
但是，如果目的网关上有目的 IP 对应的 ARP 表条目，但是没有目的 MAC 对应的 MAC 地址表条目时，目的网关会将数据帧从所有包含该网段的接口发送出去， 形成未知单播泛洪。
ARP 表老化时间和 MAC 地址表老花时间的不同（ARP 表老花时间比 MAC 地址表老化时间长），是产生未知单播泛洪的一个原因。
2. 线上机房未知单播问题原因分析
如图，server 通过 LVS tunnel 模式对外提供服务，lvs tunnel 模式的特点是：server 在响应 client 的请求时，回包不会再经过 LVS 服务器，而是直接回包给 client，这种方式降低了 LVS 服务器的压力。
如图，client 请求 server 上的服务，数据包的的发送路径是：client-->SW1-->核心交换机-->SW3-->LVS Server-->SW3-->核心交换机-->SW2→server
client 请求 server 时 SW2 不能学习并生成 client 的 MAC 地址表条目。
回包的路径是：server-->SW2-->核心交换机-->SW1→client
server 在第一次给 client 回包时，在 ARP 交互过程中 SW2 能学习并生成 client 的 MAC 地址表条目。但该条目五分钟后会老化消失。
随着 server 持续给 client 回包，当时间来到5分钟以后，SW2 上关于 client 的 MAC 地址表条目老化删除后，SW2 就开始将 server 到 client 的流量进行未知单播泛洪，泛洪的流量会发送到核心交换机上。
正常来说，核心交换机上应该有 client 的 MAC 地址表条目的，因为 client 请求 server 服务（LVS VIP）的包一直经过核心交换机，核心交换机会将数据包从相应的接口发送出去，不会进行未知单播泛洪。
但是，核心交换机的厂商为了减少交换机上 MAC 地址表条目数量，节省硬件资源，将 MAC 地址表的学习机制改为：只学习进行二层转发的数据包的源 MAC 地址（二层口进，二层口出），不学习进行三层转发的数据包的源 MAC 地址（二层口进，三层口出）。案例中 client 到 LVS VIP 的请求就是需要核心交换机进行三层转发的（client 与 lvs vip 不属于同一网段）。所以核心交换机不会学习 client 的 MAC 地址。
这样当 server 回给 client 的包到达核心交换机时，也会产生未知单播泛洪。
由于核心交换机与接入交换机都是二层 trunk（trunk 即包含所有的网段）互联的，所以流量会泛洪到所有的接入交换机上。接入交换机再将流量泛洪到所有的宿主机（trunk 口）和与 client 同网段的服务器上。
当 server 到 client 的流量达到1G 的时候，泛洪流量也会达到1G，会将千兆服务器的网卡打满，影响千兆服务器的网络。
3. 问题改进方案
1、修改核心交换机上的 MAC 地址学习机制：学习所有从二层接口进入的数据包的源 MAC 地址，不检查出接口，消除了核心交换机上的未知单播泛洪。
2、修改 server 上回复 client 请求的路由方式，将基于目的 IP 的路由改为基于源 IP 的路由，将源 IP 是 lvs vip 的数据包直接发送给核心交换机，消除了 SW2 交换机上的未知单播泛洪。
END
