USG9520防火墙配置静态ARP后网络中出现大量重复报文问题案例

发布时间:  2014-01-24 浏览次数:  560 下载次数:  0
问题描述
客户网络中站点2增加2台服务器做双机主备后,需要在防火墙上配置绑定MAC地址的静态ARP表项,完成配置后网络中出现大量的重复报文,严重影响网络的性能和占用了大量的网络带宽。

告警信息
处理过程
(1) 在防火墙上配置静态ARP  [arp static 10.10.146.90 03bf-xxxx-925a VID 110]后,从防火墙ping eSDK服务器IP地址,发现有很多的重复回应报文,如下:

HRP_M[DHA-0840-FW-01]ping 10.10.146.90
16:27:36  2014/01/12
  PING 10.10.146.90: 56  data bytes, press CTRL_C to break
    Reply from 10.10.146.90: bytes=56 Sequence=1 ttl=128 time=6 ms
    Reply from 10.10.146.90: bytes=56 Sequence=1 ttl=128 time=496 ms (DUP!)
    Reply from 10.10.146.90: bytes=56 Sequence=1 ttl=128 time=498 ms (DUP!)

从ping测试结果看,怀疑是eSDK服务器双机都重复回应了ping请求报文所致,于是进行抓包确认。但是从抓包报文情况分析,对于业务请求报文,只有一台服务器进行回应,另一台服务器没有做任何回应,抓包报文信息如下:
服务器1有回应报文:


服务器2没有回应报文:

因此,主备服务器是工作正常的,只有主服务器对业务情况进行了回应。排除了服务器重复回应的可能。
(2) 于是继续分析抓包中的重复报文的特点,发现报文的TCP序列号虽然是重复的,但是报文的源MAC地址却是不断变化的,由此排除网络二层环路的可能,因为如果是二层环路的话,报文的源MAC地址也是不会变化的。抓包报文如下:


从以上抓包可以看出,对于源IP 10.110.252.69,源MAC地址在两个MAC地址间不停的跳变。于是让一线现场确认这两个MAC是什么设备的地址。经现场确认,这两个MAC地址是主备防火墙的内网接口地址,这样看来报文是从主备防火墙转发出来的。再看报文的TTL,虽然报文的源MAC地址不同,但是报文的TTL是顺序递减的。从以上信息看,问题像是主防火墙发出的报文,到了备防火墙,备份防火墙转发后又到了主防火墙,报文在主防火墙与备防火墙之间形成了三层环路。
  从抓包的情况分析有上述结论,但是为什么会出现这个现象呢,报文的目的地址明明是服务器地址10.10.146.90。为什么报文会在主备防火墙之间形成环路呢?回过头再来梳理静态arp配置和抓包。注意到静态arp绑定的MAC地址是一个组播MAC地址。这个从上面的抓包中也能看出来。由于目的MAC地址组播MAC地址,交换机上是没有相应的动态MAC转发表项的,于是与一线确认交换机上是否配置该组播MAC相关的静态表项。一线反馈交换机上没有做任何配置修改,到这里问题原因应该比较清楚了。

于是对网络中产生重复报文的原因梳理如下:
主机10.110.252.69发送报文到10.10.146.90,由于10.10.146.90对应的MAC地址是组播MAC(03:bf:xx:xx:92:5a),当交换机LSW1(或者LSW2)收到该报文后,交换机找不到该组播MAC地址的MAC转发表项(因为交换机是无法学习组播MAC地址的转发表项的),会在同一VLAN内除了报文入接口的其他接口上泛洪,防火墙与交换机所连接的接口都在同一个VLAN 110内。所以防火墙也会收到该报文。由于在防火墙添加了组播MAC与10.10.146.90之间的arp绑定表(arp static 10.10.146.90 03bf-xxxx-925a VID 110)。
防火墙收到该报文后,能够正常查到arp表项,因此防火墙又将报文转发到交换机了,只是由于是三层转发,防火墙将报文的源MAC地址改成自己的接口的MAC地址了。这样就导致10.110.252.69发出的这个报文被防火墙又多转发了一次。而从抓包来看,报文的源MAC既有主防火墙的也有备防火墙的,这是由于在主墙上配置arp静态绑定后,该配置自动备份到了备防火墙,因此,备墙也转发了该报文。再加上交换又会对两台防火墙转发出来的报文进行了泛洪,防火墙又会重复处理,如此反复直到报文TTL超时。同时,交换机对报文的每次泛洪,服务器都会收到一份报文,这样就导致服务器收到很多的重复报文。由于以上原因,在交换机与服务器相连的接口上的抓包,就看到了很多重复的,失序的报文。

根因
根据故障现象,以及现场的组网情况,对问题原因有如下怀疑点:
(1) eSDK服务器的双机主备环境存在问题,两个服务器都会回应请求;
(2) 网络中存在环路;
建议与总结
由于交换机上没有组播MAC地址的MAC转发表项,导致交换机对目的地址是组播MAC的报文进行泛洪,而防火墙在配置组播MAC地址的arp表项后,对交换机泛洪的报文又转发回了交换机,加上防火墙双机组网,在主备防火墙之间就形成了三层环路,最终导致了大量的重复报文产生。

解决方案:
需要抑制目的MAC为组播MAC地址的报文在交换机上泛红洪,因此可以对交换机上需要转发组播MAC地址报文的接口上配置静态组播MAC地址功能进行解决,命令行为:Mac-address multicast 03bf-xxxx-925a vlan 110。该功能需要确认交换交换机软件版本是否支持。

建议:
在定位分析重复报文,乱序报文等问题时,仔细分析抓包信息是非常重要的,也是非常有用的。

END