要約

  • RFC 7947のIXPルートサーバーは、到達性を配る制御プレーンの仲介者であり、データ転送の中継点ではない。そのため通常は自分のASをAS_PATHへ追加せず、広告元のNEXT_HOPをそのまま受信者へ渡す。
  • クライアントが受け取るUPDATEでは、BGPセッションの相手、AS_PATH先頭のAS、転送先のルーターが一致しない。first AS整合性チェックの例外は、確認済みのルートサーバー隣接だけに閉じ込め、その他のインポート判断は維持しなければならない。
  • 正しさはセッション状態ではなく、広告元の出力、サーバーの検証、クライアント別の選択、Adj-RIB-Out、受信側Adj-RIB-In、FIB、ARP/NDP、実パケットを連結して立証する。二台のサーバーも、経路ごとの出力が一致して初めて冗長となる。

一つの例外が全隣接へ漏れた

文書用のアドレスとASNだけを用いた検証環境を考える。参加者Aがテスト用プレフィックスをIXPの二台のルートサーバーへ広告し、参加者Bが両方とeBGPセッションを張る。Bが受け取ったUPDATEのAS_PATHはAのASNから始まり、NEXT_HOPはAのpeering LANアドレスである。UPDATEを送ったルートサーバーのASNは経路にない。

Bの標準テンプレートは、外部隣接のASNとAS_PATHの左端が一致することを要求する。セッションはEstablishedになるが、テスト経路は拒否される。担当者はチェックを外して問題を解消しようとする。しかし設定階層を誤り、同じ例外がトランジットを含む全隣接へ展開される。

正しい変更は、IXPの公式情報で確認したルートサーバーのアドレスにだけ例外を置くことだ。経路が受理されると、BのFIBはルートサーバーではなくAのアドレスを次ホップに選ぶ。パケットは共有スイッチを介してBからAへ直接進む。

二台目とのセッションも正常に見えるが、そこからはテスト経路が来ない。クライアント別ポリシーを適用する順番によって、許可された代替経路まで隠れている。セッション数、プレフィックス総数、ホストの稼働という三つの緑色表示は、どれもBが受け取る同じサービスを証明していない。

この事例は合成したもので、特定のIXPの障害ではない。狙いは、通常のeBGPで重なりやすい四つの主体を分離することにある。TCP/BGPの相手、AS_PATHの先頭、NEXT_HOPの所有者、パケットが実際に通る装置は、ルートサーバー環境では意図的に別物となる。

ルートを扱うが、トラフィックは扱わない

IXPでは複数の自律システムが共通のレイヤー2基盤へ接続する。全参加者が相互に二者間セッションを作れば、接続数と運用調整は急増する。ルートサーバーは、多数のネットワークとの到達性交換を少数のセッションへ集約する。

この機能は観測用のルートコレクターとは異なる。コレクターは分析のためにfeedを受け取る。IXPルートサーバーは本番の経路配布へ参加し、入力検証、選択、クライアントごとの出力を行う。

一方で、通常の転送ルーターでもない。BGPを話し、RIBを持ち、配布判断をしても、対象トラフィックを中継しない。参加者間のパケットは交換基盤上を直接移動する。

この境界を理解すると、AS_PATHに何を残すべきかが分かる。AS_PATHは、自律システムの経路、ポリシー、ループ検出に使われる。UPDATEに触れた全プロセスの出席者名簿ではない。セッションを話したという理由だけでサーバーASNを加えれば、存在しない転送ホップを作り、下流の選択まで変え得る。

ルートサーバーは見えないのではない。セッション、RIB、ポリシー、ログには明確に現れる。ただし、その権限は経路仲介に限定され、転送履歴を自分の存在証明に使ってはならない。

属性を変えないことも能動的な設計である

RFC 4271の一般的なeBGP手続きでは、外部へ広告する話者が自分のASをAS_PATHへ追加する。RFC 7947はルートサーバーについて、既定ではその追加を行わず、明示設定がなければAS_PATHを改変しないよう勧告する。余分なASは長さ比較やポリシーマッチを変えるからだ。

