内容

概要

背景説明

ポリシーベースのリダイレクトの概要

サービスグラフ導入のトラブルシューティング

1.設定手順と障害の確認

2. UIのサービスグラフ配置を確認します

PBR転送のトラブルシューティング

1. VLANが展開され、エンドポイントがリーフノードで学習されることを確認します

2.予想されるトラフィックパスを確認する

ポリシーはどこに適用されますか。

3.トラフィックがサービスノードにリダイレクトされるかどうかを確認します

4.リーフノードにプログラムされているポリシーを確認します

その他のトラフィックフローの例

1. SNATのないロードバランサ

トラフィックパスの例

リーフノードにプログラムされたポリシー。

2.トラフィックフローの例：SNATのないファイアウォールとロードバランサ

トラフィックパスの例

リーフノードにプログラムされたポリシー

3.共有サービス（VRF間契約）

リーフノードにプログラムされたポリシー

概要

このドキュメントでは、ACIポリシーベースリダイレクト(PBR)のシナリオを理解し、トラブルシューティングする手順について説明します。

背景説明

このドキュメントの内容は、『Troubleshooting Cisco Application Centric Infrastructure, Second Edition』に記載されているポリシーベースのリダイレクト – 概要、ポリシーベースのリダイレクト – サービスグラフの導入、ポリシーベースのリダイレクト – 転送およびポリシーベースのリダイレクト – その他のトラフィックフローの例の章から抜粋したものです。

ポリシーベースのリダイレクトの概要

この章では、ポリシーベースのリダイレクト(PBR)を使用したアンマネージドモードのサービスグラフのトラブルシューティングについて説明します。

次に、一般的なトラブルシューティング手順を示します。この章では、PBRに固有のステップ2と3を確認する方法について説明します。ステップ1と4については、次の章を参照してください。「Intra-Fabric forwarding」、「External forwarding」、および「Security policies」

1. PBRサービスグラフを使用せずにトラフィックが動作していることを確認します。

- コンシューマとプロバイダーのエンドポイントが学習されます。

- コンシューマとプロバイダーのエンドポイントが通信できます。

2. サービスグラフが展開されていることを確認します。

- 配置されたグラフインスタンスにエラーはありません。

- サービスノードのVLANとクラスIDが導入されます。

- サービスノードエンドポイントが学習されます。

3. 転送パスを確認します。

- リーフノードにチェックポリシーがプログラムされています。

- サービスノード上のトラフィックをキャプチャして、トラフィックがリダイレクトされるかどうかを確認します。

- ACIリーフ上のトラフィックをキャプチャして、PBRの後にトラフィックがACIファブリックに戻るかどうかを確認します。

4. トラフィックがコンシューマおよびプロバイダーのエンドポイントに到達し、エンドポイントがリターントラフィックを生成することを確認します。

このドキュメントでは、設計または設定オプションについては説明しません。詳細については、Cisco.comの「ACI PBR White Paper」を参照してください。

この章では、サービスノードとサービスリーフは次のことを意味します。

- サービスノード：PBRがトラフィックをリダイレクトする外部ノード（ファイアウォールやロードバランサなど）。

- サービスリーフ：サービスノードに接続されているACIリーフ。

サービスグラフ導入のトラブルシューティング

この章では、サービスグラフが導入されていない場合のトラブルシューティング例について説明します。

サービスグラフポリシーを定義して契約の対象に適用した後、ACI GUIに展開済みのグラフインスタンスが表示されます。次の図は、サービスグラフが導入済みとして表示されないトラブルシューティングシナリオを示しています。

サービスグラフは展開済みグラフインスタンスとして表示されません。

1.設定手順と障害の確認

トラブルシューティングの最初のステップは、必要なコンポーネントが何の障害もなく設定されていることを確認することです。次の一般的な設定がすでに行われていることを前提としています。

- コンシューマEPG、プロバイダーEPG、およびサービスノード用のVRFおよびBD

- コンシューマおよびプロバイダーEPG。

- コントラクトとフィルタ。

サービスノードのEPGは手動で作成する必要がないことに注意してください。サービスグラフの導入によって作成されます。

PBRを使用したサービスグラフの設定手順は次のとおりです。

- L4-L7デバイス（論理デバイス）を作成します。

- サービスグラフを作成します。

- PBRポリシーを作成します。

- デバイス選択ポリシーを作成します。

- サービスグラフを契約の件名に関連付けます。

2. UIのサービスグラフ配置を確認します

