route-map 生效验证
route-map 写完不等于生效，验证要分三层：先看策略本身（序列、条件、计数），再看具体前缀在 BGP 表里的属性与去留，最后看邻居方向上的接收与发布集合。策略改动后已建立的会话不会自动重新评估，还需要软重置。跳过最后一步，是「改了没用」类问题的头号原因。
基本信息
| 看策略 | show route-map <名>：序列、匹配条件与命中计数 |
|---|---|
| 看结果 | show ip bgp <前缀>：属性值与是否被过滤 |
| 看邻居 | show ip bgp neighbors <ip> routes / advertised-routes |
| 改后生效 | clear ip bgp <ip> soft in / soft out 触发重新评估 |
| 平台差异 | 华为 VRP 用 display route-policy 与 display bgp routing-table 组合核对 |
典型使用场景
- 新策略上线：逐条前缀确认属性与过滤结果符合设计
- 策略改完看不到效果：优先怀疑未做软重置或软重置方向搞错
- 对端反馈某段路由消失了：先查本端出向策略与发布集合
- 策略评审与审计：把命中计数作为「哪条序列在起作用」的证据
- 故障回滚：记录变更前的属性快照，回滚后逐项比对
排查流程
排查流程
# 1) 策略本身：序列与命中计数
show route-map RM-X
# 2) 结果：该前缀的属性与去留
show ip bgp 10.1.0.0/16
# 3) 邻居方向：从该邻居收到/向其发布的集合
show ip bgp neighbors 10.0.0.2 routes | include 10.1.0.0
show ip bgp neighbors 10.0.0.2 advertised-routes
# 4) 改完策略后触发重新评估
clear ip bgp 10.0.0.2 soft in验证检查点
| 层次 | 命令 | 判断依据 |
|---|---|---|
| 策略层 | show route-map | 序列顺序正确，条件与 set 动作符合设计 |
| 数据层 | show ip bgp <前缀> | LOCAL_PREF、MED、社区等属性已按预期变化 |
| 方向层 | neighbors routes / advertised-routes | 入向收到集合与出向发布集合分别正确 |
| 时效层 | soft in / soft out | 改后已学路由被重新评估，而不是停留在旧结果 |
部分平台的 route-map 命中计数只在特定场景累计，BGP 场景下不要单凭计数下结论，应以表中属性与通告集合的实际变化为准。
变更前先留基线：把前后缀数量、属性分布与关键前缀快照记下来，改完按同一口径再采一次对比。单条前缀看属性、整体看数量，比逐条翻表更快发现策略写宽或写窄。