Chapter1. はじめに

- 概要

- はじめに

- 1.2（1）の新機能APIC

概要

Cisco Application Centric Infrastructure (ACI) は、現代の IT 自動化と DevOps においてインフラストラクチャをダイナミックに管理する新しい強力な方法を提供します。インフラストラクチャの構築方法を変えるツールがあるということも重要ですが、有効性や効率性を長期的に向上させるためには、構築時（Day 0）のアクティビティ以上に、インフラストラクチャを効率的に運用する能力が欠かせません。ACI を効果的に活用するために、組織は ACI を日常業務に組み込む方法を理解する必要があります。本書では、インフラストラクチャを継続的に運用するために IT チームが実施する一般的な運用アクティビティのいくつかを検証します。また、ACI ベースのファブリックで構築後（Day 1 以降）の運用をサポートするために採用可能なツール、手法、プロセスを紹介します。

本書で使用したハードウェアとソフトウェア

Cisco Application Centric Infrastructure (ACI) は、ハードウェア、ソフトウェア、ASIC イノベーションを組み合わせて統合システム アプローチを実現し、ネットワーク、アプリケーション、セキュリティ、仮想化に共通する管理フレームワークを提供します。

本書の執筆にあたっては、以下のハードウェア デバイスを使用しました。

- Application Policy Infrastructure Controller（APIC）

- ACI スパイン スイッチ（Cisco Nexus 9508 および 9336PQ など）

- ACI リーフ スイッチ（Cisco Nexus 9396PX、9396TX、93128TX など）

- Cisco Application Virtual Switch（AVS）

- Cisco UCS B シリーズおよび C シリーズ サーバ

- 複数のスイッチとルータのモデル（Cisco Nexus 5000 スイッチ、Cisco サービス統合型ルータ（ISR）など）

- さまざまなハイパーバイザ（KVM、Microsoft Hyper-V、VMware vSphere など）

- IXIA IxVM 製品ファミリのトラフィック ジェネレータ

本書の記述は、ACI 1.2 ソフトウェア リリースに基づいています。

はじめに

ACME 社について

ACME 社は、ロケット動力付きローラー スケート、ジェット式一輪車、各種爆発物など、多種多様な製品ポートフォリオの製造、販売、流通を専門としている多国籍企業です。各製品グループは、社内で個々のビジネス グループとして活動しており、これまでは、個々にインフラストラクチャとアプリケーションを保持していました。これらのグループは市場への小売りルートに重点を置いていましたが、オンライン販売チャネルを占めている新たな競合他社の出現に強い危機感を覚え、最近、より直販型のビジネス モデルを推進することを決定しました。さらに競争力を高める一助として、ACME はプロジェクトを立ち上げ、ポートフォリオ全体の顧客への製品提供に向けて、注文と流通をサポートするモバイル アプリケーション プラットフォームを構築することにしました。

従来、ACME の事業部門は IT 要求を満たすために、サードパーティのソフトウェア企業と市販のソフトウェアを利用していました。しかし、消費者とより親密な関係を築き、ユーザからのフィードバックをプラットフォームで直接得ることを望んでおり、また、市場の変動により俊敏に対応できるように、継続的な改善サイクルを組み込むことも望んでいます。これまで、カスタム ソフトウェアを使用していたときは、従来のインフラストラクチャおよびソフトウェア モデルを利用していたので、変化する要件に対応できませんでした。そのため、ACME はアプリケーションとインフラストラクチャ両方のライフサイクルを管理する新しいアプローチを探しています。アプリケーション開発者は、継続的デリバリや継続的インテグレーションなどの新たなアプリケーション開発傾向について調査し、新しいアプリケーション プラットフォームをこの方式で開発することにしました。これに対応するには、従来の概念では不可能な方法で、インフラストラクチャ コンポーネントをこれらの新しいパラダイムにマッピングできる必要があります。

ACME がこれまでに直面した最も大きな課題の 1 つは、運用とインフラストラクチャが製品開発の付け足しであったことです。このことはいくつかの問題を引き起こしています。アプリケーションを導入する際に、チーム全員が週末に長い時間を費やしているため、顧客に影響するような停止が生じ、さらに、完成までにビジネス リーダーの希望以上の時間がかかっていました。そのため、ACME 社 は環境の構築による変革を決意しました。この環境では、インフラストラクチャのアーティファクトをアプリケーションの一部として扱い、バージョン管理によりチェックして、実際のアプリケーションと同時にテストし、継続的に向上させることができます。

ACME は、新しいアプリケーション プラットフォームをタイムリーに配置することに大きな重点を置いています。その一方で、拡張してインフラストラクチャの共有プールを提供できる基盤づくりにも関心を示しています。このプールは、効率を高めるために、すべてのビジネス グループで共有され、マルチテナント方式で運用されます。

エグゼクティブ ブリーフィングで、Cisco Systems の当時の CEO、John Chambers 氏は ACME に次のように説明しました。「世界は変化しています。あらゆる企業がテクノロジー企業となっています。そのことを受け入れないと取り残されてしまいます」

Amazon Web Services（AWS）や OpenStack などのクラウド プラットフォームの成功によって実証されているように、技術提供型の消費モデルは急激なビジネス要件の変化により迅速に適応できます。これこそ、ACME 社 のビジネス オーナーに必要な消費タイプです。運用の管理は運用グループが重点を置いていることですが、管理は純粋な消費モデルのフォールトとなる可能性があります。企業が自動化コンポーネントの消費を可能にするテクノロジーに投資をしない場合、成長するために残された唯一の方法は、人的レベルのコンポーネントを破棄することですが、そのような企業で働くことを選ぶ人間はあまりいません。

さまざまなテクノロジー ベンダーからの現在の提案を分析した結果、ACME 社は Cisco Application Centric Infrastructure (ACI)を選択しました。とりわけ必要なのは、すべての物理的および仮想的なインフラストラクチャ構成を、開発、テスト、実稼働の全環境にわたって一貫性のある 1 つの構成にまとめる能力、および、現在 ACME が保持しているさまざまなデータセンターのロケーション全体における互換性です。ACI は、ネットワーク デバイスとプロトコルの構築に使用される下部構造を変更するためにゼロから構築されています。このレベルのイノベーションは、ユーザの対話用ツールを拡張する機会を提供します。ここでは、IT とインフラストラクチャがより動的であることに力点を置いています。つまり、ビジネスの速度に合わせて IT を運用および管理できるようにすることです。ただし、この種の変化は恐れ、不安、疑念を引き起こします。本書では、ACI ファブリックでの運用アクティビティにある程度の快適さと親しみやすさを感じてもらえるように図っています。

ACME 社は架空の企業ですが、この事例はあらゆる企業に該当し、重要なことは、そのような企業の従業員の事例でもあることです。IT 業界の従事者には、ビジネスの急激な変化についていく心構えが必要です。しかし、これは、ビジネスとテクノロジーの関係における大部分の運用グループの在り方に反しています。ほとんどの IT 運用グループは、現在のサービス提供に必要なツールにかなりの時間をかけているので、再投資には組織的な抵抗があります。考えるべきことは、「これまで機能してるものをなぜ変更するのか」ということです。

Why、Who、What、When、How

ACI について、ACME はインフラストラクチャの運用方法を単純化することに目を向けていますが、それは初歩に過ぎないと気づきました。このアプリケーションとインフラストラクチャは ACME 社にとって新しいものです。ACME は、誰が何を管理するのか、どのようにタスクに取り組むのかなど、基本的な問いに取り組む必要があります。さまざまなグループが通常操作を実行する時期や、それらの操作を実行する対象範囲についても検討する必要がありますが、これらにはより戦術的なポイントインタイムが関連します。ここでは以下のモニカに関連する事項について説明します。これらのモニカは、ACI ファブリックの運用、および ACME 社などの企業がワークロードを分割する方法に関連しています。

Why

「Why（理由）」は、ACI ファブリックを運用可能にするために考慮すべきことの中で最も重要な部分です。ACME 社の場合、主要な成功基準は、アプリケーション イニシアティブのサポートに必要なインフラストラクチャ展開のプロセスと手順を合理化することです。目的とする結果を得るには、高度な自動化が必要です。自動化は、繰り返しタスクを高速化し、エラーや工程漏れを排除します。当初、自動化は一部の仕事に対する脅威のように感じられるため、それらの関係者にとっては恐ろしい提案となる可能性があります。しかし、自動化はまったく逆のことをもたらします。チームのメンバー全員がより楽しく作業し、自由に価値を刷新して追加できるようになり、その一方で、日常的な繰り返しタスクがなくなります。ファブリックの自動化が組織にとって有益になる why（理由）を考えることは、期待投資利益率を設定する上で重要です。また、運用が特定の方法で実行される why（理由）を考えることも、使用するプロセスやツールを構想する上で役立ちます。

Who

多くの組織と同様、元来、ACME 社には IT イニシアティブの成功に関わっているさまざまなタイプの関係者がおり、それぞれが専門とするインフラストラクチャの特定要素を担当していました。これらのグループに対して明確な組織的境界を設けることもできますが、どの IT 組織でも、境界はある程度あいまいになっているようです。下記はこれらのグループの特徴の一部を示していますが、いくつの特徴が組み合わされている場合もあることに留意してください。マクロ レベルでは、さまざまな組織が存在しているということがエンドユーザにわからないようにするべきです。代わりに、組織全体が 1 つのチームとして、組織に価値をもたらす共通の目標に向かっているように映るべきです。

ACME の開発応用チームは、社内で使用するソフトウェアとアプリケーション、および顧客に提供するソフトウェアに重点を置いています。チームのアプリケーション担当部署にはアプリケーション製品の責任者と各部門の専門家がおり、他のビジネス部門がビジネス アプリケーションを活用して仕事を遂行できるように尽力しています。チームの開発担当部署は、モバイル アプリケーション ソフトウェアのプラットフォームを作成します。アプリケーションの設計、パフォーマンス、可用性がエンドユーザにとって最適なものになるように、両部署は同じ部門の他のチームと緊密に連携する必要があります。

ACME のネットワーク チームは、レイヤ 2（MAC/スイッチング）とレイヤ 3（IP ルーティング）でパケットを転送する、ネットワーク構成の構築と管理に重点を置いています。チームの課題は、高い可用性を保ちながら、アプリケーション要件のやりくり、SLA の管理、情報セキュリティの実施支援を行うことです。このチームは、ネットワーク構成の設定方法、レイヤ 3 とレイヤ 2 の結合方法、転送の検証方法、およびファブリック内のネットワーク転送に関するトラブルシューティング方法を理解している必要があります。ACIconrefACI を使用すると、チームは、過負荷のネットワーク構成を分離したり、解決を目指していた特定のネットワークの問題に立ち返ることができ、一方、他のグループは特定のチームの専門知識を活用してセキュリティやアプリケーション レベルのポリシーを操作できます。また、チームは、ネットワーク転送のパフォーマンスにおいてさらに高い透過性を実現し、セルフサービス容量内でオンデマンドで利用可能な主要メトリックを作成できます。

ACME のストレージ チームは、組織にデータ ストレージ リソースを配布することに主な重点を置いています。ストレージ チームは、可用性の面からデータの保護に取り組み、さらに、機密データの安全性も確保します。ストレージ チームは、非常に厳しい SLA の維持に大きな成功を収めており、これまで、ストレージ アクセス用の個々のインフラストラクチャを管理していました。ACI ファブリックによって提供される機能を使用することで、チームは新しい IP ベースのストレージおよびクラスタリング テクノロジーを自信を持って展開できます。チームは、ストレージ アクセスの実行の様子を確認できること、および競合の発生時に通知を受けることを望んでいます。チームは、主として、QoS の複数パスなどに関する特定の要件を抱えています。これまでは、ストレージ デバイスの管理に加えて、ストレージ ファブリックの配布にも気を使わなければなりませんでした。ACI は、ストレージ チームに必要とされる可視性をもたせます。これらの機能については、主にモニタリングの項で説明します。

ACME 社のコンピューティングおよび仮想化チームは、管理を担うサーバ ファームの仮想化という大きな取り組みを終えようとしています。最近、チームは、仮想化への取り組みとは別の新たなワークロードに対処し、仮想化への取り組みから得たのと同様のアジリティをベア メタル サーバにおいても実現するために、新しい設定管理ツールを採用しました。アプリケーションのロールアウトには仮想化と非仮想化の両方のワークロードがあるので、この採用はタイムリーです。また、アプリケーション開発者は、アプリケーションのポータビリティを大幅に向上させるために、Linux コンテナ テクノロジーの活用にますます関心を抱いています。コンピューティングおよび仮想化チームは、物理サーバと仮想サーバに共通のアクセスを提供する ACIconrefACI の機能に関心を示しています。この機能を使用すると、複数のハイパーバイザを集約した一か所から仮想化クラスタにエンドポイント グループをパブリッシュできます。これらの機能については、「ファブリック接続」の章で詳しく説明します。

ACME 社の情報セキュリティ チームは、従来、アプリケーション導入プロセスに関与し、脆弱性評価とデータの分類を担当していました。現在のプロジェクトでは、新しいアプリケーションにクレジット カード番号などの顧客機密情報が格納されます。この情報の機密性と ACIconrefACI ファブリックのセキュリティ面から見て、情報セキュリティ チームはプロセスの初期に入力を行うことで、セキュリティやコンプライアンスの問題による作業のやり直しを回避できます。情報セキュリティ チームは、ACI セキュリティ モデルの運用面に関心を持っています。これには、テナント、ロール ベース アクセス コントロール（RBAC）、モニタリング、およびレイヤ 4 ～ レイヤ 7 サービスが関連しているからです。

What

「What（何を）」についてはさまざまな面から考察できますが、本書における主要コンセプトは、ACI ファブリックの運用管理にどのようなツールを使用するかということです。これまでのネットワークでは、CLI や SNMP などの従来のツールを使用してネットワークの運用を管理し、ツールを管理プラットフォームや設定/管理プロセスに統合していました。

ACI には従来のツールの要素もいくつかありますが、ファブリックの管理は、より柔軟なベースを提供する抽象化オブジェクト モデルに基づいて行われます。このベースによって、ファブリック オペレータは複数のモードから選択できます（GUI、CLI、API 統合、プログラム、スクリプティング、またはこれらの組み合わせなど）。ACIconrefACI でのツールの選択方法は、実行内容とツールの使用方法によって決まります。たとえば、運用スタッフが多数のインターフェイスとスイッチから情報を収集する場合や、さまざまなオブジェクトを同時に管理する場合は、スクリプティングを使用すると効率的です。一方、単純なダッシュボードのモニタリングには GUI の方が適しています。

When

「When（いつ）」は、上記のチームが計画に関与する時期を示します。ファブリックの実装および管理方法に関するポリシーとプロセスを作成する際は、早い段階でさまざまなチームを関与させることをお勧めします。ACIconrefACI のコラボレーション特性によって、ワークフローの高度な並列化を実現できます。これは ACI と従来の処理との主要な相違点です。従来の処理は本質的に逐次的であるため、アプリケーションの開発に長い時間がかかり、問題が発生した場合の平均解決時間も長くなります。

How

「How（どのように）」は、以下の基本的な質問に対する回答です。

- ネットワーク担当者は、どのようにネットワーク転送の設定に取り組むのか。

- コンピューティング チームは、どのようにインフラストラクチャから情報を取得し、最適なワークロードの配置を決定するのか。

- アプリケーション チームは、どのようにパフォーマンスと使用メトリックを追跡するのか。

- ストレージ チームは、どのようにストレージ サブシステムへのアクセスを追跡し、それが性能基準を満たしていることを確認するのか。

「how（どのように）」に環境設定の変更が関連する場合は、変更の管理についても検討する必要があります。変更の管理は、ACI がサポート対象としているミッションクリティカルな環境において避けがたいことです。ACI ポリシー モデルは、フォールトドメインの全体サイズを削減し、増分変更のメカニズムを提供するように設計されています。バックアップと復元用のメカニズムがありますが、これらについては以降の章で説明します。また、このモデルについて、およびテナントやファブリック全体に影響を及ぼすオブジェクトについても説明します。

運用手順の変化に伴い、現行の変更管理や継続的な統合/デリバリ戦略の評価が必要になります。本書では、全体を通じて、ファブリックのプロアクティブおよびリアクティブな管理を取り上げています。

その根拠となるのは、ビジネス リスクを軽減してシステムの可用性を高めるために、大部分の組織がある種の構造化された変更管理方式を実装しているということです。変更/IT 管理に関するいくつかの基本原則（Cisco Lifecycle Services、FCAPS、および ITIL）があるので、それらを適切な指針として開始することができます。変更管理や継続的統合に対する共通認識アプローチの基礎となるのは、ファブリックを処理する前の設計実装サイクルの初期に、日常的なメンテナンス、モニタリング、プロビジョニングを行う運用チームと話し合うことです。達成基準（本書の目標の 1 つ）に関する運用チームのトレーニングも重要です。5 年前のテクノロジーに基づく変更管理方針を適用している状況では、ACI が提供するテクノロジーを迅速に導入できません。

ACI ソリューション固有のマルチテナント機能とロール ベース アクセス コントロール機能により、変更の範囲と影響をクリーン ボックスに入れて分離したり取り出すことができます。詳細については、ロールベース アクセス コントロールを参照してください。

最終的には、各変更の評価は基本的に業務に与えるリスクと価値の両方の観点から実施する必要があります。低オーバーヘッドの変更管理プロセスを可能にするための 1 つの方法は、それぞれの変更によるリスクを軽減し、価値を増大させることです。デリバリ プロセスの初期から定期的にリリースを実行し、ユーザからのフィードバックに基づいて、デリバリ チームが常に最も価値があることに取り組むことで、継続的デリバリにおいてこれを実現できます。

情報管理システムの分野では、3 種類の基本的変更があります。

- 緊急の変更

- 標準

- 規格

定義によると、緊急の変更はある種の技術的な機能停止（ハードウェア、ソフトウェア、インフラストラクチャ）への対応であり、影響を受けたシステムへのサービスを復旧するために実行されます。

通常の変更とは、変更要求の作成から始まり、検討、評価、承認または却下、計画と実装（承認された場合）という、一定の変換管理プロセスを経た変更です。ACI 環境では、通常の変更は次の構成要素内の項目に適用できます。」

- ファブリック ポリシー（ファブリック内部とアクセスについては後述）。

- 他のすべてのテナントと共有される、共通テナント内のコンフィギュレーション オブジェクト（ファブリック全体に影響を与えるもの）

- プライベート ネットワーク

- ブリッジ ドメイン

- Subnets

- Virtual Machine Manager（VMM）の統合

- レイヤ 4 ～ レイヤ 7 デバイス

- デバイス パッケージ

- 論理デバイスの作成

- 具体的なデバイスの作成

- レイヤ 2 またはレイヤ 3 外部コンフィギュレーション

- 接続可能エンティティ プロファイル（AEP）の作成

- サーバまたは外部ネットワークの接続

- トラフィックが流れる方向を実質的に変化させる、現在展開されているコントラクトとフィルタへの変更

標準の変更とは、事前承認された低リスクの変更です。それぞれの組織が、許可する標準の変更の種類、承認者、「標準」と見なす変更の基準、および変更管理プロセスを決定します。通常の変更と同様に、記録して承認する必要があります。ACI 環境における「標準」の変更の例は、次のとおりです。

- テナントの作成

- アプリケーション プロファイルの作成

- エンドポイント グループ（EPG）の作成

- テナント レベルでのコントラクト

- レイヤ 4 ～ レイヤ 7 サービス グラフ

- エンドポイント グループのドメインの関連付け

上記の項目はすべてのタスクを包括したものではなく、毎日または毎週実行される一般的なタスクを示しています。

環境に対する変更を監査する機能は、ACME 社にとって要件の 1 つです。 Application Policy Infrastructure Controller (APIC) はシステムに対するすべての設定変更の監査ログを保持します。これは、「何かが動作を停止した場合」に対処する主要なトラブルシューティング ツールです。緊急の対応として、監査ログを確認し、誰がどのような変更をいつ行ったかを調べ、その変更に起因するエラーと関連付けます。これにより、変更を迅速に元に戻すことができます。

インフラストラクチャの管理における継続的デリバリの詳細については、本書の範囲外です。

以降ではこれらの質問に回答しながら、コンセプトと手順の使用方法のフレームワーク、および組織内の同様の取り組みにそれらを適用する方法のフレームワークを示します。本書は一定の順序でレイアウトされています。しかし、ACI を使用することで、ACME 社は、全体を通じて取り上げられている関係者と並行してそれらのタスクを完了できます。また、本書では、関係者が以前よりも協力的な方法で連携して作業できる方法も示しています。本書全体を通じていくつかのスクリプト作成例が示されており、最後の項では、ACI API を使用して大部分の運用作タスクを自動化する方法が詳しく説明されています。組織構造がこれらのチームにサイロ化してしまう可能性がありますが、顧客、ユーザ、そして最終的にはビジネスにより高い価値をもたらす上で最も重要なことは、グループが相互に協力（insieme（インスィエーメ））して作業することです。

ACI は組織全体の IT 要件に対応

1.2（1）の新機能APIC

Application Policy Infrastructure Controller (APIC) リリース 1.2(1) で多数の新機能と機能拡張が採用されています。このセクションでは、新しい機能を強調し、概要を説明します。新しいハードウェア サポートを含む詳細については、Cisco Application Centric Infrastructure (ACI) ソフトウェアの使用しているバージョンのリリース ノートを参照してください。

基本 GUI

新しい「基本」GUI 動作モードが追加されました。APIC ログイン画面に、[Basic]または [Advanced] GUI モードを選択するオプションがあります。シンプル化された GUI の目的は、一般的なワークフローを実現するための簡単なインターフェイスを提供することです。GUI の動作モードを使用して、管理者はオブジェクト モデルについての最小限の知識で ACI を簡単に開始することができます。シンプル化された GUI により、スイッチ プロファイル、インターフェイス プロファイル、ポリシー グループ、またはアクセス エンティティ プロファイル（AEP）などの、高度なポリシーを設定する必要なく、リーフ ポートとテナントを設定できます。ACI 管理者は、必要に応じて、引き続き高度な（標準）GUI モードを使用できます。基本 GUI は ACI に新しく取り組むユーザにとっては有意義なものですが、シスコは大規模な運用、既存のファブリックの展開、およびより詳細なポリシー制御のためには、高度な GUI を活用することをお勧めします。

NX-OS スタイルの CLI

APIC の設定に対する既存のアプローチでは、ポリシー モデルのほとんどすべての側面へのユーザ アクセスが可能ですが、ポリシー モデルおよびフレームワークを包括的に把握する必要があります。NX-OS スタイルの CLI の前の APIC CLI 設定機能では ACI ポリシー モデルに関連するすべての管理対象オブジェクト（MO）の知識が必要で、CLI は mocreate および moconfig などのコマンドを使用して、UNIX ファイル システムとして表されるこれらの管理対象オブジェクトを作成、編集、保存することができました。このアプローチは、設定プロセスをできるだけ簡単にするために内部の詳細のほとんどを隠す Cisco IOS/NX-OS CLI 機能とは根本的に異なりました。既存の NX-OS スタイルのコマンド インターフェイスとより適切に連携するために、APIC の NX-OS スタイルの CLI が、ACI のポリシー モデルの詳細を知る負担なく、APIC の能力を利用する目的で導入されました。

APIC の新しい NX-OS スタイルの CLI は、使い慣れた NX-OS の構文をできるだけ多く使用します。NX-OS スタイルの CLI は、大規模にアプリケーションを展開する ACI ポリシー モデルの能力を犠牲にすることなく、必要に応じて基盤となる ACI ポリシー モデルを作成または変更するためのインテリジェンスを、ユーザ入力に提供します。

使用するモードにより、コマンドがその状況で有効ではない可能性があります。たとえば、ポッド設定モード [apic1(config-pod)#] の場合、show running-config ntp コマンドは、現在の NTP 設定を示しています。NTP 設定モード [apic1(config-ntp)#] の場合、show running-config server コマンドは、現在の NTP 設定を示しています。現在のモードを調べるには、where コマンドを使用します。次に例を示します。

apic1# where
exec
apic1# configure
apic1(config)# where
configure
apic1(config)# pod 1
apic1(config-pod)# where
configure; pod 1
apic1(config-pod)# ntp
apic1(config-ntp)# where
configure; pod 1; ntp

（注）

デフォルトでは、バージョン 1.2(1) 以降を実行している APIC への ssh の場合、以前のリリースのオブジェクト モデル CLI ではなく、NX-OS スタイルの CLI に自動的に配置されます。オブジェクト モデル CLI を使用するには、bash コマンドを使用します。次のコマンドを使用して、bash シェルで 1 つのコマンドを実行できます。

bash -c 'path/command'

次に例を示します。

bash -c '/controller/sbin/acidiag avread'

レイヤ 4 ～ レイヤ 7 のサービスに対するロールベースのアクセス コントロール ルールの強化

マルチテナント環境のレイヤ 4 ～ レイヤ 7 のポリシー設定では、従来のロールベース アクセス コントロール（RBAC）ドメインおよびロールを使用して、テナント管理者が作成できない特定のオブジェクトを作成するのに、管理者の介入が必要でした。これは、ACI ポリシー モデルの、よりきめ細かな RBAC の権限の要件を採用します。テナント管理者は、グローバルな管理者の介入なしに、セルフサービスを介して RBAC ルールを作成し、テナント サブツリーの下にあるリソースの権限をシステム内の他のテナントやユーザに付与することもできるようになりました。

入力ベースの ACL

通常、ファブリックは、宛先エンドポイント グループが L3Out である場合、またはハードウェア プロキシ モードのブリッジ ドメインで、宛先エンドポイントがどのエンドポイント グループにあるかを入力リーフ スイッチが認識していない場合などを除き、ポリシー適用のために入力エンドポイント グループベースのアクセス コントロール リスト（ACL）を使用します。これらの例外が発生しても、ポリシーの適用は、パケットがファブリックから発信されているときに発生します。

ACI 管理者は、境界リーフ（L3Out 接続が配置され、入力/出力ポリシーがこれまで適用されてきた）から着信接続の送信元の非境界リーフへ、ポリシーの適用を移動できるようになりました。目標は、L3Out 接続を利用しているテナントの境界リーフでプログラムする必要がある ACL ルールの数を削減することと、代わりに接続元の入力リーフ スイッチへとそれらを移行することです。

「Policy Control Enforcement Direction」という名前の新しい設定プロパティが、レイヤ 3 External Outside エンドポイント グループに追加されました。このプロパティは、L3Out の出力トラフィックのポリシー適用の方向を定義するために使用されます。新しいデフォルト設定は、新しく作成されたレイヤ 3 External エンドポイント グループの入力ですが、このソフトウェアのバージョンよりも前の既存の L3Out では、以前の動作が変更されないように、古いデフォルトの動作が出力モードで継続されます。以前に作成した L3Out は ACI 管理者により、入力モードに手動で変更できます。

トラブルシューティング ウィザードの機能拡張

バージョン 1.1(1) で導入されたトラブルシューティング ウィザード（TSW）は、単一のテナント内からのエンドポイント接続のテストに限られていました。これでは、エンドポイントのいずれかがユーザ テナントの外にある場合（共通テナントなど）、問題が表示されました。この機能は、テナント間のエンドポイントのテストをサポートするように改善されました。

APIC コンフィギュレーション ロールバック

設定のロールバック機能により、設定のスナップショットを作成でき、ローカルまたはリモートの場所に保存できます。2 つの保存されたスナップショットは、2 つの違いを特定するために使用することもできます。ファブリック ポリシーの変更が誤って行われた、またはそれにより問題が引き起こされた場合、スナップショットをロールバックして、変更されたポリシーのみを戻すことができます。既存かつ永続的なポリシーはこの操作中に影響を受けません。この機能には、スナップショットを自動化し、スケジュールする、組み込みの繰り返し機能が含まれています。スナップショットは、ファブリック全体またはユーザ テナント レベルで作成できます。

vRealize 統合

vRealize 自動化アプリケーションから APICポリシーの管理を可能にする、VMware の vRealize スイート用の ACI 固有プラグインが導入されました。ユーザは、オーケストレーションおよび自動化ソフトウェアを使用して、仮想コンピューティングおよびサービスに加えて、基礎となるファブリックをプロビジョニングできるようになりました。プラグインは、定義済みの APIC ポリシー、ワークフロー、ブループリントへのアクセスを提供します。

レイヤ 4 ～ レイヤ 7 サービス用のアンマネージド モード

レイヤ 4 ～ レイヤ 7 サービスの挿入機能によって、管理者は 1 つ以上のサービスを 2 つのエンドポイント グループ間に挿入できます。APIC はサービスのファブリック リソース（VLAN）を割り当て、サービス グラフで指定された設定に基づいてファブリック（リーフ）およびサービス アプライアンスをプログラムします。以前は、APIC には、サービス グラフの一部として使用するレイヤ 4 ～ レイヤ 7 のサービスに対するデバイス パッケージが必要でした。この処理の一部は、グラフのインスタンス化時の APIC のサービス アプライアンスのプログラミングを含んでいました。

一部の環境では、グラフのインスタンス化時に、APIC はサービス グラフのネットワーク リソースのみを割り当て、ファブリック側のみをプログラムすることが望ましい場合があります。これは、さまざまな理由で必要とされる可能性があります。たとえば、サービス アプライアンスをプログラムするために、既存のオーケストレータまたは DevOps ツールがすでにある環境の場合です。別の一般的な場合として、サービス アプライアンス用のデバイス パッケージがそのプラットフォームでは使用できない可能性がある場合です。

サービスのアンマネージド モードは必要な柔軟性を向上させます。有効にすると、サービス アプライアンス向けネットワーク リソースの割り当てと、ファブリック（リーフ）のプログラムのみに APIC を制限します。デバイスの設定は、外部でのお客様による実行に任せられます。

簡易ネットワーク管理プロトコル（SNMP）のサポート APIC

次の拡張機能が APIC とファブリック スイッチの既存の SNMP エージェントに追加されました。

- ISIS の隣接状態の変化トラップ

- 温度センサーのしきい値トラップ

- 電源インレット回線またはケーブルの状態変化トラップ

- CPU 使用率しきい値トラップ

vSphere 6 のサポート

VMM の vSphere 6.0 と vCenter 6.0 との統合が APIC バージョン 1.1(2) で導入されました。サポートには VMware Virtual Distributed Switch（vDS）の統合のみが含まれていました。Cisco AVS に対する追加のサポートは、このリリースに含まれています。リリース 1.2(1) での唯一のサポート制限は、vCenter 間と、vDS vMotion 間は AVS でサポートされないということです。これらの機能は、VMware vDS で完全にサポートされます。

共通パーベイシブ ゲートウェイ

複数のファブリックが展開されている ACI 展開で、1 つのファブリックから別のファブリックへのエンドポイントの移動には、ヘアピン トラフィックを回避するためにデフォルト ゲートウェイまたは IP アドレスを変更する必要がありました。この機能により、何も変更する必要なく、ファブリック間のエンドポイントのシームレスな移動が可能になります。

この機能を設定するには、各ファブリックに同様に設定された 2 つのブリッジ ドメインの設定が必要です。各ファブリックのブリッジ ドメインは、同じ仮想 IP アドレスと仮想 MAC アドレスを使用して設定され、それにより物理ファブリックがどこに存在しているかに関係なく、ブリッジ ドメインのエンドポイントからの到達可能性がもたらされます。

Microsoft マイクロセグメンテーション（uSeg）のサポート

APIC ソフトウェア リリース 1.1(1) では、ACI に属性ベースのエンドポイント グループ（別名 uSeg）の概念が導入されました。これにより、仮想マシン属性（VM 名、OS タイプ、およびハイパーバイザなど）、IP アドレスおよび仮想マシンと一致する MAC 設定を含む、さまざまな属性で定義された「uSeg EGP」と呼ばれる特別なエンドポイント グループが有効になります。属性の照合は、その uSeg エンドポイント グループのポリシーを仮想エンドポイントに動的に適用します。仮想ポート グループのバインディングを再度割り当てる必要はありません。このリリースより前では、VMware 仮想マシンのみがサポートされていました。現在は、Microsoft HyperV 仮想マシンにもサポートの対象が拡大されました。

Direct Server Return

エンドポイントがロード バランサの背後に配置されると、クライアントの要求はロード バランサに送信され、次に宛先サーバにリレーされます。サーバがクライアントに応答すると、同じパスを通過してロード バランサへ、さらにクライアントへと戻ります。これにより、しばしばロード バランサが通信のボトルネックとなり、ネットワーク パフォーマンスを低下させる可能性があります。Direct Server Return では、宛先サーバが直接クライアントに応答でき、ロード バランサを経由してリレーされる必要はありません。

共有レイヤ 3 Out

以前のソフトウェア リリースでは、レイヤ 3 Out 接続の導入方法と、複数のテナントによる使用に制限がありました。多くの場合、ユーザは同じゲートウェイ デバイスを使用しているテナントにもかかわらず、テナントごとにレイヤ 3 Out のポリシーを定義する必要がありました。

このリリースではこの機能が改善され、テナントまたは VRF が、異なるテナントに設定されたレイヤ 3 Out 接続を使用できる機能が追加されました。この機能の一般的な使用例は、複数のユーザ テナントにより共有される「共通」テナントのレイヤ 3 Out を含むファブリックです。これは 2 つのテナント間で学習したルートをリーキングすることによって実現されます。

この機能の 1 つの制限は、中継ルーティングとも言われる、共有 L3Out 接続から渡される 1 つのテナントの学習ルートの交換がサポートされないことです。

Chapter2. 管理

- APIC の概要

- 管理プロトコルの設定

- ロールベース アクセス コントロール

- インポートおよびエクスポート ポリシー

APIC の概要

従来のネットワーク ハードウェアと Cisco Application Centric Infrastructure (ACI) ファブリックの運用にはいくつかの基本的な相違があります。これらの相違点として、管理の大幅な簡素化、タッチポイント数の減少、目的とする設定インテントからのスイッチング ハードウェアの分離などがあげられます。変更点には次の項目が含まれます。

- コントローラ ベースのアーキテクチャによる一元管理

- ステートレス ハードウェア

- 指定した状態型の結果整合性モデル

ACI アーキテクチャにおける管理の一元化は、Application Policy Infrastructure Controller (APIC) として知られています。このコントローラによって、すべての設定、管理、モニタリング、ヘルスの機能にアクセスできます。アプリケーション プログラミング インターフェイス（API）を使用した集中型コントローラを装備するということは、ファブリックによって設定またはアクセスされるすべての機能に、グラフィカル ユーザ インターフェイス（GUI）、コマンドライン インターフェイス（CLI）、API を介して一様にアクセスでき、各種データ インターフェイス間で不整合が発生するリスクがないことを意味します。これにより、インターフェイス間における正常で予測可能な遷移が実現されます。すべてのアクセス方法の基本インターフェイスは、REST ベースの API を介して提供されます。この API は、クラスタ内の APIC 全体に複製される同期済みデータベースの内容を変更し、すべてのインターフェイス間に抽象レイヤを提供します。

このコントローラ ベースのアーキテクチャによって、実行している構成からハードウェアを分離するステートレスな設定モデルが可能になります。これは、リーフおよびスパイン スイッチの個々のファブリック ノードを管理する APIC クラスタに変換されます。これらのスイッチは、シャーシのシリアル番号やデバイスの設定ファイルからではなく、コントローラが必要なインテントとして定義したものから ID を取り出します。各ノードは一意のノード ID を受け取り、これによって、デバイスがコントローラから適切な設定属性をダウンロードできるようになります。デバイスはステートレスな方法で置き換えることができます。つまり、ハードウェア スワップが速くなり、トポロジの変更による影響が軽減され、ネットワーク管理が簡素化されます。

構成に対して指定した状態モデルは約束理論（Promise Theory）という概念に基づいており、宣言型制御ベースの管理と呼ばれる概念を利用して、コントローラ ベースの管理とステートレス状態に関する概念を補完します。宣言型制御は、詳細に指定しなくても、各オブジェクトが目的の状態を実現して「promise（約束）」を果たすように指示します。これは、命令型制御の従来モデルと対照的です。従来モデルでは、管理対象の各要素は、何を実行するべきかの正確な指示と、その実行方法の指定が必要であり、現在の状態から設定済みの状態に移行できるかどうかに影響する特定の状況を考慮することが必要です。宣言型制御に基づくシステムでは、命令型制御システムに比べてはるかに効率的なスケーリングが可能です。これは、管理側のコントローラの指示により、ドメイン内の各エンティティ自体が、現在の状態と、目的の状態になるために必要な手順とを把握しているためです。

新しい APIC 機能の詳細については、ご使用のソフトウェアリリースの 『Cisco Application Policy Infrastructure Controller Release Notes』 を参照してください。

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/ tsd-products-support-series-home.html

管理プロトコルの設定

ACME のシスコ アプリケーション セントリック インフラストラクチャ（ACI）ファブリックを最適化するために、ネットワーク チームは次の管理プロトコル ポリシーを作成しました。

- Cisco Discovery Protocol（CDP）：CDP は既存のネットワーク機器の標準ポリシーであるため、主にネットワーク チームによって使用されます。

- Link Layer Discovery Protocol（LLDP）：検出プロトコルは、ネットワーク デバイスだけに限定されなくなりました。LLDP はトポロジ関係を検出するための標準プロトコルです。ACME は、サーバ、レイヤ 4 ～ レイヤ 7 サービス、デバイス、ストレージ アレイに LLDP を展開します。したがって、これらのポリシーはすべてのチームで使用可能になります。

- ネットワーク タイム プロトコル（NTP）：アプリケーション ログとインフラストラクチャ コンポーネントにおいて正確な時刻を維持することは、イベントを関連付ける上で非常に重要です。ACME には既存の NTP サーバがあるので、それらを活用して ACI ファブリックの展開で時間を維持します。ACI では、正確な時刻はアトミック カウンタなどの機能の前提条件であるため、正確な時刻の維持は非常に重要です。

- ドメイン ネーム サービス（DNS）：アプリケーション チームやサーバ チームとの一貫性を保つように、ファブリック コンポーネントの名前を解決します。ファブリック内の名前を解決できることに加えて、重要な ACI コンポーネントが ACME の DNS サーバに登録されるので、チームは各自の管理タスクにおいてそれらに簡単にアクセスできます。

- GUI を使用した Cisco Discovery Protocol ポリシーの作成

- GUI を使用した Link Layer Discovery Protocol ポリシーの作成

- 時刻同期と NTP

- GUI を使用したアウトオブバンド管理 NTP の設定

- NX-OS スタイルの CLI を使用したアウトオブバンド管理 NTP の設定

- インバンド管理 NTP

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

- NX-OS スタイルの CLI を使用した NTP ポリシー設定の確認

- NX OS スタイルの CLI を使用した NTP ポリシーが各ファブリック スイッチに展開されていることの確認

- オブジェクト モデル CLI を使用した NTP ポリシーが各ファブリック スイッチに展開されていることの確認

- NX OS スタイルの CLI を使用した NTP ポリシーが各 APIC に展開されていることの確認

- オブジェクト モデル CLI を使用した NTP ポリシーが各 APIC に展開されていることの確認

- ドメイン ネーム サービス（DNS）

- NX-OS スタイルの CLI を使用したコントロール プレーン ポリシングの表示

GUI を使用した Cisco Discovery Protocol ポリシーの作成

Cisco Discovery Protocol（CDP）は、物理およびデータリンク層の問題をトラブルシューティングするための有用な情報源です。ACI の運用中に、CDP のオン/オフ ポリシーを使用して、特定のホスト側のポートを手動でプロビジョニングしなければならない場合もあります。デフォルトでは、ACI ファブリックは、CDP が無効化されているデフォルトのポリシーを備えています。推奨事項として、CDP が有効な「CDP 対応」ポリシーを手動で作成し、さらに、すべてのインターフェイス ポリシー設定から参照できる、CDP が無効な「CDP 非対応」ポリシーを作成することをお勧めします。

CDP ポリシーを作成する手順：

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [CDP Interface] の順に選択します。

3. [Work] ペインで、[Actions] > [Create CDP Interface Policy] の順に選択します。

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

1. [Name] フィールドに、ポリシーの名前を入力します（「CDP-ENABLED」など）。

2. [Admin State] オプション ボタンで、[Enabled] をクリックします。

3. [Submit] をクリックします。`

5. [Work] ペインで、[Actions] > [Create CDP Interface Policy] の順に選択します。

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

1. [Name] フィールドに、ポリシーの名前を入力します（「CDP-DISABLED」など）。

2. [Admin State] オプション ボタンで、[Disabled] をクリックします。

3. [Submit] をクリックします。`

これで、CDP ポリシーをインターフェイス ポリシー グループに割り当てられるようになりました。

GUI を使用した Link Layer Discovery Protocol ポリシーの作成

Link Layer Discovery Protocol（LLDP）は、物理およびデータリンク層の問題をトラブルシューティングするための有用な情報源です。ACI の運用中、デフォルトでは、ファブリックで LLDP 機能が有効になります。ACI ファブリックの運用中、エンドホスト デバイスの相互運用性の要件を満たすために、手動で LLDP プロトコルを調整しなければならない場合があります。たとえば、Cisco Unified Computing System（UCS）ブレード サーバに接続するときは、LLDP を無効にする必要があります。

今後のインターフェイス ポリシーの導入決定を合理化して簡単に設定できるように、事前プロビジョニングして LLDP を有効化し、プロトコル ポリシーを無効化することをお勧めします。

LLDP ポリシーを作成する手順：

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [LLDP Interface] の順に選択します。

3. [Work] ペインで、[Actions] > [Create LLDP Interface Policy] の順に選択します。

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

1. [Name] フィールドに「LLDP-TX-ON-RX-ON」と入力します。

2. [Receive State] オプション ボタンで、[Enabled] をクリックします。

3. [Transmit State] オプション ボタンで、[Enabled] をクリックします。

4. [Submit] をクリックします。`

5. [Work] ペインで、[Actions] > [Create LLDP Interface Policy] の順に選択します。

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

1. [Name] フィールドに「LLDP-TX-ON-RX-OFF」と入力します。

2. [Receive State] オプション ボタンで、[Disabled] をクリックします。

3. [Transmit State] オプション ボタンで、[Enabled] をクリックします。

4. [Submit] をクリックします。`

7. [Work] ペインで、[Actions] > [Create LLDP Interface Policy] の順に選択します。

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

1. [Name] フィールドに「LLDP-TX-OFF-RX-ON」と入力します。

2. [Receive State] オプション ボタンで、[Enabled] をクリックします。

3. [Transmit State] オプション ボタンで、[Disabled] をクリックします。

4. [Submit] をクリックします。`

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

1. [Name] フィールドに「LLDP-TX-OFF-RX-OFF」と入力します。

2. [Receive State] オプション ボタンで、[Disabled] をクリックします。

3. [Transmit State] オプション ボタンで、[Disabled] をクリックします。

4. [Submit] をクリックします。`

これで、LLDP ポリシーは、インターフェイス ポリシー グループの一部として使用できるようになりました。

時刻同期と NTP

Cisco Application Centric Infrastructure (ACI) ファブリック内で、時刻同期は、次のタスクを含むモニタリング、運用、およびトラブルシューティングタスクの多くが依存する重要な機能です。

- Application Policy Infrastructure Controller (APIC) およびファブリック スイッチは、証明書を使用して相互間の暗号化された通信チャネルを確立します。APIC とスイッチとの間の時間差が顕著に大きくなると（7 時間を超えると）、スイッチは、既存の通信チャネルを切断するか、または APIC の新たな通信チャネルを作成しなくなり、手動でスイッチの時間を設定するまで、スイッチはファブリックから分離されます。

- クロック同期は、トラフィック フローの適切な分析にとって重要であり、複数のファブリック ノード間でデバッグとフォールトのタイム スタンプを関連付けるためにも重要です。1 つ以上のデバイスでオフセットが生じると、多くの一般的な運用問題を適切に診断して解決する機能がブロックされる可能性があります。また、クロック同期によって、アプリケーションのヘルススコアが依存している ACI の内蔵アトミック カウンタ機能をフル活用できます。

ファブリックまたはアプリケーション全体を展開する前に、それらの機能を適切に使用できるよう時刻同期を設定する必要がありますが、時刻同期の設定が存在しないかまたは不適切であるためにフォールトや低ヘルス スコアが必ずしも発生するわけではありません。デバイスのクロックを同期させる最も一般的な方法は、ネットワーク タイム プロトコル（NTP）を使用することです。アトミック カウンタの詳細については、アトミック カウンタを参照してください。

NTP を 設定する前に、どの管理 IP アドレス スキームを ACI ファブリックに配置するかを検討してください。すべての ACIノードと APIC の管理を設定するために、インバンド管理とアウトオブバンド管理の 2 つのオプションがあります。ファブリックに対して選択した管理オプションに応じて、NTP の設定が異なります。

時刻同期の展開に関するもう 1 つの考慮事項は、時刻源の場所です。プライベート内部時刻または外部パブリック時刻の使用を決定する際は、時刻源の信頼性について慎重に検討する必要があります。

GUI を使用したアウトオブバンド管理 NTP の設定

ACI ファブリックをアウトオブバンド管理と共に展開する場合、ファブリックの各ノードは、スパイン、リーフ、および APIC クラスタの全メンバーを含めて、ACI ファブリックの外部から管理されます。この IP 到達可能性を活用することで、各ノードは一貫した時刻源として同じ NTP サーバに個々に照会することができます。

NTP を設定するには、アウトオブバンド管理のエンドポイント グループを参照する日付時刻ポリシーを作成する必要があります。日付時刻ポリシーは 1 つのポッドに限定され、ACI ファブリック内のプロビジョニングされたすべてのポッドに展開する必要があります。このドキュメントの発行時点では、ACI ファブリックごとに 1 つのポッドだけが許可されています。

GUI を使用して NTP の設定するには、次の手順に従います。

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

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

3. [Work] ペインで、[Actions] > [Create Date and Time Policy] の順に選択します。

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

1. 環境内のさまざまな NTP 設定を簡単に識別できる名前をポリシーに対して指定します（「Production-NTP」など）。

2. Next をクリックします。

3. [+] 記号をクリックし、使用する NTP サーバ情報（プロバイダー）を指定します。

4. [Create Providers] ダイアログボックスで、次のフィールドを含めて、すべての関連情報を入力します。[Name]、[Description]、[Minimum Polling Intervals]、および [Maximum Polling Intervals]

1. 複数のプロバイダーを作成する場合は、最も信頼できる NTP 時刻源の [Preferred] チェックボックスをオンにします。

2. ファブリックのすべてのノードがアウトオブバンド管理によって NTP サーバに到達できる場合は、[Management EPG] ドロップダウン リストで、[Out-of-Band] を選択します。インバンド管理を展開した場合は、「インバンド管理 NTP」の項を参照してください。

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

5. 作成する各プロバイダーごとにステップ c と d を繰り返します。

これで、NTP ポリシーを ACI ファブリック ノードに展開できるようになりました。

NX-OS スタイルの CLI を使用したアウトオブバンド管理 NTP の設定

NX-OS スタイルの CLI を使用して、ファブリックのデフォルト ポッドの POD 1 に対し NTP サーバを設定できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure

ステップ 3

POD 1 の設定モードを入力します。

apic1(config)# pod 1

ステップ 4

NTP 設定モードを入力します。

apic1(config-pod)# ntp

ステップ 5

NTP サーバを設定します。

apic1(config-ntp)# server 192.168.29.35 prefer use-vrf oob-mgmt

この設定では、NTP ソースとして IP アドレス 192.168.29.35 を優先し、そこに到達するために VRF oob-mgmt（アウトオブバンド管理）を使用します。

インバンド管理 NTP

ACI ファブリックがインバンド管理とともに導入されている場合は、ACI インバンド管理ネットワーク内から（前面パネル リーフ ポートにより到達可能な送信元から）NTP サーバへの到達可能性を考慮してください。インバンド管理されているファブリックの外部の NTPサーバを使用するには、その通信を可能にするポリシーを作成する必要があります。インバンド管理ポリシーの設定に使用する手順は、アウトオブバンド管理ポリシーの設定に使用する手順と同じです。相違点は、NTP サーバへのファブリックの接続を許可する方法に関することです。

通信を許可するポリシーを設定したら、「アウトオブバンド管理 NTP」の項と同じ手順で、NTP ポリシーを作成できます。

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

NTP 機能の完全な検証は、Cisco Application Centric Infrastructure (ACI) CLI と Application Policy Infrastructure Controller (APIC) GUI の両方を使用することで最適に遂行できます。すべてのポリシーが APIC GUI 内で正しく設定されていることを確認して、時刻同期設定の確認を開始します。ポリシーの設定は、次の手順を使用して確認できます。

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

2. [Navigation] ペインで、[Pod Policies] > [Policies] > [Date and Time] > [ntp_policy] > [server_name] の順に選択します。[ntp_policy] は前に作成したポリシーです。

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

NX-OS スタイルの CLI を使用した NTP ポリシー設定の確認

NX-OS スタイルの CLI を使用して、NTP ポリシー設定を確認できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure

ステップ 3

POD 1 の設定を表示します。

apic1(config)# show running pod 1 ntp
# Command: show running-config pod 1 ntp
# Time: Mon Nov 9 17:17:18 2015

ステップ 4

POD 1 の設定モードを入力します。

apic1(config)# pod 1

ステップ 5

NTP 設定モードを入力します。

apic1(config-pod)# ntp

ステップ 6

NTP サーバを設定します。

apic1(config-ntp)# server 192.168.29.35 prefer use-vrf oob-mgmt

ステップ 7

設定モードを終了します。

apic1(config-ntp)# exit
apic1(config-pod)# exit

NX OS スタイルの CLI を使用した NTP ポリシーが各ファブリック スイッチに展開されていることの確認

ポリシーが各ノードに正常に展開されたことを確認するには、APIC にある NX-OS Virtual Shell を使用する必要があります。NX-OS Virtual Shell にアクセスするには、任意の APIC ノードのアウトオブバンド管理 IP インターフェイスに対して SSH セッションを開きます。このプロンプトで「version」コマンドを実行し、ノード ホスト名の統合リストを取得します。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

APIC が認識しているスイッチを探します。

apic1# show switch
ID   Address      In-Band Address  OOB Address     Version       Flags  Serial Number  Name
---  -----------  ---------------  --------------  ------------  -----  -------------  ------
101  10.0.136.64  192.168.1.14     10.122.254.241  n9000-11.2(1  aliv   ABC1234DEF5    Leaf-1
k)
...

ステップ 3

スイッチに接続します。

apic1# ssh admin@Leaf-1

ステップ 4

NTP ピアのステータスを表示します。

Leaf-1# show ntp peer-status
Total peers : 1
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
remote                local              st  poll  reach delay   vrf
-----------------------------------------------------------------------------
*192.168.129.235    0.0.0.0         3     64      377   0.00142 management

到達可能な NTP サーバの IPアドレスの前にはアスタリスク（*）が付き、遅延がゼロ以外の値になります。

ステップ 5

ファブリックのすべてのノードに対して、ステップ 3 と 4 を繰り返します。

オブジェクト モデル CLI を使用した NTP ポリシーが各ファブリック スイッチに展開されていることの確認

ポリシーが各ノードに正常に展開されたことを確認するには、APIC にある NX-OS Virtual Shell を使用する必要があります。NX-OS Virtual Shell にアクセスするには、任意の APIC ノードのアウトオブバンド管理 IP インターフェイスに対して SSH セッションを開きます。このプロンプトで「version」コマンドを実行し、ノード ホスト名の統合リストを取得します。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

オブジェクト モデル CLI に切り替えます。

apic1# bash
admin@apic1:~>

ステップ 3

attach コマンドを入力して Tab キーを 2 回押し、使用可能なノードの名前をすべて表示します。

admin@apic1:~> attach <Tab> <Tab>
Leaf-1  Node name
Leaf-2  Node name
Spine-1 Node name
apic-1  Node name
apic-2  Node name
apic-3  Node name

ステップ 4

APIC へのアクセスに使用したのと同じパスワードを使用して、ノードのいずれかにログインします。

admin@apic1:~> attach Leaf-1
# Executing command: ssh Fab2-Leaf1
...

ステップ 5

NTP ピアのステータスを表示します。

Leaf-1# show ntp peer-status
Total peers : 1
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
remote                local              st  poll  reach delay   vrf
-----------------------------------------------------------------------------
*192.168.129.235    0.0.0.0         3     64      377   0.00142 management

到達可能な NTP サーバの IPアドレスの前にはアスタリスク（*）が付き、遅延がゼロ以外の値になります。

ステップ 6

ファブリックのすべてのノードに対して、ステップ 3 と 4 を繰り返します。

NX OS スタイルの CLI を使用した NTP ポリシーが各 APIC に展開されていることの確認

NX OS スタイルの CLI を使用して、ポリシーが各 Application Policy Infrastructure Controller (APIC) に正常に展開されていることを確認できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

show ntpq コマンドを実行して、NTP サーバとそのステータスのリストを取得します。

apic1# show ntpq
nodeid   remote         refid     st    t   when   poll   reach    delay   offset   jitter
------ - -------------  --------  ----  --  -----  -----  -------  ------  -------  -------
1      * 192.168.38.65  .GPS.     u     27  64     377    76.427   0.087   0.067
2      * 192.168.38.66  .GPS.     u     3   64     377    75.932   0.001   0.021

オブジェクト モデル CLI を使用した NTP ポリシーが各 APIC に展開されていることの確認

オブジェクト モデル CLI を使用して、ポリシーが各 APIC に正常に展開されていることを確認できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

オブジェクト モデル CLI に切り替えます。

apic1# bash
admin@apic1:~>

ステップ 3

ntpq -p コマンドを実行して、NTP サーバとそのステータスのリストを取得します。

admin@apic1:~> ntpq -p
remote              refid           st t when poll reach delay offset jitter
=======================================================================
*adc-mtv5-c1-1.c 192.168.1.5   3  u 58   64   377     1.712 6.180  5.170

追加のコマンドを表示するには、 APIC で man ntpq コマンドを使用します。

ドメイン ネーム サービス（DNS）

DNS サーバを設定すると、APIC によってさまざまなホスト名を IP アドレスに解決できます。これは、VMM ドメインまたはレイヤ 4 ～ レイヤ 7 デバイスとホスト名との結びつきを参照する際に役立ちます。

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

2. [Navigation] ペインで、[Global Policies] > [DNS Profiles] > [default]> の順に選択します。

3. [Work] ペインで、[Management EPG] ドロップダウン リストから適切な管理 EPG を選択します。 注: デフォルトは デフォルト（帯域外）です。

4. [DNS Providers] の横にある [+] をクリックして、DNS プロバイダーを追加します。

1. [Address] フィールドに、プロバイダー アドレスを入力します。

2. 優先するプロバイダーとしてこのアドレスが必要な場合は、[Preferred] フィールドで、チェックボックスをオンにします。注：優先できるプロバイダーは 1 つだけです。

3. [Update] をクリックします。

5. 追加する DNS プロバイダーごとにステップ 4 を繰り返します。

6. [DNS Domains] の横にある [+] をクリックして、DNS ドメインを追加します。

1. [Name] フィールドに、ドメイン名を入力します（「cisco.com」など）。

2. [Default] フィールドで、チェックボックスをオンにして、このドメインをデフォルト ドメインにします。注：デフォルトにできるのは 1 つのドメイン名だけです。

3. [Update] をクリックします。

7. 追加する DNS ドメイン サフィックスごとにステップ 6 を繰り返します。

8. [送信（Submit）] をクリックします。

- オブジェクト モデル CLI を使用した DNS の動作の確認

オブジェクト モデル CLI を使用した DNS の動作の確認

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

オブジェクト モデル CLI に切り替えます。

apic1# bash
admin@apic1:~>

ステップ 3

resolv.conf ファイルを確認します。

admin@apic1:~> cat /etc/resolv.conf
# Generated by IFC
search acme.com
nameserver 192.168.168.183
nameserver 192.168.131.10

ステップ 4

APIC アウトオフバンド管理から到達可能なホストを DNS 名によって ping します。

admin@apic1:~> ping acme.com
PING acme.com (192.168.4.161) 56(84) bytes of data.
64 bytes from www.acme.com (192.168.4.161): icmp_seq=1 ttl=241 time=42.7 ms
64 bytes from www.acme.com (192.168.4.161): icmp_seq=2 ttl=241 time=42.4 ms
64 bytes from www.acme.com (192.168.4.161): icmp_seq=3 ttl=241 time=43.9 ms
^C
--- acme.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2102ms
rtt min/avg/max/mdev = 42.485/43.038/43.903/0.619 ms
admin@apic1:~>

NX-OS スタイルの CLI を使用したコントロール プレーン ポリシングの表示

リーフまたはスパイン スイッチ上にリストされているプロトコルのコントロール プレーン ポリシングを表示するには、show system internal aclqos brcm copp entries unit 0 コマンドを使用します。コマンドの出力により、スイッチのデフォルトの動作を理解し、不要なコントロール プレーンの負荷によるスイッチのパフォーマンス問題を監視できます。ネットワーク動作の相違を見つけるには、これらのパラメータのアドホック モニタリング用に、次のコマンドを使用できます。

次の例は、コマンドの出力を示しています。

module-1# show system internal aclqos brcm copp entries unit 0
Protocol  CPUQ  Entry-ID  Priority  Counter-ID  Rate  Burst  GreenPkts
OSPF      1     603       0         603         2000  2000   2584133
EIGRP     30    575       0         575         2000  2000   0

GreenBytes  RedPkts  RedBytes
373659784   0        0
0           0        0

ロールベース アクセス コントロール

シスコ アプリケーション セントリック インフラストラクチャ（ACI）ファブリックを操作する上で、ロール ベース アクセス コントロール（RBAC）とテナントは習得する必要がある重要な概念です。テナントの概念およびロール ベースのアクセスは、ACI 管理とポリシー モデルを構築するための 2 つの中心基盤です。

ACI ファブリックでは、Cisco Application Policy Infrastructure Controller（APIC）は、設定で定められているユーザのロールに基づいて、すべてのオブジェクトへのアクセスを許可します。各ユーザは、一連のロール、権限のタイプ、およびセキュリティ ドメインに割り当てることができます。ここでは、Who、What、Where という観点から考えてみます。ロールとは誰であるか（Who）（権限の論理的集合）を示し、権限はユーザがどのような（What）機能を実行できるかを定義し、セキュリティ ドメインはユーザがアクションを実行できる対象範囲（Where）を定義します。これらのオブジェクトを組み合わせることで、非常に詳細なアクセス コントロールをシステムで実現できます。

ロールの分類とはアクセス許可をグループ化したものです。たとえば、fabric-admin はファブリック全体へのアクセスに加え、他のユーザ ロールを割り当ててセキュリティ ドメインに関連付けることができます。一方、tenant-admin は、関連付けられているテナント内のコンポーネントにのみアクセスでき、ファブリック レベルで他のユーザ ロールを割り当てることはできません。ACME の IT 組織はこのアクセス コントロール モデルに完全に適合しています。

APIC は、ユーザのロールに従って RBAC によりアクセスを提供します。ACI ファブリック ユーザは、次に関連付けられています。

- ロールのセット

- ロールごとに、権限と権限タイプ（「アクセスなし」、「読み取り専用」、「読み取り/書き込み」）

- ユーザがアクセスできる管理情報ツリー（MIT）の一部を識別する 1 つ以上のセキュリティ ドメイン タグ

認証されたユーザの作成ライフサイクル

ACI ファブリックは、管理対象オブジェクト（MO）レベルでアクセス権限を管理します。権限は、システム内の特定の機能に対するアクセスを許可または制限する MO です。たとえば、fabric-equipment は特権フラグです。このフラグは、物理ファブリックの機器に対応するすべてのオブジェクトに、APIC によって設定されます。

APIC ポリシーは、シスコ ACI ファブリックのアクセス、認証、およびアカウンティング（AAA）機能を管理します。ユーザ権限、ロール、セキュリティ ドメインをアクセス権限の継承とを組み合わせることにより、管理者は管理対象オブジェクト レベルで非常に詳細に AAA 機能を設定することができます。これらの設定は、REST API、CLI、または GUI を使用して実行できます。

- マルチテナントのサポート

- GUI を使用したユーザ ロールの表示

- セキュリティ・ドメイン

- GUI を使用したセキュリティ ドメインの作成

- GUI を使用したユーザの追加

マルチテナントのサポート

コア APIC 内部データ アクセス コントロール システムにより、マルチテナントの分離が実現され、テナント間での個人情報の漏洩が防止されます。読み取り/書き込みの制約により、テナントによる他のテナントの設定、統計情報、障害、またはイベント データの参照が防止されます。管理者によって読み取り権限が割り当てられない限り、テナントはファブリックの設定、ポリシー、統計情報、障害、またはイベントの読み取りが制限されます。

仮想マシン管理（VMM）ドメインがセキュリティ ドメインでタグ付けされている場合、セキュリティ ドメイン内のユーザは、対応する VMM ドメインにアクセスできます。たとえば、solar という名前のテナントに sun というセキュリティ ドメインのタグが付いており、VMM ドメインにも sun というセキュリティ ドメインのタグが付いている場合、solar テナント内のユーザは各自のアクセス権限に従って VMM ドメインにアクセスできます。

GUI を使用したユーザ ロールの表示

組み込みのユーザ ロールを表示したり、特定の要件に適したカスタム ロールを作成できます。

1. メニュー バーで、[Admin] > [AAA] の順に選択します。

2. [Navigation] ペインで、[Security Management Roles] を選択します。ここでは、それぞれの組み込みロールと関連する特権を表示できます。また、[Actions] メニューからカスタム ロールを作成できます。

セキュリティ・ドメイン

セキュリティ ドメインの概念は、ACI ファブリックを適切に運用するために重要です。セキュリティ ドメインを使用することで、さまざまな権限構造にユーザを組み入れることができます。最も一般的にはテナントに適用されます。ACI ファブリックのテナント機能を適切に設定されたセキュリティ ドメインと併用すると、必要とするユーザにのみアクセスを提供しながら、アプリケーション ワークロードの設定を完全に分離することができます。

セキュリティ ドメインを設定する際に留意すべき主要な概念は、設定はテナント レベルでのみ適用されるということです。APIC の RBAC 画面ではオブジェクト レベルで参照できますが、現時点では、ポリシーは個々のオブジェクトに適用できません。

テナントを展開する前に、セキュリティ ドメインとアクセス レベルを設定することをお勧めします。また、「all」ドメイン権限を変更することによって、ユーザ アクセス設定を行うことはお勧めしません。「all」ドメインでの変更は、すべてのユーザのアクセス権限に影響します。選択的に変更して、ユーザのセキュリティ ドメイン外へのアクセスを許可する必要がある場合は、必ず、その通信専用のユーザ アクセス ポリシーを個別に設定してください。

GUI を使用したセキュリティ ドメインの作成

ACI ファブリックでは、デフォルトで 3 つのセキュリティ ドメイン（「all」、「common」、「mgmt」）がプロビジョニングされます。通常、「all」セキュリティ ドメインには、管理情報ツリー（MIT）内のすべてに対するアクセス権限があります。「common」は、通常、DNS やディレクトリ サービスなど、テナント間で共有リソースが必要な場合に使用されます。「mgmt」セキュリティ ドメインは、管理トラフィック ポリシー用です。必要に応じてセキュリティ ドメインを追加できます。たとえば、マルチテナント環境の場合は、各テナントごとにセキュリティ ドメインが作成されます。次に、ユーザが作成され、特定のセキュリティ ドメインやテナントに割り当てられます。

MIT の詳細については、次の URL にあるドキュメントを参照してください。

http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/aci-fabric-controller/white-paper-c11-729586.html

セキュリティ ドメインを作成する手順：

1. メニュー バーで、[ADMIN] > [AAA] の順に選択します。

2. [Navigation] ペインで、[Security Management] > [Security Management] の順に選択します。

3. [Work] ペインで、[Actions] > [Create a Security Domain] の順に選択します。

4. [Create a Security Domain] ダイアログボックスで、次の操作を実行します。

1. セキュリティ ドメインの名前、および説明（任意）を入力します。

GUI を使用したユーザの追加

ACI ファブリック内に新しいユーザを追加する必要がある場合があります。ACI には管理者によって手動でローカル ユーザを入力できます。また、LDAP、RADIUS、Active Directory、TACACS+ などを使用して、ACI ネットワークの一部を管理するユーザを指定できます。

ローカル ユーザを設定する手順：

1. メニュー バーで、[ADMIN] > [AAA] の順に選択します。

2. [Navigation] ペインで、[AAA Authentication] を選択します。

3. [Local] をまだ選択していない場合は、[Work] ペインで、[Realm] ドロップダウン リストから [Local] を選択し、[Submit] をクリックします。

4. [Navigation] ペインで、[Security Management] を選択します。

5. [Work] ペインで、[Actions] > [Create Local User] の順に選択します。

6. [Create Local User] ダイアログボックスで、次の操作を実行します。

1. 必要なセキュリティ情報を指定し、[Next] をクリックします。

2. 管理者またはテナント管理者用の読み取り/書き込みなど、ユーザに割り当てる [Roles] を選択し、[Next] をクリックします。

3. ユーザーのログイン情報を指定します。

7. [完了（Finish）] をクリックします。

インポートおよびエクスポート ポリシー

新しいモバイル アプリケーション プラットフォームの展開と管理に関係する ACME のすべての人員は、各自がコンフィギュレーションの消失から簡単かつ迅速に回復できることを確認する必要があります。APIC のポリシーと設定データはすべて、ディザスタ リカバリ、トラブルシューティング、オフライン分析用のバックアップやテニカル サポート ファイルを作成するためにエクスポートできるので、ACI はこの面でも適しています。APIC の他のすべてと同様、ポリシーを設定してエクスポートするか、設定ポリシーをバックアップする必要があります。これは、ACI ファブリック内の完全に適合するアクティブな APIC から実行できます。バックアップと復元プロセスでは、個々のコンポーネントのバックアップは必要ありません。

エクスポート ポリシーによりバックアップを設定し、リモート サーバに定期的または即時にバックアップすることができます（推奨）。外部 SCP/FTP サーバを使用できない場合、バックアップはローカル APIC ファイル システムに書き込まれます。

バックアップ/エクスポート ポリシーは、オンデマンドで実行するか、定期的スケジュールに基づいて実行するように設定できます。大きなシステム設定変更を行う場合や、ソフトウェアのアップデートを適用する場合は、その前に現在のバックアップを実行することをお勧めします。設定のインポート ポリシー（ポリシーの復元）については、この項の後半で説明します。

デフォルトでは、すべてのポリシーとテナントがバックアップされますが、管理者は管理情報ツリーの特定のサブツリーだけを選択して指定できます。これは、個々のテナントごとにポリシーをバックアップまたは復元する必要がある、マルチテナント展開において役立ちます。

また、テクニカル サポート情報を収集する場合にも、エクスポート ポリシーが必要です。システム内で問題が発生した場合は、Cisco Technical Assistance Center（TAC）に連絡する必要があります。テクニカル サポート バンドルを提出すると、シスコのサポート エンジニアは、問題を特定して修復案を提示するために必要な情報を得ることができます。テクニカル サポートのエクスポート ポリシーは、オンデマンドで実行するか、定期的に繰り返して実行するように設定できます。テクニカル サポート バンドルは、設定のエクスポート ポリシーと非常によく似た手順で設定できるので、ここではバンドルの詳細について説明しません。テクニカル サポートのエクスポート ポリシーの詳細については、本書の付録に示されている『Cisco APIC Troubleshooting Guide』を参照してください。

- 設定のエクスポート（バックアップ）

- GUI を使用したリモート ロケーション（SCP）の追加

- GUI を使用したワンタイム エクスポート ポリシーの作成

- GUI を使用したポリシーが正常にエクスポートされたことの確認

- GUI を使用した設定ファイルの取得と表示

- GUI を使用した設定のインポート（復元/マージ）

- GUI を使用した設定のロールバック

設定のエクスポート（バックアップ）

ACI はポリシー主導型であるため、バックアップ以外の作業も行う必要があります。まず、リモート ロケーション（情報のエクスポート先となる外部サーバ）を作成し、次に、エクスポート ポリシー タスクと、必要に応じて（繰り返しタスク用の）スケジューラを作成します。以下の手順は、ACI でリモート ロケーションとエクスポート ポリシーを作成し、SCP サーバに設定ファイル バンドルを転送する方法を示しています。設定バンドルがデスクトップに転送された後、個々の XML ファイルを取り出して表示できます。作成された tar.gz ファイルを圧縮解除するには、解凍ユーティリティが必要です。

設定のエクスポート ポリシー

GUI を使用したリモート ロケーション（SCP）の追加

1. メニュー バーで、[Admin] > [Import/Export] の順に選択します。

2. [Navigation] ペインで、[Remote Locations] を選択します。

3. [Work] ペインで、[Actions] > [Create Remote Location] の順に選択します。

4. [Create Remote Location] ダイアログボックスで、次の操作を実行します。

1. リモート ロケーションの名前を入力します。

2. ホスト名/IP アドレスを入力します。

3. プロトコルを選択します。

4. リモート パスを入力します。

5. リモート ポートを入力します。

6. ユーザ名を入力します。

7. パスワードを入力します。

8. 管理 EPG を選択します。デフォルトはアウトオブバンドです。

5. [送信（Submit）] をクリックします。

GUI を使用したワンタイム エクスポート ポリシーの作成

以下は設定のエクスポート ポリシーを作成する手順を示していますが、テクニカル サポートのエクスポート ポリシーの手順とよく似ています。

1. メニュー バーで、[Admin] > [Import/Export] の順に選択します。

2. [Navigation] ペインで、[Export Policies] > [Configuration] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Configuration Export Policy] の順に選択します。

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

1. Name：Export_Policy_Name

2. Format：XML

3. Start Now：Yes

4. Export Destination：Choose_the_Remote_location_created_above

5. [Submit] をクリックします。`

繰り返し操作を設定する場合は、2 つのオプション設定をスケジューラ ポリシーに適用し、管理情報ツリー（MIT）のサブセットのみをバックアックする場合は、特定の識別名（DN）を指定します。

GUI を使用したポリシーが正常にエクスポートされたことの確認

1. メニュー バーで、[Admin] > [Import/Export] の順に選択します。

2. [Navigation] ペインで、[Export Policies] > [Configuration] > [Export_Name] の順に選択します。

3. [Work] ペインで、[Operational] タブをクリックします。

1. エクスポートが正常に完了すると、[State] が [pending] から [Success] に変わります。

2. （任意）SCP サーバで、バックアップ ファイル名があることを確認します。

GUI を使用した設定ファイルの取得と表示

設定のエクスポート タスクは、個々の XML ファイルの圧縮バンドルをエクスポートします。これらの XML 設定ファイルは別のワークステーションで取得して表示できます。

1. エクスポートしたバンドルがコピーされているワークステーションで、アーカイブ ユーティリティを選択します。

2. 設定のエクスポート ファイル（tar.gz）があるフォルダに移動し、ファイルを強調表示して、[Extract] を選択します。

3. いずれかの XML ファイルをダブルクリックし、ブラウザで内容を表示します。

4. さまざまな XML 設定ファイルを表示して、設定されているパラメータを確認します。

GUI を使用した設定のインポート（復元/マージ）

設定をインポートするには、リモート ロケーションが必要です。リモート ロケーションが存在しない場合は、[Adding a Remote Location (SCP)] セクションごとにリモート ロケーションを作成します。

以前のバックアップから設定を復元する手順：

1. メニュー バーで、[Admin] > [Import/Export] の順に選択します。

2. [Navigation] ペインで、[Import Policies] > [Configuration] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Import Configuration Policy] の順に選択します。

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

1. インポート ポリシーの名前とファイル名（「backup-file.tar.gz」など）を入力します。ファイル パスを含めないでください。

2. インポート タイプを選択します。

- Merge：既存の実行されている設定とバックアップ設定をマージします。 既存のポリシーは書き換えられません。

- Replace：すべての設定をバックアップ ファイルの設定に置き換えます。

3. [Merge] インポートを実行する場合は、インポート モードを指定する必要があります。設定データはモジュールごとにインポートされます。各モジュールにはシステム設定オブジェクトの特定部分が含まれています。デフォルトは [best-effort] です。[Replace Import Mode] は次のいずれかになります。

- best-effort - 各モジュールがインポートされ、無効なオブジェクトはスキップされます。

- atomic - 無効な設定を含むモジュールはスキップしながら、各モジュールをインポートしようとします。このモードでインポートする場合、モジュールのすべての設定が有効である必要があります。

4. [Start Now] を選択します。

5. [Adding a Remote Location (SCP)] セクションで作成したリモート ロケーションを選択します。

GUI を使用した設定のロールバック

APIC の設定のスナップショットを作成できます。これにより、不適切な設定の変更を迅速にロールバックできるようになります。設定のロールバックは手動または繰り返しポリシーとして設定できます。設定のエクスポートと設定のロールバックの違いは、設定のロールバックは APIC に残すことができることです。設定のエクスポートは、SCP/FTP/SFTP サーバなど、外部の場所が必要です。設定のスナップショットはファブリックまたはテナント レベルで実行できます。

ACME 社 は保護手段として、毎日の設定のエクスポート ポリシーに加えて、毎日のファブリック全体の設定のスナップショットを設定することを決定しました。

手順

ステップ 1

メニュー バーで、[Admin] > [Config Rollbacks] の順に選択します。

ステップ 2

[Work] ペインで、右上部の繰り返しスナップショット ポリシーのアイコンをクリックします。

ステップ 3

[Automatic Snapshot] ダイアログボックスで、ポリシーが有効になっていることを確認します。[Enable/Disable] を切り替えます。

ステップ 4

[Automatic Snapshot] ダイアログボックスで、実行する繰り返しスナップショットの [Days of the Week] および [Time] を選択します。

デフォルトでは、スナップショットは APIC に保存されたままになります。

ステップ 5

（任意） スナップショットをリモートの場所に保存する場合は、[Remote Location] を選択するか、新しく作成します。

ステップ 6

[Submit] をクリックして変更を保存します。

Chapter3. ファームウェアのアップグレードとダウングレード

- ファームウェア管理

- アップグレードとダウングレードに関する考慮事項

ファームウェア管理

ACME 社はシスコと協力して、必要なソフトウェア機能、選択したハードウェア プラットフォームのサポート、およびソフトウェア リリースの完成度に基づき、展開の要件を評価しました。また、展開するソフトウェアの対象バージョンを選択しました。さらに、定期的にこの決定に立ち返って、さらにアップグレードが必要かどうかを判断するために、プロアクティブな計画を立てました。

- ファームウェア バージョン

- ファームウェアのコンポーネント

- ファームウェアのポリシー

ファームウェア バージョン

Cisco Application Centric Infrastructure (ACI) のソフトウェア バージョンは、次のような形式で示されます。

major.minor(maintenance)

- major：製品のアーキテクチャ、プラットフォーム、または機能内容の大きな変更を表します。

- minor：新しいソフトウェア機能を備えたマイナー リリースを表します。

- maintenance：Application Policy Infrastructure Controller (APIC) の機能リリースへのバグ修正を表します。これは、新機能が追加されたときではなく、ソフトウェアの不具合が修正されたときに変化します。

次の例では、いくつかの APIC バージョンを示します。

1.0(1e)
1.1(1j)
1.2(1i)

APIC ソフトウェアとファブリック ノードの両方は、同じバージョン スキームによって示されます。たとえば、APIC 1.2(1i) リリースは、スイッチ ソフトウェア 11.2(1i) リリースに対応します。APIC バージョンのリリース ノートと対応するスイッチ バージョンは、相互に関連しています。

APIC、リーフ スイッチ、スパイン スイッチなど、ACI インフラストラクチャのコンポーネントはすべて同じバージョンでなければなりません。アップグレード時に、APIC とスイッチ間に異なるバージョンが存在する場合は、その状態のままファブリックを長時間操作しないでください。

アップグレードによる影響とリスクを検討する場合、メンテナンス バージョンのアップグレード（1.1(1j) => 1.1(1o) など）は、バグの修正のみで新機能の追加がないため、メジャーまたはマイナー バージョンのアップグレードよりも影響が小さいと想定できます。

ファームウェアのコンポーネント

次の 3 つの主要コンポーネントをアップグレードできます。

- スイッチ（リーフとスパイン）

- Application Policy Infrastructure Controller（APIC）

- カタログ ファームウェア

ファームウェアのポリシー

ファームウェア グループ

Application Policy Infrastructure Controller (APIC) のファームウェア グループ ポリシーは、ファームウェアをアップグレードするノード グループを定義します。大部分の展開では、ファームウェア グループは 1 つだけで十分です。

メンテナンス グループ

メンテナンス グループ ポリシーは、いっしょに関連するファームウェア セットにアップグレードするスイッチ グループを定義します。メンテナンス グループは、オンデマンドで、またはスケジュールに従ってアップグレードできるので、ビジネス メンテナンスの時間帯までアップグレード タスクを延期できます。通常、2 つのメンテナンス グループがあり、それぞれにリーフとスパインのセットが含まれます。各メンテナンス グループは別々にアップグレードされます。

コントローラ ファームウェア

APIC のファームウェア ポリシーはクラスタ内のすべてのコントローラに適用されますが、アップグレードは常に順番に実行されます。APIC GUI により、ファームウェア アップグレードに関するリアルタイムのステータス情報が提供されます。コントローラ ファームウェア ポリシーは、オンデマンドで、またはスケジュールに従ってアップグレードできます。

カタログ ファームウェア

各ファームウェア イメージには、サポート対象のスイッチ モデルを識別する互換性カタログが含まれています。APIC は、ファームウェア イメージ、スイッチ タイプ、およびそのファームウェア イメージを使用することを許可されるモデルのカタログを保持しています。イメージ管理を実行する APIC には、互換性カタログ、APIC のファームウェア イメージおよびスイッチ イメージのイメージ リポジトリがあります。

ファームウェア アップグレード ポリシーの関係

アップグレードとダウングレードに関する考慮事項

アップグレードまたはダウングレード プロセスを開始する前に、次の事項を考慮してください。

- Application Policy Infrastructure Controller (APIC) クラスタの状態：アップグレード プロセスを開始する前に、コントローラの状態が良好であることを確認します。続行する前に、クラスタ内のすべてのコントローラのヘルス ステータスが [Fully Fit] であることを確認します。完全に適合（Fully Fit）していないコントローラの問題を解決するには、『Troubleshooting Cisco Application Centric Infrastructure』のドキュメントを参照してください。

- 設定のバックアップ：アップグレードを開始する前に、必ず、外部ソースに設定をエクスポートします。設定のエクスポートについては、「インポートおよびエクスポート ポリシー」を参照してください。

- 権限：ファームウェア アップグレード タスクを実行するには、ファブリック管理者ロールが必要です。

- 空き領域の確認：/firmware パーティションの使用率が 75% 以下であることを確認します。パーティションの使用率が 75% を超えている場合は、圧縮イメージを格納したり、イメージを取得する十分なスペースを確保できるように、未使用のファームウェア ファイルをリポジトリから削除する必要があります。APIC はイメージを自動的に取得します。

- アップグレード順序：通常、コントローラは、スイッチ ノードよりも先に、最初にアップグレードする必要があります。必ず、対象となるファームウェア バージョンの関連リリース ノートを参照して、この順序が変更されているかどうかを確認してください。

- メンテナンス時間：データプレーンに影響を与えずに、ファブリックをアップグレードすることは可能ですが、変更管理ポリシーに従って、スケジュールされたメンテナンス時間中にアップグレードを実行してください。この時間帯については、アップグレード中に発生する可能性がある予想外の問題を考慮し、トラブルシューティングやロールバックを実行できる十分な時間を割り当てる必要があります。

- メンテナンス グループ：アップグレード中に、ホストへの影響を最小限に抑えるには、少なくとも 2 つの異なるメンテナンス グループを設定する必要があります。一般的には、奇数と偶数のノード ID により分けます。ホストが 1 つの奇数リーフ ノードと 1 つの偶数リーフ ノードに二重接続されている場合、ホストはまったく影響を受けません。メンテナンス グループの作成については、この章の後半で詳しく説明します。もう 1 つの考慮事項は、リーフ vPC ペアに奇数と偶数のノードを 1 つずつ含める必要があることです。

- アプリケーション仮想スイッチ（AVS）を展開したファブリックのアップグレード：AVS ソフトウェアは特に APIC またはスイッチのソフトウェア バージョンに関連付けられません。

- デバイス パッケージ：デバイス パッケージは APIC ソフトウェアに関連付けられていない場合があります。オンライン Cisco Application Centric Infrastructure (ACI) 互換性ツールを使用して、レイヤ 4 ～ レイヤ 7 デバイスに対し、デバイスの互換性を確認できます。

GUI を使用したファームウェア イメージのダウンロード

Application Policy Infrastructure Controller (APIC) 用のコントローラ ソフトウェア パッケージとスイッチ ソフトウェア パッケージの両方を、Cisco.com からダウンロードする必要があります。

手順

ステップ 1

メニュー バーで、[Admin] > [Firmware] の順に選択します。

ステップ 2

[Navigation] ペインで、[Fabric Node Firmware] をクリックします。

[Work] ペインには、ファブリック内の全スイッチのリストと、ファームウェアが最後にアップグレードされたときのステータスが表示されます。

ステップ 3

[Navigation] ペインで、[Download Tasks] を選択します。

ステップ 4

[Work] ペインで、[Actions] > [Create Firmware Download Task] の順に選択します。

ステップ 5

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

1. [Source Name] フィールドにスイッチ イメージの名前（「apic_1.2.1i」など）を入力します。

2. [Protocol] ラジオ ボタンで、[Secure copy] または [HTTP] ラジオ ボタンをクリックします。

3. [URL] フィールドに、イメージをダウンロードする URL を入力します。

- HTTP の例：http://192.168.0.50/aci-apic-dk9.1.2.1i.iso

- SCP の例：192.168.0.50:/tmp/aci-firmware/aci-apic-dk9.1.2.1i.iso

- SCP の場合、ユーザ名とパスワードを入力します。

4. [Submit] をクリックします。`

ステップ 6

（任意） 次の操作を実行すると、代わりにローカル マシンからイメージをアップロードできます。

1. [Navigation] ペインで、[Download Tasks] を選択します。

2. [Upload Firmware to APIC] を右クリックして選択します。

3. ローカル マシンに保存されたイメージを参照してください。

4. [Submit] をクリックします。`

ステップ 7

[Navigation] ペインで、[Download Tasks] を選択します。

ステップ 8

[Work] ペインで、[Operational] タブを選択し、イメージのダウンロード ステータスを表示します。

ステップ 9

スイッチ イメージに対してこの手順を繰り返します。

ステップ 10

ダウンロードが 100% に達したら、[Navigation] ペインで [Firmware Repository] を選択します。

ステップ 11

ダウンロードしたバージョン番号とイメージのサイズを表示するには、[Work] ペインで、[Images] タブを選択します。

オブジェクト モデル CLI を使用したファームウェア イメージのダウンロード

Application Policy Infrastructure Controller (APIC) 用のコントローラ ソフトウェア パッケージとスイッチ ソフトウェア パッケージの両方を、Cisco.com からダウンロードする必要があります。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

オブジェクト モデル CLI に切り替えます。

apic1# bash
admin@apic1:~>

ステップ 3

イメージ リポジトリにイメージを格納します。

admin@apic1:~> firmware add ver_no.iso

ステップ 4

ソフトウェアがリポジトリに追加されたことを確認します。

admin@apic1:~> firmware list
Name : aci-apic-dk9.1.2.1i.bin
Type : controller
Version : 1.2(1i)

GUI を使用した APIC のアップグレード

カタログ ファームウェア イメージは、 Application Policy Infrastructure Controller (APIC) イメージがアップグレードされるとアップグレードされます。カタログ ファームウェア イメージを個別にアップグレードする必要はありません。

APIC をアップグレードするには、次の手順を実行します。

1. メニュー バーで、[ADMIN] > [Firmware] の順に選択します。

2. [Navigation] ペインで、[Controller Firmware] をクリックします。

3. [Work] ペインで、[Actions] > [Upgrade Controller Firmware Policy] の順に選択します。

4. [コントローラ ファームウェア アップグレード ポリシー (Upgrade Controller Firmware Policy)] ダイアログボックスで、次の操作を実行します。

1. [ターゲット ファームウェア バージョン (Target Firmware Version)] フィールドで、ドロップダウン リストから、アップグレードするイメージ バージョンを選択します。

2. [Apply Policy] フィールドで、[Apply Now] ラジオ ボタンをクリックします。または、特定の日付けまたは時刻までタスクを延期する場合は、スケジュール ポリシーを適用できます。

3. [Submit] をクリックして、タスクを完了します。

[Status] ダイアログボックスに「Changes Saved Successfully」というメッセージが表示されて、アップグレード プロセスが開始されます。アップグレード中に APIC のクラスタを使用できるように、APIC は順番にアップグレードされます。

5. [Work] ペインでアップグレードのステータスを確認します。

APIC のアップグレードにはそれぞれ約 10 分かかります。APIC のイメージがアップグレードされた場合、クラスタからドロップし、クラスタ内の他の APIC が動作している間に、新しいバージョンで再起動します。APIC が再起動すると、クラスタに再び参加します。その後、クラスタが収束し、次の APIC のイメージのアップグレードを開始します。クラスタがすぐに収束せず、完全に適合しない場合は、クラスタが収束して [Fully Fit] になるまでアップグレードは待機状態になります。この間、アップグレードされる各 APIC の [ステータス（Status）] カラムに [クラスタ コンバージェンスの待機（Waiting for Cluster Convergence）] というメッセージが表示されます。

ブラウザが接続されている APIC がアップグレードされて再起動すると、ブラウザにエラー メッセージが表示されます。

（注）

アップグレード プロセス中に、新しいイメージで APIC がリブートしますが、その特定の APIC の GUI は使用できません。アップグレード プロセス中に、APIC の GUI にログインすると、ブラウザのエラー メッセージを受信し、ログオフされる可能性ががあります。その特定の APIC のステータスが [Fully Fit] になったら、その APIC に再度ログインできます。

NX-OS スタイルの CLI を使用した APIC のアップグレード

NX-OS スタイルの CLI を使用してApplication Policy Infrastructure Controller (APIC) をアップグレードすることができます。スイッチをアップグレードする前に、APIC のアップグレードが完了し、ヘルス ステータスが [Fully Fit] になっている必要があります。NX-OS スタイルの CLI では、まずカタログ ファームウェアを設定する必要があります。次の設定手順で、カタログ ファームウェアを設定し、アップグレードを開始します。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure
apic1(config)#

ステップ 3

ファームウェア モードを入力します。

apic1(config)# firmware
apic1(config-firmware)#

ファームウェア モードによりカタログ バージョンを設定することができます。

ステップ 4

カタログ バージョンを設定します。

apic1(config-firmware)# catalog-version aci-catalog-dk9.1.2.0.225.bin

コントローラ ファームウェアのアップグレードの準備ができました。

ステップ 5

コントローラ グループ モードを開始し、現在のバージョンを確認してください。

apic1(config-firmware)# controller-group
apic1(config-firmware-controller)# show version
Role          Id            Name                        Version
----------  ----------  ------------------------  --------------------
controller  1             apic1                       1.2(0.139g)
controller  2             apic2                       1.2(0.139g)
controller  3             apic3                       1.2(0.139g)

ステップ 6

コントローラ ファームウェアを目的のバージョンに設定します。

apic1(config-firmware-controller)# firmware-version aci-apic-dk9.1.2.0.225.bin

ステップ 7

アップグレードを開始します。

アップグレードの開始時間を指定することも、すぐにアップグレードを開始することもできます。

- アップグレードを開始する時間を指定するには、次を入力します。

apic1(config-firmware-controller)# time start 23:30

時間は必ず指定する必要があります。日付はオプションです。

- アップグレードをすぐに開始するには、次を入力します。

apic1(config-firmware-controller)# exit
apic1(config-firmware)# exit
apic1(config)# exit
apic1# firmware upgrade controller-group

オブジェクト モデル CLI を使用した APIC のアップグレード

カタログ ファームウェア イメージは、 Application Policy Infrastructure Controller (APIC) イメージがアップグレードされるとアップグレードされます。カタログ ファームウェア イメージを個別にアップグレードする必要はありません。GUI からファームウェアのアップグレードを実行することをお勧めします。GUI を使用すると、APIC はソフトウェア イメージに対してさらに検証と整合性チェックを実行します。

オブジェクト モデル CLI を使用して APIC をアップグレードするには、次の手順を実行します。

1. 前にダウンロードした、リポジトリ内の現在のソフトウェアを一覧表示します。

例：

admin@apic1:~> firmware list
Name : aci-apic-dk9.1.1.1j.bin
Type : controller
Version : 1.1(1j)

2. APIC のファームウェアをアップグレードします。

例：

admin@apic1:~> firmware upgrade controllers ver_no .bin

アップグレード中に APIC のクラスタを使用できるように、APIC は順番にアップグレードされます。アップグレードはバックグラウンドで実行されます。

3. アップグレードのステータスを確認します。

例：

admin@apic1:~> firmware upgrade status
Node-Id   Role        Current-     Target-            Upgrade-   Progress-Percent
Firmware     Firmware           Status     (if inprogress)
--------- ----------- ------------ ------------------ ---------- ------------------
1         controller  1.1(1.200j)  apic-1.2(1.202i)   complete   0
2         controller  1.1(1.200j)  apic-1.2(1.202i)   inprogress 0
3         controller  1.1(1.200j)  apic-1.2(1.202i)   inqueue    0

[Upgrade Status] フィールドに、「inqueue」、「inprogress」、または「completeok」が表示されます。このフィールドに「Unknown」と表示された場合、APIC はアップグレードされ再起動中です。この間、APIC CLI への接続が失われることがあり、CLI に再度ログインする必要があります。

GUI を使用したスイッチのアップグレード

スイッチをアップグレードする前に、Application Policy Infrastructure Controller (APIC) のアップグレードが完了し、ヘルス ステータスが [Fully Fit] になっている必要があります。

GUI を使用してスイッチをアップグレードするには、次の手順を実行します。

1. メニュー バーで、[Admin] > [Firmware] の順に選択します。

2. [Navigation] ペインで、[Fabric Node Firmware] をクリックします。

[Work] ペインに、ファブリック内で動作しているスイッチが表示されます。

3. ファームウェア グループを作成していない場合は、次のサブステップを実行します。

1. [Navigation] ペインで、[Fabric Node Firmware] > [Firmware Groups] の順に選択します。

2. [Work] ペインで、[Policy] タブを選択します。

3. [Actions] > [Create Firmware Group] の順に選択します。

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

1. [Group Name] フィールドに、ファームウェア グループの名前を入力します。

2. [Target Firmware Version] ドロップダウン リストから、アップグレードするファームウェア バージョンを選択します。

3. [Group Node IDs] フィールドに、グループに追加するノード ID のカンマ区切りリストまたは範囲を入力します。たとえば、「101, 103-105, 108」のように指定します。

4. [Submit] をクリックします。`

5. ファームウェア グループが作成されていることを確認するには、[Navigation] ペインで、[Fabric Node Firmware] > [Firmware Groups] > [new_firmware_group] の順に選択します。Work ペインに、前に作成したファームウェア ポリシーの詳細が表示されます。

4. メンテナンス グループを作成していない場合は、次のサブステップを実行します。

1. [Navigation] ペインで、[Fabric Node Firmware] > [Maintenance Groups] の順にクリックします。

すべてのスイッチに対して 2 つのメンテナンス グループを作成することをお勧めします。たとえば、偶数番号のノードを含むグループと、奇数番号のノードを含む別のグループを作成します。接続全部が失われないように、少なくとも 1 つのスパインと 1 つのリーフが、他と異なるメンテナンス グループにあることを確認します。

2. [Work] ペインで、[Action] > [Create Maintenance POD Group] の順に選択します。

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

1. [Group Name] フィールドに、メンテナンス グループの名前を入力します。たとえば、「Even-Nodes」と入力します。

2. [Run Mode] ドロップダウン リストで、[Pause Upon Upgrade Failure] を選択します。これは、デフォルトのモードです。

3. [Group Node IDs] フィールドに、グループに追加するノード ID のカンマ区切りリストまたは範囲を入力します。たとえば、「102, 104, 106, 108, 110」のように指定します。

4. [Scheduler] ドロップダウン リストでは、アップグレードのスケジュールを作成できます。または、オンデマンドでアップグレードできるように空欄にしておくことも可能です。

5. [Submit] をクリックします。`

6. もう一方のメンテナンス グループに対して同じ手順を繰り返します。たとえば、「Odd-Nodes」という名前のグループに対して手順を実行します。

4. メンテナンス グループが作成されたことを確認します。

1. [Navigation] ペインで、[Fabric Node Firmware] > [Maintenance Groups] > [new_maintenance_group] の順に選択します

2. 作成したメンテナンス グループの名前を選択します。

3. [Work] ペインで、ノードがそのメンテナンス グループに接続されていることを確認します。

5. 作成したメンテナンス グループのいずれかを右クリックし、[Upgrade Now] を選択します。

6. [Upgrade Now] ダイアログボックスで、「Do you want to upgrade the maintenance group policy now?」 に対する [Yes] をクリックします。

注： 作業ウィンドウの [Status] に、グループ内の全スイッチが同時にアップグレードされていることが表示されます。グループ内のデフォルトの同時実行数は 20 に設定されます。したがって、20 台のスイッチが同時にアップグレードされ、その後また 20 台のスイッチの組がアップグレードされます。障害が発生した場合、スケジューラがサスペンドし、APIC 管理者の手動操作が必要になります。スイッチのアップグレードには、グループごとに最長で 12 分かかります。スイッチはアップグレードすると再起動し、接続が切断されて、クラスタ内のコントローラはグループ内のスイッチとしばらくの間、通信しません。スイッチが起動後にクラスタに再加入した場合、コントローラ ノードの下に全スイッチが一覧で表示されます。クラスタに VPC コンフィギュレーションがある場合、アップグレード プロセスは vPC ドメインの 2 台のスイッチのうち一度に 1 台のスイッチのみをアップグレードします。

7. [Navigation] ペインで、[Fabric Node Firmware] をクリックします。

注：作業ウィンドウに、リスト内の全スイッチが表示されます。[Current Firmware] 列には、各スイッチに対するアップグレード イメージの詳細が表示されます。ファブリック内のスイッチが新しいイメージにアップグレードされることを確認します。

NX-OS スタイルの CLI を使用したスイッチのアップグレード

NX-OS スタイルの CLI を使用して、スイッチをアップグレードすることができます。スイッチをアップグレードする前に、APIC のアップグレードが完了し、ヘルス ステータスが [Fully Fit] になっている必要があります。次に、スイッチをアップグレードします。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

イメージをファームウェア リポジトリに追加します。

apic1# firmware repository add aci-n9000-dk9.11.2.0.225.bin

ステップ 3

設定モードを開始します。

apic1# configure
apic1(config)#

ステップ 4

ファームウェア モードを入力します。

apic1(config)# firmware
apic1(config-firmware)#

ステップ 5

ファームウェア バージョンを確認します。

apic1(config-firmware)# show version
Role          Id               Name                           Version
----------  ----------  ------------------------  --------------------
leaf             101              176-Leaf-1                     n9000-11.2(0.65l)
leaf             102              176-Leaf-2                     n9000-11.2(0.65l)
spine            201              176-Spine-1                    n9000-11.2(0.65l)
spine            202              176-Spine-2                    n9000-11.2(0.65l)

ステップ 6

スイッチ グループの作成によってファームウェア スイッチ モードを入力します。

apic1(config-firmware)# switch-group EvenNodes
apic1(config-firmware-switch)#

ステップ 7

スイッチ グループにスイッチを追加します。

apic1(config-firmware-switch)# switch 102, 202

ステップ 8

（任意） スイッチが追加されたことを確認します。

apic1(config-firmware-switch)# show run
# Command: show running-config firmware switch-group all-nodes
# Time: Fri Nov  6 15:18:34 2015
firmware
switch-group EvenNodes
switch     102
switch     202

ステップ 9

スイッチ ファームウェアを目的のバージョンに設定します。

apic1(config-firmware-controller)# firmware-version aci-apic-dk9.1.2.0.225.bin

ステップ 10

アップグレードが障害の発生時に一時停止するように、スイッチの実行モードを pause-on-failure に設定します。

apic1(config-firmware-switch)# run-mode pause-on-failure

ステップ 11

アップグレードを開始します。

スケジューラを使用してアップグレードの開始時間を指定することも、すぐにアップグレードを開始することもできます。

- スケジューラを使用するには、次を入力します。

apic3(config-firmware-switch)# schedule upgradetimerEvenNodes

- アップグレードをすぐに開始するには、execsh モードに戻り、次を入力します。

apic1# firmware upgrade switch-group

オブジェクト モデル CLI を使用したスイッチのアップグレード

スイッチをアップグレードする前に、Application Policy Infrastructure Controller (APIC) のアップグレードが完了し、ヘルス ステータスが [Fully Fit] になっている必要があります。

オブジェクト モデル CLI を使用してスイッチをアップグレードするには、次の手順を実行します。

1. 次のコマンドの出力が下記の出力例と同様になり、正しいバージョン番号が示されていることを確認します。

例：

admin@apic1:~> firmware list
Name : aci-n9000-dk9.11.2.1i.bin
Type : switch
Version : 11.2(1i)

名前が「.iso」から「.bin」に変わります。

2. スイッチをアップグレードします。

例：

admin@apic1:~> firmware upgrade switch node 101 ver_no.bin
Firmware Installation on Switch Scheduled

各スイッチを個別にアップグレードする必要があります。

3. スイッチのアップグレード ステータスを確認します。次のコマンドの出力は、下記の例のようになります。

例：

admin@apic1:~> firmware upgrade status node node_id
Node-Id   Role        Current-            Target-            Upgrade-   Progress-Percent
Firmware            Firmware           Status     (if inprogress)
--------- ----------- ------------------- ------------------ ---------- ------------------
1017      leaf        n9000-11.1(1.869S1) n9000-11.2(1i)     completeok 100

firmware upgrade status コマンドを入力すると、一度にすべてのノードのステータスを確認できます。

4. 各追加スイッチに対してステップ 2 と 3 を繰り返します。

GUI を使用したクラスタの収束の確認

定期メンテナンス後に、クラスタの収束の進行状況をモニタできます。収束のプロセス中の一連のメッセージを表示する、GUI のコントローラ ファームウェア画面で進行状況を確認できます。これらのメッセージは [Status] フィールドに表示されます。

コントローラとスイッチのアップグレードの進行に伴い、キューに入っているノードの数とアップグレード中のノードの数、および成功したアップグレードの数に関するメッセージが表示されます。

表示されるノードのアップグレード ステータスは次のとおりです。

- NotScheduled：現在、ノードに対してアップグレードはスケジュールされていません。

- Scheduled：ノードに対してアップグレードがスケジュールされています。

- Queued：現在アクティブな時間枠（スケジュール）があり、ノードがアップグレードの認可を要求しています。

- Inprogress：現在、ノードに対してアップグレードが進行中です。

- CompleteOK：アップグレードが正常に完了しました。

- CompleteNOK：ノードでのアップグレードが失敗しました。

- Inretryqueue：アップグレードを再試行するためにノードがキューに入っています（5 回試行した後に、失敗が宣言されます）。

This may take a while. すべてのクラスタが正常に収束されると、[Controller Firmware] 画面の [Waiting for Cluster Convergence] フィールドに「No」と表示されます。

アップグレード プロセス中にフォールトのトラブルシューティング

メンテナンス ポリシーごとに 1 つのスケジューラが存在します。デフォルトでアップグレードフォールトが検出されると、スケジューラを停止し、そのグループのノードはアップグレードを開始しません。スケジューラは、アップグレード フォールトの場合に手動介入によるデバッグを必要とします。手動介入が完了したら、一時停止されたスケジューラを再開させる必要があります。

スイッチのステータスが「queued」になっている場合は、以下を確認します。

- コントローラのクラスタが正常かどうか。コントローラのクラスタは正常でなければなりません。API に「waitingForClusterHealth = yes」と表示されている場合、または GUI で [Waiting for Cluster Convergence] に対して [Yes] が表示されている場合は、コントローラのクラスタが正常ではないことを示しています。コントローラのクラスタが正常になるまで、アップグレードを開始していないスイッチのステータスは「queued」のままになります。

- スイッチのメンテナンス グループが一時停止していないか。スイッチがアップグレードに失敗すると、グループは一時停止状態になります。

スイッチの処理に約 60 分以上かかり、API に「waitingForClusterHealth = no」と表示されている場合、または GUI で [Waiting for Cluster Convergence] に対して [No] が表示されている場合は、スケジューラの一時停止を確認するステップを実行します。

そのほかのトラブルシューティング手順については、『Troubleshooting Cisco Application Centric Infrastructure』を参照してください。

Chapter4. ファブリック接続

- ファブリック ポリシーの概要

- ファブリックへの新しいデバイスの追加

- サーバ接続

- アプリケーションの移行の使用例

ファブリック ポリシーの概要

これまでに、ACME に ACI ファブリックをプロビジョニングし、リーフとスパイン スイッチ、アクセス権限、および基本的な管理ポリシー間にインフラストラクチャ領域を設定しました。次に、ACI ファブリック内で接続ポリシーの作成を開始します。APIC GUI の [Fabric] タブを使用して、デバイス ディスカバリとインベントリ管理、診断ツール、ドメインの設定、スイッチとポートの動作など、システムレベルの機能を設定します。[Fabric] ペインは 3 つのセクション（[inventory]、[fabric policies]、[access policies]）に分かれています。ファブリック ポリシーとアクセス ポリシーによってファブリックを設定する方法を理解することは、ACME のネットワーク チームにとって重要です。このチームは、ファブリックのリーフ ノード間の内部接続や、サーバ、ネットワーク機器、ストレージ アレイなどの外部エンティティへの接続のために、これらのポリシーを保持する必要があるからです。サーバ チームなどの他のチームも、ネットワーク チームと協力して作業する上で（特に、キャパシティを追加するビルド プロセスにおいて）、これらの概念を理解する必要があります。

この章では、[Fabric] タブの [access policies] サブセクションの主要オブジェクト（その多くが再利用可能）をレビューし、スイッチの追加および事前プロビジョニング方法について説明します。また、ACI ファブリックを効果的に運用するために新しいデバイスをファブリックに追加する場合に必要な、手順とオブジェクトについても概説します。多くのポリシーは再利用可能ですが、ACI ファブリックでのポリシーの削除による影響を理解することも重要です。

[access policies] サブセクションは複数のフォルダに分割されており、ファブリックの動作に影響するさまざまなタイプのポリシーとオブジェクトが分類されています。たとえば、インターフェイス ポリシーのフォルダにはポートの動作が設定されています（ポートの速度、リーフ スイッチ インターフェイスで LACP などのプロトコルを実行するかどうかなど）。[access policies] ビューではドメインと AEP も作成されます。また、ファブリックにおけるリーフ スイッチのアクセス ポートの基本設定は、ファブリック アクセス ポリシーによって行われます。

ドメイン

ACI では、エンドポイント グループは 「who」、コントラクトは「what/when/why」に該当します。また、AEP は「where」、ドメインはファブリックの「how」と見なすことができます。デバイスがリーフ スイッチに接続している方法に応じて、さまざまなドメイン タイプが作成されます。4 つのドメイン タイプ（物理ドメイン、外部ブリッジ ドメイン、外部ルーテッド ドメイン、VMMドメイン）があります。

- 物理ドメインは、通常、ベアメタル サーバ、またはハイパーバイザの統合がオプションでないサーバに対して使用されます。

- 外部ブリッジ ドメインはレイヤ 2 接続に使用されます。たとえば、外部ブリッジ ドメインを使用して、トランクアップされている既存のスイッチをリーフ スイッチに接続できます。

- 外部ルーテッド ドメインはレイヤ 3 接続に使用されます。たとえば、外部ルーテッド ドメインを使用して、WAN ルータをリーフ スイッチに接続することができます。

- ドメインは、[Fabric] タブで行われたポリシー モデルの設定と [Tenant] ペインにあるエンドポイント グループの設定を結びつける役割を果たします。ドメインはファブリック オペレータによって作成され、テナント管理者によってエンドポイント グループに関連付けられます。

理想的には、ポリシーを 1 回だけ作成して、ファブリックに新しいデバイスを接続するときにそれを再利用します。ポリシーとオブジェクトを最大限に再利用すると、日常業務が飛躍的に速くなり、大規模な変更が容易になります。これらのポリシーの使用状況は、 Application Policy Infrastructure Controller (APIC) GUI で [Show Usage] ボタンをクリックして表示できます。これを使用して、特定のポリシーをどのオブジェクトが使用しているかを判別することで、変更を行った場合の影響を把握することができます。

ドメインの詳細については、https://www.youtube.com/watch?v=_iQvoC9zQ_A にあるビデオ「How Devices Connect to the Fabric: Understanding Cisco ACI Domains」をご覧ください。

VLAN プール

VLAN プールにはドメインが関連付けられる EPG によって使用される VLAN が含まれています。ドメインは 1 つの VLAN プールに関連付けられます。VXLAN やマルチキャスト アドレス プールも設定できます。VLAN は、AEP の設定に基づいてリーフ スイッチでインスタンス化されます。許可/拒否の決定は、サブネットや VLAN ではなく、コントラクトとポリシー モデルに基づきます。

接続可能アクセス エンティティ プロファイル

接続可能アクセス エンティティ プロファイル（AEP）は、ファブリック設定の「where」に該当し、類似の要件を持つドメインのグループ化に使用されます。AEP はインターフェイス ポリシー グループに関連付けられます。1 つ以上のドメインを AEP に追加できます。ドメインを AEP にグループ化して関連付けることによって、ファブリックはドメイン内のさまざまなデバイスの場所を把握し、Application Policy Infrastructure Controller (APIC) は必要とする場所に VLAN やポリシーをプッシュできます。AEP は [Global Policies] セクションで設定されます。

ポリシー タイプ

大部分のポリシー フォルダにはサブフォルダがあります。たとえば、[interface policies] フォルダには、[policies]、[policy groups]、[profiles] という設定用のフォルダがあります。

スイッチ ポリシー

また、スイッチ用のポリシーもあります。たとえば、Application Policy Infrastructure Controller (APIC) GUI および vPC ポリシーで明示的 vPC 保護グループと呼ばれる、vPC ドメインを設定したりします。理想的には、ポリシーを 1 回だけ作成して、ファブリックに新しいデバイスを接続するときにそれを再利用します。ポリシーとオブジェクトを最大限に再利用すると、日常業務が飛躍的に速くなり、大規模な変更が容易になります。

スイッチ ポリシー グループ

スイッチ ポリシー グループを使用すると、スパニングツリー ポリシーやモニタリング ポリシーなど、既存のスイッチ ポリシーを活用できます。

スイッチ プロファイル

スイッチ プロファイルを使用すると、1 つ以上のリーフ スイッチを選択してインターフェイス プロファイルを関連付け、特定のノードにポートを設定できます。この関連付けによって、インターフェイスに設定がプッシュされ、インターフェイス ポリシーで設定されている場合は、ポート チャネルまたは vPC が作成されます。

次の図は、さまざまなグローバル ポリシー、スイッチ ポリシー、インターフェイス ポリシー間の関係を示しています。

EPG に物理インターフェイスまたはインターフェイスを接続できる関係

インターフェイス ポリシー

インターフェイス ポリシーはインターフェイスの動作を指示し、その後、インターフェイス ポリシー グループに関連付けられます。たとえば、CDP の無効化を指示するポリシーと CDP の有効化を指示するポリシーがある場合、リーフ スイッチに新しいデバイスが接続されたときにこれらを再利用できます。

インターフェイス ポリシー グループ

インターフェイス ポリシー グループはポートの動作を指示するテンプレートであり、AEP に関連付けられます。インターフェイス ポリシー グループは、前の段落で説明したポリシーを使用して、リンクの動作方法を指定します。また、同じポート設定が必要な多数のデバイスがポートに接続していることがよくあるので、再利用可能なオブジェクトもあります。リンクのタイプに応じて、3 つのインターフェイス ポリシー グループ（アクセス ポート、ポート チャネル、vPC）があります。

リーフ スイッチのポートはデフォルトで 10 GE に設定されるので、その速度で接続するデバイスに対しては 1 GE リンク レベルのポリシーを作成する必要があります。ポート チャネルと vPC については、ポリシー グループごとにスイッチ上の単一の論理インターフェイスが指定されます。10 個の PC/vPC を作成する場合、10 のポリシー グループを作成する必要があります。アクセス ポートのポリシー グループはインターフェイス間で再利用することができます。ポリシー グループは、プロトコルやポート動作を実装する where（対象）を実際には指定しません。以降で説明するように、「where（対象）」は、スイッチ プロファイルに 1 つ以上のインターフェイス プロファイルを関連付けることによって生じます。

インターフェイス プロファイル

インターフェイス プロファイルは部分を結合するのに役立ちます。インターフェイス プロファイルはポートインターフェイス セレクタのブロックを含んでおり、前述のように、インターフェイス ポリシー グループに関連付けられます。また、これは単なる任意ポート（e1/1 など）なので、ポートを設定するには、プロファイルを特定のスイッチ プロファイルに関連付ける必要があります。

レイヤ 2 インターフェイス ポリシー

Cisco APIC リリース 1.1 では設定可能なインターフェイス ポリシーが追加され、ポート単位の VLAN シグニフィカンスが可能になりました。

Cisco Application Centric Infrastructure (Cisco ACI) ファブリックにデバイスを接続するために、タグなしトラフィック、802.1Q タグ付きトラフィック、または VXLAN カプセル化を使用できます。ポート単位の VLAN を使用すると、トラフィックが別のポートに着信される場合、同じ VLAN を異なるエンドポイント グループに使用できます。リリース 1.1 より前は、VLAN はリーフ スイッチごとに 1 つのエンドポイント グループのみを関連付けることができました。

従来のネットワークでは、ネットワーク デバイス内の VLAN 数が 4096 までに限定されているため、VLAN カプセル化に関する制限の 1 つとして、拡張性と再利用可能性が制限されています。

Cisco ACI のデフォルト設定（グローバル）では、EPG が個別のスイッチにバインドされ、異なる VLAN プールにバインドされている異なる物理ドメインを使用している限り、同じ VLAN カプセル化で EPG を使用できます。これによって、テナント間の通信を許可しなくても、テナントはファブリックを介して VLAN カプセル化 ID を再使用できます。ただし、グローバル設定では、テナントがリーフ スイッチを共有しておらず、したがって、同じリーフ スイッチ内に重複する VLAN がないと想定しています。

ポート単位の VLAN に関する制限事項と考慮事項

- ポート単位の VLAN を使用する場合は、VLAN カプセル化 ID の代わりに、ポートと VLAN のペア（P、V）が内部に登録されます。これによって、スイッチ レベルごとのハードウェア リソース消費量が増加します。

- 1 つのブリッジ ドメインに属している 2 つの EPG は、リーフ スイッチで同じカプセル化 ID を共有できません。

- グローバルとローカル間のレイヤ 2 インターフェイス ポリシーが変更されると、ポートがフラップすることが想定されます。つまり、トラフィックに影響します。

DWDM-SFP10G-C 光インターフェイス ポリシー

Cisco APICリリース 3.1 (1) は DWDM-SFP10G-C 光ファイバのサポートを追加し、光ファイバのインターフェイス ポリシーを含みます。DWDM-SFP10G-C ポートが挿入されるとき、デフォルトでポートにはチャンネル番号 32 があります。DWDM-SFP10G-C 光インターフェイス ポリシーでは、1 ～ 96 の番号にチャネル番号を変更でき、それで光ファイバを対応する波長に調整します。

チャネルごとの DWDM-SFP10G-C ポート波長

チャネル番号

周波数（THz）

波長（nm）

1

191.35

1566.72

2

191.40

1566.31

3

191.45

1565.90

4

191.50

1565.50

5

191.55

1565.09

6

191.60

1564.68

7

191.65

1564.27

8

191.70

1563.86

9

191.75

1563.45

10

191.80

1563.05

11

191.85

1562.64

12

191.90

1562.23

13

191.95

1561.83

14

192.00

1561.42

15

192.05

1561.01

16

192.10

1560.61

17

192.15

1560.20

18

192.20

1559.79

19

192.25

1559.39

20

192.30

1558.98

21

192.35

1558.58

22

192.40

1558.17

23

192.45

1557.77

24

192.50

1557.36

25

192.55

1556.96

26

192.60

1556.55

27

192.65

1556.15

28

192.70

1555.75

29

192.75

1555.34

30

192.80

1554.94

31

192.85

1554.54

32

192.90

1554.13

33

192.95

1553.73

34

193.00

1553.33

35

193.05

1552.93

36

193.10

1552.52

37

193.15

1552.12

38

193.20

1551.72

39

193.25

1551.32

40

193.30

1550.92

41

193.35

1550.52

42

193.40

1550.12

43

193.45

1549.72

44

193.50

1549.32

45

193.55

1548.91

46

193.60

1548.51

47

193.65

1548.11

48

193.70

1547.72

49

193.75

1547.32

50

193.80

1546.92

51

193.85

1546.52

52

193.90

1546.12

53

193.95

1545.72

54

194.00

1545.32

55

194.05

1544.92

56

194.10

1544.53

57

194.15

1544.13

58

194.20

1543.73

59

194.25

1543.33

60

194.30

1542.94

61

194.35

1542.54

62

194.40

1542.14

63

194.45

1541.75

64

194.50

1541.35

65

194.55

1540.95

66

194.60

1540.56

67

194.65

1540.16

68

194.70

1539.77

69

194.75

1539.37

70

194.80

1538.98

71

194.85

1538.58

72

194.90

1538.19

73

194.95

1537.79

74

195.00

1537.40

75

195.05

1537.00

76

195.10

1536.61

77

195.15

1536.22

78

195.20

1535.82

79

195.25

1535.43

80

195.30

1535.04

81

195.35

1534.64

82

195.40

1534.25

83

195.45

1533.86

84

195.50

1533.47

85

195.55

1533.07

86

195.60

1532.68

87

195.65

1532.29

88

195.70

1531.90

89

195.75

1531.51

90

195.80

1531.12

91

195.85

1530.72

92

195.90

1530.33

93

195.95

1529.94

94

196.00

1529.55

95

196.05

1529.16

96

196.10

1528.77

ベスト プラクティス

シスコは、ファブリック設定のベスト プラクティスを策定しました。これらは必須条件ではなく、すべての環境やアプリケーションに適しているわけでもありませんが、Cisco Application Centric Infrastructure (ACI) ファブリックの日常の運用を簡素化する上で役立ちます。

- ポリシー

- 可能な限りポリシーを再利用します。たとえば、LACP の場合は、アクティブ/パッシブ/オフ、ポート速度 1GE、ポート速度 10GE を指定するポリシーがあります。

- ポリシーに名前を付ける場合は、設定が伝わりやすい名前を使用します。たとえば、アクティブ モードで LACP を有効にするポリシーに、「LACP-Active」という名前を付けたりします。「デフォルト」と名付けられたポリシーが多数あります。しかし、すべてのデフォルトを覚えておくのは大変です。ですから、新しいデバイスをファブリックに追加する際にミスを防ぐためにも、わかりやすい名前を指定する必要があります。

- 各リーフ スイッチごとにスイッチ プロファイルを個別に作成し、さらに、（vPC を使用している場合は）各 vPC ペアごとにスイッチ プロファイルを作成します。

- ドメイン

- 同様の処理が必要なハイパーバイザを統合せずに、ベア メタル サーバまたはサーバ用に、テナントごとに 1 つの物理ドメインを構築します。

- 外部接続用にテナントごとに 1 つの物理ドメインを構築します。

- 複数のテナント間で VMM ドメインを活用する必要がある場合は、1 つの VMM ドメインを作成して、VMware ESXi サーバが接続しているすべてのリーフ ポートに関連付けることができます。

- AEP

- 簡素化するために、複数のドメインを 1 つの AEP に関連付けることができます。場合によっては、重複 VLAN プールなどのインフラストラクチャ VLAN を有効にしたり、ファブリック全体での VLAN の範囲を制限するために、複数の AEP の設定が必要なこともあります。

ファブリックへの新しいデバイスの追加

ここでは、日常のファブリック運用を簡素化し、ファブリック アクセス ポリシーを再利用するための ACI の設定方法を示します。また、ファブリック全体でプロファイルを再利用する方法に焦点を当て、プロファイルの設定について最初から説明します。前の項で概説したように、これらのさまざまなプロファイルは互いにリンクして依存関係を築いています。次の図は、オブジェクトの関係を示しています。

オブジェクトの関係

スイッチの従来のコマンドライン インターフェイスは、一般的にポート単位の設定を必要としますが、ACI では再利用可能なポリシーとオブジェクトを定義することができます。ポリシーの再利用によって、スイッチの設定を非常に簡単に複製することができます。次の図は、この再利用によってファブリックの運用が簡素化される仕組みを時系列で示しています。

ポリシーの再利用

どのデータセンターでも、少数のスイッチを設定する場合には多数のプロセスや自動化は必要ありません。自動化は事業運営コストに直接影響するため、データセンターの規模の拡大に伴い、自動化はますます重要になります。従来のネットワークでは、多数のデバイスに影響を及ぼす変更を行う必要が生じた場合、オペレータはそれらのデバイスを管理するプロセスの設計コストに直面します。それらはネットワーク管理ツール、スクリプト、または専用アプリケーションかもしれません。Cisco ACI ポリシー モデルを活用すると、オペレータはプロファイルを使用して、デバイスの追加や管理に関する操作を合理化できます。このことは、上記の図でポリシー再利用の変曲点として示されています。

- 設定例

- 再利用

- vPC の作成例

設定例

以降の項では、接続デバイス、ポート チャネル接続デバイス、vPC 接続デバイスの個々の設定例を、設定されたオブジェクトのレビューも含めて、検討していきます。これらは、新しいデバイスがリーフ スイッチに接続されたときに、リーフ スイッチのアクセス ポートのスイッチポート設定が適切であることを確認するために、APIC GUI で実行されるステップであり、また、設定の正しさを確認するための検証ステップでもあります。次のステップは、リーフ スイッチに接続された新しいベアメタル サーバを追加する場合の使用例です。

一般的なサーバ接続方法である vPC の設定を行う前に、vPC について理解し、vPC と従来のサーバ接続方法との相違を理解することが重要です。ここでは、vPC とは何か、vPC によるメリット、および NX-OS ソフトウェア が稼働している Cisco Nexusスイッチに展開された vPC と ACI ファブリック内の vPC との相違について概要を説明します。

大まかに言えば、vPC は 2 つの個別の物理スイッチにリンク集約を拡張します。

vPC トポロジ

上の図では、冗長性のために、1 つのサーバが 2 つの異なるスイッチにデュアルホーム接続されています。vPC を使用しない場合、サーバはアクティブ/スタンバイ設定を使用するか、アルゴリズムによってトラフィックをインテリジェントにロードバランスできる、NIC ドライバまたはカーネルの特別な設定を使用します。

当社では、2 つの異なるスイッチに同じポートチャネルとしてポートを設定し、スイッチ間メッセージング チャネル（左側の緑色のボックスにあるスイッチ間ポート チャネルなど）を使用して冗長性に対処することにより、サーバのプロビジョニングと管理を大幅に簡素化する論理トポロジを実現しています。

これにより、サーバ展開の観点から見て重要な次のメリットがもたらされます。

- リンク集約に基づく復元力のある レイヤ 2 トポロジを作成できます。

- STP は必要ありません。

- すべてのリンクがアクティブに転送されるため、帯域幅が増加します。

- 設定は単なるポートチャネルとして示され、特別なソフトウェアが不要なので、ドライバやカーネルの調整の観点から見て、サーバの設定が簡素化されます。

また、vPC を使用して他のダウンストリーム デバイス（Cisco UCS ファブリック インターコネクトなど）を接続すると、同様のメリットを実現できます。

下記の図は、vPC 対応の Ciscoスイッチ ペアに接続された従来の単一のレイヤ 2 スイッチを示しています。

vPC と従来の接続の比較

従来の vPC ドメインのコンポーネントは、次の図のとおりです。

従来の vPC トポロジ

上記の図に示すように、NX-OS ソフトウェアを実行している Cisco スイッチ製品では、vPC の設定はオペレータが手動で行う必要があり、設定にはピアリンクという専用の「スイッチ間」リンク ペアが必要です。また、アウトオブバンド管理ポートには、通常、ピアキープアライブ リンクがあり、これを使用してピアの状態を調べ、vPC ピア スイッチのフォールトを検出します。このような状況で、コンフィギュレーション同期機能を有効にせずに、設定を変更すると、vPC のプライマリとセカンダリ スイッチ間で vPC パラメータの不一致が生じ、タイプ 1 の不整合が検出された場合は、変更時に部分的な接続損失が発生する可能性があります。

ACI ファブリックは VPC の設定を大幅に簡素化します。

ACI の vPC トポロジ

従来の vPC 設計と比較した場合、注意すべき重要な相違点は、vPC ピアリンクの設定に対して要件がないということです。また、管理ポートには送信するキープアライブがありません。ファブリック自体がピアリンクとして動作します。ファブリック ノード間の優れた相互接続によって、ピアがピア間のアクティブ パスを持つ可能性は低くなります。

注意点として、2 つのリーフ スイッチ間でケーブル接続を試みると、GUI で「配線の不一致」フォールトが発生し、ポートは手動での復旧が必要なポートとしてブラックリストに入れられます。

以下に、vPC を ACI ファブリックに適用する際に vPC に対して行われるその他の重要な動作変更を、従来の vPC と対比して示します。オペレータはこれらをよく理解する必要があります。

- ACI ファブリックの全設定を集中管理する APIC によるエラーのない設定を回避するために、設定は自動的に同期されます。

- 従来の vPC ソリューションでは、MCT がダウンした場合、スレーブ スイッチはその vPC リンクをすべて停止させます。

- ACI ファブリックでは、vPC ピア間のすべての冗長パスが同時に機能しなくなることはほとんどありません。したがって、ピア スイッチが到達不能になった場合、そのスイッチはクラッシュしたと見なされます。スレーブ スイッチは vPCリンク を停止しません。

- ロールの選択は引き続き発生し、ピアはマスター/スレーブの役割を担います。

- ロールは、vPC タイプ 1 の整合性エラー時に使用されます。スレーブ スイッチは vPC ポートをすべて停止します。次に示すタイプ 1 パラメータは、ACI ファブリック固有の vPC ドメインの整合性をチェックするために使用されます。

- グローバル タイプ 1 パラメータ：

- STP

- インターフェイス タイプ 1 パラメータ：

- STP：BPDU Guard のみ設定可能

- EthPM

- ポート速度

- デュプレックス モード

- ポート モード

- MTU

- ネイティブ VLAN

- PCM：チャネル モード、static と lacp

- LACP：Lag ID

次の図は、ファブリック内の vPC ドメインと非 vPC 接続ホスト間で、ACI ファブリックによってトラフィックが転送される仕組みを示しています。

vPC 転送

ユニキャスト パケット フロー H2 -> H1

1. H2 が、S3 へのリンクを介して H1 にパケットを送信します。

2. S3 が、vPC 仮想 IP（VIP）を使ってテーブルを検索し、ルーティングします。

3. スパイン スイッチは、VIP の複数のルートを調べ、そのいずれかを選択します（この例では S2）。

4. S2 が、ローカル接続されたホスト H1 にパケットを配信します。

H1 -> H2

1. H1 が、PC リンクのいずれか（この例では S1）を介して H2 にパケットを送信します。

2. S1 が、S3 の IP を使ってテーブルを検索し、ルーティングします。

3. スパイン スイッチが S3 にルーティングします。

4. S3 が、ローカル接続されたホスト H2 にパケットを配信します。

- VLAN プールの作成

- 物理ドメインの作成

- GUI を使用した接続可能アクセス エンティティ プロファイルの作成

- REST API を使用した接続可能アクセス エンティティ プロファイルの作成

- インターフェイス ポリシーの作成

- インターフェイス ポリシー グループの作成

- インターフェイス プロファイル

- スイッチ プロファイル

VLAN プールの作成

この例では、新たに接続されたベアメタル サーバを設定するために、最初に物理ドメインを作成し、次に VLAN プールへのドメインのアソシエーションを作成する必要があります。前の項で説明したように、VLAN プールは EPG で使用される VLAN ID の範囲を定義します。

サーバはファブリックの 2 つの異なるリーフ ノードに接続されています。各サーバは、802.1Q または VXLAN カプセル化を使用してタギングされます。この設定例で使用される VLAN の範囲は 100 ～ 199 です。次の図に示すように、ACI ファブリックは、タグなしトラフィック、802.1Q VLAN タグ、VXLAN VNID、NVGRE タグなど、異なるカプセル化タイプ間のゲートウェイとしても動作することができます。リーフ スイッチは、タグを除去して、必要なタグをファブリック出力に再適用することで、トラフィックを正規化します。ACI では、VLAN はリーフ スイッチのポートに関係するため、VLAN の定義は識別用にのみ使用されることを理解する必要があります。ファブリックのリーフ スイッチの入り口にパケットが到達したときに、VLAN、VXLAN、NVGRE、物理ポート ID、仮想ポート ID などの識別子を使用してさまざまな EPG にパケットを分類する方法を、ACI が事前に知っている必要があります。

カプセル化の正規化

- GUI を使用した VLAN プールの作成

- REST API を使用した VLAN プールの作成

GUI を使用した VLAN プールの作成

この手順では、GUI を使用して、VLAN プールを作成します。

手順

ステップ 1

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 2

[Navigation] ペインで、[Pools] > [VLAN] の順に選択します。

ステップ 3

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

ステップ 4

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

1. VLAN プールの名前を入力します。

2. （任意） VLAN プールの説明を入力します。

3. 割り当てモードを選択します。

- Dynamic Allocation： Application Policy Infrastructure Controller (APIC) はプールから VLAN を動的に選択します。これは、ポリシーが EPG 自体に適用されるため、実際の VLAN ID は重要ではない、VMM 統合モードで共通です。

- Static Allocation：これは通常、ベアメタル サーバで使用するために、スタティック ソース（EPG のスタティック パス バインディングなど）のプールが参照される場合に使用されます。

4. 1 つ以上のカプセル化ブロックを追加します。

カプセル化ブロックは VLAN プールの VLAN 範囲を定義します。1 つのプールに複数の範囲を追加できます。カプセル化の各ブロックの割り当てのモードを選択します。

- Dynamic Allocation： Application Policy Infrastructure Controller (APIC) はプールから VLAN を動的に選択します。これは、ポリシーが EPG 自体に適用されるため、実際の VLAN ID は重要ではない、VMM 統合モードで共通です。

- Inherit Allocation Mode from parent：カプセル化ブロックは VLAN プールに基づいてモードを継承します。

- Static Allocation：これは通常、ベアメタル サーバで使用するために、スタティック ソース（EPG のスタティック パス バインディングなど）のプールが参照される場合に使用されます。

ステップ 5

[送信（Submit）] をクリックします。

REST API を使用した VLAN プールの作成

次の REST 要求は VLAN プールを作成します。

<fvnsVlanInstP allocMode="static" childAction="" configIssues="" descr=""
dn="uni/infra/vlanns-[bsprint-vlan-pool]-static" lcOwn="local" modTs="2015-02-23T15:58:33.538-08:00"
monPolDn="uni/fabric/monfab-default" name="bsprint-vlan-pool"
ownerKey="" ownerTag="" status="" uid="8131">
<fvnsRtVlanNs childAction="" lcOwn="local" modTs="2015-02-25T11:35:33.365-08:00"
rn="rtinfraVlanNs-[uni/l2dom-JC-L2-Domain]" status="" tCl="l2extDomP" tDn="uni/l2dom-JC-L2-Domain"/>
<fvnsRtVlanNs childAction="" lcOwn="local" modTs="2015-02-23T16:13:22.007-08:00"
rn="rtinfraVlanNs-[uni/phys-bsprint-PHY]" status="" tCl="physDomP" tDn="uni/physbsprint-PHY"/>
<fvnsEncapBlk childAction="" descr="" from="vlan-100" lcOwn="local" modTs="2015-02-23T15:58:33.538-08:00"
name="" rn="from-[vlan-100]-to-[vlan-199]" status="" to="vlan-199" uid="8131"/>
</fvnsVlanInstP>

物理ドメインの作成

物理ドメインは、VLAN プールとアクセス エンティティ プロファイル（AEP）間のリンクとして動作します。ドメインはファブリックの設定をテナントの設定に結びつけます。ドメインを EPG に関連付けるのはテナント管理者であり、ドメインが作成されるのは [Fabric] タブだからです。この順序で設定すると、プロファイル名と VLAN プールのみが設定されます。AEP とアソシエーションの作成については、この項の後半で説明します。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Physical and External Domains] > [Physical Domains] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Physical Domain] の順に選択します。

4. [Create Physical Domain] ダイアログボックスで、次の操作を実行します。

1. プロファイルのわかりやすい名前を定義します。

2. 作成した VLAN プールを選択します。

XML オブジェクト

<physDomP childAction="" configIssues="" dn="uni/phys-bsprint-PHY" lcOwn="local"
modTs="2015-02-23T16:13:21.906-08:00" monPolDn="uni/fabric/monfab-default"
name="bsprint-PHY" ownerKey="" ownerTag="" status="" uid="8131">
<infraRsVlanNs childAction="" forceResolve="no" lcOwn="local" modTs="2015-02-
23T16:13:22.065-08:00" monPolDn="uni/fabric/monfab-default" rType="mo" rn="rsvlanNs"
state="formed" stateQual="none" status="" tCl="fvnsVlanInstP" tDn="uni/infra/vlanns-
[bsprint-vlan-pool]-static" tType="mo" uid="8131"/>
<infraRsVlanNsDef childAction="" forceResolve="no" lcOwn="local" modTs="2015-02-
23T16:13:22.065-08:00" rType="mo" rn="rsvlanNsDef" state="formed" stateQual="none"
status="" tCl="fvnsAInstP" tDn="uni/infra/vlanns-[bsprint-vlan-pool]-static"
tType="mo"/>
<infraRtDomP childAction="" lcOwn="local" modTs="2015-02-23T16:13:52.945-08:00"
rn="rtdomP-[uni/infra/attentp-bsprint-AEP]" status="" tCl="infraAttEntityP"
tDn="uni/infra/attentp-bsprint-AEP"/>
</physDomP>

GUI を使用した接続可能アクセス エンティティ プロファイルの作成

この手順では、GUI を使用して接続可能なアクセス エンティティ プロファイル（AEP）が作成されます。

手順

ステップ 1

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 2

[Navigation] ペインで、[Global Policies] > [Attached Acess Entity Profle] の順に選択します。

ステップ 3

[Work] ペインで、[Actions] > [Create Attached Entity Profile] の順に選択します。

ステップ 4

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

1. AEP の名前を入力します。

2. （任意） AEP の説明を入力します。

3. インフラストラクチャ VLAN がこの AEP に関連付けられたリンクを通過するようにするには、[Enable Infrastructure VLAN] チェックボックスにチェックマークを付けてください。

4. [+] をクリックして、ドメインを AEP に関連付けます。

5. 先ほど設定した物理ドメインを選択します。

ステップ 5

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

ステップ 6

[送信（Submit）] をクリックします。

REST API を使用した接続可能アクセス エンティティ プロファイルの作成

次の REST 要求は接続可能アクセス エンティティ プロファイル（AEP）を作成します。

<infraAttEntityP childAction="" configIssues="" descr="" dn="uni/infra/attentpbsprint-AEP"
lcOwn="local" modTs="2015-02-23T16:13:52.874-08:00" monPolDn="uni/fabric/monfab-default"
name="bsprint-AEP" ownerKey="" ownerTag="" status="" uid="8131">
<infraContDomP childAction="" lcOwn="local" modTs="2015-02-23T16:13:52.874-08:00"
rn="dompcont" status="">
<infraAssocDomP childAction="" dompDn="uni/phys-bsprint-PHY" lcOwn="local"
modTs="2015-02-23T16:13:52.961-08:00" rn="assocdomp-[uni/phys-bsprint-PHY]" status=""/>
<infraAssocDomP childAction="" dompDn="uni/l2dom-JC-L2-Domain" lcOwn="local"
modTs="2015-02-25T11:35:33.570-08:00" rn="assocdomp-[uni/l2dom-JC-L2-Domain]"
status=""/>
</infraContDomP>
<infraContNS childAction="" lcOwn="local" modTs="2015-02-23T16:13:52.874-08:00"
monPolDn="uni/fabric/monfab-default" rn="nscont" status="">
<infraRsToEncapInstDef childAction="" deplSt="" forceResolve="no" lcOwn="local"
modTs="2015-02-23T16:13:52.961-08:00" monPolDn="uni/fabric/monfabdefault"
rType="mo" rn="rstoEncapInstDef-[allocencap-[uni/infra]/encapnsdef-
[uni/infra/vlanns-[bsprint-vlan-pool]-static]]" state="formed" stateQual="none"
status="" tCl="stpEncapInstDef" tDn="allocencap-[uni/infra]/encapnsdef-
[uni/infra/vlanns-[bsprint-vlan-pool]-static]" tType="mo">
<fabricCreatedBy childAction="" creatorDn="uni/l2dom-JC-L2-Domain"
deplSt="" domainDn="uni/l2dom-JC-L2-Domain" lcOwn="local" modTs="2015-02-
25T11:35:33.570-08:00" monPolDn="uni/fabric/monfab-default" profileDn=""
rn="source-[uni/l2dom-JC-L2-Domain]" status=""/>
<fabricCreatedBy childAction="" creatorDn="uni/phys-bsprint-PHY" deplSt=""
domainDn="uni/phys-bsprint-PHY" lcOwn="local" modTs="2015-02-23T16:13:52.961-08:00"
monPolDn="uni/fabric/monfab-default" profileDn="" rn="source-[uni/phys-bsprint-PHY]"
status=""/>
</infraRsToEncapInstDef>
</infraContNS>
<infraRtAttEntP childAction="" lcOwn="local" modTs="2015-02-24T11:59:37.980-08:00"
rn="rtattEntP-[uni/infra/funcprof/accportgrp-bsprint-AccessPort]" status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-bsprint-AccessPort"/>
<infraRsDomP childAction="" forceResolve="no" lcOwn="local" modTs="2015-02-
25T11:35:33.570-08:00" monPolDn="uni/fabric/monfab-default" rType="mo"
rn="rsdomP-[uni/l2dom-JC-L2-Domain]" state="formed" stateQual="none" status=""
tCl="l2extDomP" tDn="uni/l2dom-JC-L2-Domain" tType="mo" uid="8754"/>
<infraRsDomP childAction="" forceResolve="no" lcOwn="local"
modTs="2015-02-23T16:13:52.961-08:00" monPolDn="uni/fabric/monfab-default" rType="mo"
rn="rsdomP-[uni/phys-bsprint-PHY]" state="formed" stateQual="none" status="" tCl="physDomP"
tDn="uni/phys-bsprint-PHY" tType="mo" uid="8131"/>
</infraAttEntityP>

インターフェイス ポリシーの作成

次に、インターフェイス プロファイルを定義し、ファブリック ポリシーの再利用を示します。インターフェイス ポリシーは、さまざまなインターフェイス プロファイル定義の要件によって、必要に応じて再利用できます。ここでは、新しいプロファイルの作成について説明しますが、簡単に選択できるポリシーが既に存在していれば理想的です。

- リンク レベル ポリシーの作成

- CDP インターフェイス ポリシーの作成

- LLDP インターフェイス ポリシーの作成

- GUI を使用したポート チャネル ポリシーの作成

- REST API を使用したポート チャネル ポリシーの作成

- GUI を使用したポート チャネル メンバ プロファイルの作成（任意）

- GUI を使用したスパニング ツリー インターフェイス ポリシーの作成（任意）

- GUI を使用したストーム制御ポリシーの作成（任意）

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

- GUI を使用したポート単位 VLAN を有効にするレイヤ 2 インターフェイス ポリシーの作成

リンク レベル ポリシーの作成

リンク レベル ポリシーは、ポートの速度などの設定を行います。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [Link Level] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Link Level Policy] の順に選択します。

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

1. ポリシーのわかりやすい名前を定義します。

2. （任意）ポリシーの説明を入力します。

3. インターフェイスに対してオート ネゴシエーション モードを選択します。

4. インターフェイスの速度を選択します。リーフ スイッチ ポートはデフォルトで 10 GE になります。

5. 必要に応じて、デバウンス間隔を変更します。

5. [Submit] をクリックします。`

XML オブジェクト

<fabricHIfPol autoNeg="on" childAction="" descr="" dn="uni/infra/hintfpol-1G-Auto"
lcOwn="local" linkDebounce="100" modTs="2015-01-14T06:47:15.693-08:00" name="1G-Auto"
ownerKey="" ownerTag="" speed="1G" status="" uid="15374">
<fabricRtHIfPol childAction="" lcOwn="local" modTs="2015-01-14T06:48:48.081-
08:00" rn="rtinfraHIfPol-[uni/infra/funcprof/accportgrp-UCS-1G-PG]" status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-UCS-1G-PG"/>
<fabricRtHIfPol childAction="" lcOwn="local" modTs="2015-02-25T11:48:11.331-
08:00" rn="rtinfraHIfPol-[uni/infra/funcprof/accportgrp-L3-Example]" status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-L3-Example"/>
</fabricHIfPol>

CDP インターフェイス ポリシーの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [CDP Interface] の順に選択します。

3. [Work] ペインで、[Actions] > [Create CDP Interface Policy] の順に選択します。

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

1. ポリシーのわかりやすい名前を定義します（「CDP-Enable」など）。

2. （任意）ポリシーの説明を入力します。

3. 管理状態として [enabled] または [disabled] を選択します。

5. [Submit] をクリックします。`

XML オブジェクト

<cdpIfPol adminSt="enabled" childAction="" descr="" dn="uni/infra/cdpIfP-CDP-Enable"
lcOwn="local" modTs="2015-01-14T06:47:25.470-08:00" name="CDP-Enable" ownerKey=""
ownerTag="" status="" uid="15374">
<cdpRtCdpIfPol childAction="" lcOwn="local" modTs="2015-01-14T07:23:54.957-
08:00" rn="rtinfraCdpIfPol-[uni/infra/funcprof/accportgrp-UCS-10G-PG]" status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-UCS-10G-PG"/>
<cdpRtCdpIfPol childAction="" lcOwn="local" modTs="2015-02-24T14:59:11.154-
08:00" rn="rtinfraCdpIfPol-[uni/infra/funcprof/accbundle-ACI-VPC-IPG]" status=""
tCl="infraAccBndlGrp" tDn="uni/infra/funcprof/accbundle-ACI-VPC-IPG"/>
<cdpRtCdpIfPol childAction="" lcOwn="local" modTs="2015-01-14T06:48:48.081-
08:00" rn="rtinfraCdpIfPol-[uni/infra/funcprof/accportgrp-UCS-1G-PG]" status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-UCS-1G-PG"/>
<cdpRtCdpIfPol childAction="" lcOwn="local" modTs="2015-02-24T11:59:37.980-
08:00" rn="rtinfraCdpIfPol-[uni/infra/funcprof/accportgrp-bsprint-AccessPort]"
status="" tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-bsprint-
AccessPort"/>
<cdpRtCdpIfPol childAction="" lcOwn="local" modTs="2015-02-25T11:48:11.331-
08:00" rn="rtinfraCdpIfPol-[uni/infra/funcprof/accportgrp-L3-Example]" status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-L3-Example"/>
</cdpIfPol>

LLDP インターフェイス ポリシーの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. ナビゲーション ウィンドウで、[Interface Policies] > [Policies] > [LLDP Interface] の順に選択します。

3. [Work] ペインで、[Actions] > [Create LLDP Interface Policy] の順に選択します。

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

1. ポリシーのわかりやすい名前を定義します。

2. （任意）ポリシーの説明を入力します。

3. 受信状態を選択します。

4. 送信状態を選択します。

5. [Submit] をクリックします。`

XML オブジェクト

<lldpIfPol adminRxSt="enabled" adminTxSt="enabled" childAction=""
descr=""
dn="uni/infra/lldpIfP-LLDP-Enable" lcOwn="local" modTs="2015-02-11T07:40:35.664-08:00"
name="LLDP-Enable" ownerKey="" ownerTag="" status="" uid="15374">
<lldpRtLldpIfPol childAction="" lcOwn="local" modTs="2015-02-24T14:59:11.154-
08:00" rn="rtinfraLldpIfPol-[uni/infra/funcprof/accbundle-ACI-VPC-IPG]"
status=""
tCl="infraAccBndlGrp" tDn="uni/infra/funcprof/accbundle-ACI-VPC-IPG"
/>
<lldpRtLldpIfPol childAction="" lcOwn="local" modTs="2015-02-25T11:48:11.331-
08:00" rn="rtinfraLldpIfPol-[uni/infra/funcprof/accportgrp-L3-Example]"
status=""
tCl="infraAccPortGrp" tDn="uni/infra/funcprof/accportgrp-L3-Example"
/>
</lldpIfPol>

GUI を使用したポート チャネル ポリシーの作成

この手順では、GUI を使用して、ポート チャネルのポリシーを作成します。

手順

ステップ 1

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 2

[Navigation] ペインで、[Interface Policies] > [Policies] > [Port Channel Policies] の順に選択します。

ステップ 3

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

ステップ 4

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

1. ポート チャネル ポリシーの名前を入力します。

2. （任意） ポート チャネル ポリシーの説明を入力します。

3. サーバに必要な LACP モードを選択します。

リーフ スイッチで LACP が有効になっている場合は、サーバまたは他の接続デバイスでも LACP を有効にする必要があります。

4. （任意） コントロール状態を選択します。

5. （任意） ポート チャネルのリンクの最小数と最大数を指定します。

（注）

右上隅にあるアイコン i を ポート チャネル ポリシーの作成 ダイアログボックスでクリックして、 Cisco APIC Online Help ファイルにアクセスして、オプションの完全なリストを表示します。

ステップ 5

[送信（Submit）] をクリックします。

REST API を使用したポート チャネル ポリシーの作成

次の REST 要求はポート チャネル ポリシーを作成します。

<lacpLagPol childAction="" ctrl="fast-sel-hot-stdby,graceful-conv,susp-individual"
descr="" dn="uni/infra/lacplagp-LACP-Active" lcOwn="local" maxLinks="16" minLinks="1"
modTs="2015-02-24T11:58:36.547-08:00" mode="active" name="LACP-Active" ownerKey=""
ownerTag="" status="" uid="8131">
<lacpRtLacpPol childAction="" lcOwn="local" modTs="2015-02-24T14:59:11.154-08:00"
rn="rtinfraLacpPol-[uni/infra/funcprof/accbundle-ACI-VPC-IPG]" status=""
tCl="infraAccBndlGrp" tDn="uni/infra/funcprof/accbundle-ACI-VPC-IPG"/>
</lacpLagPol>

（注）

- 対称ハッシュを有効にするために、 ctrl =「対称ハッシュ」 を REST 要求に追加します。

- 対称ハッシュは、次のスイッチではサポートされていません。

- Cisco Nexus 93128TX

- Cisco Nexus 9372PX

- Cisco Nexus 9372PX-E

- Cisco Nexus 9372TX

- Cisco Nexus 9372TX-E

- Cisco Nexus 9396PX

- Cisco Nexus 9396TX

GUI を使用したポート チャネル メンバ プロファイルの作成（任意）

この手順では、GUI を使用して、ポート チャネルのメンバ プロファイルを作成します。

手順

ステップ 1

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 2

[Navigation] ペインで、[Interface Policies] > [Policies] > [Port Channel Member Policies] の順に選択します。

ステップ 3

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

ステップ 4

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

1. ポリシーの名前を入力します。

2. （任意） ポリシーの説明を入力します。

3. 必要に応じて、プライオリティを変更します。

4. 必要に応じて、送信レートを変更します。

ステップ 5

[送信（Submit）] をクリックします。

GUI を使用したスパニング ツリー インターフェイス ポリシーの作成（任意）

スパニング ツリー ポリシーは、サウスバウンド リーフ ポートのスパニング ツリー機能の動作を指定します。一般的なベスト プラクティスは、サーバに接続しているインターフェイスで BPDU ガードを有効にすることです。

（注）

ACI は、リーフとスパイン間のファブリックでスパニング ツリーを実行しません。スパニング ツリー インターフェイス ポリシーは、ポートの動作を定義するだけです。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [Spanning Tree Interface] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Spanning Tree Interface Policy] の順に選択します。

4. [Create Spanning Tree Interface Policy] ダイアログボックスで、次の操作を実行します。

1. ポリシーのわかりやすい名前を定義します。

2. （任意）ポリシーの説明を入力します。

3. BPDU フィルタと BPDU ガード（またはどちらか一方）を有効にします。

5. [送信（Submit）] をクリックします。

GUI を使用したストーム制御ポリシーの作成（任意）

トラフィック ストームは、パケットが LAN でフラッディングする場合に発生するもので、過剰なトラフィックを生成し、ネットワークのパフォーマンスを低下させます。トラフィック ストーム制御機能を使用すると、物理インターフェイス上のブロードキャスト、マルチキャスト、またはユニキャスト トラフィック ストームによって、ポート経由の通信が中断されるのを防ぐことができます。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [Storm Control] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Storm Control Policy] の順に選択します。

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

1. ポリシーのわかりやすい名前を定義します。

2. （任意）ポリシーの説明を入力します。

3. 制御ポリシーの適用方法を指定します（データセンターの要件に一致する合計帯域幅の割合、またはパケット/秒定義として適用）。

5. [送信（Submit）] をクリックします。

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] ペインで、[Interface Policies] > [Policies] > [MCP Interface] の順に選択します。

ステップ 3

[Work] ペインで、[Actions] > [Create Mis-cabling Protocol Interface Policy] の順に選択します。

ステップ 4

[Create Mis-cabling Protocol Interface Policy] ダイアログボックスで、次の操作を実行します。

1. ポリシーの名前を入力します。

2. （任意） ポリシーの説明を入力します。

3. [Admin State] に対して、ポリシーを有効にするには [Enable] を選択し、ポリシーを無効にするには [Disable] を選択します。

ステップ 5

[送信（Submit）] をクリックします。

GUI を使用したポート単位 VLAN を有効にするレイヤ 2 インターフェイス ポリシーの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [L2 Interface] の順に選択します。

3. [Work] ペインで、[Actions] > [Create L2 Interface Policy] の順に選択します。

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

1. L2 インターフェイスの名前、および説明（任意）を入力します。

2. ポート単位の VLAN を有効にするため、VLAN Scope で Port Local scope を選択します。

インターフェイス ポリシー グループの作成

インターフェイス ポリシー グループは複数のインターフェイス ポリシーから構成されており、機能グループとしてインターフェイスに関連付けられます。次の図は、これまでに作成した項目がポリシー グループの下にグループ化されている事を示しています。

ポリシー グループに含まれているポリシー

すべてのインターフェイス ポリシーを定義したら、個々のポリシーを統合してポリシー グループを形成し、インターフェイス プロファイルにリンクすることができます。ポリシー グループは、次のいずれかのマスター定義から定義されます。

- アクセス ポリシー グループ

- ポート チャネル ポリシーグループ

- vPC ポリシー グループ

- GUI を使用したアクセス ポート ポリシー グループの作成

- GUI を使用したポート チャネル インターフェイス ポリシー グループの作成

- VPC インターフェイス ポリシー グループの作成

GUI を使用したアクセス ポート ポリシー グループの作成

アクセス ポート ポリシーは、個々のリンク（非ポート チャネルまたは vPC）に対して定義されます。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policy Groups] の順に選択します。

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

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

1. ポリシー グループのわかりやすい名前を定義します。

2. （任意）ポリシー グループの説明を入力します。

3. 前に作成した、このポリシー グループに関連するプロファイルを使用します。

5. [送信（Submit）] をクリックします。

GUI を使用したポート チャネル インターフェイス ポリシー グループの作成

ポート チャネルは、チャネル グループのメンバーである物理インターフェイス間のトラフィックをロード バランシングします。ポート チャネルに設定する必要があるインターフェイス グループごとに、異なるポリシー グループを作成する必要があります。このポリシー グループは動作を定義します。たとえば、あるポート チャネルにポート 1/1-4 を設定し、別のポート チャネルにポート 1/5-8 を設定する場合は、これらの各グループに対して個別にポリシー グループを作成する必要があります。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policy Groups] の順に選択します。

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

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

1. ポリシー グループのわかりやすい名前を定義します。

2. （任意）ポリシー グループの説明を入力します。

3. 前に作成した、この PC ポリシー グループに関連するプロファイルを選択します。

5. [送信（Submit）] をクリックします。

VPC インターフェイス ポリシー グループの作成

（注）

このオブジェクトは、作成される各 vPC に対して一意である必要があります。

仮想ポート チャネル（vPC）は、2 つの異なるデバイスに物理的に接続されたリンクを、その他のデバイスから単一のポート チャネルとして見えるようにします。ACI では、ダウンストリーム デバイスがアクティブ-アクティブでデュアルホーム接続できるように、リーフ スイッチ ペアが vPC ドメインに設定される場合があります。

vPC に設定する各インターフェイス グループごとに、異なるインターフェイス ポリシー グループを作成する必要があります。vPC ポリシー グループには、ポート チャネルの動作の定義、および ID の両方が含まれています。たとえば、2 つのスイッチ間のひとつの vPC にポート 1/1-4 を設定し、別の vPC にポート 1/5-8 を設定する場合は、これらの各グループに対して個別にポリシー グループを作成する必要があります。

（注）

vPC の場合は、2 つのペア スイッチ間に一意の vPC ドメイン定義が必要です。詳細については後述します。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policy Groups] の順に選択します。

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

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

1. ポリシー グループのわかりやすい名前を定義します。

2. （任意）ポリシー グループの説明を入力します。

3. 前に作成した、この vPC ポリシー グループに関連するプロファイルを選択します。

5. [送信（Submit）] をクリックします。

インターフェイス プロファイル

ACI 内のインターフェイス プロファイルは、インターフェイスの動作を定義するポリシー グループをインターフェイスにリンクします。ポリシーグループは特定のポートを纏めるインターフェースセレクタに割り当てます。次に、インターフェイス プロファイルがスイッチ プロファイルに関連付けられ、設定するリーフ スイッチ上のポートが指定されます。引き続きポート プロファイルを定義していきますが、さまざまなプロファイルが設定されているこのオブジェクト ツリーを見ると、その下位から作業を積み上げてきた様子を確認できます。相互に関連しているこれらの各ポリシーの目的は、ポリシーの再利用を最大化することです。

インターフェイス セレクタとインターフェイス ポリシー グループにリンクしているインターフェイス プロファイル

ポリシーはインターフェイス プロファイルで定義され、インターフェイス セレクタとアクセス ポート ポリシー グループによってポートに割り当てられます。前の項の図は、そのようなポリシーをグループ化することによって何を実現できるかを視覚的に示しています。

- インターフェイス プロファイルの作成

- GUI を使用したインターフェイス セレクタの作成

- GUI を使用したポート チャネルのインターフェイス プロファイルの作成

- 仮想ポート チャネルのインターフェイス プロファイルの作成

- 仮想ポート チャネル用の vPC ドメインの作成

インターフェイス プロファイルの作成

インターフェイス プロファイルは次の 2 つのプライマリ オブジェクトから構成されます。インターフェイス セレクタとアクセス ポート ポリシー グループ。インターフェイス セレクタは、どのインターフェイスがアクセス ポート ポリシーを適用するかを定義します。同じ属性を共有するポートは、同じインターフェイスプロファイルにグループ化できます。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

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

3. [Work] ペインで、[Actions] > [Create Interface Profile] の順に選択します。

4. [Create Interface Profile] ダイアログボックスで、次の操作を実行します。

1. プロファイルのわかりやすい名前を定義します。

2. （任意）プロファイルの説明を入力します。

5. [送信（Submit）] をクリックします。

GUI を使用したインターフェイス セレクタの作成

この手順では、GUI を使用してインターフェイス セレクタを作成します。

手順

ステップ 1

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 2

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

ステップ 3

[Work] ペインで、[Actions] > [Create Access Port Selector] の順に選択します。

ステップ 4

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

1. プロファイル名を入力します。

2. （任意） プロファイルの説明を入力します。

3. インターフェイス ID を入力します。

4. ポートが FEX に接続されたら、[Connected to FEX] ボックスにチェックマークを付けてください。

5. ポートに関連付けるインターフェイス ポリシー グループを選択します。

ステップ 5

[送信（Submit）] をクリックします。

GUI を使用したポート チャネルのインターフェイス プロファイルの作成

サーバにリーフ スイッチへの複数のアップリンクがある場合は、復元性と負荷分散が有効になるように、それらのリンクを 1 つのポート チャネルにバンドルできます。ACI にこれを設定するには、Port Channel タイプのインターフェイス ポリシー グループを作成して、インターフェイスにバンドルします。異なるポート チャネルには異なるポリシー グループが必要です。

ポート チャネル ポリシーグループ

この手順では、GUI を使用して、ポート チャネルのインターフェイス プロファイルを作成します。

手順

ステップ 1

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 2

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

ステップ 3

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

ステップ 4

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

1. プロファイル名を入力します。

2. （任意） プロファイルの説明を入力します。

ステップ 5

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

次に、インターフェイス ポート セレクタを作成します。ポート チャネルを設定するため、オペレータは、ポート チャネル インターフェイスで必要なインターフェイスをすべて追加します。この例では、インターフェイスのイーサネット 1/1-2 を 1 つのポート チャネルに設定し、インターフェイスのイーサネット 1/3-4 を別のポート チャネルに設定します。

ステップ 6

メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

ステップ 7

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

ステップ 8

[Work] ペインで、[Actions] > [Create Access Port Selector] の順に選択します。

ステップ 9

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

1. プロファイル名を入力します。

2. （任意） プロファイルの説明を入力します。

3. 1 番目のポート チャネルのインターフェイス ID を入力します。

4. インターフェイス ポリシー グループを選択します。

ステップ 10

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

ステップ 11

別のポート チャネルを追加するには、ステップ 8 から 10 を繰り返します。

仮想ポート チャネルのインターフェイス プロファイルの作成

vPC ドメインは、常に 2 つのリーフ スイッチから構成され、リーフ スイッチは 1 つの vPC ドメインのメンバーにのみなることができます。つまり、ACI では、ポリシーの定義は 2 つのスイッチ間で重要になります。2 つのスイッチ間で同じポリシーを再利用し、vPC ドメインを介してペアを定義できます。ファームウェア メンテナンス グループを設定する際は、vPC スイッチ ドメインのメンバーを考慮する必要があります。このことに留意して、ファームウェアのアップグレードによって両方の vPC スイッチ ピアが同時に影響を受けないようにします。この詳細については、「ファームウェアのアップグレードとダウングレード」の項を参照してください。

したがって、2 つの個別のスイッチ ID を示すスイッチ プロファイルを作成する必要があります。同じポリシー グループ内の 2 つのポートとこれらのスイッチとの関係は、インターフェイス プロファイルによって定義されます。

vPC ポリシー グループ

vPC のメンバーになる各側のグループ化されたインターフェイスに対して、同じ手順を繰り返す必要があります。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

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

3. [Work] ペインで、[Actions] > [Create Interface Profile] の順に選択します。

4. [Create Interface Profile] ダイアログボックスで、次の操作を実行します。

1. プロファイルのわかりやすい名前を定義します。

2. （任意）プロファイルの説明を入力します。

5. [Submit] をクリックします。`

6. ナビゲーション ウィンドウで、[Interface Policies] > [Profiles] > [Name_of_Interface_Profile_Created] の順に選択します。

7. [Work] ペインで、[Actions] > [Create Access Port Selector] の順に選択します。

8. [Create Access Port Selector] ダイアログボックスで、次の操作を実行します。

1. プロファイルのわかりやすい名前を定義します。

2. （任意）プロファイルの説明を入力します。

3. インターフェイスの ID を入力します。

4. vPC ポートの動作に関連付けるインターフェイス ポリシー グループを選択します。

9. [送信（Submit）] をクリックします。

仮想ポート チャネル用の vPC ドメインの作成

vPC を設定する場合は、さらに別のステップを実行して、同じ vPC ドメインに 2 つのリーフ スイッチを配置します。

vPC ドメインの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Switch Policies] > [vPC Domain] > [Virual Port Channel default]> の順に選択します。

3. [Work] ペインで、[Actions] > [Create Explicit vPC Protection Group] の順に選択します。

4. [Create Explicit vPC Protection Group] ダイアログボックスで、次の操作を実行します。

1. vPC ドメインのわかりやすい名前を定義します。

2. vPC ドメインを表す一意の ID を入力します。

3. vPC ドメインに組み込む 1 番目のスイッチを選択します。

4. vPC ドメインに組み込む 2 番目のスイッチを選択します。

5. [送信（Submit）] をクリックします。

スイッチ プロファイル

スイッチ プロファイルは、個々のスイッチ ポートの動作を定義するすべてのインターフェイス プロファイルをグループ化します。スイッチ プロファイルは、1 つのスイッチの定義である場合と、複数のスイッチの定義である場合があります。ベスト プラクティスとして、各リーフ スイッチ用のスイッチ プロファイルと、リーフ スイッチの各 vPC ドメイン ペア用の別のスイッチ プロファイルが必要です。

ユーザが作成したインターフェイス プロファイルは、1 つのスイッチ プロファイルによってスイッチに関連付けることができます。または、さまざまなスイッチ プロファイルによって関連付けることができます。同じ方法で設定されたインターフェイス ポートが複数のスイッチにある場合は、同じスイッチ プロファイルを使用すると役立ちます。これによって、各スイッチを個々に設定することなく、運用中に多数のスイッチの設定を変更できます。

再利用

運用面から再度強調しますが、ポリシーの再利用機能は重要です。たとえば、速度 1GB のポートを設定するプロファイルが定義されている場合、そのプロファイルを多数のインターフェイス ポリシー グループに対して再利用できます。スイッチの設定全体に目を通すことで、プロファイルの再利用を拡張して、データセンターの運用を簡素化し、コンプライアンスを確保できます。次の図は、スイッチのラック間でのプロファイルの再利用を示しています。

大規模なポリシーの再利用

上記の図では、トップオブ ラック スイッチが同じスイッチ プロファイルに基づいています。これらのラックがすべて同じ方法で設定されている場合（つまり、同じ方法で配線されている場合）は、スイッチを同じスイッチ プロファイルに割り当てるだけで同じポリシーを再利用できます。これにより、スイッチはプロファイル ツリーを継承し、他のラックとまったく同じように設定されます。

また、プロファイルの削除による影響を確認することも重要です。複数のデバイス間でプロファイルが再使用されている場合は、プロファイルやポリシーを削除する前に、それが使用中かどうかを確認してください。

vPC の作成例

以下の手順は、vPC のブリングアップの様子、および vPC の API POST 設定評価を示しています。次のトポロジを設定します。

トポロジの例

VLAN プールの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Pools] > [VLAN] の順に選択します。

3. [Work] ペインで、[Actions] > [Create VLAN Pool] の順に選択します。

4. [Create VLAN Pool] ダイアログボックスで、次の操作を実行します。

1. プールのわかりやすい名前を定義します。

2. （任意）プールの説明を入力します。

3. 割り当てモードに対して [Static Allocation] をクリックします。注：この例では、プールは VLAN 100 ～ VLAN 199 になります。

REST :: /api/node/class/fvnsVlanInstP.xml

物理ドメインの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Physical and External Domains] > [Physical Domains] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Physical Domain] の順に選択します。

4. [Create Physical Domain] ダイアログボックスで、次の操作を実行します。

1. ドメインのわかりやすい名前を定義します。

2. 前に作成した VLAN プールを選択します。

REST :: /api/node/class/physDomP.xml

アクセス エンティティ プロファイルの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Global Policies] > [Attachable Access Entity Profles] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Attached Entity Profile] の順に選択します。

4. [Create Attached Entity Profile] ダイアログボックスで、次の操作を実行します。

1. AEP のわかりやすい名前を定義します。

2. AEP を表す一意の ID を入力します。

3. [Enable Infrastructure VLAN] チェックボックスはオフのままにします。

4. [+] をクリックし、インターフェイスに関連付けるドメインを追加します。

5. 前に作成した物理ドメインを選択します。

5. [Next] をクリックします。

6. [Submit] をクリックします。`

REST :: /api/node/class/infraAttEntityP.xml

リンク レベル ポリシーの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [Link Level] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Link Level Policy] の順に選択します。

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

1. プールのわかりやすい名前を定義します。

2. （任意）ポリシーの説明を入力します。

3. インターフェイスに対してオートネゴシエーションを選択します。

4. インターフェイス要件に合致する速度を選択します。

5. [Submit] をクリックします。`

REST :: /api/node/class/fabricHIfPol.xml

ポート チャネル ポリシーの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policies] > [Port Channel] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Port Channel Policy] の順に選択します。

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

1. ポリシーのわかりやすい名前を定義します。

2. （任意）プールの説明を入力します。

3. モードで [Active] をクリックします。

5. [Submit] をクリックします。`

REST :: /api/node/class/lacpLagPol.xml

vPC インターフェイス ポリシー グループの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Interface Policies] > [Policy Groups] の順に選択します。

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

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

1. ポリシー グループのわかりやすい名前を定義します。

2. （任意）ポリシー グループの説明を入力します。

3. リンク レベル ポリシーを選択します。

4. ポート チャネル ポリシーを選択します。

（注）

vPC の場合は LACP をお勧めします。ただし、リーフ スイッチに接続しているデバイス上に LACP が設定されていることを確認してください。

5. ポリシー グループに関連付ける AEP を選択します。

5. [Submit] をクリックします。`

REST :: /api/node/class/infraAccBndlGrp.xml

インターフェイス プロファイルの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

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

3. [Work] ペインで、[Actions] > [Create Interface Profile] の順に選択します。

4. [Create Interface Profile] ダイアログボックスで、次の操作を実行します。

1. ポリシー グループのわかりやすい名前を定義します。

2. （任意）ポリシー グループの説明を入力します。

5. [Submit] をクリックします。`

6. [Navigation] ペインで、[Interface Policies] > [Profiles] > [Profiles] > [ACI-VPC-int-profile] の順に選択します。

7. [Work] ペインで、[Actions] > [Create Access Port Selector] の順に選択します。

8. [Create Access Port Selector] ダイアログボックスで、次の操作を実行します。

1. プロファイルのわかりやすい名前を定義します。

2. （任意）説明を入力します。

3. 適切なインターフェイスを選択します。

4. インターフェイス ポリシー グループを選択します。

9. [Submit] をクリックします。`

REST :: /api/node/class/infraAccPortP.xml

スイッチ プロファイルの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

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

3. [Work] ペインで、[Actions] > [Create Switch Profile] の順に選択します。

4. [Create Switch Profile] ダイアログボックスで、次の操作を実行します。

1. プロファイルのわかりやすい名前を定義します。

2. （任意）プロファイルの説明を入力します。

3. スイッチ セレクタで、[+] 記号をクリックします。

1. Name：103 - 104（ノード番号を名前にした例）。

2. Blocks：スイッチ 103 と スイッチ 104 を選択します。

5. [Next] をクリックします。

6. 前に作成したインターフェイス セレクタを選択します。

7. [Finish] をクリックします。

REST :: /api/node/class/infraNodeP.xml

vPC ドメインの作成

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Switch Policies] > [Policies] > [Virual Port Channel default]> の順に選択します。

3. [Work] ペインで、[Actions] > [Create Explicit vPC Protection Group] の順に選択します。

1. [Create Explicit vPC Protection Group] ダイアログボックスで、次の操作を実行します。

2. [Explicit vPC Protection Groups] セクションで、[+] をクリックして vPC 保護グループを作成します。

3. vPC ドメインのわかりやすい名前を定義します。

4. vPC ドメインの一意の ID を入力します。

5. この vPC ペアの 1 番目のスイッチの ID（103）を選択します。

6. この vPC ペアの 2 番目のスイッチの ID（104）を選択します。

4. [Submit] をクリックします。`

REST :: /api/node/class/fabricExplicitGEp.xml

GUI を使用した設定済み vPC の動作の検証

1. メニュー バーで、[Fabric] > [Inventory] の順に選択します。

2. [Navigation] ペインで、[POD 1] > [Node_Name] > [Interfaces] > [vPC Interfaces] の順に選択します。

3. [Work] ペインに、vPC インターフェイスのステータスを示すテーブルが表示されます。適切に設定されている場合は、ステータスが表示され、vPC ドメインが正常に設定されたことが示されます。

CLI を使用した設定済み vPC の動作の検証

スイッチの CLI から直接、vPC の動作を検証することができます。コンソールまたはリーフ ノードのアウトオブバンド管理インターフェイスに接続している場合は、show vpc コマンドを使ってステータスを表示できます。

Leaf-3# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 100
Peer status : peer adjacency formed ok
vPC keep-alive status : Disabled
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 1
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
Operational Layer3 Peer : Disabled
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 up -
vPC status
----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
1 Po1 up success success

次の REST API 呼び出しを使用して、vPC を構築し、スタティック ポート バインディングに vPC を接続できます。

URL: https://{{apic-ip}}/api/policymgr/mo/.xml
<polUni>
<infraInfra>
<!-- Switch Selector -->
<infraNodeP name="switchProfileforVPC_201">
<infraLeafS name="switchProfileforVPC_201" type="range">
<infraNodeBlk name="nodeBlk" from_="201" to_="201"/>
</infraLeafS>
<infraRsAccPortP tDn="uni/infra/accportprof-intProfileforVPC_201"/>
</infraNodeP>
<infraNodeP name="switchProfileforVPC_202">
<infraLeafS name="switchProfileforVPC_202" type="range">
<infraNodeBlk name="nodeBlk" from_="202" to_="202"/>
</infraLeafS>
<infraRsAccPortP tDn="uni/infra/accportprof-intProfileforVPC_202"/>
</infraNodeP>
<!-- Interface Profile -->
<infraAccPortP name="intProfileforVPC_201">
<infraHPortS name="vpc201-202" type="range">
<infraPortBlk name="vpcPort1-15" fromCard="1" toCard="1" fromPort="15"
toPort="15"/>
<infraRsAccBaseGrp tDn="uni/infra/funcprof/accbundle-intPolicyGroupforVPC"/>
</infraHPortS>
</infraAccPortP>
<infraAccPortP name="intProfileforVPC_202">
<infraHPortS name="vpc201-202" type="range">
<infraPortBlk name="vpcPort1-1" fromCard="1" toCard="1" fromPort="1"
toPort="1"/>
<infraRsAccBaseGrp tDn="uni/infra/funcprof/accbundle-intPolicyGroupforVPC"/>
</infraHPortS>
</infraAccPortP>
<!-- Interface Policy Group -->
<infraFuncP>
<infraAccBndlGrp name="intPolicyGroupforVPC" lagT="node">
<infraRsAttEntP tDn="uni/infra/attentp-AttEntityProfileforCisco"/>
<infraRsCdpIfPol tnCdpIfPolName="CDP_ON" />
<infraRsLacpPol tnLacpLagPolName="LACP_ACTIVE" />
<infraRsHIfPol tnFabricHIfPolName="10GigAuto" />
</infraAccBndlGrp>
</infraFuncP>
</infraInfra>
</polUni>
https://{{hostName}}/api/node/mo/uni.xml
<polUni>
<fvTenant descr="" dn="uni/tn-Cisco" name="Cisco" ownerKey="" ownerTag="">
<fvAp descr="" name="CCO" ownerKey="" ownerTag="" prio="unspecified">
<fvAEPg descr="" matchT="AtleastOne" name="Web" prio="unspecified">
<fvRsPathAtt encap="vlan-1201" instrImedcy="immediate" mode="native"
tDn="topology/pod-1/protpaths-201-202/pathep-[vpc201-202]” />
</fvAEPg>
<fvAEPg descr="" matchT="AtleastOne" name="App" prio="unspecified">
<fvRsPathAtt encap="vlan-1202" instrImedcy="immediate" mode="native"
tDn="topology/pod-1/protpaths-201-202/pathep-[vpc201-202]” />
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>

サーバ接続

サーバ接続は、 Cisco Application Centric Infrastructure (ACI) ファブリックで、すべてのアプリケーション ワークロードが適切に機能するために必要です。サーバ インフラストラクチャで指定されたファブリック接続要件を注意深く検討する必要があります。Cisco Unified Computing System（UCS）の場合は、これらの条件に一致するように、ファブリック アクセス ポリシーをプロビジョニングする必要があります。これらのポリシーはすべて、インターフェイス ポリシー グループによって管理されます。ACME 社には、データセンター内に複数の異なるサーバ モデルがあります。たとえば、Cisco UCS B シリーズおよび Cシリーズ、ACI ファブリックに接続する必要があるサード パーティ製サーバなどです。

シスコ UCS B シリーズ サーバ

UCS を ACI ファブリックに接続するときに、ポート側のファブリック インターコネクトで必要とされるレイヤ 2 接続のタイプを最初に決定する必要があります。ベスト プラクティスは、仮想ポート チャネル（vPC）を使用して UCS 環境に接続することで、マルチシャーシ EtherChannel を作成することです。このシナリオでは、個々のリンクとファブリック スイッチのフォールトが軽減され、高いアップタイムが期待されます。

UCS へのリンクを vPC または従来のポート チャネルとして設定するプロセスの詳細については、「ファブリックへの新しいデバイスの追加」の項を参照してください。

スタンドアロン ラック マウント サーバまたはシスコ以外のサーバ

UCS 以外のサーバ アーキテクチャも、ACI ファブリックや Cisco Nexus 2000 ファブリック エクステンダ（FEX）に直接接続できます。ACI ファブリックに接続する場合は、サーバ リンクからの予想されるトラフィックのタイプを調べる必要があります。ワークロードがベアメタル サーバである場合は、トラフィックをポート単位で分類し、タグありまたはタグなしのトラフィックと一致するように、関連する AEP と EPG を適切にマッピングできます。サポートされているハイバーバイザ―を使用する場合は、Virtual Machine Manager（VMM）ドメインを適切に設定し、EPG と AEP のマッピングを介したハイパーバイザとして、ファブリックの対応するポートに関連付ける必要があります。重要なことは、予想されるトラフィックの分類をサーバ インフラストラクチャに接続しているポートにマッピングすることです。

FEX の使用は、ACI ファブリックにホスト デバイスを接続する別の方法です。非ホスト側ポートはサポート対象外という、NX-OSモードに関する制限は引き続き有効です。ポートはホストにのみ接続する必要があり、他のネットワーク デバイスへの接続は正常に動作しません。FEX を使用すると、すべてのホスト側ポートは、ACI ファブリックに直接接続しているかのように扱われます。

ACI の VM ネットワーキングの概要

シスコ アプリケーション セントリック インフラストラクチ（ACI）の最も一般的な使用方法の 1 つは、仮想環境でのアプリケーションの管理と展開を支援することです。ACI を使用すると、同じポリシー セットで仮想と物理の両方のエンドポイントを管理できます。この章では、日常の運用において実行されるさまざまな操作タスクについて説明します。

次のリストは、Virtual Machine Manager（VMM）システムの用語を示しています。

- 仮想マシン コントローラは外部 VMM エンティティです。たとえば、VMware vCenter、VMware vShield、Microsoft Systems Center Virtual Machine Manager（SCVMM）などが該当します。Application Policy Infrastructure Controller（APIC）は、VMM と通信し、仮想ワークロードに適用されるネットワーク ポリシーを公開します。仮想マシン コントローラの管理者は、APIC 管理者に仮想マシン コントローラの認証クレデンシャルを提供します。同じタイプの複数のコントローラが同じクレデンシャルを使用できます。

- クレデンシャルとは、仮想マシン コントローラと通信するための認証情報を指しています。複数のコントローラが同じクレデンシャルを使用できます。

- プールは、VLAN、VXLAN ID、マルチキャスト アドレスなどの、トラフィックのカプセル化 ID の範囲を表します。プールは共有リソースで、VMM などの複数のドメインおよびレイヤ 4 ～ レイヤ 7 のサービスで消費できます。リーフ スイッチは、重複した VLAN プールをサポートしていません。重複 VLAN プールのそれぞれを、同じ接続可能エンティティ プロファイル（AEP）に関連付けることはできません。

- VLAN ベースのポートには、次の 2 種類があります。

- ダイナミック プール：APIC によって内部的に管理され、エンドポイント グループ（EPG）の VLAN を割り当てます。VMware vCenter ドメインはダイナミック プールのみに関連付けることができます。これは、VMM 統合に必要なプール タイプです。

- スタティック プール：EPG はドメインと関係があり、ドメインはプールと関係があります。プールには、さまざまなカプセル化された VLAN および VXLAN が含まれます。スタティック EPG 導入環境の場合、ユーザはインターフェイスとカプセル化を定義します。カプセル化は、EPG が関連付けられているドメインに関連付けられたプールの範囲内である必要があります。

VMM 統合のダイナミック VLAN プールを作成する場合は、中間デバイス（従来のスイッチやブレード スイッチなど）で VLAN 範囲を作成する必要があります。これには、Unified Computing System（UCS）での VLAN の作成が含まれます。

- ACI VM 統合のワーク フロー

- VMware の統合

- VMM ポリシー モデルの連携

- VMM ドメインへの EPGS のパブリッシュ

- vCenter のエンドポイント グループ ポート グループへの仮想マシンの接続

- Microsoft SCVMM の統合

- 仮想エンドポイント ラーニングの確認

- VMware 統合の使用例

ACI VM 統合のワーク フロー

ACI VM 統合のワーク フロー

Application Policy Infrastructure Controller (APIC)Application Policy Infrastructure Controller (APIC) による VMware vSphere Distributed Virtual Switch の展開方法については、『Cisco APIC Getting Started Guide』を参照してください。

Microsoft SCVMM と Cisco Application Centric Infrastructure (ACI) を統合をイネーブルにする方法の詳細とワークフローについては、『Cisco ACI with Microsoft SCVMM Workflow』を参照してください。

VMware の統合

Cisco Application Centric Infrastructure (ACI) を VMware インフラストラクチャに統合する場合は、ネットワークの展開に対して 2 つのオプションがあります。VMware ドメインは、VMware vSphere Distributed Virtual Switch（DVS）または Cisco Application Virtual Switch（AVS）を利用して展開できます。どちらも同様の基本的な仮想ネットワーク機能を備えていますが、AVS には、VXLAN やマイクロセグメントのサポートなど、特別な機能が追加されています。ACME 社は AVS の特別機能を活用することにしました。VMware の標準 DVS を使用することに関心がある組織の方は、次のドキュメントを参照してください。

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/getting-started/video/cisco_apic_create_vcenter_domain_profile_using_gui.html

ACI 1.2 リリースは vCenter 6.0 および DVS のみに対する次の機能をサポートします。

- データセンターでの DVS 間の vMotion

- 同じ vCenter 内のデータセンター間の vMotion

- vCenter 間の vMotion

- vSphere 5.1 および 5.5 を使用した vSphere 6.0 への ACI 展開のアップグレード

- vSphere 6.0 での vShield 5.5

- vSphere 6.0 での NSX Manager 6.1

次の機能はサポートされていません。

- 長距離 vMotion

VMM ポリシー モデルの連携

下記は、VM 統合の設定に関連するさまざまな ACI ポリシーの一部を示しています。これは、さまざまなポリシーを相互に関連付ける上で参考になります。

VMM ポリシー モデルの連携

VMM ドメインへの EPGS のパブリッシュ

ここでは、Virtual Machine Manager（VMM）ドメインに既存のエンドポイント グループ（EPG）をパブリッシュする方法について説明します。EPG の作成方法の詳細については、「テナント」の項を参照してください。

VMM ドメインに EPG をプッシュする場合は、テナントの EPG 内でドメインのバインディングを作成する必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 Tenant_Name > Application Profiles > Application_Profile_Name > Application EPGs > Application_EPG_Name > Domains (VMs and Bare-Metals) の順に選択します。

4. [Work] ペインで、[Actions] > [Add VM Domain Association] の順に選択します。

5. [Add VM Domain Association] ダイアログボックスで、前に作成した VMM ドメイン プロファイルを選択します。

1. [Deployment and Resolution Immediacy] に対しては、デフォルトの [On Demand] オプションを使用することをお勧めます。これによって、この EPG に割り当てられたエンドポイントを接続するときに、リーフ ノードにポリシーを展開するだけで、ファブリックで最適なリソース使用を実現できます。このデフォルトを選択したままにしておくと、通信の遅延やトラフィック損失が発生しません。

6. [Submit] をクリックします。` これで、VMM のポート グループとして EPG を 使用できます。

vCenter のエンドポイント グループ ポート グループへの仮想マシンの接続

1. VI クライアントを使用して vCenter に接続します。

2. [Host and Clusters] ビューで、仮想マシンを右クリックし、[Edit Settings] を選択します。

3. [Network Adapter] をクリックし、[Network Connection] ドロップダウン ボックスで EPG に対応するポート グループを選択します。データは次の形式で表示されます。[TENANT | APPLICATION_PROFILE | EPG | VMM_DOMAIN_PROFILE]

[Network Connection] リストに自分の Cisco Application Centric Infrastructure (ACI) EPG が表示されない場合は、次のいずれかを意味しています。

- Application Policy Infrastructure Controller (APIC) が管理する分散スイッチに接続されていないホストで、VM が実行されています。

- APIC と vCenter 間で、OOB または INB 管理ネットワークを介しての通信に問題がある可能性があります。

Microsoft SCVMM の統合

次の図は、Cisco Application Centric Infrastructure (ACI) との System Center Virtual Machine Manager（SCVMM）導入の典型的なトポロジを示しています。SCVMM 仮想マシンと Application Policy Infrastructure Controller (APIC) 間の Hyper-V クラスタリング接続を管理ネットワークで実行することができます。

次の SCVMM 導入のトポロジ ACI

- ACI SCVMM のワークフロー

- ACI および SCVMM コントラクトのマッピング

- APIC コントローラへの複数の SCVMM のマッピング

- OpFlex 証明書が SCVMM から APIC への接続のために展開されていることの確認

- APIC から SCVMM への VMM の展開の確認

ACI SCVMM のワークフロー

次の図に、Microsoft SCVMM と Cisco Application Centric Infrastructure (ACI) とを統合するためのワークフローを示します。

ACI SCVMM のワークフロー

Microsoft SCVMM と ACI の統合のワークフローの詳細については、『Cisco ACI with Microsoft SCVMM Workflow』を参照してください。

ACI および SCVMM コントラクトのマッピング

次の図に、Cisco Application Centric Infrastructure (ACI) および SCVMM コントラクト（SCVMM コントローラ、クラウド、論理スイッチ）のマッピングを示します。

ACI および SCVMM コンストラクト

1 つの VMM ドメインを、同じ SCVMM に複数回マッピングすることはできません。Application Policy Infrastructure Controller (APIC) コントローラは、最大 5 つの SCVMM コントローラに関連付けることができます。その他の制限の詳細については、『Verified Scalability Guide for Cisco ACI』 を参照してください。

APIC コントローラへの複数の SCVMM のマッピング

複数の SCVMM が Application Policy Infrastructure Controller (APIC) コントローラに関連付けられている場合、必要に応じて、第 1 の SCVMM のコントローラの Opflex 証明書を第 2 のコントローラやその他のコントローラにコピーする必要があります。ローカル SCVMM コントローラで certlm.msc コマンドを使用して、証明書を次の場所にインポートします。

Certificates - Local Computer > Personal > Certificates

この SCVMM コントローラが管理する Hyper-V サーバ上に同一の Opflex 証明書が導入されます。Hyper-V サーバに証明書をインストールするには、mmc コマンドを使用します。

OpFlex 証明書が SCVMM から APIC への接続のために展開されていることの確認

OpFlex 証明書が SCVMM から Application Policy Infrastructure Controller (APIC) への接続に対して展開されていることを、 C:\Program Files (x86)\ApicVMMService\Logs\ ディレクトリにある、Cisco_APIC_SCVMM_Service ログ ファイルを表示することで確認できます。ファイルでは、次のことを確認してください。

- 正しい証明書が使用されている

- 次へのログインに成功しました. APIC

次のサンプル ログ ファイルは、これらを示しています。

2/22/2016 1:14:07 PM-1044-13||UpdateCredentials|| AdminSettingsController: UpdateCredentials.
2/22/2016 1:14:07 PM-1044-13||UpdateCredentials|| new: EndpointAddress: Called_from_SCVMMM_PS,
Username ApicAddresses 192.168.1.47;192.168.1.48;192.168.1.49 CertName: OpflexAgent
2/22/2016 1:14:07 PM-1044-13||UpdateCredentials|| ########
2/22/2016 1:14:07 PM-1044-13||UpdateCredentials|| oldreg_apicAddresses is
2/22/2016 1:14:07 PM-1044-13||UpdateCredentials|| Verifying APIC address 192.168.1.47
2/22/2016 1:14:07 PM-1044-13||GetInfoFromApic|| Querying URL https://192.168.1.47/api/node/class/infraWiNode.xml
2/22/2016 1:14:07 PM-1044-13||GetInfoFromApic|| HostAddr 192.168.1.47
2/22/2016 1:14:07 PM-1044-13||PopulateCertsAndCookies|| URL:/api/node/class/infraWiNode.xml
2/22/2016 1:14:07 PM-1044-13||PopulateCertsAndCookies|| Searching Cached Store Name: My
2/22/2016 1:14:07 PM-1044-13||PopulateCertsAndCookies|| Using Certificate CN=OpflexAgent, C=USA, S=CA, O=TS,
E=sj_aci_sol@lab.local in Cached Store Name:My
2/22/2016 1:14:07 PM-1044-13||PopulateCertsAndCookies|| Using the following CertDN:
uni/userext/user-admin/usercert-OpFlexAgent
2/22/2016 1:14:07 PM-1044-13||GetInfoFromApic|| IFC returned OK to deployment query
2/22/2016 1:14:07 PM-1044-13||GetInfoFromApic|| Successfully deserialize deployment query response
2/22/2016 1:14:07 PM-1044-13||UpdateCredentials|| ApicClient.Login(addr 192.168.1.47) Success.

APIC から SCVMM への VMM の展開の確認

C:\Program Files (x86)\ApicHyperAgent\Logs ディレクトリにあるログ ファイルを表示することで、OpFlex 証明書が Hyper-V サーバに展開されたことを確認できます。ファイルでは、次のことを確認してください。

- 正しい証明書が使用されている。

- ファブリック リーフで Hyper-V サーバとの接続が確立されている。

SCVMM では、次のことを確認してください。

- [ファブリック（Fabric）] > [論理スイッチ（Logical Switches）] の下で、SCVMM から「apicVswitch_VMMdomainName」が Application Policy Infrastructure Controller (APIC) から SCVMM に展開されていることを確認します。

- [Fabric] > [Logical Networks] の下で、「apicLogicalNetwork_VMMdomainName」がAPICconrefAPICから SCVMM に展開されていることを確認します。

- [Fabric] > [Port Profiles] の下で、「apicUplinkPortProfile_VMMdomainName」が展開されていることを確認します。そうでない場合、[Servers] の下のホストに移動し、ホストを右クリックして [Properties] を選択します。[Virtual Switches] に移動し、物理アダプタが仮想スイッチに接続されていることを確認します。

- VTEP 仮想ネットワーク アダプタが、仮想スイッチに追加され、IP アドレスが VTEP のアダプタに割り当てられます。

（注）

APIC GUI では、SCVMM の最初の 3 つの箇条書き項目が満たされるまで、Hyper-V サーバと仮想マシンは、Microsoft SCVMM のインベントリの下に表示されません。

VMM 展開を確認するためのその他のトラブルシューティングのヒント

- APIC_SCVMM_Service エージェントおよび APIC_Hyper-V エージェントのログは、それぞれ、C:\Program Files(x86)\ApicVMMService および C:\Program Files(x86)\ApicHypervAgent ディレクトリにあります。

- これらのサービスに対するサポート スクリプトがあります。サポート スクリプトをデバッグ モードで実行し、それぞれ SCVMM コントローラまたは Hyper-V サーバのサービス ステータスおよび設定をより詳細に把握することができます。

サポート スクリプトを使用するには、次の手順を実行します。

1. スクリプトを右クリックします。

2. [Edit] を選択します。[Power Shell ISE] ウィンドウが開きます。

3. 上部のバーにある [Debug] をクリックして、スクリプトを実行します。

4. 問題に対するスクリプトの出力を確認します。

仮想エンドポイント ラーニングの確認

VM を適切なポート グループ/EPG に接続したら、APIC が仮想エンドポイントを学習したことを確認する必要があります。

APIC の VM エンドポイント ラーニングの GUI による確認

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [Application_EPG_Name] の順に選択します。

4. [Work] ペインで、[Operational] タブをクリックします。注：現在のタブにクライアント エンドポイントが表示されます。すべてのエンドポイント（仮想または物理）が表示されます。ここで、[Learning Source] カラムをフィルタリングして、値「Learned VMM」を持つ行を表示すると、自分の仮想マシンを見つけることができます。

APIC の VM エンドポイント ラーニングの CLI による確認

「moquery」（管理対象オブジェクト クエリー）コマンドを使用し、2 つのフィルタを追加することで、CLI から上記と同じ情報を確認できます。1 つは EPG の識別名（DN）用、もう 1 つは「fvCEp」（ファブリック ベクトル クライアント エンドポイント）のクラス名用です。

moquery -c fvCEp --dn uni/tn-<TENANT_NAME>/ap-<APP_PROFILE_NAME>/epg-<EPG_NAME>

GUI で EPG を右クリックし、[Save As] を選択して XML オブジェクトを表示することで、EPG の DN を確認できます。このファイルで、特定の EPG の DN エントリを調べます。

<imdata totalCount="1"><fvAEPg uid="15374" triggerSt="triggerable" status=""
scope="2588672" prio="unspecified" pcTag="49159" name="epg-od"
monPolDn="uni/tn-common/monepg-default" modTs="2015-02-06T06:46:24.729+11:00"
matchT="AtleastOne" lcOwn="local" dn="uni/tn-mb-tennant1/ap-mb-app-pro/epg-epg-od"
descr="" configSt="applied" configIssues="" childAction=""/></imdata>

次に、この DN を moquery コマンドで使用すると、EPG のクライアント エンドポイントのリストが返されます。

admin@apic1:~> moquery -c fvCEp --dn uni/tn-mb-tennant1/ap-mb-app-pro/epg-epg-od
Total Objects shown: 1
# fv.CEp
name : 00:50:56:BB:8C:6A
childAction :
dn : uni/tn-mb-tennant1/ap-mb-app-pro/epg-epg-od/cep-00:50:56:BB:8C:6A
encap : vlan-211
id : 0
idepdn :
ip : 10.10.10.10
lcC : learned,vmm
lcOwn : local
mac : 00:50:56:BB:8C:6A
mcastAddr : not-applicable
modTs : 2015-02-06T06:48:52.229+11:00
rn : cep-00:50:56:BB:8C:6A
status :
uid : 0
uuid :

VMware 統合の使用例

ACME の VMware 管理者は、VLAN セットを ESX ホストにトランキングして、DVS スイッチへの接続を確保することをネットワーク チームに依頼しました。ネットワーク チームは、サーバごとに VLAN をトランキングするのではなく、より俊敏な新しい方法を利用すること、必要な時と場所に応じたリソースのオンデマンド プロビジョニングを活用すること、および、ACI ファブリック内の全 VM ホストに無制限のレイヤ 2 モビリティを提供することを決めました。

これを実行するために、ネットワーク管理者は VMware 管理者と協力し、APIC によって ESX ホストに動的に提供する VLAN の範囲を決定しました。また、未使用の VLAN 範囲（600 ～ 800）も決定しました。これは、ダイナミック VLAN プールです。範囲を決定した後、APIC 管理者は、APIC に vCenter クレデンシャルを許可して、APIC GUI で VMM 統合を設定します。APIC はすべての EPG を動的にプロビジョニングして、ポート グループとして ESX ホストで使用できるようにします。

注：APIC は VMNIC をポート グループに自動的に移動しません。これにより、VMware 管理者は、仮想 NIC を制御してポート グループにオンデマンドで移動きるようになります。

VMware 管理者が ESX ホストをプロビジョニングして、VM に適したポート グループを選択すると、APIC は vCenter と動的に通信して、ポート グループから EPG を使用できるようにします。また、APIC は、必要に応じて、リーフ スイッチに VLAN ID を設定します。

vMotion イベント中、APIC は、VM の移動について自動通知を受けると、エンドポイント トラッキング テーブルを更新してシームレスに通信できるようにします。VM は、vCenter による制限以外の制限を受けることなく、ACI ファブリック内の任意の個所に移動できます。

重要な点は、ACME は、引き続き、ポート単位で EPG を静的にプロビジョニングして、VMware DVS スイッチに従来の VLAN トランキングを展開することを選択可能であり、柔軟なレイヤ 2 ACI ファブリックのメリットを享受できることです。しかし、ACME は最適な展開モデルとして VMM 統合を選択しました。VMM 統合は、組織の課題の克服、オンデマンドのリソース割り当て、および仮想と物理の両環境における可視化とテレメトリの向上を実現する最も効果的な方法であるからです。

Cisco Application Virtual Switch の展開に関する前提条件

- すべてのスイッチ ノードがファブリックによって検出されている。

- INB または OOB 管理接続が設定されている。

- VMware vCenter がインストール済みで設定されており、使用可能である。

- 1 つ以上の vSphere ホストを AVS への展開に使用できる。

- （任意）DNS サーバ ポリシーが設定されており、ホスト名を使用して VMM に接続できる。

- ダイナミック VLAN プールが作成済みで十分な VLAN ID を備えており、各 VMM ドメインへの展開を計画している EPG ごとに 1 つの VLAN を収容できる。

使用する前に

AVS ソフトウェアは、APIC ソフトウェア バージョンから独立して動作するように設計されています。これにより、デバイスを個別にアップグレードできます。常に AVS リリース ノートを参照して、特別な考慮事項があるかどうかを確認してください。

他のソフトウェアと同様、AVS の新バージョンのリリースには新しい機能と機能強化が含まれています。最初にリリースされた AVS ソフトウェア バージョン 4.2.1 の後にバージョン 5.2.1 がリリースされました。『ACI Ecosystem Compatibility List 』マニュアルを参照して、必要な AVS のバージョンが、実行されている APIC および vSphere のバージョンと互換性があることを確認してください。

どちらのバージョンの AVS パッケージにも、vSphere Installation Bundle （VIB）が含まれています。AVS ソフトウェアの各バージョンには、すべてのサポートされている vSphere バージョン用の VIB ファイルが含まれています。本書の発行時点では、vSphere バージョン 5.1 と 5.5 に対応する 2 つの VIB があります（vSphere 5.0 はサポートされていません）。これらは、次の場所の CCO からダウンロードできます。

[Downloads Home] > [Products] > [Switches] > [Virtual Networking] > [Application Virtual Switch]

AVS 4.2.1 Bundle
cross_cisco-vem-v165-4.2.1.2.2.3.0-3.1.1.vib  5.1 VIB
cross_cisco-vem-v165-4.2.1.2.2.3.0-3.2.1.vib  5.5 VIB

AVS 5.2.1 Bundle
cross_cisco-vem-v172-5.2.1.3.1.3.0-3.1.1.vib
cross_cisco-vem-v172-5.2.1.3.1.3.0-3.2.1.vib

AVS VIB のインストール

APIC で AVS を設定する前に、仮想イーサネット モジュール（VEM）と呼ばれる AVS ソフトウェアを vSphere にインストールする必要があります。これはさまざまな方法で実行でき、すべての方法が『Cisco Application Virtual Switch Installation Guide』で説明されています。ホストが少数の場合は、この作業を手動で簡単に実行できますが、10+ ホストの場合は、Virtual Switch Update Manager（VSUM）を利用するとインストール プロセスを自動化できるので、より簡単に実行できます。

手動インストール

1. ホストを [Maintenance] モードにします。

2. ホストに VIB ファイルをコピーします。ホストに VIB をコピーする最も簡単な方法は、[Host] > [Configuration] > [Storage] > [Datastore_X] に移動し、VMware VI クライアントを利用することです。目的のデータストアを右クリックし、[Browse Datastore] を選択します。ここから、ホストのデータストアに VIB を直接アップロードできます。

3. AVS VIB をインストールする vSphere ホストに SSH 接続します。SSH が有効でない場合は、[Host Configuration] > [Security Profile] > [SSH] で有効化できます。

4. esxcli コマンドを使用して、VIB をインストールまたはアップグレードします。

AVS VIB をインストールする場合：

esxcli software vib install -v /<path>/<vibname> --maintenance-mode --no-sig-check

既存の AVS VIB をアップグレードする場合：

esxcli software vib update -v /<path>/<vibname> --maintenance-mode --no-sig-check

出力例は次のとおりです。

# esxcli software vib install -v /vmfs/volumes/datastore1/cross_cisco-vem-v172-
5.2.1.3.1.3.0-3.2 .1.vib --maintenance-mode --no-sig-check
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: Cisco_bootbank_cisco-vem-v172-5.2.1.3.1.3.0-3.2.1
VIBs Removed:
VIBs Skipped:
/vmfs/volumes/53cab6da-55209af3-0ef2-24e9b391de3e # vem version
Running esx version -1623387 x86_64
VEM Version: 5.2.1.3.1.3.0-3.2.1
VSM Version:
System Version: VMware ESXi 5.5.0 Releasebuild-1623387

5. VEM がロードされ、実行されていることを確認します。

# vem status
VEM modules are loaded
Switch Name   Num Ports   Used Ports   Configured Ports   MTU   Uplinks
vSwitch0      3072        6            128                1500  VMNIC0
VEM Agent (vemdpa) is running

接続可能アクセス エンティティ プロファイル（AEP）と AVS

AVS で使用される重要なコンポーネントの 1 つとして、接続可能エンティティ プロファイル（AEP）があげられます。既存の AEP を使用するか、新しい AEP を作成するかに関係なく、AEP ポリシーに対して [Enable Infrastructure VLAN] チェックボックスをオンにする必要があります。これによって、対象トラフィック（DHCP 要求/オファーなど）またはデータ パケットがインフラストラクチャ VLAN から AVS に確実に流れるようになります。AEP は、ホスト側インターフェイスで許可する VLAN を定義します。ドメインがエンドポイント グループにマップされると、AEP では、VLAN が特定のインターフェイスに導入可能なことを確認します。「VM ネットワーキングの概要」の章の「VMM ポリシー モデルの連携」の図に戻って説明すると、AEP とは vSphere ホストが接続されている物理インターフェイスに VMM ドメインを結び付けるものです。AEP は VMM ドメインの作成時にオンザフライで作成できますが、本書では、まず AEP を個別に作成する方法について説明します。

- 新しい AEP の作成

- 既存の AEP の変更

新しい AEP の作成

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

2. [Navigation] ペインで、[Global Policies] > [Attachable Access Entity Profile] の順に選択します。

3. [Work] ペインで、[Actions] > [Create Attachable Access Entity Profile] の順に選択します。

4. [Create Attachable Access Entity Profile] ダイアログボックスで、次の操作を実行します。

1. AEP ウィザードに情報を入力し、[Next] をクリックします。

1. Name：AEP を識別する名前を入力します（「AVS-AEP」など）。

2. Enable Infrastructure VLAN：このチェックボックスをオンにします。

3. Domains (VMs or Baremetal)：空白のままにします。これについては、後ほど「 VMM ドメインへの EPG のパブリッシュ 」の章で説明します。

2. ウィザードの次のページで、AEP に関連付ける [Interface Policy Group] を選択します。この手順では、インターフェイス ポリシー グループが作成済みであることを前提としています。目的のインターフェイス ポリシー グループの [All Interfaces] オプション ボタンをクリックします。

（注）

インターフェイス ポリシー グループの作成は、本書の他の項で説明されています。基本的に、インターフェイス ポリシー グループは、インターフェイス セレクタとプロパティ（速度/ネゴシエーション、LLDP、CDP など）を定義するインターフェイス ポリシーの集合です。インターフェイス ポリシー グループとインターフェイス プロファイルの作成の詳細については、「ファブリックへの新しいデバイスの追加」の章を参照してください。

既存の AEP の変更

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

2. [Navigation] ペインで、[Global Policies] > [Attachable Access Entity Profile] の順に選択します。

1. ナビゲーション ウィンドウで、既存の AEP を選択します。

2. [Work] ペインで、[Enable Infrastructure VLAN] チェックボックスをオンにします。

注：この章の前半で説明したように、OpenFlex 制御チャネルを使用して AVS からファブリックと通信するために、インフラストラクチャ VLAN が必要です。

vCenter の VMM ドメイン

Virtual Machine Manager（VMM）ドメインは、ACI に統合する仮想インフラストラクチャを定義します。これにより、物理エンドポイントに適用するのと同じポリシーを仮想エンドポイントに適用できます。vCenter VMM ドメインは VMware DVS または Cisco AVS を使用して作成されます。一方から他方を変更することはできません。新しい VMM ドメインは AVS 導入をサポートするために一から作成されます。

- AVS スイッチング モード

- AVS の VMM ドメインの作成

- vCenter 上の AVS 展開の確認

- AVS への vSphere ホストの追加

- ESX 上の AVS の確認

- VXLAN ロード バランシング

AVS スイッチング モード

AVS は次のスイッチング モードで実行できます。

- Local Switching：VXLAN カプセル化または VLAN カプセル化をサポートします。

- このスイッチング モードでは、EPG 間のトラフィックを AVS にローカルに切り替えることができます。

- No Local Switch：VLAN カプセル化のみをサポートします。

- このスイッチング モードは、すべてのトラフィック（EPG 間トラフィックを含む）をリーフ スイッチに送信します。

AVS スイッチング モード：ローカル スイッチなしとローカル スイッチング モード

使用するカプセル化（VLAN または VXLAN）の決定には、ファブリック外部の別の VLAN 拡張要件が必要です。VXLAN カプセル化を使用する場合は、インフラストラクチャ VLAN のみを AVS ホストに拡張する必要があります。AVS アップリンクと ACI ファブリック間のすべてのトラフィックは、VXLAN によりカプセル化され、インフラストラクチャ VLAN を使用して転送されます。

VLAN カプセル化を使用する場合は、VM ドメインの VLAN プール内のすべての VLAN をファブリックと AVS ホスト間に拡張する必要があります。これには、中間デバイス（UCS、AVS vSphere ホスト用の vNIC など）における VLAN の作成などが含まれます。

AVS の VMM ドメインの作成

これまでに、DHCP サーバ ポリシーを作成し、AEP を作成または変更しました。この時点で、AVS の VMM ドメインを作成できます。

1. メニュー バーで、[VM NETWORKING] を選択します。

2. [Navigation] ペインで、[Policies] タブを選択します。

3. [Work] ペインで、[Actions] > [Create VCenter Domain] の順に選択します。

4. [Create vCenter Domain] ダイアログボックスで、次の操作を実行します。

1. Name：この値は、vCenter で表示される AVS の「スイッチ名」として使用されます。

2. Virtual Switch：Cisco AVS

3. Switching Preference：[Local Switching] または [No Local Switching] を選択します。

- [No Local Switching] モードの場合：

- Multicast Address：AVS を表すマルチキャスト アドレスを割り当てます。

- Multicast Address Pool：各 AVS vSphere ホストを収容できる十分な大きさのマルチキャスト アドレス プールを作成します。

- [Local Switching] モードの場合：

- Encapsulation：設定に基づいて [VLAN] または [VXLAN] を選択します。

- [VLAN] カプセル化の場合：

- VLAN Pool：VLAN プールを選択または作成します。

- [VXLAN] カプセル化の場合：

- Multicast Address：AVS を表すマルチキャスト アドレスを割り当てます。

- Multicast Address Pool：各 AVS vSphere ホストを収容できる十分な大きさのマルチキャスト アドレス プールを作成します。

4. Attachable Access Entity Profile ：前に作成/変更した AEP を選択します。

5. vCenter Credentials：vCenter に対する管理者権限/ルート アクセス権限があるクレデンシャルを作成します。

6. vCenter ：vCenter の詳細を追加します。

- Name：この vCenter のわかりやすい名前。

- Hostname/IP Address：vCenter の DNS または IP アドレス。

- DVS Version：vCenter のデフォルト。

- Datacenter：vCenter で表示する正確なデータセンター名を入力します。

- Management EPG：管理 EPG への OOB または INB を設定します。

- Associated Credentials：前に作成したクレデンシャル設定を選択します。

- [OK] をクリックし、vCenter の作成を完了します。

5. [送信（Submit）] をクリックします。

vCenter 上の AVS 展開の確認

1. vCenter クライアントで、[HOME] > [INVENTORY] > [NETWORKING] の順に移動し、新しい Distributed Virtual Switch フォルダが作成されたことを確認します。

2. このフォルダを展開し、AVS と、uplink および vtep を含むいくつかのデフォルトのポート グループを検索します。

AVS への vSphere ホストの追加

vCenter で AVS が作成されたら、それにホストを接続する必要があります。これを実行するには、少なくとも 1 つの未使用の物理インターフェイス（VMNIC）を各ホストのアップリンクとして動作させる必要があります。AVS アップリンクは 既存の vSwitch や vDS で共有できません。

1. vCenter クライアントで、[Home] > [Inventory] > [Networking] の順に移動します。

2. 新しく作成された（フォルダでなく）AVS スイッチを右クリックし、[Add Host] を選択します。.

3. [Add Host] ダイアログボックスで、vSphere ホストを選択して AVS に追加し、割り当てられていない VMNIC アップリンクを選択します。

4. ウィザードが完了するまで [Next] をクリックし、現時点では、仮想アダプタまたは仮想マシン ネットワーキングの移行をスキップします。

注：UCS などのブレード スイッチ システムの場合は、使用する VMNIC インターフェイスに使用可能な必須 VLAN がすべて含まれている必要があります。UCS の条件として、サービス プロファイル内の vNIC にすべての関連 VLAN が含まれ、それらがアクティブになっている必要があります。

5. vCenter 内の分散スイッチ上に作成され、「vtep」ポート グループに割り当てられた新しい vmk インターフェイスが表示されます。この VMK が、仮想トンネル エンドポイント（VTEP）インターフェイスとなります。VTEP は、TEP サブネットの APIC から DHCP アドレスを取得しているはずです。下記のスクリーンショットに示すように、VMkernel ポートは APIC から IP アドレスを受信済みです。APIC は、APIC のセットアップ時に作成されたのと同じ 10.0.0.0/16 プ ールを使用して、IPアドレスをプロビジョニングします。これは、AVS と APIC 間の Opflex 通信の準備ができていることを示しています。

~ # esxcfg-VMKNIC -l
Interface  Port Group/DVPort   IP Family  IP Address     Netmask        Broadcast
vmk0       Management Network  IPv4       172.16.176.54  255.255.255.0  172.16.176.255
vmk1       vmotion             IPv4       192.168.99.54  255.255.255.0  192.168.99.255
vmk2       9                   IPv4       10.0.16.95     255.255.0.0    10.0.255.255

MAC Address       MTU   TSO MSS  Enabled Type
00:25:b5:00:00:29 1500  65535    true    STATIC
00:50:56:61:1c:92 1500  65535    true    STATIC
00:50:56:65:3d:b3 1500  65535    true    DHCP

ESX 上の AVS の確認

ESX のコマンドラインで、「vemcmd show openflex」コマンドを実行します。

「status: 12 (Active)」と表示されること、およびスイッチング モードであることを確認します。また、GIPO アドレスが、VMM ドメインの作成中に使用されたマルチキャスト アドレスと同じであることを確認します。

~ # vemcmd show openflex
Status: 12 (Active)
Dvs name: comp/prov-VMware/ctrlr-[AVS-TEST]-VC/sw-dvs-87
Remote IP: 10.0.0.30 Port: 8000
Infra vlan: 4093
FTEP IP: 10.0.0.32
Switching Mode: LS
NS GIPO: 225.127.1.1

AVS ホストで、ホストに展開された各 EPG ごとに 1 つのマルチキャスト グループが存在することを確認します。下記の出力例では、異なる EPG に接続されている 3 種類の仮想マシンがあります。

~ # vemcmd show epp multicast
Number of Group Additions 3
Number of Group Deletions 0
Multicast Address EPP Ref Count
225.0.0.58        1
225.0.0.76        1
225.0.0.92        1

これらのマルチキャスト アドレスは APIC GUI に表示される EPG の詳細と対応しています。EPG の詳細は、[Tenants] > [TenantX] > [Application Profiles] > [ApplicationProfileX] > [End Point Groups] > [EndPointGroupX] で、[Operational] タブの [Client End Points] をクリックすると表示されます。

VXLAN ロード バランシング

VXLAN ロード バランシングは、複数の VMKNIC が Cisco AVS に接続されるとただちに自動的に有効になります。各 VMKNIC は 1 つのアップリンク ポートしか使用できません。VMKNIC とアップリンクは同じ数が必要です。最大 8 個の VMKNIC を Cisco AVS スイッチに接続できます。作成した VMKNIC にはそれぞれ固有のソフトウェア ベースの MAC アドレスがあります。VXLAN ロード バランシングでは、VMKNIC によってデータ パケットに一意の MAC アドレスが付与され、これによって、データ パケットが特定の物理 NIC（VMNIC）を使用するように指定できます。

ホストと同じ数の VMKNIC を持つ必要があります（最大 8 つまで）。たとえば、ホストに 5 つの VMNIC がある場合は、4 つの VMKNIC を追加して VXLAN ロード バランシングを有効にする必要があります。残りの 1 つは、ホストを分散仮想スイッチ（DVS）に追加したときに、Cisco Application Policy Infrastructure Controller（APIC）によって作成済みです。

VMware vSphere Client で、各 AVS アップリンク用の追加の仮想アダプタ（VMK）を作成する必要があります。AVS 用に作成した各 vmk インターフェイスは、vtep ポート グループに接続して、DHCP 用に設定する必要があります。追加された各 VMK インターフェイスに、ファブリック TEP プールから一意の DHCP アドレスが割り当てられます。

AVS 展開における Cisco UCS B シリーズの考慮事項

ここでは、Cisco UCS B シリーズから AVS を有効にする必要手順について重点的に説明します。

USC-B FI では、デフォルトで IGMP スヌーピングが有効になります。そのため、APIC に IGMP クエリア ポリシーを設定する必要があります。IGMP スヌーピング ポリシーは、インフラストラクチャ テナントで有効にする必要があります。

UCS または他の中間ブレード スイッチで IGMP スヌーピングを無効にした場合、ブレード スイッチはすべての関連するポートにマルチキャスト トラフィックをフラッディングするので、IGMP ポリシーは必要ありません。

AVS の IGMP スヌーピング ポリシーの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[infra] を選択します。

3. [Navigation] ペインで、[infra] > [Networking] > [Bridge Domain] > [default] の順に選択します。

1. [IGMP Snoop Policy] ドロップダウン リストで、[Create IGMP Snooping Policy] を選択します

2. ポリシーの名前を入力します（「IGMP_Infra」など）。

3. [Fast Leave] チェックボックスをクリックします。

4. [Enable Querier] チェックボックスをクリックします。

4. [Submit] をクリックします。`

（注）

IGMP スヌーピング クエリアが UCS ファブリック インターコネクトに表示されているかどうかを確認します。この例では、VLAN 4093 はインフラストラクチャ VLAN であり、192.168.0.30 はインフラストラクチャ ブリッジ ドメインのブリッジ ドメイン サブネットです。

ucsb-A(nxos)# show ip igmp snooping querier vlan 4093
Vlan   IP Address      Version   Expires     Port
4093  192.168.0.30     v3        00:03:46    port-channel1

vSphere ホスト CLI で vemcmd show epp multicast コマンドを使用することにより、IGMP スヌーピングが正常に動作しているかどうかを確認できます。他には、UCS 上に IGMP ポリシーを作成して IGMP スヌーピングを無効にする方法があります。この方法では、すべてのエンドポイントにマルチキャスト トラフィックのフラッディングを引き起こす可能性があります。

Cisco Application Virtual Switch によるマイクロセグメンテーション

Cisco Application Virtual Switch（AVS）によるマイクロセグメンテーション（uSeg）は、さまざまな属性に基づいて自動的にエンドポイントをエンドポイント グループに割り当てる機能を提供します。Cisco AVS によるマイクロセグメンテーションは、Cisco AVS リリース 5.2(1)SV3(1.5) で導入されました。この機能は、Cisco Application Centric Infrastructure (ACI) で Cisco AVS についてのみ使用可能です。VMware Distributed Virtual Switch（DVS）には使用できません。エンドポイント グループは現在、アプリケーション エンドポイント グループと uSeg エンドポイント グループの 2 つのカテゴリに分類されます。アプリケーション エンドポイント グループは、vCenter などの VMM に出現するもので、ネットワーク ポート グループとして仮想マシンに割り当てられます。uSeg エンドポイント グループは、同じテナントおよび VMM ドメイン内のすべての仮想マシンに、属性の一致を保留して、暗黙的に適用されます。

Cisco AVS で使用されるマイクロセグメンテーション ポリシーは、Application Policy Infrastructure Controller (APIC) により集約的に管理されてファブリックによって適用されます。uSeg エンドポイント グループは vCenter には出現しません。仮想マシンのネットワーク バインディングを変更すると、[uSeg EPG] は、ポート グループのバインディング オプションとして表示されません。ただし、仮想マシンは、ファブリック内の通常のエンドポイント アプリケーション グループに割り当てられたままになります。

uSeg エンドポイント グループの自動割り当てに使用可能な属性

属性

Attribute Type

VM Name

VM

VM ID

VM

VNIC ID

VM

ハイパーバイザ

VM

DVS ポート グループ

VM

DVS 名

VM

MAC 設定

ネットワーク

IP 設定

ネットワーク

外部レイヤ 2 への ACI の拡張

本書の概要で説明したように、ACME 社は複数のデータセンターを持つ多国籍企業です。したがって、ACME 社はいくつかの レイヤ 2 接続を設定する必要があります。この設定は、データセンター相互接続（DCI）プラットフォームに レイヤ 2 接続を拡張し、さらにリモート データセンターに接続を拡張するか、またはファブリック外部にレイヤ 2 ドメインを拡張して ACI 以外のファブリックの既存のレイヤ 2 ネットワークに接続するために必要です。

- ACI ファブリック外部へのエンドポイント グループの拡張

- ファブリック外部への ACI ブリッジ ドメインの拡張

ACI ファブリック外部へのエンドポイント グループの拡張

ACI ファブリック外部にエンドポイント グループ（EPG）を拡張する最も簡単な方法は、既存のエンドポイント グループに静的にリーフ ポートと VLAN ID を割り当てることです。割り当てると、VLAN ID が設定されているリーフ ポートで受信されたすべてのトラフィックが EPG にマッピングされ、この EPG の設定ポリシーが適用されます。トラフィックの分類はポートで受信されたカプセル化に基づくため、エンドポイントを直接 ACI リーフに接続する必要はありません。

ACI リーフ ポートのレイヤ 2 接続を静的に EPG に 割り当てる手順：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. In the Navigation pane, choose Tenant_Name > Application Profiles > App_Profile_Name > Application EPGs > EPG_Name > Static Bindings (Paths).

4. [Work] ペインで、[Actions] > [Deploy Static EPG on PC, vPC or Interface] の順に選択します。

1. [Path] フィールドで、ポートと VLAN ID を指定します。

2. [Deployment Immediacy] オプション ボタン のいずれかをクリックします。実際の設定がリーフ スイッチ ハードウェアに適用されるタイミングは、展開の緊急度によって決まります。また、この EPG の関連コントラクトをサポートするための VLAN リソースやポリシー連想メモリ（CAM）など、ハードウェア リソースがリーフ スイッチで使用されるタイミングも緊急度によって決まります。[Immediate] オプションを選択すると、EPG の設定とそれに関連するポリシー設定がハードウェアでただちにプログラムされます。[On Demand] オプションを選択した場合、リーフ スイッチは、ポリシーと一致するトラフィックが EPG で受信された場合にのみ、EPG とその関連ポリシーをハードウェアでプログラムします。

3. 次のいずれかの [Mode] オプション ボタンをクリックします。モード オプションは、着信トラフィックへの VLAN ID のタグ付けについて、ACI リーフがどのように想定するかを指定するために使用します。

1. Tagged ‐ リーフ ノードは、事前に確立された特定の VLAN ID が着信トラフィックにタグ付けされているものと想定します。これはデフォルトの展開モードです。ホストからのトラフィックに VLAN ID がタグ付けされている場合は、このモードを選択します。カプセル化 VLAN/VXLAN ID が一意である限り、複数の EPG を同じインターフェイスに静的にバインドできます。

2. [Untagged] ：リーフは、トラフィックに VLAN ID がタグ付けされていないものと想定します。switchport access vlan vlan_ID コマンドと同様、このオプションを使用する場合は、1 つの EPG にのみインターフェイスを割り当てることができます。このオプションを使用すると、通常はタグなしトラフィックを生成するネットワーク インターフェイス カード（NIC）を備えるベアメタル サーバにリーフ ポートを接続できます。ポートには、1 つのタグなしの EPG のみを静的にバインドできます。

3. 802.1P ‐ 802.1P ヘッダーがタグ付けされているトラフィックを参照します。802.1P モードは、（switchport trunk native vlan vlan_ID コマンドと同様に）インターフェイスにタグ付けされていない 1 つの EPG のトラフィックを処理する場合に役立ちます。ただし、（タグなしモードとは異なり）802.1P を使用すると、他の「タグ付き」EPG を同じインターフェイスに静的にバインドできます。このモード分類のリンクで受信されたトラフィックには、次の条件が適用されます。

4. 物理ドメインとそれに関連付ける VLAN プール作成します。

5. 該当する EPG に物理ドメインを関連付けます。

6. 接続可能アクセス エンティティ プロファイル（AEP）を作成し、インターフェイスとポリシーを一緒にマッピングします。

AEP と物理ドメインの設定方法については、「ファブリックへの新しいデバイスの追加」の項を参照してください。

ファブリック外部への ACI ブリッジ ドメインの拡張

レイヤ 2 外部接続はブリッジ ドメインに関連付けられ、ブリッジ ドメインの個々の EPG ではなく、ブリッジ ドメイン全体を外部ネットワークに拡張するように設計されています。

ブリッジ ドメインの外部への拡張を実現するには、ブリッジ ドメイン用にレイヤ 2 外部接続を作成する必要があります。そのプロセスで、外部トラフィックを分類するための新しい外部 EPG を作成します。この新しい EPG は既存のブリッジ ドメインの一部になります。外部接続またはエンドポイントを新しい外部 EPG に分類します。また、2 つの EPG を使用する場合は、その間を通過させるトラフィックを選択する必要があります。既存の EPG にエンドポイントを追加する前述の例と同様、この方式では、エンドポイントが同じサブネットとデフォルト ゲートウェイを共有できます。

外部 レイヤ 2 ドメインを作成する手順：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Networking] > [External Bridged Network] の順に選択します。

4. [Work] ペインで、[Action] > [Create Bridged Outside] の順に選択します。

5. [Create Bridged Outside] ダイアログボックスで、次の操作を実行します。

1. レイヤ 2 外部接続にブリッジ ドメインと VLAN ID を関連付けます。この VLAN は、外部レイヤ 2 ネットワークで設定する必要があります。レイヤ 2 外部接続は、この VLAN と ACI ファブリックのブリッジ ドメインを同じレイヤ 2 ドメインに配置します。この VLAN ID は、レイヤ 2 外部接続に使用される VLAN プールの範囲内でなければなりません。

1. レイヤ 2 ドメインをまだ作成していない場合は、[External Bridged Domain] リストでそれを作成します。

2. レイヤ 2 ドメインの作成時に、VLAN プール が未作成の場合は、それを作成して、レイヤ 2 外部接続の VLAN に関連付けます。この操作で、レイヤ 2 外部接続の作成に使用される VLAN ID の範囲を指定します。これにより、EPG 用の VLAN とレイヤ 2 外部接続用の VLAN 間で VLAN 範囲が重複するのを回避できます。

2. レイヤ 2 境界リーフ ノード、およびレイヤ 2 外部接続用のレイヤ 2 インターフェイスを追加します。

3. レイヤ 2 境界リーフとレイヤ 2 インターフェイスを追加したら、[Next] をクリックし、レイヤ 2 EPG の作成を開始します。レイヤ 2 EPG の名前を入力します。指定された VLAN（ステップ 1 で指定した VLAN ID）が付いたトラフィックは、ACI ファブリックに入ると、すべてこのレイヤ 2 EPG に分類されます。

4. 既存の EPG 内の既存のエンドポイントと新しい外部レイヤ 2 EPG との間の通信を許可するコントラクトを設定します。[Navigation] ペインで、[External Bridged Networks] > [Networks] を選択し、このポリシーを制御するコントラクトを使用コントラクトとして指定します。このコントラクトを内部 EPG のコントラクトとして指定すると、外部レイヤ 2 EPG と既存の内部 EPG 間で通信できるようになります。

5. AEP を作成します。これは、選択したポートで特定のカプセル化（VLAN）を許可するように APIC に指示するポリシー オブジェクトです。接続可能アクセス エンティティ プロファイルの作成方法については、「ファブリックへの新しいデバイスの追加」の項を参照してください。

これで、内部と外部のレイヤ 2 セグメント間に必要な到達可能性を確保できました。

外部レイヤ 3 への ACI の拡張

どのアプリケーションにおいても、最も重要なコンポーネントはユーザまたはカスタマーです。これらは、通常ファブリックに直接接続していないため、外部ネットワークに接続する必要があります。ACME は、社内バックボーンに加えて、モバイル アプリケーションへのアクセス用としてインターネットにも接続できなければなりません。この統合は、テナント ポリシー レベルでシスコ アプリケーション セントリック インフラストラクチャ（ACI）を使用することにより実現できます。ルータなどのデバイスへのレイヤ 3 接続は外部ルーテッド ネットワークと呼ばれ、テナントのプライベート ネットワークと外部 IP ネットワーク間に IP 接続を提供します。各レイヤ 3 外部接続は 1 つのテナント プライベート ネットワークに関連付けられます。レイヤ 3 外部ネットワークの要件は、アプリケーション プロファイルのデバイス グループが ACI ファブリック外部のネットワークへのレイヤ 3 接続を必要とする場合にのみ必要です。

アプリケーション プロファイルによって、オペレータはアプリケーションのさまざまなコンポーネントや階層をエンドポイント グループ（EPG）にグループ化できます。これらのアプリケーション コンポーネントには、外部からの接続に対して要件がある場合があります。次の図は、ファブリックの一部を簡略化して示しています。

階層間にコントラクトがある 3 層アプリケーションのアプリケーション プロファイルの例

たとえば、Web サーバでは、ユーザが外部に到達するための接続が必要です。ACI では、定義されている外部レイヤ 3 エンドポイント グループとのコントラクトによって接続が定義されます。ファブリックのオペレータが指定することにより、テナント管理者は、テナントのアプリケーション プロファイルに対して一意に定義されたレイヤ 3 コンストラクトを使用するか、共有インフラストラクチャを使用して、さまざまな方法で外部レイヤ 3 接続とインターフェイスをとることができます。

外部レイヤ 3 接続は通常、ACI の境界リーフ コンストラクトで確立されます。ACI リーフは境界リーフになることができます。大規模な ACI 設計では、境界リーフとして専用の ACI リーフを設定すると生産性が向上することがあります。スパイン ノードが外部ルータに接続できないことに注意することが重要です。境界リーフとは、レイヤ 3 デバイスに接続することになるリーフを意味します。サーバなどの他のデバイスは、引き続き境界リーフに接続できます。ACI ファブリックでは、外部レイヤ 3 接続は次のタイプのいずれかです。

1. 物理層 3 インターフェイス

2. 8021.Q タギングがあるサブインターフェイス

3. スイッチ仮想インターフェイス（SVI）

次の図は、パブリックおよびプライベート ネットワークのロジックを示しています。

外部コンシューマ、パブリックおよびプライベート ネットワークに関する注釈付きのアプリケーション プロファイル

外部レイヤ 3 接続を介して接続するデバイスの場合、外部ネットワークは内部 ACI ネットワーク 10.1.1.0/24 を学習しており、これがレイヤ 3 外部接続を介して隣接ルータにアドバタイズされます。プライベート ネットワークの場合、ACI はルーティング プロトコルによってネットワークをレイヤ 3 隣接ルータにアドバタイズせず、ネットワークはファブリックの外部デバイスに到達できません。

Cisco Application Policy Infrastructure Controller（APIC）バージョン 1.1 以前のリリースでは、ファブリックは、関連するブリッジ ドメインでパブリックとしてマークされたサブネットだけをアドバタイズします。ファブリックの外部から学習されたルートは、他のポートを介してアドバタイズされません。この動作は、非トランジット ファブリックと呼ばれます。バージョン 1.1 以降のリリースでは、ACI は中継ネットワークとして機能し、ファブリックのルートだけではなく、外部のレイヤ 3 接続から学習したルートを別の外部レイヤ 3 接続にアドバタイズできます。

ネットワーク チームは、テナントに外部レイヤ 3 接続を提供します。一般的な方式の 1 つは、ルータのサブインターフェイスを使用して、異なるレイヤ 3 ドメインを作成することです。これは、各テナントに独自の外部ルータがない可能性があるからです。

- サポートされるルーティング プロトコル

- MP-BGP スパイン ルート リフレクタの設定

- OSPF NSSA によるマルチテナント ネットワーク経由のレイヤ 3 の統合

- 複数テナントの 外部レイヤ 3

サポートされるルーティング プロトコル

書き込み時には次のルーティング プロトコルがサポートされます。

- スタティック ルート：スタティック ルートを外部に定義することができます。スタティック ルートを使用すると、リーフ ノードのルーティング テーブルのサイズと複雑さを軽減できますが、管理者の負担が増加します。スタティック ルートを使用する場合は、外部から戻るための到達可能な内部ネットワークのスタティック パスを設定する必要があります。

- OSPF NSSA：Not-So-Stubby Area（NSSA）を使用して、Open Shortest Path First（OSPF）データベースのサイズを削減し、大きいルート テーブルを持つルーティング プロトコルのオーバーヘッドの保守を軽減します。OSPF NSSA の場合、ルータは、ファブリックからのデフォルト パスを含めて、ルートの集約のみを学習します。OSPF NSSA は、外部レイヤ 3 の内部パブリック サブネット部分を隣接ルータにアドバタイズします。

- iBGP ピアリング リーフと外部ルータ：内部ボーダー ゲートウェイ プロトコル（iBGP）では、ACI は、内部マルチプロトコル ボーダー ゲートウェイ プロトコル（MP-BGP）ルート リフレクタで使用される番号と一致する、1 つの自律システム（AS）番号のみをサポートします。MP-BGP がない場合、レイヤ 3 外部接続の外部ルート（スタティック、OSPF、または BGP）はファブリック内に伝播されず、境界リーフに含まれていない ACI リーフは外部ネットワークに IP 接続できません。両方のケースに対して同じ AS 番号を使用する場合、ユーザは、ACI 境界リーフの接続先ルータの AS 番号を検索し、その番号を ACI ファブリックの BGP AS 番号として使用する必要があります。

MP-BGP スパイン ルート リフレクタの設定

ACI ファブリックのルート リフレクタは、マルチプロトコル ボーダー ゲートウェイ プロトコル（MP-BGP）を使用してファブリック内に外部ルートを配布するので、フル メッシュ BGP トポロジは必要ありません。ACI ファブリックでルート リフレクタを有効にするには、ファブリック管理者が、ルート リフレクタとなる 1 つ以上のスパイン スイッチを選択し、ファブリックに自律システム（AS）番号を指定する必要があります。ルート リフレクタを設定すると、管理者は外部ネットワークへの接続を設定できます。

ACI ファブリックに外部レイヤ 3 デバイスを接続するには、ファブリック インフラストラクチャのオペレータが、ルート リフレクタ ポリシーを設定し、ルート リフレクタとして動作するスパインを指定する必要があります。冗長性のために、ルータ リフレクタ ノードとして複数のスパインを設定します。

テナントでレイヤ 3 接続が必要な場合、インフラストラクチャ オペレータは、WAN ルータが接続されているリーフノードを境界リーフ ノードとして設定する必要があります。これによって、境界リーフ ノードに BGP ピアとして 1 つのルート リフレクタ ノードが組み合わされます。ルート リフレクタを設定すると、それらによってファブリックのルートをアドバタイズできます。

各リーフ ノードには書き込み時に 4000 ルートを格納できます。4000 以上のルートをアドバタイズする必要がある場合、WAN ルータは複数のリーフ ノードを使ってピアします。インフラストラクチャ オペレータは、ノードがアドバタイズできるルート（またはルート プレフィクス）をペア リーフ ノードのそれぞれに設定します。

ルート リフレクタ ポリシーを設定する手順：

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

2. [Navigation] ペインで、[Pod Policies] > [Policies] > [BGP Route Deflector default] の順に選択します。

3. [Work] ペインで、次の操作を実行します。

1. ネットワークに必要な番号と一致するように、[Autonomous System Number] を変更します。

2. このリフレクタ ポリシーのメンバーとなる 2 つのスパイン ノードを追加します。

3. [Submit] をクリックします。`

4. [Navigation] ペインで、[Pod Policies] を選択します。

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

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

1. [BGP Route Reflector Policy] ドロップダウン リストから [default] を選択します。

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

3. [Work] ペインで、[Fabric Policy Group] ドロップダウン リストから [Create Pod Policy Group] を選択します。

4. [Create Pod Policy Group] ダイアログボックスで、[Date Time Policy] ドロップダウン リストから [default] を選択します。

5. [BGP Route Reflector Policy] ドロップダウン リストから [default] を選択します。

6. 設定に応じて、ダイアログボックスの残りの設定を完了させます。

7. [Submit] をクリックします。`

次の図は、外部レイヤ 3 接続のオブジェクトとその関係を示しています。

レイヤ 3 外部オブジェクトの関係

OSPF NSSA によるマルチテナント ネットワーク経由のレイヤ 3 の統合

次の図は、OSPF を使用して ACI に外部レイヤ 3 を統合する仕組みを簡略化して示しています。

2 つの境界リーフと通信する外部 OSPF ルータの論理トポロジ

このセットアップには、リーフ スイッチに接続する 2 つのインターフェイスを持つ 1 つのルータが含まれています。

注：ルータに接続しているリーフのインターフェイスに対してアクセス ポリシーを設定するには、「ファブリックへの新しいデバイスの追加」の項を参照してください。

OSPF/NSSA によってマルチテナント ネットワーク経由でレイヤ 3 を統合する手順：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Networking] > [External Routed Networks] を選択します。

4. [Work] ペインで、[Actions] > [Create Routed Outside] の順に選択します。

5. [Create Routed Outside] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プロファイルの名前を入力します。

2. [Private Network] ドロップダウン リストから、テナントのプライベート ネットワークを選択します。

3. [OSPF] チェックボックスをオンにします。

4. [OSPF Area ID] フィールドに、OSPF エリア ID を入力します（「1」など）。

5. [OSPF Area Control] セクションで、[Send redistributed LSAs into NSSA area] チェックボックスをクリックします。

6. [OSPF Area Type] セクションで、[NSSA Area] オプション ボタンをクリックします。

7. [Nodes and Interfaces Protocol Profiles] セクションで、[+] をクリックしてプロファイルを追加します。

8. [Create Node Profile] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プロファイルの名前を入力します。

2. [Nodes] セクションで、[+] をクリックしてノードを追加します。

3. [Select Node] ダイアログボックスで、次の操作を実行します。

1. [Node ID] ドロップダウン リストで、ノードを選択します（[Leaf-1] など）。

2. [Router ID] フィールドに、ID としてルータの IP アドレスを入力します（「10.0.1.1」など）。

3. [Router ID as Loopback Address] チェックボックスをオフにします。

4. [Loopback Addresses] セクションで、[+] をクリックしてループバック アドレスを追加します。

5. ループバック アドレス（「10.254.254.1」など）を入力し、[Update] をクリックします。

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

4. [OSPF Interface Profiles] セクションで、[+] をクリックし、OSPF インターフェイス プロファイルを作成します。

5. [Create Interface Profile] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プロファイルの名前を入力します。

2. [OSPF Policy] ドロップダウン リストで、[Create OSPF Interface Policy] を選択します。別の OSPF ルータとの相互作用を定義する場合は、ポリシーの相互作用を指定する必要があります。本書では、さまざまな OSPF パラメータについては説明しません。

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

1. [Name] フィールドに、OSPF ポリシーの名前を入力します（「OSPF- Point2Point」など）。

2. [Network Type] セクションで、隣接ルータと一致するオプション ボタン（[Point to Point] など）をクリックします。

3. 設定に応じて、ダイアログボックスの残りの設定を完了させます。

4. [Submit] をクリックします。`

4. [Interfaces] セクションで、[Routed Intefaces] タブをクリックします。

5. [+] をクリックし、ルーテッド インターフェイスを選択します。

6. [Select Routed Interface] ダイアログボックスで、次の操作を実行します。

1. [Path] ドロップダウン リストから、リーフのインターフェイスを選択します（e1/9 on Leaf-1 など）。

2. [IP Address] フィールドに、レイヤ 3 外部プロファイルに関連付けられているパスの IP アドレス（「10.0.1.1/24」など）を入力します。

3. [MTU (bytes)] フィールドに、外部ネットワークの最大 MTU を入力します（例のピア ルータに一致する「1500」など）。

4. 設定に応じて、ダイアログボックスの残りの設定を完了させ、[OK] をクリックします

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

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

9. [次へ（Next）] をクリックします。

10. [External EPG Networks] セクションで、[+] をクリックし、外部ネットワークを作成します。

11. [Create External Network] ダイアログボックスで、次の操作を実行します。

1. [IP Address] フィールドに、「0.0.0.0/0」を入力してサブネットの学習を許可し、[OK] をクリックします。

12. [Finish] をクリックします。次に、外部ネットワーク EPG を設定する必要があります。

複数テナントの 外部レイヤ 3

ACI では、さまざまな機能を使用して、複数のテナントに対して同じ外部レイヤ 3 ルータを再利用できます。隣接ルータがレイヤ 2 トランク インターフェイスを備えた Cisco Nexus シリーズ スイッチの場合は、SVI を介してルーティングするように外部レイヤ 3 接続を設定できます。サブインターフェイスを使用可能なルータの場合は、それらを使用して、複数の VRF やテナントに複数の外部レイヤ 3 接続を提供できます。ファブリック オペレータは、サブインターフェイスまたは SVI を使用して、複数の外部レイヤ 3 接続を設定し、それを各テナントに提供できます。

アプリケーションの移行の使用例

ACI ファブリックを運用しているときに、ACI ファブリックの外部からワークロード、サーバ、または仮想ホストを移行しなければならない場合があります。一般的な例として、従来のデータセンター構成から ACI を使用するポリシー主導型データセンターに移行する場合などがあげられます。ACME がさらに多くのデータセンターで ACI の使用を開始するには、これらの移行を実行する必要があります。この例では、ACME はスイッチ仮想インターフェイス（SVI）の移行を管理することに加えて、トラフィックがレイヤ 2 外部ネットワークを通じて ACI ファブリックに到達できるように、ポリシーを管理する必要があります。

おおまかに説明すると、まず、レイヤ 2 外部ネットワークを設定し、ソース VLAN からのトラフィックが ACI ファブリックの同じ VLAN と通信できるようにする必要があります。また、SVI 移行後の完全接続に備えて、ファブリックから既存のレイヤ 3 ネットワークへのレイヤ 3 接続を設定する必要があります。

ポリシーを含めたレイヤ 2 とレイヤ 3 接続の詳細および作成手順については、本書の「ファブリック接続」の章を参照してください。

外部レイヤ 2 ネットワーク（これを介して、ワークロードやホストが到達）と既存の内部ファブリック EPG 間の接続が正常に確立されたら、移行プロセスを開始して、ファブリックにアプリケーション ワークロードを移動できます。考慮すべき重要事項の 1 つとして、既存の環境から ACI ファブリックに SVI インターフェイスをスイッチ オーバーするタイミングと、SVI ネットワークにルートをアドバタイズするタイミングがあげられます。SVI が外部レイヤ 2 ネットワーク上に存在する場合は、ホストの大部分を移行してから、SVI を ACI ファブリックに移動することをお勧めします。

- ACI へのネットワークの拡張

ACI へのネットワークの拡張

ACME は、サイトの 1 つをレガシー データセンター アーキテクチャから次世代の Cisco Application Centric Infrastructure (ACI) ファブリックに移行することを希望しています。必要に応じて ACI の革新的技術を活用すると同時に、最小限のサービス中断でサイトを移行する必要があります。ACME はいくつかの段階を踏んで移行を実行したいと考えています。

移行前のレガシー データセンター：

移行前の従来のデータセンター

移行後の ACI データセンター：

移行後の ACI ベースのデータセンター トポロジ

第 1 段階として、レガシー データセンターから ACI ファブリックへの接続を確立します。この状態で、VLAN=EPG を論理的にマッピングします。レガシー ネットワークから ACI ファブリックへの相互接続は、標準のレイヤ 2 拡張（VLAN/VXLAN）によって実現されます。

既存のアグリゲーション レイヤから ACI 境界リーフへの物理的な接続を確立します。この接続は、仮想ポート チャネル、ポート チャネル、または 1 つのインターフェイスの形式で実現されます。

1. アグリゲーション スイッチ #1 から ACI 境界リーフ #1 への物理的接続を確立します。

2. アグリゲーション スイッチ #1 から ACI 境界リーフ #2 への物理的接続を確立します。

注：ファブリックへの外部物理接続を確立する前に、DCI で使用するアクセス ポートのファブリック アクセス ポリシーを設定する必要があります。アクセス ポリシーの設定の詳細については、本書の「ファブリック接続」の項を参照してください。

アグリゲーション リンクをレイヤ 2 トランクとして設定します。

1. ホスト接続を表す VLAN をトランキングします。これにより、ホスト VLAN をファブリックに拡張できます。

Application Policy Infrastructure Controller (APIC) で、1 つのテナントを設定します。作成したテナントは、ACI ファブリック内でレガシー データセンターを表します。

1. メニュー バーで [Tenants] > [Add Tenant] の順に選択します。

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

1. [Name] フィールドにテナントの名前を入力します。

2. [次へ（Next）] をクリックします。

3. [完了（Finish）] をクリックします。

1 つのプライベート ネットワークを設定します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Private Networks] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Private Network] の順に選択します。

5. [Create Private Network] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プライベート ネットワークの名前を入力します。

2. [Next] をクリックします。

3. [Name] フィールドに、ブリッジ ドメインの名前を入力します。

4. [Forwarding] ドロップダウン リストから [Custom] を選択します。

5. [Layer 2 Unknown Unicast] オプション ボタンで、[Flood] をクリックします。

6. [Multi Destination Flooding] オプション ボタンで、[Flood in BD] をクリックします。

7. [ARP Flooing] チェックボックスをクリックします。

6. [Finish] をクリックします。

注：ファブリック内の不明なユニキャストと arp をフラッディングするのは、レガシー データセンターのレイヤ 2 セマンティックスを ACI ファブリックに拡張できるようにするためです。レガシー データセンターのホストが ARP 要求を送ったり、不明なユニキャスト フレームをフラッディングすると、ブリッジ ドメインは ACI ファブリックでその動作を模倣します。デフォルトでは、BPDU フレームは EPG内にフラッディングされます。

1 つのアプリケーション プロファイルを設定します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Application Profiles] を選択します。

4. [Work] ペインで、[Actions] > [Create Application Profile] の順に選択します。

5. [Create Application Profile] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、アプリケーション プロファイルの名前を入力します。

2. [Submit] をクリックします。`

1 つのエンドポイント グループを設定します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application EPG] の順に選択します。

5. [Create Application EPG] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドにエンドポイント グループの名前を入力します。

2. [Bridge Domain] で、適切なブリッジ ドメインを選択します。

3. [Finish] をクリックします。

注：ファブリック内の EPG はレガシー データセンター内の 1 つの VLAN にマッピングします。ファブリックの革新的技術を導入すると同時に、EPG ごとに 1 つの VLAN を使用して、ネットワーク中心型の移行による影響を最小化するパスを指定します。

レガシー データセンターに接続するための VPC を設定します。「ファブリック接続」の項を参照してください。次に、エンドポイント グループ AcmeOutSide で VPC を使用して、スタティック トランクのバインディングを設定します。カプセル化 VLAN が、定義されているレガシー データセンターの VLAN 定義と一致する必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Domains VMs and Bare-Metals] の順に選択します。

4. [Work] ペインで、[Actions] > [Add Physical Domain Association] の順に選択します。

5. [Add Physical Domain Association] ダイアログボックスで、次の操作を実行します。

1. レガシー データ センターのインターフェイスに関連付ける [Physical Domain Profile] を選択します。

2. [Deploy Immediacy] を選択します。

3. [Resolution Immediacy] を選択します。

4. [Submit] をクリックします。`

6. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Static Bindings (Paths)] の順に選択します。

7. [Work] ペインで、[Actions] > [Deploy Static EPG on PC, VPC or Interface] の順に選択します。

8. [Deploy Static EPG on PC, VPC or Interface] ダイアログボックスで、次の操作を実行します。

1. [Path Type] を選択します。

2. [Path] を選択します。

3. カプセル化 VLAN を入力します。

4. [Submit] をクリックします。`

移行の第 1 段階が完了すると、レガシー ホスト VLAN が ACIファブリックに拡張され、ファブリックの観点から、すべてのホストが EPG AcmeOutSide に含まれます。ローカル VLAN 番号は、レガシー データセンター向けの VPC でタグ付き VLAN にマップされるため、ACIファブリックにとってローカル VLAN 番号は重要ではありません。これは正規化と呼ばれ、ACI はタグ付き VLAN を使用して、外部レイヤ 2 接続を ACI エンドポイント グループにマップします。

以下に示す接続は BD=EPG=VLAN を表しています。ACI ファブリックおよびレガシー データセンターのレイヤ 3 ゲートウェイは、レガシー データセンターによって提供されます。

VLAN データセンター展開としての EPG

移行の第 2 段階では、ファブリック ポリシー モデルを利用して、さらにアプリケーションのモデル化を定義します。この段階では、到達性を定義する APIC コントラクトによって複数の EPG が作成されます。次のリストは、実行する必要があるステップの概要を示しています。

1. APIC で次の手順を実行します。

1. （任意）追加のテナントを設定します。

2. （任意）追加のプライベート ネットワークを設定します。

3. （任意）追加のブリッジ ドメインを設定します。

4. （任意）追加のアプリケーション プロファイルを設定します。

5. 追加のエンドポイント グループを設定します。

1. エンドポイント グループ「AcmeInSide」を作成します。

6. EPG 間通信のコントラクトを設定します。

1. [Scope] ドロップダウン リストから [Tenant] を選択します。

2. [Allow] ドロップダウン リストから [Any-Any] を選択します。

2. ファブリックの EPG「AcmeInSide」へのホストの移行を開始します。

1. 移行する各物理ホストのスタティック バインディングを作成します。

2. （任意）VMM ドメインを作成して、ACI ファブリック内にホストを展開します。

注：接続、VLAN プール、物理ドメインまたは VMM ドメイン、AEP、およびスイッチまたはインターフェイスのプロファイルをサポートする、適切なリソースが作成されていることを確認します。詳細については、「ファブリック接続」の項を参照してください。

移行の第 2 段階が完了すると、レガシー データセンターと ACI ファブリックの両方にわたるホスト接続が、APIC ポリシー（コントラクト）によって管理されるようになります。

注：ACI ファブリックおよびレガシー データセンターのレイヤ 3 ゲートウェイは、レガシー データセンターによって提供されます。

既存の DC によって提供されるレイヤ 3 と ACI データセンターに拡張されたレイヤ 2 によるデータセンターの移行

移行の第 3 段階では、従来のデータセンターから ACI ファブリックにレイヤ 3 ゲートウェイを移動します。次のリストは、実行する必要があるステップの概要を示しています。

1. APIC で、以下を実行します。

1. レイヤ 3 出力を設定します。

2. レガシー データセンターからファブリックにゲートウェイを移行します。

1. [Bridge Domain] ドロップダウン リストから [AcmeBD] を選択します。

2. [Flood Layer 2] ドロップダウン リストから [Unknown Unicast] を選択します。

3. [ARP] ドロップダウン リストから [Flooding] を選択します。

4. [Unicast] ドロップダウン リストから [Routing] を選択します。

注：ブリッジ ドメイン内のユニキャスト ルーティングのコンセプトによって、ファブリック全体にわたる広範なゲートウェイの設定が可能になります。ACI ファブリックおよびレガシー データセンターのレイヤ 3 ゲートウェイは、ACI ファブリックによって提供されます。

Chapter5. テナント

- ACI テナント モデル

- アプリケーション プロファイル

ACI テナント モデル

いくつかの使用例で ACME 社はテナントを使用しています。ACME 社は、現在の展開におけるアプリケーション ライフサイクルのテナント コンストラクトを使用して、開発者がアプリケーションの作成に使用するリソースの個々のテナントを保守します。テナントは自動テストに使用され、最終的には実稼働テナントになります。また、概要で説明したように、ACME は、今後の同様のイニシアティブで活用できるインフラストラクチャを構築することも目指しています。テナントは各種業務の仮想境界を設けるために使用されます。情報セキュリティ チームはこれを社内 LDAP システムに統合し、他のグループに影響を及ぼすような変更を防ぐことができます。

Cisco Application Centric Infrastructure (ACI) は「マルチテナント」として新規に設計されています。つまり、使用者の観点から見ると、使用者に応じて内容が異なる（「クラウド」に類似）ということです。従来のサービス プロバイダーの場合、テナントとはひとつのカスタマーであり、一般的なエンドカスタマー環境では、運用グループ、営業部門、アプリケーション オーナーなどがテナントになります。

テナント モデルの使用方法は、いくつかの要因によって決まります。

1. アプリケーション、ネットワーク、サーバ、セキュリティなど、組織における全体的な IT 運用とサポート モデル。

2. ソフトウェアの開発ライフサイクルから見た、環境の分離（開発、品質保証、実稼働）。

3. ドメイン所有者別（Web、アプリケーション、データベースの所有者など）の業務の分離。

4. フォールトの影響を限定するためのフォールトドメインのサイズとスコープ（さまざまな事業部門など）。

従来のネットワーク環境では、ルータまたはレイヤ 3 スイッチでルーティング プロトコルを変更すると、多数の固有の VLAN やサブネットに影響が及びます。それによって、変更管理とアプリケーションの影響に関する保証レベルの注意が喚起されます。ACI ポリシー モデルを活用すると、論理構造から物理ハードウェアが抽出されます。テナント オブジェクトによって、使用している論理および具象オブジェクトに焦点を当て、基本およびオーバーレイ ネットワークの構造的依存関係について統一見解を持つことができます。

ACI オブジェクト モデル内のテナントは、最上位のオブジェクトを表します。内部では、プライベート ネットワーク（VRF）、ブリッジ ドメイン、サブネットなどのテナント ネットワークを定義するオブジェクトと、アプリケーション プロファイルやエンドポイント グループなどのテナント ポリシーを定義するオブジェクトを区別できます。

ACI では、テナント ポリシーによってアプリケーションを定義します。アプリケーションは、物理サーバ、またはサーバを呼び出す仮想マシンの組み合わせから構成されます。たとえば、Web サイトでは、Web サーバ、アプリケーション サーバ、データベース サーバから構成される 3 層のアプリケーションのモデルを使用できます。ユーザが Web サイトを参照する際は、実際にはロード バランサの仮想 IP アドレスと通信しており、ロード バランサは Web 要求を多数の Web サーバに分配します。次に、それらの Web サーバがコア アプリケーションと通信します。コア アプリケーションは、ロード バランシングやハイ アベイラビリティのために、複数のアプリケーション サーバ間に分割できます。最後に、アプリケーション サーバがサーバのクラスタであるデータベースと通信します。

ACI では、各サーバはエンドポイントと呼ばれます。エンドポイントは ACI で分類され、ポリシーが適用されます。同じタイプのポリシー（通信する相手、必要な通信や制限のタイプなど）を共有するエンドポイントを含むエンドポイント グループを作成します。つまり、アプリケーションは複数のエンドポイント グループから構成することができ、アプリケーション プロファイルでグループ化されます。

テナント ネットワーキングは、ネットワーク ポリシーの定義に使用され、透過的な方法で基盤ハードウェアに適用されます。これは、プライベート ネットワーク、ブリッジ ドメイン、サブネットを使用して ACI が提供する、抽象レイヤによるものです。この章の次の項では、これらの概念について詳しく説明します。下記の図は、テナントを形成しているさまざまなオブジェクトとそれらの関係を示しています。

テナント ネットワーキングとテナント ポリシーは個々に定義されますが、アプリケーションで使用されるネットワーク ポリシーは、エンドポイント グループとブリッジ ドメイン間の関係によって定義されます。

次の図は、テナント内で設定できるすべてのコンポーネントを示しています。以降の項の各図は、ACME 社が各コンポーネントを追加していく様子を示しています。

テナントの論理モデル

デフォルトでは、システムで事前設定された次の 3 種類のテナントがあります。

1. Common（共通）：ACI ファブリックの他のテナントに「共通」のサービスを提供するための特別なテナント。共通テナントの基本原則はグローバルな再利用です。共通サービスの例：

1. 共有 L3Out

2. 共有プライベート ネットワーク

3. 共有ブリッジ ドメイン

4. DNS

5. DHCP

6. アクティブ ディレクトリ

2. Infra（インフラストラクチャ）：トンネルやポリシー展開など、ファブリック内部の通信に使用されるインフラストラクチャ テナント。これには、スイッチ（リーフ、スパイン、アプリケーション仮想スイッチ（AVS））間およびスイッチと Application Policy Infrastructure Controller (APIC) 間の通信が含まれます。インフラストラクチャ テナントは、ユーザ領域（テナント）には公開されず、独自のプライベート ネットワーク領域とブリッジ ドメインを備えています。ファブリックの検出、イメージ管理、ファブリック機能用の DHCP は、すべてこのテナント内で処理されます。

3. Mgmt（管理）：管理テナントには、ファブリック ノードのアクセス ポリシーの設定に役立つ便利な機能があります。ファブリック ノードは APIC を介してアクセスおよび設定できますが、インバンドとアウトバンド接続を使用して直接アクセスできます。インバンドおよびアウトオブバンド ポリシーは管理テナントで設定されます。

- インバンド管理アクセス

- アウトオブバンド管理アクセス

アプリケーション プロファイル

アプリケーション プロファイルは、複数のホスト（物理または仮想）用の便利な論理コンテナです。さまざまな基準に基づいてアプリケーション プロファイル コンテナを作成できます。たとえば、アプリケーションが提供する機能、エンドユーザから見たアプリケーションの様子、アプリケーションを配置するデータセンターのコンテキスト内の場所、実装に関連する他の論理グループ化など。アプリケーション プロファイル サーバは、共通ポリシーの使用に応じてエンドポイント グループにグループ化されます。

アプリケーション プロファイルのメカニズムによって、サーバ グループを 1 つのアプリケーションとして把握することができます。このアプローチにより Cisco Application Centric Infrastructure (ACI) はアプリケーション認識型となり、アプリケーションの一部であるすべてのサーバを全体としてモニタしながらアプリケーションの動作状態をチェックできるようになります。さらに、その特定のアプリケーションに関連するエラーおよびヘルス ステータスが管理者に通知されるようにすることができます。作成する各アプリケーション プロファイルには、一意のモニタリング ポリシーと、適用する QoS ポリシーを含めることができます。

アプリケーション プロファイルはテナントの子オブジェクトであり、1 つのテナントに複数のアプリケーション プロファイルを含めることができます。

テナントへのコンポーネントの追加 - 1. アプリケーション プロファイル

- アプリケーション プロファイルの設定

- エンドポイント グループ

- エンドポイント

- プライベート ネットワーク

- ブリッジ ドメイン

アプリケーション プロファイルの設定

Name：アプリケーション プロファイルの名前。

Tags：タグまたはメタデータは、ファブリック モジュールに割り当てられる非階層型のキーワードまたは条件です。

Monitoring Policy：（任意）EPG セマンティック スコープのモニタリング ポリシー名。

- GUI を使用した新しいアプリケーション プロファイルの作成

- GUI を使用したアプリケーション プロファイル変更

- GUI を使用したアプリケーション プロファイルの削除

- アプリケーション プロファイルの確認

GUI を使用した新しいアプリケーション プロファイルの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application Profile] の順に選択します。

5. [Create Application Profile] ダイアログボックスで、次の操作を実行します。

1. アプリケーション プロファイルの名前を入力します。

2. （任意）説明を入力します。

3. （任意）TAG を入力します。

4. （任意）[Monitoring Policy] を選択します。

6. [送信（Submit）] をクリックします。

GUI を使用したアプリケーション プロファイル変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile] の順に選択します。

4. [Work] ペインで、[policy] を選択します。

5. [Work] ペインで、次の操作を実行します。

1. （任意）説明を入力します。

2. （任意）適切な [TAG] を入力します。

3. （任意）ラベルを入力します。

4. （任意）[QoS Class] を選択します。

5. （任意）[Monitoring Policy] を選択します。

6. [送信（Submit）] をクリックします。

GUI を使用したアプリケーション プロファイルの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile] の順に選択します。

4. [Work] ペインで、[Policy] を選択します。

5. [Work] ペインで、[Actions] > [Delete] の順に選択します。

アプリケーション プロファイルの確認

REST :: /api/node/class/fvAp.xml

CLI :: moquery -c fvAp

エンドポイント グループ

エンドポイント グループ（EPG）は、ファブリック内で類似の機能を実行し、類似のポリシーを共有するサーバまたはホストを論理グループ化するために使用されます。作成する各エンドポイント グループには、固有のモニタリング ポリシーまたは QoS ポリシーを含めることができ、1 つのブリッジ ドメインに関連付けられます。

エンドポイント グループはアプリケーション プロファイルの子オブジェクトであり、1 つのアプリケーション プロファイルに複数のエンドポイント グループを含めることができます。エンドポイント グループ内の各エンドポイントはファブリック内で同じポリシーの影響を受けます。

テナントへのコンポーネントの追加 - 2. アプリケーション プロファイルのエンドポイント グループ

EPG 内のすべてのエンドポイントは相互に通信できます。EPG コントラクト間の通信は、従来のレイヤ 2/レイヤ 3 フォワーディング コンストラクトではなく、コントラクトによって制御されます。たとえば、EPG-A の ホストA は IP アドレス/マスク 10.1.1.10/24 を持ち、EPG B のホストB は IP アドレス/マスク 10.1.1.20/24 を持つことができます（両方のホストが互いに「同じサブネット」に存在していると認識している場合）。この例では、EPG-A と EPG-B 間の接続を許可するコントラクトがない場合、これらのホストは通信できません。コントラクトについては次の項で詳しく説明します。

アプリケーション エンドポイント グループ、外部ブリッジ ネットワーク（別名、外部レイヤ 2）、外部ルーテッド ネットワーク（別名、外部レイヤ 3）、管理エンドポイント グループなど、ファブリック内の一部のエンドポイント グループはアプリケーション プロファイルに含まれていないので注意してください。これらのエンドポイント グループには特別な要件があります。たとえば、外部ブリッジ ネットワークの場合、エンドポイントの MAC アドレスはリーフ スイッチで学習されません。

エンドポイント グループはブリッジ ドメインにリンクされますが、ブリッジ ドメインのレガシー モードを使用しない限り、ブリッジ ドメインとは異なる VLAN ID を受け取ります。

1 つのサブネットを複数の EPG 間に拡張できることを理解する必要があります。各 EPG はカプセル化 VLAN または VXLAN によって識別されるので、同じサブネットがファブリック全体で異なるカプセル化 ID を使用できます。この概念は従来のネットワーキングとは異なります。

- エンドポイント グループのサブタイプ

- 新しいエンドポイント グループの作成

- エンドポイント グループの変更

- エンドポイント グループの削除

- エンドポイント グループの確認

エンドポイント グループのサブタイプ

Application Policy Infrastructure Controller (APIC) ソフトウェア バージョン 1.1 では、従来のエンドポイント グループは次の 2 つのタイプに分けられます。

アプリケーション エンドポイント グループ

従来のエンドポイント グループです。静的パス バインディング、VMM 統合、またはレイヤ 2/レイヤ 3 ドメイン バインディングを使用して、仮想または物理エンドポイントに適用できます。

マイクロセグメント（uSeg）エンドポイント グループ

この分類のエンドポイント グループを使用すると、エンドポイントにさまざまな「属性」をマッチングして、uSeg エンドポイント グループに自動的に割り当てることができます。このタイプのエンドポイント グループは、属性ベースのエンドポイント グループとも呼ばれます。マッチングできる属性には、VM プロパティ（VM 名、VM ID、およびハイパーバイザなど）、MAC アドレス、IP 設定が含まれます。

uSeg エンドポイント グループは、作成されて VMM ドメインに割り当てられると、テナント内に存在する VMM ドメイン内の任意のエンドポイントに対して自動マッチングを行い、エンドポイントを、割り当てられていたアプリケーション エンドポイント グループから uSeg エンドポイント グループに移動します。これが実行されると、uSeg EPG（コントラクト、QoS、モニタリング ポリシーなど）に適用されるポリシーが適用されるようになります。元のアプリケーション EPG のポリシーは、エンドポイントに適用されなくなります。

（注）

VM エンドポイントは、そのアプリケーションのエンドポイント グループに割り当てられていますが、属性の一致があると、ファブリックにより uSeg エンドポイント グループに自動的に移動されます。つまり、仮想マシン マネージャ（vCenter）では、エンドポイントは引き続きアプリケーションの EPG/ポート グループに割り当てられものとして表示されます。ただし、[uSeg EPG] > [Operational] > [Client End Points] で確認すると、新しい uSeg EPG の下に既知のエンドポイントが表示さます。

属性を uSeg エンドポイント グループに追加する場合、そのエンドポイント グループは現在どの VMM ドメインにも割り当てられていないことが必要です。これは、エンドポイント グループが現在、どの VM エンドポイントにも割り当てられていないことを確実にします。これにより、常にバインドされた VM ドメインに誤って属性を割り当てることによって機能エンドポイントをうっかり移動することを防ぐことができます。このため、uSeg エンドポイント グループの作成手順では、最初にエンドポイント グループを作成し、VMM ドメインはその後に追加する必要があります。これにより、VMM ドメインが追加される前に uSeg エンドポイント グループの属性が割り当てられるようになります。

新しいエンドポイント グループの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Application Profiles] > [Application_Profile]> [Application EPGs] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application EPG] の順に選択します。

5. [Create Application EPG] ダイアログボックスで、次の操作を実行します。

1. [Application EPG Name] を入力します。

2. （任意）[Tag] を入力します。

3. （任意）[Qos Class] を入力します。

4. （任意）[Custom Qos] を入力します。

5. ブリッジ ドメイン名を選択するか作成します。

6. （任意）[Monitoring Policy] を選択します。

7. （任意）VM ドメイン プロファイルへの関連付けを選択します。

8. （任意）リーフ/パスと静的にリンクすることを選択します。

6. [Finish] をクリックします。

エンドポイント グループの変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile] > [Application EPGs] > [Application_EPG] を選択します。

4. [Work] ペインで、[policy] を選択します。

1. [Application EPG Name] を入力します。

2. （任意）[Tag] を入力します。

3. （任意）[Qos Class] を入力します。

4. （任意）[Custom Qos] を入力します。

5. [Bridge Domain Name] を入力します。

6. （任意）必要に応じて適切な [Monitoring Policy] を選択します。

7. [Associated Domain Profile Name] を入力します。

5. [Finish] をクリックします。

エンドポイント グループの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Application Profiles] > [Application_Profile] > [Application EPGs] > [Application_EPG] を選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

エンドポイント グループの確認

REST :: /api/node/class/fvAEPg.xml

CLI :: moquery -c fvAEPg

エンドポイント

エンドポイントとは、ネットワークに直接的または間接的に接続されたデバイスです。エンドポイントはアドレス（ID）、ロケーション、属性を備えており、仮想または物理のいずれでもかまいません。各エンドポイントには、パス、カプセル化、展開の即時モードが関連付けられています。

エンドポイントはエンドポイント グループの子オブジェクトであり、エンドポイント グループの構成には複数のエンドポイントを含めることができます。ファブリック内で参照されるエンドポイントは、スタティック（APIC 内で定義）またはダイナミック（vCenter/Openstack で自動化）のいずれでもかまいません。

エンドポイント グループ内でスタティック バインディングを作成することによって、スタティック エンドポイントを追加できます。スタティック バインディングの例を次に示します。ダイナミック バインディングの例については、VVM の項を参照してください。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Static Bindings (Paths)] の順に選択します。

4. [Work] ペインで、[Actions] > [Deploy Static EPG on PC, VPC or Interface] の順に選択します。

5. [Deploy Static EPG on PC, VPC or Interface] ダイアログボックスで、次の操作を実行します。

1. [Path Type] を選択します。

2. [Path] を選択します。

3. カプセル化 VLAN を入力します。

4. [Submit] をクリックします。`

特定の EPG のファブリックに接続されたエンドポイントを表示する手順：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Application Profiles] > [Application_Profile] > [Application EPGs] > [Application_EPG] を選択します。

4. [Work] ペインで、[Operational] を選択します。

- エンドポイントの確認

エンドポイントの確認

REST :: /api/node/class/fvCEp.xml

CLI  :: moquery -c fvCEp

プライベート ネットワーク

プライベート ネットワークは、仮想ルーティングおよびフォワーディング（VRF）、プライベート レイヤ 3 ネットワーク、またはコンテキストとも呼ばれます。プライベート ネットワークは、一意のレイヤ 3 フォワーディングおよびアプリケーション ポリシー ドメインです。プライベート ネットワークはテナント オブジェクトの子です。プライベート ドメイン内のすべてのエンドポイントは一意の IP アドレスを持つ必要があります。ポリシーで許可されている場合は、これらのデバイス間で直接パケットを転送できるからです。1 つ以上のブリッジ ドメインがプライベート ネットワークに関連付けられます。

テナントへのコンポーネントの追加 - 3. テナント論理モデルの一部としてのプライベート ネットワーク

テナント間でプライベート ネットワークを共有する最も一般的な方法は、共通テナントを介して共有することです。共通テナントの詳細については、この章の概要の項を参照してください。共通テナントで作成されたプライベート ネットワークは、ファブリック内でグローバルに共有されます。ただし、複数のテナントで使用されることを目的とした、共通テナントで作成されないプライベート ネットワークは、共有されることを明示的に設定する必要があります。

個々のプライベート ネットワーク インスタンス間へのトラフィックのルーティングに関する要件がある場合は、サブネットの設定について特に考慮する必要があります。この詳細については、ブリッジ ドメインとエンドポイント グループの設定に関する項で説明されています。

- プライベート ネットワークの設定パラメータ

- 新しいプライベート ネットワークの作成

- GUI を使用したプライベート ネットワークの変更

- VRF ポリシー コントロール適用方向の変更

- GUI を使用したプライベート ネットワークの削除

- プライベート ネットワークの確認

プライベート ネットワークの設定パラメータ

次のリストに、プライベート ネットワークの設定パラメータを示します。

- Name：プライベート ネットワークの名前。

- Policy Control Enforcement Preference：優先ポリシー制御。値は [enforced] または [unenforced] です。[enforced] を選択した場合は、トラフィックを許可するエンドポイント グループ間のコントラクトが必要です。[unenforced] を選択した場合は、プライベート ネットワーク内のすべてのトラフィックが許可されます。デフォルトは [enforced] です。

- Policy Control Enforcement Direction：ポリシーが適用される関係性（つまり方向）での優先ポリシー制御。デフォルトでは入力になっています。

- End Point Retention Policy：（任意）エンドポイント保持ポリシーの名前。

- Monitoring Policy：（任意）テナント セマンティック スコープのモニタリング ポリシーの名前。

- DNS Label：ネットワーク ドメインのネーム ラベル。（任意）ラベルにより、互いに通信できるオブジェクトとできないオブジェクトを分類できます。

- BGP Timers：このオブジェクトに関連する BGP タイマー ポリシーの名前。

- OSPF Timers：このオブジェクトに関連する OSPF タイマー ポリシーの名前。

- OSPF Address Family Context：OSPF アドレス ファミリ コンテキストのポリシー名。

- EIGRP Address Family Context：EIGRP アドレス ファミリ コンテキストのポリシー名。

新しいプライベート ネットワークの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Networking]> [VRFs]の順に選択します。

4. 作業ウィンドウで、[Actions] > [Create VRF] の順に選択します。

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

1. プライベート ネットワークまたは VRF の名前を入力します。

2. （任意）ポリシー制御適用のプリファレンスを選択します。

3. （任意）ポリシー制御適用の方向を選択します。

4. （任意）エンドポイント保持ポリシーの名前を選択します。

5. （任意）必要に応じて適切なモニタリング ポリシーを選択します。

6. （任意）必要に応じて適切な DNS ラベルを選択します。

7. （任意）必要に応じて適切なルート タグ ポリシーを選択します。

8. （任意）ブリッジ ドメインを作成します。

9. （任意）BGP ポリシーを設定します。

10. （任意）EIGRP ポリシーを選択します。

6. [Finish] をクリックします。ブリッジ ドメインの作成や、BGP、OSPF、または EIGRP ポリシーの設定など、オプションの作成や、設定手順のいずれかを実行する場合は、[Next] をクリックします。

7. [Next] をクリックした場合は、画面の指示に従って関連する追加ポリシーを設定します。

GUI を使用したプライベート ネットワークの変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Networking] > [VRFs] > [Private_Network] を選択します。

4. [Work] ペインで、[Policy] を選択します。

1. （任意）ポリシー制御適用のプリファレンスを選択します。

2. （任意）ポリシー制御適用の方向を選択します。

3. （任意）BGP タイマー ポリシーを選択します。

4. （任意）追加/削除アイコンを使用して、アドレス ファミリごとの BGP コンテキストを変更します。

5. OSPF タイマー ポリシーを選択します。

6. （任意）追加/削除アイコンを使用して、アドレス ファミリごとの OSPF コンテキストを変更します。

7. （任意）エンドポイント保持ポリシーの名前を選択します。

8. （任意）必要に応じて適切なモニタリング ポリシーを選択します。

9. （任意）追加/削除アイコンを使用して、アドレス ファミリごとの EIGRP コンテキストを変更します。

10. （任意）必要に応じて適切な DNS ラベルを選択します。

11. （任意）必要に応じてルート タグ ポリシーを選択します。

5. [送信（Submit）] をクリックします。

VRF ポリシー コントロール適用方向の変更

（注）

ポリシー制御の適用方向の変更は、トラフィックに影響を与える操作です。この変更を行う最適なタイミングを慎重に検討してください。

VRFポリシー制御の適用方向を変更するには、コントローラと境界リーフスイッチで変更を行う必要があります。

- コントローラで必要な変更を行う

- ボーダー リーフ スイッチで必要な変更を行う

コントローラで必要な変更を行う

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. ナビゲーション ウィドウで、 [Tenant_Name] > [Networking] > [VRFs] > [Private_Network]の順に選択します。

4. [Work] ペインで、[Policy] を選択します。

1. [ポリシー制御適用向き指定（Policy Control Enforcement Direction）] ドロップダウン リストから、[入力（Ingress）] または [出力（Egress）] を選択します。

2. [送信（Submit）] をクリックします。

ボーダー リーフ スイッチで必要な変更を行う

vPCペア設定にボーダーリーフスイッチがある場合は、エンドポイントの同期の問題がないように、両方のボーダーリーフスイッチで次の手順を順番に実行します。

1. メニュー バーで、 [Fabric] > [Inventory] を選択します。

2. ナビゲーション ウィンドウで、レイヤ 3 外部ネットワーク（L3Outs）が展開されている境界リーフ スイッチに移動します。

[Pod_Number] > [Leaf_Switch_Number] > [VRF Contexts]

3. この境界リーフ スイッチのVRFコンテキストを右クリックし、[エンドポイントのクリア（Clear End-Points）] を選択して、現在学習したエンドポイントをフラッシュします。

GUI を使用したプライベート ネットワークの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Networking] > [VRFs] > [Private_Network] を選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

プライベート ネットワークの確認

REST :: /api/node/class/fvCtx.xml

CLI :: moquery -c fvCtx

ブリッジ ドメイン

ブリッジ ドメインは、ファブリック内のレイヤ 2 転送ドメインの論理表現です。ブリッジ ドメインは、テナント オブジェクトの子であり、プライベート ネットワークにリンクしている必要があります。

フラッディングが有効な場合、ブリッジ ドメインは、一意のレイヤ 2 MAC アドレス空間とレイヤ 2 フラッド ドメインを定義します。プライベート ネットワークは一意の IP アドレス空間を定義しますが、そのアドレス空間は複数のサブネットから構成できます。これらのサブネットは、プライベート ネットワークに含まれる 1 つ以上のブリッジ ドメインに拡散されます。

ブリッジ ドメインは、関連付けられているエンドポイント グループが設定されているすべてのスイッチにまたがります。ブリッジ ドメインには複数のサブネットを含めることができます。ただし、サブネットは 1 つのブリッジ ドメイン内に含まれます。

テナントへのコンポーネントの追加 - 4. テナント アプリケーション プロファイルの一部としてのブリッジ ドメイン

次の図のテナントの例は、ブリッジ ドメインがプライベート ネットワーク内に含まれる仕組みと、エンドポイント グループなどの要素にリンクされる仕組みを示しています。

テナント アプリケーション プロファイルの一部としてのエンドポイント グループ

ブリッジ ドメインは VLAN のように動作できますが、VLAN ではありません。ブリッジ ドメインを分散スイッチと見なす必要があります。この分散スイッチは、リーフ上で、ローカル シグニフィカンスを持つ VLAN としてローカルに変換できます。

実用的観点から、エンドポイント グループに属する接続エンドポイントがある場合、各ブリッジ ドメインは特定のリーフ内に存在します。各ブリッジ ドメインはリーフ スイッチで VLAN ID を受信します。

使用される VLAN ID は、プラットフォーム非依存型 VLAN または PI VLAN と呼ばれます。この VLAN の概念は従来のネットワーキングとは異なっており、VLAN はトラフィックの転送には使用されず、ID として使用されます。各 PI VLAN は、ファブリック内で転送に使用される VXLAN ID にリンクされます。

次の例では、テナント Acme の下のブリッジ ドメイン Acme-Applications-BD に、Leaf-1 で PI VLAN ID 42 が割り当てられています。

エンドポイント グループには、各リーフのローカル シグニフィカンスである PI VLAN ID も割り当てられます。この VLAN ID はブリッジ ドメインとは異なります。したがって、 Cisco Application Centric Infrastructure (ACI) では、1 つのブリッジ ドメイン内のエンドポイントに対して複数の VLAN が使用されます。詳細については、この章のエンドポイントに関する項を参照してください。

サブネットがブリッジ ドメインで定義された場合、リーフ スイッチはそのサブネットを使用するエンドポイント グループのデフォルト ゲートウェイになります。エンドポイント グループが複数のリーフにエンドポイントを持っている場合、各リーフはデフォルト ゲートウェイを設定します。この方法では、常に、ファブリック内の最初に到達するスイッチがエンドポイントのデフォルト ゲートウェイとなり、拡散型ゲートウェイとも呼ばれます。つまり、SVI はブリッジ ドメインがリンクされているプライベート ネットワークを表す VRF で設定されます。ブリッジ ドメインに複数のサブネットがある場合、ブリッジ ドメインごとに 1 つの SVI がありますが、セカンダリ IP アドレスが使用されます。

- ブリッジ ドメインの設定パラメータ

- GUI を使用した新しいブリッジ ドメインの作成

- NX-OS スタイルの CLI を使用した新しいブリッジ ドメインの作成

- GUI を使用したブリッジ ドメインの変更

- NX-OS スタイルの CLI を使用したブリッジ ドメインの変更

- GUI を使用したブリッジ ドメインの削除

- NX-OS スタイルの CLI を使用したブリッジ ドメインの削除

- オブジェクト モデル CLI を使用したブリッジ ドメインの確認

ブリッジ ドメインの設定パラメータ

- Name：ブリッジ ドメインの名前。

- Network：関連するレイヤ 3 コンテキスト。

- Forwarding：[Optimize] または [Custom] を選択。

- L2 Unknown Unicast：不明なレイヤ 2 宛先の転送方式。デフォルトのメソッドは、[Proxy] です。これは、リーフによりグローバル データベースを使用して検索用のスパインに転送されることを意味します。宛先が検出されない場合はドロップされます。2 番目の方法は [Flood] で、特定のブリッジ ドメインに対しスパインに基づくマルチキャスト ツリーが使用されます。

- L3 Unknown Multicast Flooding：不明なマルチキャスト宛先へのノード転送パラメータ。[Flood] または [Optimized Flood] を選択できます。

- Multidestination Flood：このパラメータは、レイヤ 2 マルチデスティネーション フラッドのフラッディング動作（マルチキャスト、ブロードキャスト、リンク ローカル固有のトラフィックなど）を設定します。ブリッジ ドメイン内でのフラッディング（デフォルト）、すべてのトラフィックのドロップ、カプセル化または VLAN でのフラッディングを選択できます。

- ARP Flooding：ARP フラッディングを有効にするかどうかを指定するプロパティ。フラッディングがディセーブルである場合、ユニキャスト ルーティングはターゲット IP アドレスで実行されます。ARP フラッディングはデフォルトでディセーブルに設定されています。

- Unicast Routing：事前定義済みの転送基準に基づく転送方式です（IP または MAC アドレス）。ユニキャスト ルーティングはデフォルトでイネーブルに設定されています。ユニキャスト ルーティングは、宛先 IP アドレスを使用して、ハードウェア内に特定の /32 ルートを作成することにより、トラフィックを転送します。

- Config BD MAC Address：ブリッジ ドメインまたはスイッチ仮想インターフェイス（SVI）の MAC アドレス。デフォルトで、各ブリッジ ドメインはファブリック全体のデフォルトの MAC アドレスを使用します。

- IGMP Snoop Policy：IGMP スヌーピング ポリシーの名前。対象ホストからの IGMP メンバーシップ レポート メッセージを確認（スヌーピング）して、マルチキャスト トラフィックの範囲を当該ホストが接続されている各 VLAN インターフェイスの一部だけに限定します。

- Associated L3 Outs：このオブジェクトに関連するレイヤ 3 外部インターフェイスの名前。

- L3 Out for Route Profile：外部ネットワークへの接続を制御するレイヤ 3 外部インターフェイスの ID。

- Route Profile：関連するルート プロファイルの名前。

- Monitoring Policy：（任意）テナント セマンティック スコープのモニタリング ポリシーの名前。

- Subnets：サブネットのネットワーク可視性。 サブネットは、特定のサブネット アドレスを共有するネットワークの一部です。スコープは次のようになります。

- Shared Between VRFs：ファブリック内の他のテナントにルート リークするには、エンドポイント グループにサブネットを定義し、[Shared] オプションを設定します。

- Advertise Externally：レイヤ 3 アウトバウンドと共有するには、ブリッジ ドメインにサブネットを定義し、[Public] オプションを設定します。

- Private to VRF：そのテナントでのみ使用される（リークされない）ようにするには、ブリッジ ドメインにサブネットを定義し、[Private] オプションを設定します。デフォルトは [Private] です。

- Subnet Control：制御は、IGMP スヌーピングなど、サブネットに適用される特定のプロトコルによって行われます。制御は次のとおりです。

- Querier IP：サブネットで IGMP スヌーピングを有効にします。

- DHCP Labels：ネットワーク ドメインのネーム ラベル。

GUI を使用した新しいブリッジ ドメインの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [ネットワーキング（Networking）] > [ブリッジ ドメイン（Bridge Domains）] を選択します。

4. [Work] ペインで、[Actions] > [Create Bridge Domain] の順に選択します。

5. [Create Bridge Domain] ダイアログボックスで、次の操作を実行します。

1. [Bridge Domain Name] を入力します。

2. [Network] を選択します。

3. （任意）[Forwarding Semantics] を選択します。

4. （任意）[IGMP Snoop Policy] を選択します。

5. （任意）[Associated L3 Outs] を選択します。

6. （任意）[L3 Out for Route Profile] を選択します。

7. （任意）[Route Profile] を選択します。

8. （任意）必要に応じて [Monitoring Policy] を選択します。

9. （任意）[Subnets] を選択します。

10. （任意）必要に応じて [DNS Label] を選択します。

6. [送信（Submit）] をクリックします。

NX-OS スタイルの CLI を使用した新しいブリッジ ドメインの作成

NX OS スタイルの CLI を使用して、ブリッジ ドメインを作成できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure

ステップ 3

テナントの設定モードを入力します。

apic1(config)# tenant tenant1

ステップ 4

ブリッジ ドメインの設定モードを入力します。

apic1(config-tenant)# bridge-domain bd1

ステップ 5

VRF の設定モードを入力します。

apic1(config-bd)# vrf vrf1

ステップ 6

コマンドのリストについては、? を入力してください。

GUI を使用したブリッジ ドメインの変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィドウで、 [Tenant_Name] > [Networking] > [Bridge Domains] > [Bridge_Domain_Name] を選択します。

4. [Work] ペインで、[Policy] タブを選択し、次の操作を実行します。

1. [Network] を選択します。

2. （任意）[Forwarding Semantics] を選択します。

3. （任意）[IGMP Snoop Policy] を選択します。

4. （任意）[Associated L3 Outs] を選択します。

5. （任意）[L3 Out for Route Profile] を選択します。

6. （任意）[Route Profile] を選択します。

7. （任意）必要に応じて [Monitoring Policy] を選択します。

8. （任意）[Subnets] を選択します。

9. （任意）必要に応じて [DNS Label] を選択します。

5. [完了（Finish）] をクリックします。

NX-OS スタイルの CLI を使用したブリッジ ドメインの変更

NX OS スタイルの CLI を使用して、ブリッジ ドメインを変更できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure

ステップ 3

テナントの設定モードを入力します。

apic1(config)# tenant tenant1

ステップ 4

ブリッジ ドメインの設定モードを入力します。

apic1(config-tenant)# bridge-domain bd1

ステップ 5

コマンドのリストについては、? を入力してください。

GUI を使用したブリッジ ドメインの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Bridge Domains] > [Bridge Domain_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

NX-OS スタイルの CLI を使用したブリッジ ドメインの削除

NX OS スタイルの CLI を使用して、ブリッジ ドメインを削除できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure

ステップ 3

テナントの設定モードを入力します。

apic1(config)# tenant tenant1

ステップ 4

ブリッジ ドメインを削除します。

apic1(config-tenant)# no bridge-domain bd1

オブジェクト モデル CLI を使用したブリッジ ドメインの確認

オブジェクト モデル CLI を使用して、ブリッジ ドメインを確認できます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

オブジェクト モデル CLI に切り替えます。

apic1# bash
admin@apic1:~>

ステップ 3

実体ブリッジ ドメインを確認します。

admin@apic1:~> moquery -c l2BD

ステップ 4

解決されたブリッジ ドメインを確認します。

admin@apic1:~> moquery -c fvBDDef

ステップ 5

ローカル ブリッジ ドメインを確認します。

admin@apic1:~> moquery -c fvBD

すべてのテナント用の共通プライベート ネットワーク

この使用例は、複数のテナントを作成して、そのすべてをファブリックの 1 つのプライベート ネットワーク内に配置することを ACI 管理者が望んでいる環境で一般的です。

この方法には、次の利点と欠点があります。

利点：

- すべての内部および外部ファブリック接続に対して 1 つのプライベート ネットワークを使用できる

- 異なる VRF の EPG 間でルート リーキングが不要

- 1 つのレイヤ 3 外部接続をすべてのテナントで使用できる

欠点：

- ルーティングの変更がすべてのテナントに影響する

含有と関係の観点から、このトポロジは次のように表されます。

すべてのテナント用の共通プライベート ネットワーク

共通のテナント プライベート ネットワークを設定する手順：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで [common] を選択します。

3. [Navigation] ペインで、[common] > [Networking] > [Private Networks] > [default] の順に選択します。

4. [Work] ペインで、[policy] を選択します。

1. （任意）[Policy Enforcement] を選択します。

2. （任意）[BGP Policy Name] を選択します。

3. （任意）[OSPF Policy Name] を選択します。

4. （任意）[End Point Retention Policy Name] を選択します。

5. （任意）必要に応じて適切な [Monitoring Policy] を選択します。

6. （任意）必要に応じて適切な [DNS Label] を選択します。

5. [Finish] をクリックします。

テナントが作成されました。ネットワーク管理者は、最初にブリッジ ドメインを作成して、共通のプライベート ネットワークをテナントに関連付ける必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Bridge Domains] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Bridge Domain] の順に選択します。

5. [Create Bridge Domain] ダイアログボックスで、次の操作を実行します。

1. [Bridge Domain Name] を入力します。

2. ネットワークを選択します。

3. [Subnets] フィールドで、[+] をクリックします。

4. [Gateway IP] フィールドに、サブネットの IP アドレスを入力します。

5. [Scope] フィールドで、[Private]、[Public]、または [Shared] を選択します。注：デフォルトでは、[Private] オプションが選択されます。何を選択するかの詳細については、「外部レイヤ 3」の項を参照してください。

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

7. [完了（Finish）] をクリックします。

この使用例の設定は、次の CLI 設定を通じて適用できます。

CLI：テナント Cisco

# tenant
cd '/aci/tenants'
mocreate 'Cisco'
moconfig commit
# bridge-domain
cd '/aci/tenants/Cisco/networking/bridge-domains'
mocreate 'Cisco'
cd 'Cisco'
moset network 'default'
moconfig commit
# subnet
cd '/aci/tenants/Cisco/networking/bridge-domains/Cisco/subnets'
mocreate '172.16.0.1/24'
moconfig commit
# application-profile
cd '/aci/tenants/Cisco/application-profiles'
mocreate 'App1'
moconfig commit
# application-epg
cd '/aci/tenants/Cisco/application-profiles/App1/application-epgs'
mocreate 'EPG1'
cd 'EPG1'
moset bridge-domain 'Cisco'
moconfig commit
# criterion
cd '/aci/tenants/Cisco/application-profiles/App1/application-epgs/EPG1/vm-attributescriteria'
mocreate 'default'
moconfig commit

この設定は、APIC REST API にポストされる次の XML を使用して適用することもできます。

XML：テナント Cisco

<fvTenant name="Cisco">
<fvBD arpFlood="no" multiDstPktAct="bd-flood" name="Cisco" unicastRoute="yes"
unkMacUcastAct="proxy" unkMcastAct="flood">
<fvRsCtx tnFvCtxName="default"/>
<fvSubnet ctrl="nd" descr="" ip="172.16.0.1/24" preferred="no"
scope="private"/>
</fvBD>
<fvAp name="App1">
<fvAEPg matchT="AtleastOne" name="EPG1">
<fvRsBd tnFvBDName="Cisco"/>
</fvAEPg>
</fvAp>
<fvRsTenantMonPol tnMonEPGPolName=""/>
</fvTenant>

多くのマルチテナント環境では、各テナントが独自のアドレス空間を管理および所有できるようにして、他のテナントとの重複が生じないようにすると良いでしょう。この特定の使用例では、プライベート ネットワークと各テナントとを関連付ける方法を説明します。テナントごとのプライベート ネットワーク

利点：

- テナント間を最大限に分離できる

- 複数のテナント内にある IP アドレスが重複するホスト群に対処できる

欠点：

- 専用 VRF で異なるテナント間での EPG 通信を実現する必要がある場合は複雑性が拡大する

この特定の設定のオブジェクト間の関係は次のように表すことができます。

テナントあたりのプライベート ネットワーク

テナントを作成する方法：

1. メニュー バーで [Tenants] > [Add Tenant] の順に選択します。

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

1. テナントの名前を入力します。

2. [Next] をクリックします。

3. [Finish] をクリックします。

テナントが作成されました。これで、テナント管理者はプライベート ネットワークを作成できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Private Networks] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Private Network] の順に選択します。

5. [Create Private Network] ダイアログボックスで、次の操作を実行します。

1. プライベート ネットワークの名前を入力します。

2. [Next] をクリックします。

3. 関連付けられているブリッジ ドメインの名前を入力します。

4. [Subnets] フィールドで、[+] をクリックします。

5. [Gateway IP] フィールドに、サブネットの IP アドレスを入力します。

6. [Scope] フィールドで、[Private]、[Public]、または [Shared] を選択します。注：デフォルトでは、[Private] オプションが選択されます。何を選択するかの詳細については、「外部レイヤ 3」の項を参照してください。

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

7. [完了（Finish）] をクリックします。

この使用例の設定は、次の CLI 設定を通じて適用できます。

CLI：テナント Cisco

# tenant
cd '/aci/tenants'
mocreate 'Cisco'
moconfig commit
# bridge-domain
cd '/aci/tenants/Cisco/networking/bridge-domains'
mocreate 'Cisco'
cd 'Cisco'
moset network 'Cisco'
moconfig commit
# subnet
cd '/aci/tenants/Cisco/networking/bridge-domains/Cisco/subnets'
mocreate '172.16.0.1/24'
moconfig commit
# private-network
cd '/aci/tenants/Cisco/networking/private-networks'
mocreate 'Cisco'
moconfig commit
# application-profile
cd '/aci/tenants/Cisco/application-profiles'
mocreate 'App1'
moconfig commit
# application-epg
cd '/aci/tenants/Cisco/application-profiles/App1/application-epgs'
mocreate 'EPG1'
cd 'EPG1'
moset bridge-domain 'Cisco'
moconfig commit

この設定は、APIC REST API にポストされる次の XML を使用して適用することもできます。

XML：テナント Cisco

<fvTenant name="Cisco">
<fvBD arpFlood="no" multiDstPktAct="bd-flood" name="Cisco" unicastRoute="yes"
unkMacUcastAct="proxy" unkMcastAct="flood">
<fvRsCtx tnFvCtxName="Cisco"/>
<fvSubnet ctrl="nd" ip="172.16.0.1/24" name="" preferred="no" scope="private"/>
</fvBD>
<fvCtx knwMcastAct="permit" name="Cisco" pcEnfPref="enforced"/>
<fvAp name="App1" prio="unspecified">
<fvAEPg name="EPG1">
<fvRsBd tnFvBDName="Cisco"/>
</fvAEPg>
</fvAp>
</fvTenant>

テナント内通信を行う複数のプライベート ネットワーク

サポートすることが望ましい別の使用例として、複数のプライベート ネットワークを持つ単一テナントを所有するというオプションがあります。これは、管理レベルではなく、ネットワーク レベルでマルチテナント機能を提供する必要があるためです。また、合併やその他のビジネス上の変更により、単一テナント内で重複しているサブネットをサポートする場合にも発生します。

この方法には、次の利点と欠点があります。

利点：

- 単一テナント内で重複するサブネットを所有できる

欠点：

- 重複するサブネットに存在する EPG は互いに適用し合うポリシーを所有できない

この特定の設定のオブジェクト間の関係は次のように表すことができます。

テナント内通信を行う複数のプライベート ネットワーク

テナントを作成する方法：

1. メニュー バーで [Tenants] > [Add Tenant] の順に選択します。

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

1. テナントの名前を入力します。

3. [Next] をクリックします。

4. [Finish] をクリックします。

テナントが作成されました。これで、テナント管理者はプライベート ネットワークを作成できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Private Networks] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Private Network] の順に選択します。

5. [Create Private Network] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プライベート ネットワークの名前を入力します。

2. [Next] をクリックします。

3. [Name] フィールドに、ブリッジ ドメインの名前を入力します。

4. [Subnets] フィールドで、[+] をクリックします。

5. [Gateway IP] フィールドに、サブネットの IP アドレスを入力します。

6. [Scope] フィールドで [Shared] を選択します。注：共有サブネットのタイプによって、ACI で、何が 2 つのプライベート ネットワーク（VRF）間のルート リークであるかが決まります。

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

7. [Finish] をクリックします。

8. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Private Networks] の順に選択します。

9. [Work] ペインで、[Actions] > [Create Private Network] の順に選択します。

10. [Create Private Network] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、2 つ目のプライベート ネットワークの名前を入力します。

2. [Next] をクリックします。

3. [Name] フィールドに、2 つ目のブリッジ ドメインの名前を入力します。

4. [Subnets] フィールドで、[+] をクリックします。

5. [Gateway IP] フィールドに、サブネットの IP アドレスを入力します。

6. [Scope] フィールドで [Shared] を選択します。

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

12. [Finish] をクリックします。

これで 2 つのプライベート ネットワークとブリッジ ドメインが作成されました。アプリケーション プロファイルに移動できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Application Profiles] の順に選択します。

4. [Action] タブで、[Create Application Profile] を選択します。

5. [Create Application Profile] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、アプリケーション プロファイルの名前を入力します。

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

2 つのエンドポイント グループを作成する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Application Profiles] > [Application Profile_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application EPG] の順に選択します。

5. [Create Application EPG] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、エンド ポイント グループの名前を入力します。

2. [Bridge Domain] フィールドで適切なブリッジ ドメインを選択します。

6. [Finish] をクリックします。

2 つ目の EPG にこれらの手順を繰り返します。

ここでテナント管理者は、コントラクトを作成し、2 つの EPG 間でフィルタ処理する必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Security Policies] > [Filters] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Filters] の順に選択します。

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

1. [Name] フィールドにフィルタの名前を入力します。

2. [+] をクリックします。

3. [Name] 列に ICMP と入力します。

4. [Ethertype] フィールドで [IP] を選択します。

5. [IP Protocol] 列で [ICMP] を選択します。

6. [Update] をクリックします。

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

テナント管理者は、2 つの EPG 間のトラフィックで許可するフィルタ情報を把握している必要があります。フィルタでは、アプリケーションに必要なさまざまなネットワーク プロトコルを必要な数だけを定義します。ここで、2 つの EPG が使用または提供するコントラクトを定義する必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Security Policies] > [Contracts] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Contract] の順に選択します。

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

1. [Name] フィールドにフィルタの名前を入力します。

2. [Scope] フィールドで [Global] を選択します。

3. [Subjects] フィールドで、[+] をクリックします。

4. [Name] フィールドにサブジェクトの名前を入力します。

5. [Filter Chain] フィールドで、[+] をクリックします。

6. 作成したフィルタを選択します。

6. [Update] をクリックします。

7. OK をクリックします。

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

EPG 間にコントラクトを設定します。使用されたコントラクトまたは提供されたコントラクトのいずれかとして、コントラクトが EPG に割り当てられます。作成した各 EPG は、両方の EPG 間の関係を確立するためにそのコントラクトを使用、または提供します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application Profile Name] > [Application EPGs] > [EPG_Name] > [Contracts] の順に選択します。

4. [Work] ペインで、[Actions] > [Add Provided Contract] の順に選択します。

5. [Add Provided Contract] ダイアログボックスで、次の操作を実行します。

1. 作成したコントラクトを選択します。

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

6. 2 つ目の EPG の下にある [Navigation] ペインで、[Contracts] を選択します。

7. [Action] タブで、[Add Consume Contract] を選択します。

1. 作成したコントラクトを選択します。

8. [Submit] をクリックします。`

この使用例の設定は、次の CLI 設定を通じて適用できます。

CLI：テナント Cisco

# tenant
cd '/aci/tenants'
mocreate 'Cisco'
moconfig commit
# bridge-domain
cd '/aci/tenants/Cisco/networking/bridge-domains'
mocreate 'Cisco'
cd 'Cisco'
moset network 'Cisco'
moconfig commit
# bridge-domain
cd '/aci/tenants/Cisco/networking/bridge-domains'
mocreate 'Cisco1'
cd 'Cisco1'
moset network 'Cisco1'
moconfig commit
# private-network
cd '/aci/tenants/Cisco/networking/private-networks'
mocreate 'Cisco'
moconfig commit
# private-network
cd '/aci/tenants/Cisco/networking/private-networks'
mocreate 'Cisco1'
moconfig commit
# application-profile
cd '/aci/tenants/Cisco/application-profiles'
mocreate 'App1'
moconfig commit
# application-epg
cd '/aci/tenants/Cisco/application-profiles/App1/application-epgs'
mocreate 'EPG1'
cd 'EPG1'
moset bridge-domain 'Cisco'
moconfig commit
# fv-rscon
cd '/aci/tenants/Cisco/application-profiles/App1/applicationepgs/
EPG1/contracts/consumed-contracts'
mocreate 'ICMP'
moconfig commit
# fv-subnet
cd '/aci/tenants/Cisco/application-profiles/App1/application-epgs/EPG1/subnets'
mocreate '172.16.1.1/24'
cd '172.16.1.1:24'
moset scope 'private,shared'
moconfig commit
# application-epg
cd '/aci/tenants/Cisco/application-profiles/App1/application-epgs'
mocreate 'EPG2'
cd 'EPG2'
moset bridge-domain 'Cisco1'
moconfig commit
# fv-rsprov
cd '/aci/tenants/Cisco/application-profiles/App/applicationepgs/
EPG2/contracts/provided-contracts'
mocreate 'ICMP'
moconfig commit
# fv-subnet
cd '/aci/tenants/Cisco/application-profiles/CCO/application-epgs/EPG2/subnets'
mocreate '172.16.2.1/24'
cd '172.16.2.1:24'
moset scope 'private,shared'
moconfig commit

この設定は、APIC REST API にポストされる次の XML を使用して適用することもできます。

XML：テナント Cisco

<fvTenant dn="uni/tn-Cisco" name="Cisco">
<vzBrCP name="ICMP" scope="tenant">
<vzSubj consMatchT="AtleastOne" name="icmp" provMatchT="AtleastOne"
revFltPorts="yes">
<vzRsSubjFiltAtt tnVzFilterName="icmp"/>
</vzSubj>
</vzBrCP>
<fvCtx knwMcastAct="permit" name="CiscoCtx" pcEnfPref="enforced"/>
<fvCtx knwMcastAct="permit" name="CiscoCtx2" pcEnfPref="enforced"/>
<fvBD arpFlood="yes" mac="00:22:BD:F8:19:FF" name="CiscoBD2" unicastRoute="yes"
unkMacUcastAct="flood" unkMcastAct="flood">
<fvRsCtx tnFvCtxName="CiscoCtx2"/>
</fvBD>
<fvBD arpFlood="yes" mac="00:22:BD:F8:19:FF" name="CiscoBD" unicastRoute="yes"
unkMacUcastAct="flood" unkMcastAct="flood">
<fvRsCtx tnFvCtxName="CiscoCtx"/>
</fvBD>
<fvAp name="CCO">
<fvAEPg matchT="AtleastOne" name="Web">
<fvRsCons tnVzBrCPName="ICMP"/>
<fvRsPathAtt encap="vlan-1201" instrImedcy="immediate" mode="native"
tDn="topology/pod-1/paths-201/pathep-[eth1/16]"/>
<fvSubnet ip="172.16.2.1/24" scope="private,shared"/>
<fvRsDomAtt instrImedcy="lazy" resImedcy="lazy" tDn="uni/phys-
PhysDomainforCisco"/>
<fvRsBd tnFvBDName="CiscoBD2"/>
</fvAEPg>
<fvAEPg matchT="AtleastOne" name="App">
<fvRsPathAtt encap="vlan-1202" instrImedcy="immediate" mode="native"
tDn="topology/pod-1/paths-202/pathep-[eth1/2]"/>
<fvSubnet ip="172.16.1.1/24" scope="private,shared"/>
<fvRsDomAtt instrImedcy="lazy" resImedcy="lazy" tDn="uni/phys-
PhysDomainforCisco"/>
<fvRsBd tnFvBDName="CiscoBD"/>
<fvRsProv matchT="AtleastOne" tnVzBrCPName="ICMP"/>
</fvAEPg>
</fvAp>
</fvTenant>

テナント間通信を行う複数のプライベート ネットワーク

この使用例は一般的に、ACI の管理者が、テナント間通信の機能を持つ複数のテナントを作成し、サポートしたい場合に使用されます。

この方法には、次の利点と欠点があります。

利点

- 各テナント コンテナの個別管理が可能

- テナント間の最大分離を実現

欠点

- テナントのアドレス空間は一意である必要がある

オブジェクト間の関係とコントラクトの観点から、このトポロジは次のように表されます。

テナント間通信を行う複数のプライベート ネットワーク

テナントを作成する方法：

1. GUI を使用して、[Tenants] > [ADD TENANT] に移動します。

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

1. [Name] フィールドに最初のテナントの名前を入力します。

3. [Next] をクリックします。

4. [Finish] をクリックします。

テナントが作成されました。これで、テナント管理者はプライベート ネットワークを作成できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Private Networks] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Private Network] の順に選択します。

5. [Create Private Network] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プライベート ネットワークの名前を入力します。

2. [Next] をクリックします。

3. [Name] フィールドに、ブリッジ ドメインの名前を入力します。

4. [Subnets] フィールドで、[+] をクリックします。

5. [Gateway IP] フィールドに、サブネットの IP アドレスを入力します。

6. [Scope] フィールドで [Shared] を選択します。注：共有サブネットのタイプによって、ACI で、何が 2 つのプライベート ネットワーク（VRF）間のルート リークであるかが決まります。

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

7. [完了（Finish）] をクリックします。

アプリケーション プロファイルを作成する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Application Profiles] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application Profile] の順に選択します。

5. [Create Application Profile] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、アプリケーション プロファイルの名前を入力します。

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

エンドポイント グループを作成する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Application Profiles] > [Application Profile_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application EPG] の順に選択します。

5. [Create Application EPG] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、エンド ポイント グループの名前を入力します。

2. [Bridge Domain] フィールドで適切なブリッジ ドメインを選択します。

6. [Finish] をクリックします。

2 つ目のテナントやアプリケーション プロファイルを作成する方法：

1. GUI を使用して、[Tenants] > [ADD TENANT] に移動します。

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

1. [Name] フィールドに最初のテナントの名前を入力します。

3. [Next] をクリックします。

4. [Finish] をクリックします。

テナントが作成されました。これで、テナント管理者はプライベート ネットワークを作成できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Private Networks] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Private Network] の順に選択します。

5. [Create Private Network] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、プライベート ネットワークの名前を入力します。

2. [Next] をクリックします。

3. [Name] フィールドに、ブリッジ ドメインの名前を入力します。

4. [Subnets] フィールドで、[+] をクリックします。

5. [Gateway IP] フィールドに、サブネットの IP アドレスを入力します。

6. [Scope] フィールドで [Shared] を選択します。注：共有サブネットのタイプによって、ACI で、何が 2 つのプライベート ネットワーク（VRF）間のルート リークであるかが決まります。

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

7. [完了（Finish）] をクリックします。

アプリケーション プロファイルを作成する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Application Profiles] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application Profile] の順に選択します。

5. [Create Application Profile] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、アプリケーション プロファイルの名前を入力します。

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

エンドポイント グループを作成する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Application Profiles] > [Application Profile_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Application EPG] の順に選択します。

5. [Create Application EPG] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに、エンド ポイント グループの名前を入力します。

2. [Bridge Domain] フィールドで適切なブリッジ ドメインを選択します。

6. [Finish] をクリックします。

ここでテナント管理者は、コントラクトを作成し、2 つの EPG 間でフィルタ処理する必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Security Policies] > [Filters] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Filters] の順に選択します。

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

1. [Name] フィールドにフィルタの名前を入力します。

2. [+] をクリックします。

3. [Name] 列に ICMP と入力します。

4. [Ethertype] フィールドで [IP] を選択します。

5. [IP Protocol] 列で [ICMP] を選択します。

6. [Update] をクリックします。

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

テナント管理者には、2 つの EPG 間で許可するトラフィックのフィルタを把握している必要があります。フィルタでは、アプリケーションに必要なさまざまなネットワーク プロトコルを必要な数だけ定義します。ここで、2 つの EPG が使用または提供するコントラクトを定義する必要があります。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Security Policies] > [Contracts] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Contract] の順に選択します。

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

1. [Name] フィールドにフィルタの名前を入力します。

2. [Scope] フィールドで [Global] を選択します。

3. [Subjects] フィールドで、[+] をクリックします。

4. [Name] フィールドにサブジェクトの名前を入力します。

5. [Filter Chain] フィールドで、[+] をクリックします。

6. 作成したフィルタを選択します。

6. [Update] をクリックします。

7. OK をクリックします。

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

EPG 間にコントラクトを設定します。使用されたコントラクトまたは提供されたコントラクトのいずれかとして、コントラクトが EPG に割り当てられます。作成した各 EPG は、両方の EPG 間の関係を確立するためにそのコントラクトを使用、または提供します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application Profile Name] > [Application EPGs] > [EPG_Name] > [Contracts] の順に選択します。

4. [Work] ペインで、[Actions] > [Add Provided Contract] の順に選択します。

5. [Add Provided Contract] ダイアログボックスで、次の操作を実行します。

1. 作成したコントラクトを選択します。

2. [Submit] をクリックします。`

6. GUI を使用して、[Tenants] > [ALL TENANTS] に移動します。

7. 2 つ目に作成したテナントを選択します。

8. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application Profile Name] > [Application EPGs] > [EPG_Name] > [Contracts] の順に選択します。

9. [Work] ペインで、[Actions] > [Add Consume Contract] の順に選択します。

1. 作成したコントラクトを選択します。

10. [Submit] をクリックします。`

この使用例の設定は、次の CLI 設定を通じて適用できます。

CLI：テナント Cisco1

# tenant
cd '/aci/tenants'
mocreate 'Cisco1'
moconfig commit
# bridge-domain
cd '/aci/tenants/Cisco1/networking/bridge-domains'
mocreate 'Cisco1'
cd 'Cisco1'
moset network 'Cisco1'
moconfig commit
# private-network
cd '/aci/tenants/Cisco1/networking/private-networks'
mocreate 'Cisco1'
moconfig commit
# application-profile
cd '/aci/tenants/Cisco1/application-profiles'
mocreate 'App1'
moconfig commit
# application-epg
cd '/aci/tenants/Cisco1/application-profiles/App1/application-epgs'
mocreate 'EPG1'
cd 'EPG1'
moset bridge-domain 'Cisco1'
moconfig commit
# fv-rsprov
cd '/aci/tenants/Cisco/application-profiles/CCO/applicationepgs/
App/contracts/provided-contracts'
mocreate 'ICMP'
moconfig commit
# fv-subnet
cd '/aci/tenants/Cisco/application-profiles/CCO/application-epgs/App/subnets'
mocreate '172.16.1.1/24'
cd '172.16.1.1:24'
moset scope 'private,shared'
moconfig commit
# contract
cd '/aci/tenants/Cisco/security-policies/contracts'
mocreate 'ICMP'
cd 'ICMP'
moset scope 'global'
moconfig commit
# contract-subject
cd '/aci/tenants/Cisco/security-policies/contracts/ICMP/subjects'
mocreate 'icmp'
moconfig commit
# vz-rssubjfiltatt
cd '/aci/tenants/Cisco/security-policies/contracts/ICMP/subjects/icmp/common-filters'
mocreate 'icmp'
moconfig commit

CLI：テナント Cisco2

# tenant
cd '/aci/tenants'
mocreate 'Cisco'
moconfig commit
# bridge-domain
cd '/aci/tenants/Cisco/networking/bridge-domains'
mocreate 'Cisco'
cd 'Cisco'
moset network 'Cisco'
moconfig commit
# private-network
cd '/aci/tenants/Cisco/networking/private-networks'
mocreate 'Cisco'
moconfig commit
# application-profile
cd '/aci/tenants/Cisco/application-profiles'
mocreate 'App1'
moconfig commit
# application-epg
cd '/aci/tenants/Cisco2/application-profiles/App1/application-epgs'
mocreate 'EPG1'
cd 'EPG1'
moset bridge-domain 'Cisco'
moconfig commit
# fv-rsconsif
cd '/aci/tenants/Cisco1/application-profiles/CCO/applicationepgs/
Web/contracts/consumed-contract-interfaces'
mocreate 'CiscoInterTenantICMP'
moconfig commit
# fv-subnet
cd '/aci/tenants/Cisco1/application-profiles/CCO/application-epgs/Web/subnets'
mocreate '172.16.2.1/24'
cd '172.16.2.1:24'
moset scope 'shared-subnet'
moconfig commit
# imported-contract
cd '/aci/tenants/Cisco1/security-policies/imported-contracts'
mocreate 'CiscoInterTenantICMP'
cd 'CiscoInterTenantICMP'
moset contract 'tenants/Cisco/security-policies/contracts/ICMP'
moconfig commit

この設定は、APIC REST API にポストされる次の XML を使用して適用することもできます。
XML：テナント Cisco1

<fvTenant dn="uni/tn-Cisco1" name="Cisco1">

<vzBrCP name="ICMP" scope="global">
<vzSubj consMatchT="AtleastOne" name="icmp" provMatchT="AtleastOne"
revFltPorts="yes">
<vzRsSubjFiltAtt tnVzFilterName="icmp"/>
</vzSubj>
</vzBrCP>

<vzCPIf dn="uni/tn-Cisco1/cif-ICMP" name="ICMP">

<vzRsIf consMatchT="AtleastOne" name="icmp" provMatchT="AtleastOne"
revFltPorts="yes">
<vzRsSubjFiltAtt tDn="uni/tn-Cisco2/brc-default"/>
</vzRsIf>
</vzCPIf>
<fvCtx knwMcastAct="permit" name="CiscoCtx" pcEnfPref="enforced"/>

<fvBD arpFlood="yes" mac="00:22:BD:F8:19:FF" name="CiscoBD2" unicastRoute="yes"
unkMacUcastAct="flood" unkMcastAct="flood">
<fvRsCtx tnFvCtxName="CiscoCtx2"/>
</fvBD>
<fvBD arpFlood="yes" name="CiscoBD" unicastRoute="yes" unkMacUcastAct="flood"
unkMcastAct="flood">
<fvRsCtx tnFvCtxName="CiscoCtx"/>
</fvBD>
<fvAp name="CCO">
<fvAEPg matchT="AtleastOne" name="EPG1">
<fvRsPathAtt encap="vlan-1202" instrImedcy="immediate" mode="native"
tDn="topology/pod-1/paths-202/pathep-[eth1/2]"/>
<fvSubnet ip="172.16.1.1/24" scope="private,shared"/>

<fvRsDomAtt instrImedcy="lazy" resImedcy="lazy" tDn="uni/phys-
PhysDomainforCisco"/>

<fvRsBd tnFvBDName="CiscoBD"/>
<fvRsProv matchT="AtleastOne" tnVzBrCPName="ICMP"/>
</fvAEPg>
</fvAp>
</fvTenant>

XML：テナント Cisco2

<fvTenant dn="uni/tn-Cisco2" name="Cisco2">
<fvCtx knwMcastAct="permit" name="CiscoCtx" pcEnfPref="enforced"/>
<fvBD arpFlood="yes" mac="00:22:BD:F8:19:FF" name="CiscoBD2" unicastRoute="yes"
unkMacUcastAct="flood" unkMcastAct="flood">
<fvRsCtx tnFvCtxName="CiscoCtx"/>
</fvBD>
<fvBD arpFlood="yes" name="CiscoBD" unicastRoute="yes" unkMacUcastAct="flood"
unkMcastAct="flood">
<fvRsCtx tnFvCtxName="CiscoCtx"/>
</fvBD>
<fvAp name="CCO">
<fvAEPg matchT="AtleastOne" name="EPG2">
<fvRsPathAtt encap="vlan-1202" instrImedcy="immediate" mode="native"
tDn="topology/pod-1/paths-201/pathep-[eth1/2]"/>
<fvSubnet ip="172.16.1.1/24" scope="private,shared"/>

<fvRsDomAtt instrImedcy="lazy" resImedcy="lazy" tDn="uni/phys-
PhysDomainforCisco"/>

<fvRsBd tnFvBDName="CiscoBD"/>
<fvRsConsIf matchT="AtleastOne" tnVzBrCPIfName="ICMP"/>
</fvAEPg>
</fvAp>
</fvTenant>

一般的なパーベイシブ ゲートウェイを備えたデュアル ファブリック

この使用例は、Cisco Application Centric Infrastructure (ACI) 管理者が、デュアル ファブリックを管理してファブリック間でワークロードをシームレスに移動できるようにする必要がある環境での典型的な例です。

利点

- 異なるファブリックに接続されているハイパーバイザ ホスト間で仮想マシンを移行することができます。

- シームレスなワークロードの移行を可能にします。

欠点

- デュアル ファブリックの設定間で調整が必要です。

「レイヤ 2 アウト上のルーティング/一般的なパーベイシブ ゲートウェイ」機能の目的は、エンドポイントがファブリック間をシームレスに移動するようにすることです。

次の情報は、一般的なパーベイシブ ゲートウェイを備えたデュアル ファブリックに適用されます。

- デュアル ファブリックが使用されていることが前提となります。

- この場合の「ルーティング」は、異なるブリッジ ドメイン（サブネット）のエンドポイント間のトラフィックを意味します。

- ブリッジ ドメインは、ファブリック間でミラーリングされます（ただし例外あり）。

- よく言われる「拡張されたブリッジ ドメイン」とは、実際にはファブリック間でミラーリングされたブリッジ ドメインを意味します。あくまでも 2 つの別々のブリッジ ドメインであり、独立した各ファブリックに属します。

- ゲートウェイとしてブリッジ ドメイン IP アドレスを使用しているレイヤ 2 ネットワークには、エンドポイントは存在しません。

- ユーザは、ブリッジ ドメインに関するファブリックをそれぞれ手動で設定するか、またはなんらかのオーケストレーション ツールを使用して、各ファブリックに同期設定を配布できます。

- これに役立つアプリケーションは、ACI ツール キットに含まれています。

VM16 と VM17 間のトラフィックを使用して、この機能が必要な理由について説明します。

上の図で、VM17 が VM16 にパケットを送信する際、そのデフォルト ゲートウェイに送信しているのが確認できます。その後、パケットは BD17 から BD16 に「ルーティング」されます。BD16 はその後、パケットをレイヤ 2 パケットとして、BD16 SMAC（送信元 MAC）から VM16 に転送します。VM16 が応答したら、逆の順序で同様の動作が行われます。結果として、ここでは Nexus 5K として表示されるレイヤ 2 ネットワークは、別のポートから BD16/BD17 SMAC を学習し続けることになります。

ファブリック間で同じブリッジ ドメイン IP アドレスおよび MAC アドレスを保持する必要があります。これにより、VM がファブリック間を移行する際、そのデフォルト ゲートウェイ用の新しい MAC について ARP を発行する必要がなくなります。確認できるように、両方のファブリックで同じ SMAC を使用する場合、問題を引き起こす可能性があります。

解決策として、ブリッジ ドメインに追加の設定を導入します。新しいリリース（1.2）では、ブリッジ ドメインのサブネット IP アドレスを「仮想」として設定できるようになりました。これは、VM のデフォルト ゲートウェイとして機能するアドレスです。また、VMAC（仮想 MAC）も設定できます。これは、VM がそのデフォルト ゲートウェイとして ARP を発行したときに解決される MAC です。これらは、ブリッジ ドメインのファブリック間で一致している必要があります。

また、この場合、ブリッジ ドメインの CMAC（設定済み MAC）、および仮想 IP として同じサブネット内の 2 番目の IP アドレスを設定する必要があります。これらは、ブリッジ ドメインのファブリック間で固有である必要があります。

ルーテッド パケットには CMAC を SMAC として使用し、ARP グリーニングおよびエンドポイント トラッキングには 2 番目の IP を使用します。これについては後で説明します。

上の図では、BD16 および BD17 が上のファブリックと下のファブリックで複製されていることを確認できます。ブリッジ ドメイン設定に PIP と CMAC が追加されているのが確認できますが、これらはファブリック間で異なります。一方、VIP と VMAC はファブリック間で同じです。

パケット フローを見ると、VM17 は VM16 にパケットを送信します。下のファブリックの BD17 は、下のファブリックの BD16 にパケットをルーティングします。下のファブリックの BD16 は、VM16 にフレームを転送する際、SMAC として設定済みの CMAC を使用します。N5K は、下のファブリックから MAC 0022.1616.0002 を学習します。上のファブリックの VM16 が応答すると、同じことが上のファブリックで発生します。上のファブリックの BD17 は、レイヤ 2 アウトを終了する際、パケットの SMAC として設定済み CMAC を使用します。ここで、N5K は、上のファブリックから MAC 0022.1717.0001 を学習します。ブリッジ ドメイン間でルーティングされたパケットが通過する際に、Nexus 5K はもはや MAC フラップを参照しません。

ここで注目するべきことは、VM17 が上のファブリックに移動し、VM16 が上のファブリック上に残っていても、ブリッジ ドメインは、ルーテッド パケットをエンドポイントに転送する際に、設定済み CMAC を SMAC として使用し続けることです。

LINUX ホストとして VM17 を使用する場合は、TCPDUMP を使用して、VM16 へのパケットの MAC アドレスが VMAC に移り、そのリターン トラフィックが CMAC により受信されるのを確認できます。

[root@localhost ~]# ping 16.1.1.2
PING 16.1.1.2 (16.1.1.2) 56(84) bytes of data.
64 bytes from 16.1.1.2: icmp_seq=1 ttl=64 time=0.332 ms
64 bytes from 16.1.1.2: icmp_seq=2 ttl=64 time=0.376 ms
64 bytes from 16.1.1.2: icmp_seq=3 ttl=64 time=0.383 ms

--- 16.1.1.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.332/0.363/0.383/0.031 ms
[root@localhost ~]#

[root@localhost ~]# tcpdump -e -i eth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
04:06:59.130801 00:50:56:bb:a1:03 > 00:22:bd:f8:19:ff, ethertype IPv4
(0x0800), length 98: 17.1.1.2 > 16.1.1.2: ICMP echo request, id 9583,
seq 8796, length 64
04:06:59.131095 00:22:17:17:00:01 > 00:50:56:bb:a1:03, ethertype IPv4
(0x0800), length 98: 16.1.1.2 > 17.1.1.2: ICMP echo reply, id 9583,
seq 8796, length 64
04:07:00.131368 00:50:56:bb:a1:03 > 00:22:bd:f8:19:ff, ethertype IPv4
(0x0800), length 98: 17.1.1.2 > 16.1.1.2: ICMP echo request, id 9583,
seq 8797, length 64
04:07:00.131669 00:22:17:17:00:01 > 00:50:56:bb:a1:03, ethertype IPv4
(0x0800), length 98: 16.1.1.2 > 17.1.1.2: ICMP echo reply, id 9583,
seq 8797, length 64
04:07:01.131915 00:50:56:bb:a1:03 > 00:22:bd:f8:19:ff, ethertype IPv4
(0x0800), length 98: 17.1.1.2 > 16.1.1.2: ICMP echo request, id 9583,
seq 8798, length 64
04:07:01.132237 00:22:17:17:00:01 > 00:50:56:bb:a1:03, ethertype IPv4
(0x0800), length 98: 16.1.1.2 > 17.1.1.2: ICMP echo reply, id 9583,
seq 8798, length 64

6 packets captured
6 packets received by filter
0 packets dropped by kernel
[root@localhost ~]#

–e スイッチで tcpdump コマンドを使用する場合は、17.1.1.2 から 16.1.1.2 への PING が PING 要求で VMAC を SMAC として使用するのを確認でき、PING 応答は、エンドポイントが置かれた BD で設定されている CMAC から確認できます。

最初のハイライト表示された一連の文字は、BD17 の設定済み VMAC に送信される ICMP エコー要求（PING）を表します。2 つ目のハイライト表示された一連の文字は、BD17 の設定済み CMAC（VMAC ではなく）により受信された ICMP エコー応答を表します。

各ファブリックは、30 秒ごと（デフォルト）に、VIP および VMAC から送信された GARP を送信します。これらの GARP は低レートであるため、レイヤ 2 ネットワークの問題が発生することはありません。Nexus 5000 の debug ip arp packet コマンドを使用して、周波数を確認することができます。

2015 Oct 28 12:05:31.711090arp: (context 1) Receiving packet from Vlan2330,
logical interface Vlan2330 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:05:31.711940 arp: Src 0022.bdf8.19ff/17.1.1.1 Dst
ffff.ffff.ffff/17.1.1.1
2015 Oct 28 12:05:31.713557 arp: (context 1) Receiving packet from Vlan2331,
logical interface Vlan2331 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:05:31.714382 arp: Src 0022.bdf8.19ff/16.1.1.1 Dst
ffff.ffff.ffff/16.1.1.1
2015 Oct 28 12:06:01.717761 arp: (context 1) Receiving packet from Vlan2330,
logical interface Vlan2330 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:06:01.718607 arp: Src 0022.bdf8.19ff/17.1.1.1 Dst
ffff.ffff.ffff/17.1.1.1
2015 Oct 28 12:06:01.720627 arp: (context 1) Receiving packet from Vlan2331,
logical interface Vlan2331 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:06:01.721457 arp: Src 0022.bdf8.19ff/16.1.1.1 Dst
ffff.ffff.ffff/16.1.1.1

使用中のブリッジ ドメインで設定された 2 番目の IP アドレスを使用します。上の例では、BD17 は L2 out により EP 17.1.1.230 を学習しています。

次の出力例は、トポロジにおける Nexus 5000 での debug ip arp packet コマンドによるものです。BD17 PIP と CMAC がエンドポイント トラッキングを実行しているのを確認できます。フレームは、設定済みの BD17 PIP および CMAC を使用して ACI リーフから送信されて、エンドポイント 17.1.1.1 がレイヤ 2 エンドポイント グループ上にまだ保持されていることを確認します。

2015 Oct 28 12:05:31.711090arp: (context 1) Receiving packet from Vlan2330,
logical interface Vlan2330 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:05:31.711940 arp: Src 0022.bdf8.19ff/17.1.1.1 Dst
ffff.ffff.ffff/17.1.1.1
2015 Oct 28 12:05:31.713557 arp: (context 1) Receiving packet from Vlan2331,
logical interface Vlan2331 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:05:31.714382 arp: Src 0022.bdf8.19ff/16.1.1.1 Dst
ffff.ffff.ffff/16.1.1.1
2015 Oct 28 12:06:01.717761 arp: (context 1) Receiving packet from Vlan2330,
logical interface Vlan2330 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:06:01.718607 arp: Src 0022.bdf8.19ff/17.1.1.1 Dst
ffff.ffff.ffff/17.1.1.1
2015 Oct 28 12:06:01.720627 arp: (context 1) Receiving packet from Vlan2331,
logical interface Vlan2331 physical interface Ethernet1/23, (prty 1) Hrd
type 1 Prot type 800 Hrd len 6 Prot len 4 OP 1,  Pkt size 46
2015 Oct 28 12:06:01.721457 arp: Src 0022.bdf8.19ff/16.1.1.1 Dst
ffff.ffff.ffff/16.1.1.1

- GUI を使用した共通パーベイシブ ゲートウェイを備えたデュアル ファブリックの設定

GUI を使用した共通パーベイシブ ゲートウェイを備えたデュアル ファブリックの設定

次の手順は、このユースケースに対し、GUI を使用して共通パーベイシブ ゲートウェイによってデュアル ファブリックを設定する方法について説明します。

手順

ステップ 1

メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

ステップ 2

[Work] ペインで、[Tenant_Name] をダブルクリックします。

ステップ 3

ナビゲーション ウィンドウで、[Tenant_Name] > [Networking] > [Bridge Domains] > [BD_name] の順に選択します。

ステップ 4

[Work] ペインで、[Properties] に次の値を設定します。

1. [L2 Unknown Unicast] ボタンでは [Flood] をクリックします。

2. [L3 Unknown Multicast Flooding] ボタンでは [Flood] をクリックします。

3. [Multi Destination Flooding] ボタンでは、[Flood in BD] をクリックします。

ステップ 5

[L3 Configurations] タブを選択します。

ステップ 6

[Work] ペインで、[Properties] に次の値を設定します。

1. [Custom MAC Address] フィールドには、ブリッジ ドメインのカスタム MAC アドレスを入力します。

カスタム MAC アドレスは、ファブリック間で異なる必要があります。

2. [Virtual MAC Address] フィールドには、ブリッジ ドメインの仮想 MAC アドレスを入力します。

仮想 MAC アドレスは、ファブリックの間で一致している必要があります。

ステップ 7

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

ステップ 8

ナビゲーション ウィンドウで、[Tenant_Name] > [Networking] > [Bridge Domains] > [BD_name] > [Subnets] > [Subnet_IP] の順に選択します。

ステップ 9

[Work] ペインで、[Treat as virtual IP address] ボックスにチェックマークを付けてください。

これで、VIP（仮想 IP アドレス）としてブリッジ ドメインのゲートウェイ IP アドレスが設定されます。

また、[Subnets] フォルダの下も、ARP グリーニングおよびエンドポイント トラッキングに使用される 16.1.1.103 アドレスです。このアドレスは、ファブリック全体でブリッジ ドメインで一意である必要があります。

ステップ 10

ファブリック間でミラーリングされる各ブリッジ ドメインに対してステップ 3 ～ 9 を繰り返します。

Chapter6. コントラクトの使用

- コントラクト

- フィルタ

- タブーコントラクト

- テナント間コントラクト

コントラクト

コントラクトは、Cisco Application Centric Infrastructure (ACI) 管理者にエンドポイント グループ間での Cisco ACI ファブリック内トラフィック フローを制御する手段を提供します。これらのコントラクトは、一方のエンドポイント グループが希望するサービスを提供し、もう一方のエンドポイント グループがそれらのサービスを消費するプロバイダー/コンシューマ モデルを使用して構築されます。コントラクトには、グローバル、テナント、VRF、またはアプリケーション プロファイルの範囲が割り当てられ、これによりコントラクトのアクセシビリティが制限されます。

つまり、コントラクトは 1 つ以上のサブジェクトで構成されます。各サブジェクトには 1 つ以上のフィルタが含まれます。各フィルタには 1 つ以上のエントリが含まれます。各エントリは、アクセス コントロール リスト（ACL）の 1 行に相当し、エンドポイント グループ内のエンドポイントが接続されているリーフ スイッチで適用されます。

詳細には、コントラクトは次の項目で構成されます。

- サブジェクト：特定のアプリケーションまたはサービス用のフィルタのグループ。

- フィルタ：レイヤ 2 ～ レイヤ 4 の属性 (イーサネット タイプ、プロトコル タイプ、TCP フラグ、ポートなど) に基づいてトラフィックを分類するために使用します。

- アクション：フィルタリングされたトラフィックで実行されるアクション。次のアクションがサポートされます。

- トラフィックの許可 (通常のコントラクトのみ)

- トラフィックのマーク (DSCP/CoS) (通常のコントラクトのみ)

- トラフィックのリダイレクト (サービス グラフによる通常のコントラクトのみ)

- トラフィックのコピー (サービス グラフまたは SPAN による通常のコントラクトのみ)

- トラフィックのブロック（タブー コントラクトのみ）

- トラフィックのロギング（タブー コントラクトのみ）

- ラベル：（任意）ポリシーの適用における精度を高めるために、サブジェクトやエンドポイント グループなどのオブジェクトをグループ化するために使用します。

異なるエンドポイント グループは、定義済みのコントラクト ルールに基づいてのみ別のエンドポイント グループと通信できますが、エンドポイント グループ内通信ではコントラクトは必要ありません。同じエンドポイント グループ内のエンドポイント間のエンドポイント グループ内通信は、デフォルトで許可されます。

契約がサブジェクトと、2 つのエンドポイント グループ（EPG）間の任意の送信元ポートと宛先ポート 80 を持つフィルタで定義されている場合、1つはコンシューマとして、もう 1 つはプロバイダーとして、Cisco ACI ファブリックはコンシューマ EPG からプロバイダー EPG へのパケットを許可します。宛先ポートは80、送信元ポートはanyです。ただし、プロバイダーからコンシューマへの戻りパケットはまだ許可されていません。リターンパケットを許可するオプションの1つは、フィルタのサブジェクトで [両方の方向を適用（Apply Both Direction）] と [リバース フィルタ ポート（Reverse Filter Port）] を有効にすることです。これら 2 つのオプションは、サブジェクトの作成時にデフォルトで有効になっています。

[両方の方向を適用（Apply Both Direction）] は、同じレイヤ 4 ポートの組み合わせを持つ反対方向のパケット、つまり、プロバイダー EPG から宛先ポート 80 および任意の送信元ポートを持つコンシューマ EPG へのパケットを許可するルールを作成します。次に、[リバース フィルタ ポート（Reverse Filter Port）] は、この新しいルールの宛先ポートと送信元ポートを反転させます。これにより、プロバイダー EPG からコンシューマ EPG へのパケットが、プロバイダー EPG からのリターンパケットと一致する宛先ポートと送信元ポート 80 で許可されるというルールが作成されます。

ただし、Cisco ACI コントラクトはステートフルではなく、プロバイダー EPG からコンシューマ EPG へのパケットはリターン パケットである必要はありません。これは、プロバイダー EPG がコンシューマ EPG へのトラフィックを開始する場合、送信元ポートが 80 であれば、Cisco ACI ファブリックはそれをすべての宛先ポートに許可することを意味します。フィルタの [ステートフル（Stateful）] オプションを使用すると、このような TCP トラフィックの問題を回避できます。ステートフル オプションが有効になっている場合、リターン方向（プロバイダーからコンシューマ）のルールは、TCP ポート（この例では宛先ポートと送信元ポート 80）の上にある TCP ACK フラグをチェックして、プロバイダーEPGから開始されたトラフィックをブロックします。

コントラクトを設定していない場合はマルチキャストキャスト トラフィックおよび同一クラスのトラフィック以外に、次のタイプのパケットのトラフィックだけが許可されます。

- DHCP v4（prot 0x11、sport 0x44、dport 0x43）

- DHCP v4（prot 0x11、sport 0x43、dport 0x44）

- DHCP v6（prot 0x11、sport 0x222、dport 0x223）

- OSPF（prot 0x59）

- EIGRP（prot 0x58）

- PIM（prot 0x67）

- IGMP（prot 0x2）

- ND-Sol ICMPv6（prot 0x3a dport 0x0087）

- ND-Advt ICMPv6（prot 0x3a dport 0x0088）

次の例では、第 1 のエンドポイント グループ内の Web サーバ群、第 2 のエンドポイント グループ内のアプリケーション サーバ群、第 3 のエンドポイントグループ内のデータベース サーバ群を含む 3 層アプリケーションでのエンドポイント グループ間トラフィック フローを、さまざまなコントラクトが制御する方法を示します。Web エンドポイント グループ（プロバイダー）は、L3Out エンドポイント グループ（Cisco ACI ファブリックへの外部からのトラフィック）で使用されるコントラクト（contract1）を提供します。これにより、Cisco ACI ファブリックの外部から Web サーバに Web トラフィックが 到達できるようになります。アプリケーション エンドポイント グループ（プロバイダー）は、Web エンドポイント グループ（コンシューマ）が使用する通信用のコントラクト（contract2）を提供します。これにより、Web サーバはアプリケーション サーバ上のアプリケーションを呼び出せるようになります。最後に、アプリケーション エンドポイント グループ（コンシューマ）は、データベース エンドポイント グループ（プロバイダー）が提供するコントラクト（contract3）を使用します。これにより、アプリケーション サーバは、アプリケーションのデータベースにアクセスできるようになります。非確認済み UDP トラフィックの場合、リバース ポート フィルタリングは必要ありません。ただし、TCP トラフィックの場合は、応答側は、リバース ポート フィルタリングまたは応答側からのすべての確立されたトラフィックを許可する別のコントラクトがなければ TCP セッションを設定できません。

エンド ポイント グループ間のコントラクトポリシー

Cisco ACI で適用できるコントラクトの種類は次のとおりです。

- 通常のコントラクト

- タブー コントラクト

- アウトオブバンド（OOB）コントラクト

コントラクトは、次のタイプのエンドポイント グループの通信を管理します。

- アプリケーション エンドポイント グループ間

- アプリケーション エンドポイント グループと外部ネットワーク間

- アプリケーション エンドポイント グループとインバウンド向けのマネージメント エンドポイント グループ間。たとえば、インバウンド マネージメントが Cisco ACI ファブリック用に構成されており、特定のエンドポイント グループがそのファブリックへのアクセスを許可される場合などです。

アウトオブバンド コントラクトは、管理テナントからのアウトオブバンド トラフィックのみに適用されます。タブー コントラクトは、通常のコントラクトに関連するトラフィックを拒否およびロギングするために使用され、通常のコントラクトより前にハードウェア内に設定されます。たとえば、ポート 305 を除く送信元ポート 50 から 500 までのトラフィックを許可するには、タブー コントラクトにポート 305 を拒否する単一のエントリを作成し、一方、通常のコントラクトで 50 から 500 の範囲内のすべてのポートを許可します。ポート 305 を拒否するタブー コントラクトは、通常のコントラクトでポート 50 から 500 を許可する前に、ハードウェアにプログラムします。

- コントラクト構成パラメータ

- VRF コントラクトの適用または削除

コントラクト構成パラメータ

コントラクトを構成する場合は、次のオプションを定義できます。

- Application-profile：このコントラクトは、同じアプリケーション プロファイル内のすべてのエンドポイント グループに適用できます。

- Contract Scope：2 つ以上の参加ピア エンティティまたはエンドポイント グループ間のサービスコントラクトの範囲。コントラクトは、プロバイダー エンドポイント グループの範囲外のコンシューマ エンドポイント グループには適用されません。

以下の状態があります。

- Private Network：このコントラクトは、同じ VRF 内のすべてのエンドポイント グループに適用できます。

- Tenant：このコントラクトは、同じテナント内のすべてのエンドポイント グループに適用できます。

- Global：このコントラクトは、ファブリック全体にわたり、すべてのエンドポイント グループに適用できます。

デフォルトのステータスは [Private Network] です。

- QoS Class：サービス コントラクトの優先度レベル。

以下の優先度レベルを指定できます。

- [Unspecified]

- Level1：クラス 1 の DSCP（Differentiated Services Code Point）値。

- Level2：クラス 2 の DSCP 値。

- Level3：クラス 3 の DSCP 値。

デフォルトは Unspecified（未指定）です。

- Tags (labels)：（任意）検索キーワードまたはアプリケーション プロファイルに割り当てられている用語。タグを使用すると、わかりやすい名前で複数のオブジェクトをグループ化できます。複数のオブジェクトに同じタグ名を割り当て、1 つのオブジェクトに 1 つ以上のタグ名を割り当てることができます。コントラクトがコンシューマまたはプロバイダーとしてエンドポイント グループに割り当てられている場合、デフォルトで、コントラクト内のすべてのサブジェクトがそのエンドポイント グループに適用されます。タグがある場合は、一致基準を持つアプリケーション プロファイル内のエンドポイント グループだけが、コントラクトのサブジェクトを導入します。

- Match：コンシューマ エンドポイント グループ間のサブジェクト一致基準。ラベルは、エンドポイント グループ、コントラクト、ブリッジ ドメイン、DHCP リレー ポリシー、および DNS ポリシーなどのさまざまなプロバイダーおよびコンシューマの管理対象オブジェクトに適用できます。プロバイダー ラベルとコンシューマ ラベルの一致を確認する場合、一致設定はプロバイダー エンドポイント グループによって決定されます。次のさまざまなオプションがあります。

- AtleastOne：少なくとも1 つのラベルが、プロバイダー エンドポイント グループとコンシューマ エンドポイント グループで一致する。空白のラベルは一致と見なされます。

- AtmostOne：エンドポイント グループ上のすべてのラベルがまったく同じ場合にのみ一致する。空白のラベルは一致と見なされます。

- None：サブジェクト ラベルのいずれも一致しない。

- All：両エンドポイント グループに空白のラベル以外のすべてのラベルがある場合にのみ一致する。

デフォルトは AtleastOne（1 つ以上）です。

コントラクトの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. ナビゲーション ウィンドウでは、[Tenant_Name] > [Security Policies] > [Contracts] を選択します。

4. 作業ウィンドウで、[Actions] > [Create Contract]の順に選択します。

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

1. コントラクトの名前を入力します。

2. （任意）コントラクト範囲を選択します。

3. （任意）[QoS Class] を選択します。

4. [Subject] の横にある [+] をクリックし、コントラクト サブジェクトを追加します。

1. [Create Contract Subject] ダイアログボックスで、次の操作を実行します。

1. コントラクトの件名を入力します。

2. [Filter Chain] フィールドで [+] をクリックします。

フィルタの作成については、「フィルタ」の項を参照してください。

6. [更新（Update）] をクリックします。

7. OK をクリックします。

8. [送信（Submit）] をクリックします。

コントラクトの変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Security Policies] > [Contracts] > [Contract_Name] を選択します。

4. [Work] ペインで、[Policy] タブを選択します。

1. （任意）[Contract Scope] を選択します。

2. （任意）[QoS Class] を選択します。

3. [Subject] フィールドの横にある [+] をクリックし、コントラクト サブジェクトを追加します。

1. [Create Contract Subject] ダイアログボックスで、次の操作を実行します。

1. コントラクトサブジェクトの名前を入力します。

2. [Filter Chain] の横にある [+] をクリックします。

（注）

フィルタの作成については、「フィルタ」の項を参照してください。

5. [Update] をクリックします。

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

7. [送信（Submit）] をクリックします。

コントラクトの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Security Policies] > [Contracts] > [Contract_Name] を選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

コントラクトの確認

REST :: /api/node/class/vzBrCP.xml

CLI :: moquery -c vzBrCP

EPG へのコントラクトの適用

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Contracts] の順に選択します。

4. [Work] ペインで、[Actions] > [Add Provided Contract] または [Actions] > [Add Consumed Contract] を選択します。

注：コントラクトの展開方法に応じた操作を選択します。

5. [Add Contract] ダイアログボックスで、次の操作を実行します。

1. [Contract_Name] を入力します。

2. [QOS policy] を選択します（任意）。

3. [Label] を選択します（任意）。

6. [送信（Submit）] をクリックします。

EPG からのコントラクトの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Contracts] > [Contract_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

EPG でのコントラクトの確認

Provider

REST :: /api/node/class/fvRsProv.xml

CLI :: moquery -c fvRsProv

Consumer

REST :: /api/node/class/fvRsCons.xml

CLI :: moquery -c fvRsCons

外部ネットワークへのコントラクトの適用

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Networking] > [External Routed Networks] > [Routed Outside_Name] > [Networks] > [External_Network_Instance_Profile] の順に選択します。

4. [Work] ペインで、[Add Provided Contract] または [Add Consumed Contract] のいずれかの横にある [+] をクリックします。

注：コントラクトをどのように導入するかによって選択します。

1. [Contract_Name] を選択します。

2. [QOS Type] を選択します。

3. [Match Criteria] を選択します。

5. [更新（Update）] をクリックします。

外部ネットワークからの通信に関するコントラクトの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Networking] > [External Routed Networks] > [Routed Outside_Name] > [Networks] > [External_Network_Instance_Profile] の順に選択します。

4. 作業ウィンドウで、[Contract_Name] を選択し、 [x] をクリックします。

外部ネットワークコントラクトの確認

Provider

REST :: /api/node/class/fvRsProv.xml

CLI :: moquery -c fvRsProv

Consumer

REST :: /api/node/class/fvRsCons.xml

CLI :: moquery -c fvRsCons

VRF コントラクトの適用または削除

VRF インスタンス内のすべてのエンドポイント グループにコントラクトを適用するために、コントラクトを VRF インスタンスに直接適用できます。この概念は「vzAny」エンドポイント グループとも呼ばれます。単一の設定箇所から VRF インスタンス内のすべてのエンドポイント グループのコントラクトの設定を許可し、ハードウェアのリソース消費を最適化することでコントラクト管理を容易にします。

たとえば、Cisco Application Centric Infrastructure (ACI) 管理に 100 個のエンドポイント グループがあり、それらすべてが同じ VRF の部分である場合、エンドポイント グループごとではなく、VRF にあるこの 1 つの vzAny グループにコントラクトを適用できます。

VRF インスタンス規模のコントラクトとは、従来、TCP トラフィックで逆ポート転送をイネーブルにする必要なしに、エンドポイント グループ コントラクトが 1 方向（コンシューマからプロバイダー）のトラフィックのみを定義することを可能にする、確立されたトラフィックを許可するコントラクトです。VRF インスタンス内のすべてのエンドポイント グループが確立されたトラフィックを許可するため、エンドポイント グループに直接適用されるコントラクトで逆ポート転送は不要です。

コントラクトまたはその欠如が ACI ファブリックで VRF 内のトラフィックをブロックしているかを確認する簡便な方法として、VRF インスタンスを非強制化する方法があります。これにより、コントラクトを必要とせずに、VRF インスタンス内のすべてのエンドポイント グループ間の通信が許可されます。これは、VRF インスタンス エンドポイント グループに共通のテナント コントラクト vzAny を適用することに相当します。

（注）

VRF 内に非常に多くのコントラクトがある場合は、VRF が強制化に戻ったときにリーフ スイッチにコントラクトを再導入するのに、最長で 1 時間かかる場合があります。

共有サービスの場合は、コンシューマ (vzAny) 側の宛先の pcTag（分類）を適切に導出するために、EPG の下にプロバイダ EPG 共有サブネットを定義する必要があります。コンシューマとプロバイダの両方のサブネットがブリッジ ドメイン下で定義され、共有サービス コンシューマとして機能する vzAny に対して、ブリッジ ドメインからブリッジドメインへの共有サービス設定から移行する場合は、少なくとも共有フラグを使用してプロバイダ サブネットを EPG に追加する追加の設定手順を実行する必要があります。

（注）

定義済みのブリッジ ドメイン サブネットの複製として EPG サブネットを追加する場合は、サブネットの両方の定義に同じフラグが定義されていることを確認してください。そうしないと、予期しないファブリック転送の動作が発生する可能性があります。

- GUI を使用したコントラクトの VRF（vzAny）への適用

- GUI を使用したコントラクトの VRF（vzAny）からの削除

- VRF コントラクトの確認

GUI を使用したコントラクトの VRF（vzAny）への適用

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Networking] > [Private Networks] > [Private_Network_Name] > [EPG Collection for Context] の順に選択します。[

4. [Work] ペインで、[Add Provided Contract] または [Add Consumed Contract] のいずれかの横にある [+] をクリックします。

コントラクトをどのように導入するかによって選択します。

1. [Contract_Name] を入力します。

2. [QOS Type] を選択します。

3. [Match Criteria] を選択します。

5. [更新（Update）] をクリックします。

GUI を使用したコントラクトの VRF（vzAny）からの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、[Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Networking] > [Private Networks] > [Private_Network_Name] > [EPG Collection for Context] の順に選択します。

4. 作業ウィンドウで、 [Contract_Name] を選択し、[x] をクリックします。

VRF コントラクトの確認

次の API は、VRF のコントラクトを確認します。

/api/node/class/vzBrCP.xml

次の iShell コマンドは VRF のコントラクトを確認します。

admin@apic1:~> moquery -c vzBrCP

フィルタ

フィルタは、トラフィックをフィルタリングするためのフィルタ エントリのグループです。各フィルタ エントリは、TCP/IP ヘッダー フィールド（レイヤ 3 プロトコル タイプ、レイヤ 4 ポートなど）に基づいて分類されるトラフィックを許可または拒否するのに使用されるルールです。フィルタは、エンドポイント グループに関連付けられるコントラクトで定義されます。エンドポイント グループに着信、エンドポイント グループから送信、またはその両方のいずれかに定義できます。サブジェクトは、フィルタをコントラクトに接続するエンティティです。エンティティは、このコントラクトにより提供されるかまたは消費されるエンドポイント間のトラフィックに影響を及ぼします。

- フィルタ エントリ構成パラメータ

- GUI を使用したフィルタの作成

- GUI を使用したフィルタの変更

- GUI を使用したフィルタの削除

- NX-OS スタイルの CLI を使用したフィルタの設定

- NX-OS スタイルの CLI を使用したフィルタの削除

- フィルタの確認

フィルタ エントリ構成パラメータ

フィルタを構成する場合は、次のオプションを定義できます。

- Name：フィルタ エントリの名前。

- EtherType：フィルタ エントリの EtherType。次の EtherType があります。

- 『ARP』

- FCOE

- IP

- MAC セキュリティ

- MPLS Unicast

- Trill

- [Unspecified]

- ARP Flag：フィルタ エントリのアドレス解決プロトコル フラグ。フィルタ エントリは、ネットワーク トラフィックの分類プロパティの組み合わせです。

- IP Protocol：フィルタ エントリの IP プロトコル。フィルタ エントリは、ネットワーク トラフィックの分類プロパティの組み合わせです。

- Match Only Fragments：パケット フラグメントにのみ一致。有効の場合、オフセットが 0 より大きいすべての IP フラグメント（最初のフラグメントを除くすべての IP フラグメント）にこのルールが適用されます。無効の場合、TCP/UDP ポート情報は最初のフラグメントでしかチェックできないため、オフセットが 0 より大きい IP フラグメントにルールは適用されません。

- Port Ranges (Source, Destination)：送信元と宛先のポート フィールド。[From] フィールドと [To] フィールドに同じ値を指定して単一のポートを指定するか、または、[From] フィールドと [To] フィールドに異なる値を指定して、0 ～ 65535 の範囲のポートを定義できます。数字を指定する代わりに、次のサーバ タイプのいずれかを選択すると、事前定義されたタイプのポートを使用することができます。

- HTTPS

- SMTP

- [HTTP]

- FTP-Data

- [Unspecified]

- [DNS]

- POP3

- rtsp

デフォルトは Unspecified（未指定）です。

- TCP フラグ：このオプションは、EtherType、IPプロトコル、送信元ポート、および宛先ポートに加えて、トラフィックに一致するTCPフラグ値を指定します。使用可能なTCPフラグは次のとおりです。

- Synchronize：SYN

- Established：ACKまたはRST

- Acknowledgement: ACK

- Reset: RST

- Finish: FIN

- Stateful：Stateful オプションは、ACK フラグが設定されている場合にのみ、プロバイダーからコンシューマへのTCPパケットを許可します。

GUI を使用したフィルタの作成

次の手順は、GUI を使用してフィルタを作成します。

手順

ステップ 1

メニュー バーで、[Tenants] > [All Tenants] の順に選択します。

ステップ 2

[Work] ペインで、テナントの名前をダブルクリックします。

ステップ 3

[Navigation] ペインで、[Tenant tenant_name] > [Security Policies] > [Filters] の順に選択します。

ステップ 4

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

ステップ 5

[Create Filter] ダイアログボックスで、次に指定されている点を除き、必要に応じてフィールドに入力します。

1. [Name] フィールドにフィルタの名前を入力します。

2. [Entries] テーブルの [+] をクリックします。

ステップ 6

[Entries] テーブルのフィールドに、次に指定するように入力します。

1. [Name] フィールドにフィルタ エントリの名前を入力します。

2. [Ethertype] ドロップダウン リストで、EtherType を選択します。

3. （任意） [ARP Flag] ドロップダウン リストで、ARP フラグを選択します。

4. （任意） [IP Protocol] ドロップダウン リストで、IP プロトコルを選択します。

5. （任意） 必要に応じて、[Match Only Fragments] チェックボックスにチェックマークを付けてください。

6. （任意） [Source Port From] ドロップダウン リストで、送信元ポートを選択します。

7. （任意） [Source Port To] ドロップダウン リストで、送信元ポートを選択します。

8. （任意） [Destination Port From] ドロップダウン リストで、宛先ポートを選択します。

9. （任意） [Destination Port To] ドロップダウン リストで、宛先ポートを選択します。

10. （任意） [TCP Flags] ドロップダウンリストで、TCPフラグを選択します。

11. （任意） 必要に応じて、[Stateful] チェックボックスをオンにします。

12. Update をクリックします。

ステップ 7

[送信（Submit）] をクリックします。

GUI を使用したフィルタの変更

次の手順は、GUI を使用してフィルタを変更します。

手順

ステップ 1

メニュー バーで、[Tenants] > [All Tenants] の順に選択します。

ステップ 2

[Work] ペインで、テナントの名前をダブルクリックします。

ステップ 3

[Navigation] ペインで、[Tenant tenant_name] > [Security Policies] > [Filters] > [filter_name] の順に選択します。

ステップ 4

[Navigation] ペインで、[Entries] テーブルの、変更するフィルタ エントリをダブルクリックします。

ステップ 5

値を変更します。

ステップ 6

[更新（Update）] をクリックします。

GUI を使用したフィルタの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [セキュリティ ポリシー（Security Policies）] > [フィルタ（Filters）] > [Filter_Name] を選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

NX-OS スタイルの CLI を使用したフィルタの設定

フィルタはテナント シェルを介して NX-OS スタイルの CLI で作成し、アクセスすることができます。

手順

ステップ 1

ファブリックの APIC に SSH 接続します。

# ssh admin@node_name

ステップ 2

設定モードを開始します。

apic1# configure

ステップ 3

目的のテナントに移動します。

apic1(config)# tenant tenant1

ステップ 4

「match tcp dest 80」と「match ip」のエントリを含む、「FilterHTTPS」と呼ばれるフィルタを作成します。

apic1(config-tenant)# access-list FilterHTTPS
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# exit

ステップ 5

「FilterHTTPS」フィルタを適用するコントラクトにアクセスします。

apic1(config-tenant)# contract WebHTTPS

ステップ 6

コントラクトにフィルタを接続するサブジェクト「SubjectHTTPS」を作成します。このようにして、同一のエントリを含む複数のフィルタを作成する必要なく、複数のコントラクトに同じフィルタを適用できます。

apic1(config-tenant-contract)# subject SubjectHTTPS

ステップ 7

フィルタをコントラクトに関連付けます。フィルタを使用して、コントラクト「WebHTTPs」に関連付けられているエンドポイント グループに入力しているトラフィックに一致させる、コントラクトに関連付けられているエンドポイント グループから出力しているトラフックに一致させる、またはその両方を行うことができます。

apic1(config-tenant-contract-subj)# access-group FilterHTTPS
both  match traffic in both direction
in      match traffic from provider to consumer
out   match traffic from consumer to provider
apic1(config-tenant-contract-subj)# access-group FilterHTTPS both

NX-OS スタイルの CLI を使用したフィルタの削除

手順

ステップ 1

次のコマンドは、フィルタの関連付けを削除します。

apic1(config-tenant-contract-subj)# no access-group FilterHTTPS both

ステップ 2

次のコマンドは、すべてのフィルタを削除します。

apic1(config-tenant)# no access-list FilterHTTPS

フィルタの確認

フィルタを確認するには、次のいずれの方法も使用できます。

- GUI で、次の場所に移動します。

[Tenant_Name] > [Security Policies] > [Filters] > [Filter_Name]

- 次の API を使用します。

/api/node/class/vzFilter.xml

- 次の NX-OS スタイルの CLI コマンドを入力します。

apic1# show run

- 次のオブジェクト モデルの CLI コマンドを入力します。

admin@apic1:~> moquery -c vzFilter

タブーコントラクト

ACI 管理者が別のコントラクトによって許可されたトラフィックを拒否する必要がある場合があります。タブーコントラクトは、別のコントラクトによって許可される可能性がある特定のトラフィックを拒否するために ACI 管理者が使用できる特殊なコントラクトです。タブーコントラクトは、パターンに一致するトラフィック（EPG、フィルタに一致する特定の EPG など）をドロップするために使用できます。タブーコントラクトのルールはハードウェアで通常のコントラクトのルールが適用される前の場合に適用されます。

従来のネットワーク概念を模倣するには、特定のタイプのトラフィックを制限するように構成したタブーコントラクトとともに、「すべてのトラフィックを許可する」コントラクトを適用します。

- タブーコントラクト構成パラメータ

タブーコントラクト構成パラメータ

タブーコントラクトを構成する場合は、次のオプションを定義できます。

- Name：コントラクトまたはコントラクトのオブジェクトの名前。

- Subjects：ネットワーク ドメイン名のラベル。ラベルによって、互いに通信可能なオブジェクト、または通信できないオブジェクトを分類できます。

- Directive：タブー コントラクトに割り当てられたフィルタのディレクティブ。

タブーコントラクトの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Security Policies] > [Taboo Contracts] を選択します。

4. [Work] ペインで、[Actions] > [Create Taboo Contract] の順に選択します。

5. [Create Taboo Contract] ダイアログボックスで、次の操作を実行します。

1. タブーコントラクトの名前を入力します。

2. [Subject] フィールドの横にある [+] をクリックし、禁止サブジェクトを追加します。

1. フィルタの名前を入力します。

2. ディレクティブを選択します。

6. [Update] をクリックします。

7. OK をクリックします。

8. [送信（Submit）] をクリックします。

タブーコントラクトの変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドで、 [Tenant_Name] > [Security Policies] > [Taboo Contracts] > [Taboo_Contract_Name] を選択します。

4. [Work] ペインで、[policy] を選択します。

1. [Subject] フィールドの横にある [+] をクリックします。

2. [Create Taboo Contract Subject] ダイアログ ボックスで、次の操作を実行します。

1. タブー コントラクト サブジェクトの名前を入力します。

2. [Filter Chain] フィールドで [+] をクリックします。

1. フィルタの名前を入力します。

2. ディレクティブを選択します。

5. [送信（Submit）] をクリックします。

タブーコントラクトの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドで、 [Tenant_Name] > [Security Policies] > [Taboo Contracts] > [Taboo_Contract_Name] を選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

タブーコントラクトの確認

REST :: /api/node/class/vzTaboo.xml

CLI :: moquery -c vzTaboo

EPG へのタブーコントラクトの適用

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Contracts] の順に選択します。

4. [Work] ペインで、[Actions] > [Add Taboo Contract] を選択します。

5. [Add Taboo Contract] ダイアログボックスで、次の操作を行います。

1. [Taboo Contract] を選択します。

6. [送信（Submit）] をクリックします。

EPG からのタブーコントラクトの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] > [Contracts] の順に選択します。

4. 作業ウィンドウで、[Taboo Contract_Name] > [Actions] > [Delete] の順に選択します。

EPG に適用したタブー コントラクトの確認

Provider

REST :: /api/node/class/fvRsProv.xml

CLI :: moquery -c fvRsProv

Consumer

REST :: /api/node/class/fvRsCons.xml

CLI :: moquery -c fvRsCons

テナント間コントラクト

ACI 管理者が 2 つのテナント間のトラフィックを許可する必要がある場合があります。インターフェイスコントラクトは、コントラクトのエクスポートを使用して特定のトラフィックを許可するために ACI 管理者が使用できる特殊なタイプのコントラクトです。基本的に、コントラクトを送信元テナントでエクスポートし、ターゲット テナントにインポートします。従来のコントラクトと同様に、送信元 EPG はプロバイダー タイプです。ただし、ターゲット テナントでは、コントラクトはコントラクトインターフェイス タイプとしてインポートされます。一部の使用例には、次の章の完全なプロセスが示されています。

- 構成パラメータ

- 入力ベース ACL

- コントラクトの使用例

構成パラメータ

コントラクトをインポートする場合は、次のオプションを定義できます。

- Name：コントラクト インターフェイスの名前。

- Global Contract：2 つ以上の参加ピア エンティティ間で共有されるサービス コントラクトの名前。

- Tenant：ターゲットのエクスポートコントラクトのテナント名。

エクスポートコントラクト

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウでは、 [Tenant_Name] > [Security Policies] > [Contracts] を選択します。

4. [Work] ペインで、[Actions] > [Export Contract] の順に選択します。

5. [Export Contract] ダイアログボックスで、次の操作を実行します。

1. エクスポートコントラクトの名前を入力します。

2. [Global Contract] を選択します。

3. [Tenant Name] を入力します。

6. [完了（Finish）] をクリックします。

エクスポートされたコントラクトの変更

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Security Policies] > [Contracts] > [Contract_Name] を選択します。

4. [Work] ペインで、[policy] を選択します。

1. エクスポートコントラクトの名前を入力します。

2. [Global Contract] を選択します。

3. [Tenant Name] を入力します。

5. [完了（Finish）] をクリックします。

エクスポートされたコントラクトの削除

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Security Policies] > [Contracts] > [Imported Contracts] > [Contract_Name] の順に選択します。

4. [Work] ペインで、[Actions] > [Delete] の順に選択します。

エクスポートされたコントラクトの確認

REST :: /api/node/class/vzCPif.xml

CLI :: moquery -c vzCPif

入力ベース ACL

入力ベース ACL 機能の主な目的は、境界リーフのリソースを節約することです。このポリシー拡張モデルでは、ポリシーは非境界リーフのみに適用されるため、境界リーフでのゾーン ルールの使用量が低減します。このポリシーの適用方向は VRF レベルで適用され、前のポリシーの適用との下位互換性が許可されます。この新しいモデルのポリシーが適用方向は次のとおりです。

1. Host to WAN：ポリシーは非境界リーフで適用されます。

2. WAN to Host：ポリシーは、エンドポイント グループが境界リーフで既知であるかにかかわらず、非境界リーフで適用されます。

3. WAN to WAN：ポリシーは入力境界リーフで適用されます。

この機能は、中継ルーティング、vzAny、タブー コントラクトの使用例とは互換性がありません。中継ルーティング規則はすでに入力に適用されています。

- GUI を使用した入力ベース ACL の設定

- 入力ベース ACL の確認

GUI を使用した入力ベース ACL の設定

ポリシー コントロールの適用の方向は VRF で適用されます。

手順

ステップ 1

メニュー バーで、[Tenant] > [All TENANTS] の順に選択します。

ステップ 2

[Work] ペインで、テナントの名前をダブルクリックします。

ステップ 3

[Navigation] ペインで、[Networking] > [VRFs] > [VRF Name] の順に選択します。

ステップ 4

[Work] ペインで、[Policy Control Enforcement Direction] を [Ingress] に設定します。

ステップ 5

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

ステップ 6

ポリシーの使用を確認し、[Submit Changes] をクリックします。

入力ベース ACL の確認

次の iShell コマンドは入力ベースの ACL を確認します。

admin@apic1:~> moquery -c fv.Ctx -f ‘fv.Ctx.name==”vrf-name”’

次のハードウェア CLI コマンドは入力ベースの ACL を確認します。

# vsh_lc
module-1# show system internal eltmc info vrf name

コントラクトの使用例

これらの使用例はすべて、EPG-1 のホストが EPG-2 のホストと通信して双方向トラフィックを実現することが目的であると想定しています。これらのシナリオがどのように実現されるかは、選択した運用モデルや、システムがオブジェクトの再利用を重視しているのか、テナントの自立性を重視しているのかによって異なります。詳細な説明については、コントラクトのスコーピングに関するコントラクトの項を参照してください。

次に、いくつかの一般的なシナリオを示します。

1. テナント間コントラクト

2. プライベート ネットワーク間コントラクト

3. リバースフィルタを使用した双方向通信の単一コントラクト

4. 複数フィルタを使用した単一方向の単一コントラクト

5. 単一フィルタを使用した単一方向の複数コントラクト

- テナント間コントラクト

- プライベート ネットワークコントラクトの通信

- 単一コントラクト、双方向、逆フィルタ

- 複数フィルタを使用した単一方向の単一コントラクト

- 単一方向単一フィルタの複数コントラクト

テナント間コントラクト

ACME 社は、ほとんどの企業と同様に、名前解決に DNS、ユーザ管理に Active Directory という具合に、共有サービスを利用しています。テナントのほとんどがこれらのサービスを使用する予定であるため、ACME 社 ではファブリック全体でこのトラフィックを許可する必要があります。異なるテナントに所属している EPG 間の通信は、同じコントラクトを共有している場合にだけ許可されます。同じコントラクトを使用するには、送信元のテナントから適切な接続先のテナントにそのコントラクトをエクスポートする必要があります。コントラクトは、接続先のテナントの [Security Policies] の [Imported Contract] セクションの下に表示されます。

使用されたコントラクトのインターフェイスを使用して、接続先のテナントの EPG とインポートされたコントラクトを関連付けます。

注：コントラクト消費のインターフェイスは、コントラクトで定義されている 1 つ以上のサブジェクトを表します。インターフェイスに関連付けることで、エンドポイント グループはインターフェイスによって示されるすべてのサブジェクトの使用を開始します。

次の使用例では、テナント Cisco-1 の EPG-1 にはテナント Cisco-2 の EPG-2 との通信が必要です。これは、連絡先インターフェイスを利用すると実現されます。テナント Cisco-1 では、ユーザが目的のコントラクトインターフェイスをエクスポートします。テナント Cisco-1 で、ユーザは目的のコントラクトをエクスポートし、EPG-2 にコントラクトを提供するプロバイダーを選択します。次に、ユーザは、テナント Cisco-2 にインポートされたコントラクトを確認し、使用するコントラクトとしてそのコントラクトを選択します。発信元 VRF から目的の VRF へのルートをアドバタイズするには、EPG 内にサブネットを作成する必要があります。

テナント間でのコントラクトのエクスポート

テナント Cisco-1/EPG-1

1. [Security Policies] で [Export Contract] を作成します。

2. EPG1 の共有サブネット範囲にホスト サブネット（デフォルトのゲートウェイ IP）を作成します。

3. EPG1 のプロバイダー コントラクト タイプにコントラクトを追加します。

4. ブリッジ ドメインのプライベート/パブリックのサブネット範囲にホスト サブネットを作成します。

テナント Cisco-2/EPG-2

1. エクスポートしたコントラクトが [Imported Contracts] に表示されていることを確認します。

2. EPG2 の共有サブネット範囲にホスト サブネット（デフォルトのゲートウェイ IP）を作成します。

3. EPG2 の使用されるコントラクト タイプにインターフェイス コントラクトを追加します。

4. ブリッジ ドメインのプライベート/パブリックのサブネット範囲にホスト サブネット（デフォルトのゲートウェイ IP）を作成します。

プライベート ネットワークコントラクトの通信

次の使用例では、VRF Cisco-1 の EPG-1 には VRF Cisco-2 の EPG-2 との通信が必要です。これは、EPG 内のサブネット フィールドを利用することで実現されます。EPG にサブネットを作成し、共有を選択することで、テナントを対象とするコントラクト内に示された VRF にルートがリークされます。

プライベート ネットワーク間でのコントラクトのエクスポート

1. [Security Policies] でコントラクトスコープを [Tenant] としてコントラクトを作成します。

2. （テナント Cisco-1/EPG-1）EPG1 の共有サブネット範囲にホスト サブネット（デフォルトのゲートウェイ IP）を作成します。

3. EPG1 のプロバイダー コントラクト タイプにコントラクトを追加します。

4. （テナント Cisco-1/EPG-2）EPG2 の共有サブネット範囲にホスト サブネット（デフォルトのゲートウェイ IP）を作成します。

5. EPG2 のプロバイダー コントラクト タイプにコントラクトを追加します。

単一コントラクト、双方向、逆フィルタ

この使用例は、両方向にコントラクトサブジェクトを適用するオプションと、フィルタ処理リバースを適用するオプションのコントラクトを実装する場合に役に立ちます。これは、最も一般的な使用例であり、単一プロバイダー/コンシューマ関係で実装する単一サブジェクト/フィルタを考慮しています。

次の使用例では、EPG-1は、「www」という名前のサブジェクトとのコントラクトを提供します。このサブジェクトには、送信元ポート any および宛先ポート 80（HTTP）を使用する TCP トラフィック用のフィルタと、[Apply Both Direction] および [Reverse Filter Port] オプションがあります。 これにより、EPG-2 の Web クライアントは EPG-1 の Web サーバのポート 80 で HTTP セッションを開始できます。つまり、EPG-1 は EPG-2 にサービスを提供しています。ただし、これにより、EPG-1 はポート 80 から EPG-2 の任意のポートへの TCP セッションを開始できます。これは通常、設定の目的ではありません。同じフィルタでステートフル オプションを有効にすると、EPG-1（プロバイダー）からの TCP ACK フラグを持つトラフィックのみが許可され、トラフィックが最初にコンシューマ側から開始されるようになります。ただし、ステートフル ファイアウォールとは異なり、プロバイダーからの SYN + ACK 攻撃は防止されません。

逆のフィルタを使用したデフォルトの双方向コントラクト

結果：

1 つのサブジェクトと、単一プロバイダーと単一コンシューマの 1 つのフィルタによる単一コントラクト。この例では、www です。

複数フィルタを使用した単一方向の単一コントラクト

この使用例には、両方向にコントラクトサブジェクトを適用するオプションなしでのコントラクトの実装が含まれています。このオプションを選択すると、逆フィルタ オプションを選択するオプションがなくなります。

次の使用例では、EPG-1 がサブジェクト icmp のコントラクトを提供し、EPG-2 がそのコントラクトを使用します。これにより、EPG-1 のホストは icmp を介してい EPG-2 のホストにアクセスできます。単一サブジェクトを [Apply Both Directions] を使用せずに利用すると、各方向に 1 つずつ、2 つのフィルタを構成する必要があります。

単一コントラクト、単一の単一方向サブジェクト、複数フィルタ

結果：

（1）サブジェクトと（2）フィルタによる単一のコントラクトと単一プロバイダーおよび単一コンシューマ。この例では、icmp です。

単一方向単一フィルタの複数コントラクト

この使用例は、両方向にコントラクトサブジェクトを適用するオプションをフィルタ処理フィルタを適用するオプションを使用せずにコントラクトを実装する場合に役に立ちます。これにより、エンドユーザはコントラクト導入時に最も高い粒度を許可できますが、最も包括的にもなります。

次の使用例では、EPG-1 はサブジェクト www のコントラクトを提供し、EPG-2 はそのコントラクトを使用します。これにより、EPG-2 の Web クライアントが EPG-1の Web サーバにアクセスできます。つまり、EPG-1 は EPG-2 にサービスを提供しています。

複数のコントラクト、単一方向サブジェクト、単一フィルタ

結果：

（1）サブジェクト（1）フィルタを使用した 2 つのコントラクト。各コントラクトに同じコントラクトを参照する単一プロバイダーと単一コンシューマがあります。ここで異なるのは、コントラクトが双方向に明示的に適用されることです。

Chapter7. レイヤ 4 ～ レイヤ 7 のサービスの挿入

- レイヤ 4 ～ レイヤ 7 統合のついて

- サービス導入ガイドの参考資料

- サービス グラフのモニタリング

- ASAv サンプル構成

レイヤ 4 ～ レイヤ 7 統合のついて

ACME 社 は、同社が新しいアプリケーションを設計したとき、たとえば、ファイアウォール、ロード バランサ、IDS/IPS、あるいはその他のタイプの higher-layer サービス デバイスなど、一部のサービスを組み込む必要があることに気づいていました。

従来のインフラストラクチャでは、サービスを挿入するにはデバイスを直列（インライン）に配置またはリダイレクトし、サービス デバイスへのトラフィックへ流れるようにする必要がありますたとえば、ファイアウォールを「bump in the wire」として、またはゲートウェイ ルータまたはスイッチ近くの付加サービス デバイスとして、直接インラインに配置することができます。一般的に、ファイアウォールは、静的設定のブロックを構築することで、デバイスごとに構成します。これらの静的設定ブロックは構成が機能する状況を生み出すために経時的に増大しますが、柔軟性が低く、壊れやすくなり、それによって変更管理が困難になる可能性があります。

シスコのアプリケーション セントリック インフラストラクチャ（ACI）の主要なテクノロジー イノベーションの 1 つとして、サービス グラフの適用によるサービス挿入のポリシー ベースの管理があります。この章の残りの部分では、レイヤ 4 ～ レイヤ 7 のサービスを効率的に管理するために、プロセスがどのように機能するかと、ACME がサービス グラフをどのように利用するかの概要を示します。

データセンター ファブリック機器は、ファブリック内の物理ホストや仮想ホスト間での入力からファブリックまでと、ファブリックからの出力への高速かつ効率的な転送を主な目的としています。有効なインフラストラクチャの実装では、この高速なファブリックをレイヤ 4 ～ レイヤ 7 サービスの統合をスマートに行うためにも利用します。レイヤ 4 ～ レイヤ 7 サービスには、次のようなものがあると考えられます。

- Firewalls

- ロード バランサ

- トラフィック検査のアプライアンス

- SSL オフロード機能

- アプリケーション フローのアクセラレーション機能

サービスと Cisco ACI サービス グラフとの統合サービスは、ACME に次の利点を提供します。

- ポリシー ベースの構成管理

- ACI オブジェクト モデルによる柔軟な構成状態の抽象化

- すべて一貫した ACI オブジェクト モデルに基づいた、APIC GUI、REST API、または Python を使用した統合構成の管理

- 複雑なトポロジモデル上で論理フローを繋げていくことで、複数のデバイス間を結ぶ抽象化されたリンクを作成

- ポリシー ベースのプロビジョニングによる高速で複雑なトポロジの展開

- 構成の同期化による、手動による介入を必要としない動的なワークロードのプロビジョニングとデプロビジョニング

- アプリケーション中心のテンプレート ベースの構成管理およびオブジェクトの再利用によるインフラストラクチャ実装タイムラインの短縮

- ファブリックおよびサービス デバイス内のインフラストラクチャ マルチテナント

- サービス挿入設計の原則

- EPG 通信へのサービス グラフの適用

- サービス グラフのレンダリング

- 統合サポート機能

サービス挿入設計の原則

ACI のスパインリーフ アーキテクチャと総合的なファブリック管理という側面により、サービス デバイスに出入りするトラフィック フローはきわめて効率的に管理されるため、ネットワーク ファブリック内の特定の場所にデバイスを配置する必要はありません。サービス アプライアンスは物理的でも仮想でも可能であり、ACI ファブリックの管理下のいずれのリーフにも接続できます。該当する場合は、物理アプライアンスを複数のコンテキストモードで実行させ、ファブリック転送のマルチテナント マッピングや、テナント固有のサービス構成を可能にできます。

EPG 通信へのサービス グラフの適用

ACI ファブリック内のエンドポイント グループ間の通信を許可するには、コントラクトを正しい個所に設定する必要があります。このコントラクトは、指定したプロトコルおよびポートで定義した特定のコンシューマ/プロバイダーの関係という形式をとる場合があります。完全にオープンな通信を許可する「すべてを許可」というコントラクトである場合もあります。このコントラクトは、基本的に、エンドポイント グループ間の通信フローを制御します。また、サービス グラフをコントラクトに付加することによってサービス挿入を含めるように拡張できます。この場合、サービス グラフは、ポリシー ベースの構成を備えることで解決されたサービス デバイスにコントラクトを結び付けます。

サービス グラフのレンダリング

Cisco Application Centric Infrastructure (ACI) では、ユーザが次の方法でポリシーを定義できます。

- Application Policy Infrastructure Controller (APIC) GUI

- Python SDK（Cobra）

- RESTful API

これらのポリシー オブジェクトを作成、操作、再利用できます。レイヤ 4 ～ レイヤ 7 のサービスに関連することから、これらのオブジェクトは、アプリケーションに関してそのオブジェクトを使用することが目的であることを表します。

アプリケーション プロファイルが展開され、エンドポイントがリーフ スイッチに接続されると、サービス グラフのオブジェクトが特定のデバイスの設定に変換され、レンダリングと呼ばれるプロセスを通じてサービス デバイスにプッシュされます。また、APIC もネットワーク転送パスを設定し、適切な転送アクションが行われて、処理を行うためのサービス デバイスへのトラフィック フローが得られていることを確認します。

この構成管理の抽象化プロセスは、想定される動作を定義できるポリシー テンプレートのように機能し、2 つのエンドポイント グループをリンクし、それらの関係をポリシーに委ねます。このポリシーは、必要に応じてコピー、再利用、再パッケージ化できます。レンダリングには、ACI ファブリックとレイヤ 4 ～ レイヤ 7 デバイスの両方に必要な設定の割り当てと設定が含まれます。

多くの顧客と同様に、ACME にはファイアウォールすべてとロードバランシング サービスのためのいくつかのテンプレートがあります。これらのテンプレートの初期定義は手間がかかる可能性がありますが、その後でテンプレートを再利用すると、IP アドレス、ポート、オブジェクト グループなどの値を置き換えることで、非常に扱いやすくなります。

統合サポート機能

Cisco Application Centric Infrastructure (ACI) モデルでは、サービス デバイスとの通信がデバイス パッケージのインポートによってサポートされています。これらのデバイス パッケージには、デバイスの説明や公開された機能が備わっており、構成スクリプトのコンテンツも備えています。デバイス パッケージをインポートすると、デバイスで何が実行できるか、ファブリックにどのように接続するか、トラフィックをデバイスに送り込み、トラフィックをデバイスから戻すためのパスをどのように構築するか、ポリシーの意図をデバイス固有の構成にどのように変換するかがすべて ACI ファブリックにわかるようになっています。このデバイス パッケージは、製造元のベンダーからすぐに入手できるベンダー開発のパッケージです。

API を使用しているパートナーの最新リストは、次の URL で確認できます。

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/unified-fabric/aci_ecosystem.html

サービス導入ガイドの参考資料

次の図に、デバイスを統合しようとするときのレイヤ 4 ～ レイヤ 7 のサービスのワークフローの概要を示します。

レイヤ 4 ～ レイヤ 7 のワークフロー

レイヤ4〜レイヤ7サービスの展開については、を参照してください。『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』

『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 の主な内容は次のとおりです。

Device Types

Cisco Application Centric Infrastructure (ACI) は、次のようなさまざまな方法により、レイヤ 4 ～ レイヤ 7 デバイスの統合をサポートします。

- デバイス クラスタ

- Chassis Manager

- Device Manager

レイヤ 4 ～ レイヤ 7 デバイス クラスタは、最大 2 つの同じ設定のレイヤ 4 ～ レイヤ 7 デバイスからなるクラスタです。デバイス クラスタ内の個々のデバイスは具体的なデバイスと呼ばれます。レイヤ 4 ～ レイヤ 7 デバイス クラスタが管理対象の場合、Application Policy Infrastructure Controller (APIC) は具体的なデバイスと直接通信します。

仮想レイヤ 4 ～ レイヤ 7 デバイスは、より拡散型になるため、一部のベンダーの実装は、複数の仮想レイヤ 4 ～ レイヤ 7 サービスが実行されるシャーシ プラットフォームを提供します。適切なデバイス パッケージのサポートにより、ACI はシャーシ マネージャの実装と統合されて、仮想レイヤ 4 ～ レイヤ 7 サービス ソリューション全体が適切に設定されます。

ACI また、別々のデバイス マネージャ ソリューションを提供するレイヤ 4 ～ レイヤ 7 ベンダーの統合をサポートします。たとえば、F5 からの BIG-IQ ソリューションにより、BIG-IP ローカル トラフィック管理（LTM）モジュールとアプリケーション デリバリ コントローラ（ADC）の集中管理が提供されます。レイヤ 4 ～ レイヤ 7 デバイス マネージャが使用可能な場合、APIC は、レイヤ 4 ～ レイヤ 7 デバイス クラスタと直接通信するのとは対照的に、デバイス マネージャ プラットフォームと通信します。

デバイス モード

ACI で設定される各レイヤ 4 ～ レイヤ 7 デバイス クラスタは、管理対象または非管理対象のいずれかです。管理対象モードでは、ACI は、ACI ファブリックとレイヤ 4 ～ レイヤ 7 デバイスの両方を設定する役を担います。レイヤ 4 ～ レイヤ 7 デバイスは、基本的には、すべての設定が APIC GUI または RESTful API により管理されて、拡張された ACI ファブリックになります。レイヤ 4 ～ レイヤ 7 デバイスを非管理対象として設定すると、ACI では設定のファブリック部分のみが処理され、レイヤ 4 ～ レイヤ 7 デバイスの設定は、そのデバイスの従来の方法（GUI、CLI など）の対象として残されます。

次の表に、管理対象および非管理対象モードの違いの概要を示します。

モード

ファブリックの設定

レイヤ 4 ～ レイヤ 7 デバイスの設定

レイヤ 4 ～ レイヤ 7 デバイスの健全性モニタリング

Managed

あり

あり

あり

Unmanaged（管理されていない）

対応

非対応

非対応

デバイス パッケージのインポート

レイヤ 4 ～ レイヤ 7 サービスの統合プロセスを開始するため、『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 のこの項で示しているように、ACME によりベンダー/モデル固有のデバイス パッケージをインポートします。この手順は、レイヤ 4 ～ レイヤ 7 デバイスが管理対象モードで動作している場合のみ必要になります。

デバイスの作成

デバイス パッケージをインポートすると、論理デバイス クラスタを作成し、論理デバイスと具体的なデバイス間の関係を作成するプロセスを通じて、レイヤ 4 ～ レイヤ 7 デバイスが追加されます。これは、物理または仮想レイヤ 4 ～ レイヤ 7 デバイスによって実現されます。構成のステップは、物理デバイスと仮想デバイスによって若干異なりますが、かなり似ています。

デバイスの変更

『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 の該当する項で説明されているように、デバイス構成は GUI を使用して変更できます。

レイヤ 4 ～ レイヤ 7 のサービス グラフ テンプレートの作成

『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 の該当する項で、サービス グラフの作成方法を説明しています。

EPG へのサービス グラフ テンプレートの適用

アプリケーションのエンドポイント グループが作成された後、エンドポイント グループ間のサービス グラフ テンプレートを適用するプロセスは、『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 に記載されています。

サービス グラフのモニタリング

ACME 社がレイヤ 4 ～ レイヤ 7 サービス挿入用のサービス グラフの導入を済ませた後で、サービス グラフを観察するための要件が運用上の必須要件になります。これらの作業をサポートするには、以下に示すような、使用可能ないくつかのテクニックがあります。

- サービス グラフ インスタンスのモニタリング

- サービス グラフ フォールトのモニタリングと解決

- デバイス クラスタのモニタリング

- サービス インスタンスのモニタ グラフ

- サービス グラフフォールトのモニタリングと解決

- デバイス クラスタのモニタリング

サービス インスタンスのモニタ グラフ

サービス グラフ テンプレートが設定されてエンドポイント グループに接続されたコントラクトに関連付けられた後は、モニタリングに関して主に次の側面を考慮する必要があります。

- サービス グラフの状態

- グラフ インスタンスの機能

- 機能に割り当てられたリソース

- 機能に指定されたパラメータ

GUI を使用してサービス グラフのインスタンスをモニタするには、次の手順を実行します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [L4-L7 Services] > [Deployed Graph Instances] の順に選択します。[Work] ペインに、導入済みのサービス グラフのリスト、関連付けされたコントラクト、およびグラフ履歴の現在の状態など、導入済みのグラフのインスタンスに関する情報が表示されます。「適用済み」とは、グラフがすでに適用されており、ファブリックとサービス デバイスでアクティブであることを示します。

CLI を使用してサービス グラフのインスタンスをモニタするには、次の手順を実行します。

1. APIC の 1 つに対して SSH セッションを開きます。

2. show l4l7-graph コマンドを実行します。たとえば、テナント「tenant1」の「sg1」サービス グラフを表示するには、次のコマンドを入力します。

apic1# show l4l7-graph tenant tenant1 graph sg1
Graph           : sg1
Total Instances : 1

Consumer EPg  : uni/tn-tenant1/ap-app01/epg-epg-external
Provider EPg  : uni/tn-tenant1/ap-app01/epg-epg-internal
Contract Name : uni/tn-tenant1/brc-c1

Function Connector : consumer
Encap              : vlan-2150
BD                 : bd-external
Device             : uni/tn-tenant1/lDevVip-fw1

Function Connector : provider
Encap              : vlan-2152
BD                 : bd-internal
Device             : uni/tn-tenant1/lDevVip-fw1

3. show health l4l7-graph コマンドを実行して、導入されたグラフ インスタンスのヘルス スコアを表示します。次に例を示します。

apic1# show health l4l7-graph tenant seils graph sg1
Score  Change(%)  UpdateTS             Dn
-----  -----      -------------------  ------------------------------

可能な状態と関連する状態の詳細については、『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 を参照してください。

サービス グラフフォールトのモニタリングと解決

GUI を使用してサービス グラフのフォールトをモニタするには、次の手順を実行します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [L4-L7 Services] > [Deployed Graph Instances] の順に選択します。

4. モニタする導入済みのグラフ インスタンス を選択します。

5. [Work] ペインで、[Faults] タブを選択します。[Work] ペインに、アクティブなサービス グラフに関連するフォールトが表示されます。

CLI を使用してサービス グラフのフォールトをモニタするには、次の手順を実行します。

1. APIC の 1 つに対して SSH セッションを開きます。

2. show faults l4l7-graph コマンドを実行します。

リストされた障害と可能な解決法については、『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』 のサービス グラフの障害の解決に関する情報を参照してください。

デバイス クラスタのモニタリング

サービス グラフ テンプレートを設定して、エンドポイント グループ間のグラフを導入すると、テナントのサービス グラフに関連付けられたデバイス クラスタをモニタできます。デバイス クラスタのモニタリングでは、どのようなデバイス クラスタが関連付けられているか、どの VLAN がデバイス クラスタ用に構成されているか、どのような機能が使用中か、デバイスに渡されるのはどのような関数パラメータか、デバイスからはどのような統計情報が渡されるか、デバイス クラスタのデバイスの健全性はどうなのかが通知されます。

GUI を使用してデバイス クラスタをモニタするには、次の手順に従います。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [L4-L7 Services] > [L4-L7 Devices] の順に選択します。[Work] ペインには、フォールトや健全性に関するスコアなどのデバイス クラスタに関する情報が表示されます。

CLI を使用してデバイス クラスタをモニタするには、次の手順に従います。

1. Application Policy Infrastructure Controller (APIC) の 1 つに対して SSH セッションを開きます。

2. show l4l7-cluster コマンドを実行します。たとえば、テナント「tenant1」内のクラスタ「fw1」の設定を表示するには、次のコマンドを入力します。

rtp2-apic1# show l4l7-cluster tenant tenant1 cluster fw1
Device Cluster        : fw1
Total Graph Instances : 1
Active Graphs         : sg1
Encaps Used           : vlan-2150,vlan-2152

Graph Instance : 1
Consumer EPg   : epg-external
Provider EPg   : epg-internal
Contract Name  : c1
Graph Name     : sg1

Function Connector : consumer
Encap              : vlan-2150
pctag              : 16388
scope              : 2523138
Bridge-Domain      : bd-external
Contract Name      : c1
Graph Name         : sg1
Node Name          : N1
Device Interface   : fw1_Device_1([GigabitEthernet0/1]): vnic "Network adapter 3"

Function Connector : provider
Encap              : vlan-2152
pctag              : 32773
scope              : 2523138
Bridge-Domain      : bd-internal
Contract Name      : c1
Graph Name         : sg1
Node Name          : N1
Device Interface   : fw1_Device_1([GigabitEtnernet0/0]): vnic "Network adapter 2"

3. デバイス クラスタの健全性を表示するには、show health l4l7-cluster コマンドを実行します。

4. デバイス クラスタのフォールトを表示するには、show faults l4l7-cluster コマンドを実行します。

ASAv サンプル構成

ACME 社が統合するサービス ノードの 1 つに、単一ノードでルーテッド ファイアウォー モードの ASAv があります。この例では、ASAv ファイアウォール仮想サービス アプライアンスをルーテッド モードの単一ノードとして構成するために従ったプロセスについて詳しく説明します。ルーテッド ノードとして、ASAv は、このサービス グラフが関連付けられるコントラクトによって接続される 2 つのエンドポイント グループにあるホストのデフォルト ゲートウェイです。

手順の概要は次のとおりです。

- 論理および具体的なデバイス クラスタを作成します。

- ファイアウォール ルール セットまたはグラフを定義します。

- 2 つのエンドポイント間にグラフを導入します。

- ASAv 仮想マシン構成の確認

- 関連するファブリックのブリッジ ドメインからのゲートウェイ IP アドレスの削除

- レイヤ 4 ～ レイヤ 7 のデバイスの作成

- レイヤ 4 ～ レイヤ 7 サービス グラフ テンプレートの作成

- サービス グラフ テンプレートの適用

- サービス ノード構成の確認

ASAv 仮想マシン構成の確認

実行する最初の一連のステップでは、ASAv 仮想マシンの構成を確認し、ASA デバイス パッケージをアップロード（またはすでにアップロードしている場合は確認）します。

1. ASAv VM にログインします。

2. イネーブル モードを開始します。

3. 次のコマンドを入力します。

ciscoasa# show interface ip brief

4. ASAv に、管理 0/0 インターフェイスの適切な IPv4 アドレスがあることを確認します。

5. Application Policy Infrastructure Controller (APIC) から ASAv の管理 0/0 インターフェイスへの接続を確認します。

1. APIC の 1 つに対して SSH セッションを開きます。

2. 次のコマンドを入力します。

apic1# ping ASAv_Management0/0_interface_IP_address

3. 返される応答は、次の例のようになります。

64 bytes from 172.16.10.10: icmp_seq=1 ttl=64 time=0.050 ms

応答が違う場合は、接続に何らかの問題がある可能性があります。続行する前に接続の問題を解決します。

6. GUI のメニュー バーで、[L4-L7 Services] > [Packages] の順に選択します。

7. [Navigation] ペインで、[L4-L7 Service Device Types] を展開します。

8. ASA デバイス パッケージが表示されない場合は、次の操作を実行します。

1. [L4-L7 Services Device Types] を右クリックします。

2. [Import Device Package] を選択します。

3. プロンプトに従ってデバイス パッケージをアップロードします。

関連するファブリックのブリッジ ドメインからのゲートウェイ IP アドレスの削除

ASAv パッケージと VM が確認された後の次のステップでは、ファブリックのブリッジ ドメインからブリッジ ドメインまたはゲートウェイ IP アドレスを削除して、レイヤ 3 のルーテッド ファイアウォールがデフォルト ゲートウェイになるようにします。

EPG1 および EPG2 のブリッジ ドメイン上のルーティング デフォルト ゲートウェイ機能を削除するには、次の手順に従います。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Networking] > [Bridge Domains] > [BD-EPG1] の順に選択します。

4. [Work] ペインで、次の操作を実行します。

1. [L2 Unknown Unicast] オプション ボタンで [Flood] をクリックします。

2. [L3 Configurations] タブで、[Unicast Routing] チェックボックスをオフにします。

3. [Submit] をクリックします。`

影響を受けるエンドポイント グループのブリッジ ドメインに対してこのプロセスを繰り返します。

レイヤ 4 ～ レイヤ 7 のデバイスの作成

次のステップを実行し、論理クラスタと具体的なデバイス クラスタをテナントに追加します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、 [Tenant][Tenant_Name] > [L4-L7 Services] > [Function Profiles] の順に選択します。

4. [Work] ペインで [Create Profile Group] をクリックします。

5. [Create a L4-L7 Function Profile] ダイアログボックスで、次の操作を実行します。

1. 「TXX-FP-Group」など、テナントや機能に関連する名前を入力します。

2. [Navigation] ペインで機能プロファイル グループを選択します。

3. 機能プロファイル グループを右クリックし、[Create L4-L7 Services Function Profile] を選択します。

4. 「TXX-ASAv-Profile」など、わかりやすい名前を入力します。

5. [Profile] ドロップダウン リストで [WebPolicyForRoutedMode] を選択します。

6. [Feature and Parameters] セクションで、[All Parameters] タブを選択します。外部インターフェイスと内部インターフェイス（externalIf と interalIf）の両方の [Interface Related Configuration] の下にある IP アドレスを構成します。

7. externalIf の [Interface Related Configuration] を展開します。

8. [Interface Specific Configuration] を展開します。

9. [IPv4 Address Configuration] を展開します。

10. [IPv4 Address] をダブルクリックします。

11. 「a.b.c.d/m.n.o.p」形式で IPv4 アドレスを入力します。

12. [Update] をクリックします。

13. internalIf インターフェイスで、ステップ 4f ～ 4j を繰り返します。

6. [L4-7 Services] > [Function Profiles] > [ALL PARAMETERS] の順に選択します。

7. 外部インターフェイスと内部インターフェイスの IPv4 アドレスを確認します。

次のステップで、レイヤ 4 ～ レイヤ 7 のデバイスを作成します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [L4-L7 Services] > [L4-L7 Devices] の順に選択します。

4. [Work] ペインで [Create L4-L7 Devices] をクリックします。

5. [Create a L4-L7 Devices] ダイアログボックスで、次の操作を実行します。

1. 「Txx-ASAv-Cluster」など、わかりやすい名前を入力します。

2. Device Package：CISCO-ASA-1.x Model：ASAv

3. Mode：Single Node

4. Function Type：Goto

5. Connectivity VMM Domain：Txx-vCenter

6. APIC to Device：Out of Band

7. Credentials: username_and_password

8. [Device 1] の下に次の値を設定します。

1. Management IP address：ASAv IP address

2. Management Port：https

3. VM：Tenant ASAv Controller（ドロップダウン ボックス）

4. Virtual Interfaces：2 つのエントリを作成し、[+] を 2 回クリックし、インターフェイスの値を次のように入力します。

1. Name：GigabitEthernet0/0 vNIC：Network Adapter 2 Direction：provider

2. Name：GigabitEthernet0/1 vNIC：Network Adapter 3 Direction：consumer

5. 各エントリの後に [UPDATE] をクリックします。

6. [NEXT] をクリックします。

7. [FINISH] をクリックします。

論理および具体的なデバイス クラスタが構成されていることを確認します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [L4-L7 Services] > [L4-L7 Devices] の順に選択します。

4. [TXX-ASAv-Cluster] と [TXX-ASAv-Cluster_Device_1] の両方を展開し、論理インターフェイスと物理インターフェイスを表示します。

5. [TXX-ASAv-Cluster_Device_1] を選択し、具体的なデバイスのグラフィック ビューを表示します。

注：これで論理デバイスと具体的なデバイスの作成が完了します。

レイヤ 4 ～ レイヤ 7 サービス グラフ テンプレートの作成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. ナビゲーション ウィンドウで [Tenant_Name] > [L4-L7 Services] > [L4-L7 Service Graph Templates] を選択します。

4. [Work] ペインで、[Actions] > [Create a L4-L7 Service Graph Template] の順に選択します。

5. [Create a L4-L7 Devices] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドに「TXX-ASAv-L3-Routed-Template」と入力します。

2. [Type] ドロップダウンリストで、[Single Node - Firewall in Routed Mode] を選択します。

3. [Device Function] ドロップダウンリストで、[CISCO-ASA-1.x/Firewall] を選択します。

4. [Profile] ドロップダウンリストで、[TXX-ASAv-FP] を選択します。これは、事前に作成しておいた機能プロファイルです。

5. [Submit] をクリックします。`

6. [Tenant_Name] > [L4-L7 Services] > [L4-L7 Service Graph Templates] > [Txx-ASAv-L3-Routed-Template] > [Function Node - Firewall] を展開すると、テンプレートが正常に作成されたかを確認できます。

サービス グラフ テンプレートの適用

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. ナビゲーション ウィンドウで [Tenant_Name] > [L4-L7 Services] > [L4-L7 Service Graph Templates] を選択します。

4. [Txx-ASAv-L3-Routed-Template] を右クリックし、[Apply L4-L7 Service Graph Template] を選択します。

5. [Apply L4-L7 Service Graph Template to EPGs] ダイアログボックスで、次の操作を実行します。

1. [Consumer EPG / External Network] ドロップダウンリストで、[EPG1] を選択します。

2. [Provider EPG / External Network] ドロップダウンリストで、[EPG2] を選択します。

3. [Service Graph Template] ドロップダウンリストで、[Txx-ASAv-L3-Routed-Template] を選択します。

4. [Contract] オプション ボタンの [Create A New One] をクリックします。

5. [No Filter (Allow All Traffic)] チェックボックスをオンにします。

6. [Contract Name] フィールドに「TXX-EPG1-to-EPG2」と入力します。

7. [Next] をクリックします。

8. [L4-L7 Devices] ドロップダウンリストで、[Txx-ASAv-Cluster] を選択します。

9. [Features and Parameters] セクションで、[All Parameters] タブを選択します。

10. [Device Config] > [Interface Related Configuration externalIf] > [Access Group] > [Inbound Access List] をダブルクリックします。

11. [Value] ドロップダウン リストで [access-list-inbound] を選択します。

12. [Update] をクリックします。

13. [Device Config] > [Interface Related Configuration externalIf] > [Interface Related Configuration] を展開し、IP アドレスの割り当てを確認します。マスクがない場合、その構成は ASA にプッシュされません。

14. [Device Config] > [Interface Related Configuration internalIf] > [Access Group] > [Inbound Access List] をダブルクリックします。

15. [Reset] をクリックします。これにより、内部インターフェイスからのインバウンドのアクセス リストの割り当てが解除されます。このインバウンドのアクセス リストは、ラボ トラフィック フローには適していません。

16. [Device Config] > [Interface Related Configuration internalIf] > [Interface Specific Configuration] を展開し、IP アドレスの割り当てにマスクがあることを確認します。

17. [Finish] をクリックします。Devices Selection Polices フォルダと Deployed Graph Instances フォルダに読み込みが行われます。

6. [TXX-EPG1-to-EPG2-TXX-ASAv-L3-Router-Template-TXXProduction] を選択します。コンシューマ EPG およびプロバイダー EPG と　EPG1 および EPG2 のサーバ EPG との関連付けを確認できます。

サービス ノード構成の確認

デバイスが統合され、サービス グラフが構成されて関連付けられたら、実際にサービス ノードとして動作している デバイス上で簡単な show コマンドを使用するとサービス ノードに展開された結果の設定を確認できます。

APIC から展開されたアクセス リスト構成の表示

アクセス リストの検証を行うための ASAv サービス ノードへの SSH。次のコマンドを発行します。

ciscoasa# show access-list

これにより、アクセス リストの構成が表示されるため、その構成を APIC で実行された構成に関連付けられます。

APIC から展開されたインターフェイスの設定の表示

インターフェイス設定の検証を行うための ASAv サービス ノードへの SH。次のコマンドを発行します。

ciscoasa# show interface ip brief

これにより、IP アドレスが APIC から展開されたインターフェイスの設定が表示されます。

現在のインターフェイス名の表示

インターフェイス名構成の検証を行うための ASAv サービス ノードへの SSH。次のコマンドを発行します。

ciscoasa# show nameif

これにより、APIC からプッシュされたインターフェイス名が表示され、上記の APIC で設定された論理インターフェイス名に関連付けられたインターフェイス名が表示されます。

Chapter8. ヘルススコア

- ヘルススコアの概要

- フォールトの概要

- ヘルススコアの計算方法

ヘルススコアの概要

ACME の運用チームは、自分たちが担当するシステムの現在のステータス、パフォーマンス、および可用性に関する基本的な質問への回答にいつも苦戦していました。このような難しい問題に対処するために、運用チームは Cisco Application Centric Infrastructure (ACI) を利用できるようになりました。このインフラストラクチャはステータス、パフォーマンス、可用性に関する情報を提供するヘルス スコアを提供します。このような回答を提供することは、独立したデバイスやリンクに関連付けられていれば簡単である一方で、この情報自体は、ネットワークの健全性全体への影響に関する追加データがなければ、ほとんど、またはまったく価値はないということです。情報を手動で収集して関連付けるために、以前は長時間に及ぶ面倒な作業が必要でしたが、ヘルススコアにより、 Application Policy Infrastructure Controller (APIC) でファブリック全体のデータがリアルタイムで収集、計算、関連付けされて、理解可能な形式で表示されます。

従来のネットワークのモニタリングと管理システムは、プロビジョニングされたインフラストラクチャのモデルを提供して、さまざまなデバイスとリンク間の関係を説明しようとします。ACI の中心のオブジェクト モデルはインフラストラクチャに固有です。したがって、単一の統合されたヘルス スコアは、リンク、デバイス、それらの関係、使用率のリアルタイムのステータス、システムの全体または一部の現在のステータスの評価の概要を含む、すべてのオブジェクトの現在のステータスを表示します。この可視性には多くの実用的な使用例があります。この章では、これらの使用例を事後対応型と予防型に分類します。ACI はまた、ヘルススコアの計算方法や、さまざまな障害がヘルススコアの計算に与える影響について、いくつかの側面を柔軟に監視できます。

モデル内のほとんどのオブジェクトがヘルススコアに関連付けられますが、これらは、ダッシュボードや、GUI を使用してオブジェクトの [Policy] タブで検出できます。ファブリック全体の状態を確認するには、APIC GUI で、[System] > [Dashboard] に移動します。以下の情報を確認できます。

- コントローラのヘルス状態

- ヘルスが 99 未満であるノード

- ヘルスが 99 未満であるテナント

- ヘルス グラフはシステムのヘルス スコアを一定期間にわたって表示します

ヘルス グラフは、システムの問題をよく示しています。システムが安定していれば、グラフは一定です。それ以外の場合は変動します。

さらに、すべてのヘルス スコアを healthInst クラスからインスタンス化して、API を通じて抽出できます。

対応型の機能では、ACI ヘルス スコアは、新しく発生した問題によってすぐにヘルス スコアが低下する、簡単なチェックを提供します。問題の根本原因は、エラーを見ることで確認できます。また、ヘルススコアは、フォールトが発生した場合にリアルタイムの相関も提供し、そのフォールトによって影響を受けるテナント、アプリケーション、および EPG に関するフィードバックを直ちに提供します。

ほぼすべてのオブジェクトとポリシーには [Health] タブがあります。たとえば、特定の EPG にエラーがあるかどうかを確認するには、[Tenants] > [APIC GUI] > [Tenants] > [Tenant] > [Application Profile] > [YourProfile] > [YourEPG] に移動します。[Work] ペインで、[Health] タブを探します。[History] > [Health] の下の [Health] タブにアクセスできます。このタブには、影響を受けるオブジェクトと、それが大きなモデル内でどのように関連付けられているかが示されます。[+] をクリックすると、影響を受けるオブジェクトまたはポリシーのヘルス ツリーを調査してエラーを確認できます。

フォールトのあるオブジェクト

ACI のヘルススコアは、ハードウェア リソース、帯域幅使用率、その他のキャパシティ プランニング業務に関し、予防的にボトルネックとなる可能性の特定に役立ちます。また、顧客やユーザが影響を受ける前に、運用チームが問題を特定できる可能性も高くなります。

すべてのアプリケーションとインフラストラクチャ コンポーネントのヘルスは常に 100% であるのが理想です。ただし、データセンター環境の動的な性質を考えると、これは現実的であるとは限りません。リンクは、機器、およびエンドポイントにはフォールトがあります。代わりに、ヘルススコアは、所定のコンポーネントのヘルススコアの平均が時間とともに高くなることを目標として、時間とともに変化するメトリックとして表示される必要があります。

NX-OS スタイルの CLI を使用したヘルス スコアの表示

NX-OS スタイルの CLI を使用して、特定のオブジェクトの状態を表示できます。

テナントの状態を表示するには、次の手順を実行します。

show health tenant tenant

ナント ブリッジ ドメインの状態を表示するには、次の手順を実行します。

show health tenant tenant bridge domain bd

テナント内のアプリケーションのエンドポイント グループの状態を表示するには、次の手順を実行します。

show health tenant tenant application app epg epg

リーフの状態を表示するには、次の手順を実行します。

show health leaf leafnode

次の例では、テナント「tenant1」の状態が表示されます。

apic1# show health tenant tenant1
Score  Change(%)  UpdateTS               Dn
-----  -----        -------------------  ------------------------------
100      0            2015-11-13T18:23:14  uni/tn-pineapple/health
.767-08:00

次の例では、リーフ 101 の状態が表示されます。

apic1# show health leaf 101
Score  Change(%)  UpdateTS             Dn
-----  -----      -------------------  ------------------------------
72       10         2015-11-11T12:55:52  topology/pod-1/node-101/sys/health
.847-08:00

iShell を使用したヘルス スコアの表示

iShell を使用して、特定のオブジェクトの状態を表示できます。

APIC のヘルスを表示するには、次の手順を実行します。

show health controller ID

スイッチの状態を表示するには、次の手順を実行します。

show health switch node

次の例では、スイッチ 101 の状態が表示されます。

admin@apic1:~> show health switch 101
Current Score  Previous Score  Timestamp                Dn
-------------  --------------  ---------------------  -------------------
72                65                2015-11-                 topology/pod-1/
11T12:55:52.847-08:00  node-101/sys/health

フォールトの概要

管理という観点から、Application Policy Infrastructure Controller (APIC) を 2 つの視点から検討します。

1. ポリシー コントローラ：すべてのファブリック構成が作成され、管理され、適用されている場合。管理状態または構成状態の、総合的で最新のランタイム表示を維持します。

2. テレメトリ デバイス：Cisco Application Centric Infrastructure (ACI) ファブリック内のすべてのデバイス（ファブリック スイッチ、仮想スイッチ、統合レイヤ 4 ～ レイヤ 7 のデバイス）がフォールト、イベント、統計情報を APIC に報告します。

ACI ファブリック内のフォールト、イベント、および統計情報は、ACI オブジェクト モデル/管理情報ツリー（MIT）全体ないの管理対象オブジェクト（MO）の集合体として表されます。フォールトを含めて ACI 内のすべてのオブジェクトを照会できます。このモデルでは、フォールトは、可変でステートフルな永続的 MO として表されます。

フォールトのライフサイクル

コンポーネントのフォールトやアラームなど、特定の状態が発生した場合は、システムはフォールト MO を、その MO の子オブジェクトとして作成し、基本的にそのフォールトに関連付けます。フォールトオブジェクト クラスでは、親オブジェクト クラスのフォールトルールによりフォールト状態が定義されます。フォールト MO は、親、DN、RN などを持つ通常の MO として MIT に表示されます。フォールト「コード」は、FXXX 形式の英数字文字列です。フォールトコードの詳細については、『Cisco APIC Faults, Events, and System Messages Management Guide』を参照してください。

次の例に、「3tierapp」というテナントのヘルススコアを返す、ファブリックへの REST クエリを示します。

https://hostname/api/node/mo/uni/tn-3tierapp.xml?query-target=self&rsp-subtreeinclude=
health

次の例に、「3tierapp」というテナントの統計情報を返す、ファブリックへの REST クエリを示します。

https://hostname/api/node/mo/uni/tn-3tierapp.xml?query-target=self&rsp-subtreeinclude=
stats

次の例に、リーフ ノードのフォールトを返す、ファブリックへの REST クエリを示します。

https://hostname/api/node/mo/topology/pod-1/node-103.xml?query-target=self&rspsubtree-
include=faults

ご覧のように、MO はプロパティ フィルタ、改ページなどを使用し、クラスや DN 別に照会できます。

ほとんどの場合、フォールト MO は特定の状態が検出されたときに、システムによって自動的に作成、エスカレーション、エスカレーション解除、および削除されます。MO には、所定のコードを持つフォールトが最大で 1 つある可能性があります。対応するフォールト MO がアクティブな間にある条件が複数回検出された場合は、その MO に新たなインスタンスが作成されることはありません。つまり、同じ状態が、影響を受ける同じオブジェクトで複数回検出された場合は、そのフォールトの再発を示すカウンタは増えるものの、発生するのは 1 つのフォールトだけです。フォールト状態がクリアされるまでは、フォールト MO はシステムに残ります。フォールトを排除するには、構成によって、またはファブリックの実行時状態を変更することによってのいずれかで、そのフォールトを発生させている状態を解消する必要があります。フォールトが解消された状態またはそのままの状態にあり、その場合にそのフォールトをユーザが確認することで削除できる場合は例外です。

重大度は、サービスを提供するシステムまたはコンポーネントの能力の状態への予測される影響力を示します。

値は次のとおりです。

- Warning（ほとんど影響しない）

- Minor

- Major

- Critical（システムまたはコンポーネントが完全に使用できなくなる）

フォールト MO の作成が、以下のような内部プロセスによって引き起こされる可能性があります。

- 有限状態マシン（FSM）の遷移、またはコンポーネントフォールトの検出

- さまざまなフォールトポリシーによって指定された状態（一部はユーザによる構成が可能）

たとえば、ヘルススコア、データ トラフィック、温度などの統計的な測定値にフォールトしきい値を設定できます。

ヘルススコアの計算方法

ヘルススコアは、システム全体の全体的ヘルススコアだけでなく、システムやポッド、テナント、管理対象オブジェクト（スイッチやポートなど）にもあります。すべてのヘルススコアは、適用するフォールトの数と重大度を使用して計算されます。システムやポッドのヘルススコアは、リーフヘルススコアの加重平均であり、確認されたエンドポイントの総数で除算し、スプライン数とそれらのヘルススコアから派生したスプライン係数で乗算して求められます。つまり、次のようになります。

健全性のスコアの計算

テナントのヘルススコアは似ていますが、それにはテナント内の論理コンポーネントのヘルススコアが含まれています。たとえば、そのテナントに含まれているエンドポイントだけで加重されます。

これらすべてのスコアがどのように集計されるかは、管理対象オブジェクトのスコアの計算方法、つまり、それらの関連付けられたフォールトによって直接的に計算されるかを検討することによって確認できます。フォールトはそれぞれ、重大度のレベルによって加重されます。クリティカルなフォールトは 100 % の高いフォールトレベルになる可能性もありますが、警告（Warining）では、20 % 程度の低いフォールトレベルもあります。影響力がないとされたフォールトは、0 % の値に再割り当てされる場合もあります。その場合はヘルススコアの計算には影響を与えません。

幸いにも、ヘルススコアを有効に使用するための計算を理解する必要はありません。しかし、フォールトのレベルが高なのか、中なのか、低なのか、または「なし」なのかの基本的な知識は必要です。ACI のフォールトがデフォルトの値であっても、それらの値を自身の環境にさらに適合させる値に変更できる可能性があります。

ロールベース アクセス コントロールのため、すべての管理者がすべてのヘルススコアを表示できるわけではないことに注意してください。たとえば、ファブリック管理者はすべてのヘルススコアを表示できますが、テナント管理者は自分がアクセスできるテナントに関連するヘルススコアだけしか表示できません。ほとんどの場合、テナント管理者は、自分が確認できるヘルススコアまでドリルダウンできる必要がありますが、複数のテナントに影響を及ぼすフォールトが発生することもあります。この場合は、ファブリックの管理者がトラブルシューティングを開始する必要があります。テナント管理者とファブリック管理者は、レイヤ 4 からレイヤ 7 のファイアウォール、ロード バランサ、侵入防御/検知システムなどのデバイスのヘルススコアも表示できます。これらは、WMM ドメイン内のフォールトとともに、テナント、ポッド、およびシステム全体のヘルススコアにすべてまとめられます。

フォールトの使用方法の詳細については、『Troubleshooting Cisco Application Centric Infrastructure（http://aci-troubleshooting-book.readthedocs.org/en/latest/）』を参照してください。

予防的モニタリングへの健全性のスコアの使用

ACME の管理者は従来、ネットワークに関する問題の対応に多くの時間を費やしてきましたが、ACI のヘルススコアを使用すると、問題の防止に着手できるようになります。ヘルススコアはフォールトのインジケータとして機能するだけでなく、後で比較を行うために必要な基準となります。リーフ スイッチの 1 つが 1 週間にわたって 100 %（良好を示す緑）であったにもかかわらず、次の週にはリーフが警告を示している場合は、何が変化したかを確認するためドリル ダウンすることができます。このシナリオでは、リンクがオーバーサブスクライブされているため、一部のワークロードを別のリーフに移動するか、接続するケーブルを増やして帯域幅を追加するかの時期である可能性があります。これはまだ警告にすぎないため、ネットワーク上のボトルネックが顕著になる前に問題を解決する時間があります。

過負荷になりつつあるロード バランサやファイアウォールでも同じシナリオが見られることがあります。このような場合は、別のロード バランサまたはファイアウォールを追加したり、さらにはルールの最適化が、トラフィック フローを効率化するために必要な場合があります。前述の例のように、キャパシティ プランニング ツールとしてこの基本的な方法を使用できます。

ヘルススコアを ACI 環境の予防的な監視に使用できる他の方法として、特定のコンポーネントの可視性を別のグループに付与することがあげられます。スコアとフォールトはエクスポートできるため、これらの通知をアプリケーション所有者、VMware 管理者、データベース管理者などに送信できます。これにより、これまでに使用できず、また、他の手段では取得できないネットワーク全体の環境のモニタリングが実現します。

対処的モニタリングへのヘルススコアの使用

対応処理として、ヘルススコアを使用して ACI ファブリックの問題を診断できます。ヘルススコアが低下したことを示す通知により、オペレータは GUI を使用して、そのヘルススコアに寄与している関係やフォールトに簡単に移動できます。根本原因となっているフォールトが特定されると、そのフォールト自体に可能な修復ステップに関する情報が含められます。

ほとんどのオブジェクトには [Health] タブがあり、それを使用してオブジェクト間の関係や関連するフォールトを調査できます。これにより、「根本原因を突き止めるためにダブルクリックする」機能が得られます。

Chapter9. モニタリング

- 予防的モニタリング：テナントおよびファブリックのポリシー

- スイッチの CPU 使用率のモニタリング

- スイッチのメモリ使用率のモニタリング

- ファイル システムの健全性のモニタリング

- CoPP（コントロール プレーン ポリシング）統計情報のモニタリング

- 物理インターフェイス統計情報とリンク ステート

- Module Status

- スイッチ ファンのステータス

- スイッチの電源ステータス

- LLDP ネイバーのステータス

- CDP ネイバーのステータス

- GOLD 診断結果

- 対応型モニタリング

- 対応型モニタリングの使用例

予防的モニタリング：テナントおよびファブリックのポリシー

予防的モニタリングは、ネットワーク管理者の仕事の中でも重要なものですが、通常はネットワーク内の問題の解決が優先されるため、多くの場合は無視されています。しかし、Application Policy Infrastructure Controller (APIC) では統計情報の収集や分析の実行が非常に簡単に行えるため、ネットワーク管理者の時間もフラストレーションも抑えられます。統計情報は自動的に収集され、ポリシーが使用されるとともに、他の場所でも再利用できるため、人為的なミスや手間は最小限に留まります。

統計情報の収集はこれまでACME にとっては、手作業のリソース集中型でさえあるプロセスでした。レイヤ 1 から 7 のデバイスに関する情報を収集するツールを使用していたとしても、監視すべきデバイスや監視する方法を手動で指定する必要がありました。たとえば、SNMP やサード パーティのツールを使用してスイッチの CPU やポート上の帯域幅の使用率を監視していても、デバイスごとの正確な SNMP 情報の入力に苦労したり、ネットワーク管理システム（NMS）に新しいデバイスを追加し忘れることも頻繁にありました。 Cisco Application Centric Infrastructure (ACI) は、統計情報の収集をすべて行う APIC を提供し、サード パーティのモニタリング ツールを維持するすべての手間を省いて、環境全体を予防的に監視する機能を提供します。

GUI、CLI、または API のいずれかからアクセスしたとしても、APICを使用してコンポーネントまでドリルダウンして、オンデマンドで統計情報を表示する [Stats] タブをクリックすることができますが、それよりも、永続データを環境内のトレンドを分析するとともに、発生する可能性がある問題をトラブルシューティングまたは予測するために保持するようにポリシーを設定できることが重要です。レガシー システムから ACI インフラストラクチャへのアプリケーションの移動を計画する場合は、実稼働に直接進む前にテストから開始するほうが賢明です。APIC に関連付けられている DVS または AVS のいずれかのポート グループにテスト用の VM を追加し、リーフ スイッチの VPC に物理的なテスト用サーバを追加します。また、これは、実稼働環境から完全に分離されているテスト テナントにもなり得ます。この時点で、APIC はすでに VMM ドメインと物理デバイスの統計情報を収集しています。次のステップでは、トレンド分析用のポリシーを構成します。

統計情報の収集には、共通またはファブリック全体、ファブリック、テナント、アクセスの 4 つの異なる範囲があります。ファブリック全体のポリシーは、すべてのテナントに適用されるデフォルトのポリシーとして作成されます。ただし、特定のテナントのそのポリシーをオーバーライドすると、テナントのポリシーがファブリック ポリシーをオーバーライドすることになります。次のテスト例では、統計情報を収集するために、テナント ポリシーが作成されます。このテナントが他のアプリケーション、顧客、テスト ケースと共有されているとしても、実稼働環境でアプリケーションがどのように動作するかの実際の例を提供します。

- テナント モニタリング ポリシーの作成

- 統計情報収集ポリシー

- 統計情報のエクスポート ポリシー

- GUI を使用した診断ポリシー

- Call Home/SNMP/syslog

- イベントの重大度とフォールトの重大度の割り当て

- フォールトライフサイクル ポリシー

- TCAM ポリシーの使用

- ヘルススコアの評価ポリシー

- 通信ポリシー

テナント モニタリング ポリシーの作成

テナント モニタリング ポリシーを作成方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Monitoring Policies] の順に選択します。

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

5. [Create Monitoring Policies] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドにモニタリング ポリシーの名前を入力します。

2. [Submit] をクリックします。`

6. [Navigation] ペインで、 [Tenant_Name] > [Monitoring Policies] > [Policy_Name] を選択し、次の情報を表示します。

- 統計情報収集ポリシー

- 統計情報のエクスポート ポリシー

- Callhome、SNMP、および syslog

- イベントの重大度の割り当てポリシー

- フォールトの重大度の割り当てポリシー

- フォールトライフサイクル ポリシー

統計情報収集ポリシー

[Stats Collection Policies] をクリックすると、すべての監視対象オブジェクトのデフォルトの保持期間と管理状態（Enabled/Disabled）が表示されます。ほとんどの場合は、デフォルトが保持されますが、それらをダブルクリックすると管理状態や保持期間が変更されます。たとえば、5 分ごとにコンポーネントをポーリングさせ、2 時間保持するには、5 分の粒度を指定するポリシーをクリックし、保持期間を 2 時間に変更します。同様に、特定のモニタリング オブジェクトのポリシーを変更することもできます。モニタリング オブジェクトは、統計情報を収集するコンポーネントを APIC に通知します。たとえば、ブリッジ ドメインについて収集される情報を変更するには、ブリッジ ドメイン（infra.RSOInfraBD）モニタリング オブジェクトを使用します。

モニタリング オブジェクトを追加する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、[Tenant_Name] > [Monitoring Policies] > [Monitoring Policy_Name] > [Stats Collection Policies] の順に選択します。

1. 鉛筆のアイコンをクリックし、モニタリング オブジェクトを編集します。

2. 含めるモニタリング オブジェクトの横にチェックマークを入れ、そのまま残すモニタリング オブジェクトのチェックマークはすべて外します。

3. [Submit] をクリックします。`

この例では、テナント、VXLAN プール、リーフ ポート、またはタブーコントラクトのモニタリング オブジェクトのポリシーに変更が加えられる場合があります。複数のオプションがあります。また、環境内で何をモニタリングすることが重要なのかによってすべて異なります。プルダウン メニューをクリックし、モニタリング オブジェクトを選択して、それに保持ポリシーを追加します。

モニタリング オブジェクトにポリシーを追加する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、[Monitoring Policies] > [Monitoring Policy_Name] > [Stats Collection Policies] の順に選択します。

4. [Work] ペインの [Stats Collection Policy] ダイアログボックスで、次の操作を実行します。

1. [Monitoring Object] を選択します。

2. [+] をクリックしてポリシーを追加します。

3. ポーリングする頻度を選択します。

4. 状態を継承されたままにして [ALL] に設定されるようにデフォルトを維持するか、[enabled] または [disabled] を明示的に選択します。

5. 保持ポリシーは継承するか、明示的に有効または無効に指定することもできます。

6. [更新（Update）] をクリックします。

統計情報のエクスポート ポリシー

これらの継続的な統計情報を収集するとともに、このデータが時間の経過とともにどのように動作するかを確認することが推奨されています。モニタリング ポリシーの下にある左側のナビゲーション ペインの [Stats Export Policies] オプションを使用します。統計情報収集ポリシーと同様に、すべてのモニタ オブジェクトのポリシーを作成するか、特定のモニタリング オブジェクトを選択してこの情報の保存場所を指定することができます。

統計情報のエクスポート ポリシーの作成方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. [Navigation] ペインで、 [Tenant_Name] > [Monitoring Policies] > [Monitoring Policy_Name] > [Stats Export Policies] の順に選択します。

4. [Work] ペインの [Stats Export Policy] ダイアログボックスで、次の操作を実行します。

1. ドロップダウンリストから [ALL] を選択するか、特定のモニタリング オブジェクトを指定します。

2. [+] をクリックしてポリシーを追加します。

3. [Stats Export Policy] をウィザードで定義します。

4. 形式として [JSON] か [XML] のいずれかを選択します。形式が異なるだけで内容に違いはありません。また、読み取りに使用するツールによってどちらの形式を使用したほうが良いか異なります。

5. GZIP を使用して圧縮するか、圧縮せずにそのままにするかを選択します。

6. [Export Destinations] の下にある [+] をクリックし、この情報を収集するサーバを指定します。このサーバへの接続に使用するプロトコルと認証情報を指定する別のウィザードがポップアップします。

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

5. [送信（Submit）] をクリックします。

GUI を使用した診断ポリシー

診断のポリシーは、左側の [Navigation] ペインにあります。この機能により、統計情報収集ポリシーに指定したモニタリング オブジェクトの診断テストを設定することができます。モニタリング オブジェクトの横にある 鉛筆アイコンで、診断ポリシーを使用して構成するモニタリング オブジェクトを選択します。ブートアップ診断と動作時診断の 2 種類のポリシーを構成できます。

診断ポリシーの構成方法：

1. メニュー バーで、[Fabric] > [Fabric Policies] の順に選択します。

2. ナビゲーション ウィンドウで、 [Tenant_Name] > [Monitoring Policies] > [Diagnostics Policies] を選択します。

3. [Work] ペインの [Diagnostic Policies] ダイアログボックスで、次の操作を実行します。

鉛筆アイコンをクリックし、診断テストを追加するモニタリング オブジェクトの横にあるチェックボックスをオンにします。

1. モニタリング オブジェクトのいずれかを選択します。

2. [+] をクリックしてオブジェクトを追加します。

1. [Boot-Up] または [Ongoing] のいずれかを選択します。

2. [Boot-Up] はデバイスがブートされている間にテストを実行し、[Ongoing] はウィザード内で指定した頻度でテストを実行します。

3. ウィザードで名前を付け、管理状態を選択します。

4. ASIC、CPU、内部接続、周辺機器、システム メモリの 5 種類の診断テストが使用できます。それぞれをダブルクリックして、テストなし、完全テスト、または推奨テストを指定するオプションを取得します。

5. [送信（Submit）] をクリックします。

ここにある診断は、環境内で大きな問題となる前に、フォールトが発生したコンポーネントを検出するのに役に立つ可能性があります。

Call Home/SNMP/syslog

通知またはアラート ポリシーを設定する方法はいくつかあります。Call Home/SNMP/syslog ポリシーは、アラートを柔軟に構成することができます。Cisco Call Home は、シスコの数多くの製品に備わっている機能で、クリティカルなイベントを電子メールや Web ベースの通知アラートを複数の異なる形式で提供します。これにより、機能停止に陥る前に管理者は問題を解決できます。SNMP ポリシーまたは syslog ポリシーは、現在の通知システムとの併用が可能です。アラートを「受け取る」モニタリング オブジェクトに指定された通知やアラートのレベルには、異なるロギング レベルを選択できます。

イベントの重大度とフォールトの重大度の割り当て

モニタリング オブジェクトによって発生したイベントに関するイベントの重大度とフォールトの重大度は変更できます。ほとんどの場合、イベントおよびフォールトに対するデフォルトの重大度の割り当てが使用されますが、ACI 管理者によってはイベントの重大度またはフォールトの重大度がデフォルトの値よりも高い、または低いと判断するかもしれません。たとえば、クリティカルなフォールトだけを通知する場合でも、即刻通知して欲しいメジャーなフォールトがある場合は、その特定のフォールトコードの重大度を変更できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Monitoring Policies] > [Monitoring_Policy] > [Fault Lifecycle Policies] を選択します。

4. [Work] ペインの [Fault Severity Assignment Policies] ダイアログボックスで、次の操作を実行します。

1. フォールトの重大度を変更するフォールトコードを決定するモニタリング オブジェクトを選択します。

2. [+] をクリックしてオブジェクトを追加します。

3. 重大度を変更する特定のフォールトコードを選択します。

4. [Cleared]、[Critical]、[Major]、[Minor]、[Squelched]、[Inherit]、[Warning]、[Info] から重大度を選択します。

[Squelched] の重みは 0 % です。つまり、ヘルス スコアには影響しません。

5. [Update] をクリックします。

イベントの重大度の割り当てポリシーは、同様に設定できます。

フォールトライフサイクル ポリシー

フォールトのライフサイクルは、フォールトを検知してから復旧するまでを説明するためにシスコが使用している用語です。フォールトが検出されると、そのフォールトは「ソーキング」状態になります。「ソーキング間隔」と呼ばれる一定時間後に、「発生」状態になります。「発生」とは、ソーキング間隔後にもフォールトが存在することを意味します。そのフォールトがクリアされると、「発生クリア中」と呼ばれる状態になります。この状態にあるのは短時間で、「クリア期間」状態に移行します。「クリア間隔」に指定した時間は「クリア期間」状態のままになります。最後に、「保持」状態に移行しますが、「保持間隔」が終了するまで、フォールトは削除されません。

フォールトのライフサイクル間隔を変更する方法：

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. 作業ウィンドウで、 [Tenant_Name] を選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Monitoring Policies] > [Monitoring_Policy] > [Fault Lifecycle Policies] を選択します。

4. [Work] ペインの [Fault Lifecycle Policies] ダイアログボックスで、次の操作を実行します。

1. デフォルトの間隔を変更するフォールトコードを決定するモニタリング オブジェクトを選択します。

2. [+] をクリックします。

3. [Clearing Interval]、[Retention Interval]、[Soaking Interval] に時間を指定します（すべて秒単位）。

注：デフォルトでは、[Clearing Interval] は 120 秒、[Retention Interval] は 3600 秒、[Soaking Interval] は 120 秒です。

この時点で、十分に機能するテナントのモニタリング ポリシーになります。以降の項で概要を示すように、ACME は、他にもファブリックでポリシーを設定できます。

TCAM ポリシーの使用

ポリシー設定を保存するために使用しているTernary Content-Addressable Memory（TCAM）は、高額なスイッチ ハードウェアのコンポーネントです。そのため、ポリシーの拡張性に影響を与えたり、ハードウェア コストを上昇させたりする傾向があります。Cisco Application Centric Infrastructure (Cisco ACI) ファブリック内では、エンドポイント自体ではなく、EPG に基づいてポリシーが適用されます。このポリシーの規模は、n*m*f と表すことができます。ここで、n は送信元の数、m は宛先の数、f はポリシー フィルタの数です。Cisco ACI ファブリック内では、送信元と宛先が所定の EPG の唯一のエントリとなるため、必要なエントリの総数が低減します。

TCAM は、監視対象にすべきファブリック リソースです。使用可能な TCAM リソースが確認できるシステム全体のビューがあります。メニュー バーで、TCAM リソースを表示するためには、Operations > Capacity Dashboard を選択します。Work ペインには、すべてのノード用の容量を要約したテーブルが表示されます。

TCAM は、Cisco ACI ファブリック内の重要なシステム リソースであり、使用率を監視する必要があります。アーキテクチャ/設計チームは、TCAM 使用率がどのように使用されるか想定しておく必要があります。通常の運用パラメータの予測に役立つファブリック リソース計算ツールが Github（https://github.com/datacenter/FabricResourceCalculation）にあります。

一般に、デフォルトのモニタリング ポリシーは、リソース不足を報告し、ファブリック全体のヘルススコアを下げます。大きく値が変更されるような使用環境にある、または常にオーバーサブスクライブになると懸念される場合は、違うしきい値を設定できます

- TCAM ポリシー モニタの作成

- TCAM プレフィックスの使用量

TCAM ポリシー モニタの作成

1. メニュー バーで、[Fabric] > [Fabric Policies] の順に選択します。

2. ナビゲーション ウィンドウで、[Monitor Policies] > [default] > [Stats Collection Policies] の順に選択します。

3. [Work] ペインの [Stats Collection Policies] ダイアログボックスで、次の操作を実行します。

1. モニタリング オブジェクトの [Equipment Capacity Entity]（eqptcapacity.Entity）を選択します。

2. [Stats Type Policy Entry] を選択します。

3. [Config Thresholds] の下にある [+] をクリックします。

4. [Thresholds For Collection 5 Minute] ウィンドウで、ポリシー CAM エントリ使用率の現在値の横にある青色の鉛筆アイコンを選択します。

TCAM プレフィックスの使用量

この手順で、TCAM　プレフィックスの使用量を管理します。

1. メニュー バーで、[Fabric] > [Fabric Policies] の順に選択します。

2. [Navigation] ペインで、[Monitor Policies] > [default] > [Stats Collection Policies] の順に選択します。

3. [Work] ペインの [Stats Collection Policies] ダイアログボックスで、次の操作を実行します。

1. モニタリング オブジェクトの [Equipment Capacity Entity]（eqptcapacity.Entity）を選択します。

2. 統計情報 [TypeLayer3 Entry] を選択します。

3. [Config Thresholds] の下にある [+] をクリックします。

4. [Thresholds For Collection 5 Minute] ウィンドウで、ポリシー CAM エントリ使用率の現在値の横にある青色の鉛筆アイコンを選択します。

ヘルススコアの評価ポリシー

1. メニュー バーで、[Fabric] > [Fabric Policies] の順に選択します。

2. [Navigation] ペインで、[Monitor Policies] > [Common Policies] > [Health Score Evaluation Policy] > [Health Score Evaluation Policy] の順に選択します。

3. [Work] ペインの [Properties] ダイアログボックスで、次の操作を実行します。

1. [Penalty of fault severity critical] ドロップダウン メニューで、必要な % を選択します。

2. [Penalty of fault severity major] ドロップダウン メニューで、必要な % を選択します。

3. [Penalty of fault severity minor] ドロップダウン メニューで、必要な % を選択します。

4. [Penalty of fault severity warning] ドロップダウン メニューで、必要な % を選択します。

4. [送信（Submit）] をクリックします。

通信ポリシー

1. メニュー バーで、[Fabric] > [Fabric Policies] の順に選択します。

2. [Navigation] ペインで、[Pod Policies] > [Policies] > [Communication] を展開します。

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

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

1. [Communication Policy Name] に入力します。

2. [HTTP Admin State] ドロップダウン メニューから、必要な状態を選択します。

3. [HTTP Port] ドロップダウン メニューから必要なポートを選択します。

4. 必要な HTTP リダイレクト状態を選択します。

5. [HTTPS Admin State] ドロップダウン メニューから、必要な状態を選択します。

6. [HTTPS Port] ドロップダウン メニューから必要なポートを選択します。

7. 必要な HTTPS リダイレクト状態を選択します。

8. [SSH Admin State] ドロップダウン メニューから、必要な状態を選択します。

9. [Telnet Admin State] ドロップダウン メニューから、必要な状態を選択します。

10. [Telnet Port] ドロップダウン メニューから必要なポートを選択します。

5. [送信（Submit）] をクリックします。

CPU 使用率とメモリ

GUI

コントローラの健全性を迅速に、最も簡単に確認する方法は APIC です。システム ダッシュボードにログインすると、APIC の健全性や、クラスタ自身の健全性がダッシュボードにすぐに表示されます。

APIC の通常の状態は、「完全に適合」状態にあることを示す緑色で表示されます。これは、APIC が相互に同期していることを示します。

詳細は、[System] > [Controllers] をクリックすると確認できます。

REST API

コントローラは、procEntity クラスのインスタンスを作成することで、CPU やメモリ使用率の現在のステータスに関する情報を提供します。procEntity は、システム内のプロセスのコンテナの 1 つです。このオブジェクトは、APIC で実行しているさまざまなプロセスに関する詳細情報を保持しています。procEntity オブジェクトには、次の有益なプロパティが含まれています。

cpuPct：CPU 使用率

maxMemAlloc：システムに割り当てられた最大メモリ

memFree：システムで使用可能な最大メモリ量

使用例：この情報は、次の REST コールを使用して、すべての APIC コントローラ用に取得できます。

http[s]://apic_ip/api/node/class/procEntity.xml?

CLI

Linux の top ユーティリティも、APIC コントローラに実装されており、トラブルシューティングや確認に使用できます。

user@apic1:~> top
top - 11:41:51 up 16:50, 4 users, load average: 4.19, 4.27, 4.29
Tasks: 354 total, 1 running, 353 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.4%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 131954932k total, 7473180k used, 124481752k free, 409540k buffers
Swap: 0k total, 0k used, 0k free, 1952656k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32102 root 20 0 556m 205m 85m S 3.3 0.2 38:11.04 svc_ifc_applian
32120 ifc 20 0 660m 343m 86m S 2.0 0.3 27:58.73 svc_ifc_dbgr.bi
32121 ifc 20 0 631m 286m 86m S 2.0 0.2 17:41.92 svc_ifc_topomgr
32105 root 20 0 659m 258m 85m S 1.7 0.2 17:08.35 svc_ifc_bootmgr
32113 ifc 20 0 1083m 721m 69m S 1.7 0.6 20:03.37 svc_ifc_observe
32128 ifc 20 0 639m 315m 69m S 1.7 0.2 16:28.34 svc_ifc_reader.
32132 ifc 20 0 657m 252m 71m S 1.7 0.2 17:13.74 svc_ifc_scripth
1291 root 20 0 834m 419m 94m S 1.3 0.3 20:35.24 nginx.bin

ディスク使用率

GUI

APIC には、複数のディスクとファイル システムがあります。GUI を使用するとシステム内のすべてのパーティションのディスク領域使用率にすぐにアクセスでき、この情報のモニタリングに使用できます。

ディスク使用率を表示するには、[System] > [Controllers] > [Apic-X] > [Storage] をクリックします。

Work ペインには、システムのパーティションの使用率が表示されます。

REST API

この情報は、次の REST コールを使用してすべての APIC コントローラについて取得できます。

http[s]://apic-ip/api/node/class/eqptStorage.xml?

CLI

user@apic1:~> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/dm-1 41282880 10518960 28666872 27% /
tmpfs 4194304 56456 4137848 2% /dev/shm
tmpfs 65977464 964 65976500 1% /tmp
/dev/mapper/vg_ifc0-data
41282880 10518960 28666872 27% /data
/dev/mapper/vg_ifc0-firmware
41284928 13860672 25327104 36% /firmware
/dev/mapper/vg_ifc0-data2
583149656 1281104 552246280 1% /data2

* 一部のファイル システムは、マウント ポイントに到達するためのルート アクセスが必要であるため、すべてのファイル システムに CLI からの可視性があるわけではありません。GUI は、実際のファイル システム使用率を把握するための単一ソースになります。

物理インターフェイスとボンドインターフェイスの統計情報

APIC は接合されたインターフェイスを使用します。これは、ACI ファブリックへの接続を行うための 2 つのリーフへのデュアルホームとなっており、アウトオブバンド管理ネットワークにデュアルホーム可能なボンドインターフェイスを使用する機能を備えています。

Bond0 は、（ファブリックに接続されているリーフに接続するために）ファブリック自体への接続に使用されるボンドインターフェイスです。

Bond1 は、（APIC 自体を設定できるようにする OOB セグメントに接続するために）アウトオブバンド セグメントへの接続に使用されるボンドインターフェイスです。

ボンドインターフェイスは、基盤の物理インターフェイスに依存しており、GUI が物理および論理ボンドインターフェイスにリンク情報を提供することに注意してください。

GUI

APIC のインターフェイスのインターフェイス ステータスを表示するには、[System] > [Controllers] > [Apic-x] > [Interfaces] に移動します。

REST API

この情報は、次の REST コールを使用してすべての APIC コントローラについて取得できます。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-1/sys.json?querytarget=
subtree&target-subtree-class=l3EncRtdIf

CLI

リンクの状態を確認するには、CLI コマンドの「ifconfig」と「ip link」の両方を使用できます。CLI では、RX カウンタや TX カウンタなどのインターフェイスの詳細な統計に関する情報も提供されます。

Fan Status

次の項では、APIC のファン トレイのステータスを取得する方法について説明します。

GUI

APIC のインターフェイスのインターフェイス ステータスを表示するには、[System] > [Controllers] > [Apic-x] > [Equipment-Fans] に移動します。

REST API

この情報は、次の REST コールを使用してすべての APIC コントローラについて取得できます。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-1.json?querytarget=
subtree&target-subtree-class=eqptFan

CLI

APIC のファン ステータスは、APIC の CIMC ポートで CLI を使用して監視できます。これを行うには、CIMC の設定に使用した認証情報（APIC に使用した認証情報とは異なる場合があります）を使用して CIMC にログインします。これをまだ設定していない場合のデフォルトのユーザ名は admin、デフォルトのパスワードは password です。

CIMC ポートは、重大なフォールトが発生した場合に APIC を回復するのに使用できる統合停電管理ポートです。

user@apic1:~> ssh -l admin 172.16.176.179
Warning: Permanently added '172.16.176.179' (RSA) to the list of known hosts.
admin@172.16.176.179's password:
C220-FCH1807V02V# scope sensor
C220-FCH1807V02V /sensor # show fan
Name Sensor Reading Units Min. Max. Min. Max.
Status Warning Warning Failure Failure
----------- ------- -------- ----- --------- --------- -------- ---------
FAN1_TACH1 Normal 7490 RPM 1712 N/A 1284 N/A
FAN1_TACH2 Normal 7490 RPM 1712 N/A 1284 N/A
FAN2_TACH1 Normal 7490 RPM 1712 N/A 1284 N/A
FAN2_TACH2 Normal 7276 RPM 1712 N/A 1284 N/A
FAN3_TACH1 Normal 7704 RPM 1712 N/A 1284 N/A
FAN3_TACH2 Normal 7276 RPM 1712 N/A 1284 N/A
FAN4_TACH1 Normal 7704 RPM 1712 N/A 1284 N/A
FAN4_TACH2 Normal 7276 RPM 1712 N/A 1284 N/A
FAN5_TACH1 Normal 7704 RPM 1712 N/A 1284 N/A

Temperature Status

APIC で使用可能なさまざまなセンサーの温度ステータスを監視するには、次のステップを使用します。

GUI

APIC のインターフェイスのインターフェイス ステータスを表示するには、[System] > [Controllers] > [Apic-x] > [Equipment-Sensors] に移動します。

REST API

この情報は、次の REST コールを使用してすべての APIC コントローラについて取得できます。

https://{{apic-ip}}//api/node/mo/topology/pod-1/node-1.json?querytarget=
subtree&target-subtree-class=eqptSensor

CLI

C220-FCH1807V02V /sensor # show temperature
Name Sensor Reading Units Min. Max. Min. Max.
Status Warning Warning Failure Failure
------------------ -------- -------- ------- ------- --------- -------- ---------
P1_TEMP_SENS Normal 49.5 C N/A 81.0 N/A 86.0
P2_TEMP_SENS Normal 50.5 C N/A 81.0 N/A 86.0
RISER1_INLET_TMP Normal 45.0 C N/A 60.0 N/A 70.0
RISER2_INLET_TMP Normal 41.0 C N/A 60.0 N/A 70.0
RISER1_OUTLETTMP Normal 50.0 C N/A 60.0 N/A 70.0
RISER2_OUTLETTMP Normal 41.0 C N/A 60.0 N/A 70.0
FP_TEMP_SENSOR Normal 37.0 C N/A 60.0 N/A 70.0
DDR3_P1_A1_TEMP Normal 42.0 C N/A 65.0 N/A 85.0
DDR3_P1_B1_TEMP Normal 43.0 C N/A 65.0 N/A 85.0
DDR3_P1_C1_TEMP Normal 44.0 C N/A 65.0 N/A 85.0
DDR3_P1_D1_TEMP Normal 44.0 C N/A 65.0 N/A 85.0
DDR3_P2_E1_TEMP Normal 43.0 C N/A 65.0 N/A 85.0
DDR3_P2_F1_TEMP Normal 43.0 C N/A 65.0 N/A 85.0
DDR3_P2_G1_TEMP Normal 42.0 C N/A 65.0 N/A 85.0
DDR3_P2_H1_TEMP Normal 41.0 C N/A 65.0 N/A 85.0
VICP81E_0_TMP3 Normal 56.0 C N/A 85.0 N/A 90.0
PSU1_TEMP Normal 37.0 C N/A 60.0 N/A 65.0
PCH_TEMP_SENS Normal 51.0 C N/A 80.0 N/A 85.0

Power Supply Status

APIC で使用可能なさまざまなセンサーの温度ステータスを監視するには、次のステップを使用します。

CLI

C220-FCH1807V02V /sensor # show psu
Name Sensor Reading Units Min. Max. Min. Max.
Status Warning Warning Failure Failure
------------------ -------- -------- -------- ------- --------- -------- ---------
P1_TEMP_SENS Normal 49.5 C N/A 81.0 N/A 86.0
POWER_USAGE Normal 160 Watts N/A N/A N/A 800
PSU1_POUT Normal 136 Watts N/A 624 N/A 648
PSU1_PIN Normal 160 Watts N/A 720 N/A 744
PSU1_STATUS Normal present
PSU2_STATUS Normal absent
PSU1_PWRGD Normal good
PSU1_AC_OK Normal good

スイッチの CPU 使用率のモニタリング

さまざまな期間の CPU 使用率やトレンドをポーリングする方法はいくつかあります。以降の項で、使用可能ないくつかの方法について説明します。

GUI

REST API

スパイン スイッチやリーフ スイッチの CPU 使用率は、次のクラスを使用し、必要なタイムスケールと粒度に基づいて監視できます。

proc:SysCPU5min：5 分間のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは 10 秒ごとに更新されます。

proc:SysCPU15min：15 分間のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは 5 分ごとに更新されます。

proc:SysCPU1h：1 時間のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは 15 分ごとに更新されます。

proc:SysCPU1d：1 日のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは、1 時間ごとに更新されます。

proc:SysCPU1w：1 週間のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは毎日更新されます。

proc:SysCPU1mo：1 か月のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは毎日更新されます。

proc:SysCPU1qtr：1 四半期のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは毎日更新されます。

proc:SysCPU1year：1 年のサンプリング間隔でのシステム CPU の最新統計情報を表示するクラス。このクラスは毎日更新されます。

ACME では、最終日全日のすべてのファブリック スイッチの平均 CPU 使用率を表示します。

http[s]://apic_ip//api/node/class/procSysCPU1d.xml?

CLI

Leaf-1# show proc cpu sort
PID Runtime(ms) Invoked uSecs 1Sec Process
----- ----------- -------- ----- ------ -----------
4012 69510 493837 140 1.3% t2usd_tor
4065 7239 27609 262 1.3% python
4292 3841 134758 28 0.8% svc_ifc_opflexe
4391 2355 4423 532 0.4% nginx
4067 1911 206 9278 0.4% svc_ifc_policye
4302 1904 1862 1022 0.3% svc_ifc_observe
4311 1811 1018 1779 0.3% svc_ifc_confele
4123 1407 251 5606 0.3% svc_ifc_eventmg
4310 1802 689 2616 0.3% svc_ifc_dbgrele
4846 119693 36527 3276 0.2% stats_manager
3923 15406 2645 5824 0.1% pfmclnt
4864 2361 2812 839 0.1% ospfv3
4865 2402 2717 884 0.1% ospf
13606 435 211 2065 0.0% bgp
4296 6263 7413 844 0.0% snmpd
4297 6667 4542 1467 0.0% dc3_sensor
4299 8559 8225 1040 0.0% policy_mgr
4301 1860 19152 97 0.0% plog
4866 2792 3269 854 0.0% isis
5025 1611 1743 924 0.0% mcecm

CLI からの CPU 使用率の履歴ビューを表示するには、スイッチの bash プロンプトから代替シェルに移動する必要がある場合があります。このシェルは vsh（または v-shell）と呼ばれています。

Leaf-1# show processes cpu history
1 1 33 1
746554661885833055376572545534667663554785033943645665335644
100
90
80
70
60
50
40 #
30 ##
20 ##
10 # ### ####### ######## # ## ##### ## #### # # #### ##
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5
CPU% per second (last 60 seconds)
# = average CPU%
32 13311134111111111311111111131 11111113 1111 11231 1111111
749513800432206328353370732175609342000769025791144192680117
100
90
80
70
60
50
40 * * * *
30 * ** ** * * * *
20 ** **** ** * * ** * * *** ** ** ** ** *
10 ############################################################
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5
CPU% per minute (last 60 minutes)
* = maximum CPU% # = average CPU%
1
440
030
100 *
90 *
80 *
70 *
60 *
50 *
40 ***
30 ***
20 ***
10 ###
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%

スイッチのメモリ使用率のモニタリング

さまざまな期間のメモリ使用率やトレンドをポーリングする方法はいくつかあります。以降の項で、使用可能ないくつかの方法について説明します。

（注）

設定がプッシュされていない新しい導入環境のリーフおよびスパイン スイッチでも、スイッチのメモリ使用率は 70〜75％ です。ACI 固有のプロセスが追加メモリを消費するため、ACI モードのスイッチ メモリ使用率をスタンドアロン NX-OS モードの使用率と比較しないでください。

メモリ使用率が 90％ を超える場合にのみ、注意が必要です。メモリ使用率が 85％ を超えた場合は、TAC のケースを開いてプロアクティブなトラブルシューティングを行います。

REST API

スパイン スイッチやリーフ スイッチのメモリ使用率は、次のクラスを使用し、必要なタイムスケールと粒度に基づいて監視できます。

proc:SysMem5min：5 分間のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは 10 秒ごとに更新されます。

proc:SysMem15min：15 分間のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは 5 分ごとに更新されます。

proc:SysMem1h：1 時間のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは 15 分ごとに更新されます。

proc:SysMem1d：1 日のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは、1 時間ごとに更新されます。

proc:SysMem1w：1 週間のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは毎日更新されます。

proc:SysMem1mo：1 か月のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは毎日更新されます。

proc:SysMem1qtr：1 四半期のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは毎日更新されます。

proc:SysMem1year：1 年のサンプリング間隔でのシステム メモリの最新統計情報を表示するクラス。このクラスは毎日更新されます。

ACME では、最終日全日のメモリを監視し、および次の REST コールを使用します。

http[s]://apic_ip/api/node/class/procSysMem1d.xml?

CLI

Leaf-1# show system resources
Load average: 1 minute: 1.21 5 minutes: 1.14 15 minutes: 0.80
Processes : 513 total, 2 running
CPU states : 4.1% user, 2.5% kernel, 93.4% idle
Memory usage: 16401072K total, 9054020K used, 7347052K free
Current memory status: OK

SNMP

ACI リリース 1.x 用の SNMP リファレンス ガイドの URL に示したように、SNMP ポーリングの観点から、次の SNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

ファイル システムの健全性のモニタリング

CLI

現時点では、CLI がリーフのファイル システムの使用率を監視する唯一の方法です。ファイル システム階層の一部のマウント ポイントが高い % の使用率を示していても、それは正常です。使用率について監視したほうが良い重要なボリュームは、/volatile、bootflash、logflash です。

Leaf-1# df
df: `/nxos/tmp': No such file or directory
df: `/var/home': No such file or directory
df: `/var/tmp': No such file or directory
df: `/nginx': No such file or directory
df: `/debugfs': No such file or directory
df: `/recovery': No such file or directory
df: `/cfg0': No such file or directory
df: `/cfg1': No such file or directory
df: `/logflash/INXOS_SYSMGR/startup-cfg': No such file or directory
df: `/mnt/plog': No such file or directory
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 512000 1064 510936 1% /
rootfs 512000 1064 510936 1% /
none 512000 1064 510936 1% /isan
none 512000 1064 510936 1% /var
none 51200 2288 48912 5% /etc
none 51200 108 51092 1% /var/log
none 3145728 336664 2809064 11% /dev/shm
none 512000 0 512000 0% /volatile
/dev/sda4 7782036 1080636 6306088 15% /bootflash
/dev/sda5 60485 5356 52006 10% /mnt/cfg/0
/dev/sda6 60485 5356 52006 10% /mnt/cfg/1
/dev/sda3 120979 13349 101384 12% /mnt/pss
/dev/sda7 512000 1064 510936 1% /logflash
/dev/sda9 15748508 591216 14357292 4% /mnt/ifc/cfg
/dev/sda8 15748508 991204 13957304 7% /mnt/ifc/log
/dev/sda8 15748508 991204 13957304 7% /var/log/dme/oldlog
/dev/sda9 15748508 591216 14357292 4% /controller
rootfs 716800 665728 51072 93% /mnt/ifc/cfg/mgmt/opt/controller/sbin
rootfs 716800 665728 51072 93% /controller/sbin
/dev/sda8 15748508 991204 13957304 7% /data/techsupport
rootfs 716800 665728 51072 93% /bin
/dev/sda4 7782036 1080636 6306088 15% /bootflash
rootfs 716800 665728 51072 93% /data/challenge.old.plugin
/dev/sda9 15748508 591216 14357292 4% /controller
rootfs 716800 665728 51072 93% /controller/sbin
rootfs 716800 665728 51072 93% /dev
none 3145728 336664 2809064 11% /dev/shm
none 51200 2288 48912 5% /etc
none 2097152 682360 1414792 33% /isan/plugin/0/isan/utils
none 2097152 682360 1414792 33% /isan/plugin/0/lc/isan/utils
none 2097152 682360 1414792 33% /isan/plugin/0/lc/isan/lib
none 2097152 682360 1414792 33% /isan/plugin/0/isan/lib
none 2097152 682360 1414792 33% /isan/lib
none 2097152 682360 1414792 33% /isan/plugin/0/lib
none 2097152 682360 1414792 33% /isan/utils
rootfs 716800 665728 51072 93% /lc/isan/utils
rootfs 716800 665728 51072 93% /lib
rootfs 716800 665728 51072 93% /mnt/cfg
/dev/sda5 60485 5356 52006 10% /mnt/cfg/0
/dev/sda6 60485 5356 52006 10% /mnt/cfg/1
rootfs 716800 665728 51072 93% /mnt/ifc
/dev/sda9 15748508 591216 14357292 4% /mnt/ifc/cfg
rootfs 716800 665728 51072 93% /mnt/ifc/cfg/mgmt/opt/controller/sbin
/dev/sda8 15748508 991204 13957304 7% /mnt/ifc/log
/dev/sda3 120979 13349 101384 12% /mnt/pss
rootfs 716800 665728 51072 93% /sbin
/dev/sda8 15748508 991204 13957304 7% /data/techsupport
none 1572864 39444 1533420 3% /tmp
rootfs 716800 665728 51072 93% /usr
none 51200 108 51092 1% /var/log
/dev/sda8 15748508 991204 13957304 7% /var/log/dme/oldlog
none 51200 108 51092 1% /var/log/messages
rootfs 716800 665728 51072 93% /var/log/dme
rootfs 716800 665728 51072 93% /var/log/dme/nginx
rootfs 716800 665728 51072 93% /usr/share/vim
/dev/sda7 11811760 375608 10836140 4% /var/log/dme/log
/dev/sda8 15748508 991204 13957304 7% /var/log/dme/oldlog
none 512000 1064 510936 1% /var/run/mgmt/log
none 512000 1064 510936 1% /var/run/utmp
/dev/sda7 11811760 375608 10836140 4% /var/sysmgr
none 40960 8 40952 1% /var/sysmgr/startup-cfg
/dev/sda7 11811760 375608 10836140 4% /logflash/core
rootfs 716800 665728 51072 93% /usb
none 512000 0 512000 0% /volatile

CoPP（コントロール プレーン ポリシング）統計情報のモニタリング

CLI

CoPP はデフォルトで有効になっており、現時点ではパラメータは変更できません。CoPP 統計情報は、CLI を使用できます。

システムによってプログラムされている CoPP ポリシーを表示するには、次の CLI コマンドを使用します。

Leaf-1# show copp policy
COPP Class COPP proto COPP Rate COPP Burst
mcp mcp 500 500
ifc ifc 5000 5000
igmp igmp 1500 1500
nd nd 1000 1000
cdp cdp 1000 1000
pim pim 500 500
dhcp dhcp 1360 340
lacp lacp 1000 1000
ospf ospf 2000 2000
arp arp 1360 340
lldp lldp 1000 1000
acllog acllog 500 500
stp stp 1000 1000
eigrp eigrp 2000 2000
coop coop 5000 5000
traceroute traceroute 500 500
isis isis 1500 5000
icmp icmp 500 500
bgp bgp 5000 5000

CoPP の特定の CoPP クラスにおけるドロップを表示するには、次の CLI コマンドを使用します。

Leaf-1# show copp policy stats
COPP Class COPP proto COPP Rate COPP Burst AllowPkts AllowBytes DropPkts DropBytes
mcp mcp 500 500 0 0 0 0
ifc ifc 5000 5000 195072 161613961 0 0
igmp igmp 1500 1500 3 192 0 0
nd nd 1000 1000 6 564 0 0
cdp cdp 1000 1000 494 140543 0 0
pim pim 500 500 0 0 0 0
dhcp dhcp 1360 340 4 1400 0 0
lacp lacp 1000 1000 0 0 0 0
ospf ospf 2000 2000 0 0 0 0
arp arp 1360 340 1284 90068 0 0
lldp lldp 1000 1000 5029 1717208 0 0
acllog acllog 500 500 0 0 0 0
stp stp 1000 1000 0 0 0 0
eigrp eigrp 2000 2000 0 0 0 0
coop coop 5000 5000 4722 470546 0 0
traceroute traceroute 500 500 0 0 0 0
isis isis 1500 5000 17141 2167565 0 0
icmp icmp 500 500 0 0 0 0
bgp bgp 5000 5000 864 73410 0 0

物理インターフェイス統計情報とリンク ステート

GUI

インターフェイスのリンク ステート情報にアクセスするには、APIC GUI で、[Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Interfaces] > [Physical Interfaces] に移動します。Work ペインの [oper state] 列にリンクの動作状態が表示されます。Work ペインには、他にも、ポート チャネル、仮想ポート チャネル、ルーテッド インターフェイス、ループバックなど、他のタイプのインターフェイスを参照する Work ペイ可能なタブがあります。

インターフェイス統計情報にアクセスするには、APIC GUI で [Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Interfaces] > [Physical interfaces] > [Eth X/Y] に移動し、[Work] ペインで [Stats] タブをクリックします。チェック アイコンをクリックして、グラフにできる追加の統計情報を選択することができます。

REST API

REST API インターフェイスを使用してインターフェイス統計情報をポーリングする顧客の場合は、いくつかのオブジェクトが使用できます。複数の使用可能なカウンタがあります（たとえば、RX/TX、入力/出力/デュプレックス、30 秒レート、5 分レート、ユニキャスト パケット、マルチキャスト パケットなど）。ポインタとして、親管理対象オブジェクトが提供され、それらの親管理対象オブジェクトから子オブジェクトが派生できるようにします。

読者は、オブジェクト モデルを良く理解しており、モデル全体を参照し、下記の例、前出の項で提供された情報、およびそれらで説明されたツールを使用して、必要な情報を取得できると想定されています。

物理インターフェイスの統計情報を得るためのベース API コールの例は次のとおりです。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/phys-[eth1/1].json

たとえば、リーフ 101 ポートの Eth1/1の総入力バイト数を確認するには、ACME オペレータは次の API コールを発行します。

/topology/pod-1/node-101/sys/phys-[eth1/1].json

Visore ではオペレータが階層ツリーのより下位のレベルを表示できます。prior コマンドから、オペレータは入力バイトや出力バイトなどのインターフェイス オブジェクトの子オブジェクトを表示できます。子オブジェクトの 1 つは以下を含みます。

/topology/pod-1/node-101/sys/phys-[eth1/1]/dbgEtherStats

CLI

show interface eth x/y コマンドを使用して、CLI からインターフェイスを監視できます。サポートされているその他のコマンドとしては「show interface port-channel x/y」などがあります。

Leaf-1# show int e1/1
Ethernet1/1 is up
admin state is up, Dedicated Interface
Hardware: 1000/10000/auto Ethernet, address: 7c69.f60f.8771 (bia 7c69.f60f.8771)
MTU 9000 bytes, BW 1000000 Kbit, DLY 1 usec
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, medium is broadcast
Port mode is trunk
full-duplex, 1000 Mb/s, media type is 1G
Beacon is turned off
Auto-Negotiation is turned on
Input flow-control is off, output flow-control is off
Auto-mdix is turned off
Rate mode is dedicated
Switchport monitor is off
EtherType is 0x8100
EEE (efficient-ethernet) : n/a
Last link flapped 04:19:13
Last clearing of "show interface" counters never
1 interface resets
30 seconds input rate 169328 bits/sec, 97 packets/sec
30 seconds output rate 424528 bits/sec, 115 packets/sec
Load-Interval #2: 5 minute (300 seconds)
input rate 644416 bps, 134 pps; output rate 365544 bps, 114 pps
RX
2474537 unicast packets 8434 multicast packets 2 broadcast packets
2482973 input packets 1686129815 bytes
0 jumbo packets 0 storm suppression bytes
0 runts 0 giants 0 CRC 0 no buffer
0 input error 0 short frame 0 overrun 0 underrun 0 ignored
0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop
0 input with dribble 712 input discard
0 Rx pause
TX
1673907 unicast packets 575 multicast packets 7 broadcast packets
1674489 output packets 455539518 bytes
0 jumbo packets
0 output error 0 collision 0 deferred 0 late collision
0 lost carrier 0 no carrier 0 babble 0 output discard
0 Tx pause

SNMP

ACI リリース 1.x 用の SNMP リファレンスガイドの URL に示したように、インターフェイスの SNMP ポーリングの観点から、次のSNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

Module Status

リーフを固定スイッチとして見なすとしても、それらには CPU を搭載したスーパバイザ コンポーネントがあります。転送の観点から、データ プレーン コンポーネントは 2 つあります。つまり、前面ポートを提供する NFE（ネットワーク転送エンジン ASIC）と、スパインにアップリンク接続を提供する ALE または ALE2（アプリケーション リーフ エンジン ASIC）で、これはスイッチ ハードウェアの世代によって異なります。次の方法を使用して、スイッチ内のモジュールのステータスを確認できます。

GUI

NFE と CPU コンプレックスのモジュール ステータスにアクセスするには、APIC GUI で [Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Chassis] > [Module] > [Supervisor modules] に移動すると、モジュールのステータスが [Work] ペインに表示されます。

ALE/ALE2 のモジュール ステータスにアクセスするには、APIC GUI で [Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Chassis] > [Module] > [Line modules] に移動すると、[Work] ペインにモジュールのステータスが表示されます。

REST API

次の REST API コールを使用して、スーパーバイザとモジュールのステータスを監視できます。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/supslot-1/sup
https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/lcslot-1/lc

CLI

show module コマンドを使用して、ベース モジュールとアップリンク モジュールのステータスを取得できます。

Leaf-1# show module
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 48 1/10G Ethernet Module N9K-C9396PX active
GEM 12 40G Ethernet Expansion Module N9K-M12PQ ok
Mod Sw Hw
--- -------------- ------
1 11.1(0.152) 0.2050
Mod MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
1 7c-69-f6-0f-87-71 to 7c-69-f6-0f-87-ad SAL17267Z9U
Mod Online Diag Status
--- ------------------
1 pass

SNMP

ACI リリース 1.x 用の SNMP リファレンスガイドの URL に示したように、インターフェイスの SNMP ポーリングの観点から、次のSNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

スイッチ ファンのステータス

次の項では、リーフ スイッチのファン トレイのステータスを取得する方法について説明します。

GUI

リーフ スイッチのファン ステータスにアクセスするには、APIC GUI で、[Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Chassis] > [Fan Tray] に移動すると、[Work] ペインにモジュールのステータスが表示されます。

REST API

次の REST API コールと、それらの子オブジェクトを使用して、リーフ スイッチのファンの状態を監視できます（この特定のスイッチには 3 つのスロットがあることに注意してください）。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/ftslot-1
https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/ftslot-2
https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/ftslot-3

CLI

次の CLI コマンドを使用して、リーフ スイッチのファンの状態を監視できます。

Leaf-1# show environment fan
Fan:
------------------------------------------------------
Fan Model Hw Status
------------------------------------------------------
Fan1(sys_fan1) N9K-C9300-FAN1-B -- ok
Fan2(sys_fan2) N9K-C9300-FAN1-B -- ok
Fan3(sys_fan3) N9K-C9300-FAN1-B -- ok
Fan_in_PS1 -- -- unknown
Fan_in_PS2 -- -- ok
Fan Speed: Zone 1: 0x5f
Fan Air Filter : Absent

SNMP

ACI リリース 1.x 用の SNMP リファレンス ガイドの URL に示したように、ファンの SNMP ポーリングの観点から、次の SNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

スイッチの電源ステータス

以降の項では、リーフ スイッチの電源のステータスを取得する方法について説明します。

GUI

リーフ スイッチの電源ステータスにアクセスするには、APIC GUI で、[Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Chassis] > [Power Supply Units] に移動すると、[Work] ペインにモジュールのステータスが表示されます。

REST API

次の REST API コールと、それらの子オブジェクトを使用して、リーフ スイッチのファンの状態を監視できます（この特定のスイッチには 3 つのスロットがあることに注意してください）。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/psuslot-1
https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/ch/psuslot-2

CLI

次の CLI コマンドを使用して、リーフ スイッチのファンの状態を監視できます。

Leaf-1# show environment power
Power Supply:
Voltage: 12.0 Volts
Power Actual Total
Supply Model Output Capacity Status
(Watts ) (Watts )
------- ------------------- ----------- ----------- --------------
1 UCSC-PSU-650W 0 W 648 W shut
2 UCSC-PSU-650W 168 W 648 W ok
Actual Power
Module Model Draw Allocated Status
(Watts ) (Watts )
-------- ------------------- ----------- ----------- --------------
1 N9K-C9396PX 168 W 456 W Powered-Up
fan1 N9K-C9300-FAN1-B N/A N/A Powered-Up
fan2 N9K-C9300-FAN1-B N/A N/A Powered-Up
fan3 N9K-C9300-FAN1-B N/A N/A Powered-Up
N/A - Per module power not available
Power Usage Summary:
--------------------
Power Supply redundancy mode (configured) Non-Redundant(combined)
Power Supply redundancy mode (operational) Non-Redundant(combined)
Total Power Capacity (based on configured mode) 648 W
Total Power of all Inputs (cumulative) 648 W
Total Power Output (actual draw) 168 W
Total Power Allocated (budget) N/A
Total Power Available for additional modules N/A

SNMP

ACI リリース 1.x 用の SNMP リファレンスガイドの URL に示したように、電源の SNMP ポーリングの観点から、次の SNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

LLDP ネイバーのステータス

APIC は、ファブリック内のすべての LLDP ネイバーを照会し、特定するために表示する単一ペインを提供しています。

GUI

インターフェイスの LLDP ネイバーのリストを取得するには、[Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Protocols] > [LLDP] > [Neighbors] > [eth x/y] に移動します。

インターフェイスの LLDP ネイバーの完全なリストは、Work ペインで取得できます。

REST API

次の REST API コールを使用すると、同じ情報を取得できます。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/lldp/inst/if-[eth1/1]

CLI

Leaf-1# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
apic2 Eth1/1 120 4c:4e:35:09:77:2f
apic3 Eth1/4 120 90:e2:ba:4b:fa:d4
5548-2 Eth1/7 120 B Eth1/3
Spine-1 Eth1/49 120 BR Eth4/1
Spine-2 Eth1/50 120 BR Eth4/1
Spine-3 Eth1/51 120 BR Eth1/3
Spine-4 Eth1/52 120 BR Eth1/3
Spine-5 Eth1/53 120 BR Eth1/5
Spine-6 Eth1/54 120 BR Eth1/5
Total entries displayed: 9

SNMP

ACI リリース 1.x 用の SNMP リファレンス ガイドの URL に示したように、LLDP の SNMP ポーリングの観点から、次の SNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

CDP ネイバーのステータス

APIC は、ファブリック内のすべての CDP ネイバーを照会し、特定するために表示する単一ペインを提供しています。

GUI

インターフェイスの LLDP ネイバーのリストを取得するには、[Fabric] > [Inventory] > [Pod-1] > [Leaf-X] > [Protocols] > [CDP] > [Neighbors] > [eth x/y] に移動します。

インターフェイスの CDP ネイバーの完全なリストは、Work ペインで取得できます。

前述のワークフローで、[eth x/y] ではなく [Neighbors] をクリックすると、スイッチの LLDP ネイバーのリストが表示されます。

REST API

次の REST API コールを使用すると、同じ情報を取得できます。

https://{{apic-ip}}/api/node/mo/topology/pod-1/node-101/sys/cdp/inst/if-[eth1/1]

CLI

Leaf-1# show cdp neighbors
Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge
S - Switch, H - Host, I - IGMP, r - Repeater,
V - VoIP-Phone, D - Remotely-Managed-Device,
s - Supports-STP-Dispute
Device-ID Local Intrfce Hldtme Capability Platform Port ID
Services-UCS-A(SSI15450J63)
Eth1/5 129 S I s UCS-FI-6248UP Eth1/17
5548-2(SSI154300VL)
Eth1/7 123 S I s N5K-C5548UP Eth1/3

SNMP

ACI リリース 1.x 用の SNMP リファレンスガイドの URL に示したように、CDP の SNMP ポーリングの観点から、次の SNMP オブジェクトがサポートされています。『Cisco ACI MIB Support List』を参照してください。

GOLD 診断結果

GOLD は、[Hardware Replacement] セクションで詳細を確認できます。

GOLD 診断は、通常の運用中に実行するブートアップや中断を伴わないテストが適切に実行されているかを確認するために運用チームが簡単かつ早急に使用できる方法を提供するとともに、フォールト時にその原因と考えられるハードウェアを分離する診断をオンデマンドで実行する機能を提供します。

GUI

スーパーバイザの　GUI に GOLD 診断テストの結果を表示するには、[Fabric] > [Inventory] > [Pod-1] > [Leaf-1] > [Chassis] > [Supervisor Modules] > [Slot-1] をクリックします。次に、Work ペインで [Troubleshooting] をクリックします。

モジュールで同様の結果を表示するには、[Fabric] > [Inventory] > [Pod-1] > [Leaf-1] > [Chassis] > [Line Modules] > [Slot-x] をクリックします。次に、[Work] ペインで [Troubleshooting] をクリックします。

CLI

Leaf-1# show diagnostic result module all
Current bootup diagnostic level: bypass
Module 1: 1/10G Ethernet Module (Active)
Test results: (. = Pass, F = Fail, I = Incomplete,
U = Untested, A = Abort, E = Error disabled)
1) bios-mem-----------------------> .
2) mgmtp-lb-----------------------> .
4) nsa-mem------------------------> .
6) fabp-prbs:
Port 1 2 3 4 5 6 7 8 9 10 11 12
-----------------------------------------
. . . . . . . . . . . .
22) cpu-cache----------------------> .
23) mem-health---------------------> .
24) ssd-acc------------------------> .
25) act2-acc-----------------------> .
26) ge-eeprom----------------------> .
29) usb-bus------------------------> .
30) cons-dev-----------------------> .
31) obfl-acc-----------------------> .
32) nvram-cksum--------------------> .
33) fpga-reg-chk-------------------> .
34) asic-scratch-------------------> .
40) rtc-test-----------------------> .
41) pcie-bus-----------------------> .

ワークロード帯域幅のモニタリング

ACME は、サーバへの接続を予防的に監視し、所定のワークロードに対して十分な帯域幅が使用可能かどうかを判断します。これにより、サーバを 10 G から 40 G にアップグレードする必要があるかどうか、または複数のインターフェイスを接合してより多くの帯域幅をサーバに提供する必要があるかどうかという疑問に答えることができます。次に、サーバに追加の帯域幅がいつ必要になるかをオペレータに通知するために、統計情報ポリシーとしきい値をどのように使用できるかの例を示します。

ACME のサーバ チームは、5 分間にわたってリンク使用率を監視して、平均使用率が 80 % を超えた場合に影響を受けるインターフェイスに対してフォールトを発生させることを決定しました。これらのタスクを実行するには、2 つのまったく異なるタイプのポリシーを使用してモニタリング ポリシーを構成する必要があります。まず、ACME は統計情報収集ポリシーを構成し、必要な 5 分間隔でのリンクの平均使用率を収集します。次に、次の表に従って、リンク使用率がさまざまなしきい値を超えたときにフォールトを生成するしきい値ポリシーを構成します。

インターフェイス モニタリング ポリシーを作成します。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Navigation] ペインで、[Monitoring Policies] を選択します。

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

4. [Create Monitoring Policies] ダイアログボックスで、次の操作を実行します。

1. 新たに作成したモニタリング ポリシーを展開し、[Stats Collection Policy] を選択します。

2. [Monitoring Object] の横にある [edit] ボタンをクリックし、[L1 Physical Interface Configuration] を選択します。

3. [Monitoring Object] ドロップダウンリストから、[L1 Physical Interface Configuration] を選択します。

4. [Stats Type] の横にある [edit] ボタンをクリックし、[Ingress] と [Egress] を選択します。

5. [Stats Type] ドロップダウンリストから、[Ingress] を選択します。

6. [+] をクリックします。

7. 粒度に関す列から [5 minutes] を選択し、[update] をクリックします。

以上で、関連付けられたインターフェイスと入力トラフィック レートを 5 分間隔で監視するポリシーを作成したことになります。次に、使用率が　80 % を超えた場合に通知し、デフォルトのフォールト重大度を 80 % に割り当てるしきい値を構成します。

1. [Config Thresholds] 列の [+] をクリックします。

2. [Thresholds for Collection 5 minute] ウィンドウで [+] をクリックします。

3. [Ingress Link utilization average value] をクリックします。

4. 標準値として [0] と入力し、[Rising] オプション ボタンをクリックします。

注：この例では、絶対パーセンテージを対象としています。このようなポリシーでは、標準値を提供し、その標準値を超える、または下回る偏差を検索するように、さらにカスタマイズできます。

このシナリオでは、80 % という使用率は、アプリケーション パフォーマンスが低下したことを必ずしも意味するものではないため、これには警告のフラグを設定します。追加のレベル/重大度も必要に応じて指定できます。

[set] 列でフォールトが発生するレベルを指定し、[reset] 列でフォールトをクリアするレベルを設定します。たとえば、使用率が 80 を超えると警告が発生するようにし、使用率が 75 を下回ると警告をクリアします。出力統計情報についても、これらのステップを繰り返します。

最後に、新たに作成したポリシーを、監視対象インターフェイスとなるインターフェイス ポリシー グループに関連付けます。

この例では、UCS-10G-PG にポリシーを適用します。

1. メニュー バーで、[Fabric] > [Access Policies] の順に選択します。

2. [Work] ペインで、[Interface Policies] > [Policy Groups] の順に選択します。

1. [UCS-10G-PG] を選択します。

2. [Monitoring Policy] ドロップダウン メニューから、新たに作成したモニタリング ポリシーを選択します。

EPG レベルの統計情報

アプリケーション所有者は、特定の層に対するトラフィック総量など、アプリケーションのネットワーク関連情報を監視することができます。たとえば、所定のアプリケーションの Web 層へのトラフィック量を監視します。この例では、デフォルトのモニタリング ポリシーを割り当てています。それらは単にシステムから情報を取得しているだけです。この情報は、新しくアプリケーションがプッシュされた時に、プッシュ後にトラフィックの異常が発生していないことを確認するのに役に立ちます。

これを行うには、GUI を使用して EPG に移動し、[Stats] タブを選択します。

REST API

さらに、この情報は API から収集できます。

http[s]://apic_ip/api/node/mo/uni/tn-mynewproject/ap-app1/epg-web-epg.xml?querytarget=
self&rsp-subtree-include=stats

対応型モニタリング

ACME の運営スタッフは、何かが正常に機能していないという兆候に対応できます。フォールト通知、ヘルススコアの低下、またはエンドユーザの機能が影響を受けたというチケット/レポートなど、何かが正常に機能していないという通知がある場合、使用可能なモニタリング ツールの知識が、証拠の特定や収集に重要になります。これは、トラブルシューティングに対するボックス（デバイス）単位のアプローチに代わってシステム全体のアプローチを行う場合に特にあてはまります。トラブルシューティングの作業を支援し、トップ/ダウン アプローチを使用して、効果的に詳細を示すツールを理解することが重要です。この証拠を使用して、是正処置をとる前に、問題の根本原因を特定し、分析することができます。フォールトおよびヘルススコアの詳細については、このマニュアル内の特定の項を参照してください。

トラブルシューティングのプロセスの詳しい説明は、このマニュアルの対象範囲ではありません。Troubleshooting Cisco Application Centric Infrastructure の「Analytical problem solving applied to the policy driven data center」（http://aci-troubleshooting-book.readthedocs.org/en/latest/ で入手可能）を参照してください。

テナント：トラブルシューティング ポリシー

Application Policy Infrastructure Controller (APIC) GUI の中で、各テナントの下で トラブルシューティング ポリシー セクションを見つけることができます。この項では、あるテナントに固有のポリシーの設定と、トラフィックのモニタリング、およびエンドポイント間の接続をテストできます。

上の図に示すように、次のトラブルシューティングのポリシーを設定できます。

- SPAN (Switched Port ANalyzer)：テナントのトラフィック フローの外部モニタリングで使用される SPAN および ERSPAN の送信元と宛先の設定。

- Endpoint-To-Endpoint Traceroute：Cisco Application Centric Infrastructure (ACI) ファブリックのテナント エンドポイント間の通信の有効性を確認するためのパス検証ツールの設定。

- エンドポイント-外部 IP 間 Traceroute：テナント エンドポイントと ACIファブリックの外側にある外部デバイス間の通信の有効性を確認するためのパス検証ツールの設定。

- Atomic Counters：一連の定義可能なオブジェクト間の情報を収集し、報告するカスタマイズ可能なカウンタの設定。エンドポイント間、エンドポイント グループ間、エンドポイント グループと特定の IP 間、および他の具体的なオブジェクト（任意または外部のトラフィック フローなど）間の統計情報を収集するようポリシーを設定することができます。

ファブリック：トラブルシューティング ポリシー

ファブリック全体でのトラブルシューティングには、次のツールおよびポリシーがあります。

- SPAN (Switched Port Analyzer)：ファブリックのトラフィック フローの外部モニタリングで使用される SPAN および ERSPAN の送信元と宛先の設定。

- On-demand Diagnostics：ある時点で実行でき、調査に役立つ一連の出力を返す、診断情報を収集するポリシーの設定。

- Leaf Nodes Traceroute：ACI ファブリック ノード間の通信の有効性を確認するパス検証ツールの設定。リーフ ノードに対してtraceroute を使用し、経由するパケットにホップのシーケンスを返すことにより、特定の送信元から宛先に到達するためにパケットが使用するパスを決定できます。

- Traffic Map：リリース 1.2 で、このツールは [Operations] タブに移動し、[Visualization] という名前に変更されました。従来と同様、ACI ファブリック内のノード間トラフィック フローのホットスポット マップの概要を表示します。

その他のツール

- iPing：パーベイシブな送信元としてファブリックを利用して、ファブリックに接続しているデバイスの到達可能性の確認に使用できる ACI ファブリックのトラブルシューティング ツール

- Audit Logs：監査ログは、ACI ファブリックで実行されるすべての操作に関して継続的に収集され、どのユーザがどの操作をいつ行ったかを即座に示すことができます。

対応型モニタリングの使用例

この章の最後に、ACME で問題が発生した 2 つの状況と、前に説明したツールをどのように利用したかを説明します。

1. アプリケーションにアクセスできない：エンドユーザがファブリック内で実行している Web アプリケーションにアクセスできないことを電話で報告します。

2. ユーザが、ファブリック内で実行しているアプリケーションの速度が遅いと報告するか、あるいは、ファブリック内で実行している Web アプリケーションの遅さについてのレポートがあります。

- [Operations] タブ

[Operations] タブ

[Operations] タブには、エンドポイントの接続のトラブルシューティングに必要な一般的に使用されている複数のツールと出力を提供する単一の場所があります。[Operations] タブには次のサブタブがあります。

- [Enhanced Troubleshooting Wizard (Visibility & Troubleshooting)] タブ：ファブリック内のエンドポイント間接続をトラブルシューティングする際に、接続の問題を迅速に特定します。[Enhanced Troubleshooting Wizard] により、エンドポイント接続のトラブルシューティングに必要な一般的に使用される複数のツールを含む単一の場所が提供されます。

- [Capacity Dashboard] タブ：ファブリック リソースの重大なしきい値の概要が表示されます。

- [ACI Optimizer] タブ：ネットワーク要件を入力して、ネットワークに必要なリーフの数と、制約に違反せずに各リーフで各アプリケーションと外部エンドポイント グループを展開する方法を指定できます。

- [EP Tracker] タブ：エンドポイントの IP アドレスまたは MAC アドレスを入力し、このエンドポイントのロケーション、属するエンドポイント グループ、使用されている VLAN カプセル化、およびこのエンドポイントに移行（フラップ）が起きているかを確認できます。

- [Visualization] タブ：一連のスパイン スイッチとリーフ スイッチのトラフィック統計情報が表示されます。

- Visibility and Troubleshooting：拡張トラブルシューティング ウィザード

- キャパシティ ダッシュボード

- エンドポイント トラッカー

Visibility and Troubleshooting：拡張トラブルシューティング ウィザード

拡張トラブルシューティング ウィザードでは、2 つのエンドポイント間の接続を視覚的に表示します。1.2(1x) よりも前のリリースでは、エンドポイントは同じ VRF および同じテナント空間に存在する必要があります。1.2(1x) リリース以降、エンドポイントは、同じテナント内にある必要はありますが、ブリッジ ドメインと VRF は共通のテナント内であればよいことになりました。

テナント間などの他のシナリオでは、表示は可能ですが、拡張トラブルシューティング ウィザードを構成するツールの多く（アトミック カウンタやトレースルートなど）が、それらの機能に対するハードウェア ベースのトポロジ制限により動作しません。これは、拡張トラブルシューティング ウィザード自体の問題ではありません。

1. メニュー バーで、[Operations] > [Visibility and Troubleshooting] の順に選択して、拡張トラブルシューティング ウィザードを起動します。

2. [Name] フィールドで、新しいセッションで名前を入力するか、既存のセッションを選択します。

3. [Source] フィールドで、送信元のエンドポイントの MAC または IP アドレスを入力し、[Search] をクリックします。

4. （任意）外部エンドポイントの場合は、チェックボックスをオンにします。

5. 表示されたエンドポイントをクリックします。

6. [Destination] フィールドで、宛先エンドポイントの MAC または IP アドレスを入力し、[Search] をクリックします。

7. （任意）外部エンドポイントの場合は、チェックボックスをオンにします。

8. 表示されたエンドポイントをクリックします。

9. [Start] をクリックします。

10. [Drop/Stats] タブを選択して、次の画面を表示します。他のタブを選択することで、これらのエンドポイントに関するその他の情報を表示できます。さまざまなエンドポイント トポロジが入力可能ですが、拡張トラブルシューティング ウィザードに含まれるすべてのツールが動作するわけではありません。

キャパシティ ダッシュボード

[Capacity Dashboard] タブを使用して、重要なファブリック リソースのしきい値の概要を把握できます。これにより、承認されるスケーラビリティ制限にどの程度まで近づいているかを即座に確認できます。リーフごとの使用量も表示されるため、どのリーフがリソース制約に達しているかをすぐに確認できます。

1. [Capacity Dashboard] トラブルシューティング ツールを起動するには、メニュー バーで、[Operations] > [Capacity Dashboard] の順に選択します。

（注）

ポリシーのモニタリング ファブリック デフォルトで 5 分間の間隔を無効にすると、 Capacity Dashboard に表示される情報が少なくなります。

エンドポイント トラッカー

[Endpoint Tracker] タブを使用して、ファブリックにアタッチされたエンドポイントの IP アドレスまたは MAC アドレスを入力し、このエンドポイントのロケーション、属するエンドポイント グループ、使用されている VLAN カプセル化、およびこのエンドポイントに移行（フラップ）が起きているかを確認できます。

1. メニュー バーで、[Operations] > [EP Tracker] の順にクリックして、エンドポイント トラッカーのトラブルシューティング ツールを起動します。

2. [End Point Search] フィールドに、エンドポイントの IP アドレスまたは MAC アドレスを入力し、[Search] をクリックします。

3. 表示されたエンドポイントをクリックします。

エンドポイント トラッカー ツールは、イベント中の IP アドレス、MAC アドレス、含まれるエンドポイント グループ、アクション（アタッチまたはデタッチ）、物理ノード、インターフェイス、および VLAN カプセル化を、状態の移行の日時とともに表示します。

スイッチ ポート アナライザ（SPAN）

SPAN は、通常、次の 2 つの方法で使用されます。

- サード パーティまたはオフラインの分析要件の一部としての予防的な使用。

- セキュリティ ツール（IDS/IPS、データ損失の防止）。

- 通話録音。

- ファブリック内のアプリケーションやネットワーキングの問題のトラブルシューティング。

データのストリーム内で何が発生しているかを確認するために特定のトラフィックのキャプチャを実行すると役に立つ場合があります。トラフィック フローを調べることによって、トラフィックのリセット、不正に動作しているプロトコル、不適切なホスト要求や応答、ノード レベルの通信など、パケットやプロトコル レベルの詳細を調査できます。これにより、トラフィック フローやファブリック設定の単純な確認ではなく、デバイスがどのようにネットワークを使用しているかをより深く知ることができます。

スイッチド ポート アナライザ、つまり SPAN は、より詳細な復号化や調査を行うため、ネットワーク アナライザへのトラフィックをコピーしたり、複製したりできる標準機能です。1 つ以上のポート、VLAN、またはエンドポイント グループ（EPG）からのトラフィックのコピーに使用できます。

SPAN 機能プロセスは、どの接続デバイスも中断せず、ハードウェア内で実行されるため、不要な CPU 負荷を防ぎます。

送信元が受信したトラフィック（入力トラフィック）または送信元から転送されたトラフィック（出力トラフィック）、あるいはその両方を監視するように SPAN セッションを設定できます。デフォルトでは、SPAN はすべてのトラフィックを監視しますが、選択したトラフィックだけを監視するようにフィルタを設定できます。

マルチノード SPAN

APIC トラフィック モニタリング ポリシーは SPAN が適切な場所で適用して、接続が行われるたびに各エンド ポイント ユーザのメンバーからのトラフィックをコピーすることができます。メンバーが移動した場合、APIC は新しいリーフに自動的にポリシーをプッシュします。たとえば、vMotion イベントが新しいリーフ スイッチにエンドポイントを移動すると、SPAN 機能の構成を自動的に調整します。

SPAN の注意事項と制約事項

- SPAN はトラブルシューティングのために使用します。SPAN トラフィックはスイッチ リソースのユーザ トラフィックと競合します。負荷を最小限にするには、分析対象の特定のトラフィックだけをコピーするように SPAN を設定します。

- l3extLIfP のレイヤ 3 サブインターフェイスは SPAN 送信元として設定できません。ポート全体を、外部送信元からのトラフィックを監視するように使用する必要があります。

- テナントおよびアクセス SPAN は カプセル化リモート拡張 SPAN（ERSPAN）タイプ I を使用し、ファブリック SPAN は ERSPAN タイプ II を使用します。ERSPAN ヘッダーについては、次の URL にある IETF の Internet Draft を参照してください。 https://tools.ietf.org/html/draft-foschiano-erspan-00

- アクティブな SPAN セッションの最大数などの SPAN 関連の制限については、『Verified Scalability Guide for Cisco ACI』ドキュメントを参照してください。

- SPAN セッションの設定

SPAN セッションの設定

この手順では、リモート トラフィック アナライザにレプリケートされたソース パケットを転送するようにポリシーを設定する方法を示します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. ナビゲーション ウィンドウで、 [Tenant_Name] > [Troubleshoot] > [SPAN] > [SPAN Destination Groups] の順に選択します。

4. [Work] ペインで、[Actions] > [Create SPAN Destination Group] の順に選択します。

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

1. [Name] フィールドに、SPAN 宛先グループの名前を入力します。

2. [Destination EPG] ドロップダウンで、宛先の [Tenant]、[Application Profile]、および [EPG] を選択します。

3. [Destination IP] に入力します。

4. [Source IP Prefix] に入力します。

5. オプションで、必要に応じてその他のフィールドを変更します。

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

7. 必要に応じて、その他の宛先を追加します。

8. [送信（Submit）] をクリックします。

6. [SPAN] の下で [SPAN Source Groups] を右クリックし、[Create SPAN Source Group] を選択します。

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

1. [Name] フィールドに、SPAN 送信元グループの名前を入力します。

2. [Destination Group] ドロップダウン リストから、以前設定した SPAN 送信先グループを選択します。

3. [Create Sources] テーブルで [+] アイコンをクリックし、[Create Sources] ダイアログボックスを開きます。

4. [Name] フィールドに、送信元の名前を入力します。

5. [Direction] フィールドで、送信元に着信するパケット、送信元から発信するパケット、または着信と発信の両方のパケットを複製および転送するかどうかに基づいて、オプション ボタンを選択します。

6. [Source EPG] ドロップダウン リストから、そのパケットが SPAN 送信先に複製および転送される EPG （テナント / アプリケーション プロファイル / EPG によって特定）を選択します。[OK] をクリックして、SPAN 送信元を保存します。

7. [Submit] をクリックして、SPAN 送信元グループを保存します。

traceroute

トレースルート ツールは、パケットが送信先に移動するときに実際に通るルートを検出するために使用されます。traceroute では、ホップごとに使用されるパスが識別され、双方向で各ホップにタイムスタンプが付けられます。traceroute を使用すると、発信元のデバイスと送信先に最も近いデバイスの間のパスに沿ってポート接続をテストできます。送信先に到達できない場合は、パス検出によってパスが障害ポイントまで追跡されます。traceroute は、従来のネットワーキングにおいて便利な機能です。Cisco Application Centric Infrastructure (ACI) では、ファブリックの動作を考慮して、この機能が実装されています。

traceroute は、エンドポイント間やリーフ間（トンネル エンドポイント、または TEP 間）など、さまざまなモードをサポートしています。ファブリック全体のすべてのパスを検出し、外部エンドポイントの出口ポイントを検出し、パスが妨げられているかどうかを発見するのに役立ちます。

テナントのエンドポイントから開始された traceroute は、入力リーフのスイッチに表示される中間ホップとしてデフォルト ゲートウェイを示します。

（注）

traceroute が接続されているサーバまたは VM の OS から実行された場合は、リーフやスパインのホップを unknown と表示し、パケットがファブリックから出た後でその情報の記録を続けます。より正確な情報については、Application Policy Infrastructure Controller (APIC)（GUI または CLI）からのtraceroute を使用してください。

traceroute の注意事項および制約事項

- トレースルートの送信元または宛先が エンドポイントである場合、そのエンドポイントはスタティックではなくダイナミックである必要があります。ダイナミック エンドポイント（fv:CEp）とは異なり、スタティック エンドポイント（fv:StCEp）にはトレースルートに必要な子オブジェクト（fv:RsCEpToPathEp）がありません。

- traceroute 関連の制限については、『Verified Scalability Guide for Cisco ACI』ドキュメントを参照してください。

- traceroute の結果には、リモート ノードと、そのノードにあるインターフェイスの IP アドレスが表示されます。IP アドレスの相関に関する情報を表示するには、 APIC GUI から [Fabric] > [Inventory] > [Fabric Management] に移動してください。

- traceroute は、外部エンドポイント グループに存在するエンドポイントには使用できません。

- エンドポイント 間での traceroute の実行

エンドポイント 間での traceroute の実行

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Policy] > [Troubleshoot] > [Endpoint-to-Endpoint Traceroute Policies] の順に選択します。

4. [Work] ペインで、[Actions] > [Create Endpoint-to-Endpoint Traceroute Policy] の順に選択します。

5. [Create Endpoint-to-Endpoint Traceroute Policy] ダイアログボックスで、次の操作を実行します。

1. [Name] フィールドにトレースルート　ポリシーの名前を入力します。

2. [Source End Points] テーブルで [+] アイコンをクリックし、traceroute の発信元を編集します。

3. [Source MAC] ドロップダウン リストから送信元エンドポイントの MAC アドレスを選択または入力し、[Update] をクリックします。

4. [Destination End Points] テーブルで [+] アイコンをクリックし、traceroute の発信先を編集します。

5. [Destination MAC] ドロップダウン リストから、宛先エンドポイントの MAC アドレスを選択または入力し、[Update] をクリックします。

6. [State] フィールドで、[Start] オプション ボタンをクリックします。

7. [Submit] をクリックして、traceroute を起動します。

6. [Navigation] ペインまたは [Traceroute Policies] テーブルで、traceroute ポリシーをクリックします。traceroute のポリシーが、Work ペインに表示されます。

7. [Work] ペインで [Operational] タブをクリックし、[Source End Points] タブをクリックして、[Results] タブをクリックします。

8. [Traceroute Results] テーブルで、追跡に使用された単数または複数のパスを確認します。

1. 複数のパスが、送信元ノードから宛先ノードへの移動に使用されている場合があります。

2. 見やすいように、[Name] 列などの複数の列の幅を広げます。

アトミック カウンタ

アトミック カウンタは、ファブリック内のエンドポイント、EPG、アプリケーション間の接続をトラブルシューティングするのに便利です。アプリケーションのレポート時、ユーザは処理の遅さを経験する場合があります。また、2 つのエンドポイント間のトラフィック損失をモニタする場合、アトミック カウンタが必要な場合があります。アトミック カウンタが提供する機能の 1 つに、トラブル チケットを予防的モニタリング モードに配置する機能があります。たとえば、問題が断続的に発生していても、オペレータが積極的にチケットの作業にあたっている時に必ずしも発生するとは限らない場合があります。

アトミック カウンタは、ファブリック内のパケット損失を検知し、接続の問題の発生源をすばやく分離できるようにするのに役立ちます。アトミック カウンタには、NTP をファブリックで有効にする必要があります。

リーフ間（TEP 間）アトミック カウンタは次を提供できます。

- ドロップ、アドミットおよび超過パケットのカウント

- 最後の 30 秒などの短期間のデータ収集、5 分、15 分、またはそれ以上の長期間のデータ収集

- スパイン トラフィックごとの詳細（TEP、リーフ、または VPC の数が 64 未満の場合に使用可能）

- 継続的なモニタリング

リーフ間（TEP間）アトミック カウンタは累積であり、クリアできません。ただし、30 秒のアトミック カウンタは 30 秒間隔でリセットされるため、断続的な問題や、再発する問題の分離に使用できます。

テナントのアトミック カウンタは次を提供できます:

- ドロップ、承認および超過パケットを含む、ファブリック全体のトラフィックのアプリケーション固有カウンタ

- モードは次を含みます。

- エンドポイント間 MAC アドレスまたはエンドポイント間 IP アドレス注：単一のターゲット エンドポイントに、それに関連付けられた複数の IP アドレスがある場合があります。

- オプションのドリル ダウン付きの EPG ツー EPG

- EPG ツー エンドポイント

- EPG ツー *（任意）

- エンドポイント ツー外部 IP アドレス

（注）

アトミック カウンタは、2 つのエンドポイント間のパケット量を追跡し、これを測定値として使用します。ハードウェア レベルのドロップやエラー カウンタは考慮しません。

送信元が送信した数よりも宛先で受け取ったパケットの数が少ない場合に、ドロップされたパケットが計算されます。

送信元が送信した数よりも宛先で受け取ったパケットの数が多い場合に、超過パケットが計算されます。

- アトミック カウンタの構成

アトミック カウンタの構成

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Troubleshooting Policies] > [Atomic Counter Policy] の順に選択します。

4. ポリシー（トラフィック トポロジ）を選択します。エンドポイントの組み合わせ、エンドポイント グループ、外部インターフェイスおよび IP アドレス間のトラフィックを測定できます。

5. [Work] ペインで、[Actions] > [Add Policy_Name Policy] の順に選択します。

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

1. [Name] フィールドにポリシーの名前を入力します。

2. トラフィックの送信元の識別情報を選択するか、入力します。必要な識別情報のソース（エンドポイント、エンドポイントのグループ、外部インターフェイス、または IP アドレス）によって異なります。

3. トラフィックの宛先の識別情報を選択するか、入力します。

4. （任意）[Filters] テーブルで [+] アイコンをクリックし、カウントするトラフィックのフィルタリングを指定します。表示される [Create Atomic Counter Filter] ダイアログボックスで、IP プロトコル番号（たとえば TCP=6）によるフィルタリング、および送信元と送信先の IP ポート番号によるフィルタリングを指定します。

5. [Submit] をクリックし、アトミック カウンタ ポリシーを保存します。

7. [Navigation] ペインで、選択したトポロジの下の新しいアトミック カウンタ ポリシーを選択します。ポリシー設定が Work ペインに表示されます。

8. [Work] ペインで [Operational] タブをクリックし、[Traffic] サブタブをクリックして、アトミック カウンタの統計情報を表示します。

トラフィック マップ

（注）

1.2 リリースでは、これは [Operations] タブに移動し、[Visualization] という名前に変更されました。

低いパフォーマンスと輻輳はトラフィック マップを使用すると特定できます。

トラフィック マップはアトミック カウンタを使用してリーフ スイッチ間のトラフィックを継続的に監視、表示して、アプリケーション接続の問題をすばやくデバッグし、分離するのに役立ちます。

- トラフィック マップの構成

トラフィック マップの構成

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

2. [Navigation] ペインで、[Troubleshooting Policies] > [Traffic Map] の順に選択します。

3. ドロップダウン メニュー オプションを設定して、送信元リーフから宛先リーフへのトラフィック パスを表示します。

- 最後の間隔と累積

- 送信、受信、ドロップ、超過

- すべてのスパインと特定のスパイン スイッチ

送信元によるすべてのトラフィックまたは宛先で受信したすべてのトラフィックの相対的なパーセンテージが表示されます。

4. セルをクリックすると、すべての証跡とリンクが表示されたテーブルが開きます。

IPing

IPing を使用して、プライベート ネットワークを考慮し、ファブリック内のリーフ ノードからエンドポイントまでの接続をテスト、確認します。IPing は、ping コマンドと同様に、ネットワーク ユーザにとってのトラブルシューティング ツールです。

IPing の使用

iping [ -V vrf ] [ -c count ] [ -i wait ] [ -p pattern ] [ -s packetsize ] [ -t timeout ] host

例

pod1-leaf1# iping -V overlay-1 10.0.59.154
PING 10.0.59.154 (10.0.59.154): 56 data bytes
64 bytes from 10.0.59.154: icmp_seq=0 ttl=55 time=0.254 ms
64 bytes from 10.0.59.154: icmp_seq=1 ttl=55 time=0.256 ms
64 bytes from 10.0.59.154: icmp_seq=2 ttl=55 time=0.245 ms
64 bytes from 10.0.59.154: icmp_seq=3 ttl=55 time=0.241 ms
64 bytes from 10.0.59.154: icmp_seq=4 ttl=55 time=0.23 ms
--- 10.0.59.154 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.23/0.245/0.256 ms

監査ログ

ファブリックで実行された変更を表示することが必要な場合があります。ファブリック内のホストまたはアプリケーションについて報告された停電を追跡したり、監査要件を満たすためにデータをプルしたりする必要がある場合があります。

監査ログは、誰がいつ、変更を加えたのかや、操作の説明のレコードです。また、監査ログには、ユーザがいつログインし、ログアウトしたかも記録されます。

監査ログは、GUI の複数の場所で検索でき、現在の GUI コンテキストに関連するイベントだけお表示するようにフィルタリングされます。[History] タブが GUI の Work ペインに表示されている場合は、監査ログを表示できます。次の手順では、テナント イベントの表示方法を例として示します。

- 監査ログの表示

監査ログの表示

この手順では、テナントの監査ログを表示する方法を示します。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインで、[Common] を選択します。

3. [Navigation] ペインで、[Common] を選択します。

4. [Work] ペインで、[History] タブを選択します。

5. [History] タブの下にある [Events] サブタブを選択してイベント ログを表示します。

6. [History] タブの下にある [Audit Log] サブタブを選択して監査ログを表示します。

7. ログ エントリをダブルクリックして、イベントに関するその他の詳細を表示します。

対応型モニタリングの使用例

この章では、ACME の運用チームが Cisco Application Centric Infrastructure (ACI) モニタリング ツールを使用して、一般的に考えられるシナリオにどのように対応できるかの例を示します。

（注）

これらの例は、基本的な低レベルの調査を実行しており、ファブリック全体のトラフィック フローの問題が分離されていることを想定しています。ケーブルと接続は確認されており、ホストは起動し、仮想マシンは動作し、プロセスは実行しており、メモリや CPU 使用率、その他は確認されています。

いずれのユース ケースでも、最良の方法は、Application Policy Infrastructure Controller (APIC) の組み込み機能である Visibility and Troubleshooting ツールを使用することです。

- エンドポイントへの接続の切断

- ファブリック内で実行するアプリケーションが低速であることを報告するユーザ レポート

エンドポイントへの接続の切断

ACME アプリケーション所有者が、2 つのサーバで接続が切断されたことを報告しています。これら 2 つのエンドポイント（EP）は、同じサブネット、ブリッジ ドメイン、およびテナント内の 2 つの異なるエンドポイント グループ（EPG）に所属しており、それぞれのエンドポイントが異なるリーフ スイッチに接続しています。ブリッジ ドメインのユニキャストのルーティングは有効になっているため、両方のエンドポイントのデフォルト ゲートウェイは Cisco Application Centric Infrastructure (ACI) リーフ スイッチに存在します。

次のステップで、この状況のトラブルシューティングを行います。

1. エンドポイントがリーフ スイッチで既知であることを確認します。

2. 必要なコントラクトがエンドポイント間にあることを確認します。

エンドポイントがリーフ スイッチで既知であることの確認

Application Policy Infrastructure Controller (APIC) GUI を使用して、エンドポイントがリーフ スイッチで既知であることを確認できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] の順に選択します。

4. [Work] ペインで、[Operational] > [Client End-Points] タブを選択します。

5. エンドポイントが表示されていることを確認します。

6. 宛先エンドポイント グループに関して、ステップ 1 ～ 5 を繰り返します。

または、End Point Tracker ツールを使用して、エンドポイントがリーフ スイッチで既知であることを確認できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] の順に選択します。

4. [Work] ペインで、[Operational] > [EP Tracker] タブを選択します。

5. 関連するエンドポイントのロケーションを確認し、それらのエンドポイントの履歴を表示します。

必要なコントラクトがエンドポイント間にあることの確認

Application Policy Infrastructure Controller (APIC) GUI を使用して、必要なコントラクトがエンドポイント間にあることを確認できます。

1. メニュー バーで、[Tenants] > [ALL TENANTS] の順に選択します。

2. [Work] ペインでテナントを選択します。

3. [Navigation] ペインで、[Tenant_Name] > [Application Profiles] > [Application_Profile_Name] > [Application EPGs] > [EPG_Name] の順に選択します。

4. [Work] ペインで、[Operational] > [Contracts] タブを選択します。

5. 送信元エンドポイント グループと宛先エンドポイント グループのグループ間の関係をチェックして、タイプを確認します。これは、プロバイダー/コンシューマなどの方向を示すためです。タイプはさらに、使用中のコントラクト サブジェクトを示します。

6. 各サブジェクトと関連するフィルタの出力/入力累積パケットを確認します。

7. [Security Policies] フォルダの下にあるコントラクトを調査し、各フィルタに適切なフィルタ エントリが含まれていることを確認して、各フィルタの内容を検査します。

8. エンドポイントが各エンドポイント グループ内で検出され、コントラクトの関係性が適切な場合は、トラブルシューティング ポリシーを確認します。

これとは別に、ACI ファブリック内のエンドポイント間の通信を確認できる次のようなテクニックがあります。

- Visibility and Troubleshooting ツールを使用する。

- エンドポイント間のtraceroute を使用して、これらのエンドポイント間に使用可能なパスがあるかを表示する。

- ファブリック内で iPing ツールを使用して、CLI からデフォルト ゲートウェイとエンドポイント間の接続を確認する。各リーフには、デフォルト ゲートウェイとして使用される SVI があります（これが、ブリッジ ドメイン/エンドポイント グループ レベルで定義されているサブネットによる設定である場合）。このテストが成功した場合は、エンドポイントとリーフ スイッチ間の接続に問題はありません。リモート エンドへの接続を確認するには、送信元としてデフォルト ゲートウェイを使用し、各リーフからリモート エンドポイントに iPing を使用します。

それでもどこに問題があるかを特定できない場合は、SPAN を使用して、トラフィックが着信し、ファブリックから送信される場所を確認し、フレームに正しい形式があることを確認します。

ファブリック内で実行するアプリケーションが低速であることを報告するユーザ レポート

ACME のテスト ユーザは、ファブリックで実行する Web サーバの応答が遅いことを報告します。このパフォーマンスの問題は、遅延、パケット ドロップ、または断続的な接続の切断によって引き起こされた可能性があります。この場合、エンドユーザはテスト仮想マシンから Web ポータルへ接続しようとします。仮想マシンと Web ポータルは、同じブリッジ ドメインとテナントの異なる EPG に属しています。

最初に運用スタッフが確認すべきことは、リーフ スイッチにエンド ポイントが一貫して把握されており、その結果 Tenant > Application Profile > EPGs > Operational の下の運用タブに EP が表示されていることです。

エンドポイントがわかっていることを確認したら、EP 間 traceroute を使用して、パスの有効性を表示します。定義したデバイス間にドロップや不正があるかを確認するために、アトミック カウンタも導入できます。また、Operations > Visualization tool を確認することによって、ファブリック内の概要ビューを表示し、ファブリックの特定の要素内で考えられるホットスポットや輻輳を強調表示できます。EP 固有のトラフィックの送信に使用したインターフェイスの CRC エラーの特定のカウンタを確認します。

ファブリック内のすべてが正常に見える場合は、SPAN を使用して、トラフィックが着信し、ファブリックから送信される場所を確認し、フレームに正しい形式があることを確認します。破損したフレームによって、OS レベルの EP からスイッチに、異なるポイントでドロップが引き起こされる可能性があります。

Chapter10. スクリプト化

- ネットワークのプログラム可能性の利用

- ACI とスクリプト化

- API インスペクタ

- 開発テクニック

- POSTman

- Cobra SDK と Arya

- ACI ツールキット

- GitHub

ネットワークのプログラム可能性の利用

産業革命によって、商品の製造技術が近代化され、手作業による生産法から機械化された製造へと移り変わりました。手作業から自動化された操作への移行は、人の生産性を変化させ、機械によって簡単に実現できる繰り返し作業から人を解放できるようにしました。関連するコスト面での削減、高速化、品質向上により、より低いコストで、短時間に、より多くの作業が行えるようになり、高い品質の製品を生み出せるようになりました。プログラム可能性は、産業革命が商品にもたらしたものと同じ成果をネットワークに必ずもたらすものと考えられます。

IT 業界における自動化への必然的な移行により、さらに迅速に望ましい目標を達成し、需要に応じたタイムリーなやり方で迅速にインフラストラクチャをプロビジョニングし、コスト効率を高める方法を個人や企業に提供して、構成した結果の一貫性を高めています。ACI は、ネットワーク エンジニア、開発者、および初心者にまで自動化に向けてのアプローチ可能なパスを提供するため、一般的なツールや言語を使用し、固有の機能をプログラムで完全に公開することにより、これらすべての利点が利用できるようにしています。ACME は IT 組織における本来の DevOps に着手したばかりですが、これらの利点によってビジネスに後れを取ることはありません。

ACI で使用可能な総合的なプログラム可能性の機能により、誰もが恩恵を得られます。ACME のネットワーク エンジニアリング チームと設計チームは、大規模な構成の短時間でのプロビジョニングと、すべての可動部分を自動化する機能によって実現される一貫性による恩恵を受けることができます。運用チームは APIC 内に含まれている大量の情報を利用してプロセスを合理化し、良質なメトリックを収集し、イベントをより正確に関連付け、解決までの時間を短縮して顧客満足度を引き上げることができます。

ACI とスクリプト化

ネットワークのプログラム可能性の目標は明確ですが、これらの目標を実現する手法の把握は困難でした。従来のネットワーキング デバイスは、人の目で確認するための出力を提供し、人が簡単に入力できるテキスト入力を使用して構成を行います。ただし、これらの目標は、自動化主導のアプローチとは対照を成しています。マシンは、何らかの構造化形式で提供されるデータをより簡単に処理できます。視覚的な訴えを持たない構造化データは高速で解析でき、また、包括的なオブジェクト指向の構成モデルを表すことが可能な詳細すべてを簡単に表現できます。

ACI は、詳しく文書化された REST API を使用して、使用およびポスト可能なアプリケーション ベースのセマンティックによるネットワーク構成を表す高度なオブジェクト モデルを使用します。オブジェクト モデルにこのインターフェイスを提供するだけでなく、ACI は、このデータの読み取りや操作を行うための、ユーザが安心してオープン スタンダードとオープン ソースを使用してプログラミングできるさまざまなレベルでのアクセス方法も数多く備えています。

- オブジェクト モデルへの参照

- プログラマチック インターフェイス

- REST API について

オブジェクト モデルへの参照

オブジェクト モデルのトップ レベルの表現

オブジェクト モデルの包括的な概要はこのドキュメントの対象ではありませんが、プログラム可能性という観点から、ACI 機能のあらゆる側面がオブジェクト モデルに含まれていることに注意することが重要です。つまり、ファブリックで行えるすべての構成は、REST API　を使用してプログラムで行えるということです。これには、内部ファブリックのネットワーキング、外部のネットワーキング、仮想化統合、計算統合、およびその他すべての製品の側面が含まれています。

このデータは、管理情報ツリー内に、プロパティ、アイデンティティ、および適用する一貫性のルールによるプログラマチック オブジェクトとして表現されたモデルのあらゆる部分とともに保存されます。これにより、モデルの構成済みの状態が、古いノードやエントリによって収拾がつかなくなったりすることなく、あらゆる側面の検査や操作ができ、ユーザのニーズに応えられるようにすることができます。

プログラマチック インターフェイス

APIC は、構成を許可し、管理および運用可能な状態を提供するだけでなく、その構成を従属コンポーネントにまで拡張するという点で、柔軟性にかなり優れています。これらの機能を促進するインターフェイスのカテゴリは主に 2 つあります。ノースバウンド REST API とサウスバウンド プログラマチック インターフェイスです。

ノースバウンド REST API は構成を許可するとともに、コントローラに管理機能へのアクセスを提供します。このインターフェイスは、GUI や CLI の重要なコンポーネントであり、また、自動化ツール、プロビジョニング スクリプト、およびサード パーティのモニタリング ツールや管理ツールへのアクセス ポイントにもなっています。REST API は、構成変更を行うためのファブリックへの唯一のエントリ ポイントであり、一貫したプログラミングを行えるようにするための、アーキテクチャの重要な側面となっています。

APIC のサウスバウンド インターフェイスは、ファブリックを越えて従属するデバイスまでの拡張を目的とする宣言型モデルを考慮しています。つまり、ACI ファブリックの開放性における重要な側面であり、そのポリシーにおいては、APIC を通じてプログラミングすれば、ハイパーバイザ、L4-7 デバイス、将来的にはその他にもプッシュすることができつため、それらのデバイスを個々に構成する必要はありません。このサウスバウンドの拡張機能は、L4-7 デバイス パッケージと OpFlex という 2 つのモデルを通じて実現されます。

L4-7 デバイス パッケージ インターフェイスでは、ACI ポリシーについての暗黙の知識を持たない既存の L4-7 デバイスに ACI がポリシーを適用できます。IP 経由でアクセス可能な何らかの形式のインターフェイスがデバイスにある限り、これらのデバイスはどのベンダーのものであってもかまいません。デバイス パッケージの実際の実装は、固有の構成インターフェイス、つまり、REST、CLI、SOAP などを介してデバイスに到達可能な、含まれている実行環境内の APIC 上で実行する、Python スクリプトで行われます。ユーザがサービス グラフや EPG ポリシーの変更を加えると、デバイス パッケージが APIC ポリシーを L4-7 デバイスの API コールに変換します。

OpFlex は、情報モデルの一部として定義された管理対象オブジェクトのデータ交換を可能にするように設計されています。OpFlex 自体は、情報モデルを管理せず、ツリーの各ノードに関連付けられたユニバーサル リソース識別子（URI）を持つツリー ベースの抽象モデルと一緒に使用できます。プロトコルは、XML および JSON（および一部のシナリオで使用されているバイナリ符号化）をサポートし、JSON-RPC over TCP などの標準的なリモート プロシージャ コール（RPC）メカニズムを使用するように設計されています。現在、ACI では、ポリシーをアプリケーション仮想スイッチに拡張したり、OpenStack にグループ ベースのポリシーを拡張するために、OpFlexが使用されています。

REST API について

Application Policy Infrastructure Controller (APIC) REST API は、REST アーキテクチャを使用するプログラム的なインターフェイスです。API は JavaScript オブジェクトの表記（JSON）または拡張マークアップ言語（XML）のドキュメントを含む HTTP（デフォルトでは無効）または HTTPS のメッセージを受け入れ、返します。プログラミング言語を使用して、API メソッドまたは MO の説明を含むメッセージや JSON または XML ドキュメントを生成できます。

REST API は、MIT へのインターフェイスであり、オブジェクト モデルの状態を操作できます。APIC コマンドライン インターフェイス（CLI）、GUI、および SDK は同じ REST インターフェイスを使用するため、情報を表示する場合は常に、REST API を介して読み込まれ、構成変更が行われた場合は REST API を通じて書き込まれます。また、REST API は、統計情報、フォールト、監査イベントなど、他の情報を取得できるインターフェイスも提供し、さらにプッシュベースのイベント通知をサブスクライブする手段も提供するため、MIT 内で変更が発生した場合はイベントを Web ソケットを通じて送信できます。

API では、HTTP を通じた POST 操作、GET 操作、DELETE 操作など、標準的な REST メソッドがサポートされています。POST メソッドと DELETE メソッドは、同じ入力パラメータで複数回呼び出されても、それ以上の効果を持たないべき等です。GET メソッドはべきゼロで、何らの変更も行うことなく（つまり、読み取り専用操作）ゼロ回または複数回呼び出すことができます。

REST インターフェイスに出入りするペイロードは、XML エンコーディングまたは JSON エンコーディングによりカプセル化できます。XML の場合、エンコーディング操作は簡単です。要素タグはパッケージとクラスの名前で、そのオブジェクトのプロパティはその要素の属性として指定します。含有は、子要素を作成して定義します。

JSON の場合、エンコーディングにはツリーベースの階層を反映する特定のエントリの定義が必要です。ただし、その定義はツリーのすべてのレベルで繰り返されるため、最初に理解していれば実装はかなり簡単です。

- すべてのオブジェクトを JSON ディクショナリとして記述します。この場合、キーはパッケージとクラスの名前で、値は、属性と子という 2 つのキーを持つ別のネストされたディクショナリになります。

- 属性キーには、オブジェクト上の属性を定義するキー値ペアを記述する、さらにネストされたディクショナリが含まれています。

- 子キーには、すべての子オブジェクトを定義するリストが含まれています。このリストの子オブジェクトは、ここで説明したように定義された、ネストされたオブジェクトを含むディクショナリです。

読み取り操作

オブジェクト ペイロードは、XML または JSON として適切に符号化された後は、REST API での作成、読み取り、更新、削除の操作に使用できます。次の図に、REST API からの読み取り操作の構文を示します。

REST 構文

REST API は、HTTP ベースであるため、特定のリソース タイプにアクセスするようにユニバーサル リソース識別子（URI）を定義することが重要です。要求 URI の最初の 2 つのセクションでは、APIC のプロトコルとアクセスの詳細を単に定義します。要求 URI の次のセクションは、API の呼び出しを指示するリテラル文字列 /api です。先に説明したように、読み取り操作は一般に、オブジェクトまたはクラスに対するものであるため、URI の次の部分で操作が MO に対してか、クラスに対してかを指定します。次のコンポーネントで、オブジェクトベースのクエリに対して照会する完全修飾 Dn か、クラスベースのクエリに対するパッケージとクラス名のいずれかを定義します。要求 URI の最後の必須部分はエンコーディング形式で、.xml か .json のいずれかです。これはペイロード形式を定義する唯一の方法です（APIC は Content-Type やその他のヘッダーを無視します）。

書き込み操作

REST API の作成操作と更新操作は両方とも POST メソッドを使用して実装されます。そのため、まだない場合はオブジェクトが作成され、既に存在する場合は、既存の状態と必要な状態との間の変化を反映するように更新されます。

作成操作と更新操作の両方に複合オブジェクト階層が含まれていることがあります。そのため、すべてのオブジェクトが同じコンテキスト ルートにあり、REST API のデータ ペイロードの 1 MB の制限を超えていない限り、1 つのコマンドで完全なツリーを定義することができます。この制限は、パフォーマンスを保証し、高負荷時にシステムを保護するために設定されています。

コンテキスト ルートは、APIC が複数のコントローラに情報を配信する方法を定義するのに便利で、一貫性の確保に役立ちます。ほとんどの場合、構成はユーザに透過的である必要があります。ただし、かなり大規模な構成で、それが分散トランザクションになる場合は、小さく分割する必要がある場合があります。

REST ペイロード

作成操作と更新操作は、オブジェクト レベルで常に対象となること以外は、読み取り操作と同じ構文を使用します。これは、特定のクラスのあらゆるオブジェクトに変更を加えることができないからです（その必要もありません）。作成操作または更新操作は、特定の管理対象オブジェクトを対象とする必要があります。そのため、リテラル文字列 /mo で管理対象オブジェクトの Dn が提供されることを示し、その次に実際の Dn を示します。フィルタ文字列を POST 操作に適用できます。たとえば、POST 操作の結果を応答で取得する場合は、rsp-subtree=modified クエリ文字列を渡し、POST 操作によって変更されたオブジェクトを応答に含めるように指示します。

POST 操作のペイロードには、Cisco API コマンド本文を定義する管理対象オブジェクトを表す XML または JSON の符号化データが含まれます。

認証

REST API のユーザ名ベースおよびパスワードベースの認証は、POST 操作の Dn ターゲットとして、aaaLogin、aaaLogout、および aaaRefresh などの特殊な要求 URI のサブセットを使用します。ペイロードには、シンプルな XML ペイロードまたは JSON ペイロードが含まれ、これらには aaaUser オブジェクトの MO 表現と、ユーザ名とパスワードを定義する属性名および pwd が含まれています。たとえば、<aaaUser name='admin' pwd='insieme'/> のようになります。POST 操作の応答には、Set-Cookie ヘッダーと、応答の名前付きトークンの aaaLogin オブジェクトの属性の両方として認証トークンが含まれます。この場合の XPath は エンコーディングが XML の場合は /imdata/aaaLogin/@token です。REST API の後続の操作では、このトークン値を APIC-cookie という名前の cookie としてその後の要求の認証に使用できます。

Filters

REST API は、柔軟性のあるさまざまなフィルタをサポートしており、検索範囲を絞り込み、よりすばやく情報を見つけるのに役立ちます。フィルタ自体は、クエリの URI オプションとして付加され、疑問符（?）で始まり、アンパサンド（&）で連結されます。複数の条件をまとめて連結して複雑なフィルタを形成できます。

次のクエリ フィルタを使用できます。

クエリ フィルタ

サブスクリプション

REST API は、アクティブな API セッション中の 1 つ以上の MO へのサブスクリプションをサポートします。ユーザまたはシステムにより開始されたアクションによって、MO が作成、変更、または削除されると、イベントが生成されます。サブスクライブされたアクティブなクエリ上のデータがイベントにより変更されると、APIC はそのサブスクリプションを作成した API クライアントに通知を送信します。

API インスペクタ

GUI で実行されたすべての操作が REST コールを呼び出し、アクセスする情報をフェッチし、コミットします。API インスペクタは、URI やペイロードをリアルタイムで表示することによって、GUI を移動しながら REST インターフェイスで行われていることを調査するプロセスをさらに簡略化します。新しい構成がコミットされると、API インスペクタにはその結果の POST 要求が表示され、GUI に情報が表示されると、GET 要求が表示されます。

API インスペクタを起動するには、Cisco APIC の GUI の右上に表示されている [Account] メニューからアクセスします。[Welcome, <username>]　をクリックし、[Show API Inspector] オプションを選択します。

API インスペクタが起動したら、REST メソッド、URI、およびペイロードとともにタイム スタンプが表示されます。画面に表示されるデータのサブスクリプションを GUI が更新するときにリストが更新されることがあります。

上記の出力から、最後にログに記録した項目には POST 要求とともに、Cisco と言う名前のテナントと、オブジェクトに定義されたいくつかの属性を含む JSON ペイロードがあることがわかります。

url: http://172.16.176.176/api/node/mo/uni/tn-Cisco.json

{
"fvTenant": {
"attributes": {
"name": "Cisco",
"status": "created"
},
"children": [
{
"fvBD": {
"attributes": {
"mac": "00:22:BD:F8:19:FF",
"name": "CiscoBd",
"status": "created"
},
"children": [
{
"fvRsCtx": {
"attributes": {
"tnFvCtxName": "CiscoVrf",
"status": "created,modified"
},
"children": []
}
}
]
}
},
{
"fvCtx": {
"attributes": {
"name": "CiscoVrf",
"status": "created"
},
"children": []
}
}
]
}
}

開発テクニック

ACI には、プログラミングやプログラマティック インターフェイスとの対話が安心してできるレベルが異なるエンジニアが使用可能な開発コード用の方法が数多く用意されています。

最も基本的で、単純なテクニックでは、API インスペクタ、Visore が収集するか XML/JSON を GUI から保存することによって情報を取得し、たとえば POSTman などの一般的に無償で提供されているツールを使用して、この情報を REST API に送信します。

このメソッドを設定することによって、ユーザは一般的な用語を使用し、また、ネットワーキング構成の深い理解と、それらを ACI のポリシー言語ならびに良く使用されている Python プログラム言語の能力や柔軟性と結び付け、プログラマチックなやり方で ACI を構成することができます。ACI ツールキットは、最も一般的な ACI 構築ブロックを公開するオープンソースで開発されたユーティリティであり、ユーザはテナント、アプリケーション プロファイル、EPG、および関連付けられた概念をすばやく作成して、それらを物理インターフェイスに接続できます。提供される合理化されたインターフェイスは、非常にすばやく導入でき、ユーザはアプリケーションの開発にすぐに着手できます。

使用可能な開発ツールの中で最もパワフルなのは Cobra SDK です。使用可能な ACI オブジェクト モデルの詳細な表現、包括的なデータ検証、クエリおよびフィルタリングの広範なサポートにより、Corba は開発者にもユーザにも、同様な ACI の完全なエクスペリエンスを保証します。

POSTman

POSTman は、Chrome Web ブラウザのオープン ソースの拡張機能で、REST クライアント機能を使い勝手の良いパッケージとして提供します。POSTman は、構成、操作、ポリシー、運用状態データなどを表すデータを送受信するために APIC REST インターフェイスとの対話に使用できます。REST の構造に不慣れなユーザの場合も、API インスペクタを使用すると、特定の操作についてどんな基盤コールが GUI に行われているかが表示されるため、それらをキャプチャし、POSTmanを使用してそれらの操作を簡単に再生できます。さらに、POSTman では、要求を変更できます。GUI 操作は 1 回で行え、キャプチャしたデータの属性を変更し、REST API に送信し直してから変更が行われます。

インストール

POSTman を起動するには、まず、http://www.getpostman.com で入手可能な Chrome Web ブラウザのプラグインをダウンロードします。プラグインをインストールすると、Chrome アプリケーション ランチャを使用してアクセスできるようになります。

最初、2 つの主要セクション、サイドバー（左側）と要求コンストラクタ（右側）があるインターフェイスがユーザに表示されます。サイドバーを使用して、POSTman が送信した REST 要求の履歴と、共通タスクを含んでいる要求のコレクションとを切り替えます。

Collections

コレクションで作成する便利なポストは、基本的なログイン操作です。これを行うには、ユーザはまず、サイドバーの [Collections] タブをクリックする必要があります。サイドバー内では、プラス（+）が付いた小さなフォルダが表示されます。それをクリックすると、その時点でポップアップが表示され、ユーザはコレクションに名前を付けるように求められます。この例では、コレクションを「APIC」という名前にし、[Create] ボタンをクリックします。

ログイン要求の構築

ここで、新しい要求を構築できます。要求コンストラクタで、[Enter request URL here] が表示されたら、次の要求 URI を入力して、APICIPADDRESS を APIC の IP に置き換えます。

https://apicipaddress/api/mo/aaaLogin.xml

この要求 URI は REST API のログイン メソッドを呼び出します。ログインにはポスティング データが必要であるため、HTTP メソッドを変更する必要があります。これを行うには、要求 URL の右にあるドロップダウンリストをクリックします。デフォルトでは GET 要求ですが、ドロップダウンリストから POST を選択する必要があります。

これで、選択した POST メソッドで、REST ペイロードを提供できるようになります。データを REST 経由で送信する場合は、「raw」要求本文セレクタを選択する必要があります。

これで、要求のペイロードを入力できるようになります。これは、認証に使用されるユーザ名とパスワードを含むシンプルな XML です。URL は https です。つまり、Web ブラウザと APIC 間で暗号化されるため、クリア テキストで送信されるデータはありません。次の要求本文を入力し、USERNAME と PASSWORD を正しいユーザ名とパスワードに置換します。

<aaaUser name='USERNAME' pwd='PASSWORD'/>

この要求を構築すると、要求を送信できるようになりますが、これは一般的に使用されている方法であるため、要求をコレクションに追加する必要があります。これを行うには、要求本文の下にある [Add to collection] ボタンをクリックします。既存のコレクション リストから「APIC」コレクションを選択し、要求名を「Login」に変更してから、[Add to collection] をクリックします。

要求をコレクションに追加することによって、必要に応じ、APIC とのログイン セッションを確立するために後ですばやくアクセスできるようになります。

上記のステップが完了したら、要求の送信準備が整ったことになります。要求コンストラクタの [Send] ボタンをクリックすると、APIC とのログイン セッションを示す XML を REST API が返します。POSTman GUI には次のように表示されます。

APIC への照会

構築する次の要求は、システム上のテナントのリストを APIC に照会する要求です。まず、要求コンストラクタの [Reset] ボタンをクリックし、上記と同じ手順に進みます。ただし、要求 URL は次のように表示されます。

https://apicipaddress/api/class/fvTenant.xml
要求メソッドは GET に変更されます。

[Add to collection] をクリックし、APIC コレクションに要求を配置して、名前に [Query APIC for tenants] と入力します。

ここで [Send] をクリックすると、この要求は、XML で符号化されたテナントのリストを右側のコンストラクタ ペインの応答本文セクションに返します。

APIC での構成変更

構成の変更を行うにはログインと同様な POST 要求を使用しますが、要求 URL と本文には別の情報を含めます。

この例では、新しいテナントがファブリックに作成されます。要求コンストラクタの [Reset] ボタンをクリックして既存の要求フィールドをすべてクリアし、次の URL を使用します。

https://apicipaddress/api/mo/uni.xml
メソッドを POST に変更します。

要求ペイロードで、次のデータを入力します。

<fvTenant name="Cisco"/>

要求 URL は、このクエリのターゲットがテナントが存在するポリシー ユニバースであることを指定します。このターゲットの範囲を正しく指定することで、テナントを表すデータがペイロードに表示されます。この場合は、Cisco という名前のテナントが作成されます。

クエリ ガイダンスとしての API インスペクタの使用

スクリプト化の項の概要で説明したように、API インスペクタはカスタム REST 要求を構築するためのガイドラインとして使用できます。その項の例で進めると、要求 URL は次のようになります。

https://apicipaddress/api/node/mo/uni/tn-Cisco.json
ペイロードは、次のように、JSON の圧縮バージョンになります。

{"fvTenant": {"attributes": {"name": "Cisco", "status": "created"},
"children": [{"fvBD": {"attributes": {"mac": "00:22:BD:F8:19:FF",
"name": "CiscoBd", "status": "created"}, "children": [{"fvRsCtx":
{"attributes": {"tnFvCtxName": "CiscoVrf", "status":
"created,modified"}, "children": [] } } ] } }, {"fvCtx": {"attributes":
{"name": "CiscoVrf", "status": "created"}, "children": [] } } ] } }

この要求 URI とペイロードを変更し、テナント名の「Cisco」を別の名前に置換し、まったく新しいテナントを同じ構成で作成することができます。新しい要求 URL および JSON は次のようになります。

https://apicipaddress/api/node/mo/uni/tn-Acme.json

{"fvTenant": {"attributes": {"name": "Acme", "status": "created"},
"children": [{"fvBD": {"attributes": {"mac": "00:22:BD:F8:19:FF",
"name": "AcmeBd", "status": "created"}, "children": [{"fvRsCtx":
{"attributes": {"tnFvCtxName": "AcmeVrf", "status": "created,modified"},
"children": [] } } ] } }, {"fvCtx": {"attributes": {"name": "AcmeVrf",
"status": "created"}, "children": [] } } ] } }

これらの値を POSTman の POST 要求に配置し、保存したログイン要求を使用してログイン セッションを確立した後に、前に作成した Cisco というテナントと同じ新しいテナントである「Acme」を作成できます。GUI を手動でクリックしたり、他の手作業は必要ありません。

Cobra SDK と Arya

完全な Cisco ACI Python SDK を Cobra と言います。これは、API の Python の本来の実装であり、REST のすべての機能固有のバインディングを提供するとともに、オブジェクト モデルの完全なコピーを備えているため、データの整合性が確保されるだけでなく、ACI で使用可能な機能と関数をすべてサポートします。Cobra はルックアップやクエリ、GUI が使用する REST に一致し、API インスペクタを使用して検出可能なオブジェクトの作成、変更、および削除を実行するメソッドを提供します。その結果、GUI で作成したポリシーをプログラミング テンプレートとして使用して、開発を促進することができます。

Cobra のインストール プロセスは簡単で、標準的な Python 配布ユーティリティを使用できます。Cobra は APIC 上に .egg ファイルとして配布され、easy_install を使用してインストールできます。また、http://github.com/datacenter/cobra の github でも入手できます。

Cobra SDK の完全なドキュメントは、http://cobra.readthedocs.org/en/latest/ で入手できます。

- セッションの確立

- オブジェクトの使用

- Python アダプタへの Cisco APIC REST

セッションの確立

Cobra を使用するコードでは、まず、ログイン セッションを確立します。現在、Cobra はユーザ名とパスワードベースの認証と、証明書ベースの認証をサポートしています。次に、ユーザ名とパスワード名をベースにした認証を使用する例を示します。

import cobra.mit.access
import cobra.mit.session
apicUri = 'https://10.0.0.2'
apicUser = 'username'
apicPassword = 'password'
ls = cobra.mit.session.LoginSession(apicUri, apicUser, apicPassword)
md = cobra.mit.access.MoDirectory(ls)
md.login()

この例では、Cisco APIC にログインし、認証される md という MoDirectory オブジェクトを実装します。何らかの理由で認証が失敗した場合、Cobra は cobra.mit.request.CommitError 例外メッセージを表示します。セッションにログインしたら、続行できます。

オブジェクトの使用

Cobra SDK を使用して、このワークフローに概ね従っている MIT を操作します。

1. 操作するオブジェクトを特定します。

2. 属性を変更する、あるいは子オブジェクトを追加または削除する要求を構築します。

3. オブジェクトに加えた変更をコミットします。

たとえば、新しいテナントを作成する場合は、まず、MIT のどこにテナントが配置されるか、この場合は、policy Universe の監視対象オブジェクトの子オブジェクト（polUniMo）を特定します。

import cobra.model.pol
polUniMo = cobra.model.pol.Uni('')

polUniMo オブジェクトを定義すると、テナント オブジェクトを polUniMo の子として作成できます。

import cobra.model.fv
tenantMo = cobra.model.fv.Tenant(polUniMo, 'cisco')

これらのすべての操作によって作成されるのは、Python オブジェクトだけです。構成を適用するには、その構成をコミットする必要があります。これを行うには、ConfigRequest というオブジェクトを使用します。ConfigRequest は、単一コンテキストに分類される MO ベースのクラスのコンテナとして機能し、単一のアトミック POST 操作にすべてコミットできます。

import cobra.mit.request
config = cobra.mit.request.ConfigRequest()
config.addMo(tenantMo)
md.commit(config)

ConfigRequest オブジェクトが作成された後、tenantMo オブジェクトが要求に追加されたら、その構成を MoDirectory オブジェクトを使用してコミットします。

先の例では、最初のステップで polUni オブジェクトのローカル コピーを構築します。命名プロパティがないため（二重の空の単一引用符によって反映されている）、MIT でルックアップしてオブジェクトの完全な Dn を把握する必要がありません。常に uni として知られています。

MIT により詳細なものをポストする場合で、オブジェクトに命名プロパティがあるときは、そのオブジェクトのルックアップを実行する必要があります。たとえば、構成を既存のテナントにポストする場合は、そのテナントを照会し、その下にオブジェクトを作成します。

tenantMo = md.lookupByClass('fvTenant', propFilter='eq(fvTenant.name, "cisco")')
tenantMo = tenantMo[0] if tenantMo else None

その結果の tenantMo オブジェクトのクラスは cobra.model.fv.Tenant となり、.dn、.status、.name など、オブジェクト自体をすべて説明するプロパティが含まれます。lookupByClass() エントリはアレイを返します。これは、複数のオブジェクトを返すことができるためです。この場合、コマンドは限定的であり、特定の名前を使用して fvTenant オブジェクトでフィルタリングします。テナントの場合、name 属性は命名属性と呼ばれる特殊なタイプの属性です。命名属性は、ローカルの名前空間で一意である必要がある相対名の構築に使用されます。その結果、名前に関するフィルタを使用した fvTenant での lookupByClass は、長さ 1 または None のアレイ、つまり何も検出されなかったことを返します。

ルックアップを全面的に避けるには、Dn オブジェクトを構築し、その Dn の子オブジェクトを作成できます。この方法は、親オブジェクトが存在する場合にだけ有効です。

topDn = cobra.mit.naming.Dn.fromString('uni/tn-cisco')
fvAp = cobra.model.fv.Ap(topMo, name='AppProfile')

Cobra と対話するためのこのような基本的な方法によって、ネットワーク構成の自動化、トラブルシューティングの実行、およびネットワークの管理に役立てることができる、より複雑なワークフローの作成に必要な構成要素が提供されます。

Python アダプタへの Cisco APIC REST

要求の構築プロセスには時間がかかります。これは、オブジェクト データのペイロードを、加えたいオブジェクト変更を反映した Python コードとして表す必要があるためです。Cobra SDK が Cisco ACI オブジェクトで直接モデル化されるため、オブジェクト モデルに存在するものから直接コードを生成できる必要があります。当然、これは、シスコ アドバンスド サービスが開発したツールを使用して実行できます。ツールは Arya と呼ばれる Python アダプタへの Cisco APIC REST です。

Python アダプタへのサンプル REST

上の図には、API インスペクタ、Visore からの可能性がある入力や、REST クエリの出力が Cobra SDK コードにいかに迅速に変換され、トークン化され、より高度な方法で再利用されるかが明確に示されています。

Arya のインストールは比較的簡単で、ツールには外部依存関係がほとんどありません。Arya をインストールするには、Python 2.7.5 と Git がインストールされている必要があります。次のクイック インストール ステップを使用して Arya をインストールし、システムの Python に配置します。

git clone https://github.com/datacenter/ACI.git
cd ACI/arya
sudo python setup.py install

Arya をインストールしたら、Cisco ACI モデル化オブジェクトを表す XML または JSON を取得すると、Python コードにすばやく変換できます。たとえば、次のように入力します。

arya.py -f /home/palesiak/simpletenant.xml

このエントリによって次の Python コードが得られます。

#!/usr/bin/env python
'''
Autogenerated code using arya.py
Original Object Document Input:
<fvTenant name='bob'/>
''' raise RuntimeError('Please review the auto generated code before ' +
'executing the output. Some placeholders will ' +
'need to be changed')
# list of packages that should be imported for this code to work
import cobra.mit.access
import cobra.mit.session
import cobra.mit.request
import cobra.model.fv
import cobra.model.pol
from cobra.internal.codec.xmlcodec import toXMLStr
# log into an APIC and create a directory object
ls = cobra.mit.session.LoginSession('https://1.1.1.1', 'admin', 'password')
md = cobra.mit.access.MoDirectory(ls)
md.login()
# the top level object on which operations will be made
topMo = cobra.model.pol.Uni('')
# build the request using cobra syntax
fvTenant = cobra.model.fv.Tenant(topMo, name='bob')
# commit the generated code to APIC
print toXMLStr(topMo)
c = cobra.mit.request.ConfigRequest()
c.addMo(topMo)
md.commit(c)

このコードを実行する前に、まず、ランタイム エラーが発生しているプレースホルダを削除する必要があります。これは、更新する必要がある他のトークン化された値が正しいことを確認するために、意図的に配置されています。たとえば、Cisco APIC の IP アドレスはデフォルトでは 1.1.1.1 ですが、これを実際の Cisco APIC の IP アドレスを反映するように更新する必要があります。クレデンシャルやその他のプレースホルダも同様です。

完全修飾階層を持たない入力 XML または JSON を提供すると、Arya はヒューリスティックからそれを特定できない場合があることを注意してください。この場合、プレースホルダにはテキストの REPLACEME が読み込まれるため、これを正しい Dn に置き換える必要があります。この Dn は、Visore のオブジェクトを照会するか、API インスペクタに表示されたオブジェクトの要求 URI を検査することによって見つけることができます。

ACI ツールキット

完全な Cisco Application Centric Infrastructure (ACI) オブジェクト モデルには多くのエントリが含まれているため、ネットワークのプログラム可能性を初めて知ったユーザには手ごわいかもしれません。ACI ツールキットは、ACI の概念を紹介し、共通のタスクやワークフローを迅速に起動させる手段をユーザに提供する、簡略化されたモデルのサブセットを利用できるようにします。さらに、多くのアプリケーションが ACI ツールキットの上部に構築されています。

ACI ツールキットの完全なドキュメントは、http://datacenter.github.io/acitoolkit/ で入手できます。

ACI ツールキットは、オペレータがすぐに使える便利なツールをいくつか提供しますが、本来の価値は、これらの例を開始点として見なし、特定のニーズに合うように、これらの例を変更または拡張する機能にあります。試してみてください。自身の取り組みをコミュニティと共有してください。

エンドポイント トラッカー

エンドポイント トラッカー アプリケーションは、エンドポイント クラス（fvCEp）のサブスクリプションを作成し、ファブリック（サーバ、ファイアウォール、ロード バランサ、およびその他のデバイスなど）の各エンドポイントの関連詳細情報を MySQL データベースに読み込みます。MySQL のインストールはこのドキュメントの対象外であるため、MySQL　サーバに新しいデータベースを作成するためのアクセス権がユーザにあると想定します。エンドポイント トラッカー アプリケーションには主要コンポーネントが 2 つあり、どちらも　Python スクリプトです。

- aci-endpoint-tracker.py：このスクリプトは、エンドポイント クラスのサブスクリプションを作成し、MySQL データベースに読み込みます。

- aci-endpoint-tracker-gui.py：このスクリプトは、データベースのコンテンツをオペレータに表示する方法を提供する Web インターフェイスを作成します。次に例を示します。

エンドポイント トラッカー

エンドポイント トラッカーを起動するには、次の Python スクリプトを実行します。最初のスクリプトの aci-endpoint-tracker.py は、APIC に実際に接続し、データベースに読み込みます。2 番目のスクリプトは、理解可能な Web UI でコンテンツを表示できるようにします。

user@linuxhost:~/acitoolkit/applications/endpointtracker$ ./aci-endpoint-tracker.py
MySQL IP address: 127.0.0.1
MySQL login username: root
MySQL Password:
user@linuxhost::~/acitoolkit/applications/endpointtracker$ python aci-endpointtracker-
gui.py
MySQL IP address: 127.0.0.1
MySQL login username: root
MySQL Password:
* Running on http://127.0.0.1:5000/
* Restarting with reloader

これらの Python スクリプトを実行した後で、ブラウザを起動して、Web UI に進むことができます。ACI エンドポイント トラッカーの使用は、IP や　MAC アドレスを検索フィールドに入力するようなもので、テーブルはそれに応じてフィルタリングされます。次の例では、IP アドレス 192.168.5.20 が検索フィールドに入力され、一致する結果が表示されています。

エンドポイント トラッカー アプリケーションの興味深い使い方の 1 つに、テナント、アプリケーション、EPG など、他のファブリック構造にさまざまなエンドポイントがどのようにマッピングされているかを表示できる一連の可視化があります。

次に、いくつかのスクリンショットの例を示します。これらは、エンドポイントが ACI ファブリック内のどこにあり、それらが環境内の他のオブジェクトにどのように関係または依存しているかを示しています。

エンドポイントの分散の円グラフ ビュー

エンドポイントの関係性のツリー ビュー

エンドポイントの場所の示力図

ACI Lint

コンピュータ プログラミングでは、リントは不一致の識別、または一般的なエラーの単純なデバッグ ツールを参照する用語です。ACI がインフラストラクチャをコードとして提供するという意味では、ACI がリント アプリケーションを備えているのは妥当と言えます。ACI ツールキットにはそれが備わっています。ACI Lint は、次の 2 つの主要機能の構成エラーを確認し、オペレータに通知するアプリケーションです。

セキュリティの問題：セキュアかセキュアでないかのいずれかとして EPG にタグを設定する機能をサポートし、セキュリティ境界を越えてコントラクトが使用されていないことを検証します。

構成の問題：共通する構成エラーを確認し、ユーザに報告します。

参考のため、出力例を以下に示します。

user@linuxhost:~/acitoolkit/applications/lint$ ./acilint.py
Getting configuration from APIC....
Processing configuration....
Critical 001: EPG 'default' in tenant 'infra' app 'access' is not assigned security
clearance
Critical 001: EPG 'x' in tenant 'common' app 'default' is not assigned security
clearance
Warning 001: Tenant 'Cisco' has no Application Profile.
Warning 001: Tenant 'Books' has no Application Profile.
Warning 001: Tenant '3tierapp' has no Application Profile.
Warning 001: Tenant 'mgmt' has no Application Profile.
Warning 002: Tenant 'Books' has no Context.
Warning 002: Tenant '3tierapp' has no Context.
Warning 004: Context 'oob' in Tenant 'mgmt' has no BridgeDomains.
Warning 005: BridgeDomain 'CiscoBd' in Tenant 'Cisco' has no EPGs.
Warning 005: BridgeDomain 'inb' in Tenant 'mgmt' has no EPGs.
Warning 006: Contract 'default' in Tenant 'common' is not provided at all.
Warning 006: Contract 'WebServers' in Tenant 'Acme' is not provided at all.
Warning 006: Contract 'External' in Tenant 'Acme' is not provided at all.
Warning 007: Contract 'default' in Tenant 'common' is not consumed at all.
Warning 007: Contract 'WebServers' in Tenant 'Acme' is not consumed at all.
Warning 007: Contract 'External' in Tenant 'Acme' is not consumed at all.
Warning 007: Contract 'outside-to-web' in Tenant 'roberbur' is not consumed at all.

ACI ケーブル プラン モジュール

データ センターのサポートにおいて、ケーブルの管理はきわめて重要です。ケーブル配線に問題があると、データ センターで何かを新たに展開するときに数時間の遅延が起きる場合があります。Cable Plan モジュールを使用すると、プログラマは、XML ファイルから既存のケーブル プランを容易にインポートしたり、Application Policy Infrastructure Controller (APIC) コントローラから現在実行中のケーブル プランをインポートできます。また、以前にインポートしたケーブル プランの特定ファイルへのエクスポート、ケーブル プランの比較もできます。上級ユーザであれば、Cable Plan を使用して、ケーブル プランの XML ファイルを容易に作成できます。また、ケーブル プランの問い合わせ、ケーブル プランの変更もできます。

ACI CLI エミュレータ モジュール

Cisco Application Centric Infrastructure (ACI) には新しい概念が多数採用されているため、最初のうちはそのポリシー主導型アーキテクチャを理解できないユーザもいるかもしれません。このポリシー主導型アーキテクチャと使い慣れた CLI との統合を望むユーザには、ACI CLI エミュレータがその作業を支援します。CLI エミュレータ モジュールを使用すると、ACI に固有のテナント、コンテキスト、および他のポリシーに対し、show コマンドを実行できます。

ACI マルチサイト アプリケーション

マルチサイト アプリケーションを使用すると、Cisco Application Centric Infrastructure (ACI) ファブリックを複数のサイトにまたがって拡張できます。各サイトは、ファブリックがそれぞれ独自の Application Policy Infrastructure Controller (APIC) クラスタを持つ独立した ACI ファブリックになります。マルチサイト アプリケーションは、コントラクトを複数サイトに拡張させることで、 ACI のグループ ベースのポリシー モデルを保持します。これにより、異なるサイトのエンドポイント グループ間の通信が可能になります。

ACI 設定のスナップショットおよびロールバック

Snapback は、Cisco Application Centric Infrastructure (ACI) ファブリックの設定をスナップショットおよびロールバックするためのツールです。具体的には、管理者はこのツールを使用して次のタスクを実行できます。

- 実行中の ACI ファブリックの設定のライブ スナップショット

- ワンタイム スナップショットと繰り返しスナップショット（即時およびスケジュール済みの両方）

- 設定のバージョン付けしたストレージ

- スナップショット間の違いを含むスナップショット設定の完全表示

- 以前の設定スナップショットへの完全または部分的ロールバック

- Web ベースまたはコマンドラインによる管理

ACI EventsFeeds：ACIアトム フィードへのイベント

EventFeeds アプリケーションでは、オブジェクトが更新されている場合に、WebSocket 接続での Application Policy Infrastructure Controller (APIC) 管理対象オブジェクトへの登録と記録を行います。これらの更新は、HTTP で提供されるさまざまな Atom フィードに表示されます。

Atom フィード アプリケーションに対するCisco Application Centric Infrastructure (ACI) イベントの使用例として、次のものがあります。

- NOC での最近のエンドポイントの表示

- IPTV での更新されたテナントの表示

- フィード クライアントでのエンドポイント グループの変更のモニタリング

GitHub

ソース管理

オープン ソース ソフトウェアは IT で一般的な動きであり、コンシューマ ソフトウェアや Web サーバ、データベース、ならびにオペレーティング システム全体でさえも含む、多くのプロジェクトの成功の背後にある動機になっています。オープン ソースの成功の重要な側面の 1 つに、世界中の多くの開発者が 1 つのプロジェクトで一緒にコラボレーションする機能があります。Concurrent Version Control（CVS）や Subversion（SVN）のような以前のツールは、ソースコードの共通データベースを維持する中央管理サーバを使用して多くの開発者が一緒に作業できるようにするために使用されていました。これらのツールが十分に機能し続ける一方で、サーバ ベースのツールから集中管理されていないユーティリティへの移行は遅々としていました。Git は一般的なオープンソース　オペレーティング システム Linux の作者である Linus Torvalds によって作成されました。Git には、完全なローカル リポジトリのコピー、分散アーキテクチャ、効率に優れたブランチのサポートなど、その他のほとんどのソース管理ツールよりも優れた点がいくつもあります。

GitHub

GitHub は、Git に基づいたホスティング プラットフォームで、無償および有償のホスティング サービスを提供しており、個人が 800 万人を超える他の GitHub ユーザとプロジェクトで一緒にコラボレーションできるようにします。Git 関連のラッパーとは別に、GitHub は問題のトラッキング、プロジェクトへのアクセスの保護、組み込み型のプロジェクトのマニュアル化を行うテクニックも提供します。これらすべての機能を組み合わせることで、GitHub はコミュニティ メンバーの共通の場所となり、互いにコードを共有し、互いの作業を足掛かりとし、自分たちの取り組みをより大規模なプロジェクトに貢献させています。

GitHub には、特定の言語に限らず、通常は、ソース コードを保存しますが、Git プロトコル自体があらゆるファイル タイプのストレージやバージョン管理をサポートしているため、ユーザがマニュアルやその他の常に変更されるファイルを Git に保存することは珍しくありません。主な利点は、Git が提供するバージョン管理によってユーザはファイルを以前保存したバージョンに戻したり、新しいバージョンに戻したりできることにあります。Git には、ファイルに加えた変更の監査も維持され、ファイルのバージョンを分岐させる高度なサポートも備えていることから、複数の同時変更をファイルに行うことができ、作業完了後にそれらをマージすることができます。

「It's on github」

「It’s on github（それは GitHub にある）」は、IT 業界で良く使用されている最新の用語で、GitHub を使い慣れているユーザにとっては、ダウンロード、変更、プロジェクトへの貢献を誘う言葉ですが、経験のないユーザにとっては複雑なトピックのように思えます。実際には、GitHub は非常に簡単に使用できるツールです。GitHub の保存されている情報は、プロジェクトのメイン ページにアクセスし、プロジェクトのメイン ページの右下にある [Download ZIP] を見つけるだけで利用できるようになります。この方法でダウンロードしたファイルには、プロジェクト内のファイルの最新のバージョンが含まれています。ユーザがこのファイルで何を行うかは、その内容によって大きく異なりますが、GitHub で最も勧められている行為の 1 つは、プロジェクトに関する明確で明快なマニュアルを提供することです。それにより、新しいユーザが Git にあるプロジェクトのフロント ページにアクセスしたときに最初に目にするページで、そのプロジェクトのダウンロード方法とインストール方法を見つけることができます。

プロジェクトへの貢献を考えているユーザの次のステップは、GitHub のアカウントに登録し、グラフィック ベースのクライアントをダウンロードしてコマンドライン ベースの Git ツールへのシンプルなインターフェイスを提供することです。GitHub 自体にはグラフィカル クライアントが用意されています。Windows バージョンは http://windows.github.com で、Mac バージョンは http://mac.github.com で入手できます。その他の一般的なソース管理ツールには、SourceTree from Atlassian（http://sourcetreeapp.com で入手可能）などがあります。

アカウントと GitHub クライアントを取得すると、ユーザは、使用可能なプロジェクトを自分のプライベート リポジトリに「分岐」または分割し、変更を加えて、プライベート ブランチにコミットして戻します。それらの変更が機能し、ユーザが元のプロジェクトへの寄与を希望する場合は、「プル」要求を送信できます。原則的には、ユーザは自分の作業を元のプロジェクトにプル バックする必要があることを提示していることになります。プロセスはこのように単純ですが、多くのより高度なプロジェクトには、それらに貢献するための基準やルールがあり、作業をプロジェクトにコミットバックする方法が整備されているため、貢献を試行する前に目を通しておく必要があるかもしれません。

Chapter11. ハードウェアの拡張と交換

- ファブリックの展開と縮小

- ハードウェアの診断と交換

ファブリックの展開と縮小

ACME は、データセンターが拡張されるにしたがい、ACI ファブリックの展開、つまり新しいリーフ スイッチおよびスパイン スイッチ、また場合によって APIC の追加を決定できます。通常、スパイン スイッチはスループットの向上のために追加され、リーフ スイッチはアクセス ポートの増加のために追加されます。APIC は、ポリシーの数とエンドポイントの数が増えた場合に追加されます。また、場合によって一部のスイッチまたはAPIC をデコミッションする必要があります。また、故障したハードウェアを交換する必要がある場合があります。これについては「ハードウェアの交換」の章で説明します。

ここでは、既存の ACI ファブリックでスイッチおよび APIC を追加および削除する操作を順を追って説明します。この操作は、スパイン スイッチとリーフ スイッチの両方で同じように行われます。APIC の追加についても説明しています。

- スイッチ

スイッチ

ACME の既存のファブリックにスイッチを追加する方法は 2 つあります。スイッチがファブリックにケーブル配線された後に APIC 内のスイッチを自動的に検出する方法と、シリアル番号を追加し、後でスイッチを手配するときに、ファブリックに物理的に接続することでスイッチを事前プロビジョニングする方法です。どちらの方法も結果は同じです。数分でファブリックが展開されます。ここでは、スイッチのデコミッションについても説明します。

- 接続済みスイッチの追加

- 接続前のスイッチにおける事前プロビジョニング

- 既存のスイッチのデコミッション

- Cisco Nexus 9300 プラットフォーム スイッチから Cisco Nexus 9300 EX プラットフォーム スイッチへの移行

接続済みスイッチの追加

次の手順は、ファブリックにすでに追加されているスイッチを追加します。

（注）

スパイン スイッチを交換するときに、BGP ルート リフレクタ機能を考慮に入れる必要があります。レイヤ 3 Cisco Application Centric Infrastructure (Cisco ACI) ファブリックの BGP ルート リフレクタとして少なくとも 2 つのスパイン スイッチを設定しなければなりません。この設定は、 System > System Settings > BGP Route Reflectors を Route Reflector Nodes 下で選択して行うことができます。スパイン スイッチを交換するか削除する場合、スパイン スイッチを交換するか削除する間に少なくとも 1個のルート リフレクタをアクティブのままに保ち、変更が完了した後で、少なくともアクティブなルート リフレクタが 2 つになるように適切な設定変更を行います。

BGP ルート リフレクタの詳細については、 Cisco APIC Layer 3 Networking Configuration Guide を参照してください。

1. リーフ スイッチの場合は、すべてのスパイン スイッチへのスイッチをケーブル配線します。スパイン スイッチの場合は、すべてのリーフ スイッチにスイッチをケーブル配線します。理想的なベスト プラクティスは、すべてのリーフがすべてのスパイン スイッチにケーブル配線されるフル メッシュ トポロジでCisco ACIファブリックが接続されることです。すべてのデバイスをリーフ スイッチに接続する必要があり、リーフ スイッチは他のリーフ スイッチに接続してはならず、スパインは他のスパインに接続してはいけません。

2. Cisco Application Policy Infrastructure Controller (Cisco APIC)で、画面上部の [Fabric] をクリックします。

3. 左側の [Navigation] ペインで [Fabric Membership] をクリックします。

4. 新しいスイッチが表示されると、ノードがシリアル番号とともに表示されますが、ノード ID またはノード名は設定されていません。スイッチをダブルクリックし、[Node ID] および [Node Name] を割り当てます。ベスト プラクティスとして、リーフ ノードに 101 から順に番号を付け、スパイン ノードに 201 から順に番号を付けます。小さい値は Cisco APIC 用に予約されています

5. （任意）[Rack Name] に名前を追加します。これは、通常、データセンター内のスイッチの物理的な場所を特定するために使用されます。

6. [Submit] をクリックします。`

7. ファブリックに接続されているすべての新しいスイッチに対してこのプロセスを繰り返します。

接続前のスイッチにおける事前プロビジョニング

スイッチの事前プロビジョニングは、データセンターに到着する前にスイッチを事前に登録するための、便利で操作上プロアクティブなステップです。事前プロビジョニングのために受け取るスイッチのシリアル番号を把握する必要があります。以下は、リーフおよびスパイン両方に対するスイッチの事前プロビジョニングの手順です。

1. メニュー バーで、[Fabric] を選択します。

2. [Navigation] ペインで、[Fabric Membership] を選択します。

3. [Work] ペインで、[Actions] > [Create Fabric Node Member] の順に選択します。

4. [Create Fabric Node Member] ダイアログボックスで、次の操作を実行します。

1. ポップアップ ウィンドウで、到着予定のスイッチのシリアル番号を入力します。

2. [Node ID] および [Switch Name] を割り当てます。ベスト プラクティスとして、リーフ ノードに 101 から順に番号を付け、スパイン ノードに 201 から順に番号を付けます。小さい値は APIC 用に予約されています。

5. [Submit] をクリックします。`

注：事前プロビジョニングが必要なすべてのスイッチにこのプロセスを繰り返します。

[Fabric Membership] ウィンドウへの新しいエントリは、スイッチが実際にファブリックに接続されるまで [Role] 列で [Unsupported] と表示されますが、スイッチは到着してケーブル配線されるとすぐにファブリックのメンバーになります。

あらかじめファブリック ポリシーを事前プロビジョニングすることもできます。ファブリック ポリシーについては、「ファブリック接続」の章で説明します。ポリシーの事前プロビジョニングの詳細については、次のホワイト ペーパーを参照してください。

http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731960.html#_Toc405844675

既存のスイッチのデコミッション

スイッチをデコミッションすることで、ファブリックからスイッチを完全に取り外したり、メンテナンスを行うために一時的にスイッチを取り外すことができます。デコミッション後はスイッチはトラフィックを転送しないので、デバイスが接続されていないことを確認してください。スイッチのはデコミッションには 2 つのタイプがあります。[Regular] と [Remove from Controller] です。

[Regular] はデコミッションは、メンテナンスのために使用でき、基本的に、スイッチのノード ID およびファブリック メンバーシップを維持しながら、スイッチは一時的なソリューションとしてフォールトのレポートおよび SNMP 情報の送信を停止します。スイッチは、左側のナビゲーション ウィンドウの [Disabled Interfaces and Decommissioned Switches] フォルダの下に表示されます。

[Remove from Controller] オプションを使用すると、スイッチが ACI ファブリックおよびすべての APIC から完全に削除されます。登録済みのノードと割り当てられたインフラストラクチャ VTEP IP アドレスが削除されるので、スイッチはファブリック メンバーシップに表示されなくなります。

ACI ファブリックからスイッチをデコミッションするには、次の手順を実行します。

1. メニュー バーで、[Fabric] を選択します。

2. [Navigation] ペインで、[Inventory] > [Pod 1] を選択します。

3. [Navigation] ペインでデコミッションするスイッチをクリックします。

1. [General] タブをクリックします。

2. [Actions] > [Decommission] の順に選択します。

3. ポップアップで、[Regular] または [Remove from Controller] を選択します。

4. [送信（Submit）] をクリックします。

Cisco Nexus 9300 プラットフォーム スイッチから Cisco Nexus 9300 EX プラットフォーム スイッチへの移行

仮想ポート チャネル（vPC）内の Cisco Nexus 9300 プラットフォーム スイッチを Cisco Nexus 9300 EX プラットフォーム スイッチに移行するには、次の手順を実行します。

手順

ステップ 1

Cisco Nexus 9300 プラットフォーム スイッチからケーブルを取り外します。スイッチの電源を切ります。

ステップ 2

Cisco APIC にログインします。

ステップ 3

Fabric > Inventory > Unreachable Nodes を選択します。

ノードが到達不可能なことを確認します。[ノード名] と [ノード ID] のノードを作成します。

ステップ 4

ノードを選択します。[アクション] メニューから、[コントローラから削除] を選択します。

Cisco APIC からノードが削除されるまで 5 ～ 10 分間待機します。

ステップ 5

Cisco Nexus 9300 プラットフォーム スイッチ上のトラフィックをモニタします。すべてのトラフィックはその他の Cisco Nexus 9300 プラットフォーム スイッチによって処理されると、トラフィックへの影響が最小限になるか、影響を受けません。

ステップ 6

Cisco Nexus 9300 EX プラットフォームのスイッチと Cisco Nexus 9300 プラットフォーム スイッチを交換します。

ステップ 7

Cisco Nexus 9300 EX プラットフォーム スイッチの電源をオンにして、ケーブルを接続します。

ステップ 8

Cisco Nexus 9300 EX プラットフォームで Cisco APIC リリース 3.0 (1) ソフトウェアをロードします。スイッチを起動します。

ステップ 9

Cisco APIC にログインします。

ステップ 10

Fabric > Inventory > Fabric Membership を選択します。

スイッチが表示されていることを確認します。

ステップ 11

手順 3 から [ノード名] と [ノード ID] を Cisco Nexus 9300 EX プラットフォーム スイッチに割り当てます。

ステップ 12

すべての関連するポリシーが Cisco Nexus 9300-EX プラットフォーム スイッチにプッシュされ、エンドポイントの同期が完了するまで数分間待機します。確認のため、[操作] > [容量ダッシュ ボード] を選択します。このスイッチのポート チャネルは有効になっていません。

ステップ 13

その他の Cisco Nexus 9300 プラットフォーム スイッチからケーブルを取り外します。スイッチの電源を切ります。

ステップ 14

その他の Cisco Nexus 9300 プラットフォーム スイッチで手順 1-12 を繰り返します。

新しい APIC の追加

Application Policy Infrastructure Controller (APIC) クラスタに変更を加える前に、クラスタ内の各 APIC 完全に適合していることを確認し、クラスタに追加する新しいコントローラを反映するために、クラスタのサイズを変更します。クラスタの状態を検証するには、次の手順を実行します。

1. メニューバーで、 [System] > [Controllers] を選択します。

2. [Navigation] ペインで [Controllers] を選択します。

1. フォルダの最初の APIC を展開します。

2. [Cluster as Seen by Node] フォルダをクリックします。

3. すべてのコントローラが [Heath State] 列の下で [Fully Fit] と表示されていることを確認します。

APIC のいずれかが完全に適合していない場合は、『Cisco APIC Troubleshooting Guide』を参照してください。

APICconrefAPIC のクラスタ サイズを変更するには、次の手順を実行します。

1. メニュー バーで、[System] > [Controllers] の順に選択します。

2. ナビゲーション ウィンドウで、[Controllers] > APIC[_Name] > [Cluster as Seen by Node（ノードごとに表示されるクラスタ）] を選択します。

3. [Work] ペインで、[Actions] > [Change Cluster Size] の順に選択します。

1. 追加される新しい APIC を反映するように、ターゲット クラスターの管理サイズを変更します。

注：2 台によるクラスタ構成 は APIC 間の利用台数を満たさないため、使用できません。

4. [Submit] をクリックします。`

クラスタに新しい APIC を追加するには、次の手順を実行します。

1. 次のハードウェア インストール ガイドに従って、APIC をファブリックに接続することで APIC をインストールし、設定します。

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-installation-guides-list.html

2. メニュー バーで、[System] > [Controllers] の順に選択します。

3. ナビゲーション ウィンドウで、[Controllers] > [APIC _Name] > [Cluster]の順に選択します。

1. APIC コントローラは 1 つずつ追加され、N + 1 から順次ターゲット クラスタのサイズに達成するまで表示されます。

2. APIC コントローラが動作状態にあることを確認し、新しいコントローラの下の [Cluster] フォルダから各コントローラのヘルス状態が [Fully Fit] であることを確認します。

（注）

APIC が同期し、新しい APIC がクラスタに参加するまでには数分かかります。ファブリック処理は正常に継続します。

既存の APIC のデコミッション

Cisco Application Policy Infrastructure Controller（Cisco APIC）をデコミッションするときは、逆の順序で順次デコミッションする必要があります。たとえば、APIC5 は APIC4 の前にデコミッションする必要があります。また、Cisco APIC クラスタに変更を加える前に、デコミッションしている故障した Cisco APIC を除くクラスタ内の各 Cisco APIC が完全にクラスタリングされていることを確認します。電源が ON でクラスタに組み込まれた Cisco APIC をデコミッションすることはできません。

（注）

（Cisco TACから何らかの指示がある場合）ワイプ後に Cisco APIC を交換または再追加する目的で Cisco APIC を廃止する場合は、decommissionコマンドとrecommissionコマンドの実行の間に少なくとも10分間待機します。これを行わないと、クラスタの競合が発生し、最悪の場合、トラフィック転送が中断する可能性があります。

ファブリックから取り外す必要のある Cisco APIC をデコミッションするには、次の手順を実行します。

1. メニュー バーで、[System] > [Controllers] の順に選択します。

2. [Navigation] ペインで、[Controllers] > [APIC_Name] > [Cluster] の順に選択します。

（注）

注：Cisco APICデコミッションされていない APIC を選択します。

3. [Work] ペインで、[Actions] > [Change Cluster Size] の順に選択します。

1. 追加される新しい Cisco APIC を反映するように、ターゲット クラスターの管理サイズを変更します。

（注）

2 台によるクラスタ構成 は Cisco APIC 間の利用台数を満たさないため、使用できません。

4. [Submit] をクリックします。`

5. [Navigation] ペインで、[Controllers] > [APIC_Name] > [Cluster] の順に選択します。

（注）

メイン ペインで、デコミッションする Cisco APIC をクリックします。

6. [Work] ペインで、[Actions] > [Actions] > [Decommission] の順に選択します。

1. Cisco APICが残りの Cisco APIC のいずれの [Cluster] フォルダーにも表示されなくなったことを確認します。

ハードウェアの診断と交換

Cisco Application Centric Infrastructure (Cisco ACI) ファブリックは、平均故障間隔 （MTBF） と平均修復時間 （MTTR） を減らすよう、専用に設計された主要なソフトウェアおよびハードウェアの機能の組み合わせを採用しています。ハードウェアについては、シャーシに固定されているコンポーネントに加え、リーフ スイッチとスパイン スイッチの両方に複数のホットスワップ可能なコンポーネントがあります。ACME が何らかの電源サージを検知した場合や、スイッチのコンポーネントが故障したことを確認すると、ホットスワップ可能なコンポーネントによって、故障したハードウェアを迅速に、かつサービスを中断することなく交換することができます。

（注）

通常はハードウェアを交換の手順では、新しいハードウェアが交換するハードウェアと同じになることが期待されています。

リーフ スイッチとスパイン スイッチの両方でホットスワップ可能なコンポーネントの例は次のとおりです。

- 電源装置

- ファン トレイ

スパインのホットスワップ可能なコンポーネントの例は次のとおりです。

- 電源装置

- ファン トレイ

- スーパーバイザ

- システム コントローラ カード

- ラインカード モジュール

MTBF を減らす上記のコンポーネントの著しい進歩にもかかわらず、スイッチのハードウェアまたはソフトウェア、またはリーフのスイッチ交換が必要な両者の組み合わせにおいて、リーフ スイッチの障害が発生する可能性があります。このようなイベントで、 Cisco ACI ファブリックのステートレスな性質は、オペレーションの観点から管理者に大きな利点があります。

- ハードウェアフォールトの識別

- リーフ ハードウェアフォールトの解決

- APIC ハードウェアフォールトの解決

- 機器のフォールトの診断

- vPC ペアの一部である、リーフ スイッチを交換するときのガイドライン

ハードウェアフォールトの識別

ハードウェアフォールトがファブリックで発生した場合、エラーがシステムのダッシュボードに上がり、管理者に表示されます。冗長なコンポーネントがシステムに存在している状態でコンポーネント レベルのフォールトがある場合は、syslog メッセージおよび SNMP トラップが生成されます。

syslog メッセージおよび SNMP トラップを生成するハードウェア イベントの例は次のとおりです。

- スパイン スイッチのラインカード フォールト

- スパイン スイッチのスーパーバイザ フォールト

- スパイン スイッチのシステム コントローラのフォールト

- リーフ スイッチまたはスパイン スイッチの電源またはファンのフォールト

Cisco Application Policy Infrastructure Controller（APIC）がファブリック全体に対する管理の中心点である一方で、運用チームは既存の NMS ツールを活用できます。ロギング メッセージは Splunk などの syslog サーバに、SNMP メッセージは ZenOSS などの NMS システムに送信し、アラートを提供できます。ACI ファブリックのリーフ スイッチおよびスパイン スイッチは、設定された間隔で SNMP ポーリングなどのフォールトを検出する従来の方法もサポートしています。応答が一定期間スイッチから受信されない場合は、ハードウェアが故障した可能性があります。

ただし、リーフ スイッチおよびスパイン スイッチがコンポーネント レベルのフォールトに関する SNMP および Syslog メッセージを報告する一方で、APIC 自体には SNMP または syslog を使用してアラートを生成する機能がありません。たとえば、APIC の電源フォールトは SNMP または syslog メッセージを生成せず、APIC ダッシュボードを使用してモニタされ、修復される必要があります。

リーフ ハードウェアフォールトの解決

リーフフォールトの一例として、ファブリックの一部である Nexus 9396 リーフ スイッチが、アップリンク モジュール上のハードウェアフォールトによって到達不能になる可能性が考えられます。GUI を使用して、ノードの状態を判断してリーフが故障していることを確認できます。

ノードのヘルス スコアを表示するには、次の手順を実行します。

1. メニュー バーで、[Fabric] > [Inventory] の順に選択します。

2. [Navigation] ペインで、[Pod 1] を選択します。

注：ポッドの状態が [Work] ペインに表示され、ゼロとなっています。

リーフ ノードにフォールトが発生したことを確認したら、フォールトが発生したスイッチを取り外し、ファブリックの一部として新しいスイッチをプロビジョニングする必要があります。故障したスイッチを交換する最初の手順は、故障したスイッチの固有 ID（ノードID）を取得することです。各ノードには、ファブリック内で ID が割り当てられます。この ID は、新しいシリアル番号を持つ交換用スイッチが古いノードに割り当てられていたものと同じステートレスな設定を継承できるようにする参照オブジェクトです。

GUI を使用してファブリック ノード ID を表示するには、次の手順を実行します。

1. メニュー バーで、[Fabric] > [Inventory] の順に選択します。

2. [Navigation] ペインで、[Fabric Membership] を選択します。

次の例に示すように、あるヘルス レベル以下のノードの完全なリストを定期的にポーリングするために単一の REST API コールを使用することもできます。

{{protocol}}://{{apic}}/api/class/topSystem.xml?rsp-subtree-include=health&rspsubtree-
filter=le(healthInst.cur,"0")

各スイッチが独立したエンティティとして管理された従来の運用モデルの場合は、次の手順によってスイッチを交換します。

1. 交換用スイッチを立ち上げます。

2. 正しいコードのバージョンをロードします。

3. 設定リポジトリ サーバから設定の最新バージョンの取得を試みます。

4. 正しいコンフィギュレーション ファイルでデバイスを段階分けし、エラーを排除します。たとえば、AAA、NTP、および syslog サーバと、それぞれに関連付けられている ACL を更新します。

5. 古い設定をスイッチに上書きコピーします。

6. リンクを 1 つずつ起動し、データ トラフィックが正しく流れているかどうかを確認します。

ACI ファブリックで、ハードウェアのステートレスな性質を活用して、論理的な設定プロファイルをインスタンス化できます。ノードの交換は、スイッチのデコミッションおよびリコミッションと同様に簡単です。

スイッチをデコミッションおよびリコミッションするには、次の手順を実行します。

1. メニュー バーで、[Fabric] > [Inventory] の順に選択します。

2. [Navigation] ペインで、[Pod 1] を展開します。

3. フォールトが発生したノードを右クリックし、[Decommission] を選択します。

4. フォールトが発生したリーフ スイッチを新しいリーフ スイッチと交換します。

5. メニュー バーで、[Fabric] > [Inventory] の順に選択します。

6. [Navigation] ペインで、[Fabric Membership] を選択します。

7. 新しいリーフがノード ID が 0、IP アドレスが 0.0.0.0 として表示されます。

8. [Work] ペインで、新しいリーフをクリックします。

9. [Actions] > [Commission Switch] の順に選択します。

10. ノード ID の入力を求められたら、古いノードの ID を入力します。ほとんどの場合、同じリーフ名を再利用できます。

11. [Update] をクリックします。

新しいスイッチが動作していない場合は、新しいスイッチの名前とノード ID が入力した名前と ID と異なっています。到達不能ノードを表示して、名前と ID を取得できます。

到達不能ノードを表示するには、次の手順を実行します。

1. メニュー バーで、[Fabric] > [Inventory] の順に選択します。

2. [Navigation] ペインで、[Unreachable Nodes] を選択します。

3. 新しいスイッチを検索し、その名前とノード ID を記録します。

4. 「スイッチをデコミッションおよびリコミッションする」手順のステップ 5 から繰り返します。名前とノード ID の入力を求められたら、前の手順で記録した情報を入力します。

新しいリーフ スイッチが正常に作動すると、APIC はリーフにファームウェアの正しいバージョンを自動的にロードします。

APIC がロードするファームウェアのバージョンを表示するには、次の手順を実行します。

1. メニュー バーで、[Admin] > [Firmware] の順に選択します。

2. [Navigation] ペインで、[Fabric Node Firmware] > [Firmware Groups] > [All] の順に選択します。

注：[Work] ペインで、最新のファームウェア バージョンに自動的に設定されるターゲット ファームウェアのバージョンを確認できます。

さらに、デバイス上の従来の実行コンフィギュレーションを置き換えるステートレス オブジェクト モデルを利用して、APIC は AAA、syslog、SNMP、NTP、ACL、ブリッジ ドメイン、EPG などのデバイスに正しい実行コンフィギュレーションを自動的にロードします。

交換用スイッチが ACI スイッチ ソフトウェアではなくスタンドアロンの NX-OS ソフトウェアを実行している場合は、場合によって当該スイッチに ACI スイッチのソフトウェア イメージをコピーする必要があります。

ACI スイッチのソフトウェア イメージをスイッチにコピーするには、次の手順を実行します。

1. スイッチ コンソールに接続します。

2. スイッチと APIC 間の接続を許可するように mgmt0 インターフェイスに IP アドレスを設定します。

3. 次のように SCP サービスを有効にします。

# feature scp-server

4. 次のように APIC からファームウェア イメージをスイッチにコピーします。

# scp -r /firmware/fwrepos/fwrepo/switch_image_name
admin@switch_ip_address :switch_image_name

5. デュアル スーパーバイザ システムの場合は、次のコマンドを使用してシャーシ全体の交換に備えてイメージがスタンバイ スーパーバイザにコピーされていることを確認します。

# copy bootflash:aci_image bootflash://sup-standby/

6. Cisco NX-OS から起動しないようにスイッチを設定します。

switch(config)# no boot nxos

7. 設定を保存します。

switch(config)# copy running-config startup-config

8. ACI イメージでアクティブおよびスタンバイ スーパーバイザ モジュールを起動します。

switch(config)# boot aci bootflash:aci-image-name

9. MD5 チェックサムを表示して、ファイルの整合性を確認します。

switch(config)# show file bootflash:aci-image-name md5sum

10. スイッチをリロードします。

switch(config)# reload

11. 管理者としてスイッチにログインします。

Login: admin

12. デバイスの証明書をインストールする必要があるかどうかを確認します。

admin@apic1:aci> openssl asn1parse /securedata/ssl/server.crt

13. コマンド出力で PRINTABLESTRING を検索します。「シスコが製造元の CA」がリストされている場合は、正しい証明書がインストールされます。他のものがリストされている場合は、デバイスに正しい証明書を生成しインストールする方法について TAC にお問い合わせください。

証明書がインストールされ、スイッチが ACI モードであることを確認したら、スイッチはファブリックへの接続時に管理対象外のファブリック ノードとして表示されます。

APIC ハードウェアフォールトの解決

この例では、APIC クラスタ内の APIC のいずれかでハードウェアフォールトを特定して修復する必要があります。

操作可能な APIC の GUI から、次の手順を実行します。

1. メニュー バーで、[System] > [Controllers] の順に選択します。

2. [Navigation] ペインで、[Controllers] > [APIC_Name] > [Cluster] の順に選択します。

注：[Work] ペインに、フォールトが発生した APIC が「Unavailable」の動作状態で表示されます。

3. フォールトが発生した APIC のファブリック名、ターゲット サイズ、ノード ID、および TEP アドレス空間を記録します。この情報は、APIC の CLI で acidiag avread コマンドを使用することでも入手可能です。

4. [Work] ペインで、フォールトが発生した APIC をクリックして選択します。

5. [Actions] > [Decommission] の順に選択します。APIC が「Out of Service」の管理状態に変わります。

6. フォールトが発生した APIC をラックから取り外し、代替品をインストールします。新しい APIC は初期セットアップ スクリプトにブートする必要があります。

7. セットアップ スクリプトを実行し、ステップ 3 で記録したフォールトが発生した APIC の値を入力します。同じ設定で APIC を設定しないと、ファブリックが部分的に発散した状態になります。

8. 新しい APIC の起動が終了したら、[Navigation] ペインで [Controllers] > [apic_name] > [Cluster] の順の選択します。任意の APIC を選択できます。

9. [Work] ペインで、新しい APIC をクリックして選択します。

10. [Actions] > [Commission] の順に選択します。

11. 新しい APIC が、APIC GUI に反映される IP アドレスを受信します。これが発生するまでに 5 ～ 10分かかる場合があります。また、新しい APIC は、Fully Fit 状態になる前に Available 動作状態と Unavailable 動作状態の間を行き来する場合があります。

12. 新しい APIC のコマンド ラインで、残りのファブリックに設定されているクレデンシャルを使用してログインすることで、ファブリックに参加していることを確認できます。

機器のフォールトの診断

ACI ファブリックはブートアップ、ランタイムおよびオンデマンド診断を提供します。これは各リーフ スイッチおよびスパイン スイッチ上の複数のサブシステムのハードウェア状態の評価に役立ちます。

1. ブートアップ テストは、スイッチ カードが起動したときに実行します。これらは通常、ディスラプティブ テストのみです。デフォルトのテストのセットが付属しており、変更することができます。セレクタを介して展開されます。

2. ヘルス（別名進行中）テストは定期的に実行します。ノンディスラプティブ テストのみを実行できます。変更が可能なデフォルトのテストのセットが付属しており、セレクタを介して展開されます。

3. オンデマンド テストは、トラブルシューティングのために特定のポートまたはカードで実行され、デフォルトはなく、破壊的である可能性があります。

デフォルトで、テストは論理的にコレクションにグループ化されます。

デフォルトの診断ポリシーを調べるには、[fabric] > [fabric policies] > [Monitoring policies] > [default] > [diagnostics policy] の順にクリックします。

[Work] ペインで、診断モニタリング ポリシーを表示するファブリックの要素を選択します。

テスト結果は、次の順にクリックすることで表示できます。

[Fabric] > [Inventory] > [Pod-1] > [Leaf-xx or Spine-xx] > [Chassis] > [Supervisor modules] > [Slot-1]

AND

[Fabric] > [Inventory] > [Pod-1] > [Leaf-xx or Spine-xx] > [Chassis] > [Line modules] > [Slot-1]

ここで、スーパーバイザの GOLD 診断結果を表示するには、[Work] ペインで [Troubleshooting] タブを選択します。

Cisco Nexus 9500 シリーズ スイッチなどのモジュラ シャーシ ベースのシステムでは、診断結果はシステム内のすべてのスーパーバイザ、モジュール、システム コントローラおよびファブリック モジュールに使用できます。

vPC ペアの一部である、リーフ スイッチを交換するときのガイドライン

ｖPC ペアの一部であるリーフ スイッチを交換するときに、次のガイドラインが適用されます。

- 第 1 世代のスイッチでは、第 1 世代の他のスイッチとのみ互換性があります。スイッチ名の末尾に「EX」または「FX」がないので、これらのスイッチ モデルを識別できます。たとえば、N9K-9312TX です。

- 第 2 世代以降のスイッチは、vPC ドメインで混在させることができます。これらのスイッチ モデルは、「EX」、「FX」、または「FX2」がスイッチ名の末尾に付くため、識別できます。たとえば、N9K-93108TC-EX や N9K-9348GC-FXP。

- スイッチのペアを交換するときに vPC ピア リーフ スイッチが一致する必要があり、システム一時停止します。

互換性のある vPC スイッチ ペアの例を次に示します。

- N9K-9312TX および N9K-9312TX

- N9K-93108TC-EX および N9K-9348GC-FXP

- N9K-93180TC-FX および N9K-93180YC-FX

- N9K-93180YC-FX および N9K-93180YC-FX

互換性のない vPC スイッチ ペアの例を次に示します。

- N9K-9312TX および N9K-93108TC-EX

- N9K-9312TX および N9K-93180YC-FX

また、vPC をブレークするために設定を変更するか、新しい vPC ペアとしてスイッチを導入し、ノード間の設定を移行することができます。

付録

- クラス

- パッケージ デコーダ

- 頭字語とその定義

- 参考資料

クラス

Application Policy Infrastructure Controller（APIC）のクラスは、システム イベントおよびフォールトがオブジェクト モデル内のオブジェクトとどのように関連しているかを理解するために操作面で重要です。システムの各イベントやフォールトは、設定、正常性、フォールト、および/または統計情報にアクセスできる固有のオブジェクトです。

アプリケーション セントリック インフラストラクチャ ファブリックを構成するすべての物理および論理コンポーネントは、階層管理情報ツリー（MIT）で表されます。このツリー内の各ノードは、管理ステータスと動作ステータスを含む、管理対象オブジェクト（MO）またはオブジェクトのグループを表します。

プログラムの REST API は、REST アーキテクチャを使用します。API は、JSON または XML ドキュメントを含む HTTP または HTTPS メッセージを受け入れて返します。プログラミング言語を使用して、API メソッドまたは管理対象オブジェクト（MO）の説明を含むメッセージおよび JSON または XML ドキュメントを生成できます。

HTTP/1.1 または HTTPS POST、GET、または DELETE メッセージを APIC に送信することで、API 機能を呼び出すことができます。POST メッセージの HTML 本文には、MO または API メソッドを記述する JSON または XML データ構造が含まれます。応答メッセージの HTML 本文は要求されたアクションが要求されたデータ、確認、エラー情報が含まれる JSON または XML 構造が含まれます。

クラスの完全なリストにアクセスするには、APIC を指定し、URL の最後で doc/html ディレクトリを参照します。

https://apic_ip_address/doc/html/

- ファブリックのモニタリング

- VM_Monitoring

- レイヤ 4 ～レイヤ 7 のモニタリング

- 統計情報

- Authentication, Authorization, and Accounting（認証、許可、およびアカウンティング）

- ファブリックの容量

- SNMP および syslog

- 使用例

ファブリックのモニタリング

topSystem

名前：top:System

説明：コントローラ、リーフおよびスパインなど、ファブリック内のすべてのデバイスのリストを提供します。

使用：topSystem クラスは、inb/oob 管理の詳細、現在時刻、システムの稼働時間と現在の状態を含むオブジェクト プロパティを取得するために使用できます。

topSystem REST :: https://172.16.96.2/api/node/class/topSystem.json

fabricNode

名前：fabric:Node

説明：コントローラ、リーフおよびスパインなど、ファブリックの一部であるすべてのノードのリストを提供します。

使用：fabricNode クラスは、ノードのシリアル番号、割り当てられたノード ID、ノードのモデル番号とデバイス ロールを含むオブジェクト プロパティを取得するために使用できます。

fabricNode REST :: https://172.16.96.2/api/node/class/fabricNode.json

faultInst

名前：fault:Inst

説明：フォールトの詳細情報が含まれます。このオブジェクトは、フォールト状態が発生したオブジェクトの子としてアタッチされます。親オブジェクトの各フォールト状態に対し 1 つのインスタンス オブジェクトが作成されます。フォールト インスタンス オブジェクトはフォールト コードで識別されます。

使用：faultInst クラスは、APIC 内のファブリック、テナントまたは個々の管理対象オブジェクトに関連付けられたすべてのフォールトを取得するために使用できます。

faultInst REST :: https://172.16.96.2/api/node/class/faultInst.json

fabricHealthTotal

名前：fabric:HealthTotal

説明：ファブリックの総ヘルス スコア インスタンス。

使用：fabricHealthTotal クラスは、システム全体の状態を取得するために使用できます。

fabricHealthTotal REST :: https://172.16.96.2/api/node/class/fabricHealthTotal.json

fvCEp

名前：fv:CEp

説明：ネットワークにアタッチしているクライアント エンドポイント。

使用：fvCEp クラスは、ファブリックにアタッチされたエンド ポイントおよび関連付けられている IP/MAC アドレス、および各オブジェクトのカプセル化のリストを取得するために使用できます。

fvCEp REST :: https://172.16.96.2/api/node/class/fvCEp.json

fvRsCEpToPathEp

名前：fv:RsCEpToPathEp

説明：これは、パスのエンドポイントとの関係を提供する内部オブジェクトです。

使用：fvRsCEpToPathEp クラスは、ノードおよびポートなどのパスのファブリック詳細と、テナント名、アプリケーション プロファイルおよびエンドポイント グループなどのテナントの詳細を取得するために使用できます。

fvRsCEpToPathEp REST :: https://172.16.96.2/api/node/class/fvRsCEpToPathEp.json

eqptFabP

名前：eqpt:FabP

説明：ファブリック ポート、外部 IO ポートに向いているファブリック。

使用：eqptFabP クラスは、ファブリック ポートと、ラインカードやシャーシの位置などの関連情報のリストを取得するために使用できます。

eqptFabP REST :: https://172.16.96.2/api/node/class/eqptFabP.json

eqptLeafP

名前：eqpt:LeafP

説明：ファブリック ポート、外部リーフ IO ポートに向いている非ファブリック。

使用：eqptFabP クラスは、非ファブリック ポートと、ラインカードやシャーシの位置などの関連情報のリストを取得するために使用できます。

eqptLeafP REST :: https://172.16.96.2/api/node/class/eqptLeafP.json

eqptCh

名前：eqpt:ChA

説明：ハードウェアのシャーシ コンテナ。

使用：eqptCh クラスは、シャーシのリストと、動作状態、シリアル番号、モデル番号などの関連情報を取得するために使用できます。

eqptCh REST :: https://172.16.96.2/api/node/class/eqptCh.json

eqptLC

名前：eqpt:LCA

説明：IO ポートを含むラインカード（IO カード）。

使用：eqptLC クラスは、ファブリック内に展開されたラインカードと、冗長化の状態、モデル、シリアル番号、ポート数などの関連情報のリストを取得するために使用できます。

eqptLC REST :: https://172.16.96.2/api/node/class/eqptLC.json

eqptFt

名前：eqpt:Ft

説明：インベントリ化されているファン トレイ。

使用：eqptFt クラスは、ファン トレイと、動作状態、モデル番号、シリアル番号、ハードウェア バージョンなどの関連情報のリストを取得するために使用できます。

eqptFt REST :: https://172.16.96.2/api/node/class/eqptFt.json

eqptPsu

名前：eqpt:Psu

説明：電源装置。

使用：eqptFt クラスは、ファブリック内の電源装置と、モデル番号、シリアル番号、動作ステータス、電圧源などの関連情報のリストを取得するために使用できます。

eqptPsu REST :: https://172.16.96.2/api/node/class/eqptPsu.json

eqptSupC

名前：eqpt:SupC

説明：コントロール プレーンを実行中の CPU を含む、スーパーバイザ カード。

使用：eqptFt クラスは、ファブリック内に展開されたスーパーバイザ カードと、モデル番号、シリアル番号、動作ステータス、冗長化の状態などの関連情報のリストを取得するために使用できます。

eqptSupC REST :: https://172.16.96.2/api/node/class/eqptSupC.json

ethpmPhysIf

名前：ethpm:PhysIf

説明：物理インターフェイスの情報ホルダー。

使用：ethpmPhysIf クラスは、ファブリック内の物理インターフェイスと、速度、デュプレックス、動作ステータス、使用状態などの関連情報のリストを取得するために使用できます。

ethpmPhysIf REST :: https://172.16.96.2/api/node/class/ethpmPhysIf.json

dbgAcTrail

名前：dbg:AcTrail

説明：アトミック カウンタ証跡。

使用：dbgAcTrail クラスは、ファブリック内に展開されたアトミック カウンタと、ドロップされたパケット統計情報やパケット数などの関連情報のリストを取得するために使用できます。

dbgAcTrail REST :: https://172.16.96.2/api/node/class/dbgAcTrail.json

dbgEpgToEpgRslt

名前：dbg:EpgToEpgRslt

説明：エンドポイント グループからエンドポイント グループへのアトミック カウンタ、オンデマンド、エントリ。

使用：dbgEpgToEpgRsIt クラスは、ファブリック内に展開された EPG から EPG へのアトミック カウンタと、ドロップされたパケット統計情報やパケット数などの関連情報のリストを取得するために使用できます。

dbgEpgToEpgRsIt REST :: https://172.16.96.2/api/node/class/dbgEpgToEpgRslt.json

dbgEpToEpRslt

名前：dbg:EpToEpRslt

説明：エンドポイントからエンドポイントへのアトミック カウンタ、オンデマンド、エントリ。

使用：dbgEpToEpTsIt クラスは、ファブリック内に展開されたエンドポイントからエンドポイントへのアトミック カウンタと、ドロップされたパケット統計情報やパケット数などの関連情報のリストを取得するために使用できます。

dbgEpToEpTsIt REST :: https://172.16.96.2/api/node/class/dbgEpToEpRslt.json

VM_Monitoring

compVm

名前：comp:Vm

説明：仮想マシン オブジェクト。

使用：compVm クラスは、ファブリック内に展開された仮想マシンと、名前や状態などの関連情報のリストを取得するために使用できます。

compVm REST :: https://172.16.96.2/api/node/class/compVm.json

compHv

名前：comp:Hv

説明：コンピューティング ハイパーバイザを表すオブジェクト。

使用：compVm クラスは、ファブリック内に展開されたコンピューティング ハイパーバイザと、名前やステータスなどの関連情報のリストを取得するために使用できます。

compHv REST :: https://172.16.96.2/api/node/class/compHv.json

fvRsVm

名前：fv:RsVm

説明：ハイパーバイザに接続された仮想マシンとの関係。これは内部オブジェクトです。

使用：fvRsVm クラスは、ハイパーバイザに接続された仮想マシンの関係を取得するために使用できます。

vRsVm REST :: https://172.16.96.2/api/node/class/fvRsVm.json

fvRsHyper

名前：fv:RsHyper

説明：APIC VM を制御およびモニタするハイパーバイザとの関係。これは内部オブジェクトです。

使用：fvRsHyper クラスは、APIC VM を制御およびモニタするハイパーバイザの関係を取得するために使用できます。

fvRsHyper REST :: https://172.16.96.2/api/node/class/fvRsHyper.json

vmmCtrlrP

名前：vmm:CtrlrP

説明：VMM コントローラ プロファイル。ポリシー適用のドメインを含めることの一部である単一の VM 管理コントローラへの接続方法を指定します。たとえば、VMM コントローラ プロファイルは、VMM ドメインの一部である VMware vCenter に接続するためのポリシーにできます。

使用：vmmCtrlrP クラスは、接続された VM ドメインの IP アドレスとデータセンター名を取得するために使用できます。

vmmCtrlrP REST :: https://172.16.96.2/api/node/class/vmmCtrlrP.json

レイヤ 4 ～レイヤ 7 のモニタリング

vnsAbsGraph

名前：vnsAbsGraph

説明：抽象グラフは、抽象的なノードから構成され、ロード バランシング、SSL オフロード、またはファイアウォールなどのサービス機能によるトラフィック フローを定義するために使用されます。抽象的なノードは、サービス ノード バランサ（SLB）またはファイアウォール（FW）などのサービス ノード、抽象的な条件ノード（エンドポイント グループに接続されているノード）、および接続から構成されます。

使用：クラス vnsAbsGraph は、APIC で設定されたサービス グラフ テンプレートとそのプロパティのリストを取得するために使用できます。

vnsAbsGraph  REST :: https://172.16.96.2/api/node/class/vnsAbsGraph.json

vnsLDevVip

名前：vnsLDevVip

説明：L4-L7 デバイス クラスタ。単一の仮想 IP（VIP）によって表されます。設定は、VIP アドレスにプッシュ ダウンされます。

使用：クラス vnsLDevVip は、ファブリック内の論理デバイス クラスタ用に設定されたすべての VIP を取得するために使用できます。

vnsLDevVip  REST :: https://172.16.96.2/api/node/class/vnsLDevVip.json

vnsCDev

名前：vnsCDev

説明：個々のサービス デバイス。具体的な L4-L7 サービス デバイスを定義するために使用されます。

使用：クラス vnsCDev は、L4-L7 サービス統合の一部として設定された具体的なデバイスのリストを取得するために使用できます。

vnsCDev  REST :: https://172.16.96.2/api/node/class/vnsCDev.json

vnsLif

名前：vnsLif

説明：L4-L7 デバイス クラスタからの具体的なインターフェイスのセットに関連付けられている論理インターフェイス。

使用：クラス vnsLif は、サービス グラフとデバイス インターフェイス間の接続を取得するために使用できます。

vnsLif  REST :: https://172.16.96.2/api/node/class/vnsLIf.json

vnsLDevCtx

名前：vnsLDevCtx

説明：コントラクト、サブジェクト、機能ラベルまたは名前に基づいて特定のデバイスを選択するのに使用されるデバイス クラスタを指すデバイス クラスタ コンテキスト。ワイルドカードを指定するには、名前を [Any] に設定します。

使用：クラス vnsLDevCtx は、ノードおよびコントラクト名を取得するために使用できます。

nsLDevCtx  REST :: https://172.16.96.2/api/node/class/vnsLDevCtx.json

vnsRsLDevCtxToLDev

名前：vnsRsLDevCtxToLDev

説明：サービス デバイス クラスタまたはテナント内の論理デバイス クラスタ用のプロキシ オブジェクトの抽象化に対する送信元の関係。

使用：クラス vnsRsLDevCtxToLDev は、vnsLDevCtx と vnsLDev 間の関係を取得するために使用できます。

vnsRsLDevCtxToLDev  REST :: https://172.16.96.2/api/node/class/vnsRsLDevCtxToLDev.json

統計情報

compHostStats1h

名前：comp:HostStats1h

説明：1 時間のサンプリング間隔におけるホストの最新の統計情報を表すクラス。このクラスは 15 分ごとに更新されます。

使用：compHostStats1h クラスは、コンピューティング ハイパーバイザに関連付けられた統計情報を取得するために使用できます。

compHostStats1h REST :: https://172.16.96.2/api/node/class/compHostStats1h.json

compRcvdErrPkts1h

名前：comp:RcvdErrPkts1h

説明：1 時間のサンプリング間隔における受信したエラー パケットの最新の統計情報を表すクラス。このクラスは 15 分ごとに更新されます。

使用：compRcvdErrPkts1h クラスは、受信したエラー パケットの最新の統計情報を取得するために使用できます。

compRcvdErrPkts1h REST :: https://172.16.96.2/api/node/class/compRcvdErrPkts1h.json

compTrnsmtdErrPkts1h

名前：comp:TrnsmtdErrPkts1h

説明：1 時間のサンプリング間隔における送信されたエラー パケットの最新の統計情報を表すクラス。このクラスは 15 分ごとに更新されます。

使用：compTrnsmtdErrPkts1h クラスは、送信されたエラー パケットの最新の統計情報を取得するために使用できます。

compTrnsmtdErrPkts1h REST :: https://172.16.96.2/api/node/class/compTrnsmtdErrPkts1h.json

Authentication, Authorization, and Accounting（認証、許可、およびアカウンティング）

aaaModLR

名前：aaa:ModLR

説明：AAA の監査ログ レコード。ログ レコードは、ユーザがオブジェクトを変更するたびに自動的に生成されます。

使用：aaaModLR クラスは、すべての変更およびイベントに関するファブリック ベースの監査ログを取得するために使用できます。

aaaModLR REST :: https://172.16.96.2/api/node/class/aaaModLR.json

aaaUser

名前：aaa:User

説明：ローカル認証されたユーザ アカウント。

使用：aaaUser クラスは、ファブリック内に展開されたユーザ アカウントのリストを取得するために使用できます。

aaaUser REST :: https://172.16.96.2/api/node/class/aaaUser.json

aaaRemoteUser

名前：aaa:RemoteUser

説明：リモート ユーザのログイン アカウント。

使用：aaaUser クラスは、ファブリック内に展開されたリモート ユーザ アカウントのリストを取得するために使用できます。

aaaRemoteUser REST :: https://172.16.96.2/api/node/class/aaaRemoteUser.json

ファブリックの容量

ポリシー TCAM

名前：eqptcapacityPolEntry5min

説明：ポリシー CAM エントリの統計情報。5 分間のサンプリング間隔におけるポリシー エントリの最新の統計情報を表すクラス。このクラスは 10 秒ごとに更新されます。

使用：eqptcapacityPolEntry5min クラスは、ポリシー TCAM の使用に関連付けられた現在の値を取得するために使用できます。

eqptcapacityPolEntry5min REST :: https://172.16.96.2/api/class/eqptcapacityPolEntry5min.json

プレフィックス TCAM

名前：eqptcapacityL3Entry5min

説明：Layer3 エントリの統計情報。5 分間のサンプリング間隔における layer3 エントリの最新の統計情報を表すクラス。このクラスは 10 秒ごとに更新されます。

使用：eqptcapacityL3Entry5min クラスは、プレフィックス TCAM の使用に関連付けられた現在の値を取得するために使用できます。

eqptcapacityL3Entry5min  REST :: https://172.16.96.2/api/class/eqptcapacityL3Entry5min.json

SNMP および syslog

SNMP トラップの宛先

名前：snmpTrapDest

説明："background-color:rgb(255, 255, 255); color:rgb(51, 51, 51)"> トラップおよび通知が送信される宛先。

使用：snmpTrapDest クラスは、ファブリック内で実装される SNMP トラップ宛先の現在のリストを取得するために使用できます。

snmpTrapDest REST :: https://172.16.96.2/api/node/class/snmpTrapDest.json

syslog リモート宛先ホスト

名前：syslogRemoteDest

説明：syslog リモート宛先ホストによって、APIC およびファブリック ノードからのメッセージの転送先となる syslog サーバを指定できます。

使用：syslogRemoteDest クラスは、ファブリック内で実装される syslog リモート宛先の現在のリストを取得するために使用できます。

syslogRemoteDest REST :: https://172.16.96.2/api/node/class/syslogRemoteDest.json

使用例

次の使用例 #1 および #2 で使用されているクラス faultInst は、前述の、または APIC ドキュメント内で指定された、管理対象オブジェクト クラスのいずれかに置き換えることができます。『Cisco APIC Command-Line Interface User Guide』も、次の項を理解する上で役立ちます。

ケース 1：ファブリック内のフォールトの現在のリストを取得するためのアプリケーション スクリプトの作成。

この使用例は一般的に、ACI 管理者がファブリック内の現在のフォールトのリストを取得する環境向けです。ユーザには、CLI、Visore、POSTMAN および/または Cobra によって結果を収集するオプションがあります。アプリケーション固有のアクセスと説明については上記の項を参照してください。

CLI の観点からは、次のコマンドを使用してクエリを実行します。

admin@apic1:~> moquery -c faultInst

Visore の観点からは、次のパラメータを使用してクエリを実行します。

Class or DN    :: faultInst
Property       ::  n/a
Op             :: n/a
Value          ::  n/a

POSTMAN の観点からは、次の REST GET を使用してクエリを実行します。

GET http://<your apic ip address>/api/node/class/faultInst.xml

Cobra の観点からは、次のクラス クエリを使用します。

# Class Query
classQuery= ClassQuery(' faultInst')
for fault in md.query(classQuery):
print fault.name

次は、ファブリック内のフォールトをキャプチャするための Cobra スクリプトのサンプルです。

#!/usr/bin/env python
import cobra.mit.access
import cobra.mit.session
from cobra.mit.session import LoginSession
from cobra.mit.request import ClassQuery
ls = cobra.mit.session.LoginSession('https://'<your apic ip address>,  <username>,
<password>, secure=False)
md = cobra.mit.access.MoDirectory(ls)
md.login()
# Class Query
classQuery= ClassQuery(' faultInst')
for fault in md.query(classQuery):
print fault.name

ケース 2：設定の失敗によるファブリック内のフォールトの現在のリストを取得するためのアプリケーション スクリプトの作成。

この使用例は一般的に、ACI 管理者がファブリック内の現在のフォールトのリストを取得する環境向けです。ユーザには、CLI、Visore、POSTMAN および/または Cobra によって結果を収集するオプションがあります。アプリケーション固有のアクセスと説明については上記の項を参照してください。

CLI の観点からは、次のコマンドを使用してクエリを実行します。

admin@apic1:~> moquery -c faultInst -f 'fv.faultInst.cause=="config-failure"'

Visore の観点からは、次のパラメータを使用してクエリを実行します。

Class or DN    :: faultInst
Property       ::  cause
Op             :: ==
Value          ::  config-failure

POSTMAN の観点からは、次の REST GET を使用してクエリを実行します。

GET http:// <your apic ip address>/api/node/class/faultInst.xml?
query-target-filter=and(eq(faultInst.cause,"config-failure"))

Cobra の観点からは、次のクラス クエリを使用します。

# Class Query
classQuery= ClassQuery(' faultInst')
classQuery.propFilter = 'wcard(faultInst. cause, "{0}")'.format(' config-failure')
for fault in md.query(classQuery):
print fault.name

設定不良によるフォールトをキャプチャするための Cobra スクリプト。

#!/usr/bin/env python
import cobra.mit.access
import cobra.mit.session
from cobra.mit.session import LoginSession
from cobra.mit.request import ClassQuery
ls = cobra.mit.session.LoginSession('https://'<your apic ip address>,  <username>,
<password>, secure=False)
md = cobra.mit.access.MoDirectory(ls)
md.login()
# Class Query
classQuery= ClassQuery(' faultInst')
for fault in md.query(classQuery):
print fault.name

ケース 3：特定の管理対象オブジェクト DN のプロパティを取得するためのアプリケーション スクリプトの作成

この使用例は一般的に、ACI 管理者がテナント名 Common のプロパティを取得する環境向けです。ユーザには、CLI、Visore、POSTMAN および/または Cobra によって結果を収集するオプションがあります。アプリケーション固有のアクセスと説明については上記の項を参照してください。

CLI の観点からは、次のコマンドを使用してクエリを実行します。

admin@apic1:~> moquery -d uni/tn-common

Visore の観点からは、次のパラメータを使用してクエリを実行します。

Class or DN    :: uni/tn-common
Property       ::  n/a
Op             :: n/a
Value          ::  n/a

POSTMAN の観点からは、次の REST GET を使用してクエリを実行します。

GET http://<your apic ip address>/api/node/mo/uni/tn-common.xml?query-target=self

Cobra の観点からは、次のクラス クエリを使用します。

# DN Query
dnQuery= DnQuery(' uni/tn-common')
for results in md.query(dnQuery):
print results.dn

設定不良によるフォールトをキャプチャするための Cobra スクリプト。

#!/usr/bin/env python
import cobra.mit.access
import cobra.mit.session
from cobra.mit.session import LoginSession
from cobra.mit.request import DnQuery
ls = cobra.mit.session.LoginSession('https://'<your apic ip address>, <username>,
<password>, secure=False)
md = cobra.mit.access.MoDirectory(ls)
md.login()
# DN Query
dnQuery= DnQuery('uni/tn-common')
for results in md.query(dnQuery):
print results.dn

ケース 4：ファブリックにアタッチされているエンドポイント（MAC アドレス）の現在のリストを取得するためのアプリケーション スクリプトの作成

この使用例は一般的に、ファブリックにアタッチされている現在のエンドポイントのリストと、各エンドポイントに関連するノードの詳細をキャプチャするアプリケーション スクリプトを ACI 管理者が作成する環境向けです。

設定不良によるフォールトをキャプチャするための Cobra スクリプト。

#!/usr/bin/env python
from cobra.mit.access import MoDirectory
from cobra.mit.session import LoginSession
from cobra.mit.request import ClassQuery
lls = cobra.mit.session.LoginSession('https://'<your apic ip address>, <username>,
<password>, secure=False)
md = MoDirectory(ls)
md.login()
q = ClassQuery('fvCEp')
q.subtree = 'children'
q.subtreeClassFilter = 'fvRsCEpToPathEp'
mos = md.query(q)
for mo in mos:
for child in mo.rscEpToPathEp:
print child.dn

パッケージ デコーダ

ACI オブジェクト モデルのクラス名に使用される省略形がいくつかあります。次に、一般的に使用される省略形について説明します。これらは、クラス オブジェクトを REST コールで使用する際にクラス オブジェクトが何であるかを解読するときに役立ちます。

aaa：認証、許可、アカウンティング

ac：アトミック カウンタ

actrl：アクセス制御

actrlcap：アクセス コントロール機能

adcom：アプライアンス ディレクタ通信

aib：隣接関係情報ベース

arp：Address Resolution Protocol

bgp：Border Gateway Protocol

callhome：Cisco Smart Call Home サービス

cap：機能

cdp：Cisco Discovery Protocol

cnw：ノード クラスタ

comm：通信ポリシー

comp：コンピューティング

compat：互換性

condition：正常性ポリシー

config：設定ポリシー

coop：Council of Oracles プロトコル

copp：コントロール プレーン ポリシング ポリシー。ポリサー レートを説明する一連のルールが含まれます。

ctrlr：コントローラ

ctx：コンテキスト

datetime：日付/時刻ポリシー

dbg：デバッグ

dbgac：デバッグのアトミック カウンタ

dbgexp：デバッグのエクスポート ポリシー

dhcp：Dynamic Host Configuration Protocol

dhcptlv：Dynamic Host Configuration Protocol のタイプ、長さ、値

dhcptlvpol：Dynamic Host Configuration Protocol のタイプ、長さ、値ポリシー

dns：ドメイン名サービス
draw：GUI のグラフの可視化

epm：エンドポイント マネージャ

eqpt：機器

eqptcap：機器の機能

eqptcapacity：機器のキャパシティ

eqptdiag：機器の診断

eqptdiagp：機器の診断ポリシー

ethpm：イーサネット ポリシー マネージャ

event：イベント ポリシー

extnw：外部ネットワーク

fabric：ファブリック

fault：フォールトポリシー、カウンタ

file：ファイル パス、設定のインポート/エクスポート ポリシー

firmware：ファームウェア

fmcast：ファブリック マルチキャスト

fsm：有限状態マシン

fv：ファブリックの仮想化

fvns：ファブリックの仮想化の名前空間

fvtopo：ファブリックの仮想化トポロジ

geo：位置情報

glean：グリーニング隣接関係

ha：ハイ アベイラビリティ

health：ヘルス スコア

hvs：ハイパーバイザ仮想スイッチ

icmp：インターネット制御プロトコル

icmpv4：インターネット制御プロトコル バージョン 4

icmpv6：インターネット制御プロトコル バージョン 6

ident：アイデンティティ

igmp：インターネット グループ管理プロトコル

igmpsnoop：インターネット グループ管理プロトコル スヌーピング

im：インターフェイス マネージャ モジュール

imginstall：イメージ インストール

infra：インフラスラクチャ

ip：インターネット プロトコル

ipv4：インターネット プロトコル バージョン 4

ipv6：インターネット プロトコル バージョン 6

isis：Intermediate System to Intermediate System

isistlv：Intermediate System to Intermediate System のタイプ、長さ、値

l1：レイヤ 1

l1cap：レイヤ 1 機能

l2：レイヤ 2

l2cap：レイヤ 2 機能

l2ext：レイヤ 2 の外部

l3：レイヤ 3

l3cap：レイヤ 3 機能

l3ext：レイヤ 3 の外部

l3vm：レイヤ 3 仮想マシン

lacp：リンク集約プロトコル

lbp：ロード バランシング ポリシー

leqpt：ルーズ機器（ファブリック外の管理対象外ノード）

lldp：Link Layer Discovery Protocol

lldptlv：Link Layer Discovery Protocol のタイプ、長さ、値

lldptlvpol：Link Layer Discovery Protocol のタイプ、長さ、値のポリシー

maint：メンテナンス

mcast：マルチキャスト

mcp：マスター制御プロセッサ

memory：メモリ統計情報

mgmt：管理

mo：管理対象オブジェクト

mock：モック（統計情報/フォールトなどの表示のために主にシミュレータで使用されるオブジェクト）

mon：モニタリング

monitor：モニタ(PAN）

naming：名前付きオブジェクトの概要

nd：ネイバー探索

nw：ネットワーク

oam：イーサネットの操作、管理および管理

observer：統計情報、フォールト、状態、ヘルス、ログ/履歴のオブザーバ

opflex：OpFlex

os：オペレーティング システム

ospf：Open Shortest Path First

pc：ポート チャネル

pcons：**内部プロセスによって生成され、使用されます**

phys：物理的なドメイン プロファイル

ping：ping の実行と結果

pki：公開キー インフラストラクチャ

pol：ポリシー定義

policer：トラフィック ポリシング（レート制限）

pool：オブジェクト プール

pres：**内部プロセスによって生成され、使用されます**

proc：システム負荷、CPU およびメモリ使用率の統計情報

psu：電源装置ポリシー

qos：Quality of Service ポリシー

qosm：QoS の統計情報

qosp：qos/ 802.1p

rbqm：デバッグ

regress：回帰

reln：**内部プロセスによって生成され、使用されます**

repl：**内部プロセスによって生成され、使用されます**

res：**内部プロセスによって生成され、使用されます**

rib：ルーティング情報ベース

rmon：リモート ネットワーク モニタリング/インターフェイス統計情報/カウンタ

rpm：ルート ポリシー マップ

rtcom：ルート制御コミュニティ リスト

rtctrl：ルート制御

rtextcom：ルータの拡張コミュニティ

rtflt：ルート フィルタ

rtleak：ルート リーク

rtmap：RPM ルート マップ

rtpfx：ルート プレフィックス リスト

rtregcom：ルートの通常のコミュニティ リスト

rtsum：ルート集約のアドレス/ポリシー

satm：サテライト マネージャ

snmp：簡易ネットワーク管理プロトコル

span：スイッチド ポート アナライザ

stats：統計情報収集ポリシー

statstore：統計データ ホルダー

stormctrl：ストーム制御（トラフィック抑制）ポリシー

stp：スパニング ツリー プロトコルの定義とポリシー

sts：サービス タグ スイッチング（サービス挿入に使用）

svccore：コア ポリシー

svi：スイッチド仮想インターフェイス/ルーテッド VLAN インターフェイス

synthetic：模擬オブジェクト（テスト用）

sysdebug：システム デバッグ

sysfile：システム ファイル

syshist:：システム カードのリセット記録/履歴

syslog：syslog ポリシー

sysmgr：システム マネージャ（ファームウェア、スーパーバイザ、システム状態など）

sysmgrp：すべての QoS ポリシー定義のコア ポリシーおよび抽象クラスのコンテナ

tag：エイリアス（dn の記述名に使用）、タグ（複数のオブジェクトを記述名でグループ化）

task：タスクの実行、インスタンスおよび結果

test:テスト ルール、サブジェクトおよび結果の抽象クラス

testinfralab：テスト インフラストラクチャ

tlv：タイプ、長さ、値のシステム構造

top：プロセッサ アクティビティのシステム タスク マネージャ

topoctrl：トポロジ制御ポリシー（sharding、ファブリック LB、ファブリック VxLan など）

traceroute：traceroute の実行と結果

traceroutep：traceroute のエンド ポイント

trig：トリガー ポリシー

tunnel：トンネリング

uribv4：ipv4 ユニキャスト ルーティング情報の基本エンティティ

vlan：VLAN インスタンス

vlanmgr：VLAN マネージャ コントロール プレーン

vmm：仮想マシン マネージャ（コントローラ、vmm ポリシーと定義）

vns：仮想ネットワーク サービス（L4-L7 ポリシーと定義）

vpc：仮想ポート チャネル（vpc ポリシーと定義）

vsvc：サービス ラベル（プロバイダー/コンシューマ）

vtap：外部ノードの変換アドレス（サービス ノードの NATed IP）

vxlan：仮想拡張 LAN の定義

vz：仮想ゾーン（ポリシー制御の以前の名前）、すなわちコントラクト

モデル命名方式

Rs：関係のソース

Rt：関係のターゲット

Ag：集約統計

BrCP：バイナリコントラクトプロファイル

頭字語とその定義

この項は、このマニュアルで使用される用語および概念の概要説明を提供するように設計されています。ACI はパケットを回線に送信する方法を変更していませんが、いくつかの用語と概念が新しく採用されました。これらの新しい用語と概念を理解することは、ACI で機能するそれらが、それらのビットを送信するために ACI で使用される要素について、相互に通信する際に役立ちます。関連する新しい頭字語についても説明します。

これは、すべての用語および概念の完全なリストや詳細なディクショナリを意図するものではなく、共通の専門語の一部でない場合がある主要な用語および概念、または説明済みのトラブルシューティング シナリオでカバーされたトラブルシューティング演習に関連するもののみを示します。

AAA

Authentication（認証）、Authorization（許可）、および Accounting（アカウンティング）の頭字語。

アクセスのカプセル化

EPG は「EPG としての VLAN」モデルに従うため、リーフ スイッチ上の 単一ポートからの複数の EPG がある場合、問題が生じます。ポートで動作させるカプセル化のタイプを選択する場合は、EPG が存在するポート経由で他の EPG がアクセスできるかを確認する必要があります。ポートには、次の 3 種類のモードがあります。

- Tagged（デフォルト）：ホストからのトラフィックに VLAN ID がタグ付けされている場合は、このモードを選択します。このモードでは、ポートから出るすべてのパケット（VLAN 0 を含む）が 802.1Q ヘッダーでタグ付けされます。これにより、ユーザは、どの EPG でネイティブ（タグなし）VLAN を使用するかを決定せずに、複数の EPG を追加してポートに接続することができます。

- Untagged：ホストからのトラフィックがタグ付けされていない（VLAN ID も 802.1Q ヘッダーもない）場合、このモードを選択します。このモードは、EPG 内エンドポイントがポートで着信される際、他の EPG からの他のエンドポイントを伴わないことを条件とします。

- 802.1P：ホストからのトラフィックが 802.1P タグでタグ付けされている場合、このモードを選択します。これにより、単一の EPG でそのトラフィックに 802.1Q をタグ付けせずに、単一のポートで複数の EPG を着信することが可能になります。

ACI 外部接続

エンドポイントがファブリックの管理対象範囲から外れる場合に、外部のルーテッドまたはスイッチド中継システムを使用するファブリックとの間の接続。

ACID トランザクション

ACID は、Atomicity（アトミック性）、Consistency（整合性）、Isolation（分離）、Durability（耐久性）の頭文字語です。これらは、データベース トランザクションの整合性を確保するトランザクションのプロパティです。ACI クラスタ内の APIC デバイスへのトランザクションでは、データベースの整合性が維持されるように ACID が考慮されます。これは、トランザクションの一部が失敗した場合、トランザクション全体が失敗することを意味します。

アクション

フィルタされたトラフィックに対して行うアクション。たとえば、許可、拒否、ロギング、マークなどがあります。次のアクションがサポートされます。

- トラフィックの許可（通常のコントラクトのみ）

- トラフィックのマーク（DSCP/CoS）（通常のコントラクトのみ）

- トラフィックのリダイレクト（サービス グラフによる通常のコントラクトのみ）

- トラフィックのコピー（サービス グラフ、SPAN による通常のコントラクトのみ）

- トラフィックのブロック（タブー コントラクトのみ）

トラフィックのロギング

（タブー コントラクトのみ）

ALE

ACI リーフ エンジン。

エニーキャスト ゲートウェイ

「ユニキャスト ルーティング」がオンになっている場合にエンドポイントが存在するリーフ スイッチのそれぞれに、同じゲートウェイ IP アドレスを提供します。パーベイシブ SVI は、すべてのリーフ スイッチに分散されたデフォルト ゲートウェイを提供します。すべてのオフのサブネット パケットを、元のリーフ スイッチから直接ルーティングできるようにします。

APIC

Application Policy Infrastructure Controller は、集約ポリシー管理コントローラのクラスタです。APIC は、ファブリックにポリシーのインテンド状態を設定します。元々は、Insieme Fabric Controller（IFC）と呼ばれていました。

API

プログラム可能な拡張性に使用するアプリケーション プログラミング インターフェイス。

アプリケーション セントリック仮想スイッチ（AVS）

元々は、Nexus 1000 が ACI および VXLAN と連動するよう再プログラムされたもの。

アプリケーション プロファイル

アプリケーションの論理コンポーネントと、そのコンポーネントの通信方法をモデル化するアプリケーション プロファイル管理対象オブジェクト参照を参照するために使用される用語。アプリケーション プロファイルは、アプリケーションを表すのに使用されるキー オブジェクトで、ACI ファブリック内の自動インフラストラクチャ管理のアンカー ポイントでもあります。

簡潔に言えば、アプリケーション プロファイルとは、さまざまなエンドポイント グループの集合と、それらの間で通信するために必要なポリシーを意味します。各アプリケーション プロファイルには、1 つ以上のアプリケーション エンドポイント グループが含まれる場合があります。アプリケーション プロファイル レベルで、その下で定義されているアプリケーション エンドポイント グループの QoS 分類を設定します。アプリケーション エンドポイント グループ レベルで、ブリッジ ドメインを定義します。ネットワーク下でブリッジ ドメインは VRF にリンクします。

ASE

ACI スパイン エンジン。

アトミック カウンタ

アトミック カウンタは、ファブリック内のドロップとルーティングミスを検出し、迅速なデバッグとアプリケーションの接続性問題の分離が可能になります。アトミック カウンタの使用は、エンドポイントが異なるテナントまたは同じテナント内の異なるコンテキスト（VRF）にある場合はサポートされません。

接続可能エンティティ プロファイル（AEP）

これは、エンティティがファブリックにアタッチする場合に適用されるインターフェイスの設定プロファイルです。AEP は、同様のインフラストラクチャ ポリシー要件を持つ外部エンティティのグループを表します。AEP は、物理ポートをスイッチ ポリシーへのドメイン（物理または仮想）に結合するメカニズムでもあります。AEP は、ドメイン（ドメインは、VLAN プールから VLAN をリンクする）を、MIT 内のスイッチ ポート ポリシー グループ（設定）にリンクします。AEP の 2 つ目の用途として、AEP は、直接的なアクセスなしで管理者により設定された VMM ポリシーにテナントがアクセスできるようにします。

AV

アプライアンス ベクトル。

BD-VLAN

BD-VLAN はブリッジ ドメインを表すために使用され、複数のハードウェア VLAN および内部 VLAN に複数の FD-VLAN（カプセル化 VLAN）をリンクすることができます。これは、Broadcom ASIC により使用される 1 つの転送方法であり、処理のためにトラフィックをローカルでスイッチするか、または Northstar ASIC に転送するかを決定するのに使用されます。BD-VLAN は、さまざまなローカル FD-VLAN を単一のブリッジ ドメインに接続します。また、Broadcom ASIC で、複数のサブネットまたは ACCESS_ENC を含む場合があるレイヤ 2 ブロードキャスト ドメインを決定するために使用されます。

バウンス エントリ

エンドポイントが別のリーフ スイッチに移動する際、そのエンドポイントが以前に置かれていたリーフ スイッチには、エンドポイントの移動時に送信中のトラフィックのすべてが新しいロケーションのエンドポイントに向かって確実に送信され続けるように、バウンス エントリが設置されます。これは、リーフが他のリーフにパケットを直接転送するものの、その EP が他のリーフに移動している場合に発生します。中央のリーフは、エンドポイントが実際に存在する新しいリーフにパケットをバウンスします。

ブリッジ ドメイン（BD）

各一意のレイヤ 2 フォワーディング ドメイン（フラッド ドメイン）のレイヤ 2 転送動作（ブロードキャスト、ARP フラッディングなど）を定義する ACI 構造。ブリッジ ドメインは、IP サブネットのコンテナでもあり、ファブリック レイヤ 3 ゲートウェイの機能が設定される場所です。ブリッジ ドメインは、従来の VLAN の動作をエミュレートできますが、スケール制限の転送では制限されません。ACI オブジェクト モデルでは、ブリッジ ドメインはプライベート レイヤ 3 またはコンテキストの子です。エンドポイント グループは、1 つのブリッジ ドメインのメンバーにのみなることができます。MAC アドレスは、ブリッジ ドメインごとに（サブネット間で）一意である必要があります。

CLOS ファブリック

多階層ノンブロッキング リーフ - スパイン アーキテクチャ ネットワーク。

クラスタ

同じまたは類似の一連の機能を提供するために、単一システムとして連携する一連のデバイス。通信によりスケーラブルで分散可能なコントローラを提供する一連の APIC はクラスタにあたります。MIT データベースの共有にはクラスタ サイズが使用されます。クラスタは、コントローラ アプリケーションを実行し、相互に通信して、ファブリックの単一の論理ビューを形成する一連のアプライアンスです。

物理モデル

物理モデルは、APIC で実行されているロジック、およびスイッチで実行されているポリシー要素によりレンダリングされます。スイッチのソフトウェアでは、物理モデルを使用して、サービスに対してスイッチ データ プレーンのプログラミングを調整します。これには、設定オブジェクトと管理対象動作オブジェクトが含まれています。ユーザはこのモデルを見ることはできますが設定はできません。

コンシューマ

コンシューマは、コントラクトにおいて、トラフィックの「送信元」です。EPG がコントラクトを消費すると、消費する EPG のすべてのエンドポイントが、そのコントラクトを提供している任意の EPG の任意のエンドポイントとの通信を開始する場合があります。

コンテキスト

VRF と同等のレイヤ 3 フォワーディング ドメイン、ACI の用語ではプライベート レイヤ 3。

コントラクト

エンドポイント グループ間の通信のルールを制御するフィルタに関連するサブジェクトの論理コンテナ。ACI はホワイト リスト ポリシー モデルで動作します。コントラクトがないと、デフォルトの転送ポリシーはエンドポイント グループ間での通信を許可しませんが、エンドポイント グループ内の通信は許可されます。

コントラクト範囲

コントラクト範囲は、2 つ以上 EPG 間でのコントラクトの適用のレベルを意味します。以下の状態があります。

- アプリケーション プロファイル：エンドポイント グループは、同じアプリケーション プロファイル（AEP）内にある他のエンドポイント グループとのみ通信できます。

- プライベート ネットワーク（デフォルト）：エンドポイント グループは、同じプライベート ネットワーク（VRF）内にある他のエンドポイント グループとのみ通信できます。

- テナント：エンドポイント グループは、同じテナント内にある他のエンドポイント グループとのみ通信できます。

- グローバル：エンドポイント グループは、ファブリック全体の中に存在する他のエンドポイント グループと通信できます。

コントラクト範囲は、基本的に、EPG と通信できるホストの範囲を、同じアプリケーション プロファイル内、同じ VRF（プライベート ネットワーク）内、同じテナント内、またはファブリック内であれば場所を問わない、に制限します。

Council of Oracles プロトコル（COOP）

マッピング情報（ロケーションおよび ID）をスパイン プロキシに伝達するために、COOP を使用します。iLeaf は、ZeroMQ（ゼロ メッセージ キュー）を使用して、エンドポイントのアドレス情報をスパイン「Oracle」に転送します。スパイン ノードで実行している COOP によって、すべてのスパイン ノードが一貫性のあるエンドポイント アドレスとロケーション情報のコピーを維持することができ、さらに、ロケーション マッピング データベースに対するエンドポイント ID の DHT レポジトリを維持することができます。

データ管理エンジン（DME）

データ モデルのデータを制御する、APIC で実行されるサービス。DME は、通常、要求と応答を含む「stimulus」と呼ばれるメッセージ エンティティを使用して通信します。APIC またはスイッチの上の各サービスは、DME と呼ばれるライブラリまたはフレームワークで構築されます。

DLB

ダイナミック ロード バランシング：Flowlet スイッチングに基づく ACI ファブリックのネットワーク トラフィック ロードバランシング メカニズム。

dMIT

分散管理情報ツリー。上部にツリーのルートがあり下部にツリーのリーフがある ACI オブジェクト モデルを表します。ツリーには、ACI ファブリックを表すオブジェクト モデルのすべての側面が含まれます。

Dn

識別名。ACI 管理情報ツリー（MIT）内の特定の管理対象オブジェクトやツリー内の特定のロケーション情報を表す完全修飾名。これは、それ自体からツリーのルートに戻るすべての相対名の連結で構成されます。例として、タイプがアプリケーション プロファイルのポリシー オブジェクトが Prod という名前のテナント内で commerce workspace という名前で作成された場合、dn は uni/tn-Prod/ap-commerceworkspace と表されます。

Encap

関連付けられているエンドポイント グループの仮想マシン マネージャ（VMM）がカプセル化されたもの（VLAN または VXLAN）。これは、接続されたエンドポイントを含むエンドポイント グループに割り当てられる VLAN です。

エンドポイント（EP）

ホストまたはレイヤ 2/レイヤ 3 のアドレス指定可能エンティティとも呼ばれています。ポートに向いたファブリックではないリーフ スイッチ上のポートに直接または間接的に接続された論理または物理デバイス。エンドポイントには、アドレス、ロケーションなどの固有のプロパティがあり、エンドポイントの識別に使用されます。アドレス指定可能な MAC エンティティ（仮想 NIC インターフェイス、物理 NIC インターフェイス、スイッチ CPU インターフェイスなど）はすべて、エンドポイントと見なされます。エンドポイントは、エンドポイント グループにまとめられます。

エンドポイント グループ（EPG）

共通ポリシーに対する共通の要件、または同じポリシー処理を必要とする共通の要件に基づいてグループ化することができるエンドポイントの集合体。エンドポイント グループは、ダイナミックまたはスタティックにできます。ACI ファブリックは通常、802.1Q VLAN タグを使用してエンドポイント グループを表します。これは、多くの場合「EPG としての VLAN」モデルと呼ばれます。次のタイプのエンドポイント グループが定義されています。

- アプリケーション エンドポイント グループ（fvAEPg）

- レイヤ 2 外部外側ネットワーク インスタンスのエンドポイント グループ（L2extinstP）

- レイヤ 3 外部外側ネットワーク インスタンスのエンドポイント グループ（L3extinstP）

- アウトオブバンド（mgmtOoB）またはインバンド（mgmtInB）アクセス用の管理エンドポイント グループ

エンドポイント グループのメンバーシップはファブリックで次によって定義されます。

- 入力物理ポート（リーフまたは FEX）

- 入力論理ポート（VM ポート グループ）

- VLAN ID

- VXLAN（VNID）

- IP アドレス（FCS での外部/境界リーフ接続にのみ適用）

- IP プレフィックス/サブネット（FCS での外部/境界リーフ接続にのみ適用）

ポリシーが適用されるのはエンドポイント グループであり、個々のエンドポイントには適用されません。エンドポイント グループは、APIC において管理者により静的に設定されるか、vCenter または OpenStack などの自動システムによって動的に設定されます。

エンドポイント グループには以下のものが関連付けられます。

- 単一のレイヤ 2 仮想ネットワーク（ブリッジ グループ）または単一のレイヤ 3 仮想ネットワーク（VRF またはプライベート ネットワーク）

- 単一のセキュリティ グループ（コントラクト）

[Error]

エラーは APIC でのみ発生します。エラーには、重複 MO があるイベントや、RADIUS サーバに到達するエラーが記述されます。

Ethertype

フィルタ エントリの EtherType。現在、次の EtherType があります。

- 未指定（デフォルト）（すべてのプロトコル）

- ipv4

- ipv6

- lldp

- 8021ad

- 8021q

- arp

- fcoe

- flow_control

- mac_ または VMMrity

- mpls_mcast

- mpls_ucast

- ptp

- qinq

- rarp

- slow_protocols

- trill

- wake_on_lan

イベント

イベントは、エラーでもフォールトでもありません。何かが発生した場合に、ステップごとの情報を示します。たとえば、インターフェイスが起動すると、インターフェイスが起動している間に何が起きているかを示すイベントが提供されます。イベント レコードは、作成後は変更されることはなく、レコード数がイベント保持ポリシーで指定された最大値を超えた場合にのみ削除されます。

Fault

フォールトが発生したり、アラームが鳴ると、システムによってフォールトに対するフォールト管理対象オブジェクトが作成されます。フォールトには、影響を受けるオブジェクトの動作状態に関する条件、情報、および問題の潜在的な解決策が含まれています。フォールトは、APIC、ファブリック、およびホストで生成されるエラーです。

ファブリック

ACI ソリューションと関連付けられているエンドポイントの集合（リーフ、スパインおよび仮想スイッチ ＋ APIC）。ファブリックは、テナント エンドポイント アドレスとその「識別子」をその「ロケータ」または VTEP のアドレスで定義されるエンドポイントの場所から切り離します。ファブリック内では、転送は VTEP（ACI VXLAN トンネル エンドポイント）間で行われ、ACI VXLAN ポリシー ヘッダーと呼ばれるエクステンダ VXLAN ヘッダー フォーマットが使用されます。ある場所への内部テナント MAC または IP アドレスのマッピングは、分散マッピング データベースを使用して VTEP によって実行されます。ファブリックの概要は次のとおりです。

- インフラストラクチャ トポロジのために IS-IS 使用します。IS-IS は、TEP を識別して、各リーフ ノードからファブリック内の他のすべてのノードにトンネルの作成をアナウンスする役を担います。

- ループバック アドレスおよび VTEP アドレスをアドバタイズします。

- ベンダーの TLV を使用して、ファブリック内でマルチキャスト FTAG ツリーを生成する役を担います。

ファブリック内のすべてのテナント トラフィックは、ファブリック内のアプリケーション エンドポイントのポリシー属性を識別する ACI VXLAN（VXLAN）ヘッダーでタグ付けされます。

- ポリシー グループ（送信元グループ）

- 転送グループ（テナント、VRF、ブリッジ ドメイン）

- ロード バランシング ポリシー

- テレメトリ ポリシー

入力ポートで、ファブリックは内部 VXLAN タギング形式を使用して、異なるアプリケーション エンドポイントを区別するのに使用できる外部識別子を変換します。

ファブリックではカプセル化が使用され、そこでレイヤ 2 イーサネット パケットはカプセル化されてファブリックを通過します。ファブリック全体のデフォルト MTU は 9150 バイトです。

FCAPS

ISO モデルは、ネットワーク管理タスクを定義します。FCAPS は、管理カテゴリであるフォールト（fault）、構成（configuration）、アカウンティング（accounting）、パフォーマンス（performance）、セキュリティ（security）の頭字語です

FD_VLAN

フラッド ドメイン VLAN。FD-VLAN は、Broadcom ASIC 上でトラフィックを転送するのに使用される VLAN です。FD_VLAN は ACCESS_ENC に直接リンクされ、内部 VLAN とも呼ばれます。FD_VLAN は、ACCESS_ENC を BD_VLAN に直接リンクするのでなく、ACCESS_ENC を表すために使用されます。FD_VLAN を使用すると、BD_VLAN は、さまざまな ACCESS_ENC にリンクして、それらが NX-OS スイッチ上の同じ 802.1Q VLAN にあるかのように、それらすべてを処理することができます。ブロードキャスト パケットが ACI ファブリックからリーフ スイッチに着信すると、BD_VLAN は、パケットが別の ACCESS_ENC を使用して別のポートから転送されるよう、複数の FD_VLAN にマッピングすることができます。FD_VLAN は、レイヤ 2 MAC アドレスを学習するのに使用されます。

Filters

フィルタは、コントラクトに一致するレイヤ 2 ～レイヤ 4 フィールドを説明するルールを定義します。すべてのコントラクトは 1 つ以上のサブジェクトから構成され、各サブジェクトには 1 つ以上のフィルタが含まれ、各フィルタには 1 つ以上のエントリが含まれます。各エントリは、ACL 内の 1 行に相当し、EPG 内の EP が接続されているリーフ スイッチで適用されます。フィルタは、エントリがコントラクト内で PERMIT ステートメントなのか DENY ステートメントなのかを定義しません。これは、フィルタが関連付けられているコントラクト タイプによって決定されます。

Flowlet スイッチング

2004 年の MIT による調査に基づく、最適化されたマルチパス ロードバランシング方法。Flowlet スイッチングは、フローをフローレットに動的に分割し、パケットの再順序付けを必要とすることなく複数の平行パスにわたりトラフィックを分割することで、TCP フローをより効率よく転送するために TCP のバースト特性を使用する方法です。

FNV

ファブリック ノード ベクトル。

GUI

グラフィカル ユーザ インターフェイス。

ヘルス スコア

ヘルス スコアは、さまざまなシステム ビューに、エラーがあるかどうかを示します。ACI ファブリック ヘルス情報は、システムの次の表示画面で見ることができます。

- System：ポッドのヘルス スコア、テナントのヘルス スコア、ドメインおよびタイプごとのシステム エラー数、APIC クラスタ ヘルス状態など、システム全体の健全性の集約。

- Pod：ポッド（スパインおよびリーフ スイッチのグループ）のヘルス スコアの集約、ドメインおよびタイプごとのポッド全体のエラー数。

- Tenant：テナント固有のアプリケーションおよび EPG などのオブジェクトのパフォーマンス データを含むテナントのヘルス スコアの集約、ドメインおよびタイプごとのテナント全体のエラー数。

- Managed Object：管理対象オブジェクト（MO）（独立 MO および関連 MO を含む）のヘルス スコア ポリシー。これらのポリシーは、管理者によりカスタマイズできます。

ヘルス スコアは、パーセンテージの設定ポイントによって異なる色で表示されます。

- 66%：この割合を下回ると、ヘルス スコアは黄色で表示されます。

- 33%：この割合を下回ると、ヘルス スコアは赤色で表示されます。

HTML

ハイパーテキスト マークアップ言語。Web ページの書式設定に焦点を合せたマークアップ言語。

ハイパーバイザ

ホスト マシン上のハードウェアを抽象化し、ホスト マシンが複数の仮想マシンで実行できるようにするソフトウェア。

ハイパーバイザの統合

APIC に仮想マシンの可視性とポリシーの適用に関するメカニズムを提供するための、仮想マシン マネージャへの ACI ファブリック接続の拡張。

内部ファブリック メッセージ（IFM）

ACI ファブリック上のデバイス間の通信に使用されます。各エージェントのさまざまな DME アドレス間メッセージの提供を試行するソフトウェア レイヤは、「アイデンティティ」と呼ばれます。アイデンティティの形式は次のとおりです。

system-type:system-id:service:slot

たとえば、スイッチ 119 のポリシー要素は次のように表されます。

1:119:5:0

IFM はリモート接続に SSL over TCP を使用します。次のように、プロセスにより異なるポートが使用されます。

eventmgr   12119    Alerts, Faults, Health Scores
nginx                   12151
policyelem            12183
policymgr          12215    processes policy addition/deletion/modification events and
converts the policy into ppf representation and distributes the
policies to policy clients using PPF library. It uses 2-pass
verify-commit model to get the policy programmed in the
hardware.
reader                  12247
ae                   12279
topomgr            12311
observer           12343 Roll up various HW faults
dbgr                 12375 Atomic Counters
observerelem         12407
dbgrelem              12439
vmmmgr               12471 VM manager interactions
nxosmock             12503
bootmgr            12535
appliancedirector  12567 Clustering, Sharding, Syncing of replicas
dhcpd              12695 DHCP addressing
scripthandler         12727
idmgr              12759

インバンド管理（INB）

インバンド管理設定を使用した接続。これは、ファブリックと APIC の外部管理接続にリーフ スイッチの前面パネル（データ プレーン）ポートを使用します。管理接続にファブリックを使用します。スイッチに 2 番目の VTEP アドレスを適用します。

iPing

ファブリック認定 ping です。iPing は以下と連動するよう設計されています。

- パーベイシブ ファブリック インターフェイス（各リーフ スイッチ上のゲートウェイ IP アドレス）

- マルチテナントとオーバーレイ

通常の ping の問題は、ファブリック上のパーベイシブ IP ゲートウェイでは、ゲートウェイ IP アドレスが複数のリーフ スイッチ上にあるため、発信元リーフが ping 応答を受信しない可能性があることです。iPing により、ファブリック情報をペイロードに含めることで、別のリーフ スイッチに転送された場合でも、発信側リーフ スイッチは ping 応答を受信できます。

IS-IS

インフラストラクチャ トポロジのためにファブリックで利用されるリンク ローカル ルーティング プロトコル。ループバックおよび VTEP アドレスは、IS-IS 上で内部的にアドバタイズされます。IS-IS は、リーフ ノードからファブリック内の他のすべてのノードへのトンネルの作成をアナウンスします。

iTraceroute

ファブリック認定トレースルート。iTraceroute には次のような固有の機能があります。

- 複数パスを検出およびリポート

- パスあたり 1 つのプローブ パケットのみを転送

- 詳細なノード情報をレポート

- 適用されるポリシーでパスを確認し、テナント トラフィックをシミュレート

JSON

JavaScript Object Notation。データ オブジェクトを属性と値のペアにカプセル化するために人間が読めるテキストを使用するデータ カプセル化形式。

レイヤ 2 アウト（l2out）

ACI ファブリックの外部に存在する外部ネットワークへのレイヤ 2 接続。

レイヤ 3 アウト（l3out）

ACI ファブリックの外部に存在する外部ネットワークへのレイヤ 3 接続。

L4-L7 サービス挿入

トラフィックのフローへの仮想または物理サービス アプライアンス（ファイアウォール、IDS/IPS、ロード バランサ、DLP など）の VLAN/レイヤ 3 構成の挿入およびスティッチング。サービス ノードは、OSI モデルのレイヤ 4 とレイヤ 7 の間で動作するのに対し、ネットワーキング要素（ファブリック）はレイヤ 1 ～ 3 で動作します。

Label

互いに通信できるオブジェクトとできないオブジェクトを分類するために使用されます。

Leaf

ホストとボーダーの接続を提供するファブリック内のネットワーク ノード。リーフは、ホストおよびスパインのみに接続します。リーフは、相互に接続しません。すべてのデバイスは、外部ルータまたはホストを含め、リーフ スイッチに接続されます。

レガシー モード

コントラクトは、ブリッジ ドメイン下に作成されると、そのブリッジ ドメインに対して適用されず、このブリッジ ドメイン上のすべての EPG にカプセル化が適用されます。この場合、ブリッジ ドメイン、エンドポイント グループ、および VLAN はすべて、1 対 1 でマッピングされます。

ライフ サイクル

ライフサイクルには、フォールトの始まりから終わりまでが記述されます。これには、次の状態に移行するまでの特定の経過期間が含まれます。ライフサイクルという概念の背景には、非常に長い期間継続する一時エラーを管理者が確認できるようにすることです。

ライフサイクルには、フォールト MO が、SOAKING、RAISED、または RETENTION の状態である期間が記述されます。

また、ライフサイクルには、重大度（INITIAL、TARGET、または CLEAR）が記述されます。

リンク層検出プロトコル（LLDP）

LLDP は、APIC によりリーフ スイッチを検出するために使用され、リーフ スイッチによりファブリック検出のためにスパイン スイッチを検出するために使用されます。

論理モデル

APIC で、ユーザにより、GUI または XML/JSON API を使用して設定されるモデル。論理モデルは /aci->/.aci/viewfs の下にあります。

管理対象オブジェクト（MO）

MIT で管理される ACI ポリシー モデルのすべての構成可能なコンポーネントは MO と呼ばれます。管理対象オブジェクトは設定や状態を表します。管理対象オブジェクトおよびプロパティには、読み取り/書き込み可能と、読み取り専用があります。名前付き関係におけるポリシー解決ベースの場合、次のように動作します。

- 一致する名前を持つターゲット管理対象オブジェクトが現在のテナントで検出されない場合、ACI ファブリックは、共通のテナントでその名前の解決を試行します。たとえば、ユーザのテナント EPG がテナントに存在しないブリッジ ドメインを対象とした関係性管理対象オブジェクトを含んでいた場合、システムは共通のテナントでその関係性の解決を試行します。

- 名前付き関係が現在のテナントまたは共通のテナントで解決できない場合、ACI ファブリックは、デフォルト ポリシーに解決を試行します。デフォルト ポリシーが現在のテナントに存在する場合、それが使用されます。

- 現在のテナントに存在しない場合、ACI ファブリックは共通のテナントでデフォルト ポリシーを検索します。

注：ブリッジ ドメイン、コンテキストおよびコントラクト（セキュリティ ポリシー）の名前付き関係はデフォルトに解決されません。

管理情報ツリー（MIT）

ファブリックの管理対象オブジェクトのすべてを含む階層型管理情報ツリー。管理情報モデル（MIM）とも呼ばれます。

Match Type

ラベルは、EPG、コントラクト、ブリッジ ドメイン、DHCP リレー ポリシー、および DNS ポリシーなどのさまざまなプロバイダーおよびコンシューマの管理対象オブジェクトに適用できます。プロバイダー ラベルとコンシューマ ラベルの一致を確認する場合、設定はプロバイダー EPG によって決定されます。次のタイプがあります。

- AtleastOne（デフォルト）：少なくとも 1 つのラベルが、プロバイダー EPG とコンシューマ EPG で一致する。空白のラベルは一致と見なされます。

- AtmostOne：EPG 上のすべてのラベルがまったく同じ場合にのみ一致する。空白のラベルは一致と見なされます。

- None：サブジェクト ラベルのいずれも一致しない。

- All：両 EPG に空白のラベル以外のすべてのラベルがある場合にのみ一致する。

モデル

モデルは、エンティティとエンティティ間に存在する関係性を表す概念です。

多階層アプリケーション

プレゼンテーション機能、アプリケーション ロジック機能およびデータベース管理機能には物理的または論理的な分離が必要で、アプリケーション機能のために他の階層と通信するためにネットワーキング機能を必要とする、クライアント - サーバ アーキテクチャ。

NginX

NginX（「エンジン X」と読む）は、Igor Sysoev が最初に記述した、HTTP リバース プロキシ サーバ、メール プロキシ サーバ、および汎用 TCP プロキシ サーバです。APIC のすべての入力方法（REST API、Web GUI、および CLI）で、入力情報は NginX に送信されます。なかでも GUI は、NginX からステータス コードを取得し、コマンドを受信するスイッチによるコマンド検証を行いません。コマンドが適用されない場合、フォールトはスイッチから送信し直されます。設定を適用した後は、[Faults] タブを必ず確認してください。

Northstar ASIC

Cisco ACI の ASIC。24 x 40G ポートのワイヤスピード。VXLAN セグメント間ルーティング、大容量バッファ、ポリシー適用、高度なダイナミック ロード バランシング、ブリッジ ドメイン内 EPG 間のマルチキャスト転送とブリッジング、QoS、アトミック カウンタ、および遅延測定を提供します。また、NorthStar は、このような付加価値機能の一部をローカル トラフィックおよびアップリンクに適用できるようにするループバック パスを提供します。前面ポートからファブリックを出力する際、NorthStar は次の機能を提供します。

- VxLAN 終端

- ステーション ルックアップ

- ポリシー ルックアップ

- 出力ポートの選択

前面ポートからファブリックに入力する際、NorthStar は次の機能を提供します。

- EPG の取得

- ステーション ルックアップ

- ポリシー ルックアップ

- カプセル化（プロキシおよび非プロキシ）

- Bounce

オブジェクト モデル

オブジェクトとクラスのコレクションは、そのオブジェクト モデルを公開するシステムの設定および実行状態を確認し、処理するのに使用されます。ACI では、オブジェクト モデルは分散管理情報ツリー（dMIT）と呼ばれるツリーとして表されます。

OpFlex

OpFlex は、Cisco APIC と任意のデバイス（ハイパーバイザ スイッチ、物理スイッチ、およびレイヤ 4 ～ レイヤ 7 ネットワーク サービスなど）のネットワーク ポリシー コントローラ間で、XML または JavaScript オブジェクト表記（JSON）で抽象ポリシーを転送するためのオープンで拡張可能なポリシー プロトコルです。

アウトオブバンド管理（OOB 管理）

すべてのスイッチおよび APIC で特定のアウトオブバンド管理インターフェイスを使用した外部接続。

オーバーレイ - 1

ファブリック スイッチおよび APIC が使用する VRF（コンテキスト）。

物理的なドメイン

ベア メタル ホスト用に、または APIC に VMM が定義されずに接続されている場合に使用されるエンドポイント。

ポリシー制御（PC）タグ

ポリシー制御タグは、名前の代わりに数値で識別するためにエンドポイント グループに割り当てられます。「送信元 ID」または「宛先 ID」と呼ばれています。

ポート チャネル

複数の物理インターフェイスを単一の論理インターフェイスにバインドし、トポロジを変更することなく集約帯域幅とリンクフォールトのリカバリをさらに提供するポート リンク集約技術。

Prefix

プレフィックスは、どの外部サブネットがファブリック内に許可されるかを制御します。ファブリックが外部ルータによりピアリングされている場合、サブネット プレフィックスはエンドポイントであると見なされます。

プライベート ネットワーク

VRF と同様、ルーティング インスタンスを分離します。管理用の分離として使用できます。テナント内の非重複 IP アドレス空間を定義するために使用されます。エンドポイント グループは、1 つのプライベート ネットワークにのみ関連付けることができます。

Provider

プロバイダーは、コントラクトにおいて、トラフィックの「受信元」です。

特権

権限は、ロールが実行できるタスクを決定します。

ポリシー（Policy）

システム挙動の一定の側面を制御するための一般的な仕様を含む名前付きエンティティ。たとえば、レイヤ 3 外部ネットワーク ポリシーには BGP プロトコルが含まれ、ファブリックを外部レイヤ 3 ネットワークに接続する場合に BGP ルーティング機能をイネーブルにできます。

ポリシー グループ

ポリシーおよびプロファイルのグループ。

Raised

フォールトの状態がソーキング間隔後にも続く場合、フォールト MO は [Raised] 状態になります。[Initial] 重大度は、[Target] 重大度に進みます。1 つの状態として [RAISED-CLEARING] があり、これは、フォールトがソーキング間隔中、そして発生期間になってもアクティブであったものの、現在はクリアされたことを意味します。

解決されたモデル

解決されたモデルは、論理モデルから物理モデルへのマッピングを定義します（論理モデルは [intended] 状態を含み、物理モデルは [actual] 状態を含みます）。これは、APIC 上で発生します。ユーザはこのモデルを見ることはできますが設定はできません。解決されたモデルは、/mit ->/.aci/mitfs で APIC により暗黙的に設定されます。

Retaining

[Raised-Clearing] または [Soaking-Clearing] のいずれかの状態のクリア期間にフォールトの状態がない場合、フォールト MO は重大度レベルが [cleared] の [Retaining] 状態になります。保持期間が開始され、その間フォールト MO はフォールト ポリシーで指定した期間、保持されます。この期間は、障害が発生した状態が緩和された場合でも管理者が障害に気付くようにしたり、障害が早々に削除されないようにするためのものです。

Role Based Access Control（RBAC）

ロールをユーザに割り当て、それらのロールをデバイス、オブジェクトおよび権限レベルへのアクセス権の付与または拒否のプロセスで使用することで、インフラストラクチャへのセキュアなアクセスを管理する方法。RBAC により、ファブリック全体の管理者は、本来はブロックされるはずのセキュリティ ドメイン（テナント）間アクセスを許可することができます。RBAC 規則を使用して、別のセキュリティ ドメイン（テナント）にあるため他の方法ではアクセス不可能なサービスを共有したり物理リソースを公開したりできます。RBAC 規則では、ターゲット リソースへの読み取りアクセスのみ許可されます。

Representational State Transfer（REST）

ステートレスなプロトコルは通常、API にアクセスするホスト用のローカル クライアントを書き込む必要なしに、サーバ側またはクラウドベースの API へのアクセスをクライアントに許可する HTTP 上で動作します。クライアントがアクセスする場所は通常、クライアントがサービスからアクセスをしようとするデータを定義します。データは通常、XML または JSON 形式でアクセスされ、返されます。ACI を設定する方法はどれも、REST API につながります。CLI、GUI、Python（cobra）API、および XML API では、設定に REST API を使用します。

RESTful

REST、つまり Representational State Transfer を使用する API。

Rn

相対名。完全修飾されていない ACI 管理情報ツリー内の特定のオブジェクトの名前。Rn は個々のオブジェクトに重要ですが、コンテキストなしでは、ナビゲーションにおいてあまり有用ではありません。Rn は、識別名を作成するためにそれ自体からルートまで戻るすべての相対名と連結する必要があり、そうすることでナビゲーションにおいて有用になります。例として、アプリケーション プロファイルのオブジェクトが「commerceworkspace」という名前で作成されると、アプリケーション プロファイルの相対名はすべて「ap-」の文字で始まるので Rn は「ap-commerceworkspace」となります。Dn の定義も参照してください。

ロール

各ロールには特権が割り当てられています。特権を使用すると、管理者は、アクセス制限に関してテナント内の精度をより高めることができます。

RV

レプリカ ベクトル。

セキュリティ ドメイン

セキュリティ ドメインは、ユーザを、特定のテナントまたはそのテナントまたは VMM 下の MIT に制限します。

Security Domain (per tenant or VMM)
|-------------------|------------------|
Role1                 Role 2             role 3
priv1                 priv3                 priv1
priv2                 priv4                 priv4

セグメント ID

プライベート ネットワーク名の数値表現。

サービス グラフ

定義されたパラメータに基づいてトラフィックと VLAN スティッチングのリダイレクションを自動化する ACI 内のメカニズム。必要とされるすべてのサービスが、APIC から ACI ファブリックでインスタンス化されるサービス グラフとして扱われます。サービス グラフは、アプリケーションで必要なネットワーク機能またはサービス機能のセットを識別し、各機能をノードとして表します。

モジュール

モジュールはデータベースの一部です。モジュールにより、複数の物理デバイス間でデータベースを複製できます。各モジュールには、3 つの APIC にわたる 3 つのレプリカがあります。各 APIC はデータベースの完全なコピーを持ちますが、APIC がアップデートできるのは、割り当てられたデータベースの一部（またはモジュール）のみです。APIC に格納されている他のモジュールは、モジュールを所有する APIC が更新通知するまでは読み取り専用です。APIC クラスタで APIC が損失した場合、そのクラスタでまだアクティブな別の APIC がデータベース内のそのモジュールを制御することが想定されます。

Soaking

ソーキングは、フォールトの状態が検出されたときに最初に作成される時間間隔を記述します。その initial 重大度が設定されます。1 つの状態として SOAKING-CLEARING があり、これは、そーキング間隔の間にフォールトがクリアされたことを示します。

スパイン

リーフから集約ホスト トラフィックを伝送するファブリック内のネットワーク ノード。ファブリック内のリーフのみに接続し、他のデバイス タイプには接続しません。

スパイン リーフ トポロジ

スパイン ノードがリーフ ノードに接続し、リーフ ノードがホストと外部ネットワークに接続する、clos ベースのファブリック トポロジ。

スタティック バインディング パス

通常の状況では、ACI は自動的にリーフ スイッチ上に EP（EPG 内）トラフィックを入れるよう VLAN を生成してます。スタティック パス バインディングでは、リーフ スイッチ上のポートを EPG に対して設定されるよう VLAN を割り当てる必要があります。EPG がスタティック バインディング パスを使用する場合、この EPG に関連付けられるカプセル化 VLAN は定義済みのスタティック VLAN プールの一部である必要があります。これは「EPG としての VLAN」モデルに従うものです。EP をスイッチに導入したりポートを起動たりせずに、エニーキャスト ゲートウェイをリーフ スイッチで表示するようにするには、この方法が容易です。

サブジェクト

コントラクトによって含まれており、フィルタとコントラクトの間の関係を作成します。1 つのコントラクトに複数のサブジェクトが含まれている場合があります。サブジェクトは、コントラクトに適用されるとテンプレートのように機能し、EPG に一方向的に渡す必要がある特定のサービスを提供します。サブジェクトは、フィルタ、アクション、および（任意で）ラベルの組み合わせです。

Filter           Action          Label
----------------    ---------        -----------------
TCP Port 80      Permit          Web Access
Any              Permit          common/default

[Apply Both Directions] が選択されている場合、それぞれの EPG は別の EPG に 1 方向のトラフィックを送信できます。[Reverse Filter Ports] がオンになっていない場合、TCP 内の ACK を含むすべてのリターン トラフィックはブロックされます。[Reverse Filter Ports] を有効にするには、[Apply Both Directions] を最初にチェックする必要があります。[Reverse Filter Ports] がオンになっていても、コントラクトのコンシューマだけがトラフィックを開始できます。

サブネット

ブリッジ ドメインまたはエンドポイント グループによって含まれており、サブネットはブリッジ ドメイン内で使用できる IP アドレス範囲を定義します。サブネットはブリッジ ドメインで定義され、OpenStack の「サブネット」と同じです。サブネットのタイプは次のとおりです。

- Shared：エンドポイント グループ下のサブネットを、共有サービスを別の VRF 内のエンドポイント グループにルート リークするよう定義します。

- Public：エンドポイント グループ下のサブネットを、ファブリックの他のテナントにルート リークするか、またはファブリック外に外部からアドバタイズされるよう定義します。たとえば、ブリッジ ドメイン設定のもとでは、パブリック サブネットはルーティング プロトコル経由で外部ネットワークにアナウンスされます。

- Private：（デフォルト）ブリッジ ドメイン下のサブネットを、そのテナン内でのみ使用されるよう定義します。つまり、サブネットは他のテナントにリークされません。

スーパーバイザ

95xx スイッチのコントロール プレーンを提供するスイッチ モジュール。

tDN

ターゲット DN（識別名）。明示的なリファレンスにより、送信元 MO（管理対象オブジェク）とターゲット MO の特定のインスタンス間の関係性が定義されます。ターゲット インスタンスは、関係ソース（Rs）MO で明示的に設定されたターゲット DN（tDn）のプロパティによって識別されます。

テナント

アプリケーション ポリシーのすべてのポリシーをグループ化する論理コンテナ。各テナントには、個別のレイヤ 3 アドレス空間または VRF（プライベート ネットワーク）があります。テナントは OpenStack の「プロジェクト/テナント」の概念と似ています。ACI には次の 3 種類の事前定義されたテナントがあります。

- Common：すべてのテナントで使用できる ACI 構造を定義します。

- mgmt：APIC、リーフ、およびスパイン型スイッチのインバンドおよびアウトオブバンド管理を設定します。

- infra：スパインとリーフ間のファブリック ポリシーを設定します。

テナントは、管理情報ツリー（MIT）内で最高レベルの管理対象オブジェクトです。テナントが含む主要な要素は、コントラクト、ブリッジ ドメイン、プライベート ネットワーク、およびエンドポイント グループを含むアプリケーション プロファイルです。

仮想 eXtensible LAN（VXLAN）

レイヤ 3 ネットワーク上のレイヤ 2 オーバーレイ方式。トラフィックの分離/セグメント化のため、VLAN 単独で達成可能な 4K セグメントと異なり、24 ビット VXLAN セグメント ID または VXLAN ネットワーク ID（VNI）がカプセル化に含められて、最大 16M の VXLAN セグメントを提供します。これらのセグメントのそれぞれは固有のレイヤ 2 ブロードキャスト ドメインを表し、指定したテナントのアドレス空間またはサブネットを特定することが可能な方法で管理されます。VXLAN は、レイヤ 2 LISP プロトコル（draft-smith-lisp-layer2-01）を拡張したもので、ポリシー グループ、負荷およびパス メトリック、カウンタと入力ポート、およびカプセル化の情報が追加されています。

仮想ネットワーク ID（VNID）

さまざまなケースで、様々な方法でパケットを転送するために使用されます。

- ケース 1：レイヤ 2、VLAN dot1q、または VXLAN VNID が「ブリッジ ドメイン」を識別します。

- ケース 2：VRF-Lite、VLAN dot1q タグが、VRF（プライベート ネットワーク）を識別します。

- ケース 3：mBGP EVPN、VXLAN VNID が VRF を識別するか、またはレイヤ 2 の場合はブリッジ ドメインを識別します。

ACI の場合は、外部の VLAN/VXLAN が EPG を識別します。内部では、VXLAN ヘッダー内の S-Class が、EPG、VNID、および VRF/ブリッジ ドメインを識別します。

仮想ルーティングおよびフォワーディング（VRF）

複数のコンテキストを単一のデバイスまたはインフラストラクチャに展開できるようにするレイヤ 3 名前空間分離の方法論。

仮想ゾーン（vZ）

管理情報ツリー内のコントラクトは、とえば vzAny コントラクトなどのように最初に vZ が付きます。vzAny は、VRF 内のすべての IP アドレスがこの EPG に到達でき、しかも不明のプレフィックスを含んでいることを意味します。

仮想化

ハードウェア リソースを仮想表現に抽象化するために使用され、ソフトウェアの設定可能性を可能にする技術。

Visore

解決されたモデルを表示するために APIC に組み込まれたアプリケーション。MIT の設定を確認するために使用されます。Visore にアクセスするには、次の URL を使用します。

https://your_apic/visore.html

VNI

VXLAN ネットワーク ID

vPC

仮想ポート チャネル。このチャネルでは、ポート チャネルがリンク集約のために作成されますが、2 つの物理スイッチ（それ以上でもそれ以下でもない）にわたって展開されます。

VXLAN トンネル エンドポイント（VTEP）

各ファブリック スイッチと APIC には、スタートアップ スクリプトで指定されたサブネットの VTEP が割り当てられます。

XML

eXtensible Markup Language。ドキュメントのデータの書式設定よりもドキュメントのエンコーディング データに焦点を置いたマークアップ言語。

ゾーンおよびゾーン分割ルール

EPG のコントラクトは、ゾーンまたはゾーン分割ルール内のルールの形式で、スイッチ対してプッシュされます。各ゾーン分割ルールは、NX-OS ACL の 1 行に相当します。DME/PE（Policy Elements）は、リーフ スイッチに接続された EP が関連付けられている EPG によって提供されるかまたは消費されるコントラクトに基づき、リーフ スイッチにゾーン分割設定をプッシュします。相互に通信する 2 つの EPG は、1 つのゾーン内にグループ化されます。EPG が複数の EPG と通信している場合、その EPG を複数のゾーンと関連付けることができます。コントラクトとルールに対するポリシーの連携およびフローは次のとおりです。

1. APIC のポリシー マネージャは、スイッチのポリシー要素マネージャと通信します

2. スイッチのポリシー要素マネージャは、スイッチのオブジェクト ストアをプログラムします。

3. スイッチのポリシー マネージャは、スイッチの ACLQOS クライアントと通信します。

4. ACLQOS クライアントはハードウェア（TCAM）をプログラミングします。

ゾーニング ルールはコントラクトに関し、次のように指定されます。

- 範囲（アプリケーション、プライベート ネットワーク、テナント、グローバル）

- 送信元の クラス ID または SRC EPG

- 宛先のクラス ID または DST EPG

- Filter

ルールは、EPG に適用されるコントラクトから取得されます。次の 2 種類のルールがあります。

- actrlRules：EPG/ブリッジ ドメインとして PE によってプログラミングされたルール。リーフ スイッチに展開されます。

- MgmtRules：スイッチのスーパーバイザにヒットするよう指定された、トラフィックのルール。

リーフ スイッチでは、次のコマンドを含むゾーン分割ルールがあります。

show zoning-rule [src-epg sclassID] [dst-epg dclassID]

クラス ID 中の「0」は、「any」を示すために使用されています。

次のコマンドは、ゾーン中のどのルールがパケットによりヒットされているかを示します。

show logging ip access-list internal packet-log

参考資料

このオペレーション ガイドの範囲外のトピックについては、他の場所でドキュメント化されている場合があります。ここでは、有益なその他の参照マニュアルへのリンクを提示します。このリンクからマニュアルを表示して読むことができます。

ACI のインストールおよびアップグレードのガイド

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-installation-guides-list.html

ACI 入門 - ファブリックの初期化

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-installation-and-configuration-guides-list.html

ACI 設計ガイド

http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731960.html#_Toc405844675

ACI トラブルシューティング ガイド

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-troubleshooting-guides-list.html

https://datacenter.github.io/aci-troubleshooting-book/

ACI ホワイト ペーパー

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/white-paper-listing.html

ACI 導入事例

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/customer-case-study-listing.html

ACI のデモ、プレゼンテーションおよびトレーニング

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/sales-resources-list.html

ACI エコシステム互換性リスト

http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-732445.html

ACI パートナーおよびカスタマーの提示

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/presentations-listings.html

ACI と Microsoft SCVMM の統合ワークフロー

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/virtualization/workflow/cisco_aci_microsoft_scvmm_workflow.html

ACI ソリューションの概要

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/solution-overview-listing.html

ACI ツールキット

http://datacenter.github.io/acitoolkit/

ACI 互換性ツール

http://www.cisco.com/web/techdoc/aci/acimatrix/matrix.html

AVS 構成および拡張性ガイド

http://www.cisco.com/c/en/us/support/switches/application-virtual-switch/products-installation-and-configuration-guides-list.html

AVS トポロジおよびソリューション ガイド

http://www.cisco.com/c/en/us/support/switches/application-virtual-switch/products-technical-reference-list.html

APIC コマンドライン インターフェイスのユーザ ガイド

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-command-reference-list.html

APIC Layer 4 to Layer 7 Services Deployment Guide

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/L4-L7_Services_Deployment/guide/b_L4L7_Deploy.html

Cobra のドキュメント

http://cobra.readthedocs.org/en/latest/

Cobra GitHub

http://github.com/datacenter/cobra

Connecting ACI to Outside Layer 2 and 3 Networks

http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c07-732033.html

ファブリック接続のビデオ

https://www.youtube.com/watch?v=_iQvoC9zQ_A

Nexus CLI から Cisco APIC へのマッピング

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/products-configuration-examples-list.html

POSTman

http://wwww.getpostman.com

サポートされる SNMP MIB のリスト

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/mib/list/mib-support.html

はじめに

- 対象読者

- 表記法

- 関連資料

- マニュアルに関するフィードバック

- マニュアルの入手方法およびテクニカル サポート

対象読者

このガイドは、次の 1 つ以上に責任を持つ、専門知識を備えたデータセンター管理者を主な対象にしています。

- 仮想マシンのインストールと管理

- サーバ管理

- スイッチおよびネットワークの管理

- クラウド管理

表記法

コマンドの説明には、次のような表記法が使用されます。

表記法

説明

ボールド

太字の文字は、表示どおりにユーザが入力するコマンドおよびキーワードです。

italic

イタリック体の文字は、ユーザが値を入力する引数です。

[x]

省略可能な要素（キーワードまたは引数）は、角かっこで囲んで示しています。

[x | y]

いずれか 1 つを選択できる省略可能なキーワードや引数は、角カッコで囲み、縦棒で区切って示しています。

{x | y}

必ずいずれか 1 つを選択しなければならない必須キーワードや引数は、波かっこで囲み、縦棒で区切って示しています。

[x {y | z}]

角かっこまたは波かっこが入れ子になっている箇所は、任意または必須の要素内の任意または必須の選択肢であることを表します。角かっこ内の波かっこと縦棒は、省略可能な要素内で選択すべき必須の要素を示しています。

variable

ユーザが値を入力する変数であることを表します。イタリック体が使用できない場合に使用されます。

string

引用符を付けない一組の文字。string の前後には引用符を使用しません。引用符を使用すると、その引用符も含めて string とみなされます。

例では、次の表記法を使用しています。

表記法

説明

screen フォント

スイッチが表示する端末セッションおよび情報は、スクリーン フォントで示しています。

太字の screen フォント

ユーザが入力しなければならない情報は、太字のスクリーン フォントで示しています。

イタリック体の screen フォント

ユーザが値を指定する引数は、イタリック体のスクリーン フォントで示しています。

< >

パスワードのように出力されない文字は、山カッコ（< >）で囲んで示しています。

[ ]

システム プロンプトに対するデフォルトの応答は、角カッコで囲んで示しています。

!、#

コードの先頭に感嘆符（!）またはポンド記号（#）がある場合には、コメント行であることを示します。

このマニュアルでは、次の表記法を使用しています。

（注）

「注釈」です。役立つ情報やこのマニュアルに記載されていない参照資料を紹介しています。

注意

「要注意」の意味です。機器の損傷またはデータ損失を予防するための注意事項が記述されています。

警告

安全上の重要な注意事項

This warning symbol means danger. You are in a situation that could cause bodily injury. Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents. Use the statement number provided at the end of each warning to locate its translation in the translated safety warnings that accompanied this device.

SAVE THESE INSTRUCTIONS

関連資料

Cisco Cloud APIC のマニュアル

Cisco Cloud APIC のマニュアルは、次の URL で入手できます。 https://www.cisco.com/c/en/us/support/cloud-systems-management/cloud-application-policy-infrastructure-controller/tsd-products-support-series-home.html

Cisco Application Policy Infrastructure Controller（APIC）のマニュアル

次のガイドでは、Cisco APIC のドキュメントを提供します。

- 『Cisco APIC Getting Started Guide』

- 『Cisco APIC Basic Configuration Guide』

- Cisco ACI の基礎

- Cisco APIC レイヤ 2 ネットワーク設定ガイド

- Cisco APIC Layer 3 ネットワーキング設定ガイド

- 『Cisco APIC NX-OS Style Command-Line Interface Configuration Guide』

- Cisco APIC REST API 設定ガイド

- 『Cisco APIC レイヤ 4 ～ レイヤ 7 サービス導入ガイド』

- 『Cisco ACI Virtualization Guide』

- Cisco アプリケーション セントリック インフラストラクチャ：ベスト プラクティス ガイド

これらすべてのドキュメントは、次の URL で入手できます。 http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html

シスコ アプリケーション セントリック インフラストラクチャ（ACI）のマニュアル

Cisco ACI の各種マニュアルは、次の URL から入手できます。http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html

シスコ アプリケーション セントリック インフラストラクチャ（ACI）シミュレータのマニュアル

Cisco ACI Simulator のマニュアルは、次の URL から入手できます：http://www.cisco.com/c/en/us/support/cloud-systems-management/application-centric-infrastructure-simulator/tsd-products-support-series-home.html

Cisco Nexus 9000 シリーズ スイッチのマニュアル

Cisco Nexus 9000 シリーズ スイッチのマニュアルは、次の URL で入手できます。http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/tsd-products-support-series-home.html

Cisco ACI Virtual Edge マニュアル

Cisco Application Virtual Edge のマニュアルは、次の URL で入手できます。https://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html

Cisco ACI Virtual Pod のマニュアル

Cisco Application Virtual Pod (vPod) のマニュアルは、https://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html で入手できます。

シスコ アプリケーション セントリック インフラストラクチャ（ACI）と OpenStack の統合に関するマニュアル

Cisco ACI と OpenStack の統合に関するマニュアルは、次の URL から入手できます。http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html

マニュアルに関するフィードバック

このマニュアルに関する技術的なフィードバック、または誤りや記載もれなどお気づきの点がございましたら、apic-docfeedback@cisco.com までご連絡ください。ご協力をよろしくお願いいたします。

マニュアルの入手方法およびテクニカル サポート

マニュアルの入手方法、Cisco バグ検索ツール（BST）の使用法、テクニカル サポートの依頼方法、および追加情報の収集方法については、『What's New in Cisco Product Documentation』（http://www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html）を参照してください。

『What's New in Cisco Product Documentation』では、シスコの新規および改訂版の技術マニュアルの一覧を、RSS フィードとして購読できます。また、リーダー アプリケーションを使用して、コンテンツをデスクトップに直接配信することもできます。RSS フィードは無料のサービスです。

Full Cisco Trademarks with Software License

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.

Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)