サービスグラフを契約の件名に関連付けると、展開されたグラフインスタンスがサービスグラフを使用して各契約に表示されます（下図）。

場所は、[Tenant] > [Services] > [L4-L7] > [Deployed Graph Instances]です。

配置済みグラフインスタンス

導入済みグラフインスタンスが表示されない場合は、コントラクト設定に問題があります。主な理由は次のとおりです。

- 契約にコンシューマまたはプロバイダーのEPGがありません。

- コントラクト対象にフィルターがありません。

- 契約範囲はVRFですが、VRF間またはテナント間のEPG通信用です。

サービスグラフのインスタンス化が失敗すると、展開済みグラフインスタンスでエラーが発生します。これは、サービスグラフの設定に問題があることを意味します。設定によって発生する一般的な障害は次のとおりです。

F1690:ID割り当ての失敗により、構成が無効です

このエラーは、サービスノードのカプセル化されたVLANが使用できないことを示します。たとえば、論理デバイスで使用されるVMMドメインに関連付けられたVLANプールには、使用可能なダイナミックVLANがありません。

解決策：論理デバイスに使用されるドメイン内のVLANプールをチェックします。物理ドメイン内にある場合は、論理デバイスインターフェイスでカプセル化されたVLANを確認します。場所は、[Tenant] > [Services] > [L4-L7] > [Devices and Fabric] > [Access Policies] > [Pools] > [VLAN]です。

F1690:LDevのデバイスコンテキストが見つからないため、構成が無効です

このエラーは、論理デバイスがサービスグラフのレンダリングに見つからないことを示します。たとえば、サービスグラフの契約に一致するデバイス選択ポリシーはありません。

解決策：[Device Selection Policy]が定義されていることを確認します。デバイス選択ポリシーは、サービスデバイスとそのコネクタの選択基準を提供します。基準は、契約名、サービスグラフ名、およびサービスグラフ内のノード名に基づきます。場所は、[Tenant] > [Services] > [L4-L7] > [Device Selection Policy]です。

デバイス選択ポリシーの確認

F1690:クラスタインターフェイスが見つからないため、構成が無効です

このエラーは、サービスノードのクラスタインターフェイスが見つからないことを示します。たとえば、クラスタインターフェイスは[Device Selection Policy]で指定されていません。

解決策：クラスタインターフェイスがデバイス選択ポリシーで指定されており、コネクタ名が正しいことを確認します（次の図）。

F1690:BDが見つからないため、構成が無効です

このエラーは、サービスノードのBDが見つからないことを示します。たとえば、BDは[Device Selection Policy]では指定されません。

解決策：デバイス選択ポリシーでBDが指定され、コネクタ名が正しいことを確認します（次の図）。

F1690:サービスリダイレクトポリシーが無効なため、構成が無効です

このエラーは、サービスグラフのサービス機能でリダイレクトが有効になっているにもかかわらず、PBRポリシーが選択されていないことを示します。

解決策：[Device Selection Policy]で[PBR policy]を選択します（下図）。

デバイス選択ポリシーの論理インターフェイス設定

PBR転送のトラブルシューティング

この章では、PBR転送パスのトラブルシューティング手順について説明します。

1. VLANが展開され、エンドポイントがリーフノードで学習されることを確認します

サービスグラフが問題なく正常に展開されると、サービスノードのEPGとBDが作成されます。次の図は、サービスノードインターフェイス（サービスEPG）のカプセル化されたVLAN IDとクラスIDの場所を示しています。 この例では、ファイアウォールのコンシューマ側はVLANカプセル化1000を使用したクラスID 16386で、ファイアウォールのプロバイダー側はVLANカプセル化1102を使用したクラスID 49157です。

場所は、[Tenant] > [Services] > [L4-L7] > [Deployed Graph instances] > [Function Nodes]です。

サービスノード

サービスノードインターフェイスクラスID

これらのVLANは、サービスノードが接続されているサービスリーフノードインターフェイスに導入されます。VLANの導入とエンドポイントのラーニングステータスは、サービスリーフノードCLIで「show vlan extended」および「show endpoint」を使用して確認できます。

Pod1-Leaf1# show endpoint vrf Prod:VRF1

Legend:

s - arp              H - vtep             V - vpc-attached     p - peer-aged

R - peer-attached-rl B - bounce           S - static           M - span

D - bounce-to-proxy  O - peer-attached    a - local-aged       m - svc-mgr

L - local            E - shared-service

+-----------------------------------+---------------+-----------------+--------------+-------------+

