この記事は、オンプレミスの施設を相互に接続し、Azure と接続するようにソフトウェア定義ワイド エリア ネットワーク (SD-WAN) を設計するネットワーク アーキテクトを対象としています。 ここでは、Microsoft バックボーンの上に効率的でグローバルな SD-WAN オーバーレイを構築することで、Azure のお客様がプラットフォームへの既存の投資を使用できるようにするアーキテクチャについて説明します。
適用可能なシナリオ
この記事の推奨事項はベンダーに依存せず、2 つの基本的な前提条件を満たす Microsoft 以外の SD-WAN テクノロジに適用されます。
- NAT トラバーサルを使用したトンネル モード IPSec ESP など、基になるトランスポートとして Transmission Control Protocol (TCP) や User Datagram Protocol (UDP) を使用するトンネリング プロトコルへの依存。
- 外部エンティティとのルート交換に対する Border Gateway Protocol (BGP) v4 のサポート。 Microsoft 以外の SD-WAN デバイスが相互にルート指定情報を交換するために使用するルート指定プロトコルに関する前提条件はありません。
これらの推奨事項に従うお客様は、選択した SD-WAN テクノロジを使用して、次の目標を達成できます。
- Azure Virtual Network と SD-WAN デバイス間のルート交換を自動化することで、SD-WAN 製品を既存の Azure ハブ アンド スポーク ネットワークに統合します。
- ローカル インターネット ブレークアウトがあるブランチの接続 (Azure とオンプレミスのデータセンターの両方) を最適化します。 Microsoft バックボーンのリーチと、その容量、回復性、「コールド ポテト」ルート指定ポリシーを組み合わせることで、グローバル SD WAN の高性能アンダーレイとして使用できることを示唆しています。
- すべての Azure 間トラフィック (リージョン間および地域間) には、Microsoft のバックボーンを使用します。
- 既存のマルチプロトコル ラベル スイッチング (MPLS) ネットワークをハイ パフォーマンス アンダーレイとして使用します。 また、ビジネスへの影響を最小限に抑える段階的なアプローチで既存の MPLS ネットワークを置き換えるためにも使用できます。
次のセクションでは、閲覧者が SD-WAN パラダイムの基本と Microsoft バックボーンのアーキテクチャに精通していることを前提としています。 Microsoft のバックボーンは、Azure リージョンを相互接続し、パブリック インターネットにも相互接続します。
Architecture
グローバル プレゼンスと複数リージョンの Azure フットプリントを持つ組織は、通常、接続サービスの組み合わせを使用して企業ネットワークを実装し、Microsoft バックボーンに接続します。
- MPLS Internet-Protocol-Virtual-Private-Networks (IPVPN) などの専用接続サービスは、データセンターや本社などの最大のサイトで使用できます。
- 大規模サイトには、サポートされている接続モデルのいずれかを使用して、ExpressRoute 回線を介した Microsoft バックボーンへの専用接続を含めることができます。 具体的には、サイトは専用のポイントツーポイント回線を使用して、最も近い ExpressRoute ピアリングの場所に接続できます。 または、MPLS IPVPN を適用して、MPLS キャリアによって提供される ExpressRoute 回線にアクセスすることもできます。
- インターネットに接続できるブランチ オフィスでは、IPSec VPN を使用して最も近いオンプレミス データセンターに接続し、そのデータセンターの ExpressRoute 接続を使用して Azure リソースにアクセスできます。 または、IPSec VPN を使用して Azure ハブ アンド スポーク ネットワークに直接接続することもできます。
SD-WAN プロジェクトでは、置き換える従来のネットワーク サービスの範囲が異なる場合があります。 一部の組織では、大規模施設用の専用リンクまたは MPLS に従い、SD-WAN のみをデプロイして、小規模サイトの従来のインターネット ベースの IPSec VPN を置き換える必要がある場合があります。 他の組織では、SD-WAN を MPLS に接続されたサイトに拡張し、既存の MPLS ネットワークをハイ パフォーマンス アンダーレイとして使用する場合があります。 最後に、一部の組織では、MPLS IPVPN を無視する場合があります。 または、SD-WAN パラダイムを受け入れるための任意の専用接続サービス。 これにより、企業ネットワーク全体を、パブリック アンダーレイまたは共有アンダーレイ (パブリック インターネットと Microsoft バックボーン) の上に論理オーバーレイとして構築できます。
この記事で説明するアーキテクチャは、前述のすべてのスコープをサポートしており、次の原則に基づいています。
- SD-WAN デバイスは、各 Azure リージョンのハブ アンド スポーク ネットワークにネットワーク仮想アプライアンス (NVA) としてデプロイされ、オンプレミス サイトからのトンネルを終了する SD-WAN ハブとして構成されます。
- Azure の SD-WAN デバイスは相互にトンネルを確立するように構成されているため、Azure リージョン間でトラフィックを効率的に転送し、Microsoft バックボーンの上に地理的に離れたオンプレミス サイト間でトラフィックを中継できる、完全にメッシュ化されたハブ間オーバーレイが作成されます。
- SD-WAN デバイスは、SD-WAN ソリューションの対象となるすべてのオンプレミス サイトにデプロイされ、最も近い Azure リージョンの SD-WAN NVA へのトンネルを確立するように構成されます。 パブリック インターネット、ExpressRoute 接続など、トンネルのアンダーレイとして異なるサイトで異なるトランスポート サービスを使用できます。
- Azure または別のオンプレミス サイト内のサイトから任意の宛先へのトラフィックは、最も近い Azure リージョンの SD-WAN NVA にルーティングされます。 次に、ハブ間オーバーレイを介してルーティングされます。
SD-WAN 製品では、独自のプロトコルと機能を使用して検出できます。いったん動的に確立されると、2 つのサイト間の直接トンネルは、Azure の SD-WAN NVA 経由でトラフィックを中継するよりも優れたパフォーマンスを発揮します。
Microsoft バックボーン、パブリック インターネット、専用 ER 接続をアンダーレイとして使用するグローバル SD-WAN の概要アーキテクチャを次の図に示します。
図 1: Microsoft バックボーン、パブリック インターネット、専用 ER 接続をアンダーレイとして使用するグローバル SD-WAN のアーキテクチャの概要。黒い破線は、2 つのオンプレミス サイト間のトラフィックを、サイトに地理的に近い Azure リージョンにデプロイされた SD-WAN NVA 経由でルーティングする方法を示しています。Microsoft のバックボーンは、その範囲により、容量と「コールド ポテト」ルーティング ポリシーによって、特に長距離接続の場合、パブリック インターネットよりも大幅に優れたパフォーマンスまたは事前に実現できる可能性があります。
Azure ハブ アンド スポーク ネットワークの SD-WAN 製品
このセクションでは、Microsoft SD-WAN 以外の CPE デバイスを NVA として既存のハブ アンド スポーク Azure ネットワークにデプロイするための推奨事項について説明します。
ハブ仮想ネットワーク内の SD-WAN NVA
ハブ アンド スポークは、カスタマー マネージド仮想ネットワークを使用して Azure リージョンにスケーラブルなネットワークを構築するために Microsoft が推奨するトポロジです。 ハブ仮想ネットワークは、Microsoft 以外の NVA やネイティブ サービスなどの共有コンポーネントをホストし、ファイアウォール、負荷分散、サイト 2 サイト VPN または ExpressRoute 経由でのオンプレミス サイトへの接続などのネットワーク機能を提供します。 ハブ仮想ネットワークは SD-WAN NVA の自然な場所であり、最終的にはリモート ネットワークへのアクセスを提供する Microsoft 以外のゲートウェイです。
SD-WAN NVA は、次のようにハブ仮想ネットワークにデプロイする必要があります。
- すべての SD-WAN トラフィックには、1 つのネットワーク インターフェイス コントローラー (NIC) が使用されます。 管理 NIC などの他の NIC は、セキュリティとコンプライアンスの要件を満たすか、Azure デプロイのベンダー ガイドラインに従うために追加できます。
- SD-WAN トラフィックに使用される NIC は、専用サブネットに接続する必要があります。 サブネットのサイズは、この記事で後述する高可用性 (HA) とスケールまたはスループットの要件を満たすためにデプロイされた SD-WAN NVA の数に基づいて定義する必要があります。
- ネットワーク セキュリティ グループ (NSG) は、直接またはサブネット レベルで SD-WAN トラフィック NIC に関連付ける必要があります。 この関連付けにより、SD-WAN ソリューションで使用される TCP/UDP ポート経由のリモート オンプレミス サイトからの接続が許可されます。
- SD-WAN トラフィックに使用される NIC で IP 転送を有効にする必要があります。
ハブ仮想ネットワーク内の Azure Route Server
Azure Route Server は、SD-WAN NVA と Azure Software Defined Networking (SDN) スタック間のルート交換を自動化します。 Route Server では、動的ルーティング プロトコルとして BGP がサポートされます。 Route Server と SD-WAN NVA の間に BGP 隣接関係を確立する方法:
- SD-WAN に接続されているすべてのオンプレミス サイトのルートは、仮想ネットワークのルート テーブルに挿入され、すべての Azure VM によって学習されます。
- 仮想ネットワークのアドレス空間に含まれるすべての IP プレフィックスのルートは、SD-WAN に接続されているすべてのサイトに伝達されます。
Route Server は、次のように構成する必要があります。
- Azure Portal を使用して Route Server を作成および構成するには、ハブ仮想ネットワーク内の専用サブネットにデプロイする必要があります。
- すべてのスポーク仮想ネットワークに対して自動ルート交換を有効にするには、スポーク仮想ネットワークがハブ仮想ネットワークのゲートウェイと Route Server を使用できるように仮想ネットワーク ピアリングを構成する必要があります。 詳細については、「Azure Route Server に関する FAQ」を参照してください。
- Route Server と SD-WAN NVA は異なるサブネットに接続されるため、Route Server と SD-WAN NVA 間の BGP セッションは eBGP マルチホップ サポートを使用して構成する必要があります。 2 から SD-WAN NVA でサポートされる最大値までの任意の数のホップを設定できます。 Route Server の BGP 隣接関係の構成の詳細については、「Azure Portal を使用した Route Server の作成と構成」を参照してください。
- Route Server によって公開される BGP エンドポイントに対して、SD-WAN NVA に 2 つの
/32静的ルートを構成する必要があります。 この構成により、NVA のルート テーブルに、マルチホップ (直接接続されていない) BGP ピアのルートが常に含まれるようにします。
Route Server がデータ パスにありません。 コントロール プレーン エンティティです。 SD-WAN NVA と仮想ネットワーク SDN スタックの間でルートが伝達されますが、SD-WAN NVA と仮想ネットワーク内の仮想マシン間の実際のトラフィック転送は、次の図に示すように、Azure SDN スタックによって行われます。 このルーティング動作を取得するために、Route Server は、ネクスト ホップが NVA の独自のアドレスに設定された SD-WAN NVA から学習するすべてのルートを挿入します。
現在、Route Server では IPv6 はサポートされていません。 このアーキテクチャは IPv4 専用です。
図 2.Route Server は、SD-WAN CPE と仮想ネットワーク SDN スタック間のルート伝達をサポートしますが、SD-WAN CPE と仮想ネットワーク内の仮想マシンの間でトラフィックを転送しません。
Route Server を使用した SD-WAN NVA の高可用性
Route Server には HA が組み込まれています。 2 つのコンピューティング ノードは、Route Server の単一インスタンスをバックアップします。 これらは、異なる可用性ゾーン、可用性ゾーンがサポートされているリージョン、または同じ可用性セットにデプロイされます。 2 つの BGP エンドポイントを公開します。 SD-WAN NVA の HA は、複数のインスタンスを異なる可用性ゾーン、サポートするリージョン、または同じ可用性セットにデプロイすることによって実現されます。 各 SD-WAN NVA は、Route Server によって公開される両方のエンドポイントで 2 つの BGP セッションを確立します。
この記事で説明するアーキテクチャは、Azure Load Balancer には依存しません。 具体的には次のとおりです。
パブリック ロード バランサーは SD-WAN トンネル エンドポイントを公開しません。 各 SD-WAN NVA は、独自のトンネル エンドポイントを公開します。 リモート ピアは、Azure の SD-WAN NVA ごとに 1 つずつ、複数のトンネルを確立します。
内部ロード バランサーは、Azure VM によって送信されたトラフィックを SD-WAN NVA に分散しません。 Route Server と Azure SDN スタックでは、Equal-Cost Multipath (ECMP) ルート指定がサポートされます。 複数の NVA が Route Server で BGP 隣接関係を設定し、同じ優先設定を使用して同じ宛先 (SD-WAN に接続されているリモート ネットワークおよびサイトと同様) のルートを読み上げる場合、Route Server:
- 仮想ネットワークのルート テーブルに、それらの宛先に対して複数のルートを挿入します。
- ネクスト ホップとして異なる NVA を使用するように各ルートを設定します。
その後、SDN スタックは、使用可能なすべてのネクスト ホップにわたってそれらの宛先にトラフィックを分散します。
結果の HA アーキテクチャは、次の図のように表示されます。
図 3.Route Server では、ECMP (Equal-Cost Multipath) ルート指定がサポートされます。可用性やスケーラビリティの目的で複数の SD-WAN NVA を使用する場合、Azure Load Balancer は必要ありません。
N アクティブとアクティブのスタンバイの高可用性
複数の SD-WAN NVA を使用し、それらを Route Server とピアリングすると、BGP がフェールオーバーを実行します。 SD-WAN NVA がオフラインになると、Route Server へのルートのアドバタイズが停止されます。 失敗したデバイスから学習されたルートは、仮想ネットワークのルート テーブルから撤回されます。 そのため、SD-WAN NVA が障害のためにリモート SD-WAN サイトへの接続を提供しなくなった場合、デバイス自体またはアンダーレイでは、仮想ネットワークのルート テーブル内のリモート サイトへのネクスト ホップとして表示されなくなります。 すべてのトラフィックは、残りの正常なデバイスに流れます。 SD-WAN NVA と Route Server 間のルート伝達の詳細については、「BGP ピアによって Route Server にアドバタイズされるルート」を参照してください。
図 4.BGP 起因のフェールオーバー。SD-WAN NVA #0 がオフラインになると、Route Server との BGP セッションが閉じます。SD-WAN NVA #0 は、Azure からオンプレミス サイトへのトラフィックの可能性のあるネクスト ホップとして、仮想ネットワークのルート テーブルから削除されます。
BGP 起因のフェールオーバーと ECMP ルート指定により、N デバイスでトラフィックを同時に処理する N アクティブ HA アーキテクチャが自然に有効になります。 ただし、BGP を使用してアクティブ HA アーキテクチャとパッシブ HA アーキテクチャを実装することもできます。アクティブ ピアよりも優先順位の低いルートを Route Server にアナウンスするようにパッシブ デバイスを構成します。 Route Server は、アクティブ デバイスから同じ宛て先に対して優先度の高いルートを受信した場合、パッシブ デバイスから受信したルートを破棄します。 また、仮想ネットワークのルート テーブル内の後者のルートのみが組み込まれます。
アクティブ デバイスで障害が発生した場合、または一部のルートが取り消された場合、Route Server は次の手順を実行します。
- パッシブ デバイスがアナウンスした対応するルートを選択します。
- 仮想ネットワークのルート テーブル内のルートを組み込みます。
SD-WAN NVA が Route Server にアナウンスするルートの優先順位を表すために使用できる唯一の BGP 属性は AS パスです。
最適なリソース使用 (スタンバイ SD-WAN NVA がない) と水平方向のスケーラビリティを実現するため、N アクティブ HA アーキテクチャをお勧めします。 スループットを向上させるために、Route Server でサポートされている BGP ピアの最大数まで、複数の NVA を並列で実行できます。 詳細については、「BGP パーサー」を参照してください。 ただし、N アクティブ HA モデルでは、SD-WAN NVA がステートレスのレイヤー 3 ルーターとして機能する必要があります。 サイトへの複数のトンネルが存在する場合、TCP 接続を非対称にルーティングできます。 つまり、同じ TCP 接続の元のフローと応答フローは、異なるトンネルと異なる NVA を介してルーティングできます。 次の図は、非対称にルーティングされた TCP 接続の例を示しています。 このようなルーティング非対称性は、仮想ネットワークまたはオンプレミス サイトで開始された TCP 接続に対して可能です。
図 5.アクティブ/アクティブ HA アーキテクチャでの非対称ルーティング。SD-WAN NVA #0 と SD-WAN NVA #1 は、Route Server への AS パス長が同じ宛先 192.168.1.0/24 (リモート SD-WAN サイト) の同じルートをアナウンスします。元のフロー (SD-WAN リモート サイトから Azure への赤いパス) は、AZURE 側で、SD-WAN NVA #1 によって終端されたトンネル経由でルーティングされます。オンプレミスの SD-WAN CPE によってこのトンネルが選択されます。Azure SDN スタックは、仮想ネットワークのルート テーブルに従って、応答フロー (Azure からリモート SD-WAN サイト、緑のパス) を SD-WAN NVA #0 にルーティングします。これは、192.168.1.0/24 で可能なネクスト ホップの 1 つです。Azure SDN スタックによって選択されたネクスト ホップが、元のフローを受信した SD-WAN CPE と常に同じであることを保証することはできません。
アクティブおよびパッシブ HA アーキテクチャは、Azure の SD-WAN NVA が、ステートフル ファイアウォールなどのルーティング対称性を必要とする他のネットワーク機能を実行する場合にのみ考慮する必要があります。 スケーラビリティへの影響が懸念されるため、このアプローチはお勧めしません。 SD-WAN NVA でより多くのネットワーク機能を実行すると、リソースの消費量が増加します。 同時に、アクティブおよびパッシブ HA アーキテクチャでは、任意の時点で 1 つの NVA 処理トラフィックを使用できます。 つまり、SD-WAN レイヤー全体は、サポートされている Azure VM の最大サイズまでしか拡大ができず、最大サイズを超えた拡大はできません。N アクティブ HA の Standard Load Balancer に依存する個別の NVA クラスターでルーティング対称性を必要とするステートフル ネットワーク関数を実行します。
ExpressRoute の接続に関する考慮事項
この記事で説明するアーキテクチャにより、お客様は SD-WAN パラダイムを完全に採用し、パブリック インターネットと Microsoft バックボーンの上に論理オーバーレイとして企業ネットワークを構築できます。 また、後述する特定のシナリオに対応するために、専用の Expressroute 回線の使用もサポートしています。
シナリオ #1: ExpressRoute と SD-WAN の共存
SD-WAN デバイスがサイトのサブセットにのみ展開されている場合、SD-WAN ソリューションは ExpressRoute 接続と共存できます。 たとえば、一部の組織では、インターネット接続のみのサイトで従来の IPSec VPN の代わりに SD-WAN ソリューションをデプロイする場合があります。 その後、次の図に示すように、大規模サイトとデータセンターに MPLS サービスと ExpressRoute 回線を使用します。
図 6: SD-WAN CPE デバイスがサイトのサブセットにのみデプロイされている場合、SD-WAN ソリューションは ExpressRoute 接続と共存できます。
この共存シナリオでは、Azure にデプロイされた SD-WAN NVA が、SD-WAN に接続されているサイトと ExpressRoute 回線に接続されているサイト間でトラフィックをルート指定できるようにする必要があります。 Route Server は、ここで説明されているように、AllowBranchToBranch 機能を有効にすることで、Azure の ExpressRoute 仮想ネットワーク ゲートウェイと SD-WAN NVA の間でルートを伝達するように構成できます。 ExpressRoute 仮想ネットワーク ゲートウェイと SD-WAN NVA の間のルート伝達は、BGP 経由で行われます。 Route Server は両方で BGP セッションを確立し、他のピアから学習したルートを各ピアに伝達します。 プラットフォームは、Route Server と ExpressRoute 仮想ネットワーク ゲートウェイの間の BGP セッションを管理します。 ユーザーは明示的に構成する必要はありませんが、Route Serverを展開するときにフラグを AllowBranchToBranch 有効にする必要があります。
図 7. ExpressRoute 仮想ネットワーク ゲートウェイと SD-WAN NVA の間のルート伝達は、BGP 経由で行われます。Route Server では、両方を使用して BGP セッションが確立され、「AllowBranchToBranch=TRUE」と構成されている場合は両方向にルートが伝達されます。Route Server はルート リフレクターとして機能するため、データ パスの一部ではありません。
この SD-WAN と ExpressRoute の共存シナリオでは、MPLS ネットワークから SD-WAN への移行が可能になります。 従来の MPLS サイトと新しく移行された SD-WAN サイト間のパスが提供されるため、オンプレミスのデータセンター経由でトラフィックをルーティングする必要がなくなります。 このパターンは、移行中だけでなく、会社の合併や買収に起因するシナリオでも使用でき、異種ネットワークのシームレスな相互接続を提供します。
シナリオ #2: SD-WAN アンダーレイとしての Expressroute
オンプレミス サイトに ExpressRoute 接続がある場合は、ExpressRoute 回線上の Azure で実行されている SD-WAN ハブ NVA へのトンネルを設定するように SD-WAN デバイスを構成できます。 ExpressRoute 接続は、ポイントツーポイント回線または MPLS ネットワークを介して行うことができます。 ExpressRoute プライベート ピアリングと Microsoft ピアリングの両方を使用できます。
プライベート ピアリング
ExpressRoute プライベート ピアリングをアンダーレイとして使用すると、オンプレミスのすべての SD-WAN サイトが Azure の SD-WAN ハブ NVA へのトンネルを確立します。 このシナリオでは、SD-WAN NVA と ExpressRoute 仮想ネットワーク ゲートウェイ間のルート伝達は必要ありません (つまり、[AllowBranchToBranch] フラグを false に設定して Route Server を構成する必要があります)。
この方法では、ExpressRoute 接続を終了する顧客側またはプロバイダー側のルーターで適切に BGP を構成する必要があります。 実際、Microsoft Enterprise Edge Routers (MSEE) は、回線に接続されている (直接または仮想ネットワーク ピアリング経由で) 仮想ネットワークのすべてのルートをアナウンスします。 ただし、SD-WAN トンネルを介して仮想ネットワーク宛てのトラフィックを転送するには、オンプレミス サイトは、ER 回線ではなく SD-WAN デバイスからそれらのルートを学習する必要があります。
そのため、ExpressRoute 接続を終了する顧客側またはプロバイダー側のルーターは、Azure から受信したルートを除外する必要があります。 アンダーレイで構成されているルートは、オンプレミスの SD-WAN デバイスが Azure の SD-WAN ハブ NVA に到達できるようにするルートのみです。 ExpressRoute プライベート ピアリングを SD-WAN アンダーレイとして使用する場合は、それに応じてルート指定デバイスを構成できることを確認する必要があります。 これは、ExpressRoute のエッジ デバイスを直接制御できないお客様に特に関連します。 たとえば、EXPRESSRoute 回線が IPVPN サービスの上に MPLS キャリアによって提供されている場合です。
図 8. SD-WAN アンダーレイとしての ExpressRoute プライベート ピアリング。このシナリオでは、顧客側とプロバイダー側のルーターは、ExpressRoute 接続を終了する仮想ネットワーク、ER プライベート ピアリング BGP セッション、および SD-WAN CPE のルートを受け取ります。サイトの LAN に Azure ルートを伝達する必要があるのは、SD-WAN CPE だけです。
Microsoft ピアリング
また、ExpressRoute Microsoft ピアリングを SD-WAN トンネルのアンダーレイとして使用することもできます。 このシナリオでは、Azure の SD-WAN ハブ NVA はパブリック トンネル エンドポイントのみを公開します。これは、インターネットに接続されたサイトの SD-WAN CPE (ある場合) と Expressroute に接続されたサイトの SD-WAN CPE の両方が使用します。 ExpressRoute Microsoft ピアリングにはプライベート ピアリングよりも複雑な前提条件がありますが、次の 2 つの利点があるため、このオプションをアンダーレイとして使用することをお勧めします。
ハブ仮想ネットワーク内の Expressroute 仮想ネットワーク ゲートウェイは必要ありません。 これにより、複雑さが解消され、コストが削減され、ExpressRoute FastPath を使用しない場合に、ゲートウェイ自体の帯域幅制限を超えて SD-WAN ソリューションを拡大できます。
オーバーレイ ルートとアンダーレイ ルートが明確に分離されます。 MSEE は、Microsoft ネットワークのパブリック プレフィックスのみを顧客またはプロバイダー エッジにアナウンスします これらのルートは、別の VRF で管理し、サイトの LAN の DMZ セグメントにのみ伝達できます。 SD-WAN デバイスは、仮想ネットワークのルートを含め、オーバーレイ内の顧客の企業ネットワークのルートを伝達します。 このアプローチを検討しているお客様は、適切なルート指定デバイスを構成できることを確認するか、MPLS キャリアに適切なサービスを要求する必要があります。
MPLS に関する考慮事項
従来の MPLS 企業ネットワークから SD-WAN パラダイムに基づくより最新のネットワーク アーキテクチャへの移行には、多大な労力とかなりの時間が必要です。 この記事で説明するアーキテクチャにより、段階的な SD-WAN 移行が可能になります。 2 つの一般的な移行シナリオについては、後で説明します。
段階的 MPLS のデコミッション
パブリック インターネットと Microsoft バックボーンの上に SD-WAN を構築し、MPLS IPVPN またはその他の専用接続サービスを完全にデコミッションしたいお客様は、移行中に前のセクションで説明した ExpressRoute と SD-WAN の共存シナリオを使用できます。 これにより、SD-WAN に接続されたサイトは、レガシーの MPLS にまだ接続されているサイトに到達できます。 サイトが SD-WAN に移行され、CPE デバイスがデプロイされるとすぐに、その MPLS リンクをデコミッションできます。 サイトは、最も近い Azure リージョンへの SD-WAN トンネルを介して企業ネットワーク全体にアクセスできます。
図 9.「ExpressRoute と SD-WAN の共存」シナリオでは、段階的な MPLS のデコミッションが可能になります。
すべてのサイトが移行されると、MPLS IPVPN を、Microsoft バックボーンに接続する ExpressRoute 回線と共にデコミッションすることができます。 ExpressRoute 仮想ネットワーク ゲートウェイは不要になり、プロビジョニングを解除できます。 各リージョンの SD-WAN ハブ NVA は、そのリージョンのハブ アンド スポーク ネットワークへの唯一のエントリ ポイントになります。
MPLS 統合
必要なパフォーマンスと信頼性を提供するためにパブリック ネットワークと共有ネットワークを信頼していない組織は、エンタープライズ クラスのアンダーレイとして既存の MPLS ネットワークを使用することを決定する場合があります。 2 つのオプションがあります。
- データセンターや大規模なブランチ オフィスなどのサイトのサブセット。
- 接続のサブセット。通常は、待機時間が影響を受けやすいトラフィックまたはミッション クリティカルなトラフィックです。
前述の SD-WAN アンダーレイとしての Expressroute シナリオでは、SD-WAN と MPLS の統合が可能になります。 前述の理由から、ExpressRoute Microsoft ピアリングはプライベート ピアリングよりも優先される必要があります。 また、Microsoft ピアリングを使用すると、MPLS ネットワークとパブリック インターネットが機能的に同等のアンダーレイになります。 これらは、Azure の SD-WAN ハブ NVA によって公開されているすべての SD-WAN トンネル エンドポイントへのアクセスを提供します。 インターネットと MPLS の両方の接続を持つサイトにデプロイされた SD-WAN CPE は、両方のアンダーレイで Azure の SD-WAN ハブへの複数のトンネルを確立できます。 その後、SD-WAN コントロール プレーンが管理するアプリケーション レベルのポリシーに基づいて、異なるトンネル経由で異なる接続をルーティングできます。
図 10.「SD-WAN アンダーレイとしての ExpressRoute」シナリオでは、SD-WAN と MPLS の統合が可能になります。
Route Server ルート指定設定
前の 2 つのセクションで説明した MPLS シナリオの両方で、一部のブランチ サイトを MPLS IPVPN と SD-WAN の両方に接続できます。 その結果、ハブ仮想ネットワークにデプロイされた Route Server インスタンスは、ExpressRoute ゲートウェイと SD-WAN NVA から同じルートを学習できます。 Route Server のルート指定設定を使用すると、優先するパスを制御し、仮想ネットワークのルート テーブルに組み込みます。 ルート指定設定は、AS パスのプリペンドを使用できない場合に便利です。 例として、ExpressRoute 接続を終了する PE でカスタム BGP 構成をサポートしていない MPLS IPVPN サービスが挙げられます。
Route Server の制限と設計上の考慮事項
Route Server は、この記事で説明するアーキテクチャの基礎です。 仮想ネットワークにデプロイされた SD-WAN NVA と基になる Azure SDN スタックの間でルートが伝達されます。 これは、高可用性と水平方向のスケーラビリティを実現するために、複数の SD-WAN NVA を実行するための BGP ベースのアプローチを提供します。 このアーキテクチャに基づいて大規模な SD WAN を設計する場合は、Route Server のスケーラビリティの制限を考慮する必要があります。
次のセクションでは、スケーラビリティの最大値と各制限に対処する方法について説明します。
BGP ピアによって Route Server にアドバタイズされるルート
Route Server では、AllowBranchToBranch フラグが設定されている場合に ExpressRoute 仮想ネットワーク ゲートウェイにアドバタイズできるルートの数に対する明示的な制限は定義されていません。 ただし、ExpressRoute ゲートウェイは、Route Server から学習したルートを、接続先の ExpressRoute 回線にさらに伝達します。
ExpressRoute ゲートウェイがプライベート ピアリング経由で ExpressRoute 回線にアドバタイズできるルートの数には制限があります。詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。 この記事のガイダンスに基づいて SD-WAN ソリューションを設計する場合は、SD-WAN ルートによってこの制限に達しないようにすることが重要です。 制限に達すると、ExpressRoute ゲートウェイと ExpressRoute 回線間の BGP セッションが切断され、ExpressRoute に接続されている仮想ネットワークとリモート ネットワーク間の接続が失われます。
ExpressRoute ゲートウェイが回線にアドバタイズするルートの合計数は、Route Server から学習されたルート数と Azure ハブ アンド スポーク ネットワークのアドレス空間を構成するプレフィックス数の合計です。 BGP セッションの切断による停止を回避するために、次の軽減策を実装することをお勧めします。
- ネイティブ SD-WAN デバイスの機能を使用して、Route Server にアナウンスされるルート数を制限します (この機能が使用可能な場合)。
- [Azure 監視アラート]を使用して、ExpressRoute ゲートウェイがアナウンスしたルート数の急増を事前に検出します。 監視するメトリックの名前は、「ExpressRoute 監視」に記載されているように、[ピアにアドバタイズされたルート数] です。
BGP ピア
Route Server は、BGP ピアの最大数まで BGP セッションを確立できます。 この制限により、Route Server で BGP 隣接関係を確立できる SD-WAN NVA の最大数と、すべての SD-WAN トンネルでサポートできる最大集計スループットが決まります。 この制限に達するのは、大規模 SD WAN のみです。 複数のハブ アンド スポーク ネットワークを作成し、それぞれが独自のゲートウェイと Route Server 持つ以外の回避策はありません。
参加 VM
仮想ネットワーク ゲートウェイと Route Server は、独自の仮想ネットワークおよび直接ピアリングされた仮想ネットワーク内のすべての VM に対して、リモート ピアから学習するルートを構成します。 VM への更新プログラムのルーティングによるリソースの過剰消費から Route Server を保護するために、Azure では、1 つのハブ アンド スポーク ネットワークに存在できる VM 数に制限を定義します。 同じリージョンに複数のハブ とスポーク ネットワークを作成し、独自のゲートウェイと ルート サーバーを持つネットワークを作成する以外にこの制限を打開する回避策はありません。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- フェデリコ・ゲリニ | シニア クラウド ソリューション アーキテクト
- Khush Kaviaj | クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。