摘要

  • RFC 9107 允许 route reflector 使用一个为客户、客户组或整台反射器配置的 IGP 位置来计算内部成本，而不是使用反射器本身的物理位置。
  • “最优”含义很窄：它只是指定视角在同一候选集合和相应政策下会选出的路径。候选缺失、拓扑过期、递归下一跳或更早的 BGP 偏好都能改变结果。
  • 安全部署必须证明根节点分配、拓扑时点、候选完整性、计算容量、备用根切换、客户收到的路径以及 FIB 出口。

设想一台虚拟 route reflector 放在中央数据中心，服务东部、西部和南部三座城市的路由器。两个边界节点通告同一前缀。local preference、AS_PATH 等更高优先级属性相同，决策来到 IGP cost 这一步。

对东部客户而言，东部出口更近；对位于西部的 reflector 而言，西部出口更近。反射器忠实回答了“哪个 next hop 离我最近”，然后把西部路径发给所有客户。东部客户没有机会看到另一候选项，数据包穿过骨干去往一个只对控制平面机器最优的出口。

每个局部都可能正确。IGP 度量正确，BGP Decision Process 正常，会话稳定。问题出在观察位置。算法从错误地点精确计算，依然会为使用者稳定地产生错误答案。

RFC 4456 早已说明这种规模交换。Route reflection 通过汇总信息、通常只反射自身 best path 来减少 full-mesh iBGP。不同路由器到同一位置的 IGP 成本不同，一些反射拓扑不会得到 full mesh 相同的选择。传统办法是让反射拓扑与转发拓扑尽量相称。

当 reflector 离开 forwarding path 并被虚拟化、集中化，这种相称关系变弱。控制服务可以放在算力和运维最方便的位置，它的物理 IGP 坐标却意外变成 traffic engineering 输入。仅仅迁移 vRR，就可能在没有外部 UPDATE 和边缘政策变化的情况下改变出口。

RFC 9107 用逻辑位置替换这项偶然因素。运营者指定 link-state 拓扑中的一个节点，通常用 loopback 地址识别。反射器以该节点为根构建 shortest-path tree，并在内部成本比较时，使用根到各 BGP next hop 的距离。

逻辑根是视角，不是 waypoint。数据包不必经过它，reflector 也不会因为代入该根就进入 forwarding path。真正的流量路径由所选 BGP next hop、客户的递归解析和 FIB 决定。把根节点画成流量必经点，是把模型错当结果。

粒度由运营者选择：整台 reflector 一个视角、每组客户一个视角，或每个客户一个视角。RFC 9107 只要求合规实现至少支持其中一种分组方式；合规不等于提供逐客户精度。

每种粒度都包含近似。单一根计算最少，却可能重复传统偏差。区域根适合一组客户的中心，不一定适合边缘。逐客户根最接近各自位置，却会倍增 SPF 和部分 BGP 决策计算。“最细粒度”不是免费正确选项，而是一项容量决策。

“最优”的边界也要保持严格。基础 ORR 只在 RFC 4271 Phase 2 tie-break 的 step e，用指定根的成本替代 reflector 自身成本。更早执行的 BGP 政策继续优先。更高 local preference 仍可让远处出口胜过近处出口。

IGP cost 也不直接等于延迟、拥塞、丢包、transit 成本、碳排或应用体验。ORR 可以在更高优先级相同的前提下支持 hot-potato routing。准确说法是“依据这一拓扑度量和既有政策得到的最近合格出口”，而不是“全局最好路径”。

RFC 9107 还允许为不同客户组重复更多决策步骤。如果它们需要不同 BGP 政策，反射器可以运行更大范围乃至完整的 Decision Process。此时根节点映射不仅委托拓扑视角，也可能委托商业政策视角。

所以，客户到根节点的映射本身就是生产政策。把一个客户移到另一组，即使 Internet 没有新 UPDATE、IGP 没有链路变化，也可能改变成千上万条 Adj-RIB-Out。映射需要版本、审批、小范围 rollout、精确 diff 和回滚。

计算之前还必须拥有完整候选集合。Reflector 若从未学到客户会选择的路径，就不可能替客户做出同样选择。RFC 9107 指出，为了让不同 cluster 的 reflector 获得所有合格路径，需要在 reflector 之间部署 ADD-PATH。

一个 capability 状态并不能证明完整。相关 AFI/SAFI 的 send/receive 方向必须匹配，发送端 path-set policy 必须包含有用候选，进口 policy 必须保留它，ORR 节点的 Adj-RIB-In 必须真正看见它。最精确的客户根 SPF，作用在不完整候选集上，仍会给出错误出口。

ORR 与边缘 ADD-PATH 采用不同的成本分配。把多条路径推到每台边缘设备，允许客户自己决定，但增加边缘 RIB 和 update 负担。ORR 可在 reflector 层保留丰富集合，集中完成逐视角计算，再给每个 edge 发送较小结果。节省的分布式状态，转化成了中央信息、算力与信任集中。

