Link Search Menu Expand Document
27-Jan-25

EdgeConnect SDブランチWANの概要

EdgeConnect SDブランチWANオーバーレイの設計では、WANトポロジ、WAN監視、WANポリシーの3つの重要な要素を考慮する必要があります。これらのエレメントは手を取り合って動作し、最適なパフォーマンスを提供する高度に安全なオーバーレイを提供します。

目次

WANトポロジー

次のセクションでは、EdgeConnect SD-Branchを使用している組織で使用できる3種類のオーバーレイトポロジについて説明します。いずれのトポロジも、別のトポロジと組み合わせて使用できます。

ハブアンドスポーク

Aruba EdgeConnect SD-Branchソリューションは、ヘッドエンドゲートウェイ（ハブ）とBGW（スポーク）の間にSD-WANオーバーレイトンネルが確立されるハブアンドスポーク型トポロジをサポートしています。ヘッドエンドサイトのゲートウェイは、ハブツースポークトラフィックとスポークツースポークトラフィックのルーティングと転送を提供します。

ほとんどの組織のアプリケーションは単一のデータセンターに集中化され、ブランチサイトでは通常、優先順位の低いデータを交換しない、または最小限のデータを交換するため、これがデフォルトの導入です。

次の図は、ハブロケーションを通過するスポークツースポークトラフィックを持つハブアンドスポークトポロジを示しています。

ハブアンドスポーク

展開には、ブランチサイトにインストールされているBGWから開始されたVPNトンネルを終端する1つ以上のゲートウェイがインストールされたヘッドエンドサイトが1つ必要です。各ヘッドエンドサイトに導入されるゲートウェイの数は、全体的な導入サイズと冗長性のニーズによって異なります。小規模な導入では、ヘッドエンドサイトに設置された1つのゲートウェイで構成され、ブランチサイトに設置されたすべてのBGWにサービスを提供します。

大規模なSDブランチ展開では、追加のハブサイトを組み込むことができ、プライマリハブに障害が発生した場合に冗長性を提供します。一般的な大規模導入には、プライマリおよびセカンダリヘッドエンドが含まれます。

追加のハブサイトを使用する、より複雑なトポロジもサポートされています。たとえば、仮想ゲートウェイを使用して特定のアプリケーションまたはサービスをホストするクラウドベースのデータセンターを展開できます。

ハブメッシュ

Arubaは、オンプレミスハブ（物理ゲートウェイ）とクラウドハブ（仮想ゲートウェイ）の間のメッシュトポロジをサポートしています。これにより、ハブサイトは相互に直接通信できるようになり、一般的に地域ハブ間または複数のクラウドプロバイダー間の通信に使用されます。 これには、ブランチサイトからのトラフィックが含まれます。例えば、ブランチサイトに”AWSクラウドDC”宛てのトラフィックがあり、”オンプレミスDC”が優先される場合があります。この場合、”On-Premises DC”はハブメッシュトンネルを使用して”AWS Cloud DC”にトラフィックを転送します。

ハブメッシュ

分岐メッシュ

ブランチメッシュトポロジ構成により、ブランチゲートウェイは、同じグループまたは異なるグループ内の他のブランチゲートウェイと安全なオーバーレイトンネルを確立できます。ブランチメッシュトポロジが2つ以上のブランチゲートウェイ間で設定されている場合、ブランチメッシュリンクが確立され、それらの間でトラフィックが安全に転送されます。ブランチメッシュは、分散型企業や、ハブサイトを介してヘアピンで固定されるべきではない複数のブランチ間通信を持つブランチサイトを持つ組織に使用できます。

ブランチメッシュを使用する場合、ブランチゲートウェイがルートを交換できるように、SD-WANファブリックでサイトを指定してサイト間でOROを有効にする必要があります。 ただし、ブランチサイトが他のブランチサイトと直接通信できなくなるわけではありません。ブランチサイトが直接通信できない場合のバックアップパスとして使用されます。

ブランチメッシュ

システムIPプール