VLAN/                           Encap           MAC Address       MAC Info/       Interface

Domain                          VLAN            IP Address        IP Info

+-----------------------------------+---------------+-----------------+--------------+-------------+

53                                        vlan-1000    0050.56af.3c60 LV                        po1

Prod:VRF1                                 vlan-1000   192.168.101.100 LV                        po1

59                                        vlan-1102    0050.56af.1c44 LV                        po1

Prod:VRF1                                 vlan-1102   192.168.102.100 LV                        po1

サービスノードのエンドポイントIPがACIファブリックのエンドポイントとして学習されない場合、サービスリーフとサービスノード間の接続または設定の問題である可能性が高くなります。次のステータスを確認してください。

- サービスノードは、正しいリーフダウンリンクポートに接続されます。

- サービスノードが物理ドメイン内にある場合、リーフスタティックパスエンドカプセル化VLANを論理デバイスで定義する必要があります。

- サービスノードがVMMドメイン内にある場合は、VMMドメインが機能していること、およびサービスグラフで作成されたポートグループがサービスノードVMに正しくアタッチされていることを確認してください。

- サービスノードVMが存在するサービスノードまたはハイパーバイザに接続されているリーフダウンリンクポートはUPです。

- サービスノードに正しいVLANとIPアドレスがある。

- サービスリーフとサービスノード間の中間スイッチのVLAN設定が正しい。

2.予想されるトラフィックパスを確認する

PBRを有効にすると、サービスノードのエンドポイントがACIファブリックで学習されても、エンドツーエンドのトラフィックが機能しなくなった場合、次のトラブルシューティング手順は、予想されるトラフィックパスを確認することです。

図「PBR転送パスの例 – コンシューマからプロバイダー」および「PBR転送パスの例 – プロバイダからコンシューマ」は、コンシューマのエンドポイントとプロバイダーのエンドポイント間でPBRを使用してファイアウォールを挿入した転送パスの例を示しています。この場合、エンドポイントはすでにリーフノードで学習されていると仮定します。

PBR転送パスの例：コンシューマからプロバイダー

注:ソースMACはACIリーフMACに変更されないため、コンシューマエンドポイントとPBRノードが同じBD内にない場合、PBRノードはソースMACベースのフォワーディングを使用できません

PBR転送パスの例：プロバイダーからコンシューマ

注：PBRポリシーはコンシューマリーフまたはプロバイダーリーフのいずれかに適用され、図「PBR転送パスの例 – コンシューマからプロバイダー」および「PBR転送パスの例 – プロバイダーからコンシューマ」に示すようにACI PBRが行うのは宛先MAC書き換えであることに注目してください。 PBR宛先MACに到達するには、送信元エンドポイントとPBR宛先MACが同じリーフの下にある場合でも、常にスパインプロキシを使用します。

「PBR転送パスの例 – コンシューマからプロバイダー」および「PBR転送パスの例 – プロバイダーからコンシューマ」の図は、トラフィックがリダイレクトされる場所の例を示していますが、ポリシーが適用される場所は、コントラクトの設定とエンドポイントのラーニングステータスによって異なります。「ポリシーが適用される場所」の表は、単一のACIサイトでポリシーが適用される場所をまとめたものです。マルチサイトでポリシーが適用される場所は異なります。

ポリシーはどこに適用されますか。

シナリオ

VRF強制モード

消費者

プロバイダー

ポリシーの適用

VRF内

入力/出力

EPG

EPG

・ 宛先エンドポイントが学習された場合：入力リーフ*

・ 宛先エンドポイントが学習されない場合：出力リーフ

入力

EPG

L3Out EPG

コンシューマリーフ（非ボーダーリーフ）

入力

L3Out EPG

EPG

プロバイダーリーフ（非ボーダーリーフ）

出力

EPG

L3Out EPG

Border leaf ->非Border Leafトラフィック

・ 宛先エンドポイントが学習された場合：境界葉

・ 宛先エンドポイントが学習されない場合：非境葉

非ボーダーリーフ – >ボーダーリーフトラフィック

・ 境界リーフ

出力

L3Out EPG

EPG

入力/出力

L3Out EPG

L3Out EPG

入力リーフ*

VRF間

入力/出力

EPG

EPG

コンシューマリーフ

入力/出力

EPG

L3Out EPG

コンシューマリーフ（非ボーダーリーフ）

入力/出力

L3Out EPG

EPG

入力リーフ*

入力/出力

L3Out EPG

L3Out EPG

