要約

  • RIPE NCC のフォーラムで、単一 IP の Looking Glass 検索は空になる一方、対応するプレフィックスには結果があると同じ利用者が報告した。
  • 9 月 3 日の四回の確認では、報告された二組ともデータが返った。症状は再現せず、恒久的な解決が確認できたわけでもない。
  • IP 入力では、まず対象となる経路プレフィックスを探す処理がある。空の応答だけで経路撤回や通信障害を判断することはできない。

空の検索結果を見たとき、最初に疑うべきものが経路とは限らない。RIPEstat の Looking Glass には、入力された IP アドレスを、それを含む経路プレフィックスに対応づける段階がある。利用者から見れば一回の検索でも、答えができるまでの仕事は一つではない。

9 月 2 日に RIPE NCC のフォーラムへ投稿された例では、14.137.164.1 の検索は空で、14.137.164.0/24 には結果があった。翌 3 日、この記事のために同じ二つの入力を確認すると、どちらにもデータが返った。以前に報告された別の組も同様だった。

現在も異常が続いているとは書けない。かといって、後から得られた正常な応答だけでは、以前の差を説明できない。残るのは、入力の意味と観測結果を切り分けるという、小さいが実務上重要な課題である。

アドレスとアドレス群は同じ質問ではない

公式のエンドポイント説明によると、プレフィックスを指定する場合は経路データと完全に一致する必要がある。IP アドレスの場合、サービスはそのアドレスを含む、経路として存在するプレフィックスを探す。既定の遡及範囲は 86,400 秒で、それより古いエントリーは除外される。

利用者が正確なプレフィックスを知らなくても調べられる点は便利だ。ただし、対象を決める処理と、その対象について経路データを取り出す処理は区別しなければならない。前段の不調で結果が変わる可能性は、ネットワーク側で経路が撤回された可能性とは別である。今回の原因が前段にあったと確定したわけではない。

この違いを「末尾に /24 を付ければ直る」と覚えるのも誤りだ。実際に広告されている範囲は /24 とは限らない。適当なマスクを加えれば別の質問になり、比較自体が成り立たなくなる。対照として使うのは、実際の経路として確認したプレフィックスである必要がある。

公開報告の範囲

一連の投稿は 8 月 24 日の moonteach による報告で始まった。対象は 159.138.184.0 と 159.138.184.0/24 だった。翌日、RIPE NCC 職員として公開表示されるアカウント ties が、最長プレフィックスの検索を説明し、一時的な現象に見えると述べたうえで、検索失敗時の扱いを同僚に確認する意向を示した。

9 月 2 日、同じ投稿者は以前のアドレスは動作するようになったとしながら、別のアドレスで差が出る例を提示した。記載された二つの照会時刻には 27 秒の開きがある。一人の利用者が示した例であり、同時刻の比較実験でも、複数の独立した障害報告でもない。原因の確定や修正完了の発表は、このやり取りにはない。

今回得られたのは四つの応答

9 月 3 日 04:13:08.929 から 04:13:10.945 UTC にかけて、四つの入力を順に照会した。すべて HTTP 200、状態 ok でデータを返した。IP を指定した二つの応答には、包含する /24 に変換したというメッセージがあり、実際の問い合わせパラメーターにもそのプレフィックスが入っていた。

入力 コレクターの項目数 ピア記録の行数
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

数値は保存した応答内の項目を数えたもので、独立した事業者数や RIS 全体の設備数ではない。後半の組では latest_time が 20 秒異なった。行数が等しくても、同じ時点の同一データとはいえない。表のリンクは現在の検索を実行するため、過去の応答を再現する固定ページでもない。

今回の確認が示すのは、この時刻、この入力では差が再現しなかったということだけだ。過去のサーバー状態、変化した条件、他の入力での発生頻度までは分からない。正常な応答には価値があるが、それを復旧証明にまで広げる理由はない。

経路情報と通信の成否

Data API の説明では、状態、メッセージ、版、キャッシュ情報が別々に扱われる。応答を正常に受け取れたことは、その IP 宛ての通信が届くことを保証しない。データが空であることも、直ちに経路が撤回された証明にはならない。

RISは、協力するネットワークとのピア接続から BGP の観測情報を集める仕組みだ。利用者の通信を目的地まで流して確かめる試験ではない。観測点、取得時刻、検索対象を確認することと、実際の転送を検証することは、それぞれ別の作業になる。

この公開記録から顧客障害や経路ハイジャック、トラフィックの損失は確認できない。まず確かめるべきなのは、空の応答を得た検索が、どの経路を対象として成立したのかである。質問の対象が曖昧なままでは、答えだけを強く読んでも判断の精度は上がらない。