Cisco APIC 基本設定ガイド、リリース 3.x

リンクレベルポリシー

アクセスポリシーの一種であるリンクレベルポリシーを設定できます。リンクレベルポリシーには、自動ネゴシエーション、ポート速度、リンクデバウンスなどの物理層（レイヤ 1）インターフェイス設定が含まれます。

電磁場干渉に対する再トレーニング

5.2(4) 以降のリリースには、電磁干渉（EMI）再トレーニング機能があり、電磁干渉からのリンク上のノイズのフィルタリングを行い、リンクフラップを回避するようにリンクを再トレーニングできます。データセンター環境に大量の EMI ノイズが存在する場合は、EMI 再トレーニングを有効にしてください。

リンクレベルポリシーを構成するときに、EMI 再トレーニングプロパティの有効化を選択することで、EMI 再トレーニングを有効にすることができます。この機能は、銅ケーブルを使用する Cisco N9K-C93108TC-EX および N9K-C93108TC-FX リーフスイッチでのみサポートされます。

GUI を使用したリンクレベルポリシーの設定

手順

ステップ 1	メニューバーで、[ファブリック（FABRIC）] > [アクセスポリシー（Access Policies）] の順に選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[ポリシー（Policies）] > [インターフェイス（Interface）] > [リンクレベル（Link Level）]を選択します。
ステップ 3	[リンクレベル（Link Level）] を右クリックし、[リンクレベルポリシー（Create Link Level Policy）] を選択します。
ステップ 4	[リンクレベルポリシーの作成（Create Link Level Policy）] ダイアログで、必要な設定に応じてフィールドに入力します。 [速度（Speed）] には、デフォルト値である [継承（inherit）] を選択することをお勧めします。この値を使用して、Cisco APIC はスイッチに挿入されたトランシーバに基づいて速度を決定します。フィールドの詳細については、ツールチップを参照してください。
ステップ 5	[Submit] をクリックします。

ポート起動遅延

リリース 4.2（5）から、リンクレベルポリシーを構成する場合は、ポートの起動時に判定フィードバックイコライザ（DFE）の調整が遅延する時間をミリ秒単位で指定する [ポート起動遅延（ミリ秒）（Port bring-up delay (milliseconds)）] パラメータを設定します。遅延は、一部のサードパーティ製アダプタを使用する場合に、リンクの起動中に CRC エラーを回避するために使用されます。遅延は必要な場合にのみ設定してください。ほとんどの場合、遅延を設定する必要はありません。

（注）

ファブリックエクステンダ（FEX）ポートでは、ポートの起動遅延（ミリ秒）パラメータは適用されません。

リンクフラップポリシー

リンクフラップは、スイッチ上の物理インターフェイスが一定期間にわたって継続的にアップおよびダウンする状況です。原因は通常、不良、サポート対象外、または非標準のケーブルまたは Small Form-Factor Pluggable（SFP）に関連しているか、または他のリンク同期の問題に関連しており、原因は断続的または永続的です。

リンクフラップポリシーは、リンクフラッピングエラーのためにスイッチポートを無効にするタイミングを指定します。リンクフラップポリシーでは、スイッチのポートが指定した時間内にフラップできる最大回数を指定します。ポートが指定された時間内に指定された回数以上フラップした場合、ポートは「error-disable」状態になります。Cisco Application Policy Infrastructure Controller（APIC）を使用してポートで手動フラップを実行し、ポートを無効または有効にするまで、ポートはこの状態のままです。

（注）

リンクフラップポリシーは、ファブリックエクステンダ（FEX）ホストインターフェイス（HIF）ポート、および製品 ID に -EX、-FX、-FX2、-GX が指定されていないリーフスイッチモデルでは適用されません。

GUI を使用したリンクフラップポリシーの設定

次の手順では、GUI を使用してリンクフラップポリシーを設定します。これを任意のリーフまたはスパインノードインターフェイスポリシーに接続して、ノードのアクセスポートにリンクフラップポリシーを展開できます。

手順

ステップ 1	メニューバーで、[ファブリック（FABRIC）] > [アクセスポリシー（Access Policies）] の順に選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[ポリシー（Policies）] > [インターフェイス（Interface）] > [リンクフラップ（Link Flap）]を選択します。
ステップ 3	[リンクフラップ（Link Flap）] を右クリックし、[リンクフラップポリシーの作成（Create Link Flap Policy）] を選択します。
ステップ 4	[リンクレベルポリシーの作成（Create Link Level Policy）] ダイアログで、必要な設定に応じてフィールドに入力します。フィールドの詳細については、ツールチップとオンラインヘルプを参照してください。
ステップ 5	[Submit] をクリックします。

時刻同期と NTP

シスコアプリケーションセントリックインフラストラクチャ（ACI）ファブリックにおいて、時刻の同期は、モニタリング、運用、トラブルシューティングなどの多数のタスクが依存している重要な機能です。クロック同期は、トラフィックフローの適切な分析にとって重要であり、複数のファブリックノード間でデバッグとフォールトのタイムスタンプを関連付けるためにも重要です。

1 つ以上のデバイスでオフセットが生じると、多くの一般的な運用問題を適切に診断して解決する機能がブロックされる可能性があります。また、クロック同期によって、アプリケーションのヘルススコアが依存している ACI の内蔵アトミックカウンタ機能をフル活用できます。時刻同期が存在しない場合や不適切に設定されている場合でも、エラーやヘルススコアの低下が引き起こされるわけではありません。これらの機能を適切に使用できるように、ファブリックやアプリケーションを完全に展開する前に、時刻同期を設定する必要があります。デバイスのクロックを同期させる最も一般的な方法は、ネットワークタイムプロトコル（NTP）を使用することです。

NTP を設定する前に、どの管理 IP アドレススキームを ACI ファブリックに配置するかを検討してください。すべての ACI ノードと Application Policy Infrastructure Controller（APIC）の管理を設定するために、インバンド管理とアウトオブバンド管理の 2 つのオプションがあります。ファブリックに対して選択した管理オプションに応じて、NTP の設定が異なります。時刻同期の展開に関するもう 1 つの考慮事項は、時刻源の場所です。プライベート内部時刻または外部パブリック時刻の使用を決定する際は、時刻源の信頼性について慎重に検討する必要があります。

インバンドの管理 NTP

（注）

インバンド管理アクセスについては、本書の「管理アクセスの追加」という項を参照してください。

インバンド管理 NTP：ACI ファブリックをインバンド管理とともに展開する場合は、ACI のインバンド管理ネットワーク内から NTP サーバへの到達可能性を検討します。ACI ファブリック内で使用されるインバンド IP アドレッシングには、ファブリックの外部から到達できません。インバンド管理されているファブリックの外部の NTP サーバを使用するには、その通信を可能にするポリシーを作成します。。

NTP over IPv6

NTP over IPv6 アドレスは、ホスト名とピアアドレスでサポートされます。gai.conf も、IPv4 アドレスのプロバイダーまたはピアの IPv6 アドレスが優先されるように設定できます。ユーザは、IP アドレス（インストールまたは優先順位よって IPv4、IPv6、または両方）を提供することによって解決できるホスト名を設定できます。

GUI を使用した NTP の設定

（注）

使用する DNS サーバがインバンドまたはアウトオブバンド接続で到達可能に設定されている場合、ホスト名ベースの NTP サーバのホスト名解決に失敗するリスクがあります。ホスト名を使用する場合は、DNS プロバイダと接続する DNS サービスポリシーが設定されていることを確認します。また、DNS プロファイルポリシーの設定時に選択した管理 EPG のインバンドまたはアウトオブバンド VRF インスタンスに適切な DNS ラベルが設定されていることを確認します。

手順

ステップ 1	メニューバーで、[ファブリック（FABRIC）] > [ファブリックポリシー（Fabric Policies）]の順に選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[ポッドポリシー（Pod Policies）] > [ポリシー（Policies）]の順に選択します。
ステップ 3	[作業（Work）] ペインで、[アクション（Actions）]> > [日時ポリシーの作成（Create Date and Time Policy）] の順に選択します。
ステップ 4	[Create Date and Time Policy] ダイアログボックスで、次の操作を実行します。環境内のさまざまな NTP 設定を区別するポリシーの名前を入力します。をクリックして有効になっているの認証状態フィールドおよび展開、 NTP クライアントの認証キーテーブルが表示され、重要な情報を入力します。Update と Next をクリックします。 [+] 記号をクリックし、使用する NTP サーバ情報（プロバイダー）を指定します。 [Create Providers] ダイアログボックスで、次のフィールドを含めて、すべての関連情報を入力します。[Name]、[Description]、[Minimum Polling Intervals]、[Maximum Polling Intervals]。複数のプロバイダーを作成する場合は、最も信頼できる NTP 時刻源の [Preferred] チェックボックスをオンにします。ファブリックのすべてのノードがアウトオブバンド管理によって NTP サーバに到達できる場合は、[Management EPG] ドロップダウンリストで、[Out-of-Band] を選択します。インバンド管理を導入した場合は、インバンド管理 NTP の詳細を参照してください。[OK] をクリックします。作成するプロバイダーごとに、この手順を繰り返します。
ステップ 5	[ナビゲーション（Navigation）] ペインで、[ポッドポリシー（Pod Policies）] > [ポリシーグループ（Policy Groups）]を選択します。
ステップ 6	[作業（Work）] ペインで、[アクション（Actions）] > [ポッドポリシーグループの作成（Create Pod Policy Group）]を選択します。
ステップ 7	[Create Pod Policy Group] ダイアログボックスで、次の操作を実行します。ポリシーグループの名前を入力します。 [Date Time Policy] フィールドのドロップダウンリストから、前に作成した NTP ポリシーを選択します。[Submit] をクリックします。ポッドポリシーグループが作成されます。または、デフォルトのポッドポリシーグループを使用することもできます。
ステップ 8	[ナビゲーション（Navigation）] ペインで、[ポッドポリシー（Pod Policies）] > [プロファイル（Profiles）]を選択します。
ステップ 9	[Work] ペインで、目的のポッドセレクタ名をダブルクリックします。
ステップ 10	[Properties] 領域の [Fabric Policy Group] ドロップダウンリストから、作成したポッドポリシーグループを選択します。[Submit] をクリックします。

REST API を使用した NTP の設定

（注）

使用する DNS サーバがインバンドまたはアウトオブバンド接続で到達可能に設定されている場合、ホスト名ベースの NTP サーバのホスト名解決に失敗するリスクがあります。ホスト名を使用する場合は、DNS プロバイダと接続する DNS サービスポリシーが設定されていることを確認します。また、DNS プロファイルポリシーの設定時に選択した管理 EPG のインバンドまたはアウトオブバンド VRF インスタンスに適切な DNS ラベルが設定されていることを確認します。

手順

ステップ 1

NTP を設定します。

例:

POST url: https://APIC-IP/api/node/mo/uni/fabric/time-test.xml

<imdata totalCount="1">
    <datetimePol adminSt="enabled" authSt="disabled" descr="" dn="uni/fabric/time-CiscoNTPPol" name="CiscoNTPPol" ownerKey="" ownerTag="">
        <datetimeNtpProv descr="" keyId="0" maxPoll="6" minPoll="4" name="10.10.10.11" preferred="yes">
            <datetimeRsNtpProvToEpg tDn="uni/tn-mgmt/mgmtp-default/inb-default"/>
        </datetimeNtpProv>
    </datetimePol>
</imdata>

ステップ 2

デフォルトの日付と時刻のポリシーをポッドポリシーグループに追加します。

例:


POST url: https://APIC-IP/api/node/mo/uni/fabric/funcprof/podpgrp-calo1/rsTimePol.xml

POST payload: <imdata totalCount="1">
<fabricRsTimePol tnDatetimePolName=“CiscoNTPPol”>
</fabricRsTimePol>
</imdata>

ステップ 3

ポッドポリシーグループをデフォルトのポッドプロファイルに追加します。

例:

POST url: https://APIC-IP/api/node/mo/uni/fabric/podprof-default/pods-default-typ-ALL/rspodPGrp.xml

payload: <imdata totalCount="1">
<fabricRsPodPGrp tDn="uni/fabric/funcprof/podpgrp-calo1" status="created">
</fabricRsPodPGrp>
</imdata>

GUI を使用した NTP の動作の確認

手順

ステップ 1

メニューバーで、[FABRIC] > [Fabric Policies] を選択します。

ステップ 2

[Navigation] ペインで、[Pod Policies] > [Policies] > [Date and Time] > [ntp_policy] > [server_name] の順に選択します。

ntp_policy は前に作成したポリシーです。[Host Name] フィールドまたは [IP address] フィールドでは IPv6 アドレスがサポートされます。入力したホスト名に IPv6 アドレスが設定されている場合、IPv6 アドレスが IPv4 アドレスより優先されるように実装する必要があります。

ステップ 3

[Work] ペインで、サーバの詳細を確認します。

NTPサーバ

NTP サーバ機能は、クライアントのスイッチも NTPサーバとして動作して、下流のクライアントに NTP の時間情報を提供できるようにします。NTP サーバを有効にすると、スイッチ上の NTP デーモンは、NTP クライアントからのすべてのユニキャスト (IPv4 または IPv6) リクエストに対し、が時間情報によって応答します。NTP サーバの実装は、NTP RFCv3 に準拠しています。NTP RFC に従い、サーバはクライアントに関連する状態情報は維持しません。

NTP サーバーは、すべてのテナント VRF とインバンド/アウトオブバンド管理 VRF の IP アドレスを有効にして、NTP クライアントにサービスを提供します。
NTP サーバーは、両方の管理 VRF またはテナント VRF に着信した NTP 要求に応答し、同じ VRF を使用して応答を返します。
NTP サーバはIPv4 と IPv6 の両方をポートします。
スイッチは、IPv4 クライアントとして同期して IPv6 サーバとして動作すること、およびその逆が可能です。
スイッチは、アウトオブバンド管理またはインバンド管理 VRF を使用して NTP クライアントとして同期でき、管理 VRF またはテナント VRF のいずれかから NTP クライアントにサービスを提供します。
追加コントラクトまたは IP テーブルの設定は必要ありません。
スイッチは上流のサーバと同期すると、サーバとして時間情報をストラタム番号とともに送信します。この番号はシステムのピアのストラタム番号から 1 増えたものになります。
スイッチクロックが非統制 (アップストリームサーバに同期されていない) の場合、サーバはストラタム 16 で時間情報を送信します。クライアントはこのサーバには同期できません。

デフォルトでは、NTP サーバ機能は無効になっています。これはポリシーの設定によって明示的に有効にする必要があります。

（注）

クライアントは、リーフスイッチのインバンド、アウトオブバンドの IP アドレスを NTP サーバ IP アドレスとして使用できます。クライアントはまた、自身が一部となっている EPG のブリッジドメイン SVI または任意の L3Out IP アドレスを、ファブリック外のクライアントの NTP サーバー IP アドレスとして使用できます。

ファブリックのスイッチは、同じファブリックの他のスイッチに同期するべきではありません。ファブリックスイッチは常に、外部の NTP サーバに同期するべきです。

GUI を使用した NTP サーバの有効化

このセクションでは、APIC GUI で NTP を設定して NTPサーバを有効にする方法について説明します。

手順

ステップ 1

メニューバーで、FABRIC > Fabric Policies を選択します。

ステップ 2

ナビゲーションウィンドウで、Pod Policies > Policies を選択します。

Date and Time オプションが Navigation ウィンドウに表示されます。

ステップ 3

Navigation ウィンドウで、、Date and Time を右クリックして Create Date and Time Policy を選択します。

Create Date and Time Policy ダイアログが Work ウィンドウに表示されます。

ステップ 4

[Create Date and Time Policy] ダイアログボックスで、次の操作を実行します。

環境内のさまざまな NTP 設定を区別するポリシーの名前を入力します。

Server State オプションで、enabled をクリックします。

Server State によって、スイッチを NTP サーバとして動作し、下流のクライアントに NTP 時間情報を提供できるようにします。

（注）

サーバ機能をサポートする場合、サーバは常にピア設定にすることを推奨します。これにより、サーバはクライアントに対し、一貫した時間を提供できるようになります。

Server State を有効にすると、次のことが可能になります:

NTP サーバは、上流のサーバに同期するスイッチに対し、時刻情報とともにストラタム番号を送信します。この番号はシステムのピアのストラタム番号から 1 つ増えたものになります。
スイッチのクロックが上流サーバに同期していない場合、サーバは時刻情報とストラタム 16 を送信します。クライアントはこのサーバに同期することはできません。

（注）

サーバ機能をサポートする場合、サーバは常にピア設定にすることを推奨します。ピア設定では、クライアントに対し一貫した時間を提供できます。

Master Mode オプションで、enabled をクリックします。

Master Mode を使用すれば、指定された NTP サーバが、下流のクライアントに対し、設定されたストラタム番号とともに、調整されていないローカルクロック時刻を提供することが可能になります。たとえば、NTP サーバとして動作しているリーフスイッチは、クライアントとして動作しているリーフスイッチに対し、調整されていないローカルクロック時刻を提供できます。

（注）

Master Mode が適用できるのは、サーバのクロックが調整されていない場合のみです。
デフォルトのマスターモードの Stratum Value は 8 です。

Stratum Value フィールドには、NTP クライアントが同期した時刻を取得するときのストラタム番号を指定します。範囲は 1 ～ 14 です。
Next をクリックします。
[+] 記号をクリックし、使用する NTP サーバ情報（プロバイダー）を指定します。
[Create Providers] ダイアログボックスで、次のフィールドを含めて、すべての関連情報を入力します。[Name]、[Description]、[Minimum Polling Intervals]、[Maximum Polling Intervals]。
- 複数のプロバイダーを作成する場合は、最も信頼できる NTP 時刻源の [Preferred] チェックボックスをオンにします。
- ファブリックのすべてのノードがアウトオブバンド管理によって NTP サーバに到達できる場合は、[Management EPG] ドロップダウンリストで、[Out-of-Band] を選択します。インバンド管理を導入した場合は、インバンド管理 NTP の詳細を参照してください。[OK] をクリックします。

作成するプロバイダーごとに、この手順を繰り返します。

ステップ 5

Navigation ウィンドウで、Pod Policies を選択し、Policy Groups を右クリックします。

Create Pod Policy Group ダイアログが表示されます。

ステップ 6

[Work] ペインで、[Actions] > [Create Pod Policy Group] の順に選択します。

ステップ 7

[Create Pod Policy Group] ダイアログボックスで、次の操作を実行します。

ポリシーグループの名前を入力します。
[Date Time Policy] フィールドのドロップダウンリストから、前に作成した NTP ポリシーを選択します。[Submit] をクリックします。

ポッドポリシーグループが作成されます。または、デフォルトのポッドポリシーグループを使用することもできます。

ステップ 8

[Navigation] ペインで、[Pod Policies] > [Profiles] の順に選択します。

ステップ 9

[Work] ペインで、目的のポッドセレクタ名をダブルクリックします。

ステップ 10

[Properties] 領域の [Fabric Policy Group] ドロップダウンリストから、作成したポッドポリシーグループを選択します。

ステップ 11

[Submit] をクリックします。

GUI を使用した日時形式の設定

