防火墙 Keepalived 异常双活恢复后部分外网访问中断问题分析

冯亚伟 （去哪儿网 NETOPS）

2014 年 7 月加入去哪儿网，拥有丰富的网络运维经验，现负责公司 IDC 和骨干传输网络的运维工作。

1. 故障描述

1、19:01 在 fw4 仍然为 master 的状态下 fw3 独自提升为 master 状态；

2、19:27 fw3 独自放弃 master 状态，故障开始；

3、19:44 发现机器 server1 请求外部接口异常；

4、19:48 清理机器 server1 上的 arp 缓存，机器恢复；

5、19:51 在 fw4 上发送 vip 的免费 arp 刷新内部服务器上的 arp 表项后，故障恢复。

2. 涉及到的关键知识点

2.1 linux 系统的 arp cache 状态

REACHABLE 状态：arp 条目对应的邻居可达，可以直接用该 arp 条目。REACHABLE 超时时间是 15s~45s 之间的随机值。使用 arp 条目成功发送数据包后（如 tcp 得到 ack，icmp request 得到 reply），会重置超时计时器。

STALE 状态：arp 条目从 REACHABLE 状态超时后，进入 STALE 状态，该状态不确定 arp 条目对应的邻居是否可达，但是在使用该条目再次发送数据包之前不会对其可达性进行检测。

DELAY 状态：使用处于 STALE 状态的 arp 条目发送出去数据包后，arp 条目从 STALE 状态进入 DELAY 状态，DELAY 状态超时时间为 5s，在 DELAY 状态会进行邻居不可达检测，如果确认邻居依然可达则条目进入 REACHABLE 状态，否则进入 PROBE 状态。

PROBE 状态：会发送 3 次单播 arp 以确认邻居可达性，发送间隔为 1s。若收到 arp 应答，则条目进入 REACHABLE 状态，否则进入 FAILED 状态。

FAILED 状态：向条目中的 IP 地址发送数据包时，会重新发送广播 arp，解析 IP 对应的 MAC 地址。

2.2 邻居不可达检测

分两种方式：

1、通过上层协议进行邻居可达性确认，例如当 TCP 收到了 ACK，ICMP 收到了 echo reply 时，证明邻居可达；

2、使用 arp 条目中的 MAC 地址作为目的 MAC 地址，发送单播 arp 进行检测，如果能收到 arp 应答，则证明邻居可达。

2.3 Linux6.0 和 Linux7.0 系统对 STALE 状态的 ARP 条目进行邻居不可达检测的区别

Linux6.0：

图1

• Linux6.0 系统在使用处于 STALE 状态的 arp 条目发送 TCP 或者 ICMP 数据包后，将该条目改为 DELAY 状态；

• 在 DELAY 状态超时之前收到了 TCP 或者 ICMP 应答，则将该条目改为 REACHABLE 状态；

• 若在 DELAY 超时前未收到 TCP 或者 ICMP 应答，则进入 PROBE 状态；

• 发送 3 次单播 arp 进行邻居可达性检测；

• 若收到 arp 应答，则 arp 条目进入 REACHABLE 状态；

• 若未收到 arp 应答，则 arp 条目进入 FAILED 状态；

• 发送广播 arp，以解析 IP 对应的 MAC 地址。

  
  

Linux7.0：

图2

• Linux7.0 系统在使用处于 STALE 状态的 arp 条目发送数据包后，将该条目改为 DELAY 状态，并发送单播 arp 检测邻居是否依然可达；

• 若在 Delay 超时之前收到了 arp 应答，则将 arp 条目改为 REACHABLE 状态；

• 若在 DEALY 超时之前未收到 arp 应答，则将 arp 条目改为 PROBE 状态；

• 并继续向外发送 3 次单播 arp 进行检测；

• 若收到了 arp 应答，则将 arp 条目改为 REACHABLE 状态；

• 若未收到 arp 应答，则将 arp 条目改为 FAILED 状态；

• 然后发送广播 arp，以解析 IP 对应的 MAC 地址。

2.4 Cisco NXOS arp 超时时间

Cisco Nexus 交换机的 NXOS 系统，会在 arp 条目存在 18 分钟 50s 后，开始发送单播 arp 确认条目中邻居的可达性，发送间隔为 37s，发送 10 次。若收到 arp 应答则重置计时器为 0（从 0 重新开始计时）；若未收到 arp 应答，则会删除该 arp 条目；所以，arp 条目的最长生存时间是 25 分钟。

2.5 iptables 如何处理没有 session 存在的非 TCP 首包

iptables 在收到非 TCP 首包（SYN）时，如果没有对应的 session 条目存在，但是有对应的 SNAT 规则，iptables 也会进行 NAT 转换，并在/proc/net/nf_conntrack 中创建 session 条目。

2.6 keepalived 在处于 standby 状态时如何处理发送给 VIP 的数据包

当服务器上处于 standby 状态没有 keepalived 的 VIP 时，服务器依然会正常接收发送给 VIP 的数据包，只要数据包的目的 MAC 地址为服务器网卡的 MAC 地址。也会继续使用 keepalived VIP 做 SNAT，并转发数据包。

2.7 Linux 系统和 Cisco NXOS 系统处理免费 ARP 的行为

当 keepalived 处于 standby 状态的服务器升为 master 后，会发送免费 arp，用于刷新服务器和交换机上的 arp cache，linux 系统收到免费 arp 后，如果存在对应的条目，则会更新条目，并将条目的状态设置为 STALE，若不存在，不会创建新的条目。NXOS 系统在收到免费 arp 后，如果存在对应的条目，则会更新条目，并将计时器重置为 0。若不存在，不会创建新的条目。

2.8 keepalived 的双活处理机制

