摘要

  • RIPE 在 10 月 6 日报告的 RRC07 最新更新文件时间为 19:20 UTC；随后，RIPE 在 21:53 UTC 将事件标为已解决，并称 bview 文件正常生成。
  • 当前归档索引列出 19:25 至 21:50、每隔五分钟连续排列的 30 个更新文件名。目录标注的修改时间落在 21:53 至 21:55；四个抽样文件完整解压，但没有解析其中的 MRT 记录。

分析

两种时间，两类证据

路由归档里至少有两种时间。更新文件名中的时间标记对应文件所覆盖的区间；目录显示的修改时间，则是归档服务器报告该对象变更的时间。两者不能互相替代。

RIPE 最初报告的最新 RRC07 更新文件标记为 19:20 UTC。当前公开索引中，前一个文件 updates.20261006.1920.gz 的目录修改时间是 19:25。随后，索引连续列出从 19:25 到 21:50 的 30 个文件名，中间没有五分钟档位缺失。其中 25 个对象标注为 21:53，4 个为 21:54，1 个为 21:55。这个分布与一批延迟文件在短时间内进入公开目录相符，却没有说明内部处理路径，也不能确定每个读者何时首次拿到文件。

RIPE 的事故页面称事件于 10 月 6 日 21:53 UTC 解除，并表示 bview 文件正常生成。RIPE 将 bview 描述为某一时点的路由状态快照；update 文件记录的是一段时间内发生的变化。因此，快照正常并不能回答中间每个更新文件是否完整。这两类文件服务于不同的分析问题。

RIS 数据可用于查看路由状态、复盘 BGP 事件和观察长期变化。如果用于回溯的图表中出现空白，原因可能是没有观察到变化，也可能是观测文件当时不可用。事后看到连续文件名，可以缩小对归档目录序列的疑问，却不能替代对每个区间内容的核验。

序列两端的四个文件——19:20、19:25、21:45 和 21:50——均已下载并通过完整 gzip 解压检查。这只是传输层的检验；我们没有解析 MRT 记录，也没有抽查其余 26 个文件。当前索引同样不能还原事故期间读者实际能取到什么。RIPE 的公开通报没有说明 RRC07 的根因，也没有报告路由丢失或流量影响。不能从文件发布延迟推断这些结果。

来源