ここでは、Cisco APIC GUI を使用して日時形式を設定する方法を示します。

手順

ステップ 1

メニューバーで、[システム（System）]> > [システム設定（System Settings）] を選択します。

ステップ 2

ナビゲーションペインで [日付と時間（Date and Time）] をクリックします。

ステップ 3

[作業（Work）] ペインで、次のオプションから選択します。

[表示形式（Display Format）]：[local] をクリックして日時を現地時間で表示するか、[utc] をクリックして日時を UTC で表示します。デフォルトは [local] です。
[タイムゾーン（Time Zone）]：ドロップダウン矢印をクリックして、ドメインのタイムゾーンを選択します。デフォルトは [協定世界時（Coordinated Universal Time）] です。
[オフセット状態（Offset State）]：[有効（enable）] または [無効（disable）] をクリックします。有効にすると、ローカル時刻と基準時刻の差が表示されます。デフォルトは [有効（enable）] です。

DHCP リレーポリシーの設定

DHCP リレーポリシーは、DHCP クライアントとサーバが異なるサブネット上にある場合に使用できます。クライアントが配置された vShield ドメインプロファイルとともに ESX ハイパーバイザ上にある場合は、DHCP リレーポリシー設定を使用することが必須です。

（注）

インフラまたは共通テナントで作成された DHCP リレーポリシーは、ブリッジドメインで DHCP リレーを設定するときに他のテナントで使用できません。テナント間 DHCP リレー通信の場合は、グローバル DHCP リレーポリシーの作成の説明に従ってグローバル DHCP リレーポリシーを作成します。
DHCP リレー IP アドレスは、常にプライマリ SVI IP アドレスに設定されます。

vShield コントローラが Virtual Extensible Local Area Network（VXLAN）を展開すると、ハイパーバイザホストはカーネル（vmkN、仮想トンネルエンドポイント（VTEP））インターフェイスを作成します。これらのインターフェイスは、DHCP を使用するインフラストラクチャテナントで IP アドレスを必要とします。したがって、APIC が DHCP サーバとして動作しこれらの IP アドレスを提供できるように、DHCP リレーポリシーを設定する必要があります。

ACI fabric は DHCP リレーとして動作するときに、DHCP オプション 82（DHCP Relay Agent Information Option）を、クライアントの代わりに中継する DHCP 要求に挿入します。応答（DHCP オファー）がオプション 82 なしで DHCP サーバから返された場合、その応答はファブリックによってサイレントにドロップされます。したがって、ACI fabric が DHCP リレーとして動作するときは、ACI fabric に接続されたノードを計算するために IP アドレスを提供している DHCP サーバはオプション 82 をサポートする必要があります。

DHCP リレープロバイダー EPG が L3Out Ext-EPG の場合、リレーパケットは、L3Out で構成された各インターフェイスと router-id に送信されます。

Cisco APIC リリース 5.2(4) 以降、DHCPv6 オプション 79 を含むように DHCP リレーエージェントとして設定されたブリッジドメインを設定できるようになりました。オプション 79 が有効になっている場合、ブリッジドメインがリレーエージェントとして設定されているリーフスイッチには、DHCPv6 リレーパケットのオプション 79 を介してクライアントのリンク層アドレスが含まれます。

オプション 79 を選択すると、DHCP パケットのペイロードにクライアントの MAC アドレス (クライアントリンク層アドレス) が含まれるようになります。オプション 79 には、デバイスの実際のリンク層アドレスが含まれています。リレーメッセージは、クライアントから送信される実際の DHCP パケットのイーサネット送信元 MAC アドレスを使用し、イーサネットソースを示す 00:01 のプレフィックスを付けてから、これらの 8 バイト（クライアント MAC アドレス）をオプション 79 にコピーします。

DHCPv6 のクライアントリンク層アドレスオプションの詳細については、RFC 6939 を参照してください。

オプション 79 を使用する利点

デュアルスタックシナリオ（IPv6 と IPv4 をサポート）では、DHCPv4 および DHCPv6 メッセージを同じクライアントインターフェイスに関連付ける必要がある場合、オプション 79 は、RFC 標準に準拠して、DHCPv6 リレーパケットにクライアント MAC アドレスを含めて送信します。

DHCP サーバー設定フィールドについて

（注）

以下は、このセクションで使用されるいくつかの用語の定義です。

クライアント VRF：DHCP 要求を開始するホストが配置されている VRF。
サーバー VRF：DHCP サーバーが配置されている VRF、または DHCP サーバーに到達するためのパスを提供する VRF (たとえば、L3Out 経由で)。
クライアント EPG：DHCP 要求を開始するホストが配置されている EPG。
サーバー EPG : DHCP サーバーが接続されている EPG (または、DHCP サーバーが ACI ファブリックの外部にある場合、は外部 EPG)。

ACIリリース 5.2(4) では、DHCP リレープロバイダーの設定時の use-vrf オプションのサポートが追加されています。この機能は、DHCP プロバイダー EPG（たとえば、DHCP サーバーが接続されている EPG）または、DHCP サーバーに到達するために使用されるレイヤー 3 外部ネットワークが、DHCP 要求を開始するホストが存在するブリッジドメイン（DHCP ポリシーを DHCP リレーラベルとして参照しているブリッジドメイン）とは異なる VRF にある場合に使用されます。この機能は、NX-OS で使用可能な DHCP リレー use-vrf オプションに相当します。use-vrf オプションが DHCP リレープロバイダーに対して有効になっている場合、DHCP クライアントが配置されているリーフスイッチは、DHCP クライアントの VRF の代わりに、設定された DHCP プロバイダー EPG （または、DHCP サーバーに接続できるように設定された L3Out）の VRF を経由して、DHCP リレーパケットをルーティングします。

ACI リリース 5.2(4) より前のリリースでは、DHCP クライアントが存在する VRF とは異なる VRF の EPG またはレイヤ 3 外部ネットワークで DHCP リレープロバイダー (サーバー) を指定できます。この VRF 間リレーポリシーは、VRF 間コントラクトに依存しており、また DHCP サーバーへの到達可能性がある VRF（サーバー VRF とも呼ばれる）から DHCP クライアントが存在する VRF（クライアント VRF とも呼ばれる）への DHCP サーバーネットワークのルートリークにも依存しています。DHCP リレーパケットはクライアント VRF からルーティングされ、VRF 間ルートリークを使用して、サーバー VRF から DHCP サーバーに到達します。一部のシナリオでは、DHCP サーバーネットワークがクライアント VRF からも到達できる場合（たとえば、DHCP サーバーネットワークにも到達できるクライアント VRF にローカル L3Out がある場合）、DHCP リレーパケットがサーバー VRF をバイパスすることがあります。DHCP リレーポリシープロバイダーが、クライアント VRF の 1 つとは異なるレイヤー 3 外部ネットワークを使用するように構成されている場合、DHCP リレーパケットのソース IP アドレスは、サーバー VRF（プロバイダー L3Out とも呼ばれる）の L3Out から選択されます。。これらの DHCP リレーパケットが、サーバー VRF の L3Out ではなくクライアント VRF の L3Out からルーティングされる場合にも（クライアント VRF の L3Out が DHCP サーバーへのルートも持っている場合に生じる可能性があります）、DHCP サーバーの応答はサーバー VRF の L3Out に送り返されます。 DHCP リレーパケットの IP アドレスがサーバー VRF の L3Out の IP アドレスに設定されているためです。これにより、DHCP リレーパケットの非対称転送が発生し、ファイアウォールなどのステートフルデバイスによってドロップされる可能性があります。

次の図は、このシナリオの例を示しています。

このシナリオ例では、外部 DHCP サーバネットワークは、クライアントとサーバーの両方の VRF を介して ACI ファブリックで到達可能です。DHCP リレーパケットは、クライアント VRF からルーティングされ、クライアント VRF L3Out 経由で送信されます。DHCP リレーパケットの送信元 IP アドレスは、DHCP リレーポリシーに従って、サーバーの VRF L3Out から選択されます。サーバーからの DHCP リレー応答は DHCP サーバー L3Out にルーティングされるため、非対称フローになります。

この問題を解決するため、リリース 5.2(4) 以降では、[サーバー VRF を使用（Use Server VRF）] というオプションが、[DHCP サーバー設定（DHCP Server Preference）] フィールドで使用できるようになりました。[サーバー VRF を使用（Use Server VRF）] オプションを有効にすると、DHCP リレーパケットは常にサーバー VRF からルーティングされます。このオプションは、VRF 間コントラクトとルートリークの要件も削除します。

[DHCP サーバー設定（DHCP Server Preference）] フィールドで選択したオプションに基づいて、リーフスイッチは、DHCP リレーパケットをクライアント VRF またはサーバー VRF のどちらからルーティングするかを決定します。

[ なし（None）] : これはデフォルトのオプションで、リリース 5.2(4) より前の動作を反映しています。[なし（None）] オプションを選択すると、スイッチは常にクライアント VRF からの DHCP リレーパケットをルーティングします。VRF 間 DHCP リレーに使用する場合、サーバー VRF ネットワークをクライアント VRF にリークするには、共有サービスコントラクトが必要です。
[サーバー VRF を使用（Use Server VRF）] : このオプションは、リリース 5.2(4) で導入された新しい動作を反映しています。[サーバー VRF を使用（Use Server VRF）] オプションを選択すると、スイッチは、DHCP クライアントが存在する EPG と DHCP サーバーが存在する EPG（またはDHCP サーバーが到達可能な L3Out のレイヤー 3 外部）の間にコントラクトがあるかどうかには関わりなく、サーバー VRF からの DHCP リレーパケットをルーティングします。

VRF 間設定の場合、[サーバー VRF を使用（Use Server VRF）] オプション（[DHCP サーバープリファレンス（DHCP Server Preference）] フィールド）を選択すると、ルートルックアップのため、サーバーサブネットルートは、クライアントリーフスイッチのサーバ－ VRF 内でプログラムされます。クライアントリーフスイッチの DHCP プロセスは、それ以後、DHCP リレーパケットをサーバー VRF 経由で送信します。このため、サーバー VRF は、クライアントブリッジドメインが展開されているすべてのリーフスイッチに少なくとも 1 つの IP アドレスを使用して展開する必要があります。

GUI を使用した APIC インフラストラクチャに対する DHCP サーバポリシーの設定

この手順では、エンドポイントグループ（EPG）の DHCP リレーポリシーを展開します。

次の注意事項および制約事項を確認します。

アプリケーションエンドポイントグループで使用されるポートおよびカプセル化は、物理または VM マネージャ（VMM）ドメインに属している必要があります。ドメインにそれらの関連付けが確立されていない場合、APIC では EPG の展開を続行しますが障害が発生します。
Cisco APIC は、IPv4 と IPv6 の両方のテナントサブネットで DHCP リレーをサポートします。DHCP サーバアドレスには IPv4 または IPv6 を使用できます。DHCPv6 リレーは、ファブリックインターフェイスで IPv6 が有効になっており、1 つ以上の DHCPv6 リレーサーバが設定されている場合にのみ、発生します。
シスコ APIC では、プライマリ IP アドレスプールに対してのみ DHCP リレーをサポートしています。
次の注意事項と制約事項は、リリース 5.2(4) で導入された [DHCP サーバープリファレンス（DHCP Server Preference）] フィールドに適用されます。
- L3Out 用に DHCP リレーが設定されている場合（たとえば、DHCP サーバーが L3Out の背後にあり、DHCP リレーポリシーが [サーバー VRF を使用（Use Server VRF）] オプションに設定されている場合（[DHCP サーバープリファレンス（DHCP Server Preference）] フィールドにおいて））、EPG/サーバー VRF にインターフェイスがまだ存在しなければ、クライアントブリッジドメインが展開されているリーフスイッチへ EPG/ブリッジドメイン/ブリッジドメインサブネットを展開する必要があります。
- EPG の背後にある DHCP サーバーに対して、DHCP リレーポリシーが [サーバー VRF を使用（Use Server VRF）] オプションに設定されている場合（[DHCP サーバープリファレンス（DHCP Server Preference）] フィールド）、IPv4 および IPv6 ルートの両方と、サーバブリッジドメイン SVI がクライアントリーフスイッチに作成されます。
- [サーバー VRF を使用（Use Server VRF）] オプションは、サイト間 DHCP トラフィックではサポートされていません。
オプション 79 には、以下の制限が適用されます。
- オプション 79 は DHCPv6 でのみサポートされています。
- オプション 79 はインフラテナントではサポートされていません。

始める前に

レイヤ 2 またはレイヤ 3 管理接続が設定されていることを確認します。

手順

ステップ 1

メニューバーで、[テナント（Tenant）] > [テナント名（tenant_name）] を選択します。

ステップ 2

[ナビゲーション（Navigation）] ペインの [テナント（Tenant）] [テナント名（tenant_name）] の下で、[ポリシー（Policies）] > [プロトコル（Protocol）] > [DHCP]を展開します。

ステップ 3

[Relay Policies] を右クリックし、[Create DHCP Relay Policy] をクリックします。

ステップ 4

[Create DHCP Relay Policy] ダイアログボックスで、次の操作を実行します。

[Name] フィールドに、DHCP リレープロファイル名（DhcpRelayP）を入力します。

この名前では最大 64 文字までの英数字を使用できます。
（任意） [説明（Description）] フィールドに、DHCP リレーポリシーの説明を入力します。

説明には最大 128 文字までの英数字を使用できます。
[Providers] を展開します。

[DHCP プロバイダーの作成（Create DHCP Provider）] ダイアログボックスが表示されます。
[Create DHCP Provider] ダイアログボックスの [EPG Type] フィールドで、DHCP サーバがどこで接続されているかによって適切なオプションボタンをクリックします。
選択する EPG タイプのオプションは、EPG タイプによって異なります。
- EPG タイプとして [アプリケーション EPG（Application EPG）] を選択すると、次のオプションが [アプリケーション EPG（Application EPG）] 領域に表示されます。
  - [テナント（Tenant）] フィールドで、ドロップダウンリストから、テナントを選択します。（infra）
  - [Application Profile] フィールドで、ドロップダウンリストから、アプリケーションを選択します。（access）
  - [EPG] フィールドで、ドロップダウンリストから、EPG を選択します。（デフォルト）
- EPG タイプとして [L2 外部ネットワーク（L2 External Network）] を選択すると、[L2 外部ネットワーク領域（L2 External Network）] に次のオプションが表示されます。
  - [テナント（Tenant）] フィールドで、ドロップダウンリストから、テナントを選択します。
  - [L2 Out] フィールドで、ドロップダウンリストから [L2 Out] を選択します。
  - [External Network（外部ネットワーク）] フィールドで、ドロップダウンリストから外部ネットワークを選択します。
- EPG タイプとして [L3 外部ネットワーク（L3 External Network）] を選択すると、[L3 外部ネットワーク（L3 External Network）]領域に次のオプションが表示されます。
  - [テナント（Tenant）] フィールドで、ドロップダウンリストから、テナントを選択します。
  - [L3 Out] フィールドで、ドロップダウンリストから [L3 Out] を選択します。
  - [External Network（外部ネットワーク）] フィールドで、ドロップダウンリストから外部ネットワークを選択します。
- EPG タイプとして [DN] を選択した場合は、ターゲットエンドポイントグループの識別名を入力します。

[DHCP Server Address] フィールドに、インフラ DHCP サーバの IP アドレスを入力します。

（注）

インフラ DHCP IP アドレスは、インフラ IP アドレス APIC1 です。vShield コントローラ設定のために展開する場合は、デフォルトの IP アドレス 10.0.0.1 を入力する必要があります。

[DHCP サーバープレファレンス（DHCP Server Preference）]フィールドで、このプロバイダーの管理設定値を選択します。
[DHCP サーバープレファレンス（DHCP Server Preference）] フィールドは、リリース 5.2(4) 以降で使用できます。リーフスイッチは、このフィールドの値を基に、クライアント VRF またはサーバー VRF のどちらから DHCP リレーパケットをルーティングするかを決定します。詳細については、DHCP サーバー設定フィールドについてを参照してください。
- [ なし（None）] : これはデフォルトのオプションで、リリース 5.2(4) より前の動作を反映しています。[なし（None）] オプションを選択すると、スイッチは常にクライアント VRF からの DHCP リレーパケットをルーティングします。VRF 間 DHCP リレーに使用する場合、サーバー VRF ネットワークをクライアント VRF にリークするには、共有サービスコントラクトが必要です。
- [サーバー VRF を使用（Use Server VRF）] : このオプションは、リリース 5.2(4) で導入された新しい動作を反映しています。[サーバー VRF を使用（Use Server VRF）] オプションを選択すると、スイッチは、DHCP クライアントが存在する EPG と DHCP サーバーが存在する EPG（またはDHCP サーバーが到達可能な L3Out のレイヤー 3 外部）の間にコントラクトがあるかどうかには関わりなく、サーバー VRF からの DHCP リレーパケットをルーティングします。
  
  VRF 間設定の場合、[サーバー VRF を使用（Use Server VRF）] オプション（[DHCP サーバープリファレンス（DHCP Server Preference）] フィールド）を選択すると、ルートルックアップのため、サーバーサブネットルートは、クライアントリーフスイッチのサーバ－ VRF 内でプログラムされます。クライアントリーフスイッチの DHCP プロセスは、それ以後、DHCP リレーパケットをサーバー VRF 経由で送信します。このため、サーバー VRF は、クライアントブリッジドメインが展開されているすべてのリーフスイッチに少なくとも 1 つの IP アドレスを使用して展開する必要があります。
[OK] をクリックします。

[DHCP リレーポリシーの作成（Create DHCP Relay Policy）] ウィンドウに戻ります。
[Submit] をクリックします。

DHCP リレーポリシーが作成されます。

ステップ 5

ステップ 6

[Navigation] ペインで、[Networking] > [Bridge Domains] > [default] > [DHCP Relay Labels] を展開します。

ステップ 7

[DHCP Relay Labels] を右クリックし、[Create DHCP Relay Label] をクリックします。

ステップ 8

[Create DHCP Relay Label] ダイアログボックスで、次の操作を実行します。

[Scope] フィールドで、テナントのオプションボタンをクリックします。

このアクションにより、[Name] フィールドのドロップダウンリストに、以前に作成した DHCP リレーポリシーが表示されます。
[Name] フィールドのドロップダウンリストから、作成済みの DHCP ポリシーの名前（DhcpRelayP）を選択するか、[Create DHCP Relay Policy] を選択して新しいリレーポリシーを作成します。
[DHCP Option Policy] で、既存のオプションポリシーを選択するか、[Create DHCP Option Policy] を選択して新しいオプションポリシーを作成します。

オプション 79 を呼び出すには、ID として 79 を使用して以前に作成した DHCP オプションポリシーを選択します。

新しいオプションポリシーを作成する場合は、[DHCP オプションポリシー作成（Create DHCP Option Policy）] ウィンドウの [オプション（Options）] ペインで、ID として 79 を入力してください。
[Submit] をクリックします。

DHCP サーバがブリッジドメインに関連付けられます。

ステップ 9

[Navigation] ペインで、[Networking] > [Bridge Domains] > [default] > [DHCP Relay Labels] を展開し、作成された DHCP サーバを表示します。

