摘要

  • Route Refresh 让一端请求对等方重发某个 AFI/SAFI 的路由，而无需重置 BGP；Enhanced Route Refresh 还可标出重放的起点与终点。
  • BoRR 与 EoRR 证明的是协议交换边界，不证明配置版本、策略方向、最佳路径、FIB 安装或报文交付。
  • 要宣布对账完成，必须把策略提交、刷新交换、受控前缀、转发状态、流量、例外与回退绑定成一份收据。

协议结束，运营问题仍可能没有答案

设想一次受控的入站策略变更。运营团队希望拒绝从某个上游收到的一条指定路由。配置系统显示提交成功，路由器发出刷新请求；随后出现 Beginning-of-RIB，路由更新陆续抵达，End-of-RIB 最终关闭这段窗口。变更单看起来可以结案。

但在一台生产边缘路由器上，受控前缀仍处于选中状态。这并不说明标准标记失真。真正的问题是，团队把“对等方完成了重发”误当成“本地策略实现了预期结果”。

RFC 2918 定义 Route Refresh，是为了让策略重新应用时无需中断 BGP 会话。双方在建连时通告能力，之后的刷新消息指定 AFI 与 SAFI，请对等方重新通告相应的出站路由状态。

这条消息不包含本地策略哈希、配置事务号、审批人，也不声明某个前缀应该消失。它启动协议动作，却不是策略意图的提交证明。

BoRR 与 EoRR 精确界定了什么

RFC 7313 引入 Enhanced Route Refresh。Beginning-of-RIB 与 End-of-RIB 包围本次重发集合，接收方可据此识别刷新期间没有再次出现的陈旧路由，并按程序处理。

这种边界很有价值：它说明某个邻居对某个地址族的刷新何时开始、何时结束。但它没有证明新配置在第一条 UPDATE 到达前已经激活，也没有证明整个设备群都收到同一版本，更没有证明策略被用在正确方向。

范围同样不能被省略。IPv4 unicast 的成功刷新不能代表 IPv6、VPN 路由或其他 SAFI。一条会话不能代表另一邻居、路由反射器或另一组边缘设备。把一个 EoRR 变成全网绿灯，会抹掉协议特意保留的上下文。

入站与出站是两条证据链

RFC 4271 区分从邻居收到的路由、经决策进入 Loc-RIB 的路由，以及准备向邻居通告的路由。改变入站策略时，本地接收方需要新的通告来重新执行规则；改变出站策略时，发送方需要证明向指定邻居使用了新策略。

两者的负责人和观察点不同。对等方重放出站状态，本地设备重新处理入站状态；一次刷新不能悄然替双方的配置意图背书。

RFC 5291 的 Outbound Route Filtering 又增加了一层状态。ORF 能力、过滤类型、模式以及实际安装内容都应分别记录。看到刷新发生，不能单独证明预期 ORF 条目已经存在、足够新且被正确解释。

用受控前缀贯通路由与转发

每个声明都要在对应阶段验证。如果声明是“入站已拒绝”，应检查收到路由及策略结果；如果声明是“替代路径已胜出”，应检查 Loc-RIB 决策；如果声明是“流量已迁移”，还要检查 FIB、下一跳解析与代表性报文路径。

这些视图可能不同，却不互相矛盾。某前缀可从一个邻居被拒绝，却仍从另一邻居到达；一条 BGP 路由可成为最佳路径，却因递归下一跳失败而无法安装；FIB 条目也可能存在，但隧道、ACL 或下游故障仍会阻断服务。

选择一个预期结果明确的受控前缀，能把证据串起来。记录提交前、BoRR–EoRR 窗口内和结束后的来源邻居、AS 路径、关键属性、决策原因及最终下一跳，再用与目标地址族和服务相符的流量测试收尾。

这不是削弱 Route Refresh，而是保护它的解释边界。完成的刷新是对“有能力的对等方重放了一个限定路由集合”的有力证据。把它与相邻证据组合后，团队才能区分错误版本、部分下发、地址族选错、能力未协商、ORF 状态差异，以及路由正确但转发失败。