ネットワーク運用

vRR設計

すべてのCSO導入環境には、SD-WAN環境にコントロールプレーン機能を提供する1つ以上のvRRインスタンスが含まれます。 図 1 は、各サイトのオンプレミス デバイスが vRR とピアリングする一般的な例を示しています。

図 2 は、vRR からの CLI 出力の例を示しています。

コントロールプレーンの耐障害性

CSO リリース 3.3 以降では、冗長性と拡張性を提供するために、複数の vRR のインストールがサポートされています。CSOはvRRを2つの冗長グループ(RG)に分割し、単一の仮想IPアドレスをネットワークから見えるようにします。サイトの設定の一環として、CSOは各RGのデバイスとvRRの間でBGPピアリングセッションを確立します。プライマリ vRR に障害が発生したり、接続が失われたりしても、2 番目の vRR は引き続き接続サイトの LAN ルートの受信とアドバタイズを行うため、冗長性が確保されます。この設計を 図3に示します。

ルートの分散と分離

Contrail SD-WAN ソリューションは、Junos OS の VRF(仮想ルーティングおよび転送)インスタンスと MP-BGP ルート ターゲットを使用して、テナント ルートを分離し、マルチテナントを実現します。

これらの概念は、MPLS VPN 環境を例にとるとわかりやすい説明になります。 図 4 に示すように、各顧客には一意のルート ターゲット値が割り当てられ、顧客 VPN のすべてのサイトでそのルート ターゲット値が使用されます。ルータは、顧客のルーティング情報をアドバタイズするときに、どの顧客 VRF がアドバタイズメントを発信したかに基づいて、適切なルート ターゲット値を付加します。受信側ルーターは、アタッチされたルート ターゲット値を使用して、受信したルーティング情報を配置するカスタマー VRF を特定します。

MPLS VPNハブアンドスポーク環境では、 図5に示すように、ルートターゲットの使用方法が異なります。各顧客に対して、すべてのスポーク VRF は、ルーティング情報を送信するときに同じルート ターゲット値を付加します。受信側ルーターは、同じルート ターゲット値を持つルートを受け取り、ハブ VRF にインストールします。これに対し、ハブ VRF はルーティング情報を送信するときに異なるルート ターゲット値を付加し、受信側ルーターは同じルート ターゲット値を持つルートを受け入れてスポーク VRF にインストールします。

この設定では、ハブ VRF のみがスポーク VRF からのルートを受け入れ、スポーク VRF のみがハブ VRF からのルートを受け入れます。この方法を使用すると、スポークサイトはハブサイトへの到達可能性のみを必要とするため、ルーティング情報はほとんど必要ありません(おそらくデフォルトルートのみ)ため、ルーティングテーブルを小さく、チャーンフリーに保つことができます。

Contrail SD-WAN ソリューションでは、あるサイトから別のサイトへのトラフィックの転送時や、ローカル インターネットへのトラフィックのブレークアウト時に、同じ方法でルートの分散と分離を実装するため、上記のハブアンドスポークの例は、優れた基盤として機能します。

図 6 は、スポーク デバイスが 2 つのオーバーレイ トンネルとローカル ブレークアウトで構成され、すべてのトラフィックが同じインターフェイスから流れるスポーク サイトの例を示しています。各トラフィック パスには独自の VRF があり、ルート ターゲットはスポーク サイトとハブ サイトで適切に割り当てられ、テナント ルートが適切に分離されます。

APBRおよびSLA管理 - コントロールプレーン

Advanced Policy-based Routing(APBR)により、アプリケーション(グループ)ごとにルーティング動作とパス選択を定義できます。APBRメカニズムは、既知のアプリケーションとユーザー定義のアプリケーションシグネチャに基づいてセッションを分類し、ポリシーインテントを使用してアプリケーションに最適なルートを特定します。アプリケーションベースの動的ルーティングにより、アプリケーションに定義されたSLAパラメータに基づいて、WANリンクを即座に切り替えるポリシーを定義できます。

Real-Time Optimized - AppQoE

リリース3.3.1以降、CSOは、より優れた拡張性と迅速な意思決定を提供するデータプレーンレベルのメカニズムであるAppQoE(Application Quality of Experience)をサポートします。APBRと連携して動作すると、AppQoEはデバイスレベルで機能します。つまり、デバイス自体が利用可能なWANリンク全体でSLA測定を実行し、アプリケーションのSLA要件に最適なパスにアプリケーショントラフィックを動的にマッピングします。これはすべて、CSOコントローラがSLA固有のルートを配布する必要なく行われます。

