正規のBGPコミュニティが未承認経路を通した理由

要約

内部ルーティングドメインからデータセンターバックボーンへ大量のプレフィックスが広告された。各経路にはそのドメインに正規に割り当てられたBGPコミュニティが付き、入口route-mapを通過した。集約ルーターは経路をすべて受け取り、メモリーを使い切ってルーティングデーモンが再起動した。
Daria Shantalovaの提案は、プレフィックスの識別、境界ごとの通過権、実際のRIB状態との継続照合を別々の制御にする。
発表は、数か月で観測された違反のほぼすべてを除去したと述べるが、初期件数、残数、日付付きの推移は公開していない。

バッジは本物。入場者名簿は見ていなかった

RIPE 93でDaria Shantalovaが報告した障害では、問題の経路が偽のタグを付けていたわけではない。隣接する内部ルーティングドメインが、データセンターを結ぶExpress Backboneへ多数のプレフィックスを送り出した。各経路には、そのドメインに割り当てられた正規のBGPコミュニティが付いていた。入口のroute-mapは値を認識して、広告を通した。

経路は内部iBGPメッシュを伝わり、データセンターの集約ルーターが全件を受け取った。ルーティングデーモンは利用可能なメモリーを使い切って再起動した。公開資料にプレフィックス数、ルーター数、停止時間はない。一方、検査の穴は具体的だ。フィルターが確認したのはコミュニティと送信ドメインの対応関係であり、個々のプレフィックスにその境界を越える資格があるかどうかではなかった。

コミュニティは、起点ドメインや伝播範囲を示せる。しかし、その値を付けた全プレフィックスに、すべての境界で通行権を与えるものではない。

経路数の上限は、通してよい経路を決めない

最大プレフィックス数の制限が尋ねるのは「何件か」。許可リストが尋ねるのは「どのプレフィックスか」。コミュニティのフィルターが確認するのは「タグを認識するか、残すべきか」。互いに補い合えるが、同じ役割ではない。RFC 7454はプレフィックスフィルタリング、最大数制限、コミュニティ処理を別々の運用策として扱う。RFC 4271はBGPの到達性情報交換と経路選択を定める。

Shantalovaの設計は識別から始まる。各プレフィックスに一つのBGP IDコミュニティを付け、起点ドメインと伝播可能範囲を表す。値の欠落、誤り、複数付与、矛盾は違反として数える。次に内部Route Registryが各プレフィックスの想定起点とIDを記録し、ドメイン境界ごとの受信フィルターを生成する。最後に、本番RIBを継続収集して登録内容と比べ、未登録プレフィックスやIDの不一致、意図からのずれを監視して通知する。

登録簿は「こうあるべき」を持ち、RIBは「今こうなっている」を示す。導入時の設定出力一枚では、両者が保たれているとは言えない。比較を止めた瞬間、登録簿は古い願望になる。