この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章の内容は、次のとおりです。
APIC GUI にログインすると、現在の GUI モードを確認できます。GUI の右上隅に現在のモードが表示されます。次のどちらのモードで動作するかを選択することができます。
注意:シスコでは、コンフィギュレーション モード(拡張または基本)を混在させないことをお勧めします。いずれかのモードで設定を作成し、他方のモードを使用して設定を変更すると、意図しない変更が発生する可能性があります。たとえば、拡張モードを使用して 2 つのポートにインターフェイス ポリシーを適用し、次に基本モードを使用して 1 つのポートの設定を変更すると、変更内容が両方のポートに適用される可能性があります。
基本モード:基本モードで実行するタスクについては、「基本 GUI を使用した APIC の開始」の章を参照してください。
拡張モード:拡張モードで実行するタスクについては、「拡張 GUI を使用した APIC の開始」の章を参照してください。
次のようにして 1 つの GUI モードから他のモードに変更またはモード間を切り替えることができます。
このマニュアルのいくつかの例の手順には、パラメータ名が含まれています。これらのパラメータ名は、便宜上理解しやすいように例として提供されるもので、それらを使用する必要はありません。
APIC は、ACI ファブリックの一部であるすべてのスイッチに対する自動プロビジョニングおよび管理の中心となるポイントです。単一のデータセンターには、複数の ACI ファブリックを組み込むことができます。各データセンターは、自身の APIC クラスタとファブリックの一部である Cisco Nexus 9000 シリーズ スイッチを持つことができます。スイッチが単一の APIC クラスタによってのみ管理されるようにするには、各スイッチがファブリックを管理するその特定の APIC クラスタに登録される必要があります。
APIC は、現在管理している任意のスイッチに直接接続されている新規スイッチを検出します。クラスタ内の各 APIC インスタンスは、直接接続されているリーフ スイッチのみを最初に検出します。リーフ スイッチが APIC で登録されると、APIC はリーフ スイッチに直接接続されているすべてのスパイン スイッチを検出します。各スパイン スイッチが登録されると、その APIC はそのスパイン スイッチに接続されているすべてのリーフ スイッチを検出します。このカスケード化された検出により、APIC は簡単なわずかな手順でファブリック トポロジ全体を検出することができます。
(注) | スイッチを登録する前に、ファブリック内のすべてのスイッチが物理的に接続され、適切な設定で起動されていることを確認します。シャーシの設置については、http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-installation-guides-list.htmlを参照してください。 |
スイッチが APIC で登録されると、そのスイッチは APIC で管理されるファブリック インベントリの一部となります。アプリケーション セントリック インフラストラクチャ ファブリック(ACI ファブリック)を使用すると、APIC はインフラストラクチャ内のスイッチのプロビジョニング、管理、およびモニタリングのシングル ポイントとなります。
(注) | インフラストラクチャの IP アドレス範囲は、インバンドおよびアウトオブバンドのネットワーク用の ACI ファブリックで使用する他の IP アドレスと重複してはなりません。 |
(注) | インフラストラクチャの IP アドレス範囲は、インバンドおよびアウトオブバンドのネットワーク用の ACI ファブリックで使用する他の IP アドレスと重複してはなりません。 |
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
ファブリック内のすべてのスイッチが物理的に接続され、起動されていることを確認します。
スイッチが APIC で登録された後、APIC はファブリック トポロジ ディスカバリを自動的に実行し、ネットワーク全体のビューを取得し、ファブリック トポロジ内のすべてのスイッチを管理します。
各スイッチは、個々にアクセスせずに、APIC から設定、モニタ、およびアップグレードできます。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
すべてのスイッチが APIC クラスタに登録された後、APIC はファブリック内のすべてのリンクおよび接続を自動的に検出し、その結果トポロジ全体を検出します。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
シスコ アプリケーション セントリック インフラストラクチャ(ACI)ファブリックにおいて、時刻の同期は、モニタリング、運用、トラブルシューティングなどの多数のタスクが依存している重要な機能です。クロック同期は、トラフィック フローの適切な分析にとって重要であり、複数のファブリック ノード間でデバッグとフォールトのタイム スタンプを関連付けるためにも重要です。
1 つ以上のデバイスでオフセットが生じると、多くの一般的な運用問題を適切に診断して解決する機能がブロックされる可能性があります。また、クロック同期によって、アプリケーションのヘルススコアが依存している ACI の内蔵アトミック カウンタ機能をフル活用できます。時刻同期が存在しない場合や不適切に設定されている場合でも、エラーやヘルススコアの低下が引き起こされるわけではありません。これらの機能を適切に使用できるように、ファブリックやアプリケーションを完全に展開する前に、時刻同期を設定する必要があります。デバイスのクロックを同期させる最も一般的な方法は、ネットワーク タイム プロトコル(NTP)を使用することです。
NTP を 設定する前に、どの管理 IP アドレス スキームを ACI ファブリックに配置するかを検討してください。すべての ACI ノードと Application Policy Infrastructure Controller(APIC)の管理を設定するために、インバンド管理とアウトオブバンド管理の 2 つのオプションがあります。ファブリックに対して選択した管理オプションに応じて、NTP の設定が異なります。時刻同期の展開に関するもう 1 つの考慮事項は、時刻源の場所です。プライベート内部時刻または外部パブリック時刻の使用を決定する際は、時刻源の信頼性について慎重に検討する必要があります。
(注) |
|
アウトオブバンド管理 NTP:ACI ファブリックをアウトオブバンド管理とともに展開する場合、ファブリックの各ノードは、スパイン、リーフ、および APIC クラスタの全メンバーを含めて、ACI ファブリックの外部から管理されます。この IP 到達可能性を活用することで、各ノードは一貫した時刻源として同じ NTP サーバに個々に照会することができます。NTP を設定するには、アウトオブバンド管理のエンドポイント グループを参照する日付時刻ポリシーを作成する必要があります。日付時刻ポリシーは 1 つのポッドに限定され、ACI ファブリック内のプロビジョニングされたすべてのポッドに展開する必要があります。現在は、ACI ファブリックあたり 1 つのポッドのみが許可されます。
インバンド管理 NTP:ACI ファブリックをインバンド管理とともに展開する場合は、ACI のインバンド管理ネットワーク内から NTP サーバへの到達可能性を検討します。ACI ファブリック内で使用されるインバンド IP アドレッシングには、ファブリックの外部から到達できません。インバンド管理されているファブリックの外部の NTP サーバを使用するには、その通信を可能にするポリシーを作成します。 インバンド管理ポリシーの設定に使用される手順は、アウトオブバンド管理ポリシーの確立に使用される手順と同じです。 違いは、ファブリックが NTP サーバに接続できるようにする方法です。
NTP over IPv6 アドレスは、ホスト名とピア アドレスでサポートされます。gai.conf も、IPv4 アドレスのプロバイダーまたはピアの IPv6 アドレスが優先されるように設定できます。ユーザは、IP アドレス(インストールまたは優先順位よって IPv4、IPv6、または両方)を提供することによって解決できるホスト名を設定できます。
ユーザ アカウントの作成
初期の設定スクリプトで、管理者アカウントが設定され、管理者はシステム起動時の唯一のユーザとなります。APIC は、きめ細かなロールベースのアクセス コントロール システムをサポートしており、そのシステムでは、権限が少ない管理者以外のユーザを含め、ユーザ アカウントをさまざまなロールで作成することができます。
ローカル ユーザを設定する代わりに、APIC を一元化された企業クレデンシャルのデータセンターに向けることができます。APIC は、Lightweight Directory Access Protocol(LDAP)、Active Directory、RADIUS、および TACACS+ をサポートしています。
外部認証プロバイダーを通じて認証されたリモート ユーザを設定するには、次の前提条件を満たす必要があります。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
Cisco 属性/値(AV)ペアを既存のユーザ レコードに追加して、ユーザ権限を APIC コントローラに伝播することができます。Cisco AV ペアは、APIC ユーザに対してロールベース アクセス コントロール(RBAC)のロールと権限を指定するために使用する単一の文字列です。オープン RADIUS サーバ(/etc/raddb/users)の設定例は次のとおりです。
aaa-network-admin Cleartext-Password := "<password>" Cisco-avpair = "shell:domains = all/aaa/read-all(16001)"
ベスト プラクティスとして、シスコは、bash シェルでユーザに割り当てられる AV ペアには 16000 ~ 23999 の範囲の一意の UNIX ユーザ ID を割り当てることを推奨します(SSH、Telnet または Serial/KVM のコンソールを使用)。Cisco AV ペアが UNIX ユーザ ID を提供しない状況が発生すると、そのユーザにはユーザ ID 23999 または範囲内の類似した番号が割り当てられます。これにより、そのユーザのホーム ディレクトリ、ファイル、およびプロセスに UNIX ID 23999 を持つリモート ユーザがアクセスできるようになってしまいます。
属性/値(AV)のペア文字列のカッコ内の数字は、セキュア シェル(SSH)または Telnet を使用してログインしたユーザの UNIX ユーザ ID として使用されます。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
APIC コントローラには、管理ネットワークに到達するルートが 2 つあります。1 つはインバンド管理インターフェイスを使用し、もう 1 つはアウトオブバンド管理インターフェイスを使用します。
インバンド管理アクセス:APIC および ACI ファブリックへのインバンド管理接続を設定できます。APIC がリーフ スイッチと通信するときに APIC によって使用される VLAN を最初に設定し、次に VMM サーバがリーフ スイッチとの通信に使用する VLAN を設定します。
アウトオブバンド管理アクセス:APIC および ACI ファブリックへのアウトオブバンド管理接続を設定できます。アウトオブバンド エンドポイント グループ(EPG)に関連付けられるアウトオブバンド契約を設定し、外部ネットワーク プロファイルにその契約を接続します。
(注) | APIC アウトオブバンド管理接続のリンクは、1 Gbps である必要があります。 |
APIC コントローラは、インバンド管理インターフェイスが設定されている場合は、アウトオブバンド管理インターフェイスを通してインバンド管理インターフェイスを常に選択します。アウトオブバンド管理インターフェイスは、インバンド管理インターフェイスが設定されていない場合、または宛先アドレスが APIC のアウトオブバンド管理サブネットと同じサブネットにある場合にのみ使用されます。この動作は、変更または再設定できません。
APIC 管理インターフェイスは IPv6 アドレスをサポートしないため、このインターフェイスを介して外部 IPv6 サーバに接続することはできません。
インバンドまたはアウトオブバンドの管理テナントで外部管理インスタンス プロファイルを設定しても、ファブリック全体の通信ポリシーで設定されているプロトコルには影響しません。外部管理インスタンス プロファイルで指定されているサブネットおよびコントラクトは、HTTP/HTTPS または SSH/Telnet には影響しません。
インバンド管理アドレスは、ポリシーによってのみ(Postman REST API、NX-OS スタイル CLI、または GUI)APIC コントローラにプロビジョニングできます。また、インバンド管理アドレスは、各ノードに静的に設定する必要があります。
アウトオブバンド管理アドレスは、ブートストラップ時に、またはポリシーを使用して(Postman REST API、NX-OS スタイル CLI、GUI)APIC コントローラにプロビジョニングできます。また、アウトオブバンド管理アドレスは、各ノードに静的にまたはクラスタ全体にアドレスの範囲(IPv4/IPv6)を指定することによって設定する必要があります。IP アドレスは、範囲からクラスタ内のノードにランダムに割り当てられます。
管理アクセスの設定
(注) |
|
(注) |
|
APIC アウトオブバンド管理接続のリンクは、1 Gbps である必要があります。
すべての IPv6 は、ネットワーク アドレス変換(NAT)を除いて、既存の IP tables 機能をミラーリングします。
IP tables が作成されると、はじめにハッシュ マップに書き込まれ、次に中間ファイル IP tables-new に書き込まれてこれが復元されます。保存すると、新しい IP tables ファイルが /etc/sysconfig/ フォルダに作成されます。これら両方のファイルは同じ場所にあります。すべてのルールにシステム コールを行う代わりに、ファイルを復元および保存している時にのみシステム コールを行う必要があります。
ルールを追加する代わりに新しいポリシーがファイルに追加されると、hashmaps にデフォルト ポリシーをロードし、新しいポリシーを確認し、hashmaps に追加することによって、IP テーブルがゼロから作成されます。その後、中間ファイル(/etc/sysconfig/iptables-new)に書き込まれて保存されます。
アウトオブバンド ポリシーのルールの送信元ポートだけを設定することはできません。宛先ポートまたは送信元ポートいずれかを宛先ポートとともにルールに追加できます。
新しいポリシーが追加されると、新しいルールが IP tables ファイルに追加されます。このルールは、IP tables デフォルト ルールのアクセス フローを変更します。
-A INPUT -s <OOB Address Ipv4/Ipv6> -j apic-default
新しいルールが追加された場合、これは IP tables-new ファイルに存在して IP tables ファイルには存在せず、IP tables-new ファイルにエラーがあることを意味します。復元が正常な場合に限り、ファイルが保存され、新しいルールを IP tables ファイルで確認できます。
(注) |
|
アウトオブバンドとインバンド管理接続が設定されているかどうかに応じて、アウトオブバンドまたはインバンド ネットワークを使用する外部エンティティへの接続を確立します。vCenter Server などの外部エンティティへの接続を確立するには次の 2 つのモードを使用できます。
レイヤ 2 管理接続:外部エンティティがレイヤ 2 を使用してリーフ ノードに接続されている場合は、このモードを使用します。
レイヤ 3 管理接続:外部エンティティがレイヤ 3 を使用してルータを介してリーフ ノードに接続されている場合は、このモードを使用します。リーフは、外部エンティティに到達可能なルータに接続されます。
(注) |
|
次の図は、接続の確立に使用可能な 2 つのモードを示します。
(注) |
|
vCenter ドメイン プロファイルを作成する前に、インバンド管理ネットワークを使用して外部ネットワークを確立するための接続を確立する必要があります。
管理接続ポリシーの一部として設定された IP アドレス範囲が ACI ファブリックで使用されるインフラストラクチャの IP アドレス範囲と重複していないことを確認します。
(注) |
|
VMM ドメイン プロファイルを作成する前に、インバンド管理ネットワークを使用して外部ネットワークへの接続を確立する必要があります。
管理接続ポリシーの一部として設定された IP アドレス範囲が ACI ファブリックで使用されるインフラストラクチャの IP アドレス範囲と重複していないことを確認します。
この検証プロセスは、レイヤ 2 とレイヤ 3 の両方のモードに適用され、APIC GUI、REST API、または CLI を使用して確立される接続を確認するために使用できます。
管理接続を確立するための手順を完了したら、APIC コンソールにログインします。到達可能な vCenter Server の IP アドレス(たとえば、192.168.81.2)に ping を送り、その ping が機能することを確認します。この操作は、ポリシーが正常に適用されたことを示します。
VMM ドメインの設定
APIC は、サードパーティの VM マネージャ(VMM)(VMware vCenter および SCVMM など)と統合し、ACI の利点を仮想化されたインフラストラクチャに拡張します。APIC によって、VMM システム内の ACI ポリシーをその管理者が使用できるようになります。
ここでは、VMware vCenter および vShield を使用する VMM 統合の例を示します。シスコ ACI と VMM 統合の異なるモードに関する詳細については、『ACI Virtualization Guide』を参照してください。
(注) | vCenter との統合のために必要な APIC の設定に関する情報を次に示します。VMware コンポーネントの設定手順については、VMware のマニュアルを参照してください。 |
次は、VM マネージャの用語の詳細情報です。
VM コントローラは、VMware vCenter や VMware vShield などの、外部仮想マシン管理エンティティです。APIC は、コントローラと通信し、仮想ワークロードに適用されるネットワーク ポリシーを公開します。VM コントローラの管理者は、APIC 管理者に VM コントローラの認証クレデンシャルを提供します。同じタイプの複数のコントローラが同じクレデンシャルを使用できます。
クレデンシャルは、VM コントローラと通信するための認証クレデンシャルを表します。複数のコントローラが同じクレデンシャルを使用できます。
仮想マシンのモビリティ ドメイン(vCenter のモビリティ ドメイン)は、同様のネットワーキング ポリシー要件を持つ VM コントローラのグループです。この必須コンテナは、VLAN プールなどのためのポリシー、サーバ/ネットワーク MTU ポリシー、またはサーバ/ネットワーク アクセス LACP ポリシーとともに 1 つ以上の VM コントローラを保持します。エンドポイント グループが vCenter ドメインに関連付けられると、ネットワーク ポリシーが vCenter ドメイン内のすべての VM コントローラにプッシュされます。
導入する VMware vCenter では、VLAN モードまたは VXLAN モードで動作する必要があります。VMM ドメインは VLAN プールに関連付け、vShield は vCenter に関連付ける必要があります。
ACI ファブリックにより、リーフ ポートを通じて baremetal サーバ、ハイパーバイザ、レイヤ 2 スイッチ(たとえば、Cisco UCS ファブリック インターコネクト)、レイヤ 3 ルータ(たとえば、Cisco Nexus 7000 シリーズ スイッチ)などのさまざまな外部エンティティに接続する複数の接続ポイントが提供されます。 これらの接続ポイントは、リーフ スイッチ上の物理ポート、ポート チャネル、または仮想ポート チャネル(vPC)にすることができます。
接続可能エンティティ プロファイル(AEP)は、同様のインフラストラクチャ ポリシー要件を持つ外部エンティティのグループを表します。インフラストラクチャ ポリシーは、物理インターフェイス ポリシーで構成され、たとえば Cisco Discovery Protocol(CDP)、Link Layer Discovery Protocol(LLDP)、最大伝送単位(MTU)、Link Aggregation Control Protocol(LACP)などがあります。
VM マネージャ(VMM)ドメインは、AEP に関連付けられたインターフェイス ポリシー グループから物理インターフェイス ポリシーを自動的に取得します。
AEP でオーバーライド ポリシーを VMM ドメイン用の別の物理インターフェイス ポリシーを指定するために使用できます。このポリシーは、ハイパーバイザが中間レイヤ 2 ノードを介してリーフ スイッチに接続され、異なるポリシーがリーフ スイッチおよびハイパーバイザの物理ポートで要求される場合に役立ちます。たとえば、リーフ スイッチとレイヤ 2 ノード間で LACP を設定できます。同時に、AEP オーバーライド ポリシーで LACP をディセーブルにすることで、ハイパーバイザとレイヤ 2 スイッチ間の LACP をディセーブルにできます。
AEP は、リーフ スイッチで VLAN プールを展開するのに必要です。異なるリーフ スイッチ間でカプセル化プール(たとえば VLAN)を再利用することができます。AEP は、(ドメインに関連付けられた)VLAN プールの範囲を物理インフラストラクチャに暗黙的に提供します。
LLDP および CDP の設定の詳細については、本ガイドのブレード サーバとの連携に関する章を参照してください。
すべてのファブリック ノードが検出され、設定されている。
インバンド(inb)またはアウトオブバンド(oob)管理が APIC 上で設定されている。
Virtual Machine Manager(VMM)がインストールされ、設定されて、inb/oob 管理ネットワーク(たとえば、vCenter)経由で到達可能である。
VMM の管理者とルートのクレデンシャルがある(vCenter など)。
(注) | vCenter の管理者とルートのクレデンシャルを使用しない場合は、必要な最小アクセス許可を持つカスタム ユーザ アカウントを作成できます。必要なユーザ権限のリストについては、最小 VMware vCenter 権限を持つカスタム ユーザ アカウントを参照してください。 |
IP アドレスではなくホスト名で VMM を参照する予定がある場合は、APIC の DNS ポリシーを設定する必要があります。
VMware vShield のドメイン プロファイルを作成している場合は、DHCP サーバとリレー ポリシーを設定する必要があります。
Cisco APIC から vCenter を設定するには、vCenter で次の最小権限セットが許可されるクレデンシャルである必要があります。
これにより、APIC は vCenter に VMware API コマンドを送信して、DVS/AVS の作成、VMK インターフェイス(AVS)の作成、ポート グループの発行および必要なすべてのアラートのリレーを行うことができます。
この項では、VMM ドメインの例は、vCenter ドメインまたは vCenter および vShield ドメインです。
vCenter ドメインの作成時に行う作業の概要は次のとおりです(詳細は下のステップで説明します)。
vCenter および vShield ドメインの作成時に行う作業の概要は次のとおりです(詳細は下のステップで説明します)。
テナント、VRF、およびブリッジ ドメインの作成
テナントには、承認されたユーザのドメインベースのアクセス コントロールをイネーブルにするポリシーが含まれます。承認されたユーザは、テナント管理やネットワーキング管理などの権限にアクセスできます。
ユーザは、ドメイン内のポリシーにアクセスしたりポリシーを設定するには読み取り/書き込み権限が必要です。テナント ユーザは、1 つ以上のドメインに特定の権限を持つことができます。
マルチテナント環境では、リソースがそれぞれ分離されるように、テナントによりグループ ユーザのアクセス権限が提供されます(エンドポイント グループやネットワーキングなどのため)。これらの権限では、異なるユーザが異なるテナントを管理することもできます。
テナントには、最初にテナントを作成した後に作成できるフィルタ、契約、ブリッジ ドメイン、およびアプリケーション プロファイルなどのプライマリ要素が含まれます。
テナントの VRF およびブリッジ ドメインを作成および指定できます。定義されたブリッジ ドメイン要素のサブネットは、対応するレイヤ 3 コンテキストを参照します。
IPv6 ネイバー探索の有効化の詳細については、関連 KB 記事、「KB: Creating a Tenant, VRF, and Bridge Domain with IPv6 Neighbor Discovery」を参照してください。
このタスク例のビデオを視聴するには、Videos Webpage を参照してください。
外部ルーテッドを設定するときにパブリック サブネットがある場合は、ブリッジ ドメインを外部設定と関連付ける必要があります。
サーバまたはサービス ポリシーの設定
DHCP リレー ポリシーは、DHCP クライアントとサーバが異なるサブネット上にある場合に使用できます。クライアントが配置された vShield ドメイン プロファイルとともに ESX ハイパーバイザ上にある場合は、DHCP リレー ポリシー設定を使用することが必須です。
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 をサポートする必要があります。
このタスク例のビデオを視聴するには、Videos Webpage を参照してください。
アプリケーション EPG で使用されるポートおよびカプセル化は、物理または VM マネージャ(VMM)ドメインに属している必要があります。ドメインとのそのような関連付けが確立されていないと、APIC は EPG の展開を続行しますが、エラーを生成します。
Cisco APIC は、IPv4 と IPv6 の両方のテナント サブネットで DHCP リレーをサポートします。DHCP サーバ アドレスには IPv4 または IPv6 を使用できます。DHCPv6 リレーは、ファブリック インターフェイスで IPv6 が有効になっており、1 つ以上の DHCPv6 リレー サーバが設定されている場合にのみ、発生します。
レイヤ 2 またはレイヤ 3 管理接続が設定されていることを確認します。
DNS ポリシーは、ホスト名で外部サーバ(AAA、RADIUS、vCenter、サービスなど)に接続するために必要です。DNS サービス ポリシーは共有ポリシーであるため、このサービスを使用するすべてのテナントと VRF を特定の DNS プロファイル ラベルで設定する必要があります。ACI ファブリックの DNS ポリシーを設定するには、次のタスクを完了する必要があります。
管理 EPG が DNS ポリシー用に設定されていることを確認してください。設定されていない場合、このポリシーはスイッチで有効になりません。
DNS プロバイダーと DNS ドメインに関する情報が含まれる DNS プロファイル(デフォルト)を作成します。
DNS プロファイル(デフォルトまたは別の DNS プロファイル)の名前を必要なテナントで DNS ラベルに関連付けます。
テナントごと、VRF ごとの DNS プロファイル設定を設定することができます。適切な DNS ラベルを使用して、追加の DNS プロファイルを作成して、特定のテナントの特定の VRF に適用できます。たとえば、名前が acme の DNS プロファイルを作成する場合、テナント設定で acme の DNS ラベルを適切な
ポリシー設定に追加できます。次のように、サービスに対して外部宛先を設定します。
ソース | インバンド管理 | アウトオブバンド管理 | 外部サーバの場所 | ||
---|---|---|---|---|---|
APIC |
IP アドレスまたは完全修飾ドメイン名(FQDN) |
IP アドレスまたは FQDN |
Anywhere |
||
リーフ スイッチ |
IP アドレス |
IP アドレスまたは FQDN
|
Anywhere |
||
スパイン スイッチ |
IP アドレス |
IP アドレスまたは FQDN
|
リーフ スイッチに直接接続されます |
次に示すのは、外部サーバのリストです。
Call Home SMTP サーバ
Syslog サーバ
SNMP トラップの宛先
統計情報のエクスポートの宛先
エクスポートの設定の宛先
Techsupport のエクスポートの宛先
コア エクスポートの宛先
推奨されるガイドラインは次のとおりです。
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
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」を追加します。
options single-request-reopen nameserver 2001:4860:4680::8888 nameserver 2001:4860:4680::8844 nameserver 8.8.8.8 nameserver 8.8.4.4
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 の両方が存在するかどうかを認識していない場合、異なるアドレス ファミリを使用するフォールバック試行が実行されないことがあります。このようなアプリケーションでは、フォールバックの実装が必要な場合があります。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
レイヤ 2 またはレイヤ 3 管理接続が設定されていることを確認します。
スタティック ルートをアプリケーション セントリック インフラストラクチャ(ACI)ファブリック上の他のリーフ スイッチに配布する前に、マルチプロトコル BGP(MP-BGP)プロセスが最初に動作していて、スパイン スイッチが BGP ルート リフレクタとして設定されている必要があります。
ACI ファブリックを外部ルーテッド ネットワークに統合するために、管理テナントのレイヤ 3 接続に対し Open Shortest Path First(OSPF)を設定できます。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
ルータ ID と論理インターフェイス プロファイルの IP アドレスが異なっていて重複していないことを確認します。
次の手順は、管理テナントの OSPF 外部ルーテッド ネットワークを作成するためのものです。テナントの OSPF 外部ルーテッド ネットワークを作成するには、テナントを選択し、テナント用の VRF を作成する必要があります。
詳細については、トランジット ルーティングに関する KB 記事も参照してください。
(注) | このタスク例のビデオを視聴するには、Videos Webpage を参照してください。 |
ステップ 1 | メニュー バーで、 を選択します。 |
ステップ 2 | [Navigation] ペインで、 を展開します。 |
ステップ 3 | [External Routed Networks] を右クリックし、[Create Routed Outside] をクリックします。 |
ステップ 4 | [Create Routed Outside] ダイアログボックスで、次の操作を実行します。 |
ステップ 5 | [Create Node Profile] ダイアログボックスで、次の操作を実行します。 |
ステップ 6 | [Create Node Profile] ダイアログボックスで、[OSPF Interface Profiles] 領域の [+] アイコンをクリックします。 |
ステップ 7 | [Create Interface Profile] ダイアログボックスで、次のタスクを実行します。 |
ステップ 8 | [Create Node Profile] ダイアログボックスで、[OK] をクリックします。 |
ステップ 9 | [Create Routed Outside] ダイアログボックスで、[Next] をクリックします。 [Step 2 External EPG Networks] 領域が表示されます。 |
ステップ 10 | [External EPG Networks] 領域で、[+] アイコンをクリックします。 |
ステップ 11 | [Create External Network] ダイアログボックスで、次の操作を実行します。 |
アプリケーション ポリシーの展開
フィルタは、フィルタを含む契約により許可または拒否されるデータ プロトコルを指定します。契約には、複数のサブジェクトを含めることができます。サブジェクトは、単方向または双方向のフィルタを実現するために使用できます。単方向フィルタは、コンシューマからプロバイダー(IN)のフィルタまたはプロバイダーからコンシューマ(OUT)のフィルタのどちらか一方向に使用されるフィルタです。双方向フィルタは、両方の方向で使用される同一フィルタです。これは、再帰的ではありません。
契約は、エンドポイント グループ間(EPG 間)の通信をイネーブルにするポリシーです。これらのポリシーは、アプリケーション層間の通信を指定するルールです。契約が EPG に付属していない場合、EPG 間の通信はデフォルトでディセーブルになります。EPG 内の通信は常に許可されているので、EPG 内の通信には契約は必要ありません。
アプリケーション プロファイルでは、APIC がその後ネットワークおよびデータセンターのインフラストラクチャで自動的にレンダリングするアプリケーション要件をモデル化することができます。アプリケーション プロファイルでは、管理者がインフラストラクチャの構成要素ではなくアプリケーションの観点から、リソース プールにアプローチすることができます。アプリケーション プロファイルは、互いに論理的に関連する EPG を保持するコンテナです。EPG は同じアプリケーション プロファイル内の他の EPG および他のアプリケーション プロファイル内の EPG と通信できます。
アプリケーション ポリシーを展開するには、必要なアプリケーション プロファイル、フィルタ、および契約を作成する必要があります。通常、APIC ファブリックは、テナント ネットワーク内の Three-Tier アプリケーションをホストします。この例では、アプリケーションは 3 台のサーバ(Web サーバ、アプリケーション サーバ、およびデータベース サーバ)を使用して実行されます。Three-Tier アプリケーションの例については、次の図を参照してください。
Web サーバには HTTP フィルタがあり、アプリケーション サーバには Remote Method Invocation(RMI)フィルタがあり、データベース サーバには Structured Query Language(SQL)フィルタがあります。アプリケーション サーバは、SQL 契約を消費してデータベース サーバと通信します。Web サーバは、RMI 契約を消費して、アプリケーション サーバと通信します。トラフィックは Web サーバから入り、アプリケーション サーバと通信します。アプリケーション サーバはその後、データベース サーバと通信し、トラフィックは外部に通信することもできます。
この例での http 用のフィルタを作成するパラメータは次のとおりです。
パラメータ名 | http のフィルタ |
---|---|
名前 |
http |
エントリの数 |
2 |
エントリ名 |
Dport-80 Dport-443 |
Ethertype |
IP |
プロトコル |
tcp tcp |
宛先ポート |
http https |
この例での rmi および sql 用のフィルタを作成するパラメータは次のとおりです。
パラメータ名 | rmi のフィルタ | sql のフィルタ |
---|---|---|
名前 |
rmi |
sql |
エントリの数 |
1 |
1 |
エントリ名 |
Dport-1099 |
Dport-1521 |
Ethertype |
IP |
IP |
プロトコル |
tcp |
tcp |
宛先ポート |
1099 |
1521 |
この例のアプリケーション プロファイル データベースは次のとおりです。
EPG | 提供される契約 | 消費される契約 |
---|---|---|
Web |
Web |
rmi |
app |
rmi |
sql |
db |
sql |
-- |
GUI を使用したアプリケーション ポリシーの展開
3 つの個別のフィルタを作成します。この例では、HTTP、RMI、SQL です。このタスクでは、HTTP フィルタを作成する方法を示します。このタスクは、他のフィルタを作成するタスクと同じです。
テナント、ネットワーク、およびブリッジ ドメインが作成されていることを確認します。
ステップ 1 | メニュー バーで、[TENANTS] を選択します。[Navigation] ペインで、 を展開し、[Filters] を右クリックして、[Create Filter] をクリックします。
| ||
ステップ 2 | [Create Filter] ダイアログボックスで、次の操作を実行します。 | ||
ステップ 3 | [Name] フィールドの [Entries] を展開します。同じプロセスを実行して、別のエントリを宛先ポートとして HTTPS で追加し、[Update] をクリックします。 この新しいフィルタ ルールが追加されます。 | ||
ステップ 4 | さらに 2 つのフィルタ(rmi および sql)を作成し、rmi および sql 用のフィルタを作成するパラメータに示すパラメータを使用するには、上記手順の同じプロセスを実行します。 |
EPG が使用するポートは、VM マネージャ(VMM)ドメインまたは EPG に関連付けられた物理ドメインのいずれか 1 つに属している必要があります。
EPG 間のポリシー関係を作成するために、前に作成した契約を関連付けることができます。
提供するコントラクトと使用するコントラクトに名前を付けるときは、提供するコントラクトと使用するコントラクトの両方に同じ名前を付けてください。
ステップ 1 |
[Add Consumed Contract] ダイアログボックスが表示されます。 | ||
ステップ 2 | [Name] フィールドで、ドロップダウン リストから、sql 契約を選択します。[OK] をクリックします。 この手順により、db EPG は sql 契約を提供でき、app EPG は sql 契約を消費することができます。 | ||
ステップ 3 | APIC GUI 画面 をクリックして、app ePG から web EPG にドラッグします。 [Add Consumed Contract] ダイアログボックスが表示されます。 | ||
ステップ 4 | [Name] フィールドで、ドロップダウン リストから、rmi 契約を選択します。[OK] をクリックします。 この手順により、app EPG は rmi 契約を提供でき、web EPG は rmi 契約を消費することができます。 | ||
ステップ 5 | web EPG のアイコンをクリックし、[Provided Contracts] 領域の [+] 記号をクリックします。 [Add Provided Contract] ダイアログボックスが表示されます。 | ||
ステップ 6 | [Name] フィールドで、ドロップダウン リストから、web 契約を選択します。[OK] をクリックします。[Submit] をクリックします。 OnlineStore と呼ばれる 3 層アプリケーション プロファイルが作成されました。 | ||
ステップ 7 | 確認するには、[Navigation] ペインで、[Application Profiles] 下の [OnlineStore] に移動してクリックします。 [Work] ペインで、3 つの EPG app、db および web が表示されていることを確認できます。 | ||
ステップ 8 | [Work] ペインで、 を選択します。 消費/提供される順番で表示された EPG と契約を確認できます。 |