入力リーフ*

*ポリシーの適用は、パケットによってヒットされた最初のリーフに適用されます。

次に例を示します。

- VRF1のL3Out EPGの外部エンドポイントがVRF1のWeb EPGのエンドポイントにアクセスを試み、VRF1が入力強制モードに設定されている場合、トラフィックはコントラクトの方向に関係なく、Web EPGのエンドポイントが存在するリーフによってリダイレクトされます。

- VRF1のコンシューマWeb EPGのエンドポイントがVRF1のプロバイダーアプリケーションEPGのエンドポイントにアクセスを試み、エンドポイントがコンシューマおよびプロバイダーリーフノードで学習された場合、トラフィックは入力リーフによってリダイレクトされます。

- VRF1のコンシューマWeb EPGのエンドポイントがVRF2のプロバイダーアプリケーションEPGのエンドポイントにアクセスしようとすると、VRF強制モードに関係なく、コンシューマエンドポイントが存在するコンシューマリーフによってトラフィックがリダイレクトされます。

3.トラフィックがサービスノードにリダイレクトされるかどうかを確認します

予想される転送パスがクリアされたら、ELAMを使用してトラフィックがスイッチノードに到達したかどうかをチェックし、スイッチノードでの転送の決定をチェックできます。ELAMの使用方法については、「Intra-Fabric Forwarding」の章の「ツール」の項を参照してください。

たとえば、「PBR転送パスの例：コンシューマからプロバイダー」の図のトラフィックフローをトレースするには、これらをキャプチャして、コンシューマからプロバイダーへのトラフィックがリダイレクトされるかどうかを確認します。

- コンシューマリーフ上のダウンリンクポートをチェック1および2（トラフィックはコンシューマリーフに到達し、PBRが適用される）。

- スパインノード上のファブリックポートをチェック3（トラフィックはスパインプロキシに送られる）。

- サービスリーフ上のファブリックポートをチェック4（トラフィックがサービスリーフに到達する）

次に、これらをキャプチャして、サービスノードから戻ってくるトラフィックがプロバイダーに向かうかどうかを確認できます。

- サービスリーフ上のダウンリンクポートをチェック5および6（トラフィックはサービスノードから戻され、許可される）。

- スパインノード上のファブリックポートをチェック7（トラフィックはスパイン経由でプロバイダーリーフに送られる）。

- チェックするプロバイダーリーフのファブリックポート8（トラフィックはサービスリーフに到達し、プロバイダーエンドポイントに向かう）。

注：コンシューマとサービスノードが同じリーフの下にある場合は、送信元/宛先IPに加えてインターフェイスまたは送信元MACを指定し、ELAMを使用して「PBR転送パスの例：コンシューマからプロバイダー」の図の1または5を確認します。これは、両方が同じ送信元IPと宛先IPを使用するためです。

コンシューマからプロバイダーへのトラフィックがサービスノードにリダイレクトされても、サービスリーフに戻ってこない場合は、次の点を確認してください。これらは一般的な間違いです。

- サービスノードのルーティングテーブルはプロバイダーサブネットに到達します。

- ACLなどのサービスノードセキュリティポリシーによってトラフィックが許可されます。

トラフィックがリダイレクトされてプロバイダーに到達する場合は、同様の方法でプロバイダーからコンシューマへのリターントラフィックパスを確認してください。

4.リーフノードにプログラムされているポリシーを確認します

トラフィックが適切に転送またはリダイレクトされない場合、次のトラブルシューティング手順は、リーフノードにプログラムされているポリシーを確認することです。このセクションでは、例としてzoning-ruleとcontract_parserを示します。ゾーン分割ルールの確認方法の詳細については、「セキュリティポリシー」の章の「ツール」の項を参照してください。

注：ポリシーは、リーフ上のEPG導入ステータスに基づいてプログラムされます。このセクションのshowコマンド出力では、サービスノードのコンシューマEPG、プロバイダーEPG、およびEPGを持つリーフを使用します。

「show zoning-rule」コマンドの使用

次の図と「show zoning-rule」の出力は、サービスグラフを展開する前のゾーン分割ルールを示しています。

VRFスコープIDは、[Tenant] > [Networking] > [VRF]にあります。

Pod1-Leaf1# show zoning-rule scope 2752513

+---------+--------+--------+----------+----------------+---------+---------+------------+----------+----------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  |    Name    |  Action  |       Priority       |

+---------+--------+--------+----------+----------------+---------+---------+------------+----------+----------------------+

