摘要
- RFC 7911 把路由在线路上的识别方式,从单独的前缀扩展为“前缀加四字节本地 Path Identifier”,使同一前缀的多条通告能够在已经协商的方向上共存。
- 发送方仍决定公开哪一组路径;接收方仍决定进口过滤、最优路径、multipath 与 FIB。Path Identifier 不是排名、全局身份、来源证明或物理多样性证明。
- 安全部署必须证明每个 AFI/SAFI 的实际方向、精确收发集合、状态成本、单路撤回和转发结果。多看见几条路由,不等于多得到几条可用出口。
路由反射的核心是一种信息压缩。全互联 iBGP 让每个 speaker 直接听到多方候选路径,route reflector 则替客户执行一次选择,通常只反射自己认定的 best path。客户拿到结论,却未必拿到产生结论的全部候选项。
这种交换常常值得:少得多的会话换来可管理的网络。但被隐藏的路径也可能恰好是客户策略愿意接受的那一条、首选出口故障后仍然存活的那一条,或者从客户自身 IGP 位置看成本更低的那一条。会话完全健康,并不意味着客户看到了基础设施能够提供的全部选择。
传统 BGP 的隐式替换进一步强化了这项压缩。同一邻居再次通告相同 NLRI 时,新通告替换旧通告。前缀就是来自该邻居的路由键。只靠基础协议,同一会话无法让两条同前缀通告同时存在并分别管理其生命周期。
RFC 7911 在 NLRI 前加入四字节 Path Identifier。线路上的有效键变成“前缀加标识符”。相同组合的新通告只替换这一个对象;撤回一个组合也只删除这一路径。若撤回携带一个从未出现过的标识符,接收方应该忽略,而不是把整个前缀的所有路径清空。
这个号码的含义刻意很窄。它由通告方针对本地会话分配。路由器重新通告上游路径时会生成自己的标识符,并不会把上游号码作为端到端标签转发。控制平面重启后,号码可能重新分配。接收方不能从数值大小推断优先级、年龄、质量、来源或可信程度。
因此,Path Identifier 适合协议记账,却不适合充当业务身份。监控系统若把两个反射器各自的“路径 17”当作同一对象,会制造不存在的关联。重启验收若要求号码保持不变,也会把本地令牌的连续性误当作路由连续性。真正应比较的是属性、角色、下一跳和转发关系。
ADD-PATH 的协商不是整个会话的单一开关。能力码 69 中的每个 tuple 都包含 AFI、SAFI 与方向:接收、发送或双向。只有同一地址族中,发送方通告 send、接收方通告 receive,多个路径的编码才在这个方向有效。
这意味着一个会话可以只在 IPv4 unicast 的一个方向传递多路径,而反方向或 IPv6 仍保持经典单路径语义。反射器可以向客户公开更多路径,却不接受客户送回的全部候选项。“已经启用 ADD-PATH”没有说明这张方向矩阵,因而不能成为变更证据。
能力只允许运输,不负责挑选货物。RFC 7911 表示发送方应当包含自己的最佳路径,除非该路径正是从接收邻居学来的;标准并没有要求发送所有可用路径。实现可以选择全部、固定 N-best、每个相邻 AS 的 best、满足 multipath 的集合,或由策略定义的其他子集。
选择算法决定功能有没有价值。两条路径若共享同一个下一跳、机房、线卡、上游和光缆故障域,只会增加两个控制对象,并没有增加第二条逃生通道。每个相邻 AS 一条路径能够改善商业关系层面的多样性,却可能在物理层继续共路。标识符数量只统计状态,不能统计独立命运。
RFC 7964 在 MED 引发持续振荡这一较窄问题中展示了取舍。“all available paths”接近全互联所拥有的信息一致性,但状态最多。“Group Best”在特定拓扑约束下只提供每个相邻 AS 的最佳路径,集合更小。后一方案针对特定机制成立,不能被包装成所有 ADD-PATH 场景的通用答案。
接收方看到更多路径之后,决策权并未转移。它仍可按进口策略拒绝路由,只选一条 best,选出 multipath 集合,或把替代项留在控制平面而不安装。RFC 7911 没有改写 RFC 4271 的 Decision Process,也没有自动开启 ECMP,更没有要求硬件接收所有候选项。
所以,“客户收到四条路径”与“客户拥有四条独立出口”之间隔着完整证据链。有的路径可能被过滤,有的下一跳无法解析,有的最终递归到同一个 FIB 邻接。有时 Loc-RIB 接受的 multipath 数量还会超过硬件能力。只有从 Adj-RIB-In 经过 policy、选择、递归,直到 FIB 与实测数据包,结论才站得住。
IXP route server 的 path hiding 是可见性价值最清晰的案例。RFC 7947 描述:route server 先选出一条路径,但这条路径可能被某个客户的策略拒绝;服务器上另有一条该客户本可接受的候选路径。若服务器只发送自己选中的一条,客户最终无路可用。客户策略没有错误,错误在于输入集合过窄。
ADD-PATH 可以扩大输入,但信任边界不能被忽略。RFC 7947 警告,route server 若双向使用 ADD-PATH,可能把客户侧非活动、无效或次优路径继续传播。针对这一特定环境,文档建议服务器只 send、客户只 receive。它反映的是“不亲自转发流量的 IXP 协调设施”所需的权力分配,不是所有内部 RR 都应照抄的模板。
在一个 AS 内,不同客户收到不同数量或集合的路径也可能合理。边缘节点可能需要多样出口,资源有限的设备则只适合较小集合。但每项差异都必须有明确角色、地址族、算法、上限和收敛目标,否则故障期间无人能解释某台客户原本有权看到什么。
额外状态有真实成本。RFC 7911 明确指出,大量前缀的多路径接收可能耗尽内存或加剧全网不稳定。每一条新增路径都要占用 RIB、属性引用、策略计算、更新处理和遥测容量。平静时储存的备用项,会在故障时变成大规模 best-path 计算与撤回洪峰。
RFC 6774 从另一种多样路径分发架构抵达同一治理边界。减少 path starvation、让备用路径在故障前可见,必然增加副本和处理。可见性不是免费能力,而是一项资源分配;它需要预算、准入限制和可验证的收益。
生产实现把这些层次直接暴露为不同配置。Cisco 把能力、额外路径选择和通告分开;Junos 区分本地 send/receive 意图与实际协商状态;FRRouting 提供 all、per-AS-best、N-best 等发送方式,并提供接收限制。这些是产品行为而非协议保证,却准确列出了审批记录应当回答的问题。
部署证据首先是一张授权矩阵。对每个 peer 和 AFI/SAFI,记录本地实际通告的模式、从对端实际收到的模式,以及据此导出的双向有效状态。随后记录发送方选择算法、最大条数、出口过滤,以及普通最佳路径是否保证包含在集合中。
基线必须保存精确集合,而不只是计数。发送侧 Adj-RIB-Out 要有前缀、本地 Path Identifier、下一跳、AS_PATH、origin、MED、community 和入选原因;接收侧保存对应 Adj-RIB-In、过滤结论、best-path 原因与 multipath 资格。不同 speaker 的号码不得作为全局键相连。
替换和撤回测试必须围绕完整组合。使用同一标识符重新通告变化后的属性,只能改变该路径;撤回一个标识符,兄弟路径必须保留;撤回未知标识符,已有路径不得消失。这些操作可以揪出仍然以“只有前缀”为身份的监控器或自动化。
重启测试不能要求标识符持久。验收对象是旧号码是否干净消失、预期属性的路径是否在时限内重现、备用项是否仍可选,以及 FIB 是否留下孤儿。数字变了并不代表路径变了,数字不变也不能证明转发没有变。
多样性必须按故障域测量。下一跳、相邻 AS、站点、链路、线卡、供应商、光缆与策略域的重合,都比路径计数更重要。若无法获得某一层信息,正确的状态是“未知”,而不是因为出现两个标识符就宣布冗余。
最终测试应真正移除首选出口。观察已经可见的备用项能否无需远端重新探索就成为 best,记录 update 量、选择时间、下一跳解析、FIB 编程和丢包。还应重复测试一条被过滤的替代项、一条递归失败的替代项,以及一条与首选共享故障域的替代项。
容量需要预先形成准入契约:每邻居、每地址族、每前缀的路径上限,内存门槛,update 速率,遥测保留期限,以及越界时的明确行为。接收方若静默丢弃任意路径,就会在“能力已协商”的漂亮状态后面重新制造 path hiding。
回滚也不是删除一行配置。旧的状态模型必须被恢复,ADD-PATH 编码产生的对象和过期标识符必须清理,FIB 不得继续依赖已撤回候选项。若能力重新协商要求重置会话,这个连通性风险必须在最初审批时就写入,而不是事故中临时发现。
衡路的“最小初始规范”原则解释了标准的适当边界。共同机制很小:一项带方向的能力和一个允许多路径共存的本地区分符。公开哪些路径、接受多少状态、安装哪条路径,继续由各方本地决定。互操作并不要求交出未来政策权。
“运行代码优先”给出证据层级。配置表达意图;实际协商的能力、真正发出的 tuple、被接受的路由、选择原因、写入的下一跳和被观察的数据包,才是逐步增强的事实。替代路径若没有走完这条链,就没有成为运营选择。
这里的数据主权表现为可见性控制。发送方拥有公开集合的决定权,接收方拥有接受和使用权,物理网络仍决定结果是否成立。把这三层混称为“已经共享多路径”,会把形式访问误作实际权力。
ADD-PATH 既不是“全部发送”的命令,也不是高可用保证。它只是阻止“只有前缀的身份”在一个会话上持续抹去所有替代项。只有当公开集合经过选择、成本受限、含义可解释,并能在首选路径消失后变成真实转发时,这项能力才兑现价值。
来源
- RFC 7911 — Advertisement of Multiple Paths in BGP
- RFC 4271 — A Border Gateway Protocol 4
- RFC 4456 — BGP Route Reflection
- RFC 7947 — Internet Exchange BGP Route Server
- RFC 7964 — Solutions for BGP Persistent Route Oscillation
- RFC 6774 — Diverse BGP Path Distribution
- Cisco IOS XE — BGP Additional Paths
- Juniper Junos — add-path
- FRRouting — BGP
- 衡路:运行代码优先
- 衡路:最小初始规范
- 衡路:数据主权
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
