摘要

  • 仓库采集与验证不会在所有地点同时完成，因此两台可达的 RPKI 验证器可能提供不同的已验证载荷集合。
  • 为路由器选择或切换缓存，可能改变起源验证所依据的证据；可用性与策略权威不是同一个控制问题。
  • 有效的分歧处置协议应记录验证集指纹、采集结果、路由器与缓存对应关系、决策负责人、切换条件和回滚证据。

一次维护窗口中，验证器 A 和 B 都显示健康，RTR 会话也都保持连接，没有任何红色告警。然而，A 已完成新一轮仓库采集，其中反映了最近撤销的一条 ROA；B 对某个发布点仍保留此前的已验证对象。接入 A 与接入 B 的两组路由器，因而可能对同一个前缀—起源组合给出不同分类。

这种场景并不要求协议发生故障。RFC 7115 明确指出，全球 RPKI 只是松散一致：发布、获取、验证与交付运行在不同时间线上。部署多个 relying party 能提供多个可用入口，却不能创造一个全球同步的唯一答案。

验证缓存也不是被动副本。它采集仓库对象、判断其有效性，再把得到的载荷集合提供给路由器。从 A 切到 B 可能恢复服务连接，也可能同时改变本地路由策略所看到的起源授权。因此，即使切换由自动化执行，它仍然代表运营选择。

RFC 9286 说明了分歧的一种来源：manifest 超过 nextUpdate 后会被视为过期，并进入获取失败处理，但影响可能只局限于一个发布点。RFC 8182 则要求分别校验 RRDP 的会话、序列号和哈希。改用 snapshot 是协议定义的恢复路径，本身不能证明验证器错误；关键是验证是否完整结束、最终接受了哪一份仓库状态。

RFC 8210 又增加了路由器边界。路由器只有在收到以 End of Data 表示的完整响应后，才采用缓存状态；refresh、retry 和 expire 间隔决定后续查询与旧数据保留。绿色连接不能证明两台验证器产出相同，也不能证明所有路由器完成同一次更新，更不能证明缓存切换对策略没有影响。

因此，监控面板应比较输出和依赖关系，而不只是在线状态。每台验证器都应保留已验证集合的稳定指纹、最近一次完整成功采集、失败或过期的发布点、信任锚和本地例外配置，以及实际使用它的路由器清单。发现差异意味着需要调查，并不自动证明哪一侧正确。

APNIC 托管的运营经验同样强调这一点：安装指南建议部署多个验证器，Vocus 的实践则监控验证器客户端连接，避免路由器悄然继续使用旧数据库。重点不是运行两个进程，而是知道各自提供什么、由谁消费。

来源