システムIP(system-ip)は、VPNCまたはBGWとして動作する各ゲートウェイの重要な構成要素です。上記の3つのタイプでは、各ゲートウェイはシステムIPとして1つのVLANインターフェイスを使用します。デフォルトでは、Arubaゲートウェイはこのインターフェイスを使用して、RADIUS、syslog、TACACS+、SNMPなどのネットワークサービスと通信します。各ゲートウェイのシステムIPに対して選択されたVLANインターフェイスには、ゲートウェイが完全に機能するようにIPv4アドレスが割り当てられている必要があります。割り当てられたVLANインターフェイスがアクティブで動作していない限り、ゲートウェイは完全に初期化できません。Centralでは、ゲートウェイがシステムIPとしてDHCPまたはPPPoEを使用してインターネットサービスプロバイダから動的にアドレス指定を取得することはできません。

ゲートウェイプールを使用すると、システムのIPアドレスを専用VLANインターフェイスに自動的に割り当てることができます。このインターフェイスはシステムのIPアドレスとして指定されます。各プールには、開始IPv4アドレスと終了IPv4アドレスに加えて一意の名前が含まれています。各プールに定義されたアドレスの範囲は重複できません。IPアドレスはグループ単位でVLANインターフェイスに設定および適用されるため、Arubaではグループごとに1つのゲートウェイプールを設定することをお勧めします。ゲートウェイプールには、グループに割り当てられたすべてのArubaゲートウェイをサポートするのに十分なIPv4アドレスが含まれている必要があります。グループは複数のゲートウェイプールをサポートできますが、特定のIPアドレスは動的に適用しないでください。

WAN監視

Aruba EdgeConnect SD-Branchソリューションは、ゲートウェイとCentral間のコントロールプレーン通信に依存しており、SD-WAN Orchestratorがトンネルをネゴシエートしてルートを確立できるようにします。ゲートウェイとAruba Centralの間には、少なくとも2つの通信経路が推奨されます。Aruba EdgeConnect SD-Branchは、アップリンクの可用性をアクティブに監視して、接続を確実にします。

このセクションでは、アクティブおよびパッシブ監視とWANポリシーの設計に関する考慮事項について説明します。

アクティブな監視

ゲートウェイはUDPまたはICMPプローブをアクティブに送信して、アンダーレイおよびオーバーレイパスへの接続が使用可能かどうかを判断します。

また、ゲートウェイは、次の3つの操作のいずれかを使用して、WANをアクティブに監視し、アプリケーションに最適なパスを特定します。

  • Default Gateway Monitoring - Arubaゲートウェイは、デフォルトゲートウェイをプローブして、すべてのWAN回線の状態を監視します。デフォルトゲートウェイは、アップリンクと見なされるために、すべてのWANインターフェイスで設定する必要があります。デフォルトゲートウェイはICMPメッセージに応答する必要がないことに注意してください。 WAN正常性チェックのIP/FQDNがプローブに応答する限り、アップリンクは有効と見なされます。

  • **VPNC到達可能性 – **ゲートウェイは、すべてのSD-WANオーバーレイ送信先（すべてのアップリンクを介して）にプローブを送信し、正常性と状態、レイテンシ、ジッター、損失を測定します。プローブは、2秒ごとに5回のバッチで送信されます。パケット損失が検出されると、ゲートウェイはアグレッシブモードに切り替え、2秒ごとに25回のプローブを送信して、パケット損失を正確に計算します。UDPプローブはBGWのデータパスによって管理され、よりタイムリーな応答のために他のトラフィックよりも優先順位を受け取るためにDSCP 48としてマークされます。

  • **WANヘルスチェック – **ゲートウェイは、デフォルトでAruba Cloud Operationsチームが管理するAruba Path Quality Monitor (PQM)にプローブを送信します。PQMサービスは、ICMP/UDPプローブに応答する分散ノードのセットです。 PQMサービスを使用する場合、管理者はPQMをUDPモードに設定して、レイテンシ、ジッタ、およびパケット損失を測定する必要があります（ICMPモードはジッタを測定しません） 。管理者は、カスタムIP/FQDNの場所を入力して、他の正常性チェックの場所を指定できます。 アップリンクを介してヘルスチェックレスポンダに到達できない場合、バックアップアップリンクへのアンダーレイトラフィックが失敗します。オーバレイトラフィックは、関連するVPNC宛てのプローブによって決定されます。

  • SaaS Express Optimization -ブランチゲートウェイは、アプリケーションのFQDNを使用して特定のアプリケーションを解決し、WANアップリンクで構成された（またはISPからDHCPを通じて学習された） DNSサーバに問い合わせて、SaaSアプリケーションに使用する最適なアップリンクを決定します。このプローブは、オーバーレイ通信の動作の良い測定値と、各WAN回線のラストマイルの品質を提供します。この監視がなければ、ゲートウェイはSaaSエクスプレス最適化を提供できません。 SaaSエクスプレス最適化は、ブランチゲートウェイでのみ使用できます。

    ビジネスクリティカルなSaaSアプリケーションでは、ユーザーエクスペリエンスを強化するためのより専用の方法が必要になる場合があります。ISP-SaaSピアリングの問題やDNSの問題など、企業ネットワーク管理者の制御外の問題は、重要なビジネスサービスに悪影響を及ぼす可能性があります。