AppQoE では、SLA 違反が発生すると、SLA 違反を報告したアプリケーションに対応するトラフィックのみが代替リンクに移動されます。このリンクを使用している他のトラフィックは影響を受けません。

リアルタイムで最適化されたSLA管理では、 図7に示すように、デフォルトのVRFのみが必要です。デフォルトの VRF は、すべてのリンクで ECMP を使用します。SLAごとのネクストホップの選択は、データパスで行われます(データプレーンのセクションで説明)。

この場合、MPLS ラベルはテナントを識別するためにのみ使用されます。

手記：

AppQoE は、テナントの SD-WAN モードが [リアルタイム最適化] に設定されている場合に有効になります。これは、SD-WAN展開のデフォルトモードです。

AppQoEについては、次の点に注意してください。

• SRXおよびvSRX仮想ファイアウォールデバイスでのみサポートされます。

• 両端で同じ Junos OS バージョンと同じ設定を使用する必要があります。

• マルチホーミングがサポートされています。

データプレーン動作

このセクションでは、ハブアンドスポーク トポロジーでパケットがどのように転送されるかについて説明します。

スポーク サイトのユーザがオンプレミス CPE デバイスを介してトラフィックを送信し、パケットがローカルでスイッチングされていないか、インターネットに直接送信されていない場合、パケットはトンネルを介してハブデバイスに送信されます。顧客LANからのこのパケットは、まず、ハブデバイスのWANリンクの1つとしてGRE宛先を使用して、MPLSoGREヘッダー内にカプセル化されます。MPLSoGRE ヘッダーの MPLS ラベルは、ハブ サイトでパケットの転送に使用する VRF を識別します。結果のパケット・ヘッダーを 図 8 に示します。

スポークとハブ サイト間のトンネルが IPsec を使用するように設定されている場合、MPLSoGRE パケットはさらに暗号化され、トンネル モードを使用する IPsec ヘッダーにカプセル化されます。結果のパケット・ヘッダーを 図 9 に示します。

ハブでは、まずIPsecヘッダーが復号化されます。結果として得られるパケットの MPLSoGRE ヘッダーは、GRE トンネルを終端し、MPLS ラベルを使用して識別される適切な VRF でルックアップを実行するために使用されます。VRF でのルート検索に基づいて、パケットは別のスポーク サイトに転送されるか、SD-WAN 環境から送信されます。別のスポークに転送された場合、ハブデバイスは上記のようにパケットをカプセル化します。

Design Options

図 10 は、上記のパケット ヘッダーを使用してトンネルが通常どのように展開されるかを示しています。GREoIPSec トンネルは、パブリック ネットワーク上でのセキュアなパケット トランスポートの必要性から、一般的にインターネット パス上で使用されます。GRE トンネルは通常 MPLS パス上で使用されますが、必要に応じて GREoIPSec オプションを使用することもできます。

APBR and SLA Management - Data Plane

前述のように、テナントはアプリケーション トラフィックの SLA 管理に 1 つの SD-WAN モードを選択できます。

• リアルタイムに最適化 – AppQoEを使用したデバイスレベルのSLA管理

AppQoEは、データプレーンレベルのメカニズムで、より優れた拡張性と迅速な意思決定を提供します。AppQoEでは、リンクスイッチングはデバイスのデータパスのアプリケーションレベルで行われます。デバイス自体が、CSOコントローラを必要とせずに、利用可能なWANリンク全体でSLA測定を実行します。

リンク監視は、2種類のインラインプローブを使用して行われます。

• パッシブプローブ

  • アプリケーショントラフィックに同行するインラインプローブ

  • アプリケーションフローのバースト性を模倣

  • アプリケーションセッションのRTT、ジッター、パケット損失の監視を有効にします

  • SLAコンプライアンスの現在使用されているパスの監視、SLA違反の検出に使用します

• アクティブプローブ

  • すべての潜在パスのSLAデータを収集する定期的なプローブ(設定に基づく)

  • トラフィックの元の最適なパスを決定するために使用

  • 代替パスの監視に使用

手記：

AppQoE は、テナントの SD-WAN モードが [リアルタイム最適化] に設定されている場合に有効になります。

Tunnel Liveliness

トラフィックのブラックホーリングを回避するために、オーバーレイネットワークで適切な活性チェックを実施します。Contrail SD-WAN ソリューションは、2 つのメカニズムを使用して活性を確保します。

• IPsecデッドピア検出(DPD)(使用されている場所)

• GREキープアライブ

メッシュタグとダイナミックメッシュVPN

