要約

  • MIXは2025年6月26日のノートで、適切に設計された事業者は、余裕を持たせたトランジット容量や分散したピアリング戦略によってIX障害の需要を吸収すべきだと述べた [1]。
  • 同時に、高頻度の不安定性は経路収束とトラフィック再収束を通じて運用リスクを生むと指摘した。LANが本質的な単一障害点でなくても、変化の連鎖は広い経路系に影響する [1]。
  • MIXの現行ルートサーバー文書は、ASN 61968、IRR由来の許可プレフィックス、AS_PATH検査、RPKI INVALID経路の拒否、配布先を制御するcommunityを記録している [2]。
  • これらは経路受入れと配布の制御であり、代替回線の容量や物理的多様性、アプリケーション復旧を保証するものではない。
  • 説明責任には、想定構成、実際の撤回、代替経路選択、移動トラフィック、残余容量、利用者側結果を結び付けた証拠が必要である。

MIXの主張を正確に読む

MIXは、IXが決して停止しないとは述べていない。準備された参加者は一つのピアリングLANだけに全到達性を依存させるべきではない、という主張である。具体例として、トランジット側の余裕とピアリングの分散が挙げられている [1]。したがって継続性はIX内部だけで完結せず、各自律システムの設計にも依存する。

IXは共通の相互接続環境を提供するが、参加者は上流、PNI、他のIX、BGP優先度、community、容量を自ら決める。第二経路が存在しても、それが直ちに最良経路になるとは限らない。必要な全プレフィックスが受理される保証も、移動後の負荷に耐える保証もない。

MIXが強調した再収束は、ここを監査可能にする。多数のセッションが同時に変わると、通常時には小さな迂回しか扱わないトランジットへ相関した負荷が集中する。単一リンクの切替試験だけでは、この同時変化を評価できない。

冗長な構成と継続性の結果は別物

継続性は、二つの実行状態の間を安全に移った事実として記録すべきだ。変化前には、外部BGPセッション、隣接関係の役割、想定経路、local preference、community、最大プレフィックス、利用可能容量を台帳化し、IX経路を失った際にどの接続へ負荷を移すかを決めておく。

変化中には、セッション状態、withdraw、代替announcement、best-path選択、トラフィック移動の時刻を保存する。変化後には、パケット損失、遅延、輻輳、経路変動、アプリケーション成功率が許容範囲に戻ったことを確認する。測定なしの「フェイルオーバーした」は、意図の説明にすぎない。

二経路が同じルーター、電源、ファイバー経路、制御プロセスを共有する場合もある。別々の回線でも、容量計画が同じ過小な前提に基づくことがある。試験は見かけ上の回線数ではなく、共有依存と同時負荷を含めなければならない。

ピアリング基盤とルートサーバーを分ける

MIXのルートサーバーは多者間ピアリングを簡素化する。文書によればASNは61968で、主要IRRから許可プレフィックスを生成し、AS_PATH先頭が参加ASNと一致することを確認する。無効・プライベートASNなどを含む経路を拒否し、RPKIでINVALIDとなる経路も拒否する [2]。

参加者はcommunityで配布先を制御できる。実トラフィックはルートサーバーをnext hopにせずLAN上の隣接者間で直接交換され、ルートサーバーASNはAS_PATHに現れない [2]。RFC 7947もこの多者間モデルを説明している [4]。

この範囲を広げて解釈してはいけない。IRRやRPKIは経路配布を制約するが、スイッチング基盤を維持せず、参加者のバックアップ容量を作らず、全ての二者間セッションを管理しない。共有fabric、ルートサーバー制御面、参加者のトランジット・二者間経路は別々に証明する必要がある。

IX側が残すべき証拠

MIXは、スイッチ、内部リンク、会員ポート、ルートサーバープロセスの状態を再構成できるべきだ。fabricについては、インターフェースエラー、トポロジー変更、ARP/Neighbor Discovery、broadcast量、制御面保護、影響ポート範囲が重要になる。

ルートサーバーについては、セッション状態、受理・拒否経路数、ポリシーバージョン、IRR/RPKIデータの鮮度、community処理、更新レートを保管する。内部監視が正常でも参加者から部分的な到達不能が見える場合があるため、外部経路観測と時刻を合わせる必要がある。

公開報告は機密設定を開示せずとも役立つ。影響したサービス面、開始・復旧境界、失敗した制御の種類、参加者への範囲、恒久対策、同等条件を安全に拒否する負の試験を示せばよい。

参加者側が残すべき証拠

参加者はIXの変化が顧客障害になったかを証明する。バックアップBGPセッションがEstablishedである画面だけでは足りない。どのIX経路が消え、どのトランジット、PNI、他IX経路が選択され、どれだけ時間を要し、代替を失ったプレフィックスがあったかを示す必要がある。

Adj-RIB-In、ローカル選択、広告済み経路を残せば、代替が存在しなかったのか、存在したがポリシーで選ばれなかったのかを区別できる。トラフィック記録は接続ごとの移動量、余裕、損失、遅延を示す。複数参加者が同時に再収束する条件も容量モデルに含めるべきだ。

DNSとアプリケーションの外部probeも必要になる。BGP収束後も、stateful firewall、戻り経路、traffic engineeringにより取引が失敗する場合がある。最終指標は経路の存在ではなくサービス結果である。

経路セキュリティは可用性そのものではない

RPKI INVALID拒否は重要な受入れ制御であり、IRRとパス検査も有効だ [2]。RFC 7454はBGP運用セキュリティを整理し、RFC 9234はBGP RolesとOnly-to-Customerを導入する [5][6]。

ただし正しいoriginの経路でも、容量不足や関係の誤り、物理経路喪失は起こる。逆に登録情報が古ければ、正当な緊急経路が拒否され得る。緊急時にフィルターを外すのではなく、台帳を更新し、受理すべき経路と拒否すべき経路を平時に試験する必要がある。

レジストリは台帳であり実行結果ではない

PeeringDBは現在、AS16004をMIX S.r.L. - Milan Internet eXchangeに結び付けている [3]。これは識別、連絡、プロビジョニングの継続性に役立つが、特定パケットの転送やbest pathを示さない。

ここにHeng.luの論点がある。レジストリは台帳・記録者であって、実行中ネットワークを保証する主権者ではない。ASNの身元、意図したポリシー、配備設定、観測経路を照合して初めて運用上の正当性が確認できる。

再収束を監査可能にする

証拠パッケージには、想定状態、トリガーの時系列、変化前後の経路、トラフィックとサービス結果、修復と再試験を含める。原因をfabric、ルートサーバー、参加者ポリシーのいずれかに断定できない場合は、その不確実性を明記し、観測不足を修正する。

MIXのノートは妥当な設計目標を示す [1]。それが実現したかどうかは、IXと参加者の証拠を共通時刻とセッション識別子で結合して判断する。冗長性とは接続数ではなく、許容できない損失を起こさずに完了した、検証可能な状態遷移である。

出典

  1. https://www.mix-it.net/en/the-peering-lan-is-not-inherently-a-critical-point-of-failure/
  2. https://www.mix-it.net/en/route-server/
  3. https://www.peeringdb.com/api/net?asn=16004
  4. https://www.rfc-editor.org/rfc/rfc7947.html
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://www.rfc-editor.org/rfc/rfc9234.html