多路冗余、堆叠方案下网络连接故障分析

目前机房两台NGFW400-UF万兆防火墙的部署方案实施后，发现存在偶发性链路不稳定的情况。
这两天根据不同设备间抓包分析，定位问题点，经与厂商工程师反复沟通确认后，确认了故障原因。

一、物理拓扑图

  • 堆叠设备采用多虚一技术(思科VSS、华为CSS等)实现统一管理配置、简化网络结构
  • 各网段网关均设置为核心交换机
  • 为避免环路，采用多个物理口链路聚合的形式解决
  • 链路聚合厂商支持程度存在差异: 交换机支持跨设备链路聚合，防火墙仅支持一台设备不同端口的聚合
  • 防火墙设备HA采用连接保护模式，心跳线仅用于策略和连接同步，不传输网络数据
  • 交换机虚拟化技术中两台设备间的链路存在数据传输 物理拓扑结构图

增加链路聚合，避免环路的拓扑：
链路聚合，避免环路

  • 图中网络设备存在多个冗余设备虚拟化为单一逻辑设备的情况(A1+A2, B1+B2, C1+C2, D1+D2)

二、拓扑设计思想

  1. 设备多虚一的堆叠方案，既保证设备冗余性，又便于统一管理配置
  2. 链路多路冗余，任一设备均有2条上连物理链路
  3. 任一设备、链路故障，理论上均不会对网络服务产生影响
    PS: 这个方案的确定有一个前提: 对可靠性高度要求、对设备利用率不敏感

三、问题分析

通过网管软件监控网路设备状态时发现以下问题：

  1. 部分网络设备、服务器的网络时断时连
  2. 部分服务器需要添加双向策略，才能保证服务稳定
  3. 部分终端能Ping通某服务器，而部分终端不能Ping通
  4. 增加双向策略后，网络时断时连问题可解决

SSH登录防火墙后执行tcpdump抓包分析

1
2
3
4
# 抓取源IP到目的IP所有端口的报文(该模式下仅显示发送报文信息)
tcpdump -ni any and host 192.168.1.1 and host 192.168.2.1
# 抓取源IP到目的IP制定端口的报文(该模式下可显示发送\接收报文信息)
tcpdump -ni bond1 vlan 11 and host 192.168.1.1 and host 192.168.2.1

3.1 网络数据流分析: Ping Request

注：下述图示为存在网络异常时的数据流向，正常数据流向优先从单一设备收发以提高效率。
以服务器F对服务器E发起Ping为例(二者跨网段，需要经核心交换机路由), Request的报文路径如下图：
Ping Request的路径为：F -> D2 -> B1(防火墙策略允许，放行，连接同步至B2) -> A1(核心交换机VLAN间路由) -> B2(放行并洪范转发) -> C1 -> E
Ping Request报文路径

  • 防火墙策略：允许服务器F->E
  • 链路聚合后多条链路选择的均衡算法为：基于源MAC和目的MAC
  • 防火墙A建立放行连接后，将通过心跳线将该连接同步至防火墙B
    注意: 防火墙B2中看到其将Request报文洪泛至所有端口，而非直接转发至目的端口(目的MAC所在端口)

3.2 网络数据流分析: Ping Reply

Ping Reply的路径为：E -> C1 -> B1(防火墙认为与Request同一个连接，放行) -> A1(核心交换机VLAN间路由) -> B2(收到Reply报文，但未发送任何Reply报文) —–Reply中断传输—– -> D1 -> F
Ping Reply报文路径

3.3 故障点分析

  1. 在Request转发阶段，B2中首次收到Request时，本身应以有该条连接(从B1同步而来), 应直接放心Request并转发至制定端口。
    但B2在收到Request后，并未单播转发，而是洪泛至所有端口，异常！
  2. 在Reply转发阶段，B2收到Reply后，应根据已有连接，判定Reply与Request属于同一连接，放行并转发，但并未发送。
    可能由于某种原因，导致未匹配ACL规则，直接丢弃了Reply报文。

3.4 厂商工程师沟通

经过与厂商工程师的多次推敲和验证，确定结论如下：

  1. 确认防火墙B2上是否存在目的服务器E的MAC地址？
    注：防火墙B2的MAC表中，确实无服务器E的MAC地址记录。
  2. 若B2中无E的MAC记录，则受到Request时将洪泛至除来源接口外的所有其他接口。
    注：这与我抓包分析是一直的，洪泛原因可以确定为”防火墙B2中无目标服务器的MAC地址”, 同时作为二层透传模式，其不会进行ARP地址解析，只能将Request洪泛。
  3. 当防火墙发生报文洪泛时，将自动清理该报文所属的连接记录
    注：防火墙研发认为，不存在其MAC地址，洪泛出去的报文说明是不完整的连接，应删除连接。当再次请求时建立完整连接。
  4. 由于防火墙B2已清理该连接，当Reply报文抵达B2时，被认为是非法的连接请求(防火墙ACL中无E->F的允许策略)，报文丢弃。
    注：这与我们在B2上看到收到Reply，但未发送Reply报文的现象一致; 同时也解释了为什么增加双向策略后网络正常。
  5. 防火墙是不能改变洪泛后清理连接的模式，问题在于B2上为何没有服务器E的MAC地址。
    注：由于交换机C1、C2的链路聚合设置，服务器E的报文转发只会从聚合链路中选择一条路径传输，而不会向该聚合口下的所有链路转发。
    这就导致了防火墙B2可能从未收到过E发送的报文，也就不存在E的MAC地址。

四、故障结论

由于报文往返路径不一致，防火墙的洪泛后清理连接的机制，以及交换机聚合口数据发送原理，导致了这种异常网络现象的发生。
总结出现这类故障的特征：

  • 服务器间跨网段通信(需经防火墙、核心交换机)
  • 往返路径不一致，这是由交换机、防火墙根据局和端口的均衡算法决定的
  • 网络服务时断时连，由于报文转发过程只有往返链路不一时存在此故障

五、解决方案

临时解决：

防火墙ACL中对服务器间跨网段访问增加双向策略。(当前采用快速解决方案)

优化方案：

与防火墙、交换机厂商进一步确认均衡算法，优化往返链路为单一链路。
由于该方案设计多家厂商设备，该方案还需沟通后确认是否可行。

备用优化方案：

修改当前大二层拓扑结构，改为三层路由方式，从而避免洪泛导致的连接清理问题。
但该方案变化对网络拓扑影响较大，需指定详尽的计划方案和实施细则，避免对网络震荡。