導入モデルの説明でも触れたように、ダイナミックメッシュは、ジュニパーがCSO内にフルメッシュVPNを実装した、リソースを節約したソリューションです。このセクションでは、有効にできるメッシュタグとダイナミックメッシュVPNの操作について説明します。

Mesh Tags

メッシュタグは、CSOのオンボーディングプロセス中にCPEおよびハブデバイスのWANインターフェイスに適用されるテキストベースのラベルです。CSOには、インターネットとMPLSの2つのデフォルトメッシュタグが付属しています。CSO管理ポータルを使用して、独自のメッシュタグを作成できます。オンデマンド(動的)VPNは、同じメッシュタグを共有するWANインターフェイス間でのみ形成できます。

次の説明では、メッシュタグがどのように機能するか、およびそれらが適用されるいくつかのユースケースについて説明します。

前述のように、各サイトの CPE デバイスの各 WAN インターフェイスに 1 つのメッシュ タグが適用されます。NFX150やNFX250などのスポークデバイス、およびほとんどのSRXシリーズファイアウォールでは、各WANインターフェイスに適用できるメッシュタグは1つだけです。SRX4x00シリーズデバイスなどのプロバイダハブおよびエンタープライズハブデバイスでは、デバイスのVPN機能の向上により、複数のメッシュタグを各インターフェイスに適用できます。

以下のリストは、メッシュタグとダイナミックメッシュVPNが関係するさまざまなユースケースを示しています。

• Connecting Different Underlay Links

  

• Site-to-Site Tunnels Based on Capacity

  

• Geo-Based Meshing

  

• With Dual CPE

  

• Dynamic Mesh Load Balancing

  

• Redundant Link

  

Dynamic Mesh VPNs

図 11 は、3 つのスポーク サイト間の動的メッシュ VPN トポロジーを示し、サイト間 VPN がどのように起動されるかを示しています。

手記：

トンネルの削除も、トラフィックしきい値とsyslogメッセージングを使用して、CSOによって制御および自動化されます。

インターネットブレイクアウト

インターネット宛てのトラフィックは、オーバーレイトンネルを経由して中央サイトを経由して送信できますが、トンネルは通常、サイト間のトラフィックをサポートすることを目的としています。SD-WAN以外の宛先の場合、ローカルブレイクアウトは、ローカルオンプレミスデバイスからインターネットにトラフィックを直接送信するオプションを提供します。ローカル ブレークアウトにより、テナントは各サイトでネットワーク帯域幅を最適に使用でき、すべてのトラフィックを中央サイトに伝送するコストを回避できます。

最近では、多くの企業が企業ネットワークの外部でホストされるSaaSサービスを使用しているため、ローカルブレイクアウトはSD-WAN導入において重要な機能です。これらのSaaSアプリケーションのほとんどは、トランスポートとしてSSLを使用し、エンタープライズAAAシステムとのシングルサインオンもサポートしているため、インターネット経由でトラフィックを直接送信しているにもかかわらず、セキュリティ上の懸念に対処しています。

WAN Interface Options

オンプレミス デバイスの WAN(MPLS およびインターネット)インターフェイスは、トンネル ブレークアウト トラフィックとローカル ブレークアウト トラフィックを任意の組み合わせでサポートできます。

• トンネリングされたトラフィックのみ

• トンネリングされたブレイクアウトトラフィックとローカルブレイクアウトトラフィック

• ローカル ブレークアウト トラフィックのみ

Design Options

設計要件に応じて、ローカルブレークアウトを実装する方法は複数あります。

Breakout at Spoke

スポークサイトでのローカルブレークアウトにより、ユーザーはオーバーレイネットワークを介してハブにトラフィックを送信することなくインターネットに直接アクセスできるため、トンネル帯域幅を節約できます。このオプションは、インターネットまたは MPLS WAN リンクのいずれかに実装できます。 図 12 は、この概念を示しています。

ローカルブレークアウトを使用する場合、インターフェイスベースまたはプールベースのNATのいずれかを指定できます。

Breakout at Provider Hub (Central Breakout)

図 13 に示すように、プロバイダー ハブ サイトの中央ブレークアウトでは、スポーク サイトがインターネット宛てのトラフィックをオーバーレイネットワークを介してプロバイダー ハブデバイスに転送し、プロバイダー ハブ デバイスがトラフィックをインターネットに転送するハブアンドスポーク展開が可能になります。

ハブ サイトでの中央ブレークアウトは、スポーク サイトとは異なる方法で有効になります。CSOでステージ2のテンプレートを使用して手動で構成できます。

中央ブレークアウトは、エンタープライズ ハブ サイトを介してスポーク サイトに提供することもできます。このシナリオでは、エンタープライズ ハブは、転送にアンダーレイ ネットワークを使用してローカル ブレークアウトを実行するか、データセンター部門からデフォルト ルートを受信してスポークに伝送できます。

