S125交换机NSR状态

正常现象：TCP NSR状态在Ready和Not ready之间动态变化是正常行为。

Not ready：表示NSR正在将BGP协议状态和数据（如邻居信息、路由表）从主进程备份到备进程，此时备份未完成。

Ready：表示备份已完成，备进程已具备无缝接管主进程的能力。

触发条件：

初始启用NSR时，首次备份需一定时间（状态为Not ready）。

当BGP路由表更新、邻居状态变化或周期性同步时，会重新触发备份流程，状态短暂切换为Not ready，完成后恢复Ready。

无业务中断：
状态切换过程不会影响当前BGP会话和转发业务。主进程仍正常处理流量，备份仅在后台异步进行。

主备倒换时的保障：

若状态为Ready：主进程中断（如主控板故障、协议重启）时，备进程可立即接管，业务中断时间**≤5秒**（启用NSR的典型值）。

若状态为Not ready：主进程中断会导致BGP会话重建，业务中断时间**≈20秒**（未启用NSR的默认超时时间）。

如果这种波动是偶尔、有规律地出现（例如在批量路由学习或主备板卡同步数据时），通常属于正常现象，对现网业务影响很小。但如果长时间停留在 Not ready 或频繁震荡，则可能存在隐患。

为了让你更放心，我来具体解释一下背后的原因和可能产生的影响。

 什么是 TCP NSR？

首先，简单解释一下这个机制。NSR（Non-Stop Routing，不间断路由）是一种高可靠性技术，目的是确保当设备的主控板发生主备倒换时，路由转发不中断，对邻居设备完全透明 。

你看到的 TCP NSR 正是为了实现这一目标，负责将 TCP 连接的状态（包括 BGP 会话等信息）从主进程实时备份到备用进程。这就像是在给飞行中的飞机配备一个“副驾驶”，主驾驶（主进程）的一举一动，副驾驶（备进程）都要时刻同步并准备接手。

 状态波动的原理：为什么会有 Ready 和 Not ready？

基于 H3C 设备的设计原理，这两个状态的含义如下：

• Ready：表示 TCP 连接信息已经成功、完整地从主进程备份到了备进程。此时“副驾驶”已经完全掌握了飞行状态，随时可以无缝接管。

• Not ready：表示备份过程正在进行中，或者同步尚未完成。

因此，状态在两者之间波动，通常发生在以下几种场景：

1. 批量路由学习或大量邻居建立时：当设备同时学习到海量路由，或者有多个 BGP 邻居同时建立连接时，主进程会生成大量的连接状态信息。备份进程需要时间来消化和处理这些信息，在此期间状态可能短暂显示为 Not ready，处理完成后又恢复为 Ready。

2. 主备板卡间的批量数据同步：即使业务平稳运行，主控板也可能定期或在特定触发条件下，将核心数据与备用板卡进行全量或增量同步。这种后台同步任务也会导致状态的短暂波动。

3. 设备 CPU 负载波动：如果设备本身 CPU 负载较高，处理备份数据的优先级可能会临时降低，导致备份进程响应变慢，状态出现短暂的不一致。

 有什么影响吗？

• 如果波动是短暂的且有规律：如上所述，这属于设备内部正常的数据同步过程，对现网的业务转发和 BGP 邻居关系几乎没有影响。因为 NSR 的设计目标就是确保在主备倒换瞬间才使用备份数据，平时只要大部分时间状态是 Ready，就能保证关键时刻的可靠性。

• 如果状态长时间（如持续几分钟以上）停留在 Not ready：这可能意味着备份进程出现了异常，比如主备通信链路不稳定、备份队列堵塞或备板卡故障。这种情况下，如果恰好在此时发生主备倒换，由于“副驾驶”还没准备好，就可能导致 TCP 连接中断，进而引发 BGP 会话重建和路由震荡，对业务产生影响。

• 如果状态频繁、快速地在 Ready/Not ready 之间震荡：这可能暗示着主备数据同步存在缺陷，或者有某种机制在反复触发全量备份。这虽然不一定会立即中断业务，但会增加主备板卡的处理负担，是需要关注的风险信号。

 给你的建议