|   4237  | 32772  | 32773  |    8     |     bi-dir     | enabled | 2752513 | web-to-app |  permit  |    fully_qual(7)     |

|   4172  | 32773  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 | web-to-app |  permit  |    fully_qual(7)     |

+---------+--------+--------+----------+----------------+---------+---------+------------+----------+----------------------+

サービスグラフが展開されると、サービスノードのEPGが作成され、ポリシーが更新されてコンシューマEPGとプロバイダーEPG間のトラフィックがリダイレクトされます。次の図と「show zoning-rule」の出力は、サービスグラフの導入後のゾーン分割ルールを示しています。この例では、pcTag 32772(Web)からpcTag 32773(App)へのトラフィックは「destgrp-27」（サービスノードのコンシューマ側）にリダイレクトされ、pcTag 32773(App)からpcTag 32772(Web)へのトラフィックは「destgrp-28」（サービスノードのプロバイダ側）にリダイレクトされます。

サービスグラフ導入後のゾーン分割ルール

Pod1-Leaf1# show zoning-rule scope 2752513

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

...

|   4213  | 16386  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |

|   4249  | 49157  | 32773  | default  |    uni-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

|   4237  | 32772  | 32773  |    8     |     bi-dir     | enabled | 2752513 |      | redir(destgrp-27) |    fully_qual(7)     |

|   4172  | 32773  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      | redir(destgrp-28) |    fully_qual(7)     |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

各destgrpの宛先情報は、「show service redir info」コマンドを使用して確認できます。

Pod1-Leaf1# show service redir info

============================================================================================

LEGEND

TL: Threshold(Low)  |  TH: Threshold(High) |  HP: HashProfile  |  HG: HealthGrp  | BAC: Backup-Dest |  TRA: Tracking  | RES: Resiliency

============================================================================================

List of Dest Groups

GrpID Name            destination                                 HG-name           BAC  operSt     operStQual      TL   TH   HP   TRAC RES

===== ====            ===========                                 ==============    ===  =======    ============    ===  ===  ===  ===  ===

28    destgrp-28      dest-[192.168.102.100]-[vxlan-2752513]      Not attached      N    enabled    no-oper-grp     0    0    sym  no   no

27    destgrp-27      dest-[192.168.101.100]-[vxlan-2752513]      Not attached      N    enabled    no-oper-grp     0    0    sym  no   no

List of destinations

Name                                          bdVnid             vMac                    vrf         operSt     operStQual      HG-name

====                                          ======             ====                    ====        =====      =========       =======

dest-[192.168.102.100]-[vxlan-2752513]        vxlan-16023499     00:50:56:AF:1C:44       Prod:VRF1   enabled    no-oper-dest    Not attached

dest-[192.168.101.100]-[vxlan-2752513]        vxlan-16121792     00:50:56:AF:3C:60       Prod:VRF1   enabled    no-oper-dest    Not attached

...

ゾーン分割ルールが適切にプログラムされているが、トラフィックが適切にリダイレクトまたは転送されない場合は、次の点を確認してください。これらは一般的な間違いです。

- ELAMを使用して、送信元クラスIDまたは宛先クラスIDが期待どおりに解決されているかどうかを確認します。そうでない場合は、間違ったクラスIDと、パスやカプセル化VLANなどのEPG導出基準を確認してください。

- 送信元と宛先のクラスIDが適切に解決され、PBRポリシーが適用されてもトラフィックがPBRノードに到達しない場合でも、redirアクション(「show service redir info」)で宛先のIP、MAC、およびVRFが正しいことを確認してください。

デフォルトでは、PBRが有効になっている場合、サービスノード（コンシューマ側）に対するコンシューマEPGの許可ルールと、サービスノード（プロバイダー側）に対するプロバイダーEPGの許可ルールはプログラムされません。したがって、コンシューマまたはプロバイダーのエンドポイントは、デフォルトではサービスノードと直接通信できません。このトラフィックを許可するには、Direct Connectオプションを有効にする必要があります。使用例については、「その他のトラフィックフローの例」の項で説明します。

contract_parserの使用

contract_parserツールは、ポリシーの確認にも役立ちます。C-consumerはサービスノードのコンシューマ側で、C-providerはサービスノードのプロバイダー側です。

Pod1-Leaf1# contract_parser.py --vrf Prod:VRF1

Key:

[prio:RuleId] [vrf:{str}] action protocol src-epg [src-l4] dst-epg [dst-l4] [flags][contract:{str}] [hit=count]

