M9K RBM组网+会话引流网络不通

一、先理清你的故障核心本质（分布式架构关键坑）
M9K 是分布式业务板卡架构，每块 slot 业务引擎独立维护本地会话表；你现象：
外网访问201.10.4.23:4236，SYN 从 slot1 入，slot1 本地生成完整 NAT Server 会话；
服务器回程 SYN+ACK 从 slot2 入，slot2 虽然能查到全局同步会话，但本地无 NAT 转换缓存 + ASPF 严格状态校验，直接判定为首包非法丢弃；
安全策略全部放通、两块板都能查到会话，依然不通，是会话引流 + 跨板 NAT+ASPF 强状态检测叠加导致，和 RBM 双机会话同步无关（同机跨板问题）。
关键前置：你的 NAT Server 配置特点
plaintext
nat server protocol tcp global 101.23.4.10 4236 inside 192.168.89.3 4236 vrrp 1 rule ServerRule_2
绑定 VRRP，属于全局静态目的 NAT；会话引流后流量按五元组 hash 分配业务板，去回程 hash 分到不同 slot，触发跨板异常。
二、6 层排查 + 修复（按优先级执行）
1. 必开：会话 ASP 非对称跨板支持（最高发缺失配置）
M9K 会话引流场景，跨业务板不对称流量必须开启session asp，让回程板卡可全局检索完整会话、完成反向 NAT 转换，否则仅本地会话生效：
plaintext
system-view
# 开启非对称路径会话兼容（同机跨板核心命令）
session asp
# 会话快速备份，新建会话立刻同步所有业务板本地缓存
session synchronization fast-backup enable
# 会话状态机宽松模式，适配不对称回程
session state-machine mode loose
作用：slot2 收到回程包，不再只查本地会话表，通过 ASP 读取 slot1 同步的完整会话五元组、NAT 映射，正常转换公网 IP→内网 192.168.89.3。
2. 会话引流全局一致性校验（引流分发不均导致跨板）
① 确认会话引流全局开启、所有业务板生效
plaintext
display session steering configuration
display blade-controller-team default
必须满足：
全局session steering enable；
所有业务 blade 加入同一分发组，无单独关闭引流的 slot；
若仅部分 slot 开启引流，五元组 hash 分流错乱，来回必然跨板。
② 禁止针对 NAT Server 流量特殊分流策略
不要配置基于目的公网 IP 的 QACL 分流，会强制拆分正反向流量到不同板卡。
3. NAT Server + 会话引流特殊限制（静态 NAT 双向缓存同步）
M9K 会话引流场景，全局 nat-server 的反向 NAT 缓存不会自动同步到所有业务板本地，回程 slot2 缺少本地目的转换条目：
修复方案二选一
方案 A（推荐，无需改组网）：全局静态双向 NAT 替代 nat-server
nat-server 依赖会话做反向转换；双向 static nat 不依赖会话，任意板卡收到报文均可直接转换，完美适配跨板不对称流量：
plaintext
# 删除原有nat server
undo nat server rule ServerRule_2
# 双向静态NAT，任意业务板都存在转换条目
nat static global 101.23.4.10 inside 192.168.89.3 netmask 255.255.255.255 vrrp
# 限定仅TCP 4236，等价原端口映射
acl number 3000
rule permit tcp destination 101.23.4.10 eq 4236
nat static enable acl 3000
方案 B（不改 nat-server，临时兼容）：开启 NAT 表全局同步
plaintext
system-view
nat synchronization enable
同步所有静态 NAT、NAT Server 映射到每块业务板本地缓存，回程 slot2 自带转换条目。
4. 关闭 / 宽松 URPF，避免回程跨板 URPF 校验失败
回程 slot2 收到服务器回包，源 IP 是内网 192.168.89.3，slot2 本地无入接口直连路由，严格 URPF 直接丢弃：
plaintext
# 所有外网/内网三层接口下配置宽松URPF
interface Vlan-interface XX
urpf loose allow-default-route
# 或临时测试关闭urpf
undo urpf
5. ASPF 状态检测优化（TCP 回程报文误判首包）
默认 ASPF 只认入板卡发起的 SYN 为合法首包，跨板回程 SYN+ACK 会被当成非法新建连接：
plaintext
system-view
# 允许跨板匹配会话后的回程TCP报文跳过首包校验
aspf cross-board session-match enable
# 加长TCP会话超时，避免会话同步延迟老化
session timeout tcp syn 30
session timeout tcp established 3600
6. RBM 配套校验（双机场景补充，你同机跨板也要核对）
如果是 RBM 双机热备，额外确认：
plaintext
remote-backup group
backup-mode dual-active
hot-backup enable
hrp asymmetric enable
hrp mirror session enable
保证整机所有会话、NAT 表项同步到对端防火墙。
三、快速定位丢包根因（debug / 查看命令）
1. 查看两块板卡会话详情
plaintext
# 指定slot1查看正向会话
display firewall session table slot 1 verbose source 201.10.4.23 destination 101.23.4.10 eq 4236
# 指定slot2查看回程会话缓存
display firewall session table slot 2 verbose source 192.168.89.3 destination 201.10.4.23
现象：slot1 有完整 NAT 转换记录，slot2 仅五元组会话、无 nat 转换信息。
2. 抓丢弃原因（核心定位）
plaintext
debug firewall packet-filter
debug aspf packet
terminal debugging
terminal monitor
回程报文报错关键字：
dropped by aspf illegal first packet 跨板无 ASP 支持；
dropped by urpf check failed URPF 严格校验拦截；
no nat mapping entry match 回程板卡无 NAT Server 本地缓存。
四、最简一键修复配置（复制直接部署）
plaintext
system-view
# 1. 开启跨板非对称会话支持
session asp
session synchronization fast-backup enable
session state-machine mode loose
aspf cross-board session-match enable
# 2. NAT表全局同步，适配nat-server跨板
nat synchronization enable
# 3. 宽松URPF（所有三层接口统一配置）
interface-range Vlan-interface all
urpf loose allow-default-route
# 4. 会话引流完整性校验
session steering enable
# 5. 优化TCP会话超时
session timeout tcp syn 30
session timeout tcp established 3600
执行完成后清空现有会话测试：reset firewall session table all，外网重新访问 201.10.4.23:4236。
五、根本优化方案（长期稳定，避免跨板）
原进原出绑定：外网接口配置ip last-hop hold，强制回程流量从原入板卡接口返回，从根源消除跨板；
plaintext
interface 外网三层接口
ip last-hop hold
业务分流规划：NAT Server 公网流量单独 hash 到固定 slot，避免五元组随机分发跨板；
优先双向 nat static 替代 nat-server，消除跨板 NAT 缓存缺失问题。

