摘要

  • 11 月 8 日，RIPE NCC 确认 RIS Looking Glass 数据库触及配置中的 3.2 万文件描述符上限，多个 RIPEstat API 一度不可用。
  • 数据库和 API 通路恢复后，截至当日 20:06 UTC，RRC25 仍有约十分之一的对等体数据在追赶 BGP 消息回放。

绿灯先亮，钟却没跟上。11 月 8 日 13:39 UTC，RIPE NCC 称数据库已恢复，RIPEstat API 的吞吐量接近正常。到了 20:06 UTC，它仍报告 RRC25 约十分之一的对等体数据滞后。此时能拿到回答，与回答反映的路由时刻，是两回事。

这次故障有一个具体的闸口：Looking Glass 使用的 RIS 数据库被配置为最多 3.2 万个文件描述符。RIPE NCC 说，数据库耗尽描述符后，处理 Looking Glass 请求的内部 API 占满了可用处理槽位。机构在 00:58 UTC 收到第一张工单，12:51 UTC 的公告列出 Looking Glass、RIS Peers 等多个不可用接口。工单时间记录的是第一次报告，不能充当故障开始时间。

数据库重新运转后，接口的请求能力先回来，后台仍在重放此前数小时的 BGP 消息。晚间更新把剩余滞后收窄到 RRC25 的约十分之一对等体，并把原因指向这部分数据的消息量。RIPE NCC 估计会在 9 日 05:00 UTC 左右追平；核查时事故状态仍是“监控中”。

官方 Looking Glass 文档说明，结果按采集器和对等体排列，并附带路由上次变化、上次确认的时间。做路由取证的人应看这些时间，而非只看 API 是否返回成功。事故页尚未给出滞后对等体全部追平的时间记录；那份记录和正式结案公告会补齐恢复时间线。

原始资料：RIPE NCC 事故记录；Looking Glass 文档；RIS Peers 文档。