[7:4213] [vrf:Prod:VRF1] permit ip tcp tn-Prod/G-Prod-ASAv-VM1ctxVRF1/C-consumer(16386) eq 80 tn-Prod/ap-app1/epg-Web(32772)  [contract:uni/tn-Prod/brc-web-to-app] [hit=0]

[7:4237] [vrf:Prod:VRF1] redir ip tcp tn-Prod/ap-app1/epg-Web(32772) tn-Prod/ap-app1/epg-App(32773) eq 80  [contract:uni/tn-Prod/brc-web-to-app] [hit=0]

destgrp-27 vrf:Prod:VRF1 ip:192.168.101.100 mac:00:50:56:AF:3C:60 bd:uni/tn-Prod/BD-Service-BD1

[7:4172] [vrf:Prod:VRF1] redir ip tcp tn-Prod/ap-app1/epg-App(32773) eq 80 tn-Prod/ap-app1/epg-Web(32772)  [contract:uni/tn-Prod/brc-web-to-app] [hit=0]

destgrp-28 vrf:Prod:VRF1 ip:192.168.102.100 mac:00:50:56:AF:1C:44 bd:uni/tn-Prod/BD-Service-BD2

[9:4249] [vrf:Prod:VRF1] permit any tn-Prod/G-Prod-ASAv-VM1ctxVRF1/C-provider(49157) tn-Prod/ap-app1/epg-App(32773) [contract:uni/tn-Prod/brc-web-to-app] [hit=15]

...

その他のトラフィックフローの例

このセクションでは、他の一般的なトラフィックフローの例を考慮して、トラブルシューティングに必要なフローを特定します。トラブルシューティング手順については、このセクションの前の章を参照してください。

1. SNATのないロードバランサ：

- この例では、コンシューマEPG WebおよびプロバイダEPGアプリケーションに、ロードバランサのサービスグラフとの契約があります。App EPGのエンドポイントは、ロードバランサのVIPに関連付けられた実サーバです。

- プロバイダーからコンシューマトラフィックの方向に対して、ロードバランサへのPBRが有効になっています。

2. SNATのないファイアウォールとロードバランサ：

- この例では、コンシューマEPG WebおよびプロバイダーEPGアプリケーションに、ファイアウォールとロードバランサのサービスグラフとの契約があります。App EPGのエンドポイントは、ロードバランサのVIPに関連付けられた実サーバです。

- ファイアウォールへのPBRが両方向で有効になっている。

- プロバイダーからコンシューマトラフィックの方向に対して、ロードバランサへのPBRが有効になっています。

3. 共有サービス（VRF間契約）:

- この例では、コンシューマEPG WebおよびプロバイダーEPGアプリケーションは、ファイアウォールのサービスグラフと契約しています。EPG WebとEPG Appは異なるVRFにあります。

- ファイアウォールへのPBRが両方向で有効になっている。

- ファイアウォールはVRFの間にあります。

1. SNATのないロードバランサ

PBRは、双方向PBRまたは単方向PBRとして導入できます。単方向PBRの使用例の1つは、送信元ネットワークアドレス変換(NAT)を使用しないロードバランサ統合です。 ロードバランサが送信元NATを実行する場合、PBRは必要ありません。

トラフィックパスの例

次の図は、コンシューマEPG Webから2つの接続を持つプロバイダーEPGアプリケーションへの着信トラフィックフローの例を示しています。1つはコンシューマEPG Web内のエンドポイントからロードバランサVIPへ、もう1つはロードバランサからプロバイダーEPGアプリケーション内のエンドポイントへです。着信トラフィックはVIPを宛先としているため、VIPが到達可能であれば、トラフィックはPBRを使用しないロードバランサに到達します。ロードバランサは、宛先IPをVIPに関連付けられたEPGアプリケーションのいずれかのエンドポイントに変更しますが、送信元IPは変換しません。したがって、トラフィックはプロバイダーエンドポイントに向かいます。

SNAT転送パスのないロードバランサの例：コンシューマからVIP、ロードバランサからプロバイダー（PBRなし）

次の図は、プロバイダーEPGアプリケーションからコンシューマEPG Webへのリターントラフィックフローを示しています。リターントラフィックは元の送信元IPを宛先としているため、PBRはリターントラフィックをロードバランサに戻すために必要です。それ以外の場合、コンシューマエンドポイントは、送信元IPがVIPではなくプロバイダーエンドポイントであるトラフィックを受信します。ACIファブリックなどの中間ネットワークがパケットをコンシューマエンドポイントに転送しても、コンシューマエンドポイントがプロバイダーエンドポイントへのトラフィックを開始しなかったため、このようなトラフィックはドロップされます。