根据你的描述，在M9K RBM组网中，流量经过不同板卡（slot1和slot2）导致业务不通，是开启了会话引流功能后，由于流量路径不对称而引发的典型问题。

🔍 问题原因分析

会话引流功能本身是为了将流量引到正确的业务板上处理，但在你的场景中，请求和响应流量被哈希到了不同的业务板。

• 会话引流的工作原理：当正向流量的第一个报文到达防火墙并建立会话后，会话引流模块会根据五元组（源IP、目的IP、源端口、目的端口、协议）进行HASH计算，来决定后续流量（包括反向流量）由哪块业务板处理。

• 流量不对称：在你的场景中，请求流量（201.10.4.23 -> 101.23.4.10）被哈希到了slot1，而响应流量（192.168.89.3 -> 201.10.4.23）被哈希到了slot2。

• 安全策略检查与NAT转换问题：防火墙基于会话转发。slot2在处理响应流量时，必须能够匹配到由slot1同步过来的会话表项，并执行正确的NAT转换（将192.168.89.3转换回101.23.4.10）。如果slot2上的会话表项或NAT转换存在任何问题，就会导致业务不通。

🛠️ 详细排查步骤

建议按照以下步骤，系统地排查问题：

1. 检查RBM会话同步状态：这是最基础的一步。在设备上执行命令，确认slot1和slot2之间的会话同步功能正常。

   text

   display rbm session synchronization status

2. 检查NAT Server绑定的VRRP状态：你的NAT Server配置中绑定了vrrp 1。请确认这个VRRP备份组的状态是正常的（即Master设备是活跃的）。

   text

   display vrrp brief

3. 检查slot2上的回程会话和NAT转换：这是排查的核心。既然响应流量由slot2处理，就需要检查它上面的会话信息。

   • 在slot2上执行命令，查看响应流量的会话详情：

     text

     display session verbose source-ip 192.168.89.3 destination-ip 201.10.4.23

   • 重点检查会话中的NAT转换信息，确认源IP 192.168.89.3 是否被正确转换为 101.23.4.10。如果转换不正确或会话缺失，流量必然不通。

4. 检查slot2上的安全策略：确认slot2上是否有针对回程流量（源192.168.89.3，目的201.10.4.23）的放行策略。

   text

   display security-policy rule name <策略名称>

5. 开启“备份上一跳”功能（关键修复步骤）：当流量出入接口不同且存在多业务板时，需要开启此功能，以确保上一跳信息能在板卡间同步。

   • 根据你的软件版本，选择对应的命令：

     • D045分支：ip last-hop backup enable

     • D071分支：last-hop backup enable

   • 此命令通常在系统视图下配置。

6. 抓包验证：如果以上步骤都正常但问题依旧，建议进行抓包分析。

   • 在slot1的入接口抓取请求包（201.10.4.23 -> 101.23.4.10）。

   • 在slot2的出接口抓取响应包（192.168.89.3 -> 201.10.4.23）。

   • 通过对比，可以确认流量是否真的到达了slot2，以及slot2是否正确发出了响应包。

可以坐下流量统计或者抓包，确认下流量是否是丢在防火墙上了