M9000 RBM双主 NAT 地址池最后一个可用地址无法转换，同网段其他地址正常

在 M9000 RBM 双主 + NAPT（PAT） 场景下，地址池的最后一个地址经常因为端口分配 / ARP / 路由 / HA 资源冲突而 “单独失效”，尤其 /17 这种大段、掩码不规整、尾地址是 x.x.255.254 的情况非常典型。下面按 “最可能 → 次要 → 验证命令 → 规避方案” 给你完整排查思路。
一、最可能原因（90% 是这几个）
1）RBM 双主下，地址池最后一个 IP 发生 ARP 冲突 / 双主同时 ARP 响应
M9000 RBM 双主时，NAT 地址池不能包含设备接口 IP，也不能让两台设备同时对同一池 IP 应答 ARP。
地址池最后一个 IP：10.137.255.254
刚好落在 子网广播 / 边缘段，容易：
被上行网关当作 子网广播 / 黑洞
两台 M9000 都发 ARP 应答 → 上行交换机 / 路由器 ARP 表漂移、丢包
现象：同池其他 IP 正常，只有最后一个不通
2）NAT 端口块（port-block）分配到最后一个 IP 时 端口资源耗尽 / 分配失败
M9000 做 NAPT（PAT）时，会把地址池每个 IP 划分为端口块：
例如：10.137.255.1 ~ 10.137.255.254
前面的 IP 端口块正常分配
最后一个 IP：端口块被耗尽、或 HA 同步异常、或标记为 “full”
表现：display nat session 看不到用这个 IP 的会话；display nat address-group 显示该 IP used=100% 或 failed
3）10.137.255.254 被 黑洞路由 / 静态路由 / VRRP 占用
可能存在：
静态路由：ip route-static 10.137.255.254 32 NULL0（防环 / 黑洞）
VRRP 虚拟 IP 正好是这个
接口 IP、或被别的 VPN/VRF 占用
导致：匹配 NAT 后，转发时丢包
4）ACL 看似匹配 /16，但 隐含拒绝 /255.254 这类边界地址
比如 ACL 写：
plaintext
rule permit ip source 10.137.0.0 0.0.255.255
但某些版本 / 板卡对 host 255.254 存在 掩码边界 bug，或被隐含拒绝。
二、M9000 RBM 双主 NAT 特殊限制（重点）
官方明确：
双主 + PAT：必须一台 primary、一台 secondary，端口拆分，否则同 IP 端口冲突
地址池 不能包含接口 IP
双主模式下，最后一个 IP 极易出现分配异常（内部算法 / 边界处理问题）
三、排查命令（逐行敲，定位到根因）
1）看地址池状态（关键）
plaintext
display nat address-group
重点看：
10.137.255.254 的 Used、Free、Failed 计数
是否显示 In use 100% 或 Error
2）看该 IP 有没有 NAT 会话
plaintext
display nat session | include 10.137.255.254
display nat session verbose | include 10.137.255.254
完全没有 → 分配不到这个 IP
有会话但不通 → 路由 / 回程 / ARP 问题
3）查是否有黑洞 / 静态路由
plaintext
display ip routing-table | include 10.137.255.254
display ip routing-table vpn-instance xxx | include 10.137.255.254
看是否指向 NULL0、或其他接口。
4）查 ARP 冲突（RBM 双主必查）
plaintext
display arp | include 10.137.255.254
两台 M9000 都有这个 ARP → 冲突
5）查端口块分配（probe 视图）
plaintext
probe
display system internal nat statistics chassis 1 slot X cpu 1 | include fail
display nat port-block summary
看是否 port alloc failed、last ip full
四、快速解决方法（现场可直接操作）
方案 A：地址池 去掉最后一个 IP（最稳妥，立刻见效）
把地址池从：
plaintext
10.137.255.1 10.137.255.254
改成：
plaintext
10.137.255.1 10.137.255.253
避开尾地址，绝大多数现场这样就恢复
方案 B：RBM 双主严格配置 primary/secondary 端口拆分
主设备：
plaintext
nat remote-backup port-alloc primary
备设备：
plaintext
nat remote-backup port-alloc secondary
强制端口拆分，避免最后一个 IP 端口冲突
方案 C：排查并删除针对 10.137.255.254 的黑洞 / 静态路由
方案 D：ACL 精确放行，避免掩码边界问题
plaintext
rule permit ip source 10.137.0.0 0.0.255.255
rule permit ip source 10.137.255.254 0
五、总结一句话
M9000 RBM 双主 PAT 场景，最后一个 NAT 地址不通，99% 是 ARP 冲突、端口块耗尽、或尾地址被黑洞 / 路由占用。优先把地址池缩掉最后一个 IP，再检查 primary/secondary 配置，基本都能解决。

1. 检查是否触发了 HA/RBM 端口拆分冲突

• 排查命令：检查两台设备上是否正确配置了 nat remote-backup port-alloc primary 和 nat remote-backup port-alloc secondary 命令。
• 原因分析：如果未正确配置或配置遗漏，当大量并发流量命中该地址池时，极易导致资源分配冲突或端口耗尽，从而使得某些特定 IP 的转换失败。

2. 排查 ARP 响应异常（重点怀疑对象）

• IP 冲突检测：请确认 10.137.255.254 这个地址是否被意外配置为了 M9000 某台设备上行接口的物理 IP？在 HA 与 NAT 结合的组网中，NAT 地址池不允许包含两台设备上接口的 IP 地址。如果包含，上行设备请求该 IP 的 ARP 时，主、备两台设备都会回应，导致严重的 ARP 冲突。
• 免费 ARP 刷新问题：如果该地址池与接口在同一网段，请通过直连对端设备抓包或查看 ARP 表，确认 10.137.255.254 对应的 MAC 地址是否正确。有时设备割接或主备切换后，地址池中的个别 IP 未能成功发送免费 ARP，导致上游路由器 ARP 表项老化或指向错误。

3. 检查跨框/跨板卡处理异常

• OpenFlow 表项一致性：对于静态或动态 NAT，所有的 OpenFlow 规则都需要下发到主板卡上。请使用 display blade-controller-team default 确认当前哪块是主板卡，并检查对应 IP 的 OpenFlow 转发规则是否存在不一致的情况。
• 会话跨框问题：您可以尝试查看该 IP 不通时的会话表（Session）。如果发现部分流量被分发到了非预期的机箱（如 Chassis 2）处理，可能会因为跨框资源调度异常导致回包丢失。

4. 路由与基础连通性验证

• 对端路由检查：虽然同网段其他地址正常，但仍需确认对端（上行路由器）是否有明确的路由指向该单一 IP，或者存在更精细的子网掩码路由覆盖了 .255.254 所在的范围。修改本端 NAT 配置后，务必检查对端路由。
• Debug 追踪：建议在防火墙上开启针对该 IP 的 debug 开关（如 debugging nat error 或相关 ARP/NAT 调试），持续 ping 该地址，观察防火墙是否能收到外部的 ARP 请求报文，以及内部是否生成了 NAT 转换失败的报错日志。