若在 keepalived 主用服务器未失败的情况下，备用服务器异常升为主用，备用服务器会发送免费 arp 刷新交换机和服务器的 arp 条目，流量会被切到备用服务器上。当两台服务器检测到彼此都处于主用状态后，会重新进行选举，如果异常升为主用的服务器选举失败，会重新回到备用状态，然而主用防火墙因为其状态并未发生过改变，所以并不会向外发送免费 ARP 用于刷新服务器和交换机上的 arp 条目。所以，流量依然会留在备用服务器上。

2.9 fw 上的 session 超时时间为 60 分钟

3. 本次故障过程及原因分析

3.1 FW 主备异常切换发生前的网络流量图

图3

FW4 为主，FW3 为备，VIP 在 FW4 上，流量的进出都经过 FW4，来回路径一致。

3.2 FW3 异常升为主用后，双主时的流量图

图4

当 FW4 依然处于主用状态，FW3 异常升为主用时，FW3 向外发送免费 arp，刷新了服务器和交换机已有的 arp 条目，将 VIP 对应的 MAC 地址更新为 FW3 的 MAC 地址，在 Linux6.0 和 7.0 上更新后的 VIP ARP 条目状态为 STALE，当使用该 arp 条目向 VIP 发送数据包时，Linux6.0 通过上层应用完成了邻居不可达检测，VIP 的 ARP 条目状态更改为 REACHABLE 状态；Linux7.0 通过单播 arp 完成了邻居不可达检测（因为 VIP 此时依然在 FW3 上，所以 FW3 会响应关于 VIP 的 ARP），VIP 的 arp 条目状态更改为 REACHABLE 状态。所以 Server1 和 Server2 的流量都开始通过 FW3 进行转发。核心交换机在 VIP 的 arp 条目被刷新后，也开始将 VIP 的回包发送给 FW3。此时进出流量都经过 FW3，且流量的来回路径一致。

3.3 FW 检测到双活，Keepalived 重新选举，FW3 选举失败重回备用状态后的流量图

Server2 在 FW3 上有相关的 session 时：

图5

Server2 在 FW3 上没有相关的 session 时：

图6

当 FW3 和 FW4 检测到彼此都处于主用状态后，便开始进行选举，最终 FW3 选举失败，重回备用状态。当 Server2 上关于 FW VIP 的 arp 条目变为 STALE 状态后，再次使用该条目发送数据包时，会向 FW3 发送单播 arp 进行可达性检测。因为 FW3 已经不是主 FW，没有 VIP 了，所以不会响应该 arp 应答。

Server2 最终检测到邻居不可达，关于 VIP 的 arp 条目进入 FAILED 状态。然后 Server2 重新发送广播 arp，解析 VIP 对应的 MAC 地址，主用防火墙 FW4 响应了 arp 请求。所以 Server2 开始向 FW4 发送数据包。

因为核心交换机上关于 VIP 的 arp 条目还未超时，所以会将 Server2 的回包发送给 FW3。如果 FW3 上保持有相关的 session，则 FW3 会将回包成功返回给 Server2【见图 5】。

如果 FW3 上没有相关的 session 的话，FW3 会发送广播 arp 请求，解析 VIP 的 MAC 地址，在 FW4 响应了 arp 请求后，FW3 将回包发送给 FW4，FW4 再将回包发送给 Server2【见图 6】。所以此时，Server2 的 Out/In 流量为异步，但是通信依然正常。

当 Server1 上关于 VIP 的 arp 条目进入 STALE 状态后，再次使用该条目发送 TCP 数据包时，该条目进入 DELAY 状态。如【图 5】所示，当 Server1 收到 TCP 应答后，VIP 的 arp 条目会被更新为 REACHABLE。此时 Server1 的进出流量依然经过 FW3，进出路径一致，通信正常。

3.4 当核心交换机上关于 VIP 的 ARP 条目【MAC 地 址对应 FW3】在存在 25 分钟超时后的流量图

Server1 在 FW4 上有 session 的情况：

图7

Server1 在 FW4 上没有 Session 的情况：

图8

核心交换机上关于 VIP 的 arp 条目（对应 FW3 的 MAC 地址）在存在了 25 分钟后超时，然后发送关于 VIP 的广播 arp，FW4 响应 arp 请求，核心交换机到 VIP 的回包开始向 FW4 发送。此时 Server2 的流量进出都经过 FW4，来回路径一致，网络通信正常。Server1 的回包会被核心交换机发送到 FW4，如果 FW4 上存在相关的 session，则 FW4 发送回包给 Server1，此时 Server1 的外网访问正常。如果 Server1 这个正常的外网访问不停的发送数据，则 Server1 上关于 VIP 的 arp 条目（对应 FW3 的 MAC 地址）会一直保持在 REACHABLE 状态。

当 Server1 需要建立新的 TCP 连接时，TCP SYN 发送给 FW3，但回包 TCP SYN+ACK 会被发送到 FW4 上，这个 TCP SYN+ACK 包的目的地址是 FW4 上的 VIP 地址，由于 FW4 上没有 TCP SYN 包的 session 记录，所以 FW4 回复一个 RESET，重置掉这个连接，不会将 SYN+ACK 包转发给 Server1。此时，Server1 上新的 TCP 连接建立失败，Ping 同样会失败，会出现访问外网失败的现象。

3.5 原因总结

1、FW4 在检测到双活重新选举胜利后，因为其状态未发生过改变，所以没有及时发送免费 arp 以刷新核心交换机和内网服务器上的 VIP ARP 信息。

2、Linux6.0 系统使用上层应用进行 arp 条目邻居不可达检测的机制，导致不能及时发现 VIP ARP 信息的变化。