AWS Direct Connect でのアクティブ/パッシブ BGP 接続の構築

この記事は Creating active/passive BGP connections over AWS Direct Connect を翻訳したものです。

お客様のデータセンターを AWS に接続する方法はたくさんあります。本記事では AWS Direct Connect (DX) を用いてネットワークを構築する際に、お客様からよくご質問いただく、オンプレミスと AWS との間で Direct Connect 経由のアクティブ/パッシブ Border Gateway Protocol (BGP) 接続を構築する方法について解説します。

冗長性を確保し、高いキャパシティを得るために、多くのお客様が 2 つ以上の DX 接続をデプロイしています。この場合のよくあるパターンは、プライベート仮想インターフェイス (Private VIF、Private Virtual Interface) と Direct Connect Gateway (DXGW) を利用する方法と、トランジット仮想インターフェイス (Transit VIF、Transit Virtual Interface) と DXGW を利用する方法の 2 つです。これらのアーキテクチャの図を見てみましょう。

いずれの構成でも、一般的に推奨されているように複数の DX ロケーションを利用しており、2 つのデータセンター (DC) はクラウド経由ではない接続手段を持っています。また、いずれの場合も、お客様のデータセンターからは DXGW に接続されており、その DXGW はさらに仮想プライベートゲートウェイ（VGW、Virtual Private Gateway）あるいは AWS Transit Gateway (TGW) に直接接続されています。

上記のどちらの構成も高いキャパシティと回復性を提供しますが、お客様ができることはこれだけではありません。ご興味のある方は、ぜひ https://aws.amazon.com/directconnect/sla/ で DX SLA の詳細をご覧ください。

複数の DX 接続があると、お客様は経路制御や、ネットワークの最適化をすることが可能になります。

複数の DX 接続を構築する場合にお客様からよくあるご質問は、例えば以下のようなものです。

• AWS の本番環境ネットワークに接続用に 1 つの DX 接続 (プライマリ) を割り当てて、開発環境ネットワークに接続用に別の DX 接続を割り当てるにはどうすれば良いのか?
• 特定のパス (DX 接続) を通るトラフィックを制御し、リソース間の非効率なルーティングや非対称ルーティングを防ぐにはどうすれば良いのか?
• DX 接続あるいはお客様のルーティングデバイスが利用できなくなった場合や、メンテナンスが必要な場合でも可用性を高く保つにはどうすれば良いのか?

BGP ルーティングの概要

CCNA (Cisco Certified Network Associate) の試験と比較して、CCNP R&S (Cisco Certified Network Professional, Routing and Switching) の試験内容はかなり重たかったことを私は覚えています。Border Gateway Protocol (BGP) は CCNP の主要トピックだったのですが、BGP が最適パスを選択するアルゴリズムに関して、私が使用した暗記方法は今でも思い出せます。

We Love Oranges AS Oranges Mean Pure Refreshment
*訳注：直訳すると「私たちはオレンジが好きです。なぜならオレンジは純粋な、(私たちを) リフレッシュさせてくれるもの、を意味するから。」

これは以下の順番を覚えるためのものです。

Weight, Local Pref, Originate, AS_PATH, Origin, MED, Paths, RouterID

これは BGP のアルゴリズムを全て網羅するわけではありませんが、本記事での説明には十分です。本記事では、Local Pref、AS_Path、MED について解説します。

BGP の最適パス選択 (ベストパスアルゴリズム) についてご存知ないという方も、以下でその概要を説明しますので、ご心配は不要です。(ご存知ない方でも、暗記方法の言う通り、オレンジは私たちをリフレッシュさせてくれることには既に同意していただけていると思いますが!)