1. 观察规律：你可以在不同时间段（如业务高峰期和低谷期）多执行几次 display bgp non-stop-routing status 命令，看看状态的波动是否与网络变化（如大量路由发布）相关。

2. 检查备板卡状态：同时关注备用主控板（Slot 1）的 CPU 和内存利用率，确保其有足够的资源处理备份任务。

3. 查看日志：可以检查设备的日志信息，看是否有关于主备通信异常或备份进程出错的记录。

一、核心结论先明确

二、先解释「正常 vs 异常」的边界

1. 正常情况下的状态变化（仅两种场景）

• 场景 1：设备刚启动 / 主备进程刚建立时 → 短暂Not ready（几秒内）→ 稳定到Ready；
• 场景 2：主备倒换完成后 → 备进程重新同步 TCP 连接信息 → 短暂Not ready（通常≤10 秒）→ 稳定Ready。

2. 你当前的异常点

三、具体影响（按严重程度排序）

1. 最核心影响：BGP NSR 失效，主备倒换时 BGP 会话中断

• BGP 会话基于 TCP 连接（端口 179），TCP NSR 负责把主进程的 TCP 连接状态（如序列号、窗口大小、连接标识）备份到备进程；
• 若 TCP NSR 状态频繁Not ready，备进程没有完整的 TCP 连接备份 → 主备倒换时，备进程无法接管原有 TCP 连接，只能重新建立 BGP 会话；
• 后果：倒换期间 BGP 路由丢失，依赖 BGP 的业务（如跨域路由、公网出口、VPN）会出现秒级甚至数十秒级中断，严重时触发路由震荡。

2. 次要影响：设备资源消耗增加

• 主进程需不断重新封装 TCP 连接信息发送给备进程；
• 备进程需反复接收、解析但无法完成备份，导致进程占用率升高；
• 长期下来可能出现设备 CPU 偏高（尤其是主控板），甚至影响其他协议（如 OSPF、PIM）的正常运行。

3. 隐性影响：故障定位难度加大

四、为什么会出现这种现象？（常见根因）

1. 主备主控板通信异常
   • 主控板间的心跳链路（如集群链路、备板同步通道）丢包 / 延迟高；
   • 主备板的板间通信协议（如 VRRP/IRF 的同步通道）故障，导致 TCP 连接信息传输不完整。
2. TCP 连接数量 / 状态异常
   • BGP 对等体数量过多（如数百 / 数千个 BGP 邻居），TCP 连接信息超过备板同步能力；
   • 部分 BGP 会话的 TCP 连接处于异常状态（如半开连接、FIN_WAIT 状态），同步时触发备进程解析失败。
3. 设备软件 / 硬件问题
   • 设备系统版本存在 TCP NSR 同步的 BUG（尤其是早期版本）；
   • 备主控板内存不足、进程异常（如备板 BGP 进程占用率 100%），无法接收备份信息。

五、排查与解决步骤（可直接操作）

步骤 1：先确认状态切换的频率和触发条件

• 若日志中有 “TCP NSR sync failed”“standby channel error” → 优先排查主备板通信；
• 若日志中有 “memory insufficient” → 排查备板内存。

步骤 2：检查主备主控板的基础状态

步骤 3：临时缓解 + 长期解决

步骤 4：验证修复效果

• 若 TCP NSR status 稳定为Ready → 修复成功；
• 若仍切换 → 建议联系厂商技术支持，抓取 NSR 同步的 debug 日志（debugging bgp nsr）定位根因。

总结

1. 状态切换异常：TCP NSR 在Ready/Not ready间反复切换是异常的，正常仅启动 / 倒换时短暂Not ready；
2. 核心影响：BGP NSR 失效，主备倒换时 BGP 会话中断，引发业务闪断，同时增加设备资源消耗；
3. 排查重点：先查主备板通信状态，再查备板资源（CPU / 内存），最后排查系统版本 BUG 或 BGP 连接异常。