摘要

  • RIPE NCC 称，10 月 2 日 01:30 UTC 起，一个 DE-CIX peer 向路由收集器 RRC12 发送异常大量的 BGP 消息，之后负责消费 Kafka 更新的处理进程反复超时。
  • 当天 19:10 UTC 检查时，RRC12 公开档案仍没有晚于 01:00 UTC 的更新文件。这说明观测服务的文件发布滞后，并不能证明互联网路由缺失或流量中断。

分析

RIPE NCC 于 10 月 2 日 09:42 CEST 为“RRC12 MRT 更新文件未生成”建立状态事件。首条说明称，RRC12 最新 MRT 更新文件的时间戳为 01:00 UTC，最新 BVIEW 状态快照为 00:00 UTC。13:26 CEST，RIPE 表示，一个 DE-CIX peer 自 01:30 UTC 起向 RRC12 发送异常大量的 BGP 消息。按 RIPE 的说明，消费 Kafka 更新的处理进程跟不上这一体量；每次重启后又会超时，无法取得足够进展。RIPE 还称，其他 RRC 更新文件的生成也受到延迟。

RRC12 是位于法兰克福、连接 DE-CIX 的路由收集器。收集器通过对等会话接收 BGP 数据，并不替网络决定采用哪些路由。RIPE 文档说明，采集数据按收集器分别保存：“update”文件记录某段时间内的变化，BVIEW 文件保存某一时点的状态快照。RIPE 称更新文件通常每五分钟生成一次。这是观测数据流的常规发布节奏，并非每台收集器始终达标的保证。

在 19:10 UTC 对 RIPE 公开档案进行只读检查时，RRC12 没有比 updates.20261002.0100.gz 更新的文件；该文件时间戳早于检查 18 小时 10 分钟。RRC18 档案当时已到 19:05 UTC。这只能说明那一刻两个公开目录的可见新鲜度不同，不能证明其他所有收集器都未受影响，也不能指出此前哪些收集器出现延迟，更不能解释 RRC18 为何有更新的文件。

在本次审查截点，状态仍标记为“已确认”，处于排查中。页面没有公布 peer 身份或 ASN、消息速率、涉及的路由、其他收集器延迟多久、队列是否会重放，或恢复计划。RIPE 也没有说路由已经丢失或流量受到影响。文件延迟意味着分析者应先看时间戳再解读空白区间；它并不证明那段时间没有 BGP 变化。

下一条有用的更新应是一份简短的恢复回执：受影响收集器最新的 update 与 BVIEW 时间戳、延迟区间是否重放，以及正常发布何时恢复。RIS 使用者便能区分采集、处理和发布状态，而不把档案延迟误当成路由系统本身发生变化。

来源