Gratuitous ARP｜记一次业务迁移引发的灵异事件

写在前面

    最近一客户跟我反馈说：涛哥，我们在做新老F5设备业务（同一个vlan64网段的业务）迁移的过程中，发现有的业务迁移没问题，有的业务迁移老失败，迁移失败的故障场景下，该业务IP地址ping和telnet都不通，整个迁移过程也都使用tcpdump在F5上抓包了，帮忙看看？

    以小咩以往的经验，大概率arp广播的问题，进一步和沟通并且结合数据包分析发现该故障并不简单，本着拔出萝卜带出泥的理念，给各位铁子们分享一下此次灵异事件。

网络结构

用户目前现网有一台F5 LTM 2000设备，设备系统版本为11.4.1，由于该设备型号较老，于是新采购了一台F5 LTM i2600设备（系统版本14.1.4）用于替换老F5 LTM 2000设备，但是为了保证业务的平缓迁移，没有采用一锅端，整机替换的方式去操作，而是先把新F5 LTM i2600设备接入网络（和LTM 2000在一个网段里），然后手动分批去迁移业务。以下是简图：

业务迁移

故障现象：

当执行第2步F5 LTM i2600设备创建VIP1和VIP2后（即完成业务迁移），客户端访问业务故障，并且ping、telnet都无法联通该业务地址。

故障定位：

在整个业务迁移的过程中，在F5 LTM i2600设备上使用tcpdump抓包记录了整个迁移过程。

PS：由于新老F5设备在同一个二层网络里，所以可以抓取到新老F5设备广播的arp数据包。

#在F5 LTM i2600设备上使用tcpdump抓取arp包
tcpdump -s0 -nni 0.0:nnn arp -vw var/tmp/arp20210901.pcap
复制

过滤业务IP地址10.xx.64.224触发出来的gratuitous ARP (以下简称garp)数据包：

数据包解析：

1. 其中标红部分触发出来的garp数据包为文章第二部分业务迁移步骤一“F5 LTM 2000设备业务VIP1和VIP2地址修改成其他IP地址”动作触发出来的garp数据包。

2. 绿色部分garp数据包为文章第二部分业务迁移步骤二“新F5 LTM i2600设备创建VIP1和VIP2”动作触发出来的garp数据包

3. 其中MAC 19:85为F5 LTM 2000的设备Mac，e1:06为F5 LTM i2600设备的MAC

4. 抓包截图最后一部分未标注的数据包即12:05分触发的garp数据包暂时忽略，是由于业务不通，通过黑科技手动强制触发让F5 LTM i2600广播10.xx.64.224的数据包，去强制刷上联交换机arp缓存，解决故障，这个我们最后介绍。

带着这些疑问我们接着往下看

拔出萝卜带出泥

是什么原因导致了，以上的问题？

开始之前我们在回顾下两台F5设备的系统版本，F5 LTM 2000 系统版本为11.4.1，F5 LTM i2600系统版本为14.1.4

F5 设备garp广播机制介绍

其他的GARP触发行为我们这里不做讨论，我们看标注部分介绍：在创建和修改VIP地址时设备会广播该IP的GARP。

老版本F5 设备VIP广播机制

新版本F5 设备VIP广播机制

新版本F5设备VIP广播机制为，当修改或者创建某一个业务的VIP地址时，只会触发更新该VIP地址的GARP，以下是数据包：

故障总结

通过以上F5新旧版本的的GARP的广播机制结合具体的操作步骤我们可以还原故障问题：

优化

tmsh modify ltm virtual-address 10.xx.64.224 arp disabled
tmsh modify ltm virtual-address 10.xx.64.224 arp enabled
复制

- EOF -

觉得本文对你有帮助，请分享给更多人