プロバイダーエンドポイントからコンシューマエンドポイントへのトラフィックがロードバランサにリダイレクトされた後、ロードバランサは送信元IPをVIPに変更します。その後、トラフィックはロードバランサから戻り、コンシューマエンドポイントに戻ります。

SNAT転送パスのないロードバランサの例：PBRを使用したコンシューマへのプロバイダー

リーフノードにプログラムされたポリシー。

次の図と「show zoning-rule」の出力は、サービスグラフ導入後のゾーン分割ルールを示しています。この例では、pcTag 32772(Web)からpcTag 16389(Service-LB)へのトラフィックが許可され、pcTag 16389(Service-LB)からpcTag 32773(App)へのトラフィックが許可され、pcTag 32773(App)からpcTag 32772(Web)へのトラフィックは「destgrp-31」（ロードバランサ）にリダイレクトされます。

サービスグラフ導入後のゾーン分割ルール：SNATを使用しないロードバランサ

Pod1-Leaf1# show zoning-rule scope 2752513

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

|   4248  | 16389  | 32773  | default  |    uni-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

|   4143  | 32773  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      | redir(destgrp-31) |    fully_qual(7)     |

|   4234  | 16389  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      |       permit      |    fully_qual(7)     |

|   4133  | 32772  | 16389  |    8     |     bi-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |

...

デフォルトでは、プロバイダーEPG(pcTag 32773)からService-LB(pcTag 16389)への許可ルールはプログラムされていません。ロードバランサからプロバイダーエンドポイントへのヘルスチェック用に双方向通信を許可するには、接続の[直接接続(Direct Connect)]オプションを[はい(True)]に設定する必要があります。場所は、[Tenant] > [L4-L7] > [Service Graph Templates] > [Policy]です。 デフォルト値はFalseです。

Direct Connectオプションの設定

次のように、プロバイダーEPG(32773)の許可ルールをService-LB(16389)に追加します。

Pod1-Leaf1# show zoning-rule scope 2752513

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

|   4248  | 16389  | 32773  | default  |     bi-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

|   4143  | 32773  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      | redir(destgrp-31) |    fully_qual(7)     |

|   4234  | 16389  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      |       permit      |    fully_qual(7)     |

|   4133  | 32772  | 16389  |    8     |     bi-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |

|   4214  | 32773  | 16389  | default  | uni-dir-ignore | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

2.トラフィックフローの例：SNATのないファイアウォールとロードバランサ

PBRは、1番目のノードとしてファイアウォールを、2番目のノードとしてロードバランサを使用するなど、複数のサービス機能をサービスグラフに配置できます。

トラフィックパスの例

次の図は、コンシューマEPG Webから2つの接続を持つプロバイダーEPGアプリケーションへの着信トラフィックフローの例を示しています。1つはコンシューマEPG Web内のエンドポイントからファイアウォール経由でロードバランサVIPに到達する方法で、もう1つはロードバランサからプロバイダーEPGアプリケーション内のエンドポイントに到達する方法です。VIP宛ての着信トラフィックはファイアウォールにリダイレクトされ、PBRを使用せずにロードバランサに送られます。ロードバランサは、宛先IPをVIPに関連付けられたApp EPGのいずれかのエンドポイントに変更しますが、送信元IPは変換しません。次に、トラフィックはプロバイダーエンドポイントに送信されます。

SNAT転送パスのないファイアウォールとロードバランサの例：コンシューマからVIP、ロードバランサからプロバイダー

SNAT転送パスのないファイアウォールとロードバランサの例：コンシューマからVIP、ロードバランサからプロバイダー（続き）

次の図は、プロバイダーEPGアプリケーションからコンシューマEPG Webへのリターントラフィックフローを示しています。リターントラフィックは元の送信元IPを宛先としているため、リターントラフィックをロードバランサに戻すにはPBRが必要です。

プロバイダーエンドポイントからコンシューマエンドポイントへのトラフィックがロードバランサにリダイレクトされた後、ロードバランサは送信元IPをVIPに変更します。トラフィックはロードバランサから戻り、ファイアウォールにリダイレクトされます。その後、トラフィックはファイアウォールから戻り、コンシューマエンドポイントに戻ります。

SNAT転送パスを使用しないファイアウォールとロードバランサの例：コンシューマへのプロバイダー

