要約

  • RIPE NCCは、10月2日01:30 UTCにDE-CIXのピア1社からRRC12へ通常を大きく上回る数のBGPメッセージが届き始め、その後Kafkaから更新を処理するプロセスが何度もタイムアウトしたと説明した。
  • 同日19:10 UTCの確認時点でも、RRC12の公開アーカイブに01:00 UTCより後の更新ファイルはなかった。これは観測サービスのファイル公開遅延であり、インターネットの経路欠落やトラフィック中断を示すものではない。

分析

RIPE NCCは10月2日09:42 CEST、「RRC12 MRT update files are not produced」というインシデントを登録した。最初の更新では、RRC12の最新MRT更新ファイルは01:00 UTC、BVIEWスナップショットは00:00 UTCとされた。13:26 CEST、同組織はDE-CIXのピアから01:30 UTCに異常に多いBGPメッセージが届き始めたと説明した。Kafkaから更新を消費する処理が量に追いつかず、再起動しても十分に進む前に再びタイムアウトしたという。RIPEは、他のRRCの更新ファイル生成にも遅れが出ていると報告した。

RRC12はフランクフルトにあり、DE-CIXに接続するルートコレクターだ。ルートコレクターはピアからBGPデータを受け取る装置であり、各ネットワークが使う経路を選ぶものではない。RIPEの資料によれば、データはコレクターごとに保存され、「update」ファイルは一定区間の変化を、「BVIEW」ファイルはある時点の状態を記録する。更新ファイルは通常5分ごとに作られる。これは観測データの平常時の公開間隔で、各コレクターが常に守る保証ではない。

19:10 UTCにRIPEの公開アーカイブを読み取り専用で確認したところ、RRC12にupdates.20261002.0100.gzより新しい更新ファイルはなく、確認時点で18時間10分の差があった。RRC18のアーカイブは同日19:05 UTCまで進んでいた。この比較で分かるのは、その時点で二つの公開ディレクトリの鮮度が異なったことだけだ。他のすべてのコレクターに影響がなかったこと、どのコレクターが先に遅れたか、RRC18に新しいファイルがあった理由までは示さない。

確認時点でインシデントは「identified」のまま調査中だった。ステータスにはピアやASN、メッセージレート、対象経路、他コレクターの遅延時間、キュー再処理の状態、復旧計画は記載されていない。経路が失われた、あるいはトラフィックが乱れたとも述べていない。ファイルの遅れがあるなら、分析者は空白区間を読む前にタイムスタンプを確認する必要がある。更新がなかったと解釈してよいという意味ではない。

次に有用なのは、復旧状況を示す簡潔な記録だろう。影響を受けたコレクターごとの最新updateとBVIEWの時刻、遅れた区間を再処理したか、通常の公開に戻った時刻を示せば、RIS利用者はデータの収集、処理、公開を区別できる。アーカイブの遅延を、経路システム自体の変化と取り違えずに済む。

出典