REST API を使用してオプション 79 を設定する

REST API を使用して DHCP オプションポリシーのオプション 79 を設定するには：


POST URL: https://apic-ip-address/api/mo/uni.xml

<dhcpOptionPol dn="uni/tn-dhcp_client/dhcpoptpol-dhcp_option_policy" name="dhcp_option_policy" status="">
<dhcpOption data="" id="79" name="option_79"/>
</dhcpOptionPol>

NX-OS スタイル CLI を使用した APIC インフラストラクチャの DHCP サーバーポリシーの設定

アプリケーションエンドポイントグループで使用されるポートおよびカプセル化は、物理または VM マネージャ（VMM）ドメインに属している必要があります。ドメインにそれらの関連付けが確立されていない場合、APIC では EPG の展開を続行しますが障害が発生します。
Cisco APIC は、IPv4 と IPv6 の両方のテナントサブネットで DHCP リレーをサポートします。DHCP サーバアドレスには IPv4 または IPv6 を使用できます。DHCPv6 リレーは、ファブリックインターフェイスで IPv6 が有効になっており、1 つ以上の DHCPv6 リレーサーバが設定されている場合にのみ、発生します。

始める前に

DHCP サーバアドレスに到達するためにレイヤ 2 またはレイヤ 3 接続が設定されていることを確認します。

手順

APIC インフラストラクチャトラフィックの DHCP サーバポリシー設定を設定します。

例:

エンドポイントグループの DHCP リレーポリシー


apic1(config)# tenant infra
apic1(config-tenant)# template dhcp relay policy DhcpRelayP
apic1(config-tenant-template-dhcp-relay)# ip address 10.0.0.1 tenant infra application access epg default 
apic1(config-tenant-template-dhcp-relay)# exit
apic1(config-tenant)# interface bridge-domain default
apic1(config-tenant-interface)# dhcp relay policy tenant DhcpRelayP
apic1(config-tenant-interface)# exit

例:

レイヤ 3 Outside の DHCP リレーポリシー

ifav28-ifc2(config)# tenant dhcpTn
ifav28-ifc2(config-tenant)# template dhcp relay policy DhcpRelayPol
ifav28-ifc2(config-tenant-template-dhcp-relay)# ip address 11.1.1.11 tenant dhcpTn application ap epg serverEpg
ifav28-ifc2(config-tenant-template-dhcp-relay)# exit
ifav28-ifc2(config-tenant)# exit
ifav28-ifc2(config)# leaf 2001
ifav28-ifc2(config-leaf)# interface ethernet 1/4
ifav28-ifc2(config-leaf-if)# no switchport
ifav28-ifc2(config-leaf-if)# vrf member tenant dhcpTn vrf v1
ifav28-ifc2(config-leaf-if)# dhcp relay policy tenant DhcpRelayPol
ifav28-ifc2(config-leaf-if)# exit

GUI を使用した APIC インフラストラクチャ用 DHCP サーバポリシーの設定

このタスクは、vShield ドメインプロファイルを作成するユーザの前提条件です。
アプリケーションエンドポイントグループで使用されるポートおよびカプセル化は、物理または VM マネージャ（VMM）ドメインに属している必要があります。ドメインにそれらの関連付けが確立されていない場合、APIC では EPG の展開を続行しますが障害が発生します。
Cisco APIC は、IPv4 と IPv6 の両方のテナントサブネットで DHCP リレーをサポートします。DHCP サーバアドレスには IPv4 または IPv6 を使用できます。DHCPv6 リレーは、ファブリックインターフェイスで IPv6 が有効になっており、1 つ以上の DHCPv6 リレーサーバが設定されている場合にのみ、発生します。

始める前に

レイヤ 2 またはレイヤ 3 管理接続が設定されていることを確認します。

手順

インフラストラクチャテナントの DHCP サーバポリシーとして APIC を設定します。

（注）

このリレーポリシーは、接続エンティティプロファイルの設定を使用した接続されたハイパーバイザであるすべてのリーフポートにプッシュされます。接続エンティティプロファイルによる設定の詳細については、VMM ドメインプロファイルの作成に関連する例を参照してください。

例:

EPG の DHCP リレーポリシー

<!-- api/policymgr/mo/.xml -->
<polUni>

POST https://apic-ip-address/api/mo/uni.xml


  <fvTenant name="infra">

    <dhcpRelayP name="DhcpRelayP"  owner="tenant">
      <dhcpRsProv tDn="uni/tn-infra/ap-access/epg-default" addr="10.0.0.1" />
    </dhcpRelayP>
    
    <fvBD name="default">
      <dhcpLbl name="DhcpRelayP" owner="tenant"/>
    </fvBD>

  </fvTenant>
</polUni>

例:

レイヤ 3 Outside の DHCP リレーポリシー

（注）

l3extLIfP で適切な名前とオーナーを使用して DHCP リレーラベルを指定する必要があります。

<polUni>
  <fvTenant name="dhcpTn">
    <l3extOut name="Out1" >
      <l3extLNodeP name="NodeP" >
        <l3extLIfP name="Intf1">
           <dhcpLbl name="DhcpRelayPol" owner="tenant" />
       </l3extLIfP>
     </l3extLNodeP>
   </l3extOut>
 </fvTenant>
<polUni>

POST https://apic-ip-address/api/mo/uni.xml

例:

DHCP サーバープリファレンスを [サーバー VRF を使用] オプションに設定する


<!-- api/policymgr/mo/.xml -->
<polUni>

POST https://apic-ip-address/api/mo/uni.xml

<dhcpRelayP descr="" dn="uni/tn-dhcp_client/relayp-dhcp_relay_pol" status="">
    <dhcpRsProv addr="100.1.1.1/24" pref="use-server-vrf" tDn="uni/tn-dhcp_server/ap-ap_server/epg-epg_server"/>
</dhcpRelayP>

例:

DHCP サーバープリファレンスを [なし] オプションに設定する


<!-- api/policymgr/mo/.xml -->
<polUni>

POST https://apic-ip-address/api/mo/uni.xml

<dhcpRelayP descr="" dn="uni/tn-dhcp_client/relayp-dhcp_relay_pol" status="">
    <dhcpRsProv addr="100.1.1.1/24" pref="" tDn="uni/tn-dhcp_server/ap-ap_server/epg-epg_server"/>
</dhcpRelayP>

DNS サービスポリシーの設定

DNS ポリシーは、ホスト名で外部サーバ（AAA、RADIUS、vCenter、サービスなど）に接続するために必要です。DNS サービスポリシーは共有ポリシーであるため、このサービスを使用するすべてのテナントと VRF を特定の DNS プロファイルラベルで設定する必要があります。ACI ファブリックの DNS ポリシーを設定するには、次のタスクを完了する必要があります。

管理 EPG が DNS ポリシー用に設定されていることを確認してください。設定されていない場合、このポリシーはスイッチで有効になりません。

（注）

管理 EPG では、デフォルトの DNS ポリシーのみがサポートされます。

DNS プロバイダーと DNS ドメインに関する情報が含まれる DNS プロファイル（デフォルト）を作成します。
DNS プロファイル（デフォルトまたは別の DNS プロファイル）の名前を必要なテナントで DNS ラベルに関連付けます。

テナントごと、VRF ごとの DNS プロファイル設定を設定することができます。適切な DNS ラベルを使用して、追加の DNS プロファイルを作成して、特定のテナントの特定の VRF に適用できます。たとえば、名前が acme の DNS プロファイルを作成する場合、テナント設定で acme の DNS ラベルを適切な [Networking] > [VRF] ポリシー設定に追加できます。

インバンド DNS サービスポリシーによる外部宛先の設定

次のように、サービスに対して外部宛先を設定します。

ソース

インバンド管理

アウトオブバンド管理

外部サーバの場所

APIC

IP アドレスまたは完全修飾ドメイン名（FQDN）

IP アドレスまたは FQDN

Anywhere

リーフスイッチ

IP アドレス

IP アドレスまたは FQDN

（注）

DNS ポリシーは、DNS サーバの到達可能性に対するアウトオブバンド管理 EPG を指定する必要があります。

Anywhere

スパインスイッチ

IP アドレス

IP アドレスまたは FQDN

（注）

DNS ポリシーは、DNS サーバの到達可能性に対するアウトオブバンド管理 EPG を指定する必要があります。

リーフスイッチに直接接続されます

次に示すのは、外部サーバのリストです。

Call Home SMTP サーバ
Syslog サーバ
SNMP トラップの宛先
統計情報のエクスポートの宛先
エクスポートの設定の宛先
Techsupport のエクスポートの宛先
コアエクスポートの宛先

推奨されるガイドラインは次のとおりです。

外部サーバは、リーフアクセスポートに接続する必要があります。
管理ポートの追加の配線を避けるために、リーフスイッチにはインバンド接続を使用します。
スパインスイッチにはアウトオブバンド管理接続を使用します。スパインスイッチとリーフスイッチが外部サーバの同じセットに到達できるように、スパインスイッチのこのアウトオブバンドネットワークをインバンド管理の仮想ルーティングおよび転送（VRF）機能があるリーフポートの 1 つに接続します。
外部サーバには IP アドレスを使用します。

デュアルスタック IPv4 および IPv6 DNS サーバ

DNS サーバには、A レコード (IPv4) または AAAA レコード (IPv6) のプライマリ DNS レコードがあります。A および AAAA レコードは、ドメイン名を特定の IP アドレス (IPv4 または IPv6) と関連付けます。

ACI ファブリックは、IPv4 で実行する信頼できるパブリック DNS サーバを使用するように設定できます。これらのサーバは、A レコード (IPv4) または AAAA レコード (IPv6) で解決および応答できます。

純粋な IPv6 環境では、システム管理者は IPv6 DNS サーバを使用する必要があります。IPv6 DNS サーバは、/etc/resolv.conf に追加することによって有効化されます。

より一般的な環境では、デュアルスタック IPv4 および IPv6 DNS サーバを使用します。デュアルスタックの場合、IPv4 と IPv6 の両方が /etc/resolv.conf にリストされます。ただし、デュアルスタック環境で、単純に IPv6 DNS サーバをリストに追加すると、DNS 解決の大きな遅延を引き起こす可能性があります。これは、デフォルトで IPv6 プロトコルが優先されるため、IPv4 DNS サーバに接続できないためです (/etc/resolv.conf で最初にリストされている場合) 。この解決法は、IPv4 DNS サーバの前に IPv6 DNS サーバをリストすることです。また、IPv4 と IPv6 両方のルックアップで同一ソケットを使用できるようにするために、「options single-request-reopen」を追加します。

IPv6 DNS サーバが最初にリストされているデュアルスタック IPv4 および IPv6 DNS サーバの resolv.conf の例を次に示します。「single-request-reopen」オプションにも注意してください。

options single-request-reopen
nameserver 2001:4860:4680::8888
nameserver 2001:4860:4680::8844
nameserver 8.8.8.8
nameserver 8.8.4.4

デュアルスタック IPv4 および IPv6 環境

ACI ファブリックの管理ネットワークが IPv4 と IPv6 の両方をサポートする場合、Linux システムアプリケーション（glibc）では、getaddrinfo() が IPv6 を最初に返すため、IPv6 ネットワークをデフォルトで使用します。

ただし、特定の条件下では IPv4 アドレスが IPv6 アドレスよりも推奨されることがあります。Linux IPv6 スタックには、IPv6 にマッピングされた IPv4 アドレス（::ffff/96）を使用して、IPv6 アドレスとしてマッピングされた IPv4 アドレスを有効にする機能があります。これは、IPv6 対応アプリケーションが IPv4 と IPv6 両方を受け入れまたは接続するためにシングルソケットのみ使用できるようにします。これは /etc/gai.conf の getaddrinfo() の glibc IPv6 選択項目によって制御されます。

/etc/hosts を使用する場合は glibc が複数のアドレスを返すようにするために、/etc/hosts ファイルに「multi on」を追加する必要があります。追加しないと、最初に一致したものだけを返す場合があります。

アプリケーションが IPv4 と IPv6 の両方が存在するかどうかを認識していない場合、異なるアドレスファミリを使用するフォールバック試行が実行されないことがあります。このようなアプリケーションでは、フォールバックの実装が必要な場合があります。

DNS プロファイルの IPv4 または IPv6 の優先順位のポリシー

DNS プロファイルは、IPv4 と IPv6 のバージョン優先順位の選択をサポートします。ユーザインターフェイスを使用して、優先順位を有効にすることができます。IPv4 がデフォルトです。

次の例は、Postman REST API を使用したポリシーベースの設定を示します。

<?xml version="1.0" encoding="UTF-8”?>
<!— api/node/mo/uni/fabric/dnsp-default.xml —>
<dnsProfile dn="uni/fabric/dnsp-default" IPVerPreference="IPv6" childAction="" descr="" >	
</dnsProfile>

gai.conf の設定は、宛先アドレス選択を制御します。ファイルには、ラベルテーブル、優先順位テーブル、IPv4 範囲テーブルが含まれます。IPv4 または IPv6 をもう一方よりも優先付けする変更は、優先順位テーブルのエントリに含める必要があります。Linux システムで多数のフレーバーに使用されている標準ファイルの内容例を下に示します。ファイルの precedence ラベルの一行でデフォルト設定を上書きします。

次の例は、IPv4 を IPv6 よりも優先させるための gai.conf です。

# Generated by APIC
label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
precedence  ::1/128       50
precedence ::/0           40
precedence 2002::/16      30
precedence ::/96          20
# For APICs prefering IPv4 connections, change the value to 100.
precedence ::ffff:0:0/96  10

GUI を使用した DNS プロバイダーと接続するための DNS サービスポリシーの設定

始める前に

レイヤ 2 またはレイヤ 3 管理接続が設定されていることを確認します。

手順

ステップ 1	メニューバーで、[FABRIC] > [Fabric Policies] を選択します。[Navigation] ペインで、[Global Policies] > [DNS Profiles] を展開し、デフォルトの DNS プロファイルをクリックします。
ステップ 2	[Work] ペインの [Management EPG] フィールドで、ドロップダウンリストから、適切な管理 EPG （デフォルト（Out-of-Band））を選択します。
ステップ 3	[DNS Providers] を展開し、次の操作を実行します。 [Address] フィールドに、プロバイダーアドレスを入力します。 [Preferred] カラムで、優先するプロバイダーとしてこのアドレスが必要な場合は、チェックボックスをオンにします。優先するプロバイダーは 1 つだけ指定できます。 [Update] をクリックします。（任意）セカンダリ DNS プロバイダーを追加するには、[DNS Providers] を展開し、[Address] フィールドで、プロバイダーアドレスを入力します。[Update] をクリックします。
ステップ 4	[DNS Domains] を展開し、次の操作を実行します。 [Name] フィールドに、ドメイン名（cisco.com）を入力します。 [Default] カラムで、チェックボックスをオンにしてこのドメインをデフォルトドメインにします。デフォルトとして指定できるドメイン名は 1 つだけです。 [Update] をクリックします。（任意）セカンダリ DNS ドメインを追加するには、[DNS Domains] を展開します。[Address] フィールドに、セカンダリドメイン名を入力します。Update をクリックします。
ステップ 5	[送信（Submit）] をクリックします。 DNS サーバが設定されます。
ステップ 6	メニューバーで、[TENANTS] > [mgmt] をクリックします。
ステップ 7	[Navigation] ペインで、[Networking] > [VRF] > [oob] の順に展開し、[oob] をクリックします。
ステップ 8	[Work] ペインの [Properties] 下で、[DNS labels] フィールドに、適切な DNS ラベル（デフォルト）を入力します。[Submit] をクリックします。 DNS プロファイルラベルがテナントおよび VRF で設定されました。

カスタム証明書の設定のガイドライン

Cisco Application Policy Infrastructure Controller（APIC）で証明書署名要求（CSR）を生成するために使用される秘密キーのエクスポートはサポートされていません。証明書の CSR を生成するために使用された秘密キーを共有することにより、「Subject Alternative Name（SAN）」フィールドのワイルドカード（「* cisco.com」など）を介して複数のサーバで同じ証明書を使用する場合は、秘密キーを Cisco Application Centric Infrastructure（ACI）ファブリックの外部に配置し、Cisco ACI ファブリックにインポートします。
証明書署名要求（CSR）を生成する前に、公開中間証明書とルート CA 証明書をダウンロードしてインストールする必要があります。ルート CA 証明書は技術的には CSR を生成するために必要ではありませんが、シスコでは、対象とする CA 機関と CSR への署名に使用される実物の間の不一致を防ぐために、CSR を生成する前にルート CA 証明書が必要です。Cisco APIC は、送信された証明書が設定された CA によって署名されていることを確認します。
更新された証明書の生成に同じ公開キーと秘密キーを使用するには、次のガイドラインを満たす必要があります。
- 元の CSR にはキーリング内の秘密キーとペアになる公開キーが含まれているため、元の CSR を維持する必要があります。
- Cisco APIC で公開キーと秘密キーを再使用する場合は、元の証明書に使用されたものと同じ CSR を更新された証明書に再送信する必要があります。
- 更新された証明書に同じ公開キーと秘密キーを使用する場合は、元のキーリングを削除しないでください。キーリングを削除すると、CSR で使用されている関連秘密キーが自動的に削除されます。
Cisco ACI マルチサイト、VCPlugin、VRA、および SCVMM は、証明書ベースの認証ではサポートされません。
Cisco APIC クラスタごとに 1つのSSL証明書のみが許可されます。
以降のリリースからリリース 4.0(1) にダウングレードする前に、証明書ベースの認証を無効にする必要があります。
証明書ベースの認証セッションを終了するには、ログアウトして CAC カードを削除する必要があります。
Cisco APIC に設定されたカスタム証明書は、リーフスイッチとスパインスイッチに展開されます。ファブリックノードに接続するために使用される URL または DN が [サブジェクト（Subject）] または [サブジェクト代替名（Subject Alternative Name）] フィールド内にある場合、ファブリックノードは証明書でカバーされます。
Cisco APIC GUI は、最大サイズが 4k バイトの証明書を受け入れることができます。

GUI を使用した Cisco ACI HTTPS アクセス用カスタム証明書の設定

注意	ダウンタイムの可能性があるため、メンテナンス時間中にのみこのタスクを実行してください。

ダウンタイムは外部ユーザまたはシステムからの Cisco Application Policy Infrastructure Controller（APIC）APIC クラスタおよびスイッチへのアクセスには影響しますが、Cisco APIC とスイッチの接続には影響しませスイッチで実行されている NGINX プロセスのため、外部接続にも影響が及びますが、ファブリックのデータプレーンには影響ありません。Cisco APIC、設定、管理、トラブルシューティングなどへのアクセスは影響を受けることになります。Cisco APIC およびスイッチで実行されている NGINX Web サーバーは、この操作中に再起動されます。

始める前に

適切な認証局を作成できるように、信頼できる証明書を取得する機関を決定します。

手順

ステップ 1

メニューバーで、[Admin] > [AAA] の順にクリックします。

ステップ 2

[ナビゲーション（Navigation）] ペインで、[セキュリティ（Security）] を選択します。

ステップ 3

作業ペインで、[認証局（Certificate Authorities）] > [アクション（Actions）] > [認証局の作成（Create Certificate Authority）] の順に選択します。

