この記事は Influencing Traffic over Hybrid Networks using Longest Prefix Match を翻訳したものです。

導入

オンプレミスのデータセンターをクラウドに接続するために、多くの組織がハイブリッドネットワークを利用しています。その際によく用いられるのは、 AWS Direct Connect とプライベート WAN の MPLS 接続を併用してデータセンター群とクラウドリソースとを接続する方法です。このように複数のコネクションがある場合、組織はネットワークトラフィックが通るエンドポイント間のパスを制御できる必要があります。過去のブログ記事 Creating active/passive BGP connections over AWS Direct Connect では、 Direct Connect 利用時に、BGP の最適パス選択アルゴリズム LOCAL_PREF と AS-PATH プリペンドを設定する方法をご紹介しました。本記事では、オンプレミスのデータセンターから AWS への、あるいは逆方向のネットワークパスを制御するために Longest Prefix Match (LPM) ルーティングアルゴリズムを利用する方法をご紹介します。

ハイブリッドクラウドネットワークの構成要素

Direct Connect はお客様のネットワークと、世界中の 100 以上の AWS Direct Connect ロケーション 上の AWS グローバルネットワークバックボーンとの間でお客様専用のプライベートネットワーク接続を作成します。本記事では、 構成要素の例として Direct Connect Gateway と Transit Gateway を用います。1 つの Direct Connect Gatewayは、最大で 3 つの Transit Gateway と関連付けできます。これらの関連付けによって、 Direct Connect Gateway は Transit Gateway にアタッチされた Direct Connect と Amazon Virtual Private Cloud (VPC) との間の接続を構築できます。また、1 つの Transit Gateway はリージョン内外の複数の Transit Gateway と接続できます。

シナリオ 1: 1 つの Direct Connect Gateway

図 1 に、2 つのオンプレミスのデータセンターを示しています。1 つは米国西部 (図中 PHX) にあり、もう 1 つは米国東部 (図中 ATL) にあります。

図 1: 1 つの Direct Connect Gateway を用いた接続

地理的距離を考慮して、PHX は米国西部 (北カルフォルニア) リージョン (us-west-1) に、ATL は米国東部 (バージニア北部) リージョン (us-east-1) に接続されています。各リージョンにある Transit Gateway は、リージョン間でピアリング接続されています。なお本記事の図では両方のデータセンターで Direct Connect 接続を 1 つずつ示していますが、AWS では本番稼働環境においては AWS Direct Connect の回復性に関する推奨事項に従うことを推奨しています。

このとき、AWS リージョンからいずれかのデータセンターへのパスは 2 通りあることに注意してください。例えば、図 2 に示すように、PHX から us-west-1 への接続したい場合を考えてみましょう。

図 2: PHX から us-west-1 への接続の構築

Direct Connect Gateway が 1 つの場合、復路のトラフィックは図 3 に示すように、Direct Connect Gateway から直接 PHX の Direct Connect へ向かう (Path A) か、あるいは ATL の Direct Connect ロケーションを通り、MPLS 接続を経由 (Path B) して PHX に戻ります。

図 3: Direct Connect Gateway が 1 つある場合の 2 つの復路のパス

図 3 では、オンプレミスのデータセンターから AWS リージョンへのトラフィックでは、復路として非対称なルーティングが起こりうることを示しています。この時、いずれかのデータセンターに、双方向のトラフィックが対称になる必要があるステートフルのファイアウォールなどが設置されていると、もしトラフィックがローカルの Direct Connect から始まり MPLS 接続経由で戻ってきた場合に問題となり得ます。

ではこのように Direct Connect Gateway から取りうるパスが 2 通りある場合、どうすればトラフィックが通るパスを制御できるでしょうか? 結論を述べてしまうと、1 つの Direct Connect Gateway からトラフィックが通るパスを制御するシンプルな方法はありません。これは、ネットワーク管理者は Direct Connect Gateway のルーティングの決定への直接的なアクセス権を持っていないからです。(訳注：なお、トラフィックを対称にするという意味では、次項でご紹介する方法の他に、別のブログ記事 Creating active/passive BGP connections over AWS Direct Connect でご紹介している方法を利用することもできます。)

シナリオ 2: 2 つの Direct Connect Gateway

AWS からオンプレミスのデータセンターへのトラフィックを制御するためには、図 4 に示すように、Direct Connect Gateway を 2 つデプロイする必要があります。

図 4: Direct Connect Gateway を 2 つ用いた接続

