策略排障的思路
定位「路由为什么没生效」时，先用表属性比对确认现象，再用受控范围的 debug 观察 UPDATE 的处理细节。debug 是放大镜而不是探照灯：范围限定不好会直接压满控制面。生产环境开启前要限定范围、避开业务高峰，并在同一时间准备好终止命令。
基本信息
| 表侧 | show ip bgp <前缀>、advertised-routes 确认现象 |
|---|---|
| 计数侧 | show ip bgp neighbors <ip> 的收发前缀计数 |
| debug 侧 | debug ip bgp updates in <acl> 限定观察范围 |
| 收尾 | undebug all 及时关闭，避免影响邻居保持 |
| 替代手段 | 软重置与路由刷新触发重新评估，比 debug 更安全 |
典型使用场景
- 路由被策略拦下，需要确认是哪一步拦截
- 对端说没收到，需要确认出方向实际发送内容
- 路由抖动定位：结合邻居日志与更新计数一起看
- 上线验证：策略变更后确认新旧路由的处理结果
- 生产环境谨慎使用：大范围 debug 只在隔离环境或维护窗口进行
受控 debug 示例
受控 debug 示例
access-list 99 permit 10.1.0.0 0.0.255.255 # 先限定观察范围
!
debug ip bgp updates in 99 # 仅观察该网段相关的入向更新
# 观察后立即关闭：
undebug all
!
show ip bgp neighbors 10.0.0.2 | include updates|prefixes # 用计数交叉验证手段与代价
| 手段 | 代价 | 适用时机 |
|---|---|---|
| 查表比对 | 无额外开销 | 任何时候，首选 |
| 软重置或刷新 | 可控 | 策略改动后触发重新评估 |
| 受控 debug | 中等，需限定范围 | 需要观察处理细节时 |
| 全量 debug | 高，可能压满控制面 | 生产环境基本不建议 |
计数与表项是最廉价的证据：邻居的收发计数变化能快速区分「没发」「发了没收到」「收到了没入表」三种情况，比 debug 更安全也更快。
限定范围是使用前提：用 ACL 圈定观察对象后，输出量会下降一个量级，同时也更容易在日志里找到目标路由。
忘记关闭 debug 是常见事故：控制面负载上升可能影响邻居保持与会话稳定，建议开启的同一次操作里就准备好 undebug all，并设置定时确认。