（注）	クラスタ モードで EPL を設定するには、単一のネイバーを EPL に追加する必要があります。DCNM EPL コンテナのインバンド IP アドレスは EPL の IP です。

DCNM クラスタ モードの展開では、DCNM ノードに加えて、追加の 3 つのコンピューティングノードが展開内に存在するようになります。クラスタ モードでのアプリケーションの展開については、「クラスタ モードの Cisco DCNM」を参照してください。

DCNM クラスタ モードでは、EPL を含むすべてのアプリケーションがコンピューティングノードで実行されます。DCNM アプリケーション フレームワークは、コンピューティングノードで実行されるすべてのアプリケーションの完全な耐用周期の管理を行います。EPL インスタンスは、コンピューティング ノードに割り当てられたインバンド プールから割り当てられた独自の IP アドレスを持つコンテナとして実行されます。この IP アドレスは、eth2 またはインバンド インターフェイスに割り当てられたものと同じ IP サブネットにあります。EPL 機能を有効にすると、EPL インスタンスはこの IP アドレスを使用してスパイン/RR と BGP ピアリングを形成します。EPL インスタンスをホストしているコンピューティング ノードがダウンすると、残りの 2 つのコンピューティングノードのいずれかで EPL インスタンスが自動的に再生成されます。EPL インスタンスに関連付けられているすべての IP アドレスおよびその他のプロパティは保持されます。

コンピューティングノードのレイヤ 2 隣接関係（アジャセンシー）要件により、コンピューティングノードの eth2 インターフェイスは DCNM ノードと同じ IP サブネットの一部である必要があります。この場合もやはり、同じ vPC ペアのスイッチにコンピューティング ノードを接続することが、推奨される導入オプションです。以下に示すように、クラスタ モード DCNM の OVA 設定では、eth2 インターフェイスに対応するポート グループで無差別モードが有効になっていることを確認してください。

DCNM クラスタ モードの EPL 機能の有効化は、非クラスタ モードの有効化と同じです。主な違いは、スパイン/RR では、EPL インスタンスに割り当てられたIP アドレスを指す単一の BGP ネイバーシップだけが必要なことです。非クラスタモードでの DCNM ネイティブ HA 導入では、すべてのスパイン/RR に常に 2 つの構成済み BGP ネイバーがあります。1 つは DCNM プライマリ eth2 インターフェイスを指し、もう 1 つは DCNM セカンダリ eth2 インターフェイスを指します。ただし、アクティブになるネイバーは常に 1 つだけです。

DCNM リリース 11.2(1) では、Easy ファブリックに加えて、外部ファブリックにインポートされるスイッチで構成される VXLAN EVPN ファブリックの EPL を有効にできます。外部ファブリックは、の [ファブリック モニタ モード (Fabric Monitor Mode)] フラグ ([外部ファブリック設定 (External Fabric Settings)]) の選択に基づいて、管理対象モードまたはモニタ対象モードにすることができます。DCNM からモニタされているだけで構成されていない外部ファブリックの場合、このフラグは無効になります。そのため、OOB 経由で、または CLI を使用して、スパインの BGP セッションを設定する必要があります。サンプル テンプレートを確認するには、ℹ アイコンをクリックして、EPL を有効にしながら必要な設定を表示します。

[外部ファブリック設定 (External Fabric settings)] の [ファブリック モニタ モード (Fabric Monitor Mode)] チェックボックスがオフの場合でも、EPL はデフォルトの [ファブリックの設定 (Configure my fabric)] オプションを使用してスパイン/RRを設定できます。ただし、EPL を無効にすると、スパイン/RR のルータ bgp 設定ブロックが消去されます。これを防ぐには、BGP ポリシーを手動で作成し、選択したスパイン/RR にプッシュする必要があります。

エンドポイント ロケータ機能の有効化に失敗する理由は複数あります。通常、適切なデバイスが選択され、使用する IP アドレスが正しく指定されている場合は、DCNM から BGP RR への接続が存在しないため、機能を有効にできません。これは、基本的な IP 接続が使用可能であることを確認するための健全性チェックです。次の図は、EPL 機能を有効にしようとしたときに発生したエラーシナリオの例を示しています。

EPL 機能が有効または無効になったときに発生した内容の詳細を示すログは、/usr/local/cisco/dcm/fm/logs/epl.log にある、epl.log ファイルに記載されています。次の例は、ファブリックの EPL 設定の進行状況を示す epl.log のスナップショットです。