ここでは、両方の Direct Connect はそれぞれ異なる Direct Connect Gateway を経由して AWS に接続しています。この構成では、AWS とオンプレミスのデータセンターの間には 2 つの異なるパスが張られています。図 5 に示すように、us-west-1 から始まったトラフィックはローカルの Direct Connect を通り直接 PHX に届きます (Path A) 。あるいは別のパスとして、まず Transit Gateway ピアリングを経由して us-east-1 に向かい、ATL の Direct Connect を経由して、MPLS 接続で PHX に届きます。

図 5: AWS リージョンからデータセンターへの 2 つのパス

PHX から us-west-1 への復路のトラフィックも、図 6 に示す通り 2 つのパスを通ることができます。

図 6: データセンターから AWS リージョンへの 2 通りの復路のパス

AWS リージョンからオンプレミスのデータセンターへのネットワークパスの可能性が 2 通りある場合、どうすればトラフィックが通るパスを制御できるでしょうか? お客様が通常よく選択されるのは、パフォーマンスとレイテンシーの観点から、データセンターのローカルの Direct Connect を、オンプレミスと AWS リージョンとの間のプライマリの接続として利用し、プライマリのパスが利用できなくなった場合にのみ、セカンダリパスを利用する方法です。

例えば、PHX のローカルの Direct Connect 接続が利用できなくなった場合を考えてみましょう。この場合でも、us-west-1 のリソースが、図 7 に示す通りセカンダリパスを通って、つまり us-east-1 と ATL を経由して、PHX へリーチできて欲しい、ということになります。

図 7: us-west-1 から PHX までのセカンダリパス

図 7 のように、プライマリのパスが利用できなくなった場合に限り、トラフィックがセカンダリパスを通るようにするにはどうすれば良いでしょうか?

ソリューション: Longest Prefix Match

Direct Connect で BGP トラフィックエンジニアリングを行うには複数の方法があります。この例では、オンプレミスと AWS 間の相互のパス選択を制御するために Longest Prefix Match (LPM) ルーティングアルゴリズムを利用します。LPM では、ルーターはどのアウトバウンドインターフェイスからパケットを送信するのかを決定する際に、ルートテーブル上の複数のルートのうち最も長い/最も具体的な IP プレフィックスを選択します。

本記事の図中のデータセンターは、互いのルート交換に Internal BGP (iBGP) を利用し、Direct Connect 経由で AWS とルート交換を行う際に External BGP (eBGP) を利用します。2 つのオンプレミスのデータセンターはお客様の AS (ASN 65000) 内にあります。また、この例では各 Direct Connect Gateway はそれぞれ ASN 65001 と 65002 が割り当てられています。

us-west-1 の Transit Gateway のルートテーブル上のルートの具体性の制御は、Direct Connect 経由でデータセンターから AWS に広報される IP プレフィックスの長さを制御することで実現できます。データセンターのルーターで BGP を設定すると、具体的な IP プレフィックスは広報され、Direct Connect Gateway と関連付けられた Transit Gateway に伝達されます。その後、Transit Gateway はそのルートテーブル上で最も長いプレフィックスを持つ/最も具体的なルートエントリを選択します。

AWS からデータセンターへのトラフィック

ここまでの例に戻って、us-west-1 のリソースが、PHX データセンター上の送信先 IP アドレス 172.16.0.101 のサーバーにリーチしたい場合を考えてみましょう。us-west-1 に設置された Transit Gateway のルートテーブルは、はじめ表 1 に示すようなエントリを持っています。

表 1: us-west-1 に設置された Transit Gateway のルートテーブル

この段階では、PHX の 172.16.0.0/16 にトラフィックを送信する際は、ローカルの Direct Connect にルーティングします。この 172.16.0.0/16 へのルートは、BGP 経由で us-west-1 の Transit Gateway のルートテーブルに動的に広報されます。代替ルートが必要な場合には、表 2 に示すように、Transit Gateway ピアリングアタッチメントをネクストホップに設定した静的ルートを登録します。

表 2: us-west-1 に設置された Transit Gateway のルートテーブル

この段階で、同一の IP プレフィックスへのルートが 2 つ存在することになります。1 つ目は Direct Connect Gateway から広報された動的ルートです。そして 2 つ目はピアリングアタッチメント経由の、us-east-1 の Transit Gateway への静的ルートです。通常、静的ルートの方が動的ルートよりも優先されます。しかし今回の目標は、Transit Gateway 経由のパスよりも Direct Connect Gateway 経由のパスを優先させることです。これを実現するためには、図 8 に示すように、PHX のルーターから、より具体的なルートを広報する必要があります。

図 8: より具体的なルート (/17) のPHX からの広報

これにより、us-west-1 に設置された Transit Gateway のルートテーブルは表 3 のようになります。