Border Gateway Protocol (BGP) は Exterior Gateway routing Protocol (EGP) に分類されます。EGP は自律システム (AS、Autonomous System) 間の経路情報を広報するプロトコルです。AS とはその内部のアドレス空間に責任を持つ管理ユニットだと捉えていただくと良いでしょう。AS は 16 ビットあるいは 32 ビットの番号で特定されます。リンクステートやインターフェイスコストを考慮して AS 内部のルーティングを制御する Interior Gateway routing Protocol (IGP) とは異なり、EGP はデータ送信先である外部の AS へのルーティングパスを制御します。EGP がパスベクタ型ルーティングプロトコルと呼ばれることがあるのはこのためです。BGP スピーカー (BGP ピア) がお互いに Network Layer Reachability Information (NRLI) を広報する際、同時にパス属性 (Path Attribute、PA) も広報しており、これらは BGP Update メッセージという特別なメッセージで送信されます。BGP におけるベストパスアルゴリズムは、受け取った全ての経路を考慮し、最適な経路を選択します。アルゴリズムのロジックに沿ってパスを検討していく際には、設定されたポリシーと受信した経路のパス属性を利用します。そして、この検討プロセスは最適な経路 (この経路は複数存在する場合もあります) が見つかったら終了します。

この仕組みの詳細な説明は本記事のスコープ外ですが、こちらの Web ページ https://datatracker.ietf.org/doc/html/rfc4271 で多くの情報をご覧いただけます。

では BGP パス属性のうちの 3 つを少し詳しく見ていきましょう。これらのパス属性の設定は、DX 接続経由の双方向のルーティングの制御に利用できます。

Local Pref – このパス属性はベストパスアルゴリズムの一番はじめに検討されるので、ルーティング制御に最適なパラメータと言えます。インバウンドとアウトバンドの両方で使用され、高い値が優先されます。

AS_Path – このパス属性は、経路広告が通過した全ての AS の AS 番号を結合したものです。パスのループの防止と、距離の目安として利用されます。インバウンドとアウトバウンドの制御の両方で使用され、AS_Path が短いほど優先されます。

MED – このパス属性も Local Pref と同様、数値で表現します。MED は一般的に、ピアリングされた外部 AS に対して、特定の経路の着信先を指定する時に使用します。インバウンド制御で使用され、低い値が優先されます。

前提

DX を使用してオンプレミスと AWS を接続する場合、BGP 接続が必須です。これにより、ポリシーと経路選択ロジックに基づいて、オンプレミスと AWS 間のトラフィックを制御することができます。

BGP ピアリングの設定は、仮想インターフェイスの両端で設定します。以下の表は、DX で利用できる仮想インターフェイスと、利用できる BGP のパス属性をまとめたものです。

* 複数の Public VIF を利用して DX 接続をロードバランスさせる場合、DX のホームリージョンが一致している必要があります。
** Public VIF を利用する場合、パブリック ASN を使用している場合にのみ AS-Path プリペンドが利用できます。
*** 訳注：MED については利用可能ですが、本サービスでは推奨しておらず、正式サポートしておりません。

本記事では BGP のパス属性の説明をしていきますが、一般的に、より具体的なプレフィックスが最も優先されることに注意してください。あるリンクから、より具体的なプレフィックスを広報した場合、BGP の設定によらず、AWS からのトラフィックはより具体的なプレフィックスのリンクを通ることになります。

VIF の種類の詳細については、こちらをご覧ください : https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html

また、DX 接続の種類の詳細については、こちらをご覧ください : https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/WorkingWithConnections.html

ウォークスルー

上述のアーキテクチャでは、いずれの場合も BGP の ASN が DXGW の先 (図中の上部) にもあることにお気づきになったかもしれません。これらの ASN は DC1/DC2 から見た時には AS_Path のリストに存在しません。つまり、DXGW は AWS 側にある AS 群のリフレクタとして動作するものなのです。

今回のアーキテクチャにおける接続の詳細は以下の通りです。

いずれのパターンでも、以下の前提で話を進めます。

• DC1 と DC2 のルーターはどちらもオンプレミスの全ネットワーク範囲を AWS に広報する
• DC1 と DC2 のルーターはどちらも DXGW から AWS ネットワークの全プリフィックスを受け取る

データセンターのルーティングテーブル群について

経路制御を一切行っていない場合、ルートテーブルは次のようになっています。

• DC1/DC2 は 10.0.1.0/24 と 10.0.2.0/24 への経路を持っていて、これらの経路の AS_Path には 65001 が含まれている。外向きの (eBGP 用の) インターフェイスは Private VIF か Transit VIF。
• DXGW は 172.16.1.0/24 と 172.16.2.0/24 への経路を持っていて、これらの経路の AS_Path には 65000 が含まれている。外向きのインターフェイスは DC1 か DC2 と関連付けられた Private VIF か Transit VIF。

