要点
- 7月20日10時48分（UTC）の AfNOG メーリングリスト投稿は、
as-TelOneZWの重複を抽出する短いコマンドを示した。 - AFRINIC への再照会では、
members:が24行ある一方、異なる ASN は21個だった。AS37183 は3回、AS37123 は2回現れる。 - RPSL の集合という意味では、同じ値を繰り返しても新しいメンバーは増えない。停止、経路漏えい、経路拒否を裏づけるものでもない。
- AFRINIC は、上流・トランジット事業者が IRR を経路フィルター更新に利用すると説明している。実害を誇張せず、入力データの保守シグナルとして扱うべき事例だ。
増えたのは3行であって、3ネットワークではない。
月曜日に African Network Operators Group のメーリングリストへ投稿された短い指摘は、この違いを明快にした。S. Moonesamy が AFRINIC の WHOIS にあるas-TelOneZWを照会し、出現回数の多いメンバーを上に並べると、AS37183 が3回、AS37123 が2回表示された。
投稿は原因を断定していない。「もっともらしい説明がある可能性が高い」としながら、その説明自体は示していない。BTW が投稿後に現行レコードを確認したところ、24件のメンバー宣言と21個の一意な AS 番号を再現できた。オブジェクトの説明は「TelOne ASNs」、maintainer はAS8668-MAINTAINER、source は AFRINIC となっている。
これは通信障害の記事ではない。ポリシーの意味より、表現上の行数が多くなっていることを再現可能な形で示す事例である。
集合の意味とレコードの見た目を分ける
RFC 2622では、as-setのmembers属性に AS 番号または別の AS-set 名を列挙する。集合として評価する限り、AS37183 を3回記載しても AS37183 は1メンバーであり、AS37123 も2メンバーにはならない。異なるメンバー数は21のままだ。
現時点で主張できる範囲は狭い。AfNOG の投稿にも現行 WHOIS にも、経路が落とされた、誤ったオリジンが広告された、トラフィック経路が変わった、生成済みフィルターが壊れたという記録はない。集合の意味を守って展開する処理なら、重複行から新しい別 ASN が生じることはない。
ただし、全てのツールが途中の表現まで同じに扱うとは限らない。設定生成前に重複を取り除く実装もあれば、中間ファイル、差分、監査ログ、画面表示に生の行を残す実装もあり得る。確認できたのは入力の冗長性であり、あらゆるパーサーの挙動ではない。
重複した2つの ASN は別組織の登録だ。AFRINIC の現行情報では、AS37183 は Utande Internet Services (Pvt) Ltd、AS37123 は Telecontract Pvt Ltd に割り当てられ、いずれもジンバブエにある。TelOne 名義の集合に含まれることだけで、所有関係、子会社関係、現在の取引関係を推定してはいけない。AS-set はルーティングポリシーの範囲であって、企業グループ図ではない。
無害に見える異常ほど点検に向く
IRR オブジェクトは、運用者の宣言と機械的な制御の間に置かれる。RFC 2622は、AS 単位のポリシーを、低レベルのルーター設定生成にも使える粒度で記述することを想定している。AFRINIC の公開ガイドも、上流・トランジット事業者がルーティングレジストリを照会し、経路フィルターを更新すると説明する。
今回の重複からフィルターの誤りは証明できない。むしろ、数学的な結果を変えないまま入力レコードがずれる可能性を示している。
同じ有効 ASN を繰り返すだけなら、処理結果への影響は出にくい。その一方で、更新処理が照合せず追記している、複数の管理経路が同じオブジェクトを触った、最終 lint がない、といった可能性を検討する入口にはなる。これらは原因ではなく仮説だ。公開投稿には変更履歴も根本原因も含まれていない。
問うべきは「この重複でインターネットが止まったか」ではない。同じ保守経路が、より厳しいエラーを見逃さないかである。有効 ASN の重複は結果を変えにくいが、古いメンバー、欠けたメンバー、意図しないネストが同様に無害とは限らない。
削除より先に、意図した21個を確かめる
maintainer が最初に行うべき作業は、21個の一意なメンバーが今も想定範囲にあるかの確認だ。その後に余分な3行が入った経路を調べ、必要ならクリーンな更新を出す。重複だけを機械的に消しても、残った集合の正しさまでは検証できない。
監視も表現と展開を分けた方がよい。生の行数と一意な直接メンバー数を比較する点検に加え、ネストした集合を展開し、履歴を残し、重複・存在しないオブジェクト・想定外の追加・展開失敗を別々に検知する。RIPE Database の集合照会ドキュメントが示す通り、最終メンバーは一つのオブジェクトに見える行だけで決まるとは限らない。
IRR からフィルターを作る側は、生成物に由来情報も残す必要がある。どのレジストリをいつ照会し、どの方法で展開し、どの段階でレビューしたかが分かれば、入力が誤っていた場合にも追跡できる。由来情報はレジストリを無謬にしないが、障害調査を可能にする。
AfNOG の投稿が提示したのは、大事件ではなく安価な統制テストだ。余分な3行は21個の一意なメンバーを変えなかった。それでも、次の誤りが同じように寛容である保証はない。だからこそ、今のうちに照合、レビュー、観測の有無を確かめる意味がある。