NEXT_HOPについてはさらに強く、元の値を変更せずクライアントへ渡すことを求める。Aの経路を選んだBは、Aの交換網インターフェースへ直接送るべきである。ルートサーバーのアドレスへ書き換えれば、転送しない制御装置へパケットを引き寄せてしまう。

透明性は「何もしない」という意味ではない。サーバーは不正なプレフィックスやoriginを拒否し、参加者の配布指示を解釈し、B向けの候補を選べる。透明性が制限するのは、介入を転送ホップのように偽装することだ。

したがって記録は二種類必要になる。BGP属性は転送判断に必要な経路情報を運ぶ。サーバー側のAdj-RIB、検証ログ、ポリシー世代は、仲介者が何をしたかを運ぶ。きれいなAS_PATHだけでは誰が配布を止めたか分からず、設定画面だけではパケットの行方が分からない。

first ASの不一致を許す範囲

外部から受けたAS_PATHの左端が隣接ASNと一致するかを調べる実装は多い。二者間ピアやトランジットでは、関係に合わない経路を見つける有用な確認になる。透明なルートサーバーはこの前提を意図的に破る。

RFC 7947はクライアント実装にチェックを無効化できることを求め、できれば隣接単位にするよう勧める。例外の正当性は、その狭さで決まる。対象は正式に確認したルートサーバーだけで、同じ設定を外部隣接の共通テンプレートへ置いてはならない。

チェックを残せば、セッションは生きたまま有効経路を捨てる。全体で外せば、通常の隣接で得られたはずの異常信号も失う。双方とも、局所的なプロトコル適応を組織全体の盲点へ変える。

例外を置いても、Bの責任は残る。自ASの経路内出現を検査し、プレフィックス、origin、最大受信数、必要なRPKIやIRR条件を適用する。ルートサーバーは候補を仲介するが、BのLoc-RIBやFIBを支配する権限までは持たない。

クライアントごとの視点がなければ経路が隠れる

参加者は、特定の相手だけへ広告する、ある相手を除外する、全員へ送るといった配布方針を持つ。RFC 7948はCommunity、ルーティングレジストリ、クライアントが操作できるデータベースを表現手段として挙げる。IXP Manager、AMS-IX、LINXの現行文書には、標準CommunityやLarge Communityを使う実例がある。

タグだけでは実行を証明しない。その意味は各IXPが公開した契約で決まり、特定のB向けAdj-RIB-Outに目的の経路が現れて初めて結果となる。

path hidingは、選択とフィルタの順序から生じる。サーバーが同じプレフィックスへの二経路を受け、共通視点でAを最良とする。その後BのポリシーがAを除外する。既に選ばれた一経路だけを出口で消す実装なら、Bが許可する別経路が存在しても何も送られない。

個々の処理は正しそうに見える。最良経路の選択も、Bの拒否規則も、空の出力もそれぞれ説明できる。欠けているのはBの視点で最良を再計算する段階である。

RFC 7947は、フィルタ後に選択できるクライアント別Loc-RIBを移植性の高い対策として記す。共通部分を共有し差分だけ保持する最適化も可能だ。複数経路を送るDiverse PathsやADD-PATHも候補になるが、ADD-PATHではクライアントの非活動経路をサーバーが新たな入力として受けないよう、サーバーから送信のみとする考え方が示される。

FRRoutingは現在、route-server clientごとのLoc-RIBモデルを文書化している。AMS-IXはBIRDのsecondary利用を説明する。しかし機能名はテストではない。二つの候補を作り、共通の優先経路をBだけで拒否し、許可された代替が実際にBへ届くか確認する必要がある。

NEXT_HOPを保存するなら、入口で所有者を確かめる

元のNEXT_HOPを保つことで、データはサーバーを迂回する。同時に、参加者Aが自分のプレフィックスへ別ASの参加者Cのアドレスを指定する余地も生まれる。サーバーがそのまま配れば、多数のクライアントがCへトラフィックを向ける。

RFC 7948は、受信したNEXT_HOPが広告クライアントのインターフェースアドレスに一致するかをサーバー側で確認し、異なるASに属する不一致を破棄するよう勧める。同じASが複数ポートを持つ場合には、明示的な例外があり得る。IXP Managerも同種の検証を記載している。

