摘要

  • RFC 2918 允许一方针对已经协商的 AFI/SAFI，请求具备能力的邻居重新通告其当前 Adj-RIB-Out；邻居仍保留自己的出口策略权。
  • RFC 7313 用 BoRR 和 EoRR 标出完整刷新周期：旧路由先成为 stale，重回的条目替换旧状态，未返回者在结束时清除。
  • 命令成功、会话稳定或收到结束标志都不等于结果正确；必须比较前缀、属性、选择、FIB 与流量。

设想运营者修复了一条入站前缀过滤规则。旧规则误拒绝两百条本应接受的通告。新配置提交成功，却不代表那两百条输入重新出现。如果路由器没有保留未经修改的接收副本，新规则根本无从判断。

相反的情况同样危险。新策略准备拒绝一批过去已经进入 Loc-RIB 的路径。仅仅改变配置文本，不能证明存量路由被重新送入 policy。仓库里的规则可以是新的，运行中的路由决定仍可能是旧的。

传统 inbound soft reconfiguration 通过保存邻居所有原始 UPDATE 解决这个问题，包括被策略拒绝的部分。以后重新评估完全由本地完成，代价则是长期占用内存和处理资源。

RFC 2918 重新分配了这笔成本。BGP speaker 用 capability code 2 表明自己能够接收并处理 ROUTE-REFRESH。请求方必须先收到邻居的 capability，才能针对会话建立时协商的某个 AFI/SAFI 发出请求。

邻居收到有效请求后，会依据自己的当前 outbound route filtering policy，重新通告相应的 Adj-RIB-Out。这个名词就是权力边界：请求方不能读取远端数据库，也不能强迫对方公布已过滤路径。它只能请邻居再次说出今天愿意对这个 peer 说的内容。

因此，refresh 不是历史归档回放。昨天存在的路由可能已撤回，远端属性或出口策略可能已经变化；昨天没有的路径也可能今天出现。最终集合是发送方当前 export 与接收方当前 import 的共同产物。

这意味着数量变化不能独自说明原因。刷新后少了五百条，可能来自本地新过滤、远端撤回或对方策略变化。只有精确的 prefix、attribute 与时间证据，才能分离这些机制。

基础 RFC 2918 还有一个可观察性缺口：它没有给完整重通告标出明确开始与结束。普通 UPDATE 可能穿插其中。某条旧路由暂时未出现，无法判断它已经消失，还是仍在队列里。

RFC 7313 定义 Enhanced Route Refresh capability code 70。Subtype 1 是 Beginning-of-RIB-Refresh，简称 BoRR；subtype 2 是 End-of-RIB-Refresh，简称 EoRR；subtype 0 保留普通 refresh 请求。

收到 BoRR 后，接收方把该邻居、该 AFI/SAFI 的全部路由标为 stale。刷新期间重新出现的条目替换对应旧状态。收到 EoRR 时，仍然 stale 的条目立即清除。原本含糊的“没有看到”，变成了一个有边界周期内“没有回来”。

刷新并不冻结网络。周期中发生变化的路由可以按新状态通告。接收方处理的是活的消息流，而不是静止文件。EoRR 只证明刷新周期闭合，不证明每条路由正确，更不证明它忠实复刻了过去。

实现可以设置本地 stale 保留上限，在迟迟没有 EoRR 时主动清理。这样能防止旧可达性无限存活；若上限太短，又可能在健康但缓慢的刷新完成前删除可用路由。

EoRR 不能与 Graceful Restart 的 End-of-RIB 混为一谈。前者结束重通告周期，后者参与控制面重启时的转发连续性。RFC 7313 明确安排两者顺序，避免提前清理 stale 路由。

入站 soft 与出站 soft 也不是同一权力动作。入站时，本地需要远端重新发送，或者使用自己保留的原始副本；出站时，本地重建自己发给邻居的通告。相似命令名掩盖了不同的数据来源与依赖。

Cisco 文档把选择写得很清楚：具备 capability 时，动态 inbound soft reset 发出 refresh 请求；没有 capability 但保存了 soft-reconfiguration 输入时，可本地重跑；两者都不存在，就可能只能硬重置会话，让全部路由随 session 重建。

这不是单纯的命令差异，而是资源与自治选择。保存原始输入，以内存成本换取未来不依赖邻居；Route Refresh 节约长期存储，却依赖对方 capability、响应和当前 export；hard reset 则把故障域扩大到整段关系。

FRRouting 还提醒，一些功能仍需要知道被拒绝的路由，例如某些 maximum-prefix 计数方式。能够再次索取当前通告，不等于持有另一个控制所需的完整原始库存。

RFC 5291 的 Outbound Route Filtering 是另一项单独协商的能力，允许接收方传递部分过滤信息。普通 refresh 可以有或没有 ORF。ROUTE-REFRESH 本身不会变成远端出口策略编辑器。

验证要在变更前开始。逐 peer、逐方向、逐 AFI/SAFI 记录 basic 与 enhanced capability 的 advertised 和 received 状态。只看到本地支持，不能证明邻居能响应；只支持基础能力，也不能假定存在 BoRR/EoRR。

随后建立基线：确切前缀与关键属性、接收和接受集合、best path、策略版本、session uptime、FIB next hop。若平台无法展示被拒绝输入，就明确记录证据空白。

先在一个 peer 和一个 AFI/SAFI 上应用变更。记录请求、BoRR、EoRR 与持续时间，监测 EoRR 缺失、stale timeout、控制面负载、意外 reset、withdraw 和 best-path 变化。

必须比较集合，而非总数。删除十条并新增十条，总数不变；一个 aggregate 换成许多 more-specifics，数量会暴增；同一 NLRI 的 community 改变，也可能让选择结果发生变化。

最后进入 forwarding。重新接受的路由可能输给另一个 peer，next hop 可能无法解析，新的 FIB 路径可能落到容量不足的链路。Route Refresh 只提供重新判断的输入，不提供交付证明。

回滚也需要重新评估。恢复旧 policy 文件，不会自动恢复旧路由状态。如果窗口期间邻居的 export 已改变，完全回到先前快照甚至不可能。这正是基线只能作为证据、不能作为承诺的原因。

自动化必须限制并发。同时刷新大量 peer 与地址族，会产生大量 UPDATE 与路径计算。“soft”只表示不主动拆会话，不表示没有控制面成本。

Heng Lu 的最小初始规范原则体现为小而明确的请求：一个邻居、一个地址族、一次重通告。双方保留自己的策略。Running-code primacy 则要求用协商能力、刷新周期、RIB 差异和 FIB 结果验收，而不是相信命令返回成功。

Route Refresh 把策略修复与会话破坏分开，却从未把策略修复与证据分开。邻居再次发言之后，只有实际返回、被重新判断并改变转发的路由，才能证明新规则已经掌权。

Sources