2019.12.05 12:18:23  INFO  [epl] Found DCNM Active Inband IP: 192.168.94.55/24
2019.12.05 12:18:23  INFO  [epl] Running script: [sudo, /sbin/appmgr, setup, inband-route, --host, 11.2.0.4]
2019.12.05 12:18:23  INFO  [epl] Getting EPL configure progress for fabric 4
2019.12.05 12:18:23  INFO  [epl] EPL Progress 2
2019.12.05 12:18:23  INFO  [epl] [sudo, /sbin/appmgr, setup, inband-route, --host, 11.2.0.4] command executed, any errors? No
2019.12.05 12:18:23  INFO  [epl] Received response:
2019.12.05 12:18:23  INFO  [epl] Validating host route input
2019.12.05 12:18:23  INFO  [epl] Done configuring host route
2019.12.05 12:18:23  INFO  [epl] Done.
2019.12.05 12:18:23  INFO  [epl] Running script: [sudo, /sbin/appmgr, setup, inband-route, --host, 11.2.0.5]
2019.12.05 12:18:23  INFO  [epl] [sudo, /sbin/appmgr, setup, inband-route, --host, 11.2.0.5] command executed, any errors? No
2019.12.05 12:18:23  INFO  [epl] Received response:
2019.12.05 12:18:23  INFO  [epl] Validating host route input
2019.12.05 12:18:23  INFO  [epl] Done configuring host route
2019.12.05 12:18:23  INFO  [epl] Done.
2019.12.05 12:18:23  INFO  [epl] Running command: sudo /sbin/appmgr show inband
2019.12.05 12:18:24  INFO  [epl] Received response: Physical IP=192.168.94.55/24
Inband GW=192.168.94.1
No IPv6 Inband GW found
 
2019.12.05 12:18:26  INFO  [epl] Call: http://localhost:35000/afw/apps?imagetag=cisco:epl:2.0&fabricid=epl-ex-site, Received response: {"ResponseType":0,"Response":[{"Name":"epl_cisco_epl-ex-site_afw","Version":"2.0","FabricId":"epl-ex-site","ImageTag":"cisco:epl:2.0","TotalReplicaCount":1,"Url":"","Category":"Application","Status":"NoReplicas","RefCount":0,"Deps":["elasticsearch_Cisco_afw","kibana_cisco_afw"],"RunningReplicaCount":0,"ApplicationIP":"172.17.8.23","Members":{},"MemberHealth":{},"ReplicationMode":1,"services":null,"Upgradable":false}]}
2019.12.05 12:18:26  INFO  [epl] Epl started on AFW

EPL が正常に有効化されると、エンドポイント情報に関連付けられているすべてのデバッグ、エラー、および情報ログが、関連するファブリックのディレクトリの下の /var/afw/applogs/ に保存されます。たとえば、[test] ファブリックで EPL が有効になっている場合、ログは /var/afw/applogs/epl_cisco_test_afw_log /epl/ に置かれ、ファイル名 afw_bgp.log.1 で始まります。ネットワークの規模とエンドポイント イベントの数に応じて、ファイル サイズが増加します。したがって、afw_bgp.log の最大数とサイズには制限があります。ファイル サイズは最大 100 MB、10 ファイルまで保存されます。

Note	EPL は Docker コンテナ内のこのディレクトリにシンボリック リンクを作成するので、ネイティブにアクセスすると破損しているように見えます。

EPL は、BGP アップデートを使用してエンドポイント情報を取得します。これが機能するためには、エンドポイントを持つすべてのスイッチのスイッチ ループバックまたは VTEP インターフェイスの IP アドレスを DCNM で検出する必要があります。検証するには、Cisco DCNM の [Web UI] > [ダッシュボード（Dashboard）] > [スイッチ（Switch）] > [インターフェイス（Interfaces）] タブに移動し、対応するレイヤ 3 インターフェイス（通常はループバック）に関連付けられている IP アドレスとプレフィックスが正しく表示されるかどうかを確認します。

Cisco DCNM クラスタの導入で、EPL が BGP ピアリングを確立できず、アクティブな DCNM はスパインのループバック IP アドレスに ping を送信できるものの、EPL コンテナはできない場合、Cisco DCNM およびそのコンピューティング ノードの eth2 ポート グループで無差別（Promiscuous）モードが [受容（Accept）] に設定されていないことを意味します。この設定を変更すると、コンテナはスパインにを ping を送信でき、EPL は BGP を確立します。

大規模なセットアップでは、スイッチからこの情報を取得するために 30 秒（Cisco DCNMで設定されたデフォルトタイマー）以上かかる場合があります。この場合、ssh.read-wait-timeout プロパティ（[管理（Administration）] > [DCNM サーバー（DCNM Server）] > [サーバー プロパティ（Server Properties）]）をデフォルトの 30000 から、60000 以上の値に変更する必要があります。