注:
デフォルトのゲートウェイ監視とVPNC到達可能性のために、アクティブ監視は常にオンになっています。

**Active Monitoring**

受動監視

ゲートウェイは、各アップリンクに関連付けられた物理インターフェイスの帯域幅使用量を受動的に監視する。 使用率は、インターフェイスに設定されているWAN速度と比較され、使用率が計算されます。 ギガビットインターフェイスのトラフィックが600 Mbの場合、回線の使用率は60 %です。 アップリンクの使用率とDPSポリシーは、パスを決定する際に、各インターフェイスのトラフィック量を考慮します。

ゲートウェイは、クライアントからSaaSプロバイダーに送受信されるトラフィックの往復時間とパケット損失について、TCPセッションを監視します。この情報は、各アプリケーションのQuality of Experience(QoE)スコアの計算に使用されます。 Centralダッシュボードには、各アプリケーションの帯域幅の使用状況、QoE、損失、および遅延が表示されます。

**パッシブモニタリング**

WANポリシー

ArubaのSD-Branchには、各ロケーションでWANトランスポートを通過するトラフィックを形成するのに役立ついくつかのWANポリシーがあります。 ポリシーは、次の機能で構成されます。

  • Policy-Based Routing（PBR;ポリシーベースルーティング）: PBRは、ネットワークの宛先がルーティングテーブルに見つからない場合、アプリケーションおよびユーザの役割に基づいて、プライベートまたはパブリックWANアップリンクを介してトラフィックをルーティングします。

  • Quality of Service(QOS):ロールおよびアプリケーションベースの802.1p COSとDSCPマーキングをLAN入力に使用すると、発信WANインターフェイスで4クラスのキューイングモデルを使用してトラフィックをスケジュールできます。完全優先キューはリアルタイムアプリケーションをサポートし、帯域幅の割合を持つDRR (Deficit Round Robin)キューはゲートウェイから離脱するビジネスクリティカルなアプリケーションをサポートします。

  • Dynamic Path Steering(DPS):複数のWANリンクが存在する場合、DPSは、スループット、レイテンシ、ジッタ、パケット損失、アップリンクの使用率などの特性に基づいて、アプリケーションに使用できる最適なパスを選択するのに役立ちます。（ブランチゲートウェイでのみ使用可能）
  • Forward Error Correction(FEC): FECを使用すると、キューオーバーフローや帯域幅リンクの制約など、さまざまなネットワーク層の状況によって発生する可能性があるパケット損失からネットワークを簡単に回復できます。FECはDPSポリシーに適用され、WANで損失が発生した場合に最も必要になります。 （ブランチゲートウェイでのみ利用可能）
  • SaaS Express Optimization:特定のアプリケーションは、GWファイアウォールを通過してレイテンシ、損失、ジッタの測定値を収集するため、Observe SaaSトラフィックに基づいて監視され、利用可能な最適なパスに導くことができます。