さて、ここまでの説明を踏まえると、以下の懸念事項についてお分かりいただけるかと思います。

• 一切経路制御をしていない状態では、DC1/DC2 の AWS へのアウトバウンドのトラフィックを制御し、それぞれ Production あるいは Development ネットワークへ優先的にルーティングすることができない。
• DXGW を経由する AWS からの復路のトラフィックに関して、不必要に DC 間接続を経由する (遠回りの) パスを通らないよう制御ができない。
• 非対称ルーティングの可能性がある。これ自体は必ずしも問題ではないが、経路内にセキュリティデバイスなどが存在する場合に問題になりうる。

なお Private VIF と Transit VIF のどちらを使用する場合でも、エンドツーエンドの通信のためには DX の BGP 以外にも設定が必要です。DXGW や TGW のご利用がはじめてのお客様は、Jeff Bar による以下のブログ記事をぜひご覧ください。

https://aws.amazon.com/jp/blogs/aws/new-aws-direct-connect-gateway-inter-region-vpc-access/

https://aws.amazon.com/jp/blogs/aws/new-use-an-aws-transit-gateway-to-simplify-your-network-architecture/

初期状態の経路はどうなっているでしょう?

1 つ目の課題は、DC1/DC2 から AWS へのアウトバウンド通信をどう制御するのかという点でした。どうすれば DC1/DC2 のそれぞれに Production または Development のネットワークを対応づけて通信できるでしょう? Local Pref を覚えていますか? このパス属性はこのような課題に対して利用できるものです。ポリシー定義を作成して、そのポリシーを DC1/DC2 の間の BGP ネイバー (neighbor) で設定することで利用できます。

設定に変更を加える前の、DC1/DC2 それぞれのルーターの BGP ルートテーブルを見てみましょう。

ご覧の通り、どちらのルートテーブルでも、DC1 と DC2 は AWS への経路としてそれぞれの eBGP ピアを優先しています。これは単に、eBGP のパスは iBGP のパスより優先されるというロジックによるものです。上述の暗記方法でいうところの 7 番目、Pure/Paths が適用されています。

Local Pref によるアウトバウンド通信の経路制御

該当するトラフィックに関して Local Pref の値を増加させた経路を広報するポリシーを作成して、ローカルでのルーティングを制御しましょう。AS 65000 内の BGP ピア間でこれを実施します。Local Pref は iBGP ピアの間でのみ、つまり同一 AS 内のピア間でのみ広報されます。

設定の手順は以下の通りです。

手順を実行した後の BGP ルートテーブルを見てみましょう!

望んでいた通りの結果ですね! DC1 に届く Production ネットワーク ‘10.0.1.0/24’ を送信先とするパケットは、eBGP ピアのインターフェイス ‘169.254.254.41’ にフォワーディングされます。また、Development ネットワーク ‘10.0.2.0/24’ を送信先とするパケットは、AWS に送信される前に DC 間のリンクを経由されるようになっています。DC2 のルートテーブルでも、DC1 の場合と対称のルーティングができています。

AS_Path によるアウトバウンド通信の経路制御

では AS_Path はどうでしょう? これは Local Pref の後に検討されるパラメータで、トラフィック制御に利用できます。設定自体は似ていますが、この場合は AWS の eBGP ピアから、DC1/DC2 にそれぞれ広報されるネットワークの AS_Path を長くする必要があります。こうすると、結果としてそれぞれのルーターは特定の eBGP で学習した経路を「より長い」と捉え、iBGP ピア接続を優先するようになります。これは上述したように、通常とは異なる挙動です。ここで覚えておいていただきたい注意点は、AS_Path を利用する場合は、トラフィックを通過させたくない方の経路に対して設定を実施するということです。

設定の手順は以下の通りです。

設定完了後の BGP のルートテーブルを確認してみましょう。

いいですね! 望み通りの結果が得られています。Path を長く設定することで、アウトバウンドのパス選択を制御できました。