リーフノードにプログラムされたポリシー

次の図および次に示す「show zoning-rule」出力は、サービスグラフ導入後のゾーン分割ルールを示しています。この例では、pcTag 32772(Web)からpcTag 16389(Service-LB)へのトラフィックは「destgrp-32」（ファイアウォールのコンシューマ側）に、pcTag 32773(App)からpcTag 32772(Web)へのトラフィックは「destgrp-33」（ロードバランサ）に、pcTag 16389(Service-LB)からpcTag 32772(Web)へのトラフィックは「destgrp-34」（ファイアウォールのプロバイダー側）にリダイレクトされます。

サービスグラフ導入後のゾーニングルール：SNATを使用しないファイアウォールとロードバランサ

Pod1-Leaf1# show zoning-rule scope 2752513

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |       Priority       |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

|   4236  | 32772  | 16389  |    8     |     bi-dir     | enabled | 2752513 |      | redir(destgrp-32) |    fully_qual(7)     |

|   4143  | 32773  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      | redir(destgrp-33) |    fully_qual(7)     |

|   4171  | 16389  | 32773  | default  |     bi-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

|   4248  | 16389  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      | redir(destgrp-34) |    fully_qual(7)     |

|   4214  | 32774  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      |       permit      |    fully_qual(7)     |

|   4244  | 32775  | 16389  | default  |    uni-dir     | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

|   4153  | 32773  | 16389  | default  | uni-dir-ignore | enabled | 2752513 |      |       permit      |    src_dst_any(9)    |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+----------------------+

上記の例では、ロードバランサのプロバイダー側とプロバイダーEPG間の接続でDirect Connectオプションが「True」に設定されています。ロードバランサからプロバイダーエンドポイントへのヘルスチェックを有効にする必要があります。場所は、[Tenant] > [L4-L7] > [Service Graph Templates] > [Policy]です。 図「直接接続オプションの設定」を参照してください。

3.共有サービス（VRF間契約）

PBRはVRF間契約で有効にできます。このセクションでは、EPGからEPGのVRF間契約の場合にゾーン分割ルールがどのようにプログラムされるかについて説明します。

リーフノードにプログラムされたポリシー

EPGからEPGへのVRF間契約の場合、ポリシーは常にコンシューマVRFに適用されます。したがって、リダイレクトはコンシューマVRFで発生します。その他の組み合わせについては、表「ポリシーが適用される場所」を参照してください。 セクション「Forwarding」で説明します。

次の図と「show zoning-rule」の出力は、サービスグラフの導入後のゾーン分割ルールを示しています。この例では、pcTag 32772(Web)からpcTag 10936(App)へのトラフィックは「destgrp-36」（サービスノードのコンシューマ側）にリダイレクトされ、pcTag 10936(App)からpcTag 32772(Web)へのトラフィックは「destgrp-35」（サービスノードのプロバイダ側）にリダイレクトされます。 どちらも、コンシューマVRFであるVRF1で適用されます。pcTag 32776（ファイアウォールのコンシューマ側）からpcTag 32772(Web)へのトラフィックは、VRF1で許可されます。

サービスグラフ導入後のゾーニングルール：VRF間契約

Pod1-Leaf1# show zoning-rule scope 2752513

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+------------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  | Name |       Action      |        Priority        |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+------------------------+

|   4191  | 32776  | 32772  |    9     |    uni-dir     | enabled | 2752513 |      |       permit      |     fully_qual(7)      |

|   4143  | 10936  | 32772  |    9     | uni-dir-ignore | enabled | 2752513 |      | redir(destgrp-35) |     fully_qual(7)      |

|   4136  | 32772  | 10936  |    8     |     bi-dir     | enabled | 2752513 |      | redir(destgrp-36) |     fully_qual(7)      |

+---------+--------+--------+----------+----------------+---------+---------+------+-------------------+------------------------+

pcTag 49157（ファイアウォールのプロバイダー側）からpcTag 10936(App)へのトラフィックは、両方ともVRF2にあるため、VRF2で許可されます。

Pod1-Leaf1# show zoning-rule scope 2555904

+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------+

| Rule ID | SrcEPG | DstEPG | FilterID |   Dir   |  operSt |  Scope  | Name |  Action  |       Priority       |

+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------+

|   4249  | 49157  | 10936  | default  | uni-dir | enabled | 2555904 |      |  permit  |    src_dst_any(9)    |

+---------+--------+--------+----------+---------+---------+---------+------+----------+----------------------+