中央ブレークアウトがデフォルトルート方式を介してプロバイダハブとエンタープライズハブの両方で提供される場合、BGPローカル設定を使用してエンタープライズハブからのデフォルトルートが優先されます。

Cloud Breakout

インターネット宛てのトラフィックの別のブレークアウト オプションであるクラウド ブレークアウトは、スポーク サイトとエンタープライズ ハブ サイトで使用できます。クラウド ブレークアウトが有効になっている場合、スポーク サイトまたはエンタープライズ ハブ サイトは、インターネット宛てのトラフィックを Zscaler に転送し、セキュリティ関連の処理をさらに行ってから、インターネットに送信します。Zscalerアカウントは、ブレイクアウトを介してトラフィックを送信する前に、アクティブでアクセス可能である必要があります。

Usage Notes for Cloud Breakout

• WANリンクにパブリックIPアドレスを使用するGRE(Generic Routing Encapsulation)トンネルは、クラウドブレイクアウトでサポートされています。

• GREトンネルを使用する場合、CPEデバイスをNATの背後にすることはできません。

• クラウド ブレークアウト設定を構成する場合、IPsec フェーズ 1 パラメータ、フェーズ 2 パラメータ、およびドメイン名を指定できます。

• クラウド ブレークアウト ノードの IP アドレスまたはホスト名の検証を指定できます。

• CSOは、FQDN、事前共有キー、WANリンク情報を自動入力し、自動入力された値を変更するオプションを提供します。

• CSOは、SD-WANスポークサイトのWANリンクとクラウドブレイクアウトノード間の高可用性をサポートします。

• WANリンクノードは、アクティブ/パッシブまたはアクティブ/アクティブとして設定できます。

• SD-WAN スポークサイトとクラウドブレークアウトノードの間には、最大 2 つの WAN リンクを定義できます。

Order of Preference for Scenarios with Multiple Breakout Options

スポークサイトの CPE で複数のブレークアウトオプションが使用可能であり、ブレークアウトポリシーが指定されていない場合、ブレークアウトの優先順位は次のとおりです。

1. データセンター部門/エンタープライズハブ

2. ローカル ブレークアウト/クラウド ブレークアウト

3. プロバイダー ハブ (中央)

エンタープライズ ハブ サイトで複数のブレークアウト オプションを使用できる場合、ブレークアウト トラフィックの優先順位は次のとおりです。

SD-WANポリシーなし:

1. データセンター部門

2. ハブ

SD-WANポリシーを使用:

1. ローカル ブレークアウト/クラウド ブレークアウト

2. データセンター部門

3. プロバイダー ハブ (中央)

Use Cases for Local Breakout

以下に、ローカルブレークアウトのユースケースのいくつかについて説明します。

Service Provider Data Center

このユースケースでは、エンタープライズのお客様は、サイト間の相互接続にサービスプロバイダのSD-WANサービスを使用します。お客様は、サービスプロバイダのデータセンターでホストされている付加価値サービスも利用します。

スポークサイトでは、オンプレミスデバイスのMPLSに面したWANインターフェイスが、トンネリングされたブレイクアウトトラフィックとローカルブレイクアウトトラフィックの両方をサポートするように設定されています。 図 14 に示すように、トラフィックは次のようにネットワーク上を流れます。

• サイト間(SD-WAN)トラフィックは、オーバーレイトンネルを使用して MPLS ネットワーク上を移動します。

• DC を宛先とするトラフィックは、ローカル ブレークアウトを使用し、アンダーレイ MPLS ネットワークを直接通過します。

このシナリオのバリエーションとして、 図 16 に示すように、データ センターを MPLS ネットワーク上の別の場所、たとえば POP に配置できます。この場合、トラフィックフローは基本的に上記と同じままです。

このシナリオの別のバリエーションとして、DC宛てのトラフィックは、オーバーレイトンネルを使用し、ハブデバイスでブレイクアウトし、DCにダブルバックすることができます( 図16を参照)。

このオプションにはいくつかの欠点があります。

• より多くのトンネル帯域幅を使用します。

• スポークサイトのオンプレミスデバイスがより多くのトラフィックを処理してカプセル化するため、レイテンシーが増加する可能性があります。

• ハブデバイスへの負荷が増加します。

• その結果、最適ではないパスが作成され、トラフィックがトンネルを通ってハブデバイスに到達し、DCに到達するまでに倍返しが必要になります。

ただし、いくつかの利点もあります。

