はじめに
はじめまして。AWS Direct Connect をよく触っているネットワークエンジニアです。
今回の記事のテーマは少しマニアックな話題になりますが、皆さんはAWS Direct Connectの「100ルート問題」という言葉を聞いたことはありますか？
「100ルート問題」とはAWSドキュメントの Direct Connect クォータのページに記載があるこちらです。
Routes per Border Gateway Protocol (BGP) session on a private virtual interface or transit virtual interface from on-premises to AWS.
If you advertise more than 100 routes each for IPv4 and IPv6 over the BGP session, the BGP session will go into an idle state with the BGP session DOWN.
では実際にオンプレミスからDirect Connectで100ルート以上流してみるとどうなるのでしょうか・・・
▼ Direct Connect BGPピアのCiscoルーターのログ
Jan 16 19:33:21.506 JST: %BGP-3-NOTIFICATION: received from neighbor 192.168.0.2 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 000064
Jan 16 19:33:21.506 JST: %BGP-5-NBR_RESET: Neighbor 192.168.0.2 reset (BGP Notification received)
Jan 16 19:33:21.506 JST: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 Down BGP Notification received
Jan 16 19:33:21.506 JST: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.2 IPv4 Unicast topology base removed from session BGP Notification received
Jan 16 19:33:27.457 JST: %BGP-3-NOTIFICATION: received from neighbor 192.168.0.2 active 6/1 (Maximum Number of Prefixes Reached) 0 bytes
Jan 16 19:33:27.457 JST: %BGP-5-NBR_RESET: Neighbor 192.168.0.2 active reset (BGP Notification received)
Jan 16 19:33:27.457 JST: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 active Down BGP Notification received
Jan 16 19:33:27.457 JST: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.2 IPv4 Unicast topology base removed from session BGP Notification received
Jan 16 19:33:36.673 JST: %BGP-3-NOTIFICATION: received from neighbor 192.168.0.2 active 6/1 (Maximum Number of Prefixes Reached) 0 bytes
Jan 16 19:33:36.673 JST: %BGP-5-NBR_RESET: Neighbor 192.168.0.2 active reset (BGP Notification received)
Jan 16 19:33:36.673 JST: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 active Down BGP Notification received
Jan 16 19:33:36.673 JST: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.0.2 IPv4 Unicast topology base removed from session BGP Notification received
上記のように、BGPピアに広報したルート数が上限値の100ルートを超過したためBGPピアが切断されたことを示すログが数秒おきに出力されます。Direct Connectを冗長化していてもそれぞれの接続で同一のルートをAWSへ広報している場合は、全ての接続が同時にダウンしBGPのログが瞬く間にログ管理ツールを埋め尽くしその様子はまるで地獄絵図と化します。
本記事ではこのような事象が発生する背景と対策、また解決策の１つとして Transit Gateway Connect over Direct Connect についてご紹介します。
100ルート問題の背景・原因と対策
AWS Direct Connect へのルート広報数の上限は以前から100ルートとなっていましたが、100ルート上限を超過したためBGPピアを切断されるトラブルを見る機会がここ数年で特に増えています。その中でも多くの事例で共通していたのが、マルチクラウド接続を行っており Direct Connect と関係のないところでの作業の影響でBGPによりルートが伝播され、結果的にAWSに広報されるルートが100ルートを超過してしまったという点です。
マルチクラウド接続を行っている環境では各パブリッククラウドごとに管理者が異なることも多いですが、ネットワーク環境は全てのクラウドに接続されているのでBGPルート広報の変更を伴う作業を実施する際はネットワーク全体の設計を意識しなければなりません。
ルート広報数が上限値を超えないようにするための対策としては
- 可能な限りBGP広報ルートの集約を行う
- AWS Direct Connect のBGPピアとなるルータにて広報ルートのフィルターを設定する
などが考えられます。また日頃からAWS Direct Connectでのルート広報数をモニタリングしておくことも大切です。
最初から100ルートを超えることが無いように全体のルーティング設計をしておくことがもちろん理想なのですが、とは言ってもどうしてもルート集約をすることができないケースもあると思います。
何か方法はないかということでAWS Blogsを見ていたときに、以下のような記事を見つけました。
Direct Connect 上で Transit Gateway Connect を利用することでAWSへのBGPルート広報数を拡張する？これって探してたやつ？？
ということで検証環境で Transit Gateway Connect over Direct Connect を試してみました。
Transit Gateway Connect とは
まずは Transit Gateway Connect について簡単にご説明します。
Transit Gateway Connect はサードパーティの仮想アプライアンス(SD-WANアプライアンス等)と Transit Gateway を Connect アタッチメントで接続するサービスで、仮想アプライアンスと Transit Gateway の間で直接ルートを広報することができるようになります。Connect アタッチメント上にGREトンネルを作成し、GREトンネル上で２つのBGPセッションを確立します。
仮想アプライアンスは Transit Gateway とアタッチされたVPC内に存在していても、Direct Connect の先のオンプレミスネットワークに存在していてもどちらでも大丈夫です。Connectアタッチメントを作成する際に、トランスポートアタッチメント(=アンダーレイのネットワークで利用するアタッチメント)として、
- VPCアタッチメント
- Direct Connect Gateway アタッチメント
のいずれかのリソースを選択することができます。
以下はAWS Blogsで紹介されていたもので、VPC内の仮想アプライアンスと Transit Gateway を Connect ピアで接続する例です。
【参考】Simplify SD-WAN connectivity with AWS Transit Gateway Connect
検証環境の構成
今回はオンプレミスからのルート広報の上限拡張を目的に Transit Gateway Connect を利用しているので、Direct Connect で利用しているルータと Transit Gateway との間で Connect アタッチメントを作成しました。接続構成の簡単なイメージ図は以下の通りです。
GREトンネルの作成で利用する Transit Gateway 側のアドレスは Transit Gateway CIDR (上図では 100.100.0.0/24) から払い出されるため、Transit Gateway から Direct Connect Gateway 向けには Transit Gateway CIDR のみを広報します。
※Transit Gateway 作成時にCIDRを指定していない場合は、先にCIDRの登録が必要です。
一方 Direct Connect ルータから Direct Connect Gateway 向けには、Transit Gateway Connect のピアGREアドレス (上図では 1.1.1.1/32)のみを広報します。
これにより Direct Connect ルータと Transit Gateway Connect ピアの間でGREトンネル(over Direct Connect)を構成することができます。これらのGREトンネルで利用するIPアドレスは Connect ピア作成時に指定します。
またBGP内部CIDRブロックIPv4では指定した/29のCIDRから、BGPピアで利用するIPアドレスが払い出されます。
実際の構成ではアンダーレイの Direct Connect も冗長化されているので、それぞれの
ConnectピアでBGPセッションを2つずつ構成し、全体で4冗長構成での接続となります。
AWS公式ドキュメントでも複数のConnectピアがある場合にそれぞれのConnectピア上でBGPセッションを2つずつ構成することが推奨されています。AWSに問い合わせてみたところ、アンダーレイの Direct Connect が分散されていたとしてもConnectピアの先のAWS側の環境で複数のBGPセッションが同一のデバイスで終端される可能性があり、Transit Gateway Connect のメンテナンスや障害で同時に影響を受けないようにするために各Connectピア上で2つずつBGPセッションを構成する必要があるとのことでした。
【参考】https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html
実際に上記の構成で Transit Gateway Connect を作成し、Direct Connect を経由して100ルート以上広報してもBGPセッションが切断されずに通信を継続することができることを確認しました。※ドキュメント上では 1000 Prefix まで広報可能となっています。(2024年12月16日時点)
Transit Gateway Connect 利用時の注意点
Transit Gateway Connect over Direct Connect を使うことでAWSへの広報ルートを増やすことはできるのですが、通常の Direct Connect での接続と異なり注意が必要な部分もあるので触れておきます。
注意点1: Direct Connect と TGW Connect over Direct Connect 違い
Direct Connect と TGW Connect (over Direct Connect) について簡単な比較表を作成しました。 ※2024年12月16日時点
| Direct Connect | TGW Connect (over Direct Connect) | |
|---|---|---|
| ルート広報数 (On-prem→AWS) | 100 (IPv4) + 100 (IPv6) | 1000 |
| ルート広報数 (AWS→On-prem) | IPv4 と IPv6 合計で 200 | 5000 |
| AWS→On-prem方向のルート広報設定方法 | Direct Connect Gateway アタッチメントで指定したプレフィックスが広報される(関連づけられているTGWルートテーブルは関係ない) | Connectアタッチメントが関連づけられている TGWルートテーブルのルートが広報される |
| 帯域 | ホスト接続の帯域(もしくはホストVIFが収容されている接続の帯域)に依存 | 各GREトンネルごとに5Gbps GREトンネルは4つまで作成可能で最大20Gbpsまで拡張可能 |
| BFD | 利用可 | 利用不可 |
| ECMP | 利用可 | 異なるGREトンネル中のConnectアタッチメント間で利用可能(同一GREトンネル上のConnectピア間でのECMPは利用不可) |
このように広報ルート数以外にも結構大きな違いがあります。特にBFDのサポート有無については障害発生時の切替時間にかなり影響するので、数秒程度での切替が求められるような環境では TGW Connect over Direct Connect の利用は適していません。一方で通常のBGPタイマーでの切替時間で問題なく、帯域も20Gbps(ECMP利用時)に収まるような環境であれば検討してみても良いかもしれません。
注意点2: ルーティングの回り込みの制御
Direct Connect Gateway と Transit Gateway はアタッチする場合は異なるASNをアサインしなければなりません。下の画像では
- Direct Connect Gateway の ASN: 64512
- Transit Gateway の ASN: 64513
としていますが、ルーター側ではそれぞれのASNからルートを学習し、もう一方のASNに学習したルート情報を広報しようとします。何も制御しなければ Transit Gateway Connect でAWSから学習したルート情報はそのまま Direct Connect へ流れてしまい、せっかく Direct Connect 向けのルート広報を減らしたのが台無しです。ASパスフィルターやPrefixフィルターをそれぞれのBGPピアに適用し、ルート広報の回り込みを防ぐようにしましょう。
注意点3: Transit Gateway Connect 利用コスト
Transit Gateway Connect アタッチメントを作成すると、Transit Gatewayのアカウント所有者に時間単位での請求が発生します。(2024/12/16時点で 0.07 USD/時間)
通常 Transit Gateway の処理データあたりの料金も発生しますが、Transit Gateway Connect については、VPCアタッチメント または Direct Connect Gateway アタッチメントに適用されるデータ処理料金以外の追加料金は発生しないとのことです。
まとめ
本記事ではまずはじめに Direct Connect の「100ルート問題」についてご説明しました。
100ルート上限を超過しないためには、可能な限りルート集約を行うこと・マルチクラウド環境においても全体のネットワーク設計を意識してルーティングの設定変更を行うことが重要です。
またAWSへのBGP広報ルートを拡張する方法として、Transit Gateway Connect over Direct Connect をご紹介しました。こちらを利用することでAWSへのBGP広報ルート数上限を大幅に拡張することができるのですが、障害発生時の切替り時間やBGP広報ルートの回り込みの制御が必要になる等の注意点も多いので、（広報ルート上限の拡張が目的でTransit Gateway Connect over Direct Connectを使うのは）どうしてもルート集約ができないような場合にのみ検討するのが良さそうです。