要約

  • RIPE NCCは11月8日、RIS Looking Glass用データベースが設定上限の3万2000ファイル記述子を使い切り、複数のRIPEstat APIが利用不能になったと説明した。
  • APIの処理量がほぼ戻った後も、同日20時06分UTCにはRRC25のピアの約1割でBGPメッセージの再生が遅れていた。

窓口のシャッターは上がった。奥の記録係はまだ追いついていない。RIPE NCCは11月8日13時39分UTC、データベースが回復し、RIPEstat APIの処理量もほぼ通常に戻ったと発表した。ところが夜の更新では、RRC25に接続するピアの約1割のデータがなお遅れていた。画面が開くことと、そこに映る経路の時刻が新しいことは同じではない。

原因として示されたのは容量設定だ。RIS Looking Glassのデータベースで、ファイル記述子の上限3万2000件に達した。その結果、Looking Glassの要求を扱う内部APIが利用可能な処理枠をすべて占めたという。最初の問い合わせは00時58分UTCに届き、12時51分UTCの調査告知はLooking Glass、RIS PeersなどのAPI停止を公表した。問い合わせの時刻から障害開始時刻は算出できない。

13時39分UTCにはデータベースとAPI経路が回復に向かったが、Looking Glassは前の数時間分のBGPメッセージを再生中だった。20時06分UTCの更新は遅れをRRC25の約1割のピアに絞り、メッセージ量を理由に挙げた。RIPE NCCは9日05時UTCごろの回復を見込んだ。確認時点の事故表示は「監視中」のままだった。

公式のLooking Glass仕様には、コレクターとピアごとの結果、経路が最後に変わった時刻と確認された時刻が記される。経路の証拠として使うなら、その時刻を読む必要がある。遅れたピアがいつ追いついたかを示す最終記録はまだ公開されていない。解決通知と合わせて、その時刻が回復の実体を示す。

一次資料：RIPE NCCの事故報告、Looking Glassの説明、RIS Peersの説明。