ポリシーベースルーティング

ほとんどの展開では、ゲートウェイはルーティングを決定する際にルートテーブルに従います。これは宛先ベースのルーティングと呼ばれます。トラフィックを特定のオーバーレイトンネルまたはインターネットアップリンクに転送する必要がある場合、PBRを使用すると、管理者はアンダーレイトラフィックとオーバーレイトラフィックの両方のルートテーブルを上書きできます。PBRを使用すると、管理者はネクストホップリストに同じ優先順位を設定して複数のパスを使用できます。これはフォールトトレランスに推奨されます。複数のアクティブパスが使用可能な場合、ゲートウェイはDPSとロードバランシングの組み合わせを使用してパスを選択します。PBRの一般的な用途は、すべてのトラフィックを特定のVPNコンセントレータまたはクラウドファイアウォールサービスに強制することです。次の図は、LAN入力でPBRポリシーが定義されている場合のトラフィックパスを示しています。

PBRポリシーが実装される最も一般的な使用法は次のとおりです。

  • 従業員のインターネットトラフィックはすべて、ハブサイトの場所にルーティングして、追加のポリシーチェックを受ける必要があります。

  • クライアントの特定のサブセットからのトラフィックは、特定のWANパスに転送する必要があります。

  • サードパーティのSaaSまたはCheck Point、Palo Alto Networks、Zscalerなどの統合脅威管理プロバイダーとの統合では、クラウドベースのセキュリティプロバイダーを通じて特定のトラフィックを管理する必要があります。

**PBR on LAN Ingress**

クラウドセキュリティ統合

ブランチゲートウェイは、ZscalerやCheckpointなどのクラウドベースのセキュリティプラットフォームを介して、選択したトラフィックをリダイレクトできます。 クラウドセキュリティプロバイダーとSD-WANファブリックの統合は自動的に検出され、トンネルとルートはビジネスとトポロジの要件に基づいて調整されます。

クラウドセキュリティプロバイダーの詳細については、次のガイドを参照してください。 Aruba SD-Branch and Zscaler Internet Access Integration guide.

アルバSD-Branch and Palo Alto Prisma Access Integration guide.

Aruba SD-Branch and Symantec Endpoint Protection Integration Guide