大規模なセットアップでは、ダッシュボードに表示されるエンドポイント データがいくらか不正確になることがあります。エンドポイント数が多い場合、パフォーマンスの精度は最大で約 1％ 低下します。ダッシュボードが予想と大きく異なる場合は、DCNM にパッケージ化されている検証スクリプトを使用して有効性を確認できます。root として、/root/packaged-files/scripts/ にある epl-rt-2.py スクリプトを実行します。このスクリプトを実行するには、RR/スパインの IPと、関連するユーザー名とパスワードが必要です。/root/packaged-files/scripts /ディレクトリは読み取り専用であるため、スクリプトはそのディレクトリの外部で実行する必要があります。たとえば、IP 10.2.0.5、ユーザ名 admin、パスワード cisco123 を使用してスパインのスクリプトを実行するには、作業ディレクトリを /root/ にして、/root/packaged-files/scripts/epl-rt-2.py -s 10.2.0.5 -u admin -p cisco123 を実行します。EPL ダッシュボードに予想された数値が表示されず、epl-rt-2.py スクリプトの出力がダッシュボードと大きく異なる場合は、テクニカル サポートにお問い合わせください。

クラスタ モードでは、BGP はスパイン/RR と DCNM の間で確立されません。eth2 DCNM インターフェイスに対応するポート グループの [無差別モード（Promiscuous mode）] 設定が [受容（Accept）] に設定されていることを確認します。接続がまだ確立されていない場合は、次の手順を実行して、DCNM の BGP クライアントとスパイン/RR 間の接続を確認します。

1. アクティブな DCNM でシェルを開いて、次のコマンドを実行します。

   1. docker service ls

      * EPL サービスの ID をメモします

   2. docker service ps $ID

      *[ノード（NODE）] フィールドをメモします、

   3. afw compute list -b

      *以前の ホスト名（HostName）（ノード）に一致する HostIp をメモします。これは、EPL サービスが現在実行されているコンピューティング ノードです。

2. 手順 1-c でメモしたコンピューティング ノードでシェルを開き、次のコマンドを実行します。

   1. docker container ls

      *EPL のコンテナ ID をメモします複数の EPL コンテナがある場合は、コンテナ名を確認して、どのコンテナがどのファブリックに対応しているかを確認します。命名スキームは epl_cisco_ $ FabricName_afw*です。

   2. docker container inspect $CONTAINER_ID

      *SandboxKeyの値をメモします

   3. nsenter --net=$SandboxKey

      このコマンドにより、EPL コンテナのネットワーク名前空間に入ります。これで、ifconfig、ip、ping などのネットワーク コマンドは、シェルで exit コマンドを発行するまで、コンテナ内から実行されているかのように動作します。

3. スパイン/RR に ping を送信してみます。DCNM クラスタに構成されているインバンド IP プールが、スイッチ ループバック IP と競合しないことを確認します。

ISE ポリシーが設定された EPL

Cisco NX-OS リリース 9.3(4) 以前のリリースを実行しているスイッチで、AAA 構成が設定されているシナリオを考えます。AAA スイッチの構成例を次に示します。

feature tacacs+
tacacs-server host ISE_ACS_IP_ADDDRESS 5 key 7 "Fewhg12345"
aaa group server tacacs+ AAA_TACACS
       server ISE_ACS_IP_ADDDRESS
       use-vrf management
       source-interface mgmt0
aaa authentication login default group AAA_TACACS local
aaa authentication login console local
aaa authorization config-commands default group AAA_TACACS local
aaa authorization commands default group AAA_TACACS local
aaa accounting default group AAA_TACACS
aaa authentication login error-enable

guestshell 、run guestshell 、show といったコマンドにより設定された ISE サーバーは、ISE 内で作成された検出アカウントまたはポリシーにアクセスすることが許可されます。許可されるコマンドは、[TACACS コマンド セット（TACACS Command Sets）] ウィンドウで設定します。このウィンドウは、ISE の [ポリシー エレメント（Policy Elements）] タブの下にあります。

DCNM の eth0 IP およびファブリック デバイスのサブネットも許可されます。これは、[デバイス管理ポリシー セット（Device Admin Policy Sets）] ウィンドウで設定します。このウィンドウは、[デバイス管理（Device Administration）] タブの下にあります。

これで、DCNM は、エンドポイント ロケータ機能に必要なすべての show コマンドを実行するために検出アカウントを使用するように構成されます。ただし、スイッチ NXAPI の問題により、リクエスタ IP がリモート AAA 認証要求に入力されていないため、AAA 検証が失敗します。show コマンドは IP アドレスから発行されたものとは見なされないため、コマンドはブロックされ、EPL ダッシュボードに必要なエンドポイント情報が表示されなくなります。

回避策として、AAA ルールを緩和し、「ブランク」の送信者からの要求を許可することを推奨します。「空白」の送信者からの要求を許可するには、[ステータス（Status）] 列の下にある アイコンをクリックします（[アカウント検出許可（Discovery Account Permit）] と [アカウント検出拒否（Discovery Account Deny）] の両方で、[デバイス管理ポリシー セット（Device Admin Policy Sets）] ウィンドウにあります）。[無効（Disabled）] を選択して [保存（Save）] をクリックします。

また、この問題は、Cisco NXOS リリース 9.3(5) 以降のリリースを実行しているスイッチでは発生しません。