收敛调优的几个抓手
BGP 收敛慢通常不是单一原因，而是「检测慢、计算慢、通告慢」叠加的结果。检测环节靠 Hold 定时器，默认 180 秒，因此首要抓手是用 BFD 把故障发现降到毫秒或亚秒级。计算环节与下一跳解析有关：默认情况下前缀要等下一跳可达性确认后才参与优选，逐前缀等待会累加时间，开启下一跳跟踪可以让解析结果变化后统一触发更新。通告环节涉及更新打包与发送节奏，设备重启后的 update-delay 决定等待时间，用来避免刚启动就把不完整的表发出去。调优原则是先量化基线，再逐项调整，一次只改一个变量。
基本信息
| 检测环节 | BFD 替代长时间等待 Hold 到期 |
|---|---|
| 计算环节 | 下一跳跟踪减少逐前缀等待 |
| 启动环节 | update-delay 影响重启后的通告节奏 |
| 通告节奏 | 更新打包与发送间隔影响邻居处理压力 |
| 基线方法 | 变更前后用同一口径测量收敛时间 |
| 观察 | 邻居 uptime、更新计数与路由表变化时间点 |
典型使用场景
- 主备链路切换时间不达标：定位是检测还是收敛环节拖慢
- 设备重启后邻居抖动：评估 update-delay 设置是否合理
- 大规模邻居场景：减少不必要的更新风暴
- 割接后验收：用统一指标证明调优有效
- 故障复盘：确认收敛时间是否符合设计预期
常用命令
常用命令
# 邻居级快速检测
router bgp 65001
neighbor 203.0.113.2 fall-over bfd
# 下一跳跟踪相关参数
bgp nexthop trigger delay 1
# 设备重启后的通告等待
bgp update-delay 60
! 观察与验证
show ip bgp summary | include 203.0.113.2
show ip bgp neighbors 203.0.113.2 | include uptime|updates
show bfd neighbors抓手与代价
| 抓手 | 收益 | 代价 |
|---|---|---|
| BFD 联动 | 检测降到亚秒级 | 增加会话与资源开销 |
| 下一跳跟踪 | 减少逐前缀等待 | 需评估内存与 CPU |
| 调小 Hold | 检测更快 | 抖动时误断，全表重收敛 |
| update-delay 调整 | 重启后通告更稳 | 过大时延长可用时间 |
| 一次改多项 | 看似省事 | 无法定位是哪项生效或恶化 |
收敛时间的测量口径要固定：从故障注入到业务流量恢复，或从邻居断开到路由更新完成，两者得出的数字差别很大，对比时必须同一口径。
全网设备同时启用快速检测可能导致同时收敛与更新风暴，建议先在关键链路上试点并观察 CPU 与邻居稳定性。