ExpressRoute ルーティングの最適化
ExpressRoute 回線が複数あるとき、Microsoft への接続経路は複数存在します。 その結果、期待したルーティングが行われない、つまりトラフィックが貴社のネットワークから Microsoft に到達するまでの経路と、Microsoft から貴社のネットワークに到達するまでの経路が、想定よりも長くなってしまう可能性があります。 ネットワーク パスが長くなるほど、遅延は大きくなります。 遅延は、アプリケーションのパフォーマンスとユーザー エクスペリエンスに直接影響します。 この記事では、該当する問題について例示すると共に、標準のルーティング技術を使ってルーティングを最適化する方法を説明します。
Microsoft ピアリングのためのパスの選択
1つ以上の ExpressRoute 回線がある場合は、Microsoft を利用するときに、トラフィックが目的のパスを経由するようにすることが重要です。 また、インターネットへのパスがインターネット交換 (IX) またはインターネット サービス プロバイダー (ISP) を使用するようにする必要もあります。 BGP では、最長プレフィックス一致 (LPM) を含む多数の要因に基づいて、最適なパス選択アルゴリズムが利用されます。 Microsoft を通じて Azure 宛てのトラフィックが ExpressRoute パスを経由するようにするには、Local Preference 属性を実装する必要があります。 この設定により、パスは常に ExpressRoute で優先されるようになります。
注意
既定のローカル設定は、通常は 100 です。 ローカル設定が高いほど優先度が高くなります。
次のシナリオ例について考えてみます。
上の例では、ExpressRoute パスを優先するには、次のように Local Preference を構成します。
R1 の観点からの Cisco IOS-XE 構成:
R1(config)#route-map prefer-ExR permit 10
R1(config-route-map)#set local-preference 150
R1(config)#router BGP 345
R1(config-router)#neighbor 1.1.1.2 remote-as 12076
R1(config-router)#neighbor 1.1.1.2 activate
R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in
R1 の観点からの Junos 構成:
- user@R1# set protocols bgp group ibgp type internal
- user@R1# set protocols bgp group ibgp local-preference 150
顧客から Microsoft への準最適なルーティング
では、具体的な例を用いてルーティングの問題を詳しく見ていきましょう。 米国のロサンゼルスとニューヨークにそれぞれ 1 つオフィスがあるとします。 2 つのオフィスは、ワイド エリア ネットワーク (WAN) に接続されています。WAN は、自社のバックボーン ネットワークでも、サービス プロバイダーの IP VPN でもかまいません。 ExpressRoute 回線が 2 つ存在し、1 つは米国西部に、もう 1 つは米国東部にあるとします。 両方とも WAN で接続されています。 オフィスから Microsoft のネットワークには、明らかに 2 とおりの接続経路があります。
このとき米国西部と米国東部の両オフィスで Azure (Azure App Service など) をデプロイしているとします。 あなたの意図は、ロサンゼルスのユーザーは Azure 米国西部に接続し、ニューヨークのユーザーは Azure 米国東部に接続することです。 この設定の理由は、あなたのサービス管理者が、各オフィスのユーザーが近くの Azure サービスにアクセスすることで最適なエクスペリエンスが得られると勧めているからです。 このプランがうまく行くのは米国東部のユーザーだけで、米国西部のユーザーには思いどおりの結果が得られません。
問題の原因はそれぞれの ExpressRoute 回線にあり、Azure 米国東部 (23.100.0.0/16) のプレフィックスと Azure 米国西部 (13.100.0.0/16) のプレフィックスの両方をオンプレミスにアドバタイズします。 どのプレフィックスがどのリージョンのものかわからなければ、両者を区別して扱うことはできません。 どちらのプレフィックスも米国西部より米国東部の方が近いと WAN ネットワークで判断される可能性があり、その場合、両オフィスのユーザーが米国東部の ExpressRoute 回線にルーティングされます。 最終的にロサンゼルス オフィスでは、満足なパフォーマンスを享受できないユーザーが続出する結果となります。
解決策: BGP コミュニティの使用
両オフィスのユーザーに使用されるルーティングを最適化するには、Azure の米国西部リージョンに属しているプレフィックスと米国東部リージョンに属しているプレフィックスとを区別できなければなりません。 この情報をコード化するためには、BGP コミュニティ値を使用します。 そこで各 Azure リージョンに一意の BGP コミュニティ値を割り当てました (例: 米国東部には 12076:51004、米国西部には 12076:51006)。 これでどのプレフィックスがどの Azure リージョンに属しているかという情報が得られるので、優先する ExpressRoute 回線を構成することができます。 ルーティング情報の交換に BGP を使用しているので、BGP の Local Preference を使用してルーティングを制御することが可能です。
この例では、13.100.0.0/16 に割り当てる Local Preference 値を米国西部では米国東部よりも大きくすることが考えられます。同様に、23.100.0.0/16 に割り当てる Local Preference 値は、米国西部より米国東部の方が大きくなるようにします。 このように構成することで、Microsoft への経路が 2 つあっても、ロサンゼルスのユーザーは米国西部の ExpressRoute 回線を使用して米国西部リージョンに接続し、ニューヨークのユーザーは米国東部の ExpressRoute を使用して米国東部リージョンに接続することができます。 両側でルーティングが最適化されます。
Note
Local Preference を使用する同じ手法は、プライベート ピアリングを使っているときのお客様から Azure Virtual Network へのルーティングにも適用できます。 Azure からお客様のネットワークにアドバタイズされるプレフィックスに対し、Microsoft は BGP コミュニティ値をタグ付けしません。 しかし、どの仮想ネットワークのデプロイが、どのオフィスに近いかはお客様が把握しているので、一方の ExpressRoute 回線をもう一方よりも優先するようにルーターを構成できます。
Microsoft から顧客への準最適なルーティング
この例では、Microsoft からの接続があなたのネットワークへ達するのに経路が長くなってしまいます。 このケースでは、オンプレミスの Exchange サーバーと Exchange Online をハイブリッド環境で使用しています。 オフィスはいずれも WAN に接続されています。 Microsoft には、両オフィスのオンプレミス サーバーのプレフィックスを 2 つの ExpressRoute 回線を介してアドバタイズします。
Exchange Online はメールボックスを移行する場合などに、オンプレミス サーバーへの接続を開始します。 ロサンゼルス オフィスへの接続が、わざわざ米国東部の ExpressRoute 回線にルーティングされてから、大陸を横断して米国西部のオフィスに戻ってくるという事態が発生しています。 問題の原因は 1 つ目の例と同様です。 手掛かりがなければ、Microsoft のネットワークが、米国東部に近いオンプレミスのプレフィックスと、米国西部に近いオンプレミスのプレフィックスを判別できないのです。 ロサンゼルスのオフィスへの経路が正しく選択されないという事態が起こります。
解決策: AS PATH プリペンドの使用
この問題には解決策が 2 つあります。 1 つ目は、米国西部の ExpressRoute 回線にはロサンゼルス オフィスのオンプレミス プレフィックス (177.2.0.0/31) をアドバタイズするだけです。 次に、米国東部の ExpressRoute 回線にはニューヨーク オフィスのオンプレミス プレフィックス (177.2.0.2/31) をアドバタイズします。 結果的に、Microsoft からそれぞれのオフィスに接続するための経路は 1 つしか存在しないことになります。 あいまいさが排除され、ルーティングが最適化されます。 この設計を採用した場合、フェールオーバーの方針を考慮する必要があります。 ExpressRoute を介した Microsoft への経路が停止した場合、Exchange Online があなたのオンプレミス サーバーに引き続き接続できるように対策を講じなければなりません。
もう 1 つの解決策は、引き続き両方の ExpressRoute 回線で 2 つのプレフィックスをアドバタイズしたうえで、どのプレフィックスがどちらのオフィスに近いか、という手掛かりを Microsoft に知らせる方法です。 BGP の AS Path プリペンドがサポートされているため、プレフィックスの AS Path を構成することでルーティングを制御することができます。 この例では、172.2.0.0/31 の AS PATH を、米国東部では意図的に長くすることが考えられます。そうすることで、このプレフィックスに向かうトラフィックでは、米国西部の ExpressRoute 回線が優先されます。 米国西部でも同様に、172.2.0.2/31 の AS PATH を意図的に長くし、米国東部の ExpressRoute 回線が優先されるようにします。 これで両方のオフィスのルーティングが最適化されます。 このように設計すれば、いずれかの ExpressRoute 回線で障害が発生しても、Exchange Online は、もう 1 つの ExpressRoute 回線および WAN を介して引き続き貴社オフィスに到達することができます。
重要
プライベート AS 番号を使用してピアリングするとき、Microsoft ピア設定では、受信したプレフィックスの AS PATH からプライベート AS 番号が削除されます。 Microsoft ピア設定のルーティングを制御するには、パブリック AS とピアリングし、AS PATH にパブリック AS 番号を付加する必要があります。
Note
ここで示した例は Microsoft ピアリングのものですが、プライベート ピアリングでも同じ機能がサポートされます。 また、AS PATH プリペンドは単一の ExpressRoute 回線内で機能し、プライマリ パスとセカンダリ パスの選択に影響します。
仮想ネットワーク間の準最適なルーティング
ExpressRoute では、2 つの Virtual Network ("VNet") を ExpressRoute 回線で結ぶことで、その両者間に通信を確立することができます。 それらの VNet を複数の ExpressRoute 回線にリンクさせると、その VNet 間のルーティングが最適に行われないケースが生じます。 具体的な例を考えてみましょう。 ExpressRoute 回線が 2 つ存在し、1 つは米国西部に、もう 1 つは米国東部にあるとします。 VNet は、それぞれのリージョンに 2 つずつ存在します。 一方の VNet には Web サーバーが、もう一方の VNet にはアプリケーション サーバーがデプロイされています。 それぞれのリージョンにある 2 つの VNet は、冗長性を確保するために、ローカルの ExpressRoute 回線とリモートの ExpressRoute 回線の両方に接続されています。 次の図で示すように、それぞれの VNet からもう一方の VNet には 2 つの経路が存在します。 VNet からは、ローカルの ExpressRoute 回線とリモートの ExpressRoute 回線を区別できません。 ECMP (Equal-Cost-Multi-Path) ルーティングを使用して VNet 間のトラフィックを負荷分散しているので、一部のトラフィック フローで長い方の経路が選択され、リモートの ExpressRoute 回線を経由してルーティングされています。
解決策: ローカル接続の重みを大きくする
これを解決するのは簡単です。 VNet と回線の位置はわかっているので、それぞれの VNet で優先すべき経路を指定すればよいのです。 具体的にこの例で言えば、ローカル接続に割り当てる重みをリモート接続よりも大きくします (構成例については、こちらを参照)。 VNet は、複数の接続上でもう一方の VNet のプレフィックスを受信すると、重みが最も大きい接続を優先的に選んで、そのプレフィックス宛てのトラフィックを送信します。
注意
複数の ExpressRoute 回線が存在する場合、AS PATH プリペンド (2 番目のシナリオで説明した手法) を適用する代わりに接続の重みを構成することで、VNet からオンプレミス ネットワークへのルーティングを制御することもできます。 トラフィックの送信方法が決定される際、AS Path の長さの前に、それぞれのプレフィックスについて必ず接続の重みが調べられます。
次の手順
- ExpressRoute を高可用性のために設計するについて説明します。
- ExpressRoute をディザスター リカバリーのために設計するについて説明します。