让对端看到多条候选
默认情况下一条前缀只向邻居通告最优路径，其余候选路径对邻居完全不可见。Add-Path（RFC 7911）允许携带 path-id 通告多条路径，对端据此保留多份候选，从而在失效时更快切换，也便于路径分析。它改变的是信息面——通告内容变多、对端掌握更多候选，但转发仍然由接收端按自己的选路规则决定。
基本信息
| 标准 | RFC 7911 |
|---|---|
| 默认行为 | 仅最优路径对外通告 |
| Add-Path 行为 | 携带 path-id 通告多条路径，对端保留多份 |
| 能力要求 | 收发两端需能力协商一致，单向配置无效 |
| 典型用途 | 备份路径预置、快速失效切换、路径分析 |
| 资源影响 | 通告条目数增加，需评估会话与内存开销 |
典型使用场景
- 备份路径预置：让对端提前拿到多条候选，失效时快速切换
- 出口冗余设计：减少单条路径失效后的收敛等待时间
- 路由分析：需要采集或分析多条候选路径时
- 流量工程配合：与策略一起让对端看到更多可用路径
- 与监控配合：观测多路径通告与切换过程
配置与核对
配置与核对
router bgp 65001
address-family ipv4 unicast
bgp additional-paths send # 允许发送多条候选路径
neighbor 10.0.0.2 additional-paths receive # 允许从该邻居接收多条
neighbor 10.0.0.2 advertise additional-paths all # 指定通告范围
!
show ip bgp neighbors 10.0.0.2 # 确认 Add-Path 能力协商结果
show ip bgp 10.1.0.0 # 看多条路径与各自的 path-id要点与注意
| 项 | 说明 | 注意 |
|---|---|---|
| 能力协商 | send 与 receive 分别协商 | 单向配置不会生效，两端都要支持 |
| path-id | 标识同一前缀的不同路径 | 对端据此区分候选路径 |
| 通告范围 | 可指定全部或前若干条 | 范围越大，开销越高 |
| 转发行为 | 仍由接收端选路决定 | 不会自动变成多路径转发 |
| 与多路径区别 | Add-Path 属信息面扩展 | 转发面多路径需要另配条件 |
Add-Path 不是「多路径转发」：它让对端提前拿到多条候选，转发决策仍在对方手里；收益体现在失效切换更快、路径可见性更好，而不是带宽自动叠加。
开启前评估开销：通告条目数增加会同时影响本端与对端的会话资源与内存占用，邻居规模大或前缀数量多时应按实测数据评估，命令关键词也随平台版本略有差异。