要約

  • RIPEは10月6日、RRC07の最新更新ファイルの時刻を19:20 UTCと報告した。その後、21:53 UTCに障害を解消したとし、bviewファイルは通常どおり作成されたと説明した。
  • 現在の公開目録には、19:25から21:50まで5分刻みで続く更新ファイル名が30個並ぶ。目録の更新時刻は21:53から21:55に集中している。4個のサンプルはgzip形式で最後まで展開できたが、中のMRTレコードは解析していない。

分析

異なる時刻は異なる事実を示す

ルーティングデータのアーカイブには、複数の時刻がある。更新ファイル名に入る時刻は、ファイルが扱う区間を示す。一方、ディレクトリーの更新時刻は、アーカイブサーバーがそのオブジェクトを変更したと記録する時刻だ。両者が答える問いは違う。

RIPEの最初の告知では、RRC07の最新更新ファイルは19:20 UTCだった。現在の公開目録では、その直前のupdates.20261006.1920.gzの更新時刻は19:25と表示される。続く30個の名前は19:25から21:50まで5分刻みで続き、欠けた時刻はない。うち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の4ファイルを取得し、gzipを最後まで展開できることを確認した。これは転送ファイルとして読めることの確認にすぎない。MRTレコードは解析しておらず、残る26ファイルも調べていない。現在の目録から障害中に利用者が何を取得できたかも分からない。RIPEの公開告知はRRC07の原因、経路の喪失、通信への影響を示していない。公開の遅れからそれらを推測すべきではない。

出典