拓扑输入必须同样可证。RFC 9107 提到 IS-IS、OSPF 和 BGP-LS。一个 topology database 存在，不代表它新鲜、完整或范围正确。它可能缺少某个 area、level 或根，也可能在冗余 reflectors 之间不一致。

BGP-LS 可以把 link-state 信息输送到计算点，却不会自动证明消费端视图正确。运营者需要 topology epoch、节点与链路覆盖、源 session 健康，以及与转发路由器本地 IGP 的对照。RFC 7752 已被 RFC 9552 取代，现网还应明确自己实际使用的规范与实现。

递归 next hop 带来更细的边界。若 BGP next hop 本身通过 BGP route 解析，相关度量应是最终解析下一跳的 IGP 成本。RFC 9107 要求无法提供最终成本的实现，在 next-hop metric 比较时把这些路径当作最低优先，但仍保留其 Phase 2 有效性。一条合法路径可能只是因为计算看不穿递归而持续落选。

不同产品有不同解析限制。Junos 文档说明某些服务使用 MPLS 协议而非 IGP 作为主要解析路径时需要调整设计；Cisco 文档列出其 rSPF、BGP-LU 和多 IGP topology 等限制。这些是具体版本边界，不应升级成 RFC 规则。

厂商所说的“保证最优”也不能替代系统证据。软件可能完全正确地为配置根选路，而根不代表客户、拓扑已过期、或关键候选缺失。产品正确只是证据链的一环。

备用根展示了视角的生命周期。RFC 9107 建议允许 backup IGP locations，Junos 提供 primary 与 backup 配置。主根消失时，观察者改变；网络可能持续可达，但大量前缀的出口也会随新视角变化。

因此，备用根需要预期 route-set diff 和实际转发测试。“已配置 backup”不是连续性证明。应在受限范围移除主根，观察 SPF 切换、比较各组通告，再检查 FIB 和流量。

Hop-by-hop forwarding 还有额外约束。RFC 9107 同样支持端到端隧道，但警告多 reflector、无封装设计必须仔细考虑 topology 以避免 loop。某个根视角下合理的选择，可能与真实反射和转发拓扑组合出危险结果。

算力是控制契约的一部分。一个根对应一个 shortest-path 视角；数百客户根可能需要数百棵树和对大表反复执行决策。细粒度提高精度，却可能延长 convergence、占满 CPU 和内存，并在拓扑变化最快时堆积队列。

容量评估要同时考虑路由数、客户数、根数、IGP 节点和故障 fan-out。应测量稳定状态资源、全表重算、增量变化，以及从 IGP 事件到 ORR 选择再到客户收到通告的时间。只在安静实验室正确的系统，不能承担故障控制。

第一份证据是视角登记表：按客户与 AFI/SAFI 记录主根、备用根、组、policy、owner 和被接受的近似。第二份证明候选完整性，包括 reflector 间 ADD-PATH 方向和实际 Adj-RIB-In。第三份保存 topology epoch、根到 next hop 的成本、早期属性和最后胜出的决策步骤。

第四份证据必须来自客户：通告是否到达、是否通过进口、为何成为 best、怎样递归、进入哪个 FIB egress，以及数据包实际走向。如果客户从别处学到另一条并最终选择它，那是需要解释的运行事实。

测试场景应覆盖客户换组、根消失、备用根启用、候选被遮蔽、拓扑过期、递归下一跳、高优先级 policy 覆盖和算力饱和。每个场景都要有预期集合差异与最长收敛时间。

回滚恢复的是视角，而不只是配置文本。删除 ORR 可能让 reflector 恢复使用物理位置，但反向更新仍需到达客户并改变 FIB。如果期间拓扑或外部候选改变，基线只能充当证据，不能保证时间倒流。

权力应当分开。IGP owner 验证根和故障域，BGP policy owner 审批分组与优先级，reflector operator 管理容量和 rollout，traffic owner 验证出口。独立 reviewer 应能否决“这个根代表该客户”的主张。

衡路的最小初始规范原则与 ORR 的技术边界相合：共享机制只定义一个逻辑点和明确决策阶段，不强制每个网络集中化或采用同一粒度。未来选择留在本地。

运行代码优先给出验收顺序。根与客户组配置是主张；真正学到的拓扑、保留的候选、发出的客户专属路径、写入的下一跳和观察到的数据包才是系统。正确配置若吃到过期输入，仍是错误运行。

这里的数据主权不是拥有一份拓扑库，而是能够理解、质疑并独立验证它产生的决定。ORR 用一种更受控的集中化修复传统集中化偏差，也因此把根节点地图变成新的路由权力。最后要问的不是路径是否被称为 optimal，而是谁的眼睛完成计算，以及客户的数据包是否同意。

来源