PBR を使用した vzAny の概要
次のセクションでは、マルチサイト e ドメインでポリシーベース リダイレクト（PBR）を使用して vzAny コントラクトを有効にするための概要、要件とガイドライン、および構成手順について説明します。一般的な vzAny の概要と、PBR を含まない基本的な vzAny のユース ケースについては、「vzAny コントラクト」の章を参照してください。
使用例
リリース 4.2(1) より前は、次の基本的な vzAny のユース ケース（PBR なし）がマルチサイトでサポートされていました。これらはすべて、「vzAny コントラクト」の章で説明されています。
-
同じ VRF 内の EPG 間の自由な通信。
-
多対 1 通信により、同じ VRF 内のすべての EPG が単一の EPG から共有サービスを利用できるようになります。
NDO リリース 4.2(1) 以降、PBR を使用した vzAny の次の追加のユース ケースは、APIC リリース 6.0(3) 以降を実行している ACI ファブリックでサポートされます。これにより、ワンアーム モードの各サイトに接続された論理ファイアウォール サービスにトラフィックをリダイレクトできます。
-
同じ VRF 内の 2 つの EPG 間の VRF 内通信（vzAny から vzAny）。
-
VRF（vzAny）内のすべての EPG と、同じ VRF の一部である特定の EPG 間の多数対 1 の通信。
-
VRF（vzAny）内のすべての EPG と、同じ VRF の一部である特定の外部 EPG 間の多数対 1 の通信。
PBR を使用して vzAny を構成するための一般的なワークフロー
次のセクションでは、PBR を使用するすべての vzAny のユース ケースに必要な個々の構成要素（テンプレート、EPG、コントラクトなど）を作成および構成する方法について説明し、その後に、個々のビルディング ブロックを、構成する特定のユース ケースに合わせて使用します。
PBR のユース ケースで vzAny のいずれかを構成する場合は、リリース 4.2(1) で導入され、サービス グラフ構成の定義に使用される新しいサービス デバイス テンプレートを含む次のワークフローを実行します。
-
サービス デバイス テンプレートを作成し、設定が必要な特定のテナントとすべてのサイトに関連付けます。これには次のものが含まれます。
-
（オプション）IP SLA ポリシーの参照。
IP SLA ポリシーは、同じテナントに関連付けられたテナント ポリシー テンプレートですでに定義されている必要があります。
-
サービス デバイス テンプレートで 1 つ以上のサービス ノード デバイスの作成。
サービス デバイス構成を作成する場合は、いずれかのアプリケーション テンプレートにすでに存在している必要があるブリッジ ドメインを指定する必要があります。正確な BD 要件は、次の PBR 注意事項および制限事項を持つ vzAny セクションに記載されています。
-
サービス デバイス テンプレートで定義されたサービス ノード デバイスのサイトレベル構成を提供し、展開します。
（注）
リリース 4.2(1) およびサービス デバイス テンプレートの導入以降、PBR のユース ケースについて Nexus Dashboard Orchestrator で明示的に作成する必要があるサービス グラフ オブジェクトはありません。NDO は暗黙的にサービス グラフを作成し、サイトの APIC に展開します。
-
-
作成したサービス デバイス テンプレートに関連付けられた特定のテナントの設定を完了します。これには、次のものが含まれます。
-
テナント アプリケーション テンプレートを作成し、構成が必要なすべてのサイトへの割り当て。
-
PBR とコントラクトを有効にするために必要な vzAny VRF 設定の構成。
-
コンシューマおよびプロバイダ EPG の構成。
サービス BD はサイト間で拡張する必要がありますが、EPG に使用する BD は拡張またはサイトローカルにすることができます。
-
-
手順 1 で作成したサービスデバイスを、ステップ 2 で作成した vzAny 契約に関連付けます。
トラフィック フロー：Intra-VRF vzAny-to-vzAny
このセクションでは、異なるサイトの特定の VRF の論理 vzAny 構造の一部である 2 つの EPG 間のトラフィック フローを要約します。このユース ケースでは、vzAny は PBR コントラクトのプロバイダとコンシューマの両方です。
（注） |
この場合、2 つのサイトに展開された独立した FW ノードによる非対称トラフィック フローを回避するために、両方向のトラフィック フローは両方のファイアウォールを介してリダイレクトされます。 |
Consumer-to-Provider への初期トラフィック フローと会話型学習
ローカル サイトとリモート サイトの両方の FW サービス ノードにトラフィックをリダイレクトするための設計原則は、トラフィック フローの両方向の入力リーフ スイッチに常に PBR ポリシーを適用することです。これを行うには、入力リーフ スイッチが宛先のエンドポイント ポリシー情報（クラス ID）を認識している必要があります。次の図は、通信がコンシューマ エンドポイントから開始され、入力（コンシューマ）リーフ スイッチに宛先（プロバイダ）エンドポイントのクラス ID 情報がまだない例を示しています。そのため、トラフィックはリモート サイトに接続されている宛先に転送されるだけです。このリリースでは、このユースケースをサポートする新しいロジックが実装されているため、トラフィックを受信するプロバイダ リーフ スイッチは、フローがサイト 1 で発生したが、そのサイトに接続されたファイアウォール サービス ノードを介して送信されていないことを理解できます。その結果、コンシューマ エンドポイント情報（クラス ID）を学習した後、サイト 2 のプロバイダー リーフはサイト 1 のファイアウォールに向けてトラフィックをバウンスバックします。
サイト 1 のファイアウォールはセキュリティ ポリシーを適用し、トラフィックはサイト 2 の宛先リーフ スイッチに再度転送されます。このリーフは、トラフィックがまだサイト 1 から送信されている間に、そのサイトに展開されたファイアウォールを介して送信されたことを認識できるようになりました。その結果、宛先リーフ スイッチはパケットを検査のためにローカル ファイアウォール デバイスに転送し、その後、次の図に示すように宛先エンドポイントに配信されます。
会話型学習上記のようにトラフィックの準最適なバウンスを回避するために、プロバイダ リーフ スイッチは特別な制御パケットを生成し、サイト 1 のコンシューマ リーフ スイッチに送信します。これにより、コンシューマ リーフはプロバイダ エンドポイントのクラス ID 情報を学習できます。
（注） |
最初のフローが provider-to-consumer への方向で確立される場合、consumer-to-provider へのトラフィック方向について前述したのと同じ動作が適用されます。 |
Consumer-to-Provider へのトラフィック フロー（定常状態）
コンシューマ リーフ スイッチは、前述の会話型学習ステージからプロバイダ エンドポイント情報を学習した後、ポリシーを適用し、以降のすべてのトラフィックに対してトラフィックをローカル ファイアウォールにリダイレクトできます。
Provider-to-Consumer トラフィック フロー（安定状態）
プロバイダ リーフ スイッチは、会話型学習 に示されているダイレクト パケットから、または会話型学習に基づいてコンシューマ エンドポイント情報を学習した後、ポリシーを適用し以降のすべてのトラフィックに対してトラフィックをローカル ファイアウォールにリダイレクトできます。
トラフィック フロー：Intra-VRF vzAny-to-EPG
このセクションでは、特定の VRF の論理 vzAny 構造の一部であるコンシューマ EPG と同じ VRF の一部であるプロバイダ EPG 間のトラフィック フローを要約します。このユース ケースでは、vzAny は PBR コントラクトのコンシューマですが、特定の EPG はプロバイダです。
（注） |
トラフィックが常に両方のサイトのファイアウォール デバイスを通過する vzAny-to-vzAny および vzAny-to-L3Out のユース ケースとは異なり、vzAny-to-EPG は常にプロバイダのサイトのデバイスのみを使用します。 |
コンシューマからプロバイダへのトラフィック フロー
vzAny-to-EPG の使用例では、ポリシーはトラフィックの方向に関係なく、プロバイダ リーフ スイッチにのみ適用されます。したがって、コンシューマからプロバイダへのトラフィックの場合、コンシューマ EPG はプロバイダ EPG のリーフ スイッチにトラフィックを直接送信します。
Provider-to-Consumer トラフィック フロー（内部トラフィックおよび会話型学習）
プロバイダ リーフ スイッチがコンシューマ エンドポイント情報（クラス ID）を学習できる前に、プロバイダ エンドポイントによって通信が開始された場合、トラフィックをローカル ファイアウォールにリダイレクトするポリシーを適用できないため、トラフィックはサイト間でコンシューマ リーフ スイッチに送信されます。ポリシーが適用されなかったため（パケット内の制御ビットによって示される）、コンシューマ リーフ スイッチはインスペクションのためにトラフィックをプロバイダ サイトのファイアウォールにリダイレクトし、最終的にトラフィックをコンシューマ エンドポイントにバウンスします。
この準最適トラフィック フローは無期限に継続できますが、コンシューマ EPG のリーフ スイッチは、今後のトラフィックを最適化し、両方のサイト間でバウンスしないようにするために、コンシューマ エンドポイント情報を含む別の制御パケットをプロバイダ リーフ スイッチにも送信します。
Provider-to-Consumer トラフィック フロー（安定状態）
プロバイダ リーフ スイッチは、vzAny-to-EPG のコンシューマからプロバイダへのトラフィック フロー に示すコンシューマ エンドポイントから発信された直接パケットから、または会話型学習に基づいてコンシューマ エンドポイント情報を学習した後、ポリシーを適用し、今後のすべてのトラフィックに対してトラフィックをローカル ファイアウォールにリダイレクトできます。
トラフィック フロー：Intra-VRF vzAny-to-External-EPG（L3Out）
このセクションでは、特定の VRF の論理 vzAny 構造の一部である EPG と、別のサイトの同じ VRF の一部である外部 EPG（L3Out）間のトラフィック フローを要約します。このユース ケースでは、vzAny は vzAny コントラクトのコンシューマであり、L3Out に関連付けられた外部 EPG はプロバイダです。
（注） |
このユース ケースでは、トラフィックは常に両方のサイトのファイアウォール デバイスを介してリダイレクトされます。 |
Consumer-to-Provider へのトラフィック フロー
入力リーフ スイッチは、宛先外部 EPG のクラス ID を常に解決でき、トラフィックをローカル FW にリダイレクトする PBR ポリシーを適用するため、この方向のトラフィックには会話型学習は必要ありません。トラフィックはサイト 1 のファイアウォール ノードを通過した後にプロバイダ リーフ スイッチによって受信されるため、プロバイダ リーフ スイッチがこのデータプレーン通信からコンシューマ エンドポイント情報（クラス ID）を学習することはできません。
Provider-to-Consumer トラフィック フロー（内部トラフィックおよび会話型学習）
プロバイダ リーフ スイッチがコンシューマ エンドポイント情報を学習する前に、トラフィックをローカル ファイアウォールにリダイレクトするポリシーを適用できないため、トラフィックはサイト間でコンシューマ リーフ スイッチに送信されます。ポリシーが適用されなかったため（パケット内の制御ビットによって示される）、コンシューマ リーフ スイッチはトラフィックをインスペクションのためにプロバイダ サイトのファイアウォールにリダイレクトし、最終的にトラフィックをコンシューマ エンドポイントに転送します。
このトラフィック フローは無期限に継続できますが、コンシューマ リーフ スイッチは、将来のトラフィックを最適化し、両方のサイト間でバウンスしないようにするために、コンシューマ エンドポイント情報を含む別の制御パケットをプロバイダ リーフ スイッチにも送信します。
Provider-to-Consumer トラフィック フロー（安定状態）
プロバイダ リーフ スイッチは、コンシューマ エンドポイント情報を学習した後、PBR ポリシーを適用して、最初にローカル ファイアウォール デバイスにトラフィックをリダイレクトします。次に、サイト間でトラフィックをコンシューマ リーフ スイッチに送信します。最後にコンシューマ エンドポイントに送信されます。
フィードバック