摘要

  • 路由从 Invalid 转为 Valid 后，多宿网络到达研究中一半测量点的中位时间为 9 分钟，单宿网络为 12 分钟。
  • 反向变化时顺序倒过来：路由从 Valid 变成 Invalid 后，多宿网络要 42 分钟，单宿网络要 30 分钟，才有一半测量点失去可达性。

两条上游链路能让路由更快回来，也能让它在授权改变后更晚退场。原因很具体：每家上游运营商都按自己的节奏更新 RPKI 视图。

这组结果来自 RIPE 93 一场关于 RPKI 状态变化如何传到数据平面的报告。研究追踪了 RIPE 仓库中约 25,000 次会改变已验证负载的变化，再筛出约 1,500 个适合测量单次可达性转换的事件。每次发现变化后，研究人员从 300 多个 CAIDA Ark 节点发起 traceroute，约每三分钟一次，持续一个小时。

计时器既不是从 ROA 被修改时启动，也不是从第一个验证器下载对象时启动。它看的是参与测量的点何时有一半重新能到达某个前缀，或有一半不再能到达。数据库先更新，并不代表承载流量的网络同时更新。

多一条上游，回来的路更快

当路由从 Invalid 转为 Valid，多宿网络到达一半测量点的中位时间是 9 分钟；单宿网络是 12 分钟。多一个上游，就多一个机会：某一家的验证器可能更早取回并处理新对象。

中位数不是全部。多宿网络的慢速尾部也更短。每家上游运行自己的 relying-party 软件，按自己的周期取数。两套独立的更新周期，让至少一条路径更早得知路由已获授权的机会增加。

多宿连接本身不会把 ROA 变成 Valid。ROA 声明来源授权；验证器根据公开对象计算状态。研究测到的差异发生在这之后：上游和路由器把新状态纳入处理流程时。

失效之后，退场更慢

把变化方向倒过来，结果也倒了过来。原本 Valid 的路由转成 Invalid 后，单宿网络的中位时间为 30 分钟，多宿网络为 42 分钟，才有一半测量点失去可达性。

备用路径仍在做它擅长的事。如果一家上游已经更新 RPKI 视图并改变路由处置，另一家验证器还没取回新状态，就可能继续通告这条路由。独立路径越多，就越可能有一条在转换期仍然可见。

这对事故判断很重要。Invalid 不是全网统一的断电按钮。每个网络按本地策略处理无效通告，验证器的更新时间也不一致。BGP 随后仍会在现存通告中选择路径。因此，控制平面的状态变了，数据平面仍然可能有流量经过。

研究测量的是单一来源的情形，并排除了被更具体覆盖路由所覆盖的案例；每次 traceroute 在一小时后停止。9、12、30、42 分钟是这一组观测的中位数。要判断某次变更是否真正影响用户，运营团队还得把中位数拆开：观察哪一个前缀、哪一个上游、哪一个验证器，以及从哪些网络位置发出的探针看到了变化。总体数字适合比较两类网络，不能替代故障现场的路径记录。

一次修改，几套时钟

从修改 ROA 到改变路由可达性，中间隔着一串动作：仓库发布对象、验证器取回并校验、计算出状态、将状态送给路由器、本地策略处理通告，最后数据平面稳定下来。

研究团队监控 RIPE 仓库源站，并使用优化过的验证器来抢先发现变化。报告人说，这个信号比被比较的公共验证器至少早 57 秒，中位数早 5 分钟。研究人员因此可以在不少网络反应之前启动 traceroute。这是测量方法，不能据此说 RIPE NCC 控制所有验证器的刷新计划。

客户问“修正何时生效”，运营商若只报一个“RPKI 已更新”的时间戳，等于交了一张只有发车时间的列车时刻表。仓库发布、验证器取回、路由器采用、探针看到路径消失，是四笔不同的账。RIPE 93 测得的 30 与 42 分钟中位数，正是账本没有合并的证据：在部分测量点上，前缀依然可达。

来源：RIPE 93 报告摘要与录像；RIPE 93 全会官方文字记录；RFC 6811：BGP 前缀来源验证。