ネットワーク運用

vRR設計

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

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

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

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

ルート配信と分離

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

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

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

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

Contrail SD-WAN ソリューションでは、トラフィックをあるサイトから別のサイトに転送するときや、ローカル インターネットにトラフィックを分割する場合に、ルートの配信と分離を同じ方法で実装するため、上記のハブアンドスポークの例が基盤として役立ちます。

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

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

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 ラベルはテナントを識別するためにのみ使用されます。

メモ：

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

AppQoE に関する以下の点に注意してください。

• SRXおよびvSRXデバイスでのみサポートされています。

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

• マルチホーミングに対応しています。

データ プレーンの運用

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

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

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

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

Design Options

図 10 は、上記のパケット ヘッダーを使用してトンネルを導入する方法を示しています。GREoIPSec トンネルは、パブリック ネットワーク上でのセキュアなパケット トランスポートの必要性を考えると、一般的にインターネット パス上で使用されます。GRE トンネルは通常 MPLS パスを介して使用されます。ただし、GREoIPSec オプションも必要に応じて使用できます。

APBR and SLA Management - Data Plane

先ほど説明したように、テナントはアプリケーション トラフィックに対して 1 つの SD-WAN モードの SLA 管理を選択できます。

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

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

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

• パッシブプローブ

  • アプリケーション トラフィックと共に進むインライン プローブ

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

  • アプリケーション セッションの RTT、ジッター、パケット ロスの監視を有効にする

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

• アクティブプローブ

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

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

  • 代替パスの監視に使用

メモ：

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

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テンプレートを介して手動で設定できます。

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

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

Cloud Breakout

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

Usage Notes for Cloud Breakout

• WANリンクにパブリックIPアドレスを使用するGRE(一般ルーティングのカプセル化)トンネルは、クラウドブレークアウトでサポートされています。

• 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. Provider Hub(Central)

エンタープライズ ハブ サイトで複数のブレークアウト オプションが使用可能な場合、ブレークアウト トラフィックの優先度は次のようになります。

SD-WAN ポリシーなし:

1. データセンター部門

2. ハブ

SD-WANポリシーの場合:

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

2. データセンター部門

3. Provider Hub(Central)

Use Cases for Local Breakout

ローカル ブレークアウトの使用例を以下に示します。

Service Provider Data Center

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

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

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

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

このシナリオの一例として、図 16 に示すように、データ センターは MPLS ネットワークの別の場所(POP など)に配置できます。この場合、トラフィック フローは通常、上記と同じままです。

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

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

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

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

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

• 最適でないパスが作成され、トラフィックがトンネルを経由してハブ デバイスに流れ、DC に到達するために 2 重に戻すだけです。

ただし、次に示すメリットもあります。

• オーバーレイトンネルを使用することで、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を使用してテナントのプライベートネットワークスペースからインターネット(パブリック)ネットワークスペースに変換する必要があります。

スポーク サイトでは、オンプレミス デバイスが Auto-NAT を使用して、すべてのローカル ブレークアウト トラフィックでソース NAT を自動的に実行できます。ハブサイトでは、Auto-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)をサポートしています。これにより、CSOは以下を行うことができます。

• SCEP サーバーとして機能する

• SCEP 腹筋として機能する

  • 証明書の取り消し

  • 認定書の自動更新

• CPE/サイトへの証明書の導入

• CPE(サイト)で証明書を管理する

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

• サイト/CPE 認定書の更新

• Microsoft CA/NDESのサポート

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

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

Data Plane

データ プレーン接続は、PKI ベースの認証で IPsec を使用するように構成できます。使用する場合、ローカルのオンプレミスデバイスは、ネットワークを介してリモートサイトに送信する前にトラフィックを暗号化し、認証はパブリックキーとプライベートキーのペアで処理されます。

Management and Control Plane

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

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