アウトバウンド通信の経路制御のまとめ

上記の方法のいずれか、あるいはその他の方法 (デバイス上の weight の設定) を使ってアウトバウンド通信の経路制御ができます。

しかしながら、BGP のベストパスアルゴリズムでは、Local Pref の方が AS_Path よりも先に考慮されることに気をつけてください。つまりローカルで設定された Local Pref の値は、AS_Path の設定と干渉しうる、ということです!

ここまでの設定、つまり Local Pref あるいは AS_Path によるアウトバウンド通信の経路制御で得られた結果は以下の図の通りです。

Local Pref によるインバウンド通信の経路制御

ここまでの内容ではアウトバウンド通信を扱ったので、次はインバウンド通信の経路制御に注目してみましょう。

インバウンド通信の経路制御でも、Local Pref から始めていきますが、先ほど Local Pref は eBGP ピア間では使用できないと強調したことを覚えていますか? これは一般的に言えることです。それでは、 AWS の AS 65001 がその BGP テーブルに登録する経路を考慮する際に、特定の Local Pref の値を使用するようにするにはどうすれば良いでしょうか?

これを実現するためには、BGP コミュニティを利用します。BGP コミュニティとは、BGP スピーカー間で追加情報を送信するためのものです。BGP コミュニティの詳細についてはこちらをご覧ください : https://tools.ietf.org/html/rfc1997

AWS では複数のコミュニティの値をサポートしています。より詳しい情報についてはこちらをご覧ください : https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/routing-and-bgp.html

BGP セッション経由で広報するプレフィックスのそれぞれについて、以下の通りにコミュニティタグを付与すれば、AWS ルーターは対応する優先度を設定します。これを利用して、復路のトラフィックをお客様のルーターで制御できます。本記事では、以下のコミュニティタグに注目します。

• 7224:7100 – 低優先度
• 7224:7200 – 中優先度
• 7224:7300 – 高優先度

DXGW から見た、現在の状態と、パケットのルーティングを見てみましょう。

DXGW はパスのコストが等しい場合、トラフィックをバランシングするようになっており*、今回もそのようになっています。設定に変更を加える前に、Production VPC 内の EC2 インスタンスで trace-route を実行した結果を見てみましょう。両方のパスが使用されていることがお分かりいただけると思います。これは Equal Cost Multipath (ECMP) によるものです。簡単に言ってしまえば、ECMP は「ルートテーブルに等コストの経路が複数あるので、どれを使っても良いね」というようなものです。

* 両方の DX 接続が同一リージョンにある場合、DXGW はロードバランシングを実施しますが、そうでない場合は DXGW はデフォルトの Local Pref の値に基づいて、AWS からのトラフィックの送信元であるリージョンを選択します。これはお客様が設定する BGP コミュニティの値によって上書きすることができます。

私は以下では traceroute の拡張版である paris-traceroute を使用しています。是非使ってみてください! https://paris-traceroute.net/

sh-4.2$ sudo paris-traceroute -n -a exh 172.16.1.1
traceroute [(10.0.1.10:33456) -> (172.16.1.1:33457)], protocol udp, algo exh, duration 51 s
 1  P(16, 16) 169.254.254.29:0,4,8,9  0.359/0.482/0.984/0.181 ms  169.254.254.25:1,2,3,5,6,7,10  0.352/1.242/5.367/1.710 ms
 2  P(12, 16) 169.254.254.42:0,6,8,9,10  11.271/11.488/11.979/0.234 ms  169.254.254.34:5,7  10.749/10.974/11.200/0.226 ms

sh-4.2$ sudo paris-traceroute -n -a exh 172.16.2.1
traceroute [(10.0.1.10:33456) -> (172.16.2.1:33457)], protocol udp, algo exh, duration 21 s
 1  P(16, 16) 169.254.254.29:0,2,5  0.365/0.876/2.579/0.798 ms  169.254.254.25:1,3,4,6,7,8,9,10  0.325/0.416/0.570/0.075 ms
 2  P(14, 16) 169.254.254.42:0,1,5,7,8,9  11.204/11.715/12.042/0.299 ms  169.254.254.34:2,6,10  10.675/11.104/11.336/0.303 ms