この検証を仲介側で行う理由は、そこでまだ入力セッションの身元が分かるからだ。多数の広告がBへの一本のセッションに集約された後では、Bが次ホップの権限を個別に再構成するのは難しい。

ただし、正当なアドレスでも到達不能になり得る。スイッチ障害が非推移的なら、BからルートサーバーへのBGPは生き、AのNEXT_HOPに対するARP/NDPだけが失敗する。制御サーバーへのpingと参加者間のデータプレーン試験を分ける必要がある。

二台という台数ではなく、出力の同等性を測る

RFC 7948は共有セグメント上の複数ルートサーバーを推奨する。異なる実装やOSを使えば、単一のソフトウェア欠陥への耐性を高められる。

だが二つのEstablished、二つのプロセス、同じ総プレフィックス数は、Bに対する同じサービスを意味しない。ポリシー生成、IRRスナップショット、RPKI状態、収束時点、クライアント別選択の違いが、個別経路のAS_PATHやNEXT_HOPを変える。

比較単位はクライアント別、AFI/SAFI別、プレフィックス別である。NLRIの有無、AS_PATH、NEXT_HOP、MED、Community、検証印を正規化して指紋化し、期待差分には理由を付ける。各実行プロセスがどの設定世代とデータ世代を使っているかも記録する。

実装多様性は、不透明な差異を正当化する言葉ではない。独立した故障領域と、観測可能な機能同等性が同時に成立して初めて冗長性になる。

一経路を立証する八つの記録

証拠は処理順に結ぶ。

  1. AのAdj-RIB-Outまたはリンク上のcaptureで、原広告を残す。
  2. ルートサーバーのAdj-RIB-Inで、実際の入力を確認する。
  3. 検証ログで、プレフィックス、origin、first AS、NEXT_HOPの判定を説明する。
  4. B向け選択ビューとポリシー世代で、候補が絞られた理由を示す。
  5. サーバーのB向けAdj-RIB-Outで、透明な属性の出力を確かめる。
  6. BのAdj-RIB-Inで、セッションを越えた表現を確認する。
  7. Bの選択済みRIB、FIB、ARP/NDPで、直接次ホップが実装されたことを示す。
  8. capture、counter、probeで、パケットがAへ直接届くことを示す。

マスターRIBはBのビューではない。looking glassは拒否候補を全て見せるとは限らない。意図した設定ファイルは実行中の世代を証明しない。各記録の時刻と主体が揃って、初めて収束中の因果関係まで説明できる。

責任も分かれる。Aは広告内容、サーバー運営者は入口検証と配布契約、Bはローカル受理と選択、IXPは直接レイヤー2配送を担う。一者の緑色表示を別の主体の完了証明に使ってはならない。

例外そのものを試す移行手順

導入時はIXPの権威ある資料から、各サーバーのASN、アドレス、アドレス族、能力、Community契約を固定する。first AS例外はその隣接だけへ置く。

テストプレフィックスを両サーバーへ広告し、入力、検証、B向けビュー、出力、受信、FIB、MAC解決、パケットを順に採取する。期待結果は、通常のeBGPらしい見た目ではない。AS_PATH左端はA、NEXT_HOPもA、サーバーASNは転送履歴へ追加されず、パケットは直接Aへ届く。

成功例だけでなく、Bだけ許可、Cだけ拒否、その逆、優先経路をBで拒否した場合の代替、異ASのNEXT_HOP、IPv4とIPv6を試す。二台の出力は属性単位で比較し、説明できない差異があれば拡大を止める。

ロールバックではクライアント側とサーバー側の旧ポリシー世代を復元する。設定行を戻すだけでは既学習経路が消えない場合があり、route refresh、再評価、限定したセッション操作が必要になる。無関係なサービスを再起動して見た目だけ揃えてはならない。

情報源と限界

プロトコルの中心はRFC 7947で、通常のBGP挙動はRFC 4271と比較した。RFC 7948は冗長性、漏えい、レイヤー2、NEXT_HOP乗っ取りへの運用勧告を示す。RFC 7911とRFC 6774は複数経路方式の根拠である。

FRRouting、BIRD、IXP Managerは実装と自動化の現行文書として用いた。AMS-IXとLINXは実運用の公開例であり、無名のIXPの稼働状態を証明するものではない。冒頭の事例も合成検証である。