【Aruba SD-Branch Integration with Check Point Intergrationガイド】(https://arubanetworking.hpe.com/techdocs/central/2.5.2/content/gateways/cfg/security/cloud-security/checkpoint-integration.htm)

注:
VPNCは通常、信頼できる送信元からトラフィックを送信するため、クラウドセキュリティ統合はブランチゲートウェイにのみ適用されます。

サービス品質

Quality of Service(QoS)とは、トラフィックの識別、マーキング、および優先順位付けによって、ネットワークがより高いレベルのサービスを提供できることを指します。適切なQoSポリシーを適用することは、ネットワークが輻輳しており、使用可能な帯域幅が制限されている場合に重要です。チーム、ビデオ会議、ビジネスクリティカルなアプリケーションなどのリアルタイムトラフィックには、特定のレイテンシ要件があります。ネットワークが輻輳している場合、アプリケーションはビットレート、スループット、パスの可用性、遅延、ジッタ、損失など、いくつかの方法で影響を受ける可能性があります。 遅延、ジッタ、および損失は、ネットワークデバイスの出力インターフェイス上で正しいQoSポリシーを使用することによって、優先度の高いアプリケーションが優先度の低いアプリケーションよりも先に配信されるように、改善されます。

QoSスケジューリングポリシーを作成する際には、次の2つの主な戦略を検討できます。

– 最初の戦略では、ビジネスにとって重要なアプリケーションを特定し、このセクションで説明するQoSスケジューリングテクニックを使用して、より高いレベルのサービスを提供します。残りのアプリケーションはベストエフォートキューに留まるため、事前設定時間が最小限に抑えられ、より複雑なQoSポリシーのトラブルシューティングに必要な日々の労力が軽減されます。将来、新しいアプリケーションが重要になる場合は、ビジネス・クリティカルなアプリケーションのリストに追加します。QoSレベルの更新は、ネットワーク上のすべてのアプリケーションに対して包括的なポリシー変更を行わなくても、必要に応じて繰り返し実行できます。この戦略は通常、企業全体のQoSポリシーを持たない組織や、WAN経由でアプリケーションのパフォーマンスの問題をトラブルシューティングする組織で使用されます。

  • 2つ目の戦略では、Aruba Deep Packet Inspection(DPI)エンジンを使用してすべてのトラフィックフローとアプリケーションを識別する包括的なQoSポリシーを作成します。 このエンジンは、既知のシグネチャとプロトコルを使用して3K以上のアプリケーションを識別できます。アプリケーションは便宜上、DPIエンジンの定義済みカテゴリに配置されますが、カテゴリが特定の組織のニーズに合わない場合は、カスタムグループを作成する必要があります。この戦略は、既存のQoSポリシーをSDブランチソリューションで使用する組織に最適です。

マーキングとキューイング

QoSポリシーを有効にする最初のステップは、アプリケーションがネットワークデバイスを通過するときにアプリケーションを識別してマーキングすることです。Arubaは、キューイング用にClass of Service（CoS;クラスオブサービス）を使用してアプリケーションにマークを付けることを推奨しています。

マーキングには、Differentiated Service Code Point（DSCP；差別化サービスコードポイント）も使用できます。ただし、DSCP値は常に考慮されるわけではありません。マーキングが遵守されていることを確認するために、サービスプロバイダーに確認してください。

アプリケーションは、アクセス制御リスト(ACL)一致規則を使用してマークする必要があります。一致するACLを作成する場合は、エイリアスとTCP/UDPポートの組み合わせ、またはサービスアプリケーションのリストを使用して、特定のアプリケーションを一致させることをお勧めします。エイリアスとポートの両方を組み合わせることで、管理者はアプリケーションを識別し、より正確にマーキングすることができます。一定レベルの優先順位付けが必要な特定のアプリケーションの場合、管理者はアプリケーションカテゴリ、TCP/UDPポート、サブネットなどの他のACL照合方法を使用できます。

アプリケーションをマークする場合、類似するアプリケーションを分類して同じマークを付けることが重要です。 たとえば、Zoom、GoToMeeting、Teamsはすべてチャット/ビデオ/音声コラボレーションツールであるため、マーキングのために同じカテゴリに配置することは理にかなっています。

ACLを定義した後は、ゲートウェイのLAN側またはユーザロール内の2つの場所にACLを適用できます。ゲートウェイへのトンネリングでは、ACLをユーザロールに適用することが重要です。ユーザロールは通常GREトンネルでカプセル化され、QoSポリシーでは着信パケットを正確にリマークできないためです。

すべてのアプリケーションは、ゲートウェイの入口にマークされます。アプリケーションが識別されない場合、アプリケーションはベストエフォートレベルのサービスでデフォルトキューに配置されます。その場所に残っている東西のトラフィックは、VLAN間のゲートウェイを通過するときに識別され、マークされます。

アプリケーションがマークされた後、優先順位レベルを決定するために、関連するマーキングとともにキューに配置されます。Arubaゲートウェイは、4つのQoSキュー、つまり1つの完全優先キューと3つのDeficit Round Robin（DRR；障害ラウンドロビン）キューをサポートしています。完全優先キューでは、常にすべてのトラフィックが転送されます。優先キューが空になるまで、他のキューが処理されます。DRRは、転送のために各DRRキューに割り当てられる帯域幅の割合を割り当てるスケジューリングアルゴリズムです。 ネットワーク管理者は、割り当てるDRR帯域幅の割合を定義できます。

リアルタイムアプリケーションと、OSPF helloパケットなどのネットワーク管理トラフィックは、常に完全優先キューに配置する必要があります。業務上重要なアプリケーションは、混雑時により高いレベルのサービスを提供するために、1つまたは2つのDRRキューで処理する必要があります。

最後のキューは、すべてのマークされていない低優先順位のマークされたトラフィックが配置されるデフォルトキューとして使用する必要があります。このキューは、より低いレベルのサービスを提供します。

次の図は、マーキングとキューイングの例を示しています。

qos_explanation

動的パスステアリング(DPS)および前方誤り訂正(FEC)

上記のアクティブおよびパッシブのモニタリングの詳細を使用して、DPSはトラフィックに最適なアップリンクをインテリジェントに選択します。DPSは、アプリケーションがSLA(Service Level Agreement)に最も適したパスで送信されることを保証します。たとえば、ゲートウェイにアップリンク1とアップリンク2の2つのパスがあり、クラウドSaaSアプリケーションがDPSポリシーのアクティブな監視基準に一致する場合、DPSは、WANヘルスチェックまたはVPNC到達可能性プローブからの遅延、ジッタ、およびパケット損失の統計を比較することで、現時点で最適なSLAを持つアップリンクを判断します。この例では、SaaSアプリケーションはVPNCサイトでホストされておらず、関連するパスはインターネットであるため、DPSはWANのヘルスチェック情報のみを使用します。DPSポリシーは、各アプリケーションの関連するパス統計情報のみを使用して、トラフィックを送信するアップリンクを決定します。

ネットワーク管理者は、DPSポリシーのSLA、優先度アップリンク、およびFECしきい値を定義できます。管理者は、トラフィックの分類、エイリアス、またはIP/サブネット一致基準に基づいて、アプリケーションのSLAを設定できます。管理者は、組み込みのSLAの1つを使用するか、レイテンシ、ジッタ、パケット損失、アップリンク使用率のパラメータを調整できます。 FEC損失しきい値は、FECが処理できるパケット損失の量に基づいて、アプリケーションのステアリングを遅延させるために使用できます。例えば、通常であれば1%以上のロスでVoIPを操縦しますが、FECを有効にして保護すれば、ロスが5%になるまで操縦を遅らせることができます。

DPSポリシーのSLAを構成する場合、アプリケーションがネガティブなユーザーエクスペリエンスを登録する直前にSLAしきい値を設定することが重要です。

次の図は、WAN出力でDPSポリシーが一致したときのトラフィックパスを示しています。

注:
ゲートウェイのルーティングテーブルまたはPBR規則によってネクストホップが決定され、DPSポリシーによってアップリンクが選択されます。

**DPS on WAN Egress**

DPSポリシーでFECをイネーブルにした後、DPSポリシーに対応するすべてのパケットがFECエンジンに送信され、符号化されます。FECを使用すると、管理者は各ブロック内の”N”個のパケットごとにパリティパケットを追加できます。ここで、”N”は2、4、または8のパケットに相当します。ポリシーごとに送信されるパリティパケットの数は、アプリケーションに必要な回復性の種類によって異なります。

BGWとVPNC間のトラフィックにのみFECパリティパケットが追加されます。トラフィックの宛先がインターネットであるポリシーでFECがイネーブルになっている場合でも、FECパリティエンコーディングは追加されません。VPNCまたはBGWに送信されたパケットは、IPsecトンネルから復号化されるとすぐにFECエンジンに送信されます。

FECエンジンでは、N個のパケットごとに受信パケット数をチェックする。損失がない場合、FECパリティパケットは廃棄されます。パケットが失われたり、エラーが含まれている場合は、FECパリティパケットを使用してパケットが再構築されます。特定のブロックに対して複数のパケットが失われたり誤った場合、FECエンジンはパケットを再構築できません。

注:
遅延を最小限に抑えるために、FECブロック内のパケット間に2ミリ秒の短い待ち時間があります。

WANを通過するすべてのトラフィックが適切なSLAに確実にヒットするようにDPSポリシーを設定し、ユーザーエクスペリエンスを円滑にする必要があります。 SLAは、構成管理を容易にするために、類似するアプリケーションをグループ化できるように設定する必要があります。 次のカテゴリ、FEC比率、およびSLAを推奨します。

アプリケーションの種類FEC 比率DPS SLAパスの優先順位
SaaSアプリケーション
（ローカルのブレイクアウト）		該当なしアプリごとのSLAの推奨事項（SaaS Expressで最適な終了を選択）プライマリ – ALL_INETセカンダリ – LTE*
VoIP1:4
5～8 %の損失		150ミリ秒の遅延
30ミリ秒のジッタ
1%パケット損失		プライマリ – ALL_INETセカンダリ – LTE
その他のリアルタイムビジネスアプリ（テレメトリ）1:8
5-8 %損失		150ミリ秒の遅延
50ミリ秒のジッタ
1%パケット損失
BW使用率: 75%		プライマリ – ALL_INETセカンダリ – LTE
ビジネスアプリケーション無効150ミリ秒の遅延
50ミリ秒のジッタ
2%パケット損失
BW使用率: 75%		プライマリ – ALL_INETセカンダリ – LTE
インターネットアプリケーション
（ローカルのブレイクアウトまたはクラウドセキュリティによる終了）		該当なし2%パケット損失
BW使用率: 75%		プライマリ – ALL_INET

SaaS Express

より多くの企業がSD-Branchを導入して安価なブロードバンドインターネットサービスを利用し、Office 365、Box、Slack、ZendeskなどのSaaS(Software-as-a-Service)アプリケーションを採用するにつれて、運用チームは、ブランチサイトのユーザーがクラウドでホストされるアプリケーションに可能な限り最高のパフォーマンスでシームレスかつ安全に接続できるようにする必要があります。クラウドアプリケーションは複数の地理的な場所でホストされるため、パスが異なるとサービスレベルも異なります。

SaaS Expressは、SaaSアプリケーションをプローブし、最適な接続でパスにステアリングすることで、アプリケーションのパフォーマンスを最適化するように設計されています。アプリケーションのFQDNを使用して利用可能なすべてのパスでプローブを実行し、アップリンクインターフェイスで構成された（またはISPからDHCPを介して学習された） DNSサーバーを15分ごとに照会します。 SaaS Expressでは、アップリンクDNSサーバーに対するプロキシDNS要求の一致基準としてFQDNを使用します。これにより、トラフィックを別のリージョンに転送してパフォーマンスを低下させる可能性のあるローカル以外のDNSサーバーがアプリケーションで使用されないようになります。ゲートウェイは10秒ごとにHTTPプローブをアプリケーションに送信し、その特定のアプリケーションの損失、遅延、ジッタを測定します。トラフィックステアリングは、SaaSアプリケーションが存在する場所によって異なります。 ほとんどのSaaSアプリケーションはローカルに分割されています。アプリケーションがハブサイトでホストされている場合、ゲートウェイはルートテーブルに従います。

ダイナミックパスステアリングとは異なり、SaaS Expressはアップリンクの出口ポイントでの損失、レイテンシ、ジッタを使用して最適なパスを決定します。 SaaS Expressは、アプリケーションのFQDNをプローブすることによって、SaaSアプリケーションの完全なラウンドトリップパフォーマンスの測定を考慮します。監視の違いにより、SaaS ExpressポリシーはDPSポリシーよりも優先されます。管理者は、特別な関心を持つSaaSアプリケーションでSaaS Expressを使用する必要がある場合、またはDPSを使用してアプリケーションのグループのSLAを整理および設定する必要がある場合に使用する必要があります。

注:
完全なトンネルの場合、またはインターネットトラフィックがクラウドセキュリティサービスを介して送信される場合は、オーバーレイでSaaSトラフィックが送信されないように、ルーティングポリシーに例外を導入する必要があります。

SaaSアプリケーションプロファイルパラメーター

ゲートウェイは、DPIライブラリ内のアプリケーションとアプリケーションカテゴリのセットをサポートします。組み込みのアプリケーションプロファイルには、Adobe、Dropbox、Amazon、Google、Salesforce、Slack、Webexなどの一連のSaaSアプリケーションが含まれます。SaaSアプリケーションが一覧にない場合は、ネットワーク管理者が構成できます。

各SaaSアプリケーションプロファイルには、次の要素が含まれます。

  • Name: SaaSアプリケーションの名前

  • FQDN: SaaSアプリケーションにバインドされているドメインURLの一覧

  • Exit profile:トラフィックステアリングポリシーを使用して、最適なパス終了を決定します

  • SLA:パスの品質とパフォーマンスを測定するためのしきい値プロファイル

  • ヘルスチェックプローブURI:使用可能な最適なパスを判断するためにプローブに使用する URI。

注:
SaaS Express機能の詳細については、SaaS Express機能ガイドを参照してください。

image-20220729170513582

負荷分散

ロードバランシングアルゴリズムは、アクティブなWANアップリンク間でセッションを分散する方法を決定します。 このアルゴリズムは、ルートプリファレンスが等しい場合にのみ開始されます。DPSおよびSaaS Expressでは、SLAが同じ場合にのみ負荷分散が有効になります。

ゲートウェイは、次のロードバランシングアルゴリズムをサポートしています。

  • ラウンドロビン:送信トラフィックは、アクティブな各WANアップリンク間で順番に分散されます。これは設定と実装が最も簡単なアルゴリズムですが、時間の経過とともにトラフィックの分散が不均一になる可能性があります。
  • セッション数:送信トラフィックは、各リンクで管理されているセッションの数に基づいて、アクティブなWANアップリンク間で分散されます。このアルゴリズムは、各アクティブWANアップリンクのセッション数が、他のアクティブWANアップリンクの5%以内であることを確認しようとします。
  • アップリンク使用率:トラフィックは、各アップリンクの使用率に基づいて、アクティブなWANアップリンク間で分散されます。アップリンクの使用率は、リンク速度を考慮して特定のリンクの使用率を計算し、最大帯域幅の割合のしきい値を定義できます。帯域幅のしきい値の割合を超えると、そのWANアップリンクは使用できなくなると見なされます。

次の図は、さまざまなロードバランシングアルゴリズムを示しています。

負荷分散アルゴリズム

注:
Arubaは、パス選択時のサービス速度を考慮しているため、アップリンクの使用アルゴリズムをお勧めします。

パスの逆ピン留め

VPNトンネル経由で企業ネットワークに向かうセッションのパスを選択する場合、非対称ルーティングによって発生する接続の問題を防ぐために、逆方向トラフィックは同じWANパスを使用する必要があります。リバースパスピニングを使用すると、ヘッドエンドゲートウェイはブランチとの間でアクティブなセッションごとに同じWANパスを選択できます。ブランチゲートウェイはパフォーマンスとSLAに基づいてパスを選択するため、これは重要です。リバース・パス・ピンは、データ・センターに向かうブランチから発生する企業セッションと、データ・センターからブランチに向かうセッションに対して実行されます。

トラフィックがデータセンターから発信される場合、ヘッドエンドゲートウェイは等コストのマルチパスアルゴリズムに基づいてパスを選択します。ブランチからトラフィックが戻るとすぐに、BGWはDPSポリシーに基づいて、5つのタプルセッションを正しいパスに誘導します。ヘッドエンドゲートウェイがリターントラフィックを認識すると、セッションが更新され、フローの期間中は選択されたパスが使用されます。

  • ヘッドエンドゲートウェイは、等コストのマルチパスルーティングを使用して、使用可能なWANパスを選択します。

  • WANパスがBGWのDPSポリシーで定義されている優先パスと一致する場合は、追加のステアリングは必要ありません。

  • WANパスがDPSポリシーで定義された優先パスと一致しない場合、ブランチゲートウェイは優先パスを介してリターンセッションを送信します。新しいパスからトラフィックを受信した後、VPNCはシンメトリを維持するために優先パスにアウトバウンドセッションを誘導します。

次の図は、プライベートWANオーバーレイトンネル上のブランチロケーションからのトラフィックと、シンメトリを強制するために同じパス上のトラフィックを返すVPNCのリバースパスピニング機能を示しています。

**Reverse-Path Pinning**