表 3: us-west-1 に設置された Transit Gateway のルートテーブル

ここでは元々の IP プレフィックス 172.16.0.0/16 を、Direct Connect Gateway 経由の、より具体的な 2 つの /17 のルートに変換しました。PHX から広報されたこれらの 2 つの /17 の IP プレフィックスは、元々の /16 の IP プレフィックスと同じルートをカバーしており、また今回の送信先である 172.16.0.101 も含んでいます。

3 つ目に登録されているルート 172.16.0.0/16 は Transit Gateway ピアリングアタッチメント経由で、これも今回の送信先 172.16.0.101 とマッチします。しかし、IP プレフィックスが短く具体性が低いため、図 9 に示す通り、us-west-1 に設置された Transit Gateway は、より具体的な /17 のパス、すなわち Direct Connect Gateway 経由のパスを優先します。

図 9: Longest Prefix Match によるプライマリパスの選択

ではもし、図 10 に示すように、PHX の Direct Connect 接続が利用できなくなった場合にはどうなるでしょうか?

図 10: PHX の Direct Connect の停止

その場合には、PHX のルーターは us-west-1 への BGP による経路広報を停止します。図 11 に示すように、過去に広報されていた /17 のルートは広報されなくなり、 us-west-1 に設置された Transit Gateway は、Transit Gateway ピアリングアタッチメント経由の 172.16.0.0/16 のルートへトラフィックをフェイルオーバーします。

図 11: セカンダリパスへのフェイルオーバー

なお上のシナリオ (図 11) で、このトラフィックのパスが動作するためには、ATL のデータセンターも 172.16.0.0/16 のプレフィックスを BGP 経由で us-east-1 に広報する必要があることに注意してください。

データセンターから AWS へのトラフィック

LPM を利用して、先ほどまでとは逆方向のトラフィックも制御することが可能です。PHX から開始するトラフィックが、us-west-1 (10.0.0.0/16) のリソースにリーチしたい場合を考えてみましょう。このときローカルの Direct Connect がプライマリパスで、MPLS がセカンダリパスとします。また、送信先のリソースは IP アドレス 10.0.0.101 の VPC 内にあるとします。

この場合、PHX の Direct Connect Gateway から広報されたルートが、MPLS 経由で広報されたルートよりも具体的なルートであって欲しい、ということになります。これを実現するためには、図 12 に示すように、10.0.0.0/17 と 10.0.128.0/17 を AWS から PHX に広報される IP プレフィックスとして登録します。これは AWS コンソールの Direct Connect Gateway 画面のゲートウェイの関連付けにおいて、許可されたプレフィックスを登録することで実施できます。

図 12: us-west-1 へのパスについて、LPM を利用したローカルの Direct Connect の優先

その結果、PHX のルーターのルートテーブルは、表 4 に示す通りになります。

表 4: PHX のルートテーブル

/17 のルートの方がより具体的なので、PHX のルーターは us-west-1 の送信先 10.0.0.101 にリーチするためのパスとしてローカルの Direct Connect を利用します。もし PHX のローカルの Direct Connect が利用できなくなった場合は、図 13 に示すように、PHX のルーターは、MPLS 経由のパス (10.0.0.0/16) にフェイルオーバーして、us-east-1 を経由して us-west-1 の送信先にリーチします。

図 13: MPLS へのフェイルオーバーによる us-west-1 へのリーチ

また、us-west-1 からの復路のトラフィックも、図 14 に示すように同一のパスを逆向きに通ることになります。

図 14: us-west-1 から PHX への復路のトラフィック

なお BGP は AWS とデータセンターの間でのルートの広報に使用されますが、Transit Gateway ピアリングでは使用されないことに注意してください。そのため、Transit Gateway 間でトラフィックをルーティングするためには、それぞれの Transit Gateway で手動で静的ルートを登録する必要があります。

まとめ

オンプレミスのデータセンターを世界中のクラウドリソースに接続するために、多くのグローバルな組織がハイブリッド接続モデルを採用しています。これらのハイブリッドネットワークではオンプレミスとクラウド間のパスを複数持つことができ、Direct Connect と、MPLS などの プライベート WAN 接続の両方を利用できます。本記事では、Longest Prefix Match を用いて、トラフィックが選択するネットワークパスを制御する方法をご紹介しました。例としては、172.16.0.0/16 が、172.16.0.0/17 と 172.16.128.0/17 のような、より具体的な 2 つのプリフィックスに分割できることを示しました。このように、より具体的なルートを使用することでトラフィックのパス選択を制御することができます。

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