オンプレミスからアドバタイズされたルートがデフォルトルートで困る場合はプレフィックスリストを使おう
デフォルトルートがアドバタイズされると不都合なんだが
こんにちは、のんピ(@non____97)です。
皆さんはDirect ConnectやSite-to-Site VPNを用いている際にオンプレミスからAWSにアドバタイズしてきたルートがデフォルトルートになって困ったことはありますか? 私はあります。
例えば、NAT Gatewayを一つのVPCに集約していたり、VPCとVPC間やVPCとオンプレミス、インターネット間の通信をNetwork Firewallなどで検査したい場合です。
以下のようにアウトバウンドのインターネット集約用のEgress VPCを用いている場合を考えます。
この時、Direct Connect Gatewayからはデフォルトルート(0.0.0.0/0)をアドバタイズしてくるものとします。実際にDirect Connectデリバリーパートナーが提供しているサービスの仕様で任意のプレフィックスに集約できず、強制的にデフォルトルートでアドバタイズしてくることがあります。
このようにデフォルトルートがアドバタイズされる場合、VPC AやVPC BのようなSpoke VPCはオンプレミス上のネットワークと通信することができません。
なぜならStaticとDynamicのルートが重複している場合、Staticが優先されるためです。
静的ルートと伝達ルートが同じ送信先を持つ場合、静的ルートの優先度が高くなるため、伝達されたルートはルートテーブルに含まれません。静的ルートを削除すると、重複する伝達ルートがルートテーブルに含まれます。
インターネットのアウトバウンド通信をEgress VPCに集約する関係上、デフォルトゲートウェイをEgress VPCとするルートはStaticである必要があります。
そのため、Direct Connect Gatewayからはデフォルトルートがアドバタイズされていると、Spoke VPCはDirect Connectを介してオンプレミスネットワーク間と通信することができません。
これは困りました。
という時に出てくるのがプレフィックスリストです。
プレフィックスリストを使う
Transit Gatewayとプレフィックスリストを連携することで、簡単に複数Transit Gateway route tableで同一ルートを設定することが可能です。
プレフィックスリストを使わない場合、自身で複数のTransit Gateway route tableを設定する必要があります。
以下の図で言うと、3つのTransit Gateway route tableでそれぞれ3ルートを設定する必要があります。
このぐらいであれば何とでもないかもしれませんが、本来オンプレミスネットワークからアドバタイズしたかったルートが100個程度で、Transit Gatewayも100個ほどあると、人力対応は非常に大変です。
そんな時にプレフィックスリストを使うと、初回に各Transit Gateway route tableでプレフィックスリストの参照を設定していれば、仮にネットワークの更新があったとしても以降はプレフィックスリストの更新のみで済みます。
やってみる
検証環境
簡単ですが実際に触ってみます。
検証環境は以下のとおりです。
プレフィックスリストにエントリを追加し、Transit Gateway route tableとプレフィックスリストを関連付けるとルートが追加されることを確認します。
プレフィックスリストの作成
プレフィックスリストを作成します。
以下のネットワークアドレスを登録します。
- 10.10.0.0/24
- 10.100.0.0/24
- 192.168.10.0/24
なお、プレフィックスリストの最大エントリは 100 × Direct Connect GatewayにアタッチしているPrimaryのVIFの本数 で十分です。Private VIFおよびTransit VIFにおいて、オンプレミスからVIFへアドバタイズできるルートの上限は100です。
オンプレミスから へのプライベート仮想インターフェイスまたはトランジット仮想インターフェイス上のボーダーゲートウェイプロトコル (BGP) セッションあたりのルート AWS。
BGP セッションで IPv4 と IPv6 にそれぞれ 100 を超えるルートをアドバタイズする場合、BGP セッションはアイドル状態になり BGP セッションが DOWN になります。IPv4 と IPv6 にそれぞれ 100
そのため、100 × Direct Connect GatewayにアタッチしているPrimaryのVIFの本数 以上の値を最大エントリに設定したとしても無駄になります。
プレフィックスリストが作成できました。
プレフィックスリストとTransit Gatewayの関連付け
プレフィックスリストとTransit Gatewayの関連付けを行います。
プレフィックスリストのリファレンスを作成します。
用意したプレフィックスリストをDirect Connect GatewayのTransit Gateway attachmentをターゲットにしてリファレンスを作成します。
リファレンスが作成されたことを確認します。
ルートを確認して、プレフィックスリストに登録しているエントリをCIDRとしてルートタイプ伝達済みのルートが3つ作成されていることが確認できました。
また、プレフィックスリストを確認すると、Transit Gateway route tableと関連づいていることを確認できました。
プレフィックスリストにエントリを追加
プレフィックスリストにエントリを追加して、Transit Gateway route tableに反映されることを確認しましょう。
プレフィックスリストに172.31.250.0/24のエントリを追加しました。
プレフィックスリストの変更は即座に行われるのではなく、反映に少し時間がかかります。Modify-in-progressとなっています。
数十秒ほど待つと状態がModify-completeとなりました。
Transit Gateway route tableを確認すると、プレフィックスリストで追加したエントリのルートが登録されていました。
便利ですね。
プレフィックスリストの最大エントリを変更
プレフィックスリストの最大エントリを変更した際の動きを確認します。
具体的にはTransit Gatewayのルート上限以上の最大エントリを設定した場合の挙動です。
Transit Gatewayで扱えるルート数のデフォルトクォータは10,000です。
1 つの Transit Gateway のすべてのルートテーブルにわたるすべてのルート (動的ルートと静的ルート) の合計数 10,000
プレフィックスリストの最大エントリは関連付けるリソースのエントリ数のクォータのカウント対象です。
カスタマーマネージドプレフィックスリストのサイズは、最大 1,000 個まで変更できます。詳細については、「プレフィックスリストのサイズ変更」を参照してください。リソース内でプレフィックスリストを参照する場合、プレフィックスリストのエントリの最大数は、リソースのエントリの数のクォータに対してカウントされます。例えば、最大エントリ数が 20 個のプレフィックスリストを作成し、セキュリティグループルール内でそのプレフィックスリストを参照する場合、セキュリティグループの 20 個のルールとしてカウントされます。
と言うことで、複数のプレフィックスリストの最大エントリ数の合計が10,000以上の場合にエラーとなるか確認します。
最大エントリの合計が9,800になるようにプレフィックスリストを用意しました。
全プレフィックスリストのリファレンスを作成します。
追加で作成したプレフィックスリストに実際にエントリは登録していないため、ルートは変わりありません。
それでは、最大エントリを100から300に変更します。これでTransit Gatewayに関連付けているプレフィックスリストの最大エントリの合計が10,100となります。
はい、何もエラーにならずModify-completeとなりました。
このあと最大エントリを300から1000変更しましたが、こちらも特にエラーになりませんでした。ルートも変わらず4つ存在しています。
Service QuotasからTransit Gatewayのルート数の上限であるRoutes per transit gateway (L-BCC1FB47)を確認すると、説明はNumber of static routes per transit gateway.と静的ルートのクォータである記載がありました。
AWS公式ドキュメントでは動的ルートも含むような記載がありましたが、実際は静的ルートのみなのでしょうか。
複数のプレフィックスに対しての同一のターゲットのルートや複数Transit Gateway route tableに同一のルートを設定したい場合はプレフィックスリストを活用しよう
オンプレミスからアドバタイズされたルートがデフォルトルートで困る場合はプレフィックスリストを使おうと言う話をしました。
複数のプレフィックスに対しての同一のターゲットのルートや複数Transit Gateway route tableに同一のルートを設定したい場合はプレフィックスリストを活用しましょう。
今回はTransit Gatewayとプレフィックスリストの例を出しましたが、VPCのルートテーブルについてもプレフィックスリストを送信先CIDRとして指定することが可能です。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
