防火墙IRF，二层聚合，哈希极化，nat harpin

一、核心问题：NAT Hairpin 跨板卡限制

故障根因拆解

1. 业务流程异常
   内网用户访问公网映射地址时，报文需要经过两次 NAT 转换：
   • 目的 NAT：公网 IP 转换为服务器私网 IP（nat server）
   • 源 NAT：内网 IP 转换为防火墙内网口地址（nat hairpin）
     当这两个转换分别在不同板卡处理时，板卡间转发会导致 NAT 会话状态丢失，无法完成双向转换。
2. 故障现象匹配
   • 外网访问正常：外网访问仅需一次目的 NAT，且流量始终通过出口板卡处理，无跨板卡问题。
   • 部分内网用户正常、部分异常：由聚合链路的哈希算法决定流量走向，部分流量刚好命中同一板卡的链路，因此可以正常访问；命中跨板卡链路的流量则失败。
   • 关闭主核心与备防火墙的互联端口后故障恢复：此时所有内网流量只能通过同一台防火墙的同一板卡处理，规避了跨板卡限制。

二、次要问题：聚合链路哈希极化放大故障

• 内网主机的源 IP / 源 MAC 哈希值固定，导致部分主机的流量始终被调度到跨板卡的链路，表现为 “部分电脑无法访问”。
• 调整负载分担模式仅能改变流量分布，无法解决跨板卡的底层限制，因此无法根治问题。

三、分步解决方案（按优先级排序）

方案 1：调整接口物理位置（根治方案）

1. 配置 nat server/nat outbound 的公网接口（如 G1/2/5/0 移动①、G1/2/6/0 联通①）
2. 配置 nat hairpin enable 的内网接口（如 XGE1/2/1/2）
3. 核心交换机与防火墙互联的聚合接口（如 XGE1/4/0/23）
   注意：两台防火墙 IRF 堆叠环境下，需确保主备防火墙的对应接口也满足同一板卡要求。

方案 2：临时规避方案（业务无中断调整）

1. 修改 NAT 配置，将内网用户流量强制调度到同一板卡
   • 调整策略路由，将访问公网映射地址的流量固定转发到某一台防火墙的同一板卡接口。
   • 或在核心交换机上修改聚合链路的负载分担模式，让所有内网用户的访问流量都命中同一板卡的链路（仅临时生效，无法根治）。
2. 调整 NAT 会话同步与转发参数
   • 开启防火墙的会话同步功能（session enable），并确保主备防火墙的会话表同步正常。
   • 关闭聚合接口的本地转发优先（undo link-aggregation local-preference enable），减少跨板卡转发概率。

方案 3：备选方案（不推荐，仅应急使用）

• 在内网接口配置 nat outbound，将内网用户的源 IP 转换为防火墙内网口地址。
• 同时配置 nat server，将公网 IP 映射为服务器私网 IP。
• 但此方案需额外配置安全策略，且性能不如原生 NAT Hairpin，不建议长期使用。

四、关键验证步骤

五、补充说明

• 跨板卡限制是 Comware V9 平台防火墙的底层限制，与 IRF 堆叠无关，必须通过调整接口位置解决。
• 哈希极化问题仅会影响故障表现（部分用户正常 / 异常），不是根本原因，仅调整负载分担模式无法解决问题。
• 建议优先采用方案 1 调整接口位置，从根本上解决 NAT Hairpin 跨板卡问题。

NAT hairpin与不同的地址转换配合工作时，这些配置所在的接口必须在同一个接口板，否则NAT hairpin功能无法正常工作，试试全局策略nat

你的怀疑非常准确，这个问题确实是板卡限制和IRF流量跨框两个因素叠加导致的。

 根本原因：NAT Hairpin 的板卡限制

H3C 官方配置指导中明确规定：

NAT hairpin 与不同的地址转换配合工作时，这些配置所在的接口必须在同一个接口板，否则 NAT hairpin 功能无法正常工作。

在你的环境中：

• 出接口（NAT Outbound 口） 在防火墙的某一个接口板上（例如 Slot A）

• 内网口（NAT Hairpin 口） 在防火墙的另一个接口板上（例如 Slot B）

这直接触发了“跨板卡”的限制，导致 NAT Hairpin 功能工作异常。

 为什么“部分电脑正常、部分异常”

这个现象是板卡限制和聚合链路哈希负载分担共同作用的结果。

核心交换机将多台内网 PC 的流量通过二层聚合链路发送给防火墙 IRF 集群。聚合链路基于哈希算法（如源目 IP、源目 MAC 等）将不同 PC 的流量分配到不同的物理成员链路上。这些成员链路分别连接着防火墙的主框（Master）和备框（Backup）。

流量路径的两种情况：

你关闭了主核心与备防火墙互联的端口后故障恢复，正是因为强制所有流量都必须走主防火墙，从而绕过了备框上的板卡不一致问题。这也佐证了故障是由跨框流量 + 板卡限制共同引起的。

 解决方案（按推荐优先级排列）

 方案一：将 NAT Hairpin 内网口与出接口调整到同一接口板（立即可行）

将当前内网口上的 NAT Hairpin 配置迁移到与出接口（NAT Outbound 口）在同一个接口板上的另一个内网口，或者反之将出接口迁移到与内网口同一板卡。

具体步骤：

1. 确认当前 NAT Outbound 所在的接口板卡位置，例如 GigabitEthernet1/0/1 在 Slot 1 上

2. 确认当前 NAT Hairpin 所在的内网接口板卡位置

3. 将 NAT Hairpin 功能重新配置在与出接口同一板卡的内网口上

 注意：NAT Hairpin 功能与内部服务器配合工作时，必须通过 protocol 参数指定协议类型，否则 NAT Hairpin 功能不生效。

 方案二：在聚合口下指定统一的流量处理板卡（推荐，适用于跨框场景）

在防火墙的聚合口下，使用 service chassis 命令指定所有成员口的流量都由同一个框的同一块板卡来处理：

 方案三：使用冗余组/冗余口替代 IRF 双主（最佳实践）

H3C 官方明确建议：防火墙堆叠最好使用冗余口冗余组，而非 IRF 双主 + 聚合口的方式。

开启会话同步，对于只转发的流量没问题，但是对于做 NAT、做 VPN 等的业务还是会有异常。推荐是主备运行冗余组冗余口配置。

如果要彻底避免此类问题，可以考虑将防火墙从 IRF 双主模式调整为 RBM（主备冗余组） 模式：

• 使用 redundancy group 和 redundancy interface 进行配置

• 结合 NQA 检测上联状态来判断出口情况

• 下行接口 down 时，上行也会同时切换，保证流量走单边

 补充验证建议

在实施上述任一方案前，可以做以下验证来确认诊断：

1. 检查接口所在板卡：执行 display interface <接口名> verbose 查看各接口所在的 slot 号

2. 检查聚合口负载分担配置：执行 display link-aggregation verbose 查看聚合口的成员口分布和哈希算法

3. 检查 NAT 会话表：当内网主机访问失败时，执行 display nat session slot <slot-number> 查看 NAT 会话是否在备框上未被正确创建