ステップ 4

[認証局の作成（Create Certificate Authority）] 画面で、[Name（名前）] フィールドに、認証局の名前を入力します。

ステップ 5

（オプション）認証局の [説明（Description）] を入力します。

ステップ 6

[証明書チェーン（Certificate Chain）] フィールドで、Cisco APIC の証明書署名要求（CSR）に署名する認証局の中間証明書とルート証明書をコピーします。

証明書は、Base64 エンコード X.509 CER（Cisco Emergency Responder）フォーマットである必要があります。中間証明書はルート CA 証明書の前に配置されます。次の例のようになります。

-----BEGIN CERTIFICATE-----
<Intermediate Certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Root CA Certificate>
-----END CERTIFICATE-----

ステップ 7

[保存（Save）] をクリックします。

ステップ 8

作業ペインで、[キーリング（Key Rings）] > [アクション（Actions）] > [キーリングの作成（Create Key Ring）] の順に選択します。

キーリングを使用すると、以下を管理できます。

秘密キー（外部デバイスからインポートされた、またはCisco APIC で内部的に生成されたもの）。
秘密キーによって生成された CSR。
CSR を通じて署名された証明書。

ステップ 9

[Create Key Ring] ダイアログボックスで、[Name] フィールドに、名前を入力します。

ステップ 10

（オプション）キーリングの [説明（Description）] を入力します。

ステップ 11

[認証局（Certificate Authority）] フィールドで、[認証局の選択（Select Certificate Authority）] をクリックし、以前に作成した認証局を選択するか、[認証局の作成（Create Certificate Authority）] を選択します。

ステップ 12

[秘密キー（Private Key）] フィールドで必要なラジオボタンを選択します。

次のオプションがあります。

新しいキーの生成（Generate New Key）
既存キーのインポート（Import Existing Key.）

ステップ 13

秘密キーを入力します。このオプションは、[秘密キー（Private Key）]の [既存キーのインポート（Import Existing Key）] オプションを選択した場合にのみ表示されます。

ステップ 14

[秘密キー（Private Key）] フィールドで [新しいキーの生成（Generate New Key）] オプションを選択した場合は、[キータイプ（Key Type）] で必要なラジオボタンを選択します。

選択できる基準は、次のとおりです。

[RSA]（Rivest、Shamir、および Adelman）
[ECC]（楕円曲線暗号）。 ECDSA（楕円曲線デジタル署名アルゴリズム）とも呼ばれます。

ステップ 15

キーリングで Cisco APIC を使用して CSR を生成する場合は、その内容を [証明書（Certificate）] フィールドに追加しないでください。前の手順で Cisco APIC を使用せずに秘密キーおよび CSR を生成していて、CA によって署名された証明書がある場合は、その内容を [証明書（Certificate）] フィールドに追加します。

ステップ 16

暗号に必要なキー強度を選択します。このオプションは、[秘密キー（Secret Key）]で [新しいキーの生成（Generate New Key）] オプションを選択した場合にのみ表示されます。RSA の場合は [モジュラス（Modulus）] ドロップダウンリストで、ECC [キータイプ（Key Type）] の場合は [ECC カーブ（ECC Curvce）] ラジオボタンで選択します。

[キータイプ（Key Type）] で [RSA] を選択した場合は、[モジュラス（Modulus）] ドロップダウンリストからモジュラス値を選択します。
[キータイプ（Key Type）] で [ECC] を選択した場合は、[ECC 曲線（ECC Curve）] ラジオボタンのリストから適切な曲線を選択します。

ステップ 17

[保存（Save）] ( [キーリングの作成（Create Key Ring）] 画面) をクリックします。

ステップ 18

[作業（Work）]ペインで、[キーリング（Key Rings）] > [キーリング名]を選択します（または、必要なキーリングの行をダブルクリックします）。

署名付き証明書と秘密キーを入力していない場合は、[作業（Work）] ペインの [キーリング（Key Rings）] 領域で、作成されたキーリングの [管理状態（Admin State）] に [開始（Started）] と表示され、CSR が生成されるのを待ちます。手順 19 に進みます。

署名付き証明書と秘密キーの両方を入力した場合は、[キーリング（Key Rings）] 領域に、作成されたキーリングの [管理状態（Admin State）] が [完了（Completed）] と表示されます。手順 22 に進みます。

（注）

キーリングは削除しないでください。キーリングを削除すると、CSR で使用されている関連秘密キーが自動的に削除されます。

展開ボタンをクリックすると、新しい画面に選択したキーリングが表示されます。

ステップ 19

[証明書要求（Certificate Request）] ペインで、[証明書要求の作成（Create Certificate Request）] をクリックします。

[証明書要求（Certificate Request）] ウィンドウが表示されます。

[サブジェクト（Subject）] フィールドに、CSR の共通名（[CN]）を入力します。

ワイルドカードを使用して Cisco APIC の完全修飾ドメイン名（FQDN）を入力することもできますが、新しいタイプの証明書では、通常、識別可能な証明書の名前を入力し、[代替サブジェクト名（Alternate Subject Name）] フィールド（[SAN]フィールド）にすべての Cisco APIC の FQDN を入力することを推奨します（多くの最新のブラウザは、[SAN] フィールドに FQDN が入力されていることを想定しています）。
[代替サブジェクト名（Alternate Subject Name）] フィールドに、「DNS:apic1.example.com, DNS:apic2.example.com, DNS:apic3.example.com」や「DNS:*example.com」など、すべての Cisco APIC の FQDN を入力します。。
[地域（Locality）] フィールドに、組織の市または町を入力します。
[州（State）] フィールドに、組織が所在する州を入力します。
[国（Country）] フィールドに、組織の所在地の国を表す 2 文字の ISO コードを入力します。
[組織名（Organization Name）] を入力し、[組織単位名（ Organization Unit Name）] に単位を入力します。
組織の連絡担当者の [電子メール（Email）] アドレスを入力します。
[パスワード（Password）] に入力し、[パスワードの確認（Confirm Password）] フィールドにもう一度入力します。
[OK] をクリックします。

ステップ 20

[証明書要求の設定（ Certificate Request Settings）] ペインに、上で入力した情報が表示されます（手順 19）。

ステップ 21

[作業（Work）]ペインで、[キーリング（Key Rings）] > [キーリング名]を選択します（または、必要なキーリングの行をダブルクリックします）。

新しい画面に選択したキーリングが表示されます。

（注）

キーリングに示されている認証局によって署名されていない CSR、または MS-DOS 形式の行末を持つ CSR は受け入れられません。エラーメッセージが表示されたら、MS-DOS の行末を削除して解決します。

キーが正常に確認されて、[作業（Work）] ペインの [管理状態（Admin State）] が [完了済み（Completed）] に変わり、HTTP ポリシーで使用できるようになります。

ステップ 22

メニューバーで、[ファブリック（Fabric）] > [ファブリックポリシー（Fabric Policies）]を選択します。

ステップ 23

[ナビゲーション（Navigation）] ペインで、[ポリシー（ Policies）] > [ポッド（Pod）] > [管理アクセス（Management Access）] > [デフォルト（default）] をクリックします。

ステップ 24

[Work] ペインの [Admin Key Ring] ドロップダウンリストで目的のキーリングを選択します。

ステップ 25

（オプション）証明書ベースの認証では、[Client Certificate TP] ドロップダウンリストで、以前に作成したローカルユーザポリシーを選択し、[Client Certificate Authentication state] の [Enabled] をクリックします。

ステップ 26

[Submit] をクリックします。

すべての Web サーバーがリスタートし、証明書がアクティブになり、デフォルト以外のキーリングは HTTPS アクセスに関連付けられます。

次のタスク

証明書の失効日には注意し、期限切れになる前に必要な措置を取ってください。更新された証明書に同じキーペアを保持するには、CSR を保持します。CSR にはキーリング内の秘密キーとペアになる公開キーが含まれています。証明書が期限切れになる前に、同じ CSR を再送信してください。削除したり、新しいキーリングを作成したりしないでください。キーリングを削除すると、 Cisco APICに保存されている秘密キーが削除されます。

APIC インバンドまたはアウトオブバンド接続設定 (preferences) の設定

このトピックでは、APIC サーバ認証サーバまたは ACI ファブリックに外部 SNMP サーバなどのデバイスの管理アクセスのインバンドおよびアウトオブバンド接続の間で切り替える方法について説明します。有効化インバンド ACI ファブリックのリーフスイッチからの外部デバイスに APIC サーバ間のインバンド管理接続を実行します。有効化 ooband ACI ファブリックに外部接続の外部デバイスに APIC サーバ間のアウトオブバンド管理接続を実行します。

始める前に

インバウンドおよびアウトバウンド管理ネットワークを構成します。詳細については、「管理」 (『Cisco APIC 基本設定ガイド、リリース 3.x』) を参照してください。

手順

ステップ 1	メニューバーで、 System > System Settings の順にクリックします。
ステップ 2	ナビゲーションバーで、をクリックして APIC 接続設定 (preferences) 。
ステップ 3	ポリシーを有効にするにはクリックしてインバンドまたは ooband 。
ステップ 4	[Submit] をクリックします。

クォータ管理ポリシーの設定

Application Policy Infrastructure Controller (APIC) リリース 2.3(1) 移行から、テナント管理者が設定できるオブジェクトの数に制限が設けられました。これにより、管理者は、テナントを超えてグローバルに追加される管理対象オブジェクトの数を制限できるようになりました。

この機能は、テナントまたはテナントのグループが、リーフごと、またはファブリックごとの ACI の最大数を超えないようにする点で、または利用可能なリソースの大部分を不当に消費して、同じファブリックの他のテナントに影響を及ぼすことがないようにする点で役立ちます。

手順

ステップ 1	メニューバーで、System > System Settings をクリックします。
ステップ 2	Quota を右クリックして、Create Quota Configuration を選択します。
ステップ 3	Class フィールドで、クォータによる制限を掛けるオブジェクトのタイプを選択します。
ステップ 4	Container Dn フィールドに、クラスを説明する識別名 (DN) を入力します。
ステップ 5	Exceed Action フィールドで、Fail Transaction Action または Raise Fault Action を選択します。
ステップ 6	Max Number フィールドで、作成できる管理対象オブジェクトの最大数を入力します。これを超えると、超過アクションが適用されることになります。
ステップ 7	[Submit] をクリックします。

適用 BD 例外リストの作成

このトピックでは、適用対象のブリッジドメインには従わない、サブネットのグローバルな例外リストの作成方法について説明します。適用 BD の機能を設定している場合、対象のエンドポイントグループ (EPG) が ping を送信できるのは、関連付けられたブリッジドメイン内のサブネットゲートウェイだけです。

例外 IP アドレスは、すべての VRF のすべての BD ゲートウェイに ping を送信できます。

L3Out 用に設定されたループバックインターフェイスでは、対象のループバックインターフェイスに合わせて設定された IP アドレスへの到達可能性は適用されません。

EBGP ピアとなる IP アドレスが、L3Out インターフェイスのサブネットとは異なるサブネットに存在している場合には、許容例外サブネットにピアサブネットを追加する必要があります。そうしないと、送信元 IP アドレスが L3Out インターフェイスのサブネットとは異なるサブネットに存在するため、eBGP トラフィックがブロックされます。

始める前に

適用対象のブリッジドメイン (BD) を作成します。

手順

ステップ 1	メニューバーで、System > System Settings を選択します。
ステップ 2	BD Enforced Exception List をクリックします。
ステップ 3	Exception List の [+] をクリックします。
ステップ 4	任意のサブネットゲートウェイに ping を送信できるサブネットの IP アドレスとネットワークマスクを追加します。
ステップ 5	これを繰り返して、適用ブリッジドメインの例外となるサブネットを追加します。
ステップ 6	[Submit] をクリックします。

BGP ルータリフレクタポリシーとルートリフレクタノードエンドポイントの作成

このトピックでは、ACI ファブリックルートリフレクタを作成する方法について説明します。リフレクタは、ファブリック内で外部ルートを配布するために、マルチプロトコル BGP (MP-BGP) を使用します。ACI ファブリックでルートリフレクタをイネーブルにするには、ファブリックの管理者がルートリフレクタになるスパインスイッチを選択して、自律システム（AS）番号を提供する必要があります。ルートリフレクタが ACI ファブリックで有効になれば、管理者は、外部ネットワークへの接続を設定できます。

始める前に

必須項目：

ACI ファブリックに外部ルータを接続するには、ファブリックインフラストラクチャの管理者がボーダーゲートウェイプロトコル（BGP）のルートリフレクタとしてスパインノードを設定するひつようがあります。
冗長性のために、複数のスパインがルータリフレクタノードとして設定されます（1 台のプライマリリフレクタと 1 台のセカンダリリフレクタ）。

手順

ステップ 1

BGP ルートリフレクタポリシーを作成するには、次の手順を実行します:

メニューバーで、System > System Settings をックリックします。
BGP Route Reflector をクリックします。
入力自律システム番号を入力します。
Route Reflector Nodes で [+] をクリックします。
スパインルートリフレクタノードの ID エンドポイントを入力し、Submit をクリックします。

ステップ 2

外部ルートリフレクタノードのエンドポイントを作成するには、次の手順に従います:

External Route Reflector Nodes で [+] をクリックします。
外部ルートリフレクタノードのエンドポイントとして機能するスパインを選択します。
これがマルチサイトによって管理されるサイトである場合には、インターサイトスパインルートリフレクタも指定できます。
[Submit] をクリックします。

ファブリック全体のコントロールプレーンの MTU ポリシーを設定する

このトピックでは、ファブリック全体のコントロールプレーン（CP）の MTU ポリシーを作成する方法について説明します。これは、ファブリックのノード（スイッチ）から送信されたコントロールプレーンパケットのグローバル MTU サイズを設定します。

マルチポッドトポロジでは、ファブリック外部ポートの MTU 設定は、CP MTU の値セット以上である必要があります。そうしないと、ファブリックの外部ポートが CP MTU パケットをドロップする可能性があります。

（注）

MTU を IPN から継承する L3Out インターフェイスプロファイルを設定するには 9150 にします。IPN 全体で使用される MTU を 2916 に構成する必要がある場合には、L3Out インターフェイスプロファイル内で明示的に構成する必要があります（[テナント（Tenants）] > tenant-name > [ネットワーキング（Networking）] > [外部ルートネットワーク（External Routed Networks）] > [外のネットワークを作成（Create Routed Outside）] > [ノードとインターフェイスプロトコルプロファイル（Nodes and Interface Protocol Profiles）] > [ノードプロファイルを作成（Create Node Profile）] > [インターフェイスプロファイルを作成（Create Interface Profile）] で構成します）。
Cisco APIC は、CP-MTU 設定に関係なく、常に 1496 バイト（TCP MSS 1456）の MTU でファブリックスイッチへの TCP 接続を確立します。リモートポッドおよびリモートリーフスイッチの IPN ネットワークは、ファブリックディスカバリのために少なくとも 1500 バイトの MTU をサポートする必要があります。

IPN または CP MTU を変更する場合、Cisco では CP MTU 値を変更し、次にリモートポッドのスパイン上の MTU 値を変更することをお勧めします。これで、MTU の不一致によりポッド間の接続が失われるリスクが減少します。

手順

ステップ 1	メニューバーで、System > System Settings をックリックします。
ステップ 2	Control Plane MTU をクリックします。
ステップ 3	ファブリックポートの MTU を入力します。
ステップ 4	[Submit] をクリックします。

エンドポイントループ保護の設定

エンドポイントのループ保護ポリシーでは、頻繁な MAC の移動を処理することによる、ループ検出の方法を指定します。EP ループ保護を設定するには、次の手順を実行します:

手順

ステップ 1	メニューバーで、System > System Settings を選択します。
ステップ 2	をクリックしてエンドポイントコントロール。
ステップ 3	Ep Loop Protection タブをクリックします。
ステップ 4	ポリシーを有効にするには、Enabled をクリックします (Administrative State フィールドにあります) 。
ステップ 5	オプション。ループを検出の間隔を設定します。これはループを検出するための時間を指定します。指定できる範囲は 30～ 300 秒です。デフォルトの設定は 60 秒です。
ステップ 6	ループ検出乗算係数を設定します。これは、ループ検出間隔内で単一の EP がポート間を移動した回数です。範囲は 1 ～ 255 です。デフォルトは 4 です。
ステップ 7	ループを検出したときに実行するアクションを選択します。アクションとしては、次のものがあります: BD Learn Disable Port Disable デフォルトは Port Disable です。
ステップ 8	[Submit] をクリックします。

不正なエンドポイントの制御ポリシーについて

不正なエンドポイントは、リーフスイッチを頻繁に攻撃し、異なるリーフスイッチポートにパケットを繰り返し挿入し、802.1Q タグを変更する（エンドポイントの移動をエミュレートする）ことで、学習されたクラスと EPG ポートを変更します。誤設定により頻繁に IP アドレスと MAC アドレスが変更 (移動する) されることになります。

ファブリックの急速な移動などで、大きなネットワークの不安定状態、高い CPU 使用率、まれなケースでは、大量かつ長期のメッセージおよびトランザクションサービス (MTS) バッファ消費のため、エンドポイントマッパー (EPM) および EPM クライアント (EPMC) がクラッシュすることになります。また、このような頻繁な移動により、EPM および EPMC ログが非常にすばやくロールオーバーされ、無関係なエンドポイントのデバッグを妨害する可能性があります。

不正なエンドポイントの制御機能は脆弱性にすばやく対処します。

急速に移動する MAC および IP エンドポイントの特定。
エンドポイントを一時的に静的にして、エンドポイントを隔離することによって移動を停止します。
3.2(6) リリースより前：不正 EP 検出間隔のエンドポイントを静的に維持し、不正エンドポイントとの間のトラフィックをドロップします。この時間が経過すると、不正な MAC アドレスまたは IP アドレスが削除されます。
3.2(6) リリース以降：不正な EP 検出間隔のエンドポイントを静的に維持（この機能はトラフィックをドロップしなくなりました）。この時間が経過すると、不正な MAC アドレスまたは IP アドレスが削除されます。
ホストトラッキングパケットを生成して、影響を受ける MAC または IP アドレスをシステムが再学習できるようにします。
修正アクションを有効にするための障害の発生。

不正なエンドポイント制御ポリシーはグローバルに設定されており、他のループ防止方法とは異なり、個々のエンドポイントレベルの機能です (IP および MAC アドレス) 。ローカルまたはリモートの移動を区別していません。いかなる種類のインターフェイスの変更も、エンドポイントを隔離する必要があるかどうかを決定する際に移動と見なされます。

不正なエンドポイント制御機能は、デフォルトで無効になっています。

不正エンドポイント制御ポリシーの制限事項

不正エンドポイント制御ポリシーを使用する際には、次の制限が適用されます:

不正エンドポイント制御ポリシーのパラメータを変更しても、既存の不正エンドポイントには影響しません。
不正エンドポイントが有効になっていても、ループ検出とブリッジドメイン移動頻度は有効になりません。
不正エンドポイント機能を無効にすると、すべての不正エンドポイントがクリアされます。
エンドポイントマッパー (EPM) の値は、不正エンドポイントのパラメータに制限を課します。この範囲外のパラメータ値を設定すると、Cisco APIC 適切でないパラメータごとにエラーが発生します。
不正エンドポイント検出のサポートは、リモートリーフノードに接続されているエンドポイントではなく、ファブリックに接続されているエンドポイントに限定されます。
不正なエンドポイント機能は、Cisco ACI マルチサイト展開の各サイト内で使用でき、サイト内でエンドポイントを移動させるサーバの設定ミスに役立ちます。不正エンドポイント機能は、エンドポイントがサイト間を移動する可能性があるシナリオ向けには設計されていません。
Cisco APIC リリース 4.1 にアップグレードする前に、不正エンドポイント制御を無効にする必要があります。

GUI を使用した不正エンドポイント制御ポリシーの設定

Cisco Application Policy Infrastructure Controller（Cisco APIC）GUI を使用して、不正なエンドポイントを検出して削除するようにファブリックの不正 EP 制御ポリシーを設定できます。このトピックには、アドホックのリーフスイッチで不正なエンドポイントをクリアする手順も含まれています。

手順

ステップ 1	メニューバーで、System > System Settings を選択します。
ステップ 2	ナビゲーションウィンドウで、[エンドポイント制御（Endpoint Controls）] を選択します。
ステップ 3	[ナビゲーション（Navigation）] ペインで、[不正な EP 制御（Rogue EP Control）] タブを選択します。
ステップ 4	[Administrative State] を [Enabled] に設定します。
ステップ 5	[不正な EP 検出間隔（Rogue EP Detection Interval）]、[不正な EP 検出倍数係数（Rogue EP Detection Multiplication Factor）]、および [保持間隔（秒）（Hold Interval (sec)）] を目的の値に設定します。不正な EP 検出間隔：不正エンドポイントの検出間隔を設定します。これは、不正エンドポイントを検出する時間を指定します。有効な値は 0 ～ 65535 秒です。デフォルトは 60 です。不正な EP 検出倍数係数：エンドポイントが不正かどうかを判断するための不正エンドポイント検出の乗数を設定します。エンドポイントがこの数よりも多く移動すると、エンドポイント検出間隔内で、エンドポイントは不正と宣言されます。有効値は 2 ～ 10 です。デフォルト値は 6 です。保持間隔（秒）：エンドポイントが不正であると宣言されてからの間隔（秒単位）。学習が防止され、不正なエンドポイントとの間のトラフィックがドロップされます。このインターバルが経過すると、エンドポイントは削除されます。5.2(3) リリースより前では、有効な値は 1800 〜 3600 秒です。5.2(3) リリースより前では、有効な値は 1800 〜 3600 秒です。デフォルト値は 1800 です。
ステップ 6	（任意）リーフスイッチの不正なエンドポイントをクリアするには、次の手順を実行します。 Cisco APICメニューバーで、[Fabric] > [Inventory] の順にクリックします。ナビゲーションバーで、[Pod] を展開し、不正なエンドポイントをクリアするリーフスイッチをクリックします。リーフスイッチサマリが作業ウィンドウに表示されたら、ナビゲーションバーのリーフスイッチ名を右クリックし、[Clear Rogue Endpoints] を選択します。 [はい（Yes）] をクリックします。

NX-OS スタイル CLI を使用している不正エンドポイント制御ポリシーの設定

NX-OS スタイルの CLI を使用して、不正なエンドポイントを検出および削除するように、ファブリックの不正エンドポイント制御ポリシーを設定できます。

手順

ステップ 1	グローバルコンフィギュレーションモードに入ります。例: `apic1# configure`
ステップ 2	グローバルな不正エンドポイント制御ポリシーを有効にします。例: `apic1(config)# endpoint rogue-detect enable`
ステップ 3	ホールド間隔を設定します。保持間隔は、エンドポイントが不正であると宣言されてからエンドポイントが静的に保たれ、学習が防止され、エンドポイントとの間のトラフィックがドロップされた後の期間（秒）です。このインターバルが経過すると、エンドポイントは削除されます。リリース 5.2(2) 以前では、有効な値は 1800 ～ 3600 秒です。リリース 5.2(3) 以降では、有効な値は 300 ～ 3600 秒です。デフォルト値は 1800 です。例: `apic1(config)# endpoint rogue-detect hold-interval 1800`
ステップ 4	検出間隔を設定します。検出間隔は、不正エンドポイント制御がエンドポイントの移動数をカウントしている間の期間（秒）です。この間隔の中のカウントが検出乗算係数で指定された値を超える場合、エンドポイントは不正であると宣言されます。有効な値は 0 ～ 65535 秒です。デフォルトは 60 です。例: `apic1(config)# endpoint rogue-detect interval 60`
ステップ 5	検出倍率を設定します。エンドポイントが、検出間隔で指定された期間中に検出倍率で指定された値よりも多く移動した場合、エンドポイントは不正であると宣言されます。有効値は 2 ～ 10 です。デフォルト値は 6 です。例: `apic1# endpoint rogue-detect factor 6`

不正/ COOP 例外リストについて

不正/ COOP 例外リストを使用すると、エンドポイントが不正としてマークされる前に、不正エンドポイント制御によるエンドポイント移動の許容度を高くするエンドポイントの MAC アドレスを指定できます。不正/ COOP 例外リストのエンドポイントは、10 分以内に 3000 回以上移動した場合にのみ不正としてマークされます。エンドポイントが不正としてマークされた後、学習を防ぐためにエンドポイントは静的なままになります。不正エンドポイントは 30 秒後に削除されます。

Cisco Application Policy Infrastructure Controller（ APIC）6.0（3）リリース以降では、グローバルな不正/COOP 例外リストを作成できます。このリストは、MAC アドレスが見つかるブリッジドメイン上の全ての不正エンドポイントコントロールから MAC アドレスを除外します。そして、L3Outs の不正 /COOP 例外リストを作成できます。ブリッジドメインまたは L3Out のすべての MAC アドレスを除外することもできます。これにより、すべての MAC アドレスに対して例外を作成する場合に例外リストを簡単に作成できます。各アドレスを個別に入力する必要はありません。

不正/ COOP 例外リストのガイドラインと制限事項

不正/COOP 例外リストを使用するとき、次の注意事項と制限事項が適用されます。

MAC アドレス例外リスト機能は、レイヤ 2 ブリッジドメイン（IP ルーティングが有効になっていないブリッジドメイン）で動作します。これは、レイヤ 3 ブリッジドメイン（IP ルーティングが有効になっているブリッジドメイン）では、MAC アドレスとともに移動する IP アドレスがあった場合、最初に IP アドレスが放浪しているとしてマークされ、その後 IP アドレスと MAC アドレスの両方が検疫対象とされるためです。
レイヤ 3 ブリッジドメインの場合、放浪エンドポイント制御から除外する特定の IP アドレスについては、サブネットごとのデータプレーン IP アドレス学習を無効にします。

サブネットごとのデータプレーン IP アドレス学習機能については、Cisco APIC Layer 3 ネットワーキング設定ガイドを参照してください。
このリストに追加されている MAC アドレスの種類を完全に理解している必要があります。このリスト内の MAC アドレスが、ファブリック全体または、リーフスイッチごとでの過剰な移動に寄与しないようにすることは、ユーザーの責任です。
ブリッジドメインごとの例外リストには、ファブリック全体で最大 100 個の MAC アドレスを追加できます。6.0（3）リリース以降では、特定のブリッジドメインのすべての MAC アドレスを不正なエンドポイント制御から除外することもできます。
6.0（3）リリース以降、ファブリック全体で 100 個の外部 L3Out MAC アドレスを例外リストに追加できます。また、L3Out SVI ブリッジドメインのすべての MAC アドレスを不正なエンドポイント制御から除外することもできます。
6.0（3）リリース以降、それらの MAC アドレスのエンドポイントの合計数が 6,000 以内であれば、最大 6,000 個の MAC アドレスをグローバル例外リストに追加できます。複数のブリッジドメインで検出された同じ MAC アドレスは、合計 6,000 のエンドポイントに対して、同じ数のブリッジドメインとしてカウントされます。たとえば、構成された MAC アドレスが 10 のブリッジドメインで検出された MAC エンドポイントとして表示される場合、MAC アドレスは 10 のエンドポイントとしてカウントされます。
リーフスイッチの例外リストの免除は、放浪エンドポイント制御が有効になっている場合にのみ適用されます。放浪エンドポイント制御が無効になっている場合、MAC アドレス例外リストは、COOP ダンプニングでのみ使用されます。
不正/ COOP 例外リストには、ブリッジドメインの MAC アドレスのみを含めることができ、VRF インスタンスの IP アドレスは含めることができません。ただし、IP アドレスのみの移動では、IP アドレスが通常の不正エンドポイント制御基準を満たす場合でも、IP アドレスが不正としてマークされる可能性があります。
データパストラフィックに基づいて IP アドレスの不正検出およびマーキングをマスクするには、ブリッジドメインサブネット学習無効を使用します。ブリッジドメインサブネットラーニング無効化は、移動するたびに Cisco ACI が IP アドレスの場所を学習しなくなります。

GUI を使用したブリッジドメイン作成時の不正/ COOP 例外リストの設定

次の手順では、ブリッジドメインの作成時に不正/ COOP 例外リストを設定します。

始める前に

ブリッジドメインを作成するテナントが必要です。
不正エンドポイント制御を有効にする必要があります。不正エンドポイント制御を有効にする手順については、GUI を使用した不正エンドポイント制御ポリシーの設定を参照してください。

手順

ステップ 1	目的のテナントで、ブリッジドメインを作成します。メニューバーで、[テナント（Tenants）] > `[tenant_name]`を選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[ネットワーキング（Networking）] > [ブリッジドメイン（Bridge Domains）] の順に選択します。
ステップ 3	Bridge Domains を右クリックして、Create Bridge Domain を選択します。
ステップ 4	[ブリッジドメインの作成（Create Bridge Domain）] ダイアログで、[ステップ 1（STEP 1）] の [メイン（MAIN）] および [ステップ 2（STEP 2）] の [L3 設定（L3 Configurations）] に必要なフィールドに入力します。
ステップ 5	[STEP 3（ステップ 3）] の [アドバンスト/トラブルシューティング（Advanced / Troubleshooting）] で、[不正/COOP 例外リスト（Rogue / Coop Exception List）] の [+] をクリックし、リストに追加するエンドポイントの MAC アドレスを入力して、[更新（Update）] をクリックします。 MAC アドレスの形式は `AA:BB:CC:DD:EE:FF` です。リストに追加するエンドポイントごとにこのステップを繰り返します。
ステップ 6	（オプション）：Cisco Application Policy Infrastructure Controller（APIC）6.0（3）リリース以降、ブリッジドメインからの MAC アドレスを無視するために不正エンドポイントコントロール BD の不正例外 MAC を有効化チェックボックスをチェックします。
ステップ 7	必要に応じて、[ステップ 3（STEP 3）] > [アドバンスト/トラブルシューティング（Advanced/Troubleshooting）] の残りのフィールドに入力します。
ステップ 8	[完了（Finish）] をクリックします。

GUI を使用した既存のブリッジドメインの不正/ COOP 例外リストの設定

次の手順では、既存のブリッジドメインの不正/ COOP 例外リストを設定します。

始める前に

ブリッジドメインを持つテナントが必要です。
不正エンドポイント制御を有効にする必要があります。不正エンドポイント制御を有効にする手順については、GUI を使用した不正エンドポイント制御ポリシーの設定を参照してください。

手順

ステップ 1	メニューバーで、[テナント（Tenants）] > `[tenant_name]`を選択します。
ステップ 2	[ナビゲーション（Navigation）] ウィドウで、[ネットワーキング（Networking）] > [ブリッジドメイン（Bridge Domains）] > `[bridge_domain_name]`. を選択します。
ステップ 3	[作業（Work）] ペインで、[ポリシー（Policy）] > [アドバンスト/トラブルシューティング（Advanced/Troubleshooting）] を選択します。
ステップ 4	[不正/COOP 例外リスト（Rogue / Coop Exception List）] で [+] をクリックし、リストに追加するエンドポイントの MAC アドレスを入力して、[更新（Update）] をクリックします。 MAC アドレスの形式は `AA:BB:CC:DD:EE:FF` です。リストに追加するエンドポイントごとにこのステップを繰り返します。
ステップ 5	（オプション）：Cisco Application Policy Infrastructure Controller（APIC）6.0（3）リリース以降、ブリッジドメインからの MAC アドレスを無視するために不正エンドポイントコントロール BD の不正例外 MAC を有効化チェックボックスをチェックします。
ステップ 6	[Submit] をクリックします。

GUI を使用した L3Out SVI の不正エンドポイント制御の例外リストの構成

このセクションの手順では、L3Out の選択されたスイッチ仮想インターフェイス（SVI）について、不正なエンドポイント制御機能が無視する MAC アドレスを設定します。

始める前に

L3Out を持つテナントが必要です。
不正エンドポイント制御を有効にする必要があります。不正エンドポイント制御を有効にする手順については、GUI を使用した不正エンドポイント制御ポリシーの設定を参照してください。

手順

ステップ 1	メニューバーで、[テナント（Tenants）] > `[tenant_name]`を選択します。
ステップ 2	ナビゲーションウィンドウで[ネットワーキング（Networking）] > [L3Outs] > `[L3Out_name]` > [ロジカルノードブロファイル（Logical Node Profiles）] > `[node_profile_name]` > [ロジカルインターフェイスプロファイル（Logical Interface Profiles）] > `[interface_profile_name]`を選択します。
ステップ 3	ワークペインで、[ポリシー（Policy）] > SVIを選択します。
ステップ 4	SVI テーブルで、[+] をクリックします。
ステップ 5	[SVIを選択（Select SVI）] ダイアログ内でいずれかの次のアクションを実行します： [不正除外 MAC グループ（Rogue Exception MAC Group）] で、既存のグループを選択するか、新しいグループを作成します。不正例外 MAC グループは、同じ VLAN カプセル化を持つすべての SVI について、不正エンドポイント制御機能が無視する MAC アドレスを指定します。 [不正 EP コントロールからの MAC を全て除外します（Exclude all MACs from Rogue EP Control）] ボックスをチェックします。このオプションを有効にすると、不正エンドポイント制御機能は、同じ VLAN カプセル化を持つすべての SVI のすべての MAC アドレスを無視します。
ステップ 6	目的に応じて、残りのフィールドに入力します。
ステップ 7	[Submit] をクリックします。

GUI を使用したファブリックの不正エンドポイント制御の MAC アドレス例外を構成

6.0（3）リリース以降、ファブリックレベルで、不正なエンドポイント制御が無視する MAC アドレスを設定できます。不正エンドポイント制御は、MAC アドレスが属するブリッジドミアンまたは L3Out SVI に関係なく、指定した MAC アドレスを無視します。

始める前に

不正エンドポイント制御を有効にする必要があります。不正エンドポイント制御を有効にする手順については、GUI を使用した不正エンドポイント制御ポリシーの設定を参照してください。

手順

ステップ 1

メニューバーで、[ファブリック（Fabric）] > [ファブリックポリシー（Fabric Policies）]を選択します。

ステップ 2

[ナビゲーション（Navigation）]ペインで、 > [ポリシー（Policies）] > [ファブリックワイルドカード不正例外（Fabric Wildcard Rogue Exception）]を選択します。

ステップ 3

[ワーク（Work）] ペインの [ファブリックワイルドカード不正例外（Fabric Wildcard Rogue Exception）] テーブルで、[+] をクリックします。

無視する不正エンドポイント制御の MAC アドレスを入力し、[更新（Update）] をクリックします。
不正なエンドポイント制御で無視する MAC アドレスごとに、この手順を繰り返します。

最大 IP アドレスフロー制御について

3.2(6) リリースでは、最大IPアドレスフロー制御機能が追加されています。これは、エンドポイントの動作不良を識別し、MAC アドレスに関連付けられている学習 IP アドレスの数に基づいて不正としてフラグを立てます。Cisco Application Centric Infrastructure（ACI）ファブリックは、MAC アドレスで最大 4,096 個の IP アドレスをサポートします。リーフスイッチが MAC アドレスに関連付けられた 4,096 を超える IP アドレスを学習した場合、MAC アドレスとすべての IP アドレスが不正として分類されます。

最大 IP アドレスフロー制御機能がエンドポイントを不正として識別した後、エンドポイントは隔離され、APIC で障害が発生し、このエンドポイントで新しい IP アドレスの学習は行われません。隔離期間は 1 時間です。標準の不正機能が有効になっている場合、隔離期間は標準の不正設定で設定された期間と同じです。

不正なエンドポイント制御ポリシー機能（移動による不正）は有効または無効に設定できますが、最大 IP アドレスフロー制御機能では明示的な設定を有効にする必要はありません。

この機能が導入される前は、設定可能な期間内に設定された回数だけロケーションを移動し続けた場合、ACI ファブリックはエンドポイントを不正と識別していました。この機能を使用すると、ACI ファブリックは、移動の数に基づいて、または MAC アドレスで 4,096 を超える IP アドレスを学習した場合に、エンドポイントを不正として識別できます。

COOP の設定

COOP について

Council of Oracle Protocol（COOP）は、スパインスイッチプロキシにマッピング情報（場所と ID）を通信するために使用されます。リーフスイッチ（「citizen」）は、ゼロメッセージキュー（ZMQ）を使用して、エンドポイントアドレス情報をスパインスイッチ（「oracle」）に転送します。スパインノードで実行している COOP によって、すべてのスパインノードが一貫性のあるエンドポイントアドレスとロケーション情報のコピーを維持することができ、さらに、ロケーションマッピングデータベースに対するエンドポイント ID の分散ハッシュテーブル（DHT）レポジトリを維持することができます。

COOP エンドポイントのダンプニング

悪意のある動作または誤った動作によって不要なエンドポイント更新が発生すると、COOP プロセスが過負荷になり、有効なエンドポイント更新の処理が妨げられる可能性があります。リーフスイッチの不正エンドポイント検出機能により、多数の誤った更新がスパインスイッチに到達するのを防ぐことができます。不正なエンドポイントの検出が不十分な場合、COOP プロセスはエンドポイントのダンプニングを呼び出します。COOP の負荷を軽減するために、スパインスイッチはすべてのリーフスイッチに、指定された期間、不正な動作をしているエンドポイントからの更新を無視するように要求します。これが発生すると、エンドポイントのダンプニング状態は「フリーズ」になり、障害が生成されます。

（注）

COOP エンドポイントダンプニングは、Cisco Application Policy Infrastructure Controller（APIC）リリース 4.2(3) で導入され、デフォルトで有効になっています。

検出基準は、次の表に示すように、エンドポイント関連イベントのタイプに基づくペナルティ値の計算に基づきます。