Exhaustive (exh) モードでは、paris-traceroute は全てのパス/ホップの可能性を正確に計算しようとします。出力結果を見ると、DC1 とのピアリングを通るトラフィックも、DC2 とのピアリングを通るトラフィックも存在することが分かります。ここでトラフィックの制御の設定を両方のルーターで行うとどうなるのか、見てみましょう。

AWS がデータセンターへの経路として特定のリンクを優先するように設定した後のトレース結果は以下の通りです。

sh-4.2$ sudo paris-traceroute -n -a exh 172.16.1.1
traceroute [(10.0.1.10:33456) -> (172.16.1.1:33457)], protocol udp, algo exh, duration 11 s
 1  P(16, 16) 169.254.254.29:0,4,8,9  0.367/0.417/0.488/0.035 ms  169.254.254.25:1,2,3,5,6,7,10  0.379/0.435/0.495/0.047 ms
 2  P(1, 6) 169.254.254.42  11.006/11.006/11.006/0.000 ms

sh-4.2$ sudo paris-traceroute -n -a exh 172.16.2.1
traceroute [(10.0.1.10:33456) -> (172.16.2.1:33457)], protocol udp, algo exh, duration 26 s
 1  P(16, 16) 169.254.254.25:0,1,3,4,8,10  0.346/0.651/1.619/0.388 ms  169.254.254.29:2,5,6,7,9  0.375/0.418/0.449/0.033 ms
 2  P(6, 6) 169.254.254.34  9.904/10.142/10.517/0.264 ms

いいですね! 優先したかった経路が常にセカンドホップになっています。これを図にすると以下のようになります。

AS_Path と MED によるインバウンド通信の経路制御

本記事の空きスペースが急激に不足してきてしまいましたが、本記事の完全性のため、Local Pref だけではなく、AS_Path と MED もインバウンドのパス制御に使えることを述べておきます。先ほどのアウトバウンド通信の場合には、上流 (AWS) 側で AS_Path を設定したポリシーを適用し、経路広報によりオンプレミスのルートテーブル上の経路を制御しました。インバウンド通信の場合も、単に先ほどのロジックを逆転させてアウトバウンドのポリシーを適用し、優先させたくない経路の AS_Path を長くすれば良いのです。

MED (暗記方法での Mean/MED) は eBGP スピーカー間で使用されるパス属性です。これを使用すると、外部の AS に、マルチホームの AS の特定のエントリーポイントを使用するように制御ができます。MED は Local Pref と AS_Path の後に考慮されるパラメータなので、ご紹介した 3 つのパス属性の中では最も推奨されません。私のテストでは動作しましたが、このパラメータが有用かどうかはお客様次第でしょう。

経路制御のまとめ

本記事で達成できたことは以下の通りです。

• Local Pref / AS_Path によるアウトバウンドのルーティングの最適化
• Local Pref /AS_Path (あるいは MED) によるインバウンドのルーティングの最適化
• 複数の DX 接続による高いキャパシティと可用性

注意点

もしお客様が、送信元と送信先が明確に定義された (一対一の) ネットワークを、オンプレミスと AWS の両方で構築されている場合は、本記事の設定は動作するでしょう。しかしネットワークが一対多の関係にある場合、例えば本記事のアーキテクチャで、White ネットワークも Development ネットワークと通信する必要がある場合、非対称な通信フローが生じます。この問題はポリシーベースのルーティング、あるいは Network Address Translation (NAT) で解決できます。また、お客様のユースケースは本記事とは異なる場合があります。

まとめ

本記事では、お客様のデータセンターと AWS との動的ルーティングを BGP により制御する方法をご紹介しました。そして複数のパス属性やコミュニティフラグを利用して、アウトバウンドとインバウンドのルーティングの制御に成功しました。なお同様の結果を得る方法は、この記事で述べた方法だけではないことを述べておきます。

ところで、皆さんはどうやって BGP のベストパスアルゴリズムを覚えましたか?

筆者について

翻訳は Solutions Architect の安藤慎太郎が担当しました。原文はこちらです。