BGP セッションが VPC のルートテーブルに現れない理由
EC2 アプライアンス上の BGP セッションは VPC のルートをインストールしません。伝播はルートテーブルごとに有効化が必要で、アプライアンスは今もすべてのパケットを転送します。
よく繰り返される話は、EC2 の VPN アプライアンス上のルーティングデーモンが、BGP が上がれば VPC にリモートプレフィックスを教えるというものだ。その半分は正しい。セッションは上がるが、それによって VPC のルートテーブルは何も変わらない。だから最初の症状は、多くの場合、サブネットが静かにトラフィックをブラックホールに落とすことになる。
ここでは二つの別のものが混同されている。ルートサーバーとのピアリングと、ルートをテーブルにインストールすることだ。
神話:BGP を上げれば VPC がプレフィックスを学ぶ
BGP は二人の話し手の間の会話であり、この設計では話し手はあなたのアプライアンス上のルーティングデーモンと、AWS があなたの所有するサブネットに配置する VPC Route Server のエンドポイントだ。その会話はプレフィックスを運ぶ。ワークロードサブネットのルートテーブルには触れない。それらのテーブルは、それぞれで有効化しなければならない伝播を通じてしか学ばないからだ。それが起きるまで、VPC のファブリックはアプライアンスが知っていることを何も知らない。
設定手順が分かれているのには理由がある。関連付け、エンドポイントの作成、ピアリング、そして伝播の有効化だ。
Route Server はコントロールプレーンであり、トンネルではない
Route Server はパケットを一つも暗号化せず、転送せず、検査しない。アプライアンスと BGP を交換し、得られたプレフィックスをそれを受け取るよう設定されたルートテーブルに渡すために存在する。データプレーンは変わらない。パケットは今もアプライアンスのネットワークインターフェースから出て、その VPN を通り、同じ道で戻ってくる。
つまり、転送インスタンスの送信元・送信先チェックは依然として重要だ。インスタンスは今、他の誰かに宛てられたトラフィックを転送しているからだ。
セキュリティグループとサブネットの制御も、転送されるフローに適用される。Route Server はトラフィックを落とすアプライアンスにそれを転送させることはなく、リモート側で欠けている戻りルートを修復することもない。
伝播は VPC 単位ではなくルートテーブル単位だ
ルートサーバーを VPC に関連付けることと、ルートテーブルで伝播を有効にすることは二つの決定であり、サブネットの動作を変えるのは後者だけだ。ルートテーブルが六つある VPC では、伝播されたプレフィックスを一つで受け取り、残り五つでは受け取らないことがある。これはハブサブネットにとってまさに正しく、そして「半分だけ動く」という不可解な結果を生む原因そのものだ。伝播が有効な場所でも、競合するルートが勝つことがある。VPC のルート選択は最長プレフィックスを優先し、同じ長さなら伝播ルートより静的ルートを優先するからだ。この優先は黙って適用される。
アプライアンスが広告するプレフィックスの一覧ではなく、そのサブネットの実効テーブルを確認すること。API はその問いに直接答える。aws ec2 associate-route-server と aws ec2 enable-route-server-propagation --route-table-id <id> は人が忘れがちな二つの手順であり、aws ec2 describe-route-tables --route-table-ids <id> はプレフィックスがそもそも route server のエントリとして届いたかどうかを示す。
アプライアンスは今もすべてのパケットを運ぶ
到達性を広告することは、到達性を持つこととは違う。BGP セッションはアプライアンスの VPN が落ちていても確立したままでいられるし、決して変わらない静的広告はトラフィックを死んだ経路へ引き寄せ続ける。Route Server は BFD のような障害検出に対応しているが、それはピアの生存を試すものであり、ピアの背後のすべての健全性ではない。
広告を実際のリモートルートに結び付けること。トンネルとリモートネットワークが上がっているときにプレフィックスをアナウンスし、そうでないときに撤回する。
プレフィックスを撤回して、何が起きるか見る
段階的にテストし、最後の段階を削除にする。広告が届くこと、プレフィックスが意図した各テーブルに現れること、アプライアンスが次ホップであること、転送がアクティブなトンネルを通過すること、リモート側が応答することを確認する。そのうえでテスト用プレフィックスを撤回するか、承認済みのトンネルを落として、トラフィックが設計どおりの場所へ動くかを観察する。テストを開いたまま、前後のテーブルを記録する。
ルートを二台目のアプライアンスへ移しても、それが運んでいたセッションは移らない。NAT とファイアウォールの状態は最初の機器に残るからだ。
十二個のプレフィックスという固定の集合なら、VPC のテーブルにおける静的ルートのほうが安い答えであり続ける。Route Server が場所を得るのは、プレフィックスの一覧が本当に変わり、撤回ポリシーを当番の人に説明できるときだ。