S3550不处理免费ARP导致VRRP故障案例.docVIP

S3550不处理免费ARP导致VRRP故障案例 800 徐立欢 一、实验拓扑图： S3550-24作3层使用，默认路由指向虚拟地址192.168.1.254，PC网关指向S3550-24。 查看当前路由器VRRP状态： NBR1000E-1为MASTER状态 NBR1000-2为BACKUP状态 查看S3550-24的ARP表及MAC表： ARP表中，虚拟地址192.168.1.254对应虚拟MAC 0000.5e00.0101。MAC表中，0000.5e00.0101对应端口Fa 0/1。这说明发往S3550-24上层的数据是通过Fa 0/1转发出去的。 当NBR1000E-1的F1/0断掉以后： 网络却无法恢复正常： 查看当前路由器VRRP状态： NBR1000E-1为BACKUP状态 NBR1000-2为MASTER状态 说明路由器已经正常切换。 查看S3550-24的ARP表与MAC表： ARP表中，虚拟地址192.168.1.254对应虚拟MAC 0000.5e00.0101。MAC表中，0000.5e00.0101则已转变为对应端口Fa 0/2。这说明S3550-24已经对数据转发端口作了正常切换。 这时在PC机上分别ping两台路由器的实地址，一切正常！ Tracert地址192.168.26.10，数据到了S3550-24后便丢了。 试着在S3550-24清ARP表，网络恢复正常。 于是怀疑S3550-24在对数据进行3层转发的时候，路由表出口并没有及时更新。 二、SNIFFER抓包分析 按照原始配置重新测试，使用PC机ping 192.168.26.10，然后断掉NBR1000-1的F1/0。 监控S3550-24的F0/2端口: 抓到的数据包中并未发现任何ICMP ECHO（ping）包。 监控S3550-24的F0/1端口： 抓到的数据包中发现了ICMP ECHO（ping）包。 三、结论 在NBR1000E-1的Fa 1/0断掉后，发向S3550-24上面的数据理论上应该由Fa 0/2路由转发出去，但实际的测试中，仍是由Fa 0/1转发的。 在S3550-24交换机上把默认路由配置指向VRRP协议的虚拟地址，当VRRP协议切换路由器时，S3550-24三层数据路由出口不能进行正确的切换。 最后经TAC的确认，问题已经定位，是由于S3550不支持免费arp导致。可以将版本更换为V2.41(3)去解决这个问题。 故障发生时Sdebug L3信息： DBdump l3 L3.0[0x1]:IP_ADDR=0xc0a80103,MAC_ADDR=0xd0f8ff4d7a,PORT=0x1b,INTF=0,HIT=0,FTYPE=0,D_HIT=1,MODID=0 L3.0[0x2]:IP_ADDR=0xc0a801fe,MAC_ADDR=0x5e000101,PORT=0,INTF=0,HIT=0,FTYPE=0,D_HIT=1,MODID=0 L3.0[0x3]:IP_ADDR=0xc0a80201,MAC_ADDR=0xd0f8ff4d7b,PORT=0x1b,INTF=1,HIT=0,FTYPE=0,D_HIT=0,MODID=0 L3.0[0x4]:IP_ADDR=0xc0a80264,MAC_ADDR=02,PORT=2,INTF=1,HIT=1,FTYPE=0,D_HIT=1,MODID=0 由SDEBUG可以看到出端口还是0端口（用户接口fa0/1)，说明arp没有更新（免费arp没有生效）。 交换机端运行命令clear arp后交换机会主动发出arp请求，VRRP master回复后，S3550将更新自身的arp表项。故障也会消除。 附：版本2.41(3)测试结果 版本信息： 将PC的网关设置在S3550-24上并长ping 192.168.26.10，这时将NBR1000E-1的F1/0口断开，在经过一个丢包时间后，网络恢复正常。