交换网络内的流量异常转发问题

在一个由2台cisco7609的核心交换机和多台二层交换机组成的三角形网络中出现了流量异常转发问题，下面具体描述该问题。  
网络环境描述：
网络拓扑图如右，2台核心交换机上面配置了vlan198、vlan200以及vlan254，每个vlan的HSRP的active和STP的root都分别强制配置在一起。例如vlan198和vlan254的hsrp-active和stp-root在CSW-A上，而vlan200的hsrp-active和stp-root在CSW-B上。

问题描述：
172.17.200.30到172.17.254.30的数据包不知道为什么在ASW-2的上联端口能够抓到。查看了CSW上面的HSRP和STP以及ARP表和MAC地址表都没有问题，都显示不应该转发到ASW-2上面。如果说是ARP表和MAC地址表的aging-time不通，导致有可能当mac地址没有条目后广播产生流量，但是这样的话也不可能有这么大这么久的流量持续啊。

今天终于针对这个问题找到原因了，原来是由于v2和v5的hsrp-active不在一起导致的，也就是存在非对称路由。默认情况下，arp的存活时间为4小时，mac存活时间为5分钟。这就会造成当某服务器A的arp表没有超时，但是mac表超时后，交换机就会洪泛到A的数据流。需要注意的是数据流经过一跳时就会将数据包的mac地址段包括源和目的mac地址都需要重写。下面依据上面拓扑图来分析一下：

1），Ser1(1.1.2.30)往Ser2(1.1.5.30)发数据包，Ser1将数据包发往默认网关，也即CW-A的V2网关：

目的mac地址	源mac地址	源ip地址	目的ip地址
M_V2_GW	M_Ser1	1.1.2.30	1.1.5.30

2），CW-A接收到数据包进行解包过程，查找路由表（CEF），查找arp表，能找到1.1.5.30的arp表项，依据arp表进行mac地址的重写，然后查找1.1.5.30的mac表项，发现没有此表项即找不到从哪个端口发包（这里假设mac表已经老化），于是进行洪泛到所有v5的端口进行二层转发，数据包为：

目的mac地址	源mac地址	源ip地址	目的ip地址
M_Ser2	M_V2_GW	1.1.2.30	1.1.5.30

3），CW-B接收到洪泛包，解包后发现目的mac地址为M_Ser2（事实上CW-B永远从 数据包的mac地址段看不到M_Ser1的mac地址，因为M_Ser1相关的数据包到了CW-A上面会进行mac地址的重写，将源mac改写成M_V2_GW。除非对Ser1进行arp请求，这是CW-B能从arp的数据报文中读取Ser1的mac地址，更新mac地址表），根据对应的端口直接转发数据包。

目的mac地址	源mac地址	源ip地址	目的ip地址
M_Ser2	M_V5_GW	1.1.2.30	1.1.5.30

4），Ser2接收到数据包进行回应，这里不敷衍了。

这里需要重点注意的是：
数据包到了相应的网关后，网关会根据arp表进行mac地址字段的rewrite。所以网关从mac字段是看不到非本网关网段内主机的mac地址的，只能从arp的影响报文的数据段内找到mac地址。然而arp表的老化时间默认为4小时，mac表的老化时间为5分钟，在不同vlan的hsrp-active布置在不同交换机的情况下，最长就有3小时55分钟相应的mac地址表为空，也就是说在这段时间内相关数据流就会洪泛。

解决方法：

1），将所有vlan的网关布置在同一台交换机上面，这样就没有了负载优势，所有vlan的数据流都由同一台设备进行处理；

2），将arp表和mac表的老化时间调至一致，或者mac地址大于arp老化时间。mac表不老化，从理论上来讲应该就只是占用了tcam条目，应该不会有其他问题，做的时候最好针对各个vlan同时进行arp和mac的clear；

3），静态绑定mac地址或者启用port-security mac sticky特性，甚至与disable-unicast特性结合一起使用，但是未知的意外现象不好估量；

4），服务器上配置脚本每隔4分钟ping一下网关。