• オーバーレイトンネルを使用することで、DCを宛先とするトラフィックはSLAサービスを活用して、最適なパスを動的に選択できるため、これらのアプリケーションのネットワークパフォーマンスが向上します。

• 追加のセキュリティ機能を一元的に提供することもできます。

Migration to SD-WAN

このユースケースでは、顧客企業は複数の広い拠点を所有し、サービスプロバイダの既存のMPLSサービスを使用してサイト間のフルメッシュを提供します。お客様はSD-WANへの移行を希望しており、実装は段階的である可能性が高い。それでも、サイト間の接続を常に維持することは重要です。

図 17 は、移行が進行中のシナリオを示しています。SD-WAN機能はサイト3とサイト4に追加されていますが、他のサイトはまだ移行されていません。各SD-WAN対応サイトでは、オンプレミスデバイスのMPLS向けWANインターフェイスが、トンネル化されたブレイクアウトトラフィックとローカルブレイクアウトトラフィックの両方をサポートするように設定されています。トラフィックは次のようにネットワーク上を流れます。

• SD-WAN対応サイト間のトラフィックは、オーバーレイトンネルを使用できます。

• SD-WAN 対応サイトとレガシー サイト間のトラフィックは、ローカル ブレークアウトを使用し、アンダーレイ MPLS ネットワーク上を直接移動します。

この場合、ローカルブレークアウトは、移行されたサイトとレガシーサイト間の接続を維持するための鍵となります。

Local breakout and NAT

トラフィックがテナント VRF からインターネットに流れる場合、通常、NAT を使用してテナントのプライベート ネットワーク スペースからインターネット(パブリック)ネットワーク スペースに変換する必要があります。

スポーク サイトでは、オンプレミス デバイスが自動 NAT を使用して、すべてのローカル ブレークアウト トラフィックに対してソース NAT を自動的に実行できます。ハブ サイトでは、自動 NAT は使用できません。ただし、CSO UI では、これらのオンプレミスデバイスの NAT ルールの手動作成がサポートされています。

Local Breakout and DNS

オンプレミスのデバイスをLANセグメントのDHCPサーバーとして設定すると、エンドホストのDNS サーバー情報を指定できます。ローカルブレークアウトが有効になっているサイトでは、一般的には複数のネームサーバーを指定することをお勧めします。企業ドメイン名解決用の内部サーバーと、インターネット宛てのローカルブレイクアウトトラフィック用のパブリックサーバーまたはISPサーバーです。

ネットワークセキュリティ

SD-WANアーキテクチャのセキュリティに関する重要な考慮事項の1つは、保存データだけでなく移動中のデータにもセキュリティを提供することです。データ セキュリティが強化され、データ トンネルと OAM トンネルにマルチレベル PKI を使用できるようになりました。これにより、CSOはCAサーバからマルチレベルのCA 証明を受信し、複数のCA 証明をCPEデバイスにプッシュし、CPEデバイスで複数のCA 証明を更新および失効できます。

CSOは、CSOリリース4.1以降、SCEP(Simple Certificate Enrollment Protocol)をサポートしています。これにより、CSOは以下が可能になります。

• SCEP サーバーとして動作

• SCEP cllientとして機能

  • 証明書の失効

  • 証明書の自動更新

• CPE/サイトへの証明書の配布

• CPE (サイト) での証明書の管理

• CA サーバ情報の GUI サポートの提供

• サイト/CPE 証明書の更新

• Microsoft CA/NDESサポート

• 各サイト/CPEのブローカー証明書

PKI 機能へのプログラムによるアクセスのために、バックエンド API が提供されています。

Data Plane

データ プレーン接続は、PKI ベースの認証で IPsec を使用するように設定できます。使用する場合、ローカルのオンプレミスデバイスは、ネットワーク経由でリモートサイトに送信する前にトラフィックを暗号化し、認証は公開鍵と秘密鍵のペアで処理されます。

Management and Control Plane

CSOは、コンソールやNETCONFの接続にSSHを使用してオンプレミスデバイスに接続し、設定を行います。CSOリリース4.0以降、専用のOAMオーバーレイトンネルは、オンプレミスデバイスとCSO間のセキュアなエンドツーエンドの通信を強化するのに役立ちます。 図 18 に示す IPsec 暗号化および PKI 認証済み OAM トンネルを使用すると、オンプレミスのスポーク デバイスは、管理、ルーティング、およびロギング トラフィックをネットワーク経由でプロバイダー ハブに安全に送信できます。その後、ハブはトラフィックをCSOに転送します。

詳細は、このガイドで前述した「 セキュアで冗長なOAMネットワーク」 セクションを参照してください。