イベント（Event）	ペナルティ値	注
新しい IP アドレスを確認する	0	新しい IP アドレスが学習されます。
追加の IP アドレスを確認する	2	追加の IP アドレスは、既存のエンドポイントの MAC アドレスで学習されます。
IP アドレスの削除	50	リモートエンドポイントの IP アドレスは、IP アドレスが学習されると削除されます。
削除された IP アドレスを確認する	50	IP アドレスが削除された後のリモートエンドポイントの IP アドレスを確認します。
IP アドレスの削除	400	IP アドレスが学習されたら、ローカルエンドポイントの IP アドレスを削除します。
削除された IP アドレスを確認する	400	IP アドレスが削除された後のローカルエンドポイント IP アドレスを確認します。
エンドポイントの移動	200	エンドポイントが別のインターフェイスに移動します。
IP アドレスの移動	200	IP アドレスが別の MAC アドレスに移動する。このイベントでは、BGP へのルート更新が 2 回発生するため、ペナルティは高くなります。
URIB プログラミング	50	エンドポイントのスパインスイッチトンネルインターフェイスのステータス変更（アップ/ダウン）。

ペナルティ値は IP アドレスごとに計算され、5 分ごとに 50％ずつ減少します。たとえば、エンドポイントのペナルティ値が 4000 で、エンドポイントの IP アドレスの数が 2 の場合、IP アドレスあたりのペナルティ値は 4000/2 = 2000 です。IP アドレスあたりのペナルティ値がクリティカルしきい値（4000）を超えると、エンドポイントの状態が [標準（Normal）] から [クリティカル（Critical）] に変更されます。エンドポイントが 5 分を超えて [クリティカル（Critical）] 状態になっている場合、または IP アドレスあたりのペナルティ値がフリーズしきい値（10000）を超えている場合、エンドポイントの状態はフリーズ（ダンプニング）になり、エンドポイントの更新は無視されます。IPアドレスあたりのペナルティ値が再利用しきい値（2500）を下回ると、エンドポイントの状態は Normal（非ダンプニング）になります。ペナルティ値を 75％（10000 * 0.5 * 0.5 = 2500）減らすには、10 分経過する必要があります。しきい値はユーザが設定することはできません。

COOP 認証

COOP データパス通信は、セキュアな接続を介した転送を優先します。悪意のあるトラフィックインジェクションから COOP メッセージを保護するために、Cisco APIC およびスイッチは COOP プロトコル認証をサポートしています。

COOP プロトコルは、次の 2 つの ZMQ 認証モードをサポートしています。

厳密モード： COOP では、MD5 認証 ZMQ 接続のみ許可します。
互換性モード：COOP ではメッセージの転送に MD5 認証接続と非認証 ZMQ 接続の両方を許可します。

COOP 認証の詳細については、『Cisco APIC セキュリティ設定ガイド』を参照してください。

GUI を使用した COOP 減衰エンドポイントの表示

スパインノードのすべての減衰エンドポイントを表示するには、この Cisco Application Policy Infrastructure Controller（APIC）GUI 手順を使用します。

手順

ステップ 1	メニューバーで、[ファブリック（Fabric）] > [インベントリ（Inventory）] をクリックします。
ステップ 2	[ナビゲーション（Navigation）] ペインで、パッドとスパインノードを展開します。
ステップ 3	[プロトコル（Protocols）] > [COOP] および [COOP] インスタンスを展開します。
ステップ 4	[エンドポイントデータベース（Endpoint Database）] をクリックして、エンドポイントを表示します。 [減衰状態（Dampened State）] カラムを調べて、減衰したエンドポイントを見つけます。次の状態があります。 Normal：エンドポイントの更新は正常です。 Critical：エンドポイントをフリーズ状態に移行できる十分な更新を受信しました。エンドポイントが 5 分以上 Critical 状態のままになると、状態は Freeze に変わります。 Freeze：このエンドポイントからの更新は、頻繁に不要な更新が行われているため、現在無視されています。障害が生成されました。

スイッチ CLI を使用した COOP 減衰エンドポイントの表示

スパインまたはリーフノードのすべての減衰エンドポイントを表示するには、このスイッチ CLI 手順を使用します。

スパインまたはリーフスイッチ CLI にログインし、次のコマンドを入力します。


show coop internal info repo ep dampening

GUI を使用した COOP 減衰エンドポイントのクリア

スパインまたはリーフノードのすべての減衰エンドポイントをクリアおよび回復するには、この Cisco Application Policy Infrastructure Controller（APIC）GUI 手順を使用します。この操作は、すべてのスパインスイッチおよびエンドポイントの送信元リーフスイッチで実行する必要があります。減衰されたエンドポイントがリーフスイッチのエンドポイントテーブルにまだある場合、エンドポイントはスパインスイッチ COOP データベースにパブリッシュされます。そうでない場合、減衰したエンドポイントは、2 分後にスパインスイッチ COOP データベースから削除されます。

手順

ステップ 1	メニューバーで、[ファブリック（Fabric）] > [インベントリ（Inventory）] をクリックします。
ステップ 2	[ナビゲーション（Navigation）] ペインで、パッドとスパインまたはリーフノードを展開します。
ステップ 3	ノードを右クリックし、[減衰エンドポイントの消去（Clear Dampened Endpoints）] を選択します。
ステップ 4	[はい（Yes）] をクリックして、アクションを確認します。

スイッチ CLI を使用した COOP 減衰エンドポイントのクリア

スパインまたはリーフノードの減衰エンドポイントをクリアして回復するには、次の手順を使用します。この手順では、ダンプニング状態が Freeze である単一のエンドポイントを回復します。この操作は、すべてのスパインスイッチおよびエンドポイントの送信元リーフスイッチで実行する必要があります。

スパインまたはリーフスイッチ CLI にログインし、次のコマンドを入力します。

clear coop internal info repo ep dampening key <bd> <mac>

RESTAPI を使用した COOP エンドポイントダンプニングの無効化

この手順では、APIC REST API を使用して COOP EP ダンプニングを無効または有効にする方法を示します。

COOP エンドポイントのダンプニングはデフォルトで有効になっていますが、場合によっては無効にする必要があります。たとえば、1つの MAC アドレスに対して多数の IP 更新が予想され、それらの更新を無視するとネットワークが中断される場合があります。

次の API を使用し、disableEpDampening = "true" を設定して COOP エンドポイントダンプニングを無効にします。


<!-- api/policymgr/mo/.xml -->

<polUni>
    <infraInfra>
        <infraSetPol disableEpDampening="true"></infraSetPol>
    </infraInfra>
</polUni>

ファブリック内のすべてのノードは COOP エンドポイントダンプニングを無効にし、ダンプニング状態が「フリーズ」である既存のエンドポイントを回復します。

APIC GUI を使用した COOP 認証の設定

手順

ステップ 1	メニューバーで、[System] > [System Settings] の順に選択します。
ステップ 2	[ナビゲーション] ペインで [COOP グループ] をクリックします。
ステップ 3	[作業] ペインの [タイプ] フィールドにある [ポリシープロパティ] 領域で、[互換性のあるタイプ] および [ストリクトタイプ] オプションから希望のタイプを選択します。
ステップ 4	[Submit] をクリックします。これにより、COOP 認証ポリシー設定を完了します。

Cisco NX OS スタイル CLI を使用した COOP 認証の設定

手順

ストリクトモードオプションを使用して、COOP 認証ポリシーを設定します。

例:

apic1# configure
apic1(config)# coop-fabric
apic1(config-coop-fabric)# authentication type ?
compatible  Compatible type
strict      Strict type
apic101-apic1(config-coop-fabric)# authentication type strict

REST API を使用した COOP 認証の設定

手順

COOP 認証ポリシーを設定します。

例では、ストリクトモードが選択されます。

例:

https://172.23.53.xx/api/node/mo/uni/fabric/pol-default.xml
 
<coopPol type="strict">
</coopPol>

エンドポイントリッスンポリシーについて

エンドポイントリッスンポリシーを設定して、ポリシーが適用されていない Cisco Application Centric Infrastructure（ACI）のリーフスイッチに匿名エンドポイントから送信されるタグなしトラフィックを検出できます。デフォルトでは、ポートにポリシーが展開されていない場合、すべてのエンドポイントトラフィックがそのポートでドロップされます。エンドポイントリッスンポリシーを設定すると、このポリシーは、適用されている既存のポリシーがないすべてのリーフスイッチポートに展開されます。エンドポイントリッスンポリシーでは、Cisco ACI でこれらのポートに着信するタグなしトラフィックを検出できます。これにより、Cisco ACI で匿名エンドポイントの MAC アドレスまたは IP アドレスがわかります。これにより、Cisco ACI 管理者はこれらのエンドポイントを配置する EPG を決定できます。Cisco Application Policy Infrastructure Controller（APIC）GUI は、検出されたすべての匿名エンドポイントをグローバルエンドポイント設定画面に表示します。

（注）

エンドポイントリッスンポリシーはベータ機能です。この機能が意図したとおりに動作する保証はありません。自己責任で使用してください。

GUI を使用したエンドポイントリッスンポリシーの設定

この手順では、エンドポイントリッスンポリシーを設定します。このポリシーは、匿名エンドポイントから、適用されたポリシーがない Cisco Application Centric Infrastructure（ACI）リーフスイッチに送信されるタグなしトラフィックを検出します。

（注）

エンドポイントリッスンポリシーはベータ機能です。この機能が意図したとおりに動作する保証はありません。自己責任で使用してください。

手順

ステップ 1	メニューバーで、[システム（System）] > [システム設定（System Settings）] の順に選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[グローバルエンドポイント（Global Endpoints）] を選択します。
ステップ 3	[作業（Work）] ペインで、[エンドポイントリッスンポリシー（End Point Listen Policy）] チェックボックスをオンにします。
ステップ 4	[エンドポイントリッスンエンキャップ（End Point Listen Encap）]ドロップダウンリストで、[VLAN] を選択します。
ステップ 5	[エンドポイントリッスンエンキャップ（End Point Listen Encap）] テキストフィールドに、VLAN ID を入力します。有効な値は 1 ～ 4094 です。これは予約済みの VLAN カプセル化である必要があり、どの EPG でも使用できません。
ステップ 6	[Submit] をクリックします。

IP エージングの設定

このトピックでは、IP エージングポリシーを有効にする方法について説明します。有効な場合、IP エージングポリシーは、エンドポイント上の未使用の Ip 5 します。

管理状態が有効になっているときに、IP エージングポリシーは、エンドポイントの ip アドレスを追跡する (IPv4) の ARP 要求と (IPv6) のネイバー要請を送信します。応答が指定されていない場合、ポリシーは、未使用の IPs 5 します。

手順

ステップ 1	メニューバーで、System > System Settings を選択します。
ステップ 2	をクリックしてエンドポイントコントロール。
ステップ 3	Ip Aging タブをクリックします。
ステップ 4	ポリシーを有効にするにはクリックして Enabled で、 Administrative State フィールド。

次のタスク

、、エンドポイント上の ip アドレスを追跡するために使用されるタイマーを指定する必要があるエンドポイント保持ポリシーを作成します。移動テナント > テナント名 > > ポリシー > プロトコル > エンドポイント保持。

リモートエンドポイントの学習を無効にする

このトピックでは、有効化または IP エンドポイントラーニングを無効にする方法について説明します。

このポリシーの適用範囲は、ファブリック全体です。を設定した後、ポリシーは起動に各リーフスイッチにプッシュされます。

Cisco Nexus 9000 シリーズのスイッチで 93128 を含むファブリックでは、このポリシーを有効にする必要がありますが正常に APIC リリース 2.2(2x) にアップグレードされた以降のすべてのノードが表示された後の N9K M12PQ アップリンクモジュール、TX、9396 PX または 9396 TX がスイッチします。

次の設定の変更のいずれか後に、、手動で以前に学習された IP エンドポイントをフラッシュする必要があります。

リモート IP エンドポイントラーニングが無効になっています
入力ポリシーの適用、VRF が設定されています。
VRF に少なくとも 1 つのレイヤ 3 インターフェイスが存在します

以前に学習された IP エンドポイントを手動でフラッシュ、VPC ピアの両方で、次のコマンドを入力します: vsh-c"システム内部 epm エンドポイントの vrf をクリア<vrf-name>リモート「 </vrf-name> 。

IP エンドポイントの学習を有効または無効にするには、次の手順を実行します:

手順

ステップ 1	メニューバーで、[System] > [System Settings] の順にクリックします。
ステップ 2	[Fabric Wide Setting] をクリックします。
ステップ 3	チェックボックスをクリックしてリモート EP 学習の無効化。
ステップ 4	[Submit] をクリックします。

サブネットチェックのグローバルな適用

このトピックでは、サブネットチェックを有効また無効にする方法について説明します。有効にすると、ある VRF で設定されたサブネットの外、つまり他のすべての VRF では、IP 学習が無効になります。

このポリシーの適用範囲は、ファブリック全体です。を設定した後、ポリシーは起動に各リーフスイッチにプッシュされます。

手順

ステップ 1	メニューバーで、[System] > [System Settings] の順にクリックします。
ステップ 2	[Fabric Wide Setting] をクリックします。
ステップ 3	Enforce Subnet Check チェックボックスをオンにします。
ステップ 4	[Submit] をクリックします。

GIPo の再割り当て

このトピックでは、非ストレッチブリッジドメインの GIPos の再割り当てを有効にして、ストレッチブリッジドメイン用のスペースを確保する方法について説明します。

Cisco ACI Multi-Site の導入により、GIPo 割り当て方式を変更して次の利点を提供する必要がありました。

同じ GIPo を持つブリッジドメインの数を最小限に抑えます。
Cisco ACI Multi-Site 拡張ブリッジドメインに割り当てられた GIPos は、非拡張ブリッジドメインに割り当てられた GIPos と重複しません。

この割り当てを実現するために、Cisco ACI では、ストレッチされたブリッジドメインとストレッチされていないブリッジドメインの量に基づいてサイズが異なる複数のプールが導入されました。

Cisco ACI の新規インストールの場合、Cisco APIC は＃1 と＃2 の両方が実行されることを保証します。2.3(1) よりも前のリリースからの Cisco ACI のアップグレード中は、既存の GIPo が非ストレッチブリッジドメインにすでに使用されている可能性があるため、ファブリックの中断を避けるために古いスキーマが維持されます。その結果、Cisco ACI は＃2 が完了したことを保証できません。

Cisco APIC のファブリック全体の設定ポリシーで [GIPo の再割り当て（Reallocate GIPo）] ノブを有効にすると、Cisco APIC は GIPos を再割り当てし、新しい割り当て方式を使用します。ノブの有効化は 1 回限りの操作です。その後、GIPos はオーバーラップしません。このノブは、2.3(1) より前のリリースから 3.0(1) 以降のリリースにアップグレードする場合にのみ、Cisco ACI Multi-Site Orchestrator の導入に関連します。

このポリシーの適用範囲は、ファブリック全体です。を設定した後、ポリシーは起動に各リーフスイッチにプッシュされます。

手順

ステップ 1	メニューバーで、[システム（System）]> > [システム設定（System Settings）] を選択します。
ステップ 2	[Fabric Wide Setting] をクリックします。
ステップ 3	[Reallocate Gipo] のチェックボックスをオンにします。
ステップ 4	[Submit] をクリックします。

ドメインの検証のグローバルな適用

このトピックでは、ドメインの検証を適用する方法について説明します。有効な場合、静的なパスを追加すると、EPG に関連付けられたドメインがないかどうか判断するために、検証チェックが実行されます。

このポリシーの適用範囲は、ファブリック全体です。を設定した後、ポリシーは起動に各リーフスイッチにプッシュされます。

手順

ステップ 1	メニューバーで、[System] > [System Settings] の順にクリックします。
ステップ 2	[Fabric Wide Setting] をクリックします。
ステップ 3	Enforce Domain Validation チェックボックスをオンにします。
ステップ 4	[Submit] をクリックします。

OpFlex クライアント認証を有効にする

このトピックでは、GOLF および Linux 用の OpFlex クライアント認証を有効にする方法について説明します。

クライアントの ID がネットワークによって保証されない環境で GOLF または Linux Opflex クライアントをデプロイするには、クライアント証明書に基づいてクライアントの ID を動的に検証できます。

（注）

証明書の適用を有効にすると、クライアント認証をサポートしていない GOLF または Linux Opflex クライアントとの接続が無効になります。

このポリシーの適用範囲は、ファブリック全体です。を設定した後、ポリシーは起動に各リーフスイッチにプッシュされます。

手順

ステップ 1	メニューバーで、[System] > [System Settings] の順にクリックします。
ステップ 2	[Fabric Wide Setting] をクリックします。
ステップ 3	OpFlex Client Authentication のチェックボックスをクリックして、GOLF および Linux Opflex クライアントのクライアント証明書認証を有効または無効にします。
ステップ 4	[Submit] をクリックします。

ファブリックロードバランシング

Cisco Application Centric Infrastructure（ACI）ファブリックでは、利用可能なアップリンクリンク間のトラフィックを平衡化するためのロードバランシングオプションがいくつか提供されます。ここでは、リーフからスパインへのスイッチトラフィックのロードバランシングについて説明します。

スタティックハッシュロードバランシングは、各フローが 5 タプルのハッシュに基づいてアップリンクに割り当てられるネットワークで使用される従来のロードバランシング機構です。このロードバランシングにより、使用可能なリンクにほぼ均等な流量が分配されます。通常、流量が多いと、流量の均等な分配により帯域幅も均等に分配されます。ただし、いくつかのフローが残りよりも多いと、スタティックロードバランシングにより完全に最適ではない結果がもたらされる場合があります。

Cisco ACI ファブリックダイナミックロードバランシング（DLB）は、輻輳レベルに従ってトラフィック割り当てを調整します。DLB では、使用可能なパス間の輻輳が測定され、輻輳状態が最も少ないパスにフローが配置されるので、データが最適またはほぼ最適に配置されます。

DLB は、フローまたはフローレットの粒度を使用して使用可能なアップリンクにトラフィックを配置するように設定できます。フローレットは、時間の大きなギャップによって適切に区切られるフローからのパケットのバーストです。パケットの 2 つのバースト間のアイドル間隔が使用可能なパス間の遅延の最大差より大きい場合、2 番目のバースト（またはフローレット）を 1 つ目とは異なるパスに沿ってパケットのリオーダーなしで送信できます。このアイドル間隔は、フローレットタイマーと呼ばれるタイマーによって測定されます。フローレットにより、パケットリオーダーを引き起こすことなくロードバランシングに対する粒度の高いフローの代替が提供されます。

DLB 動作モードは積極的または保守的です。これらのモードは、フローレットタイマーに使用するタイムアウト値に関係します。アグレッシブモードのフローレットタイムアウトは比較的小さい値です。この非常に精密なロードバランシングはトラフィックの分配に最適ですが、パケットリオーダーが発生する場合があります。ただし、アプリケーションのパフォーマンスに対する包括的なメリットは、保守的なモードと同等かそれよりも優れています。保守的なモードのフローレットタイムアウトは、パケットが並び替えられないことを保証する大きな値です。新しいフローレットの機会の頻度が少ないので、トレードオフは精度が低いロードバランシングです。DLB は常に最も最適なロードバランシングを提供できるわけではありませんが、スタティックハッシュロードバランシングより劣るということはありません。

（注）

すべての Nexus 9000 シリーズスイッチには DLB のハードウェアサポートがありますが、DLB 機能は、第 2 世代プラットフォーム（EX、FX、および FX2 サフィックスを持つスイッチ）の現在のソフトウェアリリースでは有効になっていません。

Cisco ACI ファブリックは、リンクがオフラインまたはオンラインになったことで使用可能なリンク数が変化すると、トラフィックを調整します。ファブリックは、リンクの新しいセットでトラフィックを再分配します。

スタティックまたはダイナミックのロードバランシングのすべてのモードでは、トラフィックは、Equal Cost Multipath (ECMP) の基準を満たすアップリンクまたはパス上でのみ送信され、これらのパスはルーティングの観点から同等で最もコストがかかりません。

ロードバランシング技術ではありませんが、Dynamic Packet Prioritization（DPP）は、スイッチで DLB と同じメカニズムをいくつか使用します。DPP の設定は DLB 専用です。DPP は、長いフローよりも短いフローを優先します。短いフローは約 15 パケット未満です。短いフローは長いフローよりも遅延の影響を受けやすいため、DPP はアプリケーション全体のパフォーマンスを向上させることができます。

6.0（1）および 6.0（2）リリースでは、イントラリーフスイッチトラフィックの場合、カスタム QoS 構成に関係なく、すべての DPP 優先トラフィックが CoS 0 とマークされます。リーフ間スイッチトラフィックの場合、カスタム QoS 構成に関係なく、すべての DPP 優先トラフィックが CoS 3 とマークされます。6.0（3）リリース以降、イントラリーフスイッチおよびインターリーフスイッチのトラフィックでは、カスタム QoS 構成に関係なく、すべての DPP 優先トラフィックが CoS 0 とマークされます。

GPRS トンネリングプロトコル（GTP）は、主にワイヤレスネットワークでデータを配信するために使用されます。Cisco Nexus スイッチは Telcom データセンター内の場所です。パケットがデータセンターの Cisco Nexus 9000 スイッチを介して送信される場合、トラフィックは GTP ヘッダーに基づいてロードバランシングされる必要があります。ファブリックがリンクバンドルを介して外部ルータに接続されている場合、トラフィックはすべてのバンドルメンバー（たとえば、レイヤ 2 ポートチャネル、レイヤ 3 ECMP リンク、レイヤ 3 ポートチャネル、およびポートチャネル上の L3Out）に均等に分散される必要があります。）。GTP トラフィックのロードバランシングは、ファブリック内でも実行されます。

GTP ロードバランシングを実現するために、Cisco Nexus 9000 シリーズスイッチは 5 タプルのロードバランシングメカニズムを使用します。ロードバランシングメカニズムでは、パケットの送信元 IP、宛先 IP、プロトコル、レイヤ 4 リソース、および宛先ポート（トラフィックが TCP または UDP の場合）フィールドが考慮されます。GTP トラフィックの場合は、これらのフィールドへの一意の値の数が限られていると、トンネルでのトラフィックロードの均等分散が制限されます。

ロードバランシングにおける GTP トラフィックの極性化を回避するために、GTP ヘッダーのトンネルエンドポイント ID（TEID）が UDP ポート番号の代わりに使用されます。TEID がトンネルごとに異なるため、トラフィックをバンドルの複数のリンク間で均等にロードバランシングすることができます。

GTP ロードバランシングは、GTPU パケットに存在する 32 ビット TEID 値で送信元および宛先ポート情報を上書きします。

GTP トンネルのロードバランシング機能により、次のサポートが追加されます。

物理インターフェイスでの IPv4/IPv6 トランスポートヘッダーによる GTP
UDP ポート 2152 を使用した GTPU

Cisco ACIファブリックのデフォルト構成では、従来の静的なハッシュが使用されます。スタティックなハッシュ機能により、アップリンク間のトラフィックがリーフスイッチからスパインスイッチに分配されます。リンクがダウンまたは起動すると、すべてのリンクのトラフィックが新しいアップリンク数に基づいて再分配されます。

リーフ/スパインスイッチダイナミックロードバランシングアルゴリズム

次の表に、リーフ/スパインスイッチダイナミックロードバランシングで使用されるデフォルトの設定不可能なアルゴリズムを示します。

表 1. Cisco ACIリーフ/スパインスイッチダイナミックロードバランシング
Traffic Type	データポイントのハッシュ
リーフ/スパイン IP ユニキャスト	送信元 MAC アドレス宛先 MAC アドレス送信元 IP アドレス宛先 IP アドレスプロトコルタイプ送信元レイヤ 4 ポート宛先レイヤ 4 ポートセグメント ID（VXLAN VNID）または VLAN ID
リーフ/スパインレイヤ 2	送信元 MAC アドレス宛先 MAC アドレスセグメント ID（VXLAN VNID）または VLAN ID

Cisco APIC GUI を使用したロードバランサポリシーの作成

このトピックでは、デフォルトのロードバランサーポリシーを構成する方法について説明します。

ロードバランシングポリシーオプションは、利用可能なアップリンクポート間でトラフィックのバランスをとります。スタティックハッシュロードバランシングは、各フローが 5 タプルのハッシュに基づいてアップリンクに割り当てられるネットワークで使用される従来のロードバランシング機構です。このロードバランシングにより、使用可能なリンクにほぼ均等な流量が分配されます。通常、流量が多いと、流量の均等な分配により帯域幅も均等に分配されます。ただし、いくつかのフローが残りよりも多いと、スタティックロードバランシングにより完全に最適ではない結果がもたらされる場合があります。

手順

ステップ 1	メニューバーで、[System] > [System Settings] の順にクリックします。
ステップ 2	[Load Balancer] をクリックします。
ステップ 3	[Dynamic Load Balancing Mode] を選択します。ダイナミックロードバランシング (DLB) モードは、輻輳レベルに応じてトラフィックの割り当てを調整します。DLB では、使用可能なパス間の輻輳が測定され、輻輳状態が最も少ないパスにフローが配置されるので、データが最適またはほぼ最適に配置されます。DLB は、フローまたはフローレットの粒度を使用して使用可能なアップリンクにトラフィックを配置するように設定できます。フローレットは、間隔で区切られたフローからのパケットのバーストです。モードは [Aggressive], [Conservative], または [Off] (デフォルト)。
ステップ 4	[オン（On）] または [オフ（Off）]（デフォルト）を選択して、ダイナミックパケットの優先順位付けを有効または無効にします。 Dynamic Packet Prioritization (DPP) は、長いフローよりも短いフローを優先します。短いフローは約 15 です。短いフローは、長いフローより遅延に敏感です。DPP により、アプリケーション全体のパフォーマンスが向上します。
ステップ 5	[Load Balancing Mode] を選択します。モードは、Link Failure または Traditional (デフォルト) です。ロードバランサーの管理状態。スタティックまたはダイナミックのロードバランシングのすべてのモードでは、トラフィックは、Equal Cost Multipath (ECMP) の基準を満たすアップリンクまたはパス上でのみ送信され、これらのパスはルーティングの観点から同等で最もコストがかかりません。
ステップ 6	[Submit] をクリックします。

CLI を使用したロードバランサポリシーの作成

CLI を使用したダイナミックロードバランサポリシーの作成

ダイナミックアグレッシブとダイナミック保守の 2 つのダイナミックロードバランサモードがあります。ダイナミックアグレッシブモードでは、より短い flowlet タイムアウト間隔が有効になり、ダイナミック保守モードでは、より長い flowlet タイムアウト間隔が有効になります。これらのコマンドの詳細については、『Cisco APIC NX-OS スタイル CLI コマンド資料』を参照してください。

このセクションでは、CLI を使用してダイナミックロードバランサポリシーを設定する方法を示します。

手順

ステップ 1

アグレッシブモードのダイナミックロードバランシングを有効にするには、次の手順を実行します。

apic1# conf t
apic1# (config)# system dynamic-load-balance mode dynamic-aggressive

ステップ 2

保守モードのダイナミックロードバランシングを有効にするには、次の手順を実行します。

apic1# conf t
apic1# (config)# system dynamic-load-balance mode dynamic-conservative

CLI を使用したダイナミックパケット優先順位付けポリシーの作成

ここでは、CLI を使用してダイナミックパケットの優先順位付けを有効にする方法を示します。このコマンドの詳細については、『Cisco APIC NX-OS スタイル CLI コマンド資料』を参照してください。

手順

ダイナミックパケット優位性を有効にします。

apic1# conf t
apic1# (config)# system dynamic-load-balance mode packet-prioritization

CLI を使用した GTP ロードバランサポリシーの作成

このセクションでは、CLI を使用して GTP ロードバランサポリシーを作成する方法を示します。このコマンドの詳細については、『Cisco APIC NX-OS スタイル CLI コマンド資料』を参照してください。

手順

ダイナミックパケット優位性を有効にします。

apic1# conf t
apic1# (config)# ip load-sharing address source_destination gtpu

REST API を使用したロードバランサポリシーの作成

このセクションでは、DLB、DPP、および GTP ロードバランサポリシーを有効にする方法を示します。使用可能なすべてのプロパティ値のリストについては、『Cisco APIC 管理情報モデル資料』を参照してください。

手順

DLB、DPP、および GTP ロードバランサポリシーを有効にするには、次の手順を実行します。


https://apic-ip-address/api/mo/uni.xml
<polUni>
<fabricInst>
	<lbpPol name="default" hashGtp="yes" pri="on" dlbMode="aggressive">
	</lbpPol>
</fabricInst>
</polUni>

時間精度ポリシーの有効化

このトピックでは、ネットワーク上の分散ノードの時間同期プロトコルである Precision Time Protocol (PTP) を有効にする方法について説明します。そのハードウェアのタイムスタンプ機能は、ネットワークタイムプロトコル（NTP）などの他の時刻同期プロトコルより高い精度を実現します。

PTP は、システムのリアルタイム PTP クロックが相互に同期する方法を指定する分散プロトコルです。これらのクロックは、グランドマスタークロック（階層の最上部にあるクロック）を持つマスター/メンバー同期階層に編成され、システム全体の時間基準を決定します。同期は、タイミング情報を使用して階層のマスターの時刻にクロックを調整するメンバーと、PTP タイミングメッセージを交換することによって実現されます。PTP は、PTP ドメインと呼ばれる論理範囲内で動作します。

リリース 4.2（5）より前は、PTP 機能はCisco ACIファブリック内でのみサポートされていました。リリース 4.2（5）以降、PTP 機能はCisco ACIファブリックの外部でサポートされるようになりました。Cisco ACIファブリック外部のグランドマスターとクライアントは、Cisco ACIファブリック内のスイッチの前面パネルポートに接続できます。

（注）

グランドマスタースイッチのクライアントとして構成されているCisco ACIファブリック内のスイッチに接続できる外部グランドマスタースイッチは 1 つだけです。現時点では、複数の外部グランドマスタースイッチを単一のクライアントスイッチに接続することはサポートされていません。

手順

ステップ 1	メニューバーで、[システム（System）]> > [システム設定（System Settings）] を選択します。
ステップ 2	Precision Time Protocol をクリックします。
ステップ 3	Enabled または Disabled を選択します。 PTP を無効にするように選択した場合は、NTP の時間がファブリックを同期するために使用されます。PTP を有効にすると、サイト全体を同期するためのマスターとしてあるスパインが自動的に選択されます。
ステップ 4	[Submit] をクリックします。

グローバルシステム GIPo ポリシーの有効化

このトピックでは、インフラテナント GIPo をシステム GIPo として使用する方法について説明します。

ACI マルチポッドを導入するには、239.255.255.240 のシステムグローバル IP アウトサイド (GIPo) を、インターポッドネットワーク (IPN) 上で、PIM BIDIR の範囲として設定する必要があります。この、IPN デバイス上での 239.255.255.240 PIM BIDIR 範囲の設定は、インフラ GIPo をシステム GIPo として使用することによって回避できます。

始める前に

リーフスイッチおよびスパインスイッチを含む、ACI ファブリックのすべてのスイッチを、最新の APIC リリースにアップグレードします。

手順

ステップ 1	メニューバーで、 System > System Settings の順にクリックします。
ステップ 2	Enabled または Disabled (デフォルト) を、Use Infra GIPo as System GIPo で選択します。
ステップ 3	[Submit] をクリックします。

ファブリックポートトラッキングポリシーの設定

アップリンク障害検出は、ファブリックアクセスファブリックポートトラッキングポリシーで有効にできます。ポートトラッキングポリシーは、リーフスイッチとスパインスイッチ間のリンクの状態を監視します。有効なポートトラッキングポリシーがトリガーされると、リーフスイッチは、EPG によって導入されたスイッチ上のすべてのアクセスインターフェイスをダウンさせます。ファブリックポートトラッキングの詳細については、 Cisco APIC Layer 2 Networking Configuration Guideを参照してください。

手順

ステップ 1	メニューバーで、[システム（System）]> > [システム設定（System Settings）] を選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[ポートトラッキング（Port Tracking）] を選択します。
ステップ 3	Port tracking state を on に設定して、ポートトラッキングを有効にします。
ステップ 4	（任意） [毎日の復元タイマー（Daily restore timer）] の値を変更します。
ステップ 5	ポートトラッキングパラメータをトリガーするアクティブなスパインリンクの数を設定します。
ステップ 6	[Submit] をクリックします。

グローバル接続可能アクセスエンティティプロファイルの作成

接続可能エンティティプロファイル（AEP）は、同様のインフラストラクチャポリシー要件を持つ外部エンティティのグループを表します。インフラストラクチャポリシーは、Cisco Discovery Protocol（CDP）、Link Layer Discovery Protocol（LLDP）、Link Aggregation Control Protocol（LACP）などのさまざまなプロトコルオプションを設定する物理インターフェイスポリシーで構成されます。

AEP は、リーフスイッチで VLAN プールを展開するのに必要です。カプセル化ブロック（および関連 VLAN）は、リーフスイッチで再利用可能です。AEP は、VLAN プールの範囲を物理インフラストラクチャに暗黙的に提供します。

次の AEP の要件と依存関係は、さまざまな設定シナリオ（ネットワーク接続、VMMドメイン、マルチポッド設定など）でも考慮する必要があります。

AEP は許容される VLAN の範囲を定義しますが、それらのプロビジョニングは行いません。EPG がポートに展開されていない限り、トラフィックは流れません。AEP で VLAN プールを定義しないと、EPG がプロビジョニングされても VLAN はリーフポートでイネーブルになりません。
リーフポートで静的にバインディングしている EPG イベントに基づいて、または VMware vCenter や Microsoft Azure Service Center Virtual Machine Manager（SCVMM）などの外部コントローラからの VM イベントに基づいて、特定の VLAN がリーフポート上でプロビジョニングされるかイネーブルになります。
添付されているエンティティプロファイルに関連付けられているすべてのポートに関連付けられているアプリケーション Epg を導入するアプリケーション Epg に直接と関連付けることができますプロファイルのエンティティが添付されています。AEP では、アタッチ可能なエンティティプロファイルに関連付けられているセレクタの一部であるすべてのインターフェイスで導入されている EPG (infraRsFuncToEpg) との関係が含まれている設定可能な一般的な機能 (infraGeneric) があります。

Virtual Machine Manager（VMM）ドメインは、AEP のインターフェイスポリシーグループから物理インターフェイスポリシーを自動的に取得します。

始める前に

接続されているエンティティプロファイルに関連付けられるテナント、VRF インスタンス、アプリケーションプロファイルおよび EPG を作成します。

手順

ステップ 1	メニューバーで、[ファブリック（Fabric）] > [アクセスポリシー（Access Policies）] の順にクリックします。
ステップ 2	ナビゲーションバーで、Policies と Global を展開します。
ステップ 3	[接続可能なアクセスエンティティプロファイル] を右クリックして、[接続可能なアクセスエンティティプロファイルの作成] を選択します。
ステップ 4	ポリシーの名前を入力します。
ステップ 5	[ドメイン] テーブル上の [+] アイコンをクリックします。
ステップ 6	物理ドメイン、以前に作成した物理、レイヤ 2、レイヤ 3、ファイバチャネルドメインを入力するか、新規作成します。
ステップ 7	ドメインのカプセル化を入力して、[更新] をクリックします。
ステップ 8	[EPG 展開] テーブルの [+] アイコンをクリックします。
ステップ 9	テナント、アプリケーションプロファイル、EPG カプセル化（vlan-1 など）、プライマリカプセル化（プライマリカプセル化番号）、インターフェイスモードを入力します（トランク、802.1P またはアクセス（タグなし）。
ステップ 10	Update をクリックします。
ステップ 11	[Next] をクリックします。
ステップ 12	接続可能なエンティティプロファイルに関連付けるインターフェイスを選択します。
ステップ 13	[完了（Finish）] をクリックします。

QoS クラスのグローバルポリシーを設定します。

グローバル QoS クラスポリシーを使用できます。

CoS を保持する、CoS 値を保証するために、優先度レベル 802.1 P のパケット数を入力し、ACI ファブリックを通過するが保持されます。802.1 P CoS の保持は単一のポッドおよび multipod トポロジでサポートされます。Multipod トポロジは、CoS の保持を使用できますポッド 1 を入力して、ポッド 2 外からの 802.1 P トラフィックの優先順位の QoS の設定を保持したいですが、CoS の保持を行わない/interpod の DSCP 設定のネットワーク (IPN) トラフィックポッド間。CoS を保持するために multipod トラフィックが通信中、IPN の DSCP 設定を使用して、DSCP ポリシー/(で設定されているテナント > インフラ > > ポリシー > プロトコル > DSCP クラス-cos L3 トラフィックのポリシーの変換)
次のように、デフォルトの QoS クラスレベルのプロパティをリセットします MTU 、キュー制限、またはスケジューリングアルゴリズム。

手順

ステップ 1	メニューバーで、[ファブリック（Fabric）] > [アクセスポリシー（Access Policies）] の順にクリックします。
ステップ 2	ナビゲーションバーで、Policies と Global を展開します。
ステップ 3	QOS Class をクリックします。
ステップ 4	CoS 802.1 P の有効化にして、をクリックして、保持 COS チェックボックス。
ステップ 5	QoS クラスのデフォルト設定を変更するには、それをダブルクリックします。新しい設定を入力し、Submit をクリックします。

グローバル DHCP リレーポリシーの作成

グローバル DHCP リレーポリシーは、ファブリックの DHCP サーバを識別します。

手順

ステップ 1

メニューバーで、[ファブリック（Fabric）] > [アクセスポリシー（Access Policies）] の順にクリックします。

ステップ 2

ナビゲーションバーで、Policies と Global を展開します。

ステップ 3

DHCP Relay を右クリックし、Create DHCP Relay Policy を選択します。

ステップ 4

[Create DHCP Relay Policy] ダイアログボックスで、次の操作を実行します。

[Name] フィールドに、DHCP リレープロファイル名（DhcpRelayP）を入力します。

この名前では最大 64 文字までの英数字を使用できます。
（任意） [説明（Description）] フィールドに、DHCP リレーポリシーの説明を入力します。

説明には最大 128 文字までの英数字を使用できます。
[Providers] を展開します。

[DHCP プロバイダーの作成（Create DHCP Provider）] ダイアログボックスが表示されます。
[Create DHCP Provider] ダイアログボックスの [EPG Type] フィールドで、DHCP サーバがどこで接続されているかによって適切なオプションボタンをクリックします。
選択する EPG タイプのオプションは、EPG タイプによって異なります。
- EPG タイプとして [アプリケーション EPG（Application EPG）] を選択すると、次のオプションが [アプリケーション EPG（Application EPG）] 領域に表示されます。
  - [テナント（Tenant）] フィールドで、ドロップダウンリストから、テナントを選択します。（infra）
  - [Application Profile] フィールドで、ドロップダウンリストから、アプリケーションを選択します。（access）
  - [EPG] フィールドで、ドロップダウンリストから、EPG を選択します。（デフォルト）
- EPG タイプとして [L2 外部ネットワーク（L2 External Network）] を選択すると、[L2 外部ネットワーク領域（L2 External Network）] に次のオプションが表示されます。
  - [テナント（Tenant）] フィールドで、ドロップダウンリストから、テナントを選択します。
  - [L2 Out] フィールドで、ドロップダウンリストから [L2 Out] を選択します。
  - [External Network（外部ネットワーク）] フィールドで、ドロップダウンリストから外部ネットワークを選択します。
- EPG タイプとして [L3 外部ネットワーク（L3 External Network）] を選択すると、[L3 外部ネットワーク（L3 External Network）]領域に次のオプションが表示されます。
  - [テナント（Tenant）] フィールドで、ドロップダウンリストから、テナントを選択します。
  - [L3 Out] フィールドで、ドロップダウンリストから [L3 Out] を選択します。
  - [External Network（外部ネットワーク）] フィールドで、ドロップダウンリストから外部ネットワークを選択します。
- EPG タイプとして [DN] を選択した場合は、ターゲットエンドポイントグループの識別名を入力します。

[DHCP Server Address] フィールドに、インフラ DHCP サーバの IP アドレスを入力します。

（注）

インフラ DHCP IP アドレスは、インフラ IP アドレス APIC1 です。vShield コントローラ設定のために展開する場合は、デフォルトの IP アドレス 10.0.0.1 を入力する必要があります。

[DHCP サーバープレファレンス（DHCP Server Preference）]フィールドで、このプロバイダーの管理設定値を選択します。
[DHCP サーバープレファレンス（DHCP Server Preference）] フィールドは、リリース 5.2(4) 以降で使用できます。リーフスイッチは、このフィールドの値を基に、クライアント VRF またはサーバー VRF のどちらから DHCP リレーパケットをルーティングするかを決定します。詳細については、DHCP サーバー設定フィールドについてを参照してください。
- [ なし（None）] : これはデフォルトのオプションで、リリース 5.2(4) より前の動作を反映しています。[なし（None）] オプションを選択すると、スイッチは常にクライアント VRF からの DHCP リレーパケットをルーティングします。VRF 間 DHCP リレーに使用する場合、サーバー VRF ネットワークをクライアント VRF にリークするには、共有サービスコントラクトが必要です。
- [サーバー VRF を使用（Use Server VRF）] : このオプションは、リリース 5.2(4) で導入された新しい動作を反映しています。[サーバー VRF を使用（Use Server VRF）] オプションを選択すると、スイッチは、DHCP クライアントが存在する EPG と DHCP サーバーが存在する EPG（またはDHCP サーバーが到達可能な L3Out のレイヤー 3 外部）の間にコントラクトがあるかどうかには関わりなく、サーバー VRF からの DHCP リレーパケットをルーティングします。
  
  VRF 間設定の場合、[サーバー VRF を使用（Use Server VRF）] オプション（[DHCP サーバープリファレンス（DHCP Server Preference）] フィールド）を選択すると、ルートルックアップのため、サーバーサブネットルートは、クライアントリーフスイッチのサーバ－ VRF 内でプログラムされます。クライアントリーフスイッチの DHCP プロセスは、それ以後、DHCP リレーパケットをサーバー VRF 経由で送信します。このため、サーバー VRF は、クライアントブリッジドメインが展開されているすべてのリーフスイッチに少なくとも 1 つの IP アドレスを使用して展開する必要があります。
[OK] をクリックします。

[DHCP リレーポリシーの作成（Create DHCP Relay Policy）] ウィンドウに戻ります。
[Submit] をクリックします。

DHCP リレーポリシーが作成されます。

グローバル MCP インスタンスポリシーの有効化にします。

グローバル Mis-Cabling プロトコル (MCP) インスタンスポリシーを有効にします。現在の実装では、システムで MCP の 1 つだけのインスタンスが実行されます。

手順

ステップ 1	メニューバーで、[ファブリック（Fabric）] > [アクセスポリシー（Access Policies）] の順にクリックします。
ステップ 2	ナビゲーションバーで、Policies と Global を展開します。
ステップ 3	をクリックして MCP インスタンスポリシーのデフォルト。
ステップ 4	Admin State を Enabled に変更します。
ステップ 5	必要に応じて、ファブリックの他のプロパティを設定します。
ステップ 6	[Submit] をクリックします。

次のタスク

作成エラーには、回復ポリシーが無効になっています

エラーディセーブル回復ポリシーは、1 つ以上の事前定義されたエラー状態が無効になっていたポートを再度有効にするポリシーを指定します。

手順

ステップ 1	メニューバーで、[ファブリック（Fabric）] > [アクセスポリシー（Access Policies）] の順にクリックします。
ステップ 2	ナビゲーションバーで、Policies と Global を展開します。
ステップ 3	をクリックしてエラーには、回復ポリシーが無効になっている .
ステップ 4	回復ポリシーを有効にするイベントをダブルクリックします。
ステップ 5	チェックボックスをクリックし、をクリックして更新。
ステップ 6	オプション。その他のイベントについて、ステップ 4 と 5 を繰り返します。
ステップ 7	オプション。リセット、エラー復旧間隔 (秒) の無効化。
ステップ 8	[送信（Submit）] をクリックします。

ポート単位ポリシーについて

ポート単位ポリシーは、Cisco Application Policy Infrastructure Controller（APIC）GUI を使用してリーフスイッチのインターフェイスを設定するために使用する暗黙的なポリシーです。ポート単位ポリシーは、標準のポリシーベースモデルと比較して単純化されています。これは、Cisco APIC を使用する方法を学習し続けています。この簡素化のため、既存のポリシーに新しいポートを追加することはできません。代わりに、インターフェイスごとにポリシーの新しいチャンクのみを作成できます。

ポート単位のポリシーペインでは、バックグラウンドで NX-OS CLI を使用して、暗黙的および明示的なオブジェクトを作成します。たとえば、新しいポートチャネルを作成すると、明示的なポートチャネルポリシーグループと暗黙的なオーバーライドが作成されます。明示的なポリシーグループへの変更は、暗黙的なポリシーグループが削除されるまでポートに適用されません。CLI と GUI を組み合わせて使用しないことを推奨します。再利用可能なポリシー設定の高度な使用例に移行する場合は、ポートポリシーウィザードを使用して Cisco Application Centric Infrastructure（ACI）ポリシーモデルについて学習し、同じウィザードからポートを設定解除します。

ポート単位のポリシーは、次の GUI の場所からのみ作成できます。

[ファブリック（Fabric）] > [インベントリ（Inventory）] > [Pod-#] > [leaf-switch-name] > [インターフェイスタブ（Interface）] タブ

（注）

[インターフェイス（Interface）] タブは、作業ペインの [インターフェイス（Interface）] タブを参照します。これは、ナビゲーションペインの [インターフェイス（Interfaces）] フォルダではありません。

GUI を使用したポートポリシーごとの設定

この手順では、Cisco Application Policy Infrastructure Controller（APIC）GUI を使用して、ポートポリシーごとのポリシーを作成します。

手順

ステップ 1	メニューバーで、 [Fabric] > [Inventory] を選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、`pod-#` > `leaf-switch-name` を選択します。
ステップ 3	[作業（Work）] ペインで、[インターフェイス（Interface）] タブを選択します。
ステップ 4	[モード（Mode）] ドロップダウンリストで、[設定（Configuration）] を選択します。
ステップ 5	インターフェイス番号を 1 つ以上クリックして、それらのインターフェイスを選択します。 [作業（Work）] ペインのタブのすぐ下にあるボタンが、選択したインターフェイスに設定できるコンポーネントでアクティブになります。
ステップ 6	設定するコンポーネントのいずれかのボタンをクリックします。 [作業（Work）] ペインにはそのコンポーネントのプロパティが表示されます。
ステップ 7	コンポーネントのプロパティを必要に応じて設定します。
ステップ 8	[送信（Submit）] をクリックします。`
ステップ 9	選択したインターフェイスの追加コンポーネントを設定するか、別のインターフェイスを選択してコンポーネントを設定します。

GUI を使用したポートポリシーごとの確認

この手順では、Cisco Application Policy Infrastructure Controller（APIC）GUI を使用してポート単位ポリシーを検証する方法について説明します。

始める前に

非表示ポリシーを表示するには、Cisco APIC を設定する必要があります。デフォルトでは、ポート単位のポリシーは Cisco APIC に表示されません。

手順

ステップ 1	メニューバーで、 [Fabric] > [Inventory] を選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、`pod-#` > `leaf-switch-name` を選択します。
ステップ 3	[作業（Work）] ペインで、[インターフェイス（Interface）] タブを選択します。
ステップ 4	[モード（Mode）] ドロップダウンリストで、[設定（Configuration）] を選択します。
ステップ 5	インターフェイス数を選択する場合は、そのインターフェイス名をクリックします。 [作業（Work）] ペインのタブのすぐ下にあるボタンが、選択したインターフェイスに設定できるコンポーネントでアクティブになります。
ステップ 6	プロパティを表示するコンポーネントのいずれかのボタンをクリックします。 [作業（Work）] ペインに、そのコンポーネントのプロパティが表示されます。
ステップ 7	プロパティが正しく設定されていることを確認し、目的の設定に対して正しくない値を変更します。
ステップ 8	変更を加えた場合は、[送信（Submit）] をクリックします。アンインストールしない場合は、[キャンセル（Cancel）] をクリックします。

GUI を使用した非表示ポリシーの表示

デフォルトでは、ポート単位のポリシーなどの一部のポリシーは Cisco Application Policy Infrastructure Controller（APIC）に表示されません。これらのポリシーを表示するには、非表示のポリシーを表示するように Cisco APIC を設定する必要があります。

手順

ステップ 1

GUI の右上隅にある [マイプロファイルの管理（Manage My Profile）] > [設定（Settings）] を選択します。

[アプリケーション設定（Application Settings）] ダイアログが開きます。

ステップ 2

[非表示ポリシーの表示（Show Hidden Policies）] ボックスにチェックを付けます。

ステップ 3

[OK] をクリックします。

GUI を使用した誤配線プロトコルインターフェイスポリシーの作成（任意）

誤配線プロトコル（MCP）は、Link Layer Discovery Protocol（LLDP）、スパニングツリープロトコル（STP）が検出できない設定ミスを処理するために設計されました。MCP には、それを使用するレイヤ 2 パケットがあり、MCP はファブリック内のループを形成するポートを無効にします。Cisco Application Centric Infrastructure（ACI）ファブリックリーフスイッチはスパニングツリープロトコル（STP）に参加せず、STP に関してハブとして動作します。MCP パケットが送信された後、ファブリックがパケットが戻ったことを確認し、ループが存在することを認識した場合、ファブリックはそのイベントに基づいてアクションを実行します。これが発生するとエラーとイベントが生成されます。MCP は、グローバルに、およびインターフェイスごとに有効にできます。デフォルトでは、MCP がグローバルに無効にされ、各ポートで有効になっています。MCP が機能するには、インターフェイス単位の設定に関係なく、グローバルに有効にする必要があります。

次の手順では、GUI を使用して MPC インターフェイスポリシーを作成します。

手順

ステップ 1	メニューバーで、[ファブリック（FABRIC）] > [アクセスポリシー（Access Policies）] の順に選択します。
ステップ 2	[ナビゲーション（Navigation）] ペインで、[ポリシー（Policies）] > [インターフェイス（Interface）] > [MCP インターフェイス（MCP Interface）] の順に選択します。
ステップ 3	[作業（Work）] ペインで、[アクション（Actions）] > [誤配線プロトコルインターフェイスポリシーの作成（Create Mis-cabling Protocol Interface Policy）] の順に選択します。
ステップ 4	[Create Mis-cabling Protocol Interface Policy] ダイアログボックスで、次の操作を実行します。ポリシーの名前を入力します。（任意）ポリシーの説明を入力します。 [管理状態（Admin State）] に対して、ポリシーを有効にするには [有効（Enable）] を選択し、ポリシーを無効にするには [無効（Disable）] を選択します。（任意） 6.0（2）以降：VLAN ごとの MCP PDU の場合、[有効化（Enable）] を選択すると、MCP は物理ポートが属するすべての EPG VLAN で MCP プロトコルデータユニット（PDU）パケットを送信します。 MCP は、MCP が送信する PDU パケットに、各 EPG VLAN 識別子とともに 802.1Q ヘッダーを追加します。このモードでは、MCP が VLAN 内のループを検出できます。デフォルトは [イネーブル（Enable）] です。（任意） 6.0(2）以降：VLAN ごとに MCP PDU を有効にした場合、[VLAN の最大数（Maximum Number of VLANs）] に、MCP が MCP PDU パケットを送信できるポートあたりの VLAN の最大数を入力します。 6.0（1）以前のリリースでは、VLAN ごとの MCP PDU はリンクごとに最大 256 の VLAN をサポートし、この数は変更できません。特定のリンクに 256 を超える VLAN がある場合、MCP は最初の 256 で PDU を生成します。6.0（2）以降のリリースでは、[VLAN の最大数（Maximum Number of VLANs）] パラメータを使用して、特定のリンクに最大 2,000 の VLAN を設定できます。デフォルトは 256 です。 MCP の操作モードとして [精密（Strict）] または [非生命津（Non-strict）] を選択します。 [精密（Strict）] を選択すると、次の追加フィールドが表示されます。 [初期遅延時間（秒）（Initial Delay Time（sec）] : 外部レイヤ 2 ネットワークでの STP コンバージェンスの時間。デフォルト値は 0 です（レイヤー 2 ネットワークで STP が無効になっている場合）。STP が有効になっている場合、STP が収束するまでの初期遅延時間の範囲は、スケール/トポロジにもよりますが、45 ～ 60 秒です。 [送信頻度（秒、ミリ秒）（Tranmission Frequency（sec, msec）] : 各レイヤ 2 インターフェイスの猶予期間まで、MCP パケットが送信される頻度を決めるタイマー。デフォルトの値は 500 ミリ秒です。猶予期間 (秒、ミリ秒) : 早期ループ検出が行われる猶予期間の時間。ポートは、ループ検出に使用される MCP パケットを積極的に送信します。デフォルトの猶予期間の値は 3 秒です。
ステップ 5	[Submit] をクリックします。

偏向のない言語

翻訳について

検索結果

章のタイトル： コア ACI ファブリック サービスのプロビジョニング

コア ACI ファブリック サービスのプロビジョニング

リンク レベル ポリシー

電磁場干渉に対する再トレーニング

GUI を使用したリンク レベル ポリシーの設定

手順

ポート起動遅延

リンク フラップ ポリシー

GUI を使用したリンク フラップ ポリシーの設定

手順

時刻同期と NTP

インバンドの管理 NTP

NTP over IPv6

GUI を使用した NTP の設定

手順

REST API を使用した NTP の設定

手順

例:

例:

例:

GUI を使用した NTP の動作の確認

手順

NTPサーバ

GUI を使用した NTP サーバの有効化

手順

GUI を使用した日時形式の設定

手順

DHCP リレー ポリシーの設定

DHCP サーバー設定フィールドについて

GUI を使用した APIC インフラストラクチャに対する DHCP サーバ ポリシーの設定

始める前に

手順

REST API を使用してオプション 79 を設定する

NX-OS スタイル CLI を使用した APIC インフラストラクチャの DHCP サーバー ポリシーの設定

始める前に

手順

例:

例:

GUI を使用した APIC インフラストラクチャ用 DHCP サーバ ポリシーの設定

始める前に

手順

例:

例:

例:

例:

DNS サービス ポリシーの設定

インバンド DNS サービス ポリシーによる外部宛先の設定

デュアル スタック IPv4 および IPv6 DNS サーバ

デュアル スタック IPv4 および IPv6 環境

DNS プロファイルの IPv4 または IPv6 の優先順位のポリシー

GUI を使用した DNS プロバイダーと接続するための DNS サービス ポリシーの設定

始める前に

手順

カスタム証明書の設定のガイドライン

GUI を使用した Cisco ACI HTTPS アクセス用カスタム証明書の設定

始める前に

手順

次のタスク

APIC インバンドまたはアウトオブ バンド接続設定 (preferences) の設定

始める前に

手順

クォータ管理ポリシーの設定

手順

適用 BD 例外リストの作成

始める前に

手順

BGP ルータ リフレクタ ポリシーとルート リフレクタ ノード エンドポイントの作成

始める前に

手順

ファブリック全体のコントロール プレーンの MTU ポリシーを設定する

手順

エンドポイント ループ保護の設定

手順

不正なエンドポイントの制御ポリシーについて

不正エンドポイント制御ポリシーの制限事項

GUI を使用した不正エンドポイント制御ポリシーの設定

章のタイトル：コア ACI ファブリックサービスのプロビジョニング

コア ACI ファブリックサービスのプロビジョニング

リンクレベルポリシー

GUI を使用したリンクレベルポリシーの設定

リンクフラップポリシー

GUI を使用したリンクフラップポリシーの設定

DHCP リレーポリシーの設定

GUI を使用した APIC インフラストラクチャに対する DHCP サーバポリシーの設定

NX-OS スタイル CLI を使用した APIC インフラストラクチャの DHCP サーバーポリシーの設定

GUI を使用した APIC インフラストラクチャ用 DHCP サーバポリシーの設定

DNS サービスポリシーの設定

インバンド DNS サービスポリシーによる外部宛先の設定

デュアルスタック IPv4 および IPv6 DNS サーバ

デュアルスタック IPv4 および IPv6 環境

GUI を使用した DNS プロバイダーと接続するための DNS サービスポリシーの設定

APIC インバンドまたはアウトオブバンド接続設定 (preferences) の設定

BGP ルータリフレクタポリシーとルートリフレクタノードエンドポイントの作成

ファブリック全体のコントロールプレーンの MTU ポリシーを設定する

エンドポイントループ保護の設定

GUI を使用したブリッジドメイン作成時の不正/ COOP 例外リストの設定

GUI を使用した既存のブリッジドメインの不正/ COOP 例外リストの設定

GUI を使用したファブリックの不正エンドポイント制御の MAC アドレス例外を構成

最大 IP アドレスフロー制御について

RESTAPI を使用した COOP エンドポイントダンプニングの無効化

エンドポイントリッスンポリシーについて

GUI を使用したエンドポイントリッスンポリシーの設定

リモートエンドポイントの学習を無効にする

サブネットチェックのグローバルな適用

ファブリックロードバランシング

リーフ/スパインスイッチダイナミックロードバランシングアルゴリズム

Cisco APIC GUI を使用したロードバランサポリシーの作成

CLI を使用したダイナミックロードバランサポリシーの作成

CLI を使用したダイナミックパケット優先順位付けポリシーの作成

CLI を使用した GTP ロードバランサポリシーの作成