Chapter1. 新機能および変更された機能に関する情報

- 新機能および変更された機能に関する情報

新機能および変更された機能に関する情報

次の表に、このガイドの最初に発行されたリリースから現在のリリースまでに、このガイドの編成と機能に加えられた大幅な変更の概要を示します。テーブルは、ガイドに加えられたすべての変更のすべてを網羅したリストを提供しているわけではありません。

最新のアップデート

リリース

新機能またはアップデート

参照先

3.4(1)

このドキュメントの最初のリリース。

--

Chapter2. GUI の概要

- 概要

- ダッシュボード

- [アプリケーション管理 (Application Management)] > [テナント (Tenants)] ページ

- [アプリケーション管理 (Application Management)] >-[スキーマ (Schemas)] ページ

- [アプリケーション管理 (Application Management)] > [ポリシー (Policies)] ページ

- [インフラストラクチャ (Infrastructure)] > [サイト (Sites)]ページ

概要

Nexus Dashboard Orchestrator (NDO) GUI はブラウザ ベースのグラフィカル インターフェイスで、Cisco APIC、クラウド APIC、およびDCNM の展開を設定し、監視できます。

GUI は、機能に応じて配置されています。たとえば、[ダッシュボード (Dashboard)] ページには、ファブリックとそのヘルスの概要が表示されます。[サイト (sites)] ページでは、各サイトに関する情報が提供され、サイトを追加できます。[スキーマ (schema)] ページでは、スキーマの作成と設定を行うことができます。各 NDO GUI ページの機能については、次のセクションで説明されています。

各ページの上部には、動作しているコントローラの数を示すコントローラ ステータス、および [開始 (Get Started)] メニュー アイコン、[設定] アイコン、[ユーザ] アイコンが示されます。

[開始 (Get Started)] メニューは、サイトまたはスキーマの追加、特定のポリシーの設定、管理タスクの実行など、実行する可能性のある多数の一般的なタスクへの簡単なアクセスを提供します。

[設定 (Settings)] アイコンを使用すると、現在実行中のバージョン、現在のリリースの最新情報、API ドキュメント、システム ステータスなど、Nexus Dashboard Orchestrator の概要情報にアクセスできます。

- [NDOについて (About NDO)] リンクには、現在インストールされている Nexus Dashboard Orchestrator のバージョンに関する情報が表示されます。

- [このリリースの最新情報 (What's New in This Release)] リンクをクリックすると、お使いのリリースの新機能の概要や、Nexus Dashboard Orchestrator の他のドキュメントへのリンクが表示されす。

- [API ドキュメント (API Docs)] リンクをクリックすると、一連の Swagger API オブジェクトとメソッドの参照にアクセスできます。Swagger API の使用の詳細については、『Cisco ACI Multi-Site REST API 設定ガイド』を参照してください。

- [システム ステータス (System Status)]リンクは、NDOで使用されているすべての実行中のサービスのステータスと正常性を提供します。

[ユーザー (User)] アイコンを使用すると、設定やブックマークなど、現在ログインしているユーザーに関する情報を表示できます。また、Orchestrator GUI からログアウトすることもできます。

（注）

リリース3.2（1）以降、ユーザ管理は、NDOサービスが実行されているNexusダッシュボードの共通ユーザおよび認証管理に移動しました。

- [設定 (Preferences)]リンクを使用すると、いくつかの GUI オプションを変更できます。

- [ブックマーク (Bookmarks)] リンクをクリックすると、Orchestrator の使用中に保存したすべてのブックマークされたスキーマのリストが開きます。スキーマを表示または編集する際に、画面の右上隅にあるブックマークアイコンをクリックして、スキーマをブックマークすることができます。

ファブリックオブジェクトを使用すると、オブジェクトが表示されるたびに、Orchestrator の GUI 全体で [表示名 (Display Name)] フィールドが使用されます。オブジェクトの作成時に表示名を指定できますが、サイト コントローラでのオブジェクトの命名要件により、無効な文字は削除されます。結果として得られた内部名が、オブジェクトをサイトにプッシュするときに使用されます。テナントの作成時に使用される内部名は、通常、[表示名 (Display Name)] テキストボックスの下に表示されます。

ダッシュボード

Nexus Dashboard Orchestrato ダッシュ ボードには、現在の機能と健全性だけでなく、サイトの実装のすべてのリストが表示されます。

ダッシュボードには次の機能領域があります:

- サイトのステータス: サイトのステータスのテーブルには、名前と場所に従ってサイトの一覧が表示されます。このテーブルには、わかりやすいカラー コードによって、実装の現在の健全性も表示されます。

- [Controller State] カラムには、使用可能および実行中のコントローラの数が表示されます。複数サイトの実装では、最大で 3 つのコントローラを設定できます。たとえば、3 つのコントローラのうち 1 つがダウンしている場合には、2/3 として表示されます。

- [Connectivity] カラムには、BGP セッションの動作ステータスとデータプレーン ユニキャスト、およびダッシュボードの各サイトでピア サイトに接続されているマルチキャスト トンネルが示されます。

1 つ以上の BGP セッションまたはトンネル確立に失敗した場合、 Multi-Site は、BGP セッションまたはトンネル確立に失敗したのがどのローカル スパインとリモート スパインであるかについての情報を提供します。Multi-Site は、インフラストラクチャ構成内のサイトを有効にします。ピア サイトへの BGP セッションとデータプレーン ユニキャストおよびマルチキャスト トンネルが確立されるようにするためです。

BGP セッション

- BGP ピアリングタイプが Infra-> General Settings でフル メッシュになっている場合、BGP ピアリングを有効にしたサイトのスパイン ノードは、すべてのピア サイト内で BGP ピアリングが有効にされているすべてのスパイン ノードに対して BGP セッションを確立します。

- BGP ピアリングタイプが Infra-> General Settings, でルート リフレクタになっている場合、BGP ピアリングとルート リフレクタの両方を有効にしたサイトのスパイン ノードは、すべてのピア サイト内で BGP ピアリングが有効にされているすべてのスパイン ノードに対して BGP セッションを確立します。ルート リフレクタ モードでは、少なくともローカル スパイン ノードまたはリモート スパイン ノードまたはその両方で、ルート リフレクタを有効にする必要があります。そうしないと、それらの間で BGP セッションは確立されません。

- ローカルおよびリモート ASN が異なる場合は、eBGP になります。したがって、それらのサイト間のセッションは、BGP ピアリング タイプとルート リフレクタの構成に関係なく、常にフル メッシュとなります。

ユニキャストおよびマルチキャスト トンネル: ISN に接続し、インフラストラクチャ構成を持つサイトのスパイン ノードは、ピア サイトで ISN に接続しているすべてのスパイン ノードに対してトンネルを確立します。

カラー コードは、次の条件を示します。

- 重大 (赤色)

- メジャー (オレンジ色)

- マイナー (黄色)

- 警告 (緑色)

色インジケータ カラムの番号は、サイトごとの障害の数を示しています。

- Schema Health: ロケールと健全性のスキーマの一覧を提供します。

- 対象のスキーマを検索するには、虫めがねアイコンをクリックし、スキーマ名を入力します。

- [+] 記号をクリックして、サイトへの新しいスキーマの追加を開始できます。

- スキーマの詳細とテンプレートのステータスを表示するには、[スキーマ正常性 (Schema Health)] テーブルのサイト ロケールをクリックします。

Schema Health テーブルはヒート マップタイプの表示になっています。対象としているスキーマの健全性が、色に従って表示されます。2 つのカラム (つまり、ロケール) にまたがっているスキーマは、拡大状態であることを示しています。

- 色によって強調表示されたセルをクリックすると、対象とするスキーマにどのようなポリシーが組み込まれているかをより詳細に確認できます。スキーマの詳細ページでは、矢印をクリックしてスキーマ ビルダーに移動し、対象とするスキーマのポリシーの詳細を更新できます。

- 色分けスライダーを使用すると、健全性をさらにレビューすることが必要なスキーマを、範囲を選択して識別できます。たとえば、スライダーの値を 80 ～ 100 の間に調整することができます。その後、指定した範囲に含まれるスキーマの実装を、付随する [Schema Health] テーブルで表示できます。

[アプリケーション管理 (Application Management)] > [テナント (Tenants)] ページ

マルチサイト Tenants ページには、実装を構成しているすべてのテナントが一覧表示されます。

Tenants ページのテーブルには、以下の項目が表示されます:

- テナント名

- 割り当て先サイト

- 割り当て先ユーザ

- 割り当て先スキーマ

- アクション

このページの特徴と機能としては、次のものがあります:

- Name: テナント名をクリックすると、Tenant Details の設定にアクセスできます。Tenant Details ページでは、次のセクションの編集や更新を行えます:

- General Settings: 必要に応じて、表示名と説明を変更します。

- Associated Sites: 対象のテナントと関連付けられているサイトを表示します。

- Associated Users: 対象のテナントと関連付けられているユーザを表示します。ユーザ名の隣にあるボックスをオンにすれば、ユーザを対象のテナントと関連付けることができます。

- Associated Schemas: Associated Schema の一覧をクリックすると、対象のテナントに関連付けられたスキーマが表示されます。

- Actions: Actions の一覧をクリックすると、対象テナントの詳細サイトの編集や、新しいネットワーク マッピングの作成を行えます。

（注）

Delete を Actions ドロップダウン メニューから選択すれば、テナントを削除することができます。

- Add Tenant: Add Tenant ボタンをクリックすると、実装内容に既存のテナントを追加できます。それから [Tenant Details] ページでは、テナント名、説明、セキュリティ ドメイン、および関連付けられているユーザを追加できます。

監査ログ

をクリックして、 監査ログ にアイコン、 スキーマの追加 スキーマ ページのログの詳細を一覧表示するには、タブ。[監査ログ：テナント リスト (Audit Logs: Tenants List)] ページが表示されます。

ページの表には、次の詳細情報が表示されます：

- 日付

- アクション

- 詳細

- ユーザ

[最新 (Most Recent)] タブをクリックすると、特定の期間の監査ログを選択できます。たとえば、2017 年 11 月 14日から 2017 年 11 月 17日までの範囲を選択し、[適用 (Apply)] をクリックすると、この期間の監査ログの詳細が [監査ログ (Audit Logs)] ページに表示されます。

[フィルタ (Filter)] アイコン ([最新 (Most Recent)] タブの隣) をクリックすれば、次のような基準に基づいてログの詳細のフィルタ処理を行うことができます:

- [ユーザ (User)]:あるユーザまたはすべてのユーザを選択して [適用 (Apply)] をクリックすると、ユーザ名に基づいてログの詳細のフィルタ処理を行えます。

- [アクション (Action)]: アクションを選択します。たとえば作成、更新または削除を行って [適用 (Apply)] をクリックすると、そのアクションに従ってログの詳細のフィルタ処理を行えます。

詳細については、テナントの章を参照してください。

[アプリケーション管理 (Application Management)] >-[スキーマ (Schemas)] ページ

[スキーマ (Schemas)] ページでは、すべての実装に関連付けられているスキーマを一覧表示します。

特定のスキーマを検索するには、虫めがねと関連付けられているフィールドを使用します。スキーマを設定に使用するか、VRF、EPG を持つアプリケーション プロファイル、フィルタおよびコントラクト、ブリッジ ドメイン、外部 EPG を含むテナント ポリシーをインポートします。

スキーマの表では、次の情報が表示されます。

- 名前: スキーマ名をクリックすると、件名スキーマの設定を表示または更新します。

- テンプレート: スキーマに使用されるテンプレートの名前が表示されます。テンプレートは、グループ ポリシーである ACI コンテキストのプロファイルと同様です。ストレッチ オブジェクトまたは特有のオブジェクトのテンプレートを作成することができます。

- テナント: 件名スキーマに使用されるテナントの名前が表示されます。

- アクション: 関連付けられるスキーマを持つ [アクション] フィールドをクリックして、件名スキーマを編集または削除します。

[スキーマの追加 (Add Schema)] ボタンを使用して新しいスキーマを追加できます。これについては、このドキュメントの後のセクションで詳しく説明します。

監査ログ

をクリックして、 監査ログ にアイコン、 スキーマの追加 スキーマ ページのログの詳細を一覧表示するには、タブ。[監査ログ：スキーマ リスト] ページが表示されます。

ページの表には、次の詳細情報が表示されます：

- 日付

- アクション

- 詳細

- ユーザ

[最新 (Most Recent)] タブをクリックすると、特定の期間の監査ログを選択できます。たとえば、2017 年 11 月 14日から 2017 年 11 月 17日までの範囲を選択し、[適用 (Apply)] をクリックすると、この期間の監査ログの詳細が [監査ログ (Audit Logs)] ページに表示されます。

[フィルタ (Filter)] アイコン ([最新 (Most Recent)] タブの隣) をクリックすれば、次のような基準に基づいてログの詳細のフィルタ処理を行うことができます:

- [ユーザ (User)]:あるユーザまたはすべてのユーザを選択して [適用 (Apply)] をクリックすると、ユーザ名に基づいてログの詳細のフィルタ処理を行えます。

- [アクション (Action)]: アクションを選択します。たとえば作成、更新または削除を行って [適用 (Apply)] をクリックすると、そのアクションに従ってログの詳細のフィルタ処理を行えます。

[アプリケーション管理 (Application Management)] > [ポリシー (Policies)] ページ

Nexus Dashboard Orchestrator の [ポリシー (Policies)] ページには、ファブリック用に設定したすべてのポリシーが表示されます。

[ポリシー (Policies)] ページには、すべてのポリシーのテーブルとともに、それらのタイプの概要、関連付けられているテナント、説明、および使用方法が表示されます。このページを使用して、新しいポリシーを追加したり、既存のポリシーを編集したりすることができます。

以下のポリシーを設定できます。

- DHCPポリシー（DHCPリレー章で説明）。

- MPLS QoSポリシー（SR-MPLS 経由で接続されたサイト章で説明）。

- ルート マップ ポリシー（SR-MPLS 経由で接続されたサイト章で説明）。

- マルチキャスト ルート マップ ポリシー（レイヤ 3 マルチキャスト章で説明）。

[インフラストラクチャ (Infrastructure)] > [サイト (Sites)]ページ

NDO の[インフラストラクチャ (Infrastructure)] > [サイト (Sites)] ページには、実装されているすべてのサイトが表示されます。次のようなものがあります。

マルチサイトの [Sites] ページ

[サイト (Sites)] ページには、次の情報が含まれます。

- [サイトの正常性 (Site Health)] は、次の色分けされた識別子に従って、サイトの全体的な正常性のステータスを示します。

- 重大 (赤色)

- メジャー (オレンジ色)

- マイナー (黄色)

- 警告 (緑色)

- [サイト名 (Site Name)] には、サイトの追加時に定義したサイトの表示名が表示されます。

- [サイトのタイプ (Site Type)] には、ACI や DCNM などのファブリック タイプが表示されます。

- [テンプレート (Templates)] 列には、サイトに関連付けられているテンプレートの数が表示されます。

- [状態 (State)] 列は、この特定のファブリックがNDOによって管理されているかどうかを示します。

Nexus Dashboard GUI でサイトとそのプロパティを追加し、管理します。NDO の [サイト (Sites)] ページには、Nexus Dashboard GUI で使用可能なすべてのサイトが表示され、NDO で管理する特定のサイトを定義できます。

- [コントローラ URL (Controller URL)] 列には、サイトのコントローラのインバンド IP アドレスが表示されます。

- アクション メニュー（...）では、サイトのテナント（ACIファブリックのみ）をインポートしたり、サイトのコントローラ UI を開いたりできます。

特定のサイトをクリックすると、右側の [プロパティ (Properties)] サイドバーが開き、サイトに関する追加情報を表示できます。

PartI. アプリケーション管理およびファブリック リソース

- テナント

- スキーマ

Chapter3. テナント

- テナント

- テナントの追加

テナント

テナントは、アプリケーションポリシーの論理コンテナで、管理者はドメインベースのアクセスコントロールを実行できます。テナントはポリシーの観点から分離の単位を表しますが、プライベート ネットワークは表しません。テナントは、サービス プロバイダーの環境ではお客様を、企業の環境では組織またはドメインを、または単にポリシーの便利なグループ化を表すことができます。

テナントを管理するには、パワー ユーザまたはサイトとテナント マネージャの読み取り/書き込みロールのいずれかが必要です。

次の 3 つのテナントが事前に設定されています。

- common：ACI ファブリックの他のテナントに「共通」のサービスを提供するための特別なテナント。共通テナントの基本原則はグローバルな再利用です。一般的なサービスには、共有 L3Out、DNS、DHCP、Active Directory、共有プライベート ネットワークまたはブリッジドメインなどがあります。

- dcnm-default-tn：Cisco DCNM ファブリックの設定を提供する特別なテナント。

- infra：トンネルやポリシー展開など、ファブリック内部の通信に使用されるインフラストラクチャ テナント。これには、スイッチ間の切り替えと APIC 通信への切り替えが含まれます。infra テナントは、ユーザー空間（テナント）には公開されず、独自のプライベート ネットワーク空間とブリッジ ドメインを備えています。ファブリックの検出、イメージ管理、ファブリック機能用の DHCP は、すべてこのテナント内で処理されます。

Nexus Dashboard Orchestrator を使用して Cisco DCNM ファブリックを管理する場合は、事前に設定されているデフォルトの dcnm-default-tn を使用し、次のオブジェクトを作成および管理できます。

- VRF

- ネットワーク

テナントの追加

このセクションでは、Nexus Dashboard Orchestrator GUI を使用してテナントを追加する方法について説明します。

始める前に

テナントの作成および管理には、パワー ユーザまたはサイト マネージャの読み取り/書き込みロールを持つユーザが必要です。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

テナントを追加します。

1. 左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [テナント (Tenants)] を選択します。

2. メイン ペインの右上にある [テナントの追加 (Add Tenant)] をクリックします。

[テナントの追加 (Add Tenant)] 画面が開きます。

ステップ 3

テナントの詳細を入力します。

1. [表示名 (Display Name)] とオプションの [説明 (Description)] を入力します。

Orchestrator の GUI 全体で、テナントが表示されるたびに、テナントの表示名が使用されます。ただし、APIC でのオブジェクトの命名要件により、無効な文字は削除され、その結果として得られた内部名が、サイトにテナントをプッシュするときに使用されます。テナントの作成時に使用される内部名は、[表示名 (Display Name)] テキストボックスの下に表示されます。

テナントの表示名はいつでも変更できますが、テナントの作成後に内部名を変更することはできません。

2. [関連付けられたサイト (Associated Sites)] セクションで、このテナントに関連付けるすべてのサイトと、使用する [セキュリティドメイン (Security Domain)] をオンにします。

選択したサイトのみが、このテナントを使用している任意のテンプレートで使用可能になります。

セキュリティ ドメインは APIC GUI を使用して作成し、アクセスをコントロールするために、さまざまな APIC ポリシーに割り当てることができます。詳細については、Cisco APIC 基本設定ガイドを参照してください。

3. [関連付けられたユーザー (Associated Users)] セクションで、テナントへのアクセスが許可されている Nexus Dashboard Orchestratorユーザーを選択します。

テンプレートを作成するときに選択したユーザのみが、このテナントを使用できます。

4. (オプション) 整合性チェッカ スケジューラを有効にします。

これにより、定期的な整合性チェックを有効にできます。整合性チェッカ機能の詳細については、Cisco Multi-Site Troubleshooting Guide を参照してください。

ステップ 4

[保存 (Save)] をクリックして、テナントの追加を終了します。

Chapter4. スキーマ

- スキーマ設計上の考慮事項

- 設定の同時更新

- スキーマとテンプレートの作成

- サイトへのテンプレートの割り当て

- テンプレートのバージョニング

- テンプレートのレビューと承認

- テンプレートの展開

- テンプレートの展開解除

- サイトからのテンプレートの関連付け解除

- 設定のばらつき

- スキーマの複製

- テンプレートの複製

- テンプレート間でのオブジェクトの移行

- 現在展開されている設定の表示

- スキーマの概要と展開ビジュアライザ

- シャドウ オブジェクト

スキーマ設計上の考慮事項

スキーマは、ポリシーの定義に使用されるテンプレートの集合であり、各テンプレートは特定のテナントに割り当てられます。展開の使用例に固有のスキーマとテンプレートの設定を作成する際に、複数のアプローチを実行できます。ここでは、マルチサイト環境でスキーマ、テンプレート、およびポリシーを定義する方法を決定する際に実行できる、いくつかの簡単な設計方針について説明します。

スキーマを設計する際には、スキーマ、テンプレート、およびスキーマあたりのオブジェクトの数に対してサポートされているスケーラビリティ制限を考慮する必要があることに注意してください。検証済みスケーラビリティ制限の詳細については、お使いのリリースの『Cisco Multi-Site Verified Scalability Guides』を参照してください。

- 単一スキーマの展開

- ネットワーク分離での複数スキーマ

- オブジェクトの関係性に基づく複数スキーマ

単一スキーマの展開

スキーマ設計の最も簡単なアプローチは、単一のスキーマで単一のテンプレートを導入することです。単一のテンプレートを含む単一のスキーマを作成し、そのテンプレートにすべての VRF、ブリッジドメイン、EPG、コントラクト、およびその他の要素を追加して、1 つまたは複数のサイトに展開することができます。

Multi-Site スキーマを作成する最も簡単な方法は、同じスキーマとテンプレート内にすべてのオブジェクトを作成することです。ただし、サポートされているスキーマの数に制限があるため、このアプローチは大規模な展開に適していない場合があります。これは、これらの制限を超える可能性があります。

また、このアプローチでは、テンプレートで定義されたすべてのオブジェクトが「ストレッチ オブジェクト」になり、テンプレートに加えられたすべての変更が、そのようなテンプレートに関連付けられたすべてのサイトに常に同時に展開されることに注意してください。

ネットワーク分離での複数スキーマ

スキーマ設計のもう 1 つのアプローチは、ネットワーク オブジェクトをアプリケーション ポリシー設定から分離することです。ネットワーク オブジェクトには、VRF、ブリッジ ドメイン、サブネットなどがあり、アプリケーションポリシーオブジェクトには EPG 、コントラクト、フィルタ、外部 EPG、およびサービス グラフが含まれます。

最初に、ネットワーク要素を含むスキーマを定義します。すべてのネットワーク要素を含む単一のスキーマを作成するか、または、それらを参照するアプリケーション、またはネットワークが拡張するサイトに基づいて、複数のスキーマに分割します。

次の図は、VRF、BD、およびサブネットが設定され、2 つのサイトに展開されている単一のネットワーキング テンプレート設定を示しています。

ネットワーク スキーマ

その後、各アプリケーションのポリシー オブジェクトを含む、1 つ以上の個別のスキーマを定義します。この新しいスキーマは、前のスキーマで定義されたブリッジ ドメインなどのネットワーク要素を参照できます。次の図に、2 つのアプリケーション テンプレートを含むポリシー スキーマを示します。これらのテンプレートの両方が外部スキーマのネットワーキング要素を参照しています。アプリケーションの一方は 1 つのサイトにローカルであり、他方は 2 つのサイト間で拡張されます。

ポリシー スキーマ

ポリシー スキーマとテンプレートを作成して展開すると、ネットワーク スキーマのネットワーキング オブジェクトに、ポリシー スキーマ要素による外部参照の数が表示されます。外部参照を含むオブジェクトは、上のネットワーク スキーマの図に示すように、リボンのアイコンでも示されます。

この方法で設計されたスキーマは、ネットワーキング オブジェクトをポリシー オブジェクトから論理的な分離します。ただし、これにより、各スキーマで外部参照されたオブジェクトの追跡はさらに複雑になります。

オブジェクトの関係性に基づく複数スキーマ

共有オブジェクト参照を使用して複数のスキーマを設定する場合、それらのオブジェクトを変更する際に注意を払うことが大切です。たとえば、共有ネットワーク オブジェクトを変更または削除すると、1 つ以上のサイトのアプリケーションに影響を与える可能性があります。そのため、サイトとそのアプリケーションで使用されているオブジェクト (VRF、BD、EPG、コントラクト、フィルタなど) のみを含む、個々のサイトのためのテンプレートを作成するのがよいでしょう。それから、共有オブジェクトを含む別のテンプレートを作成します。

サイトごとに 1 つのテンプレート

上の図の site1 テンプレートには、Site1 に対してローカルなオブジェクトのみが含まれています。このテンプレートは、Miami サイトにのみ展開されます。同様に、 site2テンプレートには Site2 に関連するオブジェクトのみが含まれており、San Francisco サイトに展開されます。これらのテンプレートのいずれかのオブジェクトに変更を加えても、他のテンプレートのオブジェクトには影響しません。共有テンプレートには、サイト間で共有されるオブジェクトが含まれています。

このシナリオは、次のテンプレート レイアウトを持つ追加サイトに拡張できます。

- サイト 1 テンプレート

- サイト 2 テンプレート

- サイト 3 テンプレート

- サイト 1 と 2 の共有テンプレート

- サイト 1 と 3 の共有テンプレート

- サイト 2 と 3 の共有テンプレート

- すべての共有テンプレート

同様に、展開されているサイトに基づいてオブジェクトを分離するのではなく、個々のアプリケーションに基づいてスキーマとテンプレートを作成することもできます。これにより、各アプリケーション プロファイルを簡単に特定し、それらをスキーマとサイトにマッピングし、さらには各アプリケーションをローカルまたは拡張されたサイト全体のものとして設定することができます。

ただし、これはスキーマごとのテンプレート数の制限（使用しているリリースの Verified Scalability Guide に記載）をすぐに越えてしまう可能性があるため、複数の組み合わせに対応するために追加のスキーマを作成することが必要になります。これにより、複数のスキーマとテンプレートが追加され、さらに複雑になりますが、サイトまたはアプリケーションに基づいてオブジェクトを正確に分離できます。

設定の同時更新

Nexus ダッシュボード オーケストレータ GUI は、同じサイトまたはスキーマオブジェクトでの同時更新が意図せずに相互に上書きされることがないようにします。自分が開いた後に別のユーザによって更新されたサイトまたはテンプレートに変更を加えようと、GUI はそれ以降の変更を拒否し、追加の変更を行う前にオブジェクトを更新するように求める警告を表示します。テンプレートを更新すると、その時点までに行った編集内容は失われるため、再度変更する必要があります。

ただし、既存のアプリケーションとの下位互換性を維持するために、デフォルトの REST API 機能は変更されていません。つまり、UI はこの保護を常に有効にしていますが、設定変更を追跡するためには、NDO の API コールに対しても明示的に有効にする必要があります。

（注）

この機能を有効にする場合は、次の点に注意してください。

- このリリースでは、サイト オブジェクトとスキーマ オブジェクトの競合する設定変更の検出のみがサポートされています。

- PUT および PATCH API コールのみがバージョンチェック機能をサポートします。

- API コールでバージョン チェック パラメータを明示的に有効にしていない場合、NDO は内部的に更新を追跡しません。その結果、設定の更新は、後続の API コールまたは GUI ユーザの両方によって上書きされる可能性があります。

設定のバージョン チェックを有効にするには、使用している API エンドポイントの末尾に enableVersionCheck = true パラメータを追加して、API コールにこのパラメータを渡します。次の例をご覧ください。

https://<mso-ip-address>/mso/api/v1/schemas/<schema-id>?enableVersionCheck=true

例

スキーマ内のテンプレートの表示名を更新する簡単な例を使用して、 PUT または PATCH コールでバージョンチェック属性を使用する方法を示します。

最初に、変更するスキーマを GET します。これにより、コールの応答で現在の最新バージョンのスキーマが返されます。

{
"id": "601acfed38000070a4ee9ec0",
"displayName": "Schema1",
"description": "",
"templates": [
{
"name": "Template1",
"displayName": "current name",
[...]
}
],
"_updateVersion": 12,
"sites": [...]
}

次に、リクエスト URL に、2 つの方法のいずれかで、enableVersionCheck = true を追加して、スキーマを変更します。

（注）

ペイロードの _updateVersion フィールドの値が、元のスキーマで取得した値と同じであることを確認する必要があります。

- PUT API を使用して、更新されるスキーマ全体ペイロードとします。

PUT /v1/schemas/601acfed38000070a4ee9ec0?enableVersionCheck=true

{
"id": "601acfed38000070a4ee9ec0",
"displayName": "Schema1",
"description": "",
"templates": [
{
"name": "Template1",
"displayName": "new name",
[...]
}
],
"_updateVersion": 12,
"sites": [...]
}

- PATCH API 操作のいずれかを使用して、スキーマ内のオブジェクトの 1 つに特定の変更を加えます。

PATCH /v1/schemas/601acfed38000070a4ee9ec0?enableVersionCheck=true

[
{
"op": "replace",
"path": "/templates/Template1/displayName",
"value": "new name",
"_updateVersion": 12
}
]

リクエストが行われると、APIは現在のスキーマバージョンを 1 ずつ増やし（12 から 13 など）、新しいバージョンのスキーマの作成を試みます。（enableVersionCheck が有効で）新しいバージョンがまだ存在しない場合、操作は成功し、スキーマは更新されます。別の API コールまたは UI がその間にスキーマを変更していた場合、操作は失敗し、API コールは次の応答を返します。

{
"code": 400,
"message": "Update failed, object version in the DB has changed, refresh your client and retry"
}

スキーマとテンプレートの作成

始める前に

- 管理者ユーザ アカウント (完全な読み取り/書き込み権限を持つ) が必要です。

- テナント アカウント (テナント ポリシーの読み取り/書き込み権限を持つ) が必要です。

Cisco APIC Basic Configuration Guideの User Access, Authentication, and Accountingを参照してください。

- サイトに組み込むには、少なくとも 1 つの使用可能なテナントが必要です。

詳細については、テナントの追加 を参照してください。

手順

ステップ 1

Nexus Dashboard にログインし、Nexus Dashboard Orchestrator サービスを開きます。

ステップ 2

スキーマを新規作成します。

1. 左側のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

2. [スキーマ (Schema)] ページで、[スキーマの追加 (Add Schema)] をクリックします。

3. スキーマ作成ダイアログで、スキーマの [名前 (Name)] と説明（オプション）を入力します。

デフォルトでは、新しいスキーマは空であるため、1 つ以上のテンプレートを追加する必要があります。

ステップ 3

テンプレートを作成します。

1. 左側のサイドバーの [テンプレート (Templates)] で、[+] 記号をクリックして新しいテンプレートを追加します。

2. 右側のサイドバーで、[表示名 (Display name)]を指定します。

3. （任意）[説明 (Description)] を入力します。

4. SR-MPLSテンプレートを設定する場合は、SR-MPLS ノブを有効にします。

SR-MPLSテンプレートの詳細については、SR-MPLS 経由で接続されたサイトを参照してください。

5. [テナントの選択 (Select a Tenant)]ドロップダウンから、このテンプレートのテナントを選択します。

新しいスキーマを作成するために使用しているユーザ アカウントは、そのスキーマに追加しようとしているテナントに関連付けられている必要があることに注意してください。そうしないと、テナントはドロップダウン メニューで使用できなくなります。ユーザ アカウントとテナントの関連付けについては、テナントの追加 を参照してください。

ステップ 4

テンプレートをサイトに割り当てます。

一度に 1 つのテンプレートを展開するため、設定を展開する少なくとも 1 つのサイトにテンプレートを関連付ける必要があります。

1. 左側のペインで、サイトの横にある [+] のアイコンをクリックします。

2. [サイトの追加（Add Sites）] ウィンドウで、テンプレートを展開するサイトの横のチェックボックスをオンにします。

3. 各サイトの横にある [テンプレートに割り当て（Assign to Template）] ドロップダウンから、1 つ以上のテンプレートを選択します。

テンプレートの展開は、関連付けられているすべてのサイトに一度に1 つずつ行いますが、サイトへの関連付けは、一度に複数のテンプレートで行えます。

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

- APIC サイトからのスキーマ要素のインポート

- VRF の設定

- ブリッジ ドメインの設定

- アプリケーション プロファイルと EPG の設定

- コントラクトとフィルタの設定

- オンプレミス外部接続の設定

- スキーマの表示

APIC サイトからのスキーマ要素のインポート

新しいオブジェクトを作成し、1 つまたは複数のサイトに公開できます。または、サイトローカルの既存のオブジェクトをインポートし、マルチサイト Orchestrator を使用して管理できます。ここでは、1 つ以上の既存のオブジェクトをインポートする方法について説明します。このドキュメントでは、新しいオブジェクトを作成する方法について説明します。

APIC から NDO にポリシーをインポートする際の一般的な方法は、VRF やコントラクトなどの一部のオブジェクトをストレッチ テンプレートにインポートし、その他のオブジェクト（非ストレッチ EPG や BD など）をサイトローカル テンプレートにインポートすることです。

リリース 3.1(1) より前は、ストレッチ テンプレートの一部である別のオブジェクトを参照するサイトローカル テンプレートにオブジェクトをインポートすると、次のような特定の問題がありました。

- 参照オブジェクトがすでに NDO に存在し、[関係を含める (Include Relationships)] オプションを有効にして新しいオブジェクトをインポートすると、参照オブジェクトがすでに存在するため、オブジェクトの重複が原因で NDO がエラーをスローします。

- ただし、参照オブジェクトをインポートしない場合 ([関係を含める (Include Relationships)] オプションが無効になっている場合)、管理者はインポート後に参照オブジェクトとの手動マッピングを実行する必要があります。

リリース 3.1(1) 以降では、（同じまたは異なるスキーマ内の）異なるテンプレートの一部である別のオブジェクトとの参照を持つサイトローカル テンプレートにオブジェクトをインポートすると、参照は NDO によって自動的に解決されます。このような場合、インポートされているオブジェクトのUIで [関係をインポート (Import Relationships)] オプションがグレー表示され、[参照されたオブジェクト (Referenced Object)] が [テンプレート (Template)] にすでに存在するなどの追加情報が提供されます。既存の関係はデフォルトでインポートされます。このようなオブジェクトはデフォルトで関係とともにインポートされますが、インポート操作が完了したら、BD を別の VRF に再マッピングするなどして、参照を変更できます。新しい動作は、インポート可能なすべての設定オブジェクトに適用されます。

サイトから 1 つ以上のオブジェクトをインポートするには、次の手順を実行します。

手順

ステップ 1

[スキーマ (Schema)] ページで、オブジェクトをインポートするスキーマを選択します。

ステップ 2

左側のサイドバーで、オブジェクトをインポートするテンプレートを選択します。

ステップ 3

メインペインで [インポート (Import)] ボタンをクリックし、インポート元の [サイト (Site)] を選択します。

ステップ 4

[インポート元 (Import from)] <site-name> ウィンドウが開いたら、インポートするオブジェクトを 1 つまたは複数選択します。

（注）

NDO にインポートするオブジェクトの名前は、すべてのサイトにわたって一意にする必要があります。重複する名前を持つ別のオブジェクトをインポートすると、スキーマ検証エラーとなり、インポートに失敗します。同じ名前のオブジェクトをインポートする必要がある場合は、先に名前を変更してください。

ステップ 5

（オプション）[関係のインポート (Import relations)] ノブを有効にして、すべての関連オブジェクトをインポートします。

たとえば、BD をインポートする場合、[関係のインポート (Import Relationships)] ノブを有効にすると、関連する VRF もインポートされます。

（注）

前述したように、関連オブジェクトがすでにNDOに存在するオブジェクトに対しては、[関係のインポート (Import Relationships)]ノブはデフォルトで有効になり、無効にできません。

VRF の設定

このセクションでは、VRF の設定方法を説明します。

始める前に

スキーマとテンプレートの作成の説明に従って、スキーマとテンプレートを作成し、テンプレートにテナントを割り当てる必要があります。

手順

ステップ 1

VRF を作成するためのスキーマとコントラクトを選択します。

1. メインペインで、[+ オブジェクトの作成 (+Create Object)] > [VRF]を選択します。

または、[VRF] エリアまでスクロール ダウンし、タイルの上にマウスを移動して、[VRF の追加 (Add VRF)] をクリックします。

2. 右側のペインで、VRF の [表示名 (Display Name)] を入力します。

3. （任意）[説明 (Description)] を入力します。

ステップ 2

VRF の [オンプレミス プロパティ(On-Premises Properties)] を設定します。

1. [ポリシー制御適用の選択 (Policy Control Enforcement Preference)] を指定します。

新しく作成された VRF のポリシー制御の適用は変更できず、設定は適用モードにロックされます。

ただし、これを使用して、インポート後、非適用として設定されている APIC サイトからインポートした VRF を適用モードに移行することができます。一般的な使用例は、既存の VRF を強制モードに変換してサイト間での拡張をサポートする必要がある、ブラウンフィールド展開です。インポートした VRF を NDO で非適用から適用に移行すると、このフィールドをさらに変更することはできなくなります。

- [適用 (Enforced)]：セキュリティ ルール（コントラクト）が適用されます。

- [非適用 (Unenforced)]：セキュリティ ルール（コントラクト）は適用されません。

2. （任意）[IPデータプレーン学習 (IP Data-Plane Learning)] を有効にします。

IP アドレスが VRF のデータプレーン パケットを通じて学習されるかどうかを定義します。

無効の場合、IP アドレスはデータプレーン パケットから学習されません。ローカルおよびリモート MAC アドレスは学習されますが、ローカル IP アドレスはデータ パケットから学習されません。

このパラメータが有効か無効かに関係なく、ローカル IP アドレスはARP、GARP、および ND から学習できます。

3. (オプション) VRF の [レイヤ 3 マルチキャスト (L3 Multicast)]を有効にします。

詳細については、レイヤ 3 マルチキャスト を参照してください。

4. （オプション）VRF の [vzAny] を有効にします。

詳細については、vzAny コントラクト を参照してください。

ブリッジ ドメインの設定

このセクションでは、ブリッジ ドメイン (BD) を設定する方法について説明します。

始める前に

- スキーマとテンプレートの作成の説明に従って、スキーマとテンプレートを作成し、テンプレートにテナントを割り当てる必要があります。

- VRF の設定の説明に従って VRF を作成する必要があります。

手順

ステップ 1

ブリッジ ドメインを作成するためのスキーマとコントラクトを選択します。

ステップ 2

ブリッジ ドメインを作成します。

1. メインペインで、[+ オブジェクトの作成 (+Create Object)] > [ブリッジ ドメイン (Bridge Domains)]を選択します。

または、[ブリッジ ドメイン (Bridge Domains)] エリアまでスクロール ダウンし、タイルの上にマウスを移動して、[ブリッジ ドメインの追加 (Add Bridge Domains)] をクリックします。

2. 右側のペインで、ブリッジ ドメインの [表示名 (Display Name)] を入力します。

3. （任意）[説明 (Description)] を入力します。

ステップ 3

[オンプレミス プロパティ(On-Premises Properties)] を設定します。

1. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、ブリッジ ドメインを選択します。

2. （オプション）[L2 ストレッチ(L2 Stretch)] を有効にします。

3. （オプション）[サイト間 BUM トラフィック許可 (Intersite BUM Traffic Allow)] を有効にします。

このオプションは、L2 ストレッチを有効にした場合に使用可能になります。

4. （オプション）[最適化された WAN 帯域幅 (Optimized WAN Bandwidth)] を有効にします。

5. （オプション）[ユニキャスト ルーティング (Unicast Routing)] を有効にします。

この設定が有効で、サブネットアドレスが構成されている場合、ファブリックがデフォルト ゲートウェイ機能を提供し、トラフィックをルーティングします。ユニキャストルーティングを有効にすると、マッピングデータベースがこのブリッジドメインのエンドポイントに付与された IP アドレスと VTEP の対応関係を学習します。IP 学習は、ブリッジドメイン内にサブネットが構成されているかどうかに左右されません。

6. （オプション）BD の [L3 マルチキャスト (L3 Multicast)] を有効にします。

Layer 3 マルチキャストの詳細については、レイヤ 3 マルチキャストを参照してください。

7. （オプション）[L2 不明なユニキャスト (L2 Unknown Unicast)] モードを選択します。

デフォルトでは、ユニキャストのトラフィックは、レイヤ 2 ポートに対してフラッディングされます。該当する場合、特定のポートでユニキャスト トラフィック フラッディングがブロックされ、ポート上に存在する既知の MAC アドレスを持つ出力トラフィックのみが許可されます。可能な方式は [フラッディング (Flood)] または [ハードウェア プロキシ (Hardware Proxy)] です。

BD が L2 Unknown Unicast を持っており、それが Flood に設定されている場合、エンドポイントが削除されると、システムはそれを両方のローカル リーフ スイッチから削除します。そして、Clear Remote MAC Entries を選択すると、BD が展開されているリモートのリーフ スイッチからも削除されます。この機能を使用しない場合、リモート リーフは、タイマーが時間切れになるまで、学習したこのエンドポイントの情報を保持します。

（注）

L2 Unknown Unicast の設定を変更すると、このブリッジ ドメインに関連付けられた EPG にアタッチされているデバイスのインターフェイス上で、トラフィックがバウンスします (アップ ダウンします)。

8. （オプション）[不明なマルチキャスト フラッディング (Unknown Multicast Flooding)] モードを選択します。

これは、IPv4 の不明マルチキャスト トラフィックに適用される、レイヤ 3 不明マルチキャスト宛先のノード転送パラメータです。

- [フラッド (Flood)]（デフォルト）：不明な IPv4 マルチキャスト トラフィックは、このブリッジ ドメインに関連付けられた EPG に接続されたすべての前面パネル ポートでフラッディングされます。フラッディングは、ブリッジ ドメインの M ルータポートだけに制限されません。

- [フラッドの最適化 (Optimize Flood)]：ブリッジドメイン内のMルータポートにのみデータを送信します。

9. （オプション）[IPv6 不明マルチキャスト フラッディング (IPv6 Unknown Multicast Flooding)] モードを選択します。

これは、IPv6不明マルチキャストトラフィックに適用され、レイヤ3不明マルチキャスト宛先のノード転送パラメータです。

- [フラッド (Flood)]（デフォルト）：不明な IPv6 マルチキャストトラフィックは、このブリッジドメインに関連付けられたすべての前面パネルポートでフラッディングされます。フラッディングは、ブリッジ ドメインの M ルータポートだけに制限されません。

- [フラッドの最適化 (Optimize Flood)]：ブリッジドメイン内のMルータポートにのみデータを送信します。

10. （オプション）[複数宛先フラッディング (Multi-Destination Flooding)] モードを選択します。

レイヤ 2 マルチキャストおよびブロードキャストトラフィックの複数宛先転送方式です。

- [BD のフラッド (Flood in BD)]：同じブリッジ ドメイン上のすべてのポートにデータを送信します。

- [ドロップ (drop)]：パケットをドロップします。他のポートにデータを送信しません。

- [カプセル化のフラッド (Flood in Encapsulation)]：ブリッジ ドメイン全体にフラッディングされるプロトコル パケットを除き、ブリッジ ドメイン内の同じ VLAN を持つすべての EPG ポートにデータを送信します。

（注）

このモードは、[L2 ストレッチ (L2 Stretch)] オプションが無効になっている場合にのみサポートされ、サイト間でストレッチされる BD ではサポートされません。

11. （オプション）[ARP フラッディング (ARP Flooding)] を有効にします。

これによって ARP フラッディングが有効になり、レイヤ 2 ブロードキャスト ドメインが IP アドレスを MAC アドレスにマッピングします。フラッディングがディセーブルである場合、ユニキャスト ルーティングはターゲット IP アドレスで実行されます。

ARP要求がレイヤ2ブロードキャストドメイン内でフラッディングされるように、ARPフラッディングを有効にします。BD がサイト間で拡張されている場合、ARP フラッディングを有効にできるのは、[サイト間 BUM トラフィック許可 (Intersite BUM Traffic Allow)]を有効にした場合のみです。ARP フラッディングが無効な場合、ローカルに接続されたエンドポイントから ARP 要求を受信するリーフは、ARP 要求のターゲット エンドポイントが接続されているリモート リーフに直接転送するか（リモート エンドポイントの IP がエンドポイント テーブルで既知の場合）、またはスパインへ転送します（リモートエンドポイントのIPがエンドポイントテーブルで不明な場合）。

[L2 不明なユニキャスト (L2 Unknown Unicast)] モードを [フラッド (Flood)] に設定した場合、[ARP フラッディング (ARP Flooding)] は無効にできません。[L2 不明なユニキャスト (L2 Unknown Unicast)] モードを [ハードウェア プロキシ (Hardware Proxy)] に設定した場合、ARP フラッディングは有効または無効にできます。

12. （オプション）[仮想 MAC アドレス (Virtual MAC Address)] を入力します。

BD の仮想 MAC アドレスとサブネットの仮想 IP アドレスは、ブリッジ ドメインのすべての ACI ファブリックで同じにする必要があります。複数のブリッジ ドメインを、接続されている ACI ファブリック間で通信するように設定できます。仮想 MAC アドレスと仮想 IP アドレスは、ブリッジ ドメイン間で共有できます。

（注）

仮想 MAC と仮想 IP サブネットは、個々のサイトを NDO 編成のマルチサイト ファブリックに移行する場合にのみ使用してください。移行が完了したら、これらのフラグを無効にできます。

ステップ 4

BD の 1 つ以上の [サブネット (Subnets)] を追加します。

1. [+ サブネットの追加 (+ Add Subnet)] をクリックします。

[サブネットの新規追加 (Add New Subnet)] ウィンドウが開きます。

2. サブネットの [ゲートウェイ IP (Gateway IP)] アドレスと追加するサブネットの [説明 (Description)] を入力します。

3. 必要に応じて、[仮想 IP アドレスとして扱う (Treat as virtual IP address)] オプションを有効にします。

このオプションは、BD の[仮想 MAC アドレス (Virtual MAC Address)] とともに、個々の共通パーベイシブ ゲートウェイ設定から NDO 統合 Multi-Site 展開への移行シナリオに使用できます。

4. サブネットの [範囲 (Scope)] を選択します。

これはサブネットのネットワーク可視性です。

- [VRF に対してプライベート (Private to VRF)]：サブネットが L3Out を介して外部ネットワーク ドメインにアナウンスされないようにします。

- 外部にアドバタイズ (Advertised Externally)：サブネットは L3Out を介して外部ネットワークドメインに向けてアナウンスできます。

5. （任意）[VRF 間で共有 (Shared Between VRFs)] をオンにします。

[VRF 間で共有 (Shared Between VRF)]：サブネットは、同じテナント内で、または共有サービスの一部としてテナントを越えて、複数のコンテキスト（VRF）で共有し、それらにエクスポートすることができます。共有サービスの例は、別のテナントの別のコンテキスト（VRF）に存在するEPGへのルーテッド接続です。これにより、トラフィックはコンテキスト（VRF）間で双方向に通過できます。共有サービスを提供する EPG は、その EPG の下で（ブリッジ ドメインの下ではなく）サブネットを設定する必要があり、そのスコープは外部にアドバタイズするように設定し、VRF 間で共有する必要があります。

共有サブネットは、通信に含まれるコンテキスト（VRF）全体で一意でなければなりません。EPG 下のサブネットがレイヤ 3 外部ネットワーク共有サービスを提供する場合、このようなサブネットは、ACI ファブリック内全体でグローバルに一意である必要があります。

6. [デフォルト SVI ゲートウェイなし (No Default SVI Gateway)] オプションはオフのままにします。

このオプションを有効にすると、リーフ ルートにプロキシ ルート（スパイン プロキシへのサブネット ルート）だけがプログラムされ、SVI は作成されません。つまり、SVI はゲートウェイとして使用できません。

EPG サブネットはルート リークにのみ使用されるため、ゲートウェイとして BD サブネットによって SVI を作成し、EPG で [デフォルト SVI ゲートウェイなし (No Default SVI Gateway)]オプションを有効にすることをお勧めします。

7. （オプション）[クエリア (Querier) オプションを有効にします。

サブネットでの [IGMP スヌーピング (IGMP Snooping)] を有効にします。

8. （オプション）[プライマリ (Primary)] オプションを有効にして、サブネットをプライマリとして指定します。

1 つのプライマリ IPv4 サブネットと 1 つのプライマリ IPv6 サブネットが可能です。

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

ステップ 5

（オプション）[DHCP ポリシー (DHCP Policy)] を追加します。

詳細については、DHCPリレー を参照してください。

ステップ 6

必要に応じて、ブリッジ ドメインのサイトローカル プロパティを設定します。

ブリッジドメインのサイトローカル プロパティの設定で説明されているように、テンプレート レベルの設定に加えて、ブリッジ ドメインの 1 つ以上のサイトローカル プロパティを定義することもできます。

- ブリッジドメインのサイトローカル プロパティの設定

ブリッジドメインのサイトローカル プロパティの設定

テンプレートでオブジェクトを作成するときにオブジェクトに対して通常設定するテンプレート レベルのプロパティに加えて、テンプレートを割り当てる各サイトに固有の 1 つ以上のプロパティを定義することもできます。

オブジェクトを複数のサイトに展開すると、同じテンプレート レベルの設定がすべてのサイトに展開され、サイトローカルの設定はそれらの特定のサイトにのみ展開されます。

始める前に

次のものが必要です。

- ブリッジ ドメインの設定の説明に従って、ブリッジ ドメインを作成し、そのテンプレート レベルのプロパティを設定していること。

- ブリッジ ドメインを含むテンプレートを 1 つ以上のサイトに割り当てていること。

手順

ステップ 1

ブリッジ ドメインを含むテンプレートを含むスキーマを開きます。

ステップ 2

左側のサイドバーで、設定する特定のサイトの下のブリッジ ドメインを含むテンプレートを選択します。

ステップ 3

メイン ペインで、ブリッジ ドメインを選択します。

ほとんどのフィールドでは、テンプレート レベルで設定した値が表示されますが、ここでは編集できません。

ステップ 4

[+ L3Out] をクリックして L3Out を追加します。

これは、リモート L3Out から BD サブネットをアドバタイズし、ローカル L3Out に障害が発生した場合でも BD へのインバウンド トラフィックを維持できるようにするために必要です。この場合、サブネットに [外部にアドバタイズ (Advertised Externally)] フラグを設定する必要もあります。詳細に関しては、サイト間 L3Outユース ケースの例を参照してください。

ステップ 5

[ホストルート (Host Route)] を有効にします。

これにより、ブリッジ ドメインでホスト ベース ルーティングが有効になります。このノブを有効にすると、ボーダー リーフ スイッチは、サブネットとともに個々のエンドポイント（EP）ホストルート（/32 または /128 プレフィックス）もアドバタイズします。ルート情報は、ホストがローカル POD に接続されている場合にのみアドバタイズされます。EP がローカル Pod から離れた、または EP が EP データベースから削除された場合、ルート アドバタイズメントはその時に撤回されます。

ステップ 6

必要に応じて、[SVI MACアドレス (SVI MAC Address)] を変更します。

仮想 MAC および仮想 IP が Common Pervasive Gateway（CPG）シナリオで有効になっている場合、SVI MAC アドレスはサイトごとに一意である必要があります。このフィールドは、BD のデフォルト ルータ MAC を変更する CPG が有効になっていない場合にも使用できます。

アプリケーション プロファイルと EPG の設定

このセクションでは、アプリケーション プロファイルと EPG を設定する方法について説明します。

始める前に

スキーマとテンプレートの作成の説明に従って、スキーマとテンプレートを作成し、テンプレートにテナントを割り当てる必要があります。

このセクションでは、契約とブリッジドメインが作成されていることも前提としています。

手順

ステップ 1

スキーマを選択し、アプリケーション プロファイルを作成するテンプレートを選択します。

ステップ 2

アプリケーション プロファイルを作成します。

1. メインペインで、[+ オブジェクトの作成 (+Create Object)] > [アプリケーション プロファイル (Application Profile)]を選択します。

または、[アプリケーション プロファイル (Application Profile)] エリアまでスクロール ダウンし、タイルの上にマウスを移動して、[アプリケーション プロファイルの追加 (Add Application Profile)] をクリックします。

2. 右側のペインで、アプリケーション プロファイルの [表示名 (Display Name)] を入力します。

競合することなく、異なるテンプレートに同じ名前のアプリケーションプロファイルを作成できます。ただし、同じサイトおよびテナントに展開する場合は、異なるテンプレートで同じ名前を持つ他のオブジェクト（VRF、BD、EPGなど）を作成することはできません。

3. （任意）[説明 (Description)] を入力します。

ステップ 3

EPG を作成します。

1. メインペインで [+オブジェクトの作成(Create Object)] > [EPG]を選択し、EPGを作成するアプリケーションプロファイルを選択します。

または、特定の [アプリケーション プロファイル (Application Profile)] エリアまでスクロール ダウンし、[EPGs] タイルの上にマウスを移動して、[EPG の追加 (Add EPG)] をクリックします。

2. 右側のペインで、EPG の [表示名 (Display Name)] を入力します。

3. （任意）[説明 (Description)] を入力します。

ステップ 4

EPG のコントラクトを追加します。

コントラクトとフィルタの作成については、コントラクトとフィルタの設定で詳しく説明しています。コントラクトを作成済みの場合：

1. [+ コントラクト (+ Contract)] をクリックします。

2. [コントラクトの追加 (Add Contract)] ダイアログで、コントラクトの名前とタイプを入力します。

3. [保存 (SAVE)] をクリックします。

ステップ 5

[ブリッジ ドメイン (Bridge Domain)] ドロップダウンで、この EPG のブリッジ ドメインを選択します。

オンプレミスの EPG を設定する場合は、ブリッジ ドメインに関連付ける必要があります。

ステップ 6

(オプション) [+ サブネット (+ Subnet)] をクリックして、EPG にサブネットを追加します。

たとえば、VRF ルートリークのユースケースとして、ブリッジ ドメイン レベルではなく EPG レベルでサブネットを設定することもできます。

1. [サブネットの追加 (Add Subnet)] ダイアログで、[ゲートウェイ IP (Gateway IP)] アドレスと追加予定のサブネットの説明を入力します。

2. [範囲 (Scope)] フィールドで [VRF にプライベート (Private to VRF)] または [外部にアドバタイズ (Advertised Externally)] のどちらかを選択します。

3. 適切な場合、[VRF 間で共有 (Shared Between VRFs)] チェックボックスをチェックします。

4. 必要に応じて、[デフォルトの SVI ゲートウェイなしデフォルト (No Default SVI Gateway)] をオンにします。

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

ステップ 7

(オプション) マイクロセグメンテーションを有効にします。

マイクロセグメンテーション EPG (uSeg) を設定する場合は、エンドポイントを EPG に一致させるために 1 つ以上の uSeg 属性を指定する必要があります。

1. [uSeg EPG] チェックボックスをオンにします。

2. [+uSeg EPG]] をクリックします。

3. uSeg 属性の [名前 (Name)] と [タイプ (Type)] を入力します。

4. 選択した属性タイプに基づいて、属性の詳細を指定します。

たとえば、属性タイプとして 1[MAC] を選択した場合は、この EPG でエンドポイントを識別する MAC アドレスを指定します。

5. [保存 (SAVE)] をクリックします。

ステップ 8

(オプション) EPG 内分離を有効にします。

デフォルトでは、EPG 内のエンドポイントが自由に相互に通信できます。エンドポイントを互いに分離するには、分離モードを [強制 (Enforced)] に設定します。

EPG 内エンドポイント分離ポリシーにより、仮想エンドポイントまたは物理エンドポイントが完全に分離されます。分離を適用した状態で稼働している EPG 内のエンドポイント間の通信は許可されません。分離を適用した EGP では、多くのクライアントが共通サービスにアクセスするときに必要な EPG カプセル化の数は低減しますが、相互間の通信は許可されません。

ステップ 9

(オプション) EPG のレイヤ 3 マルチキャストを有効にします。

Layer 3 マルチキャストの詳細については、次を参照してください: レイヤ 3 マルチキャスト

ステップ 10

(オプション) EPG の優先グループメンバシップを有効にします。

優先グループ機能を使用すると、単一の VRF 内に複数の EPG を含めて、コントラクトを作成しなくても、それらの間の完全な通信を可能にすることができます。EPG 優先グループの詳細については、次を参照してください: EPG 優先グループ

ステップ 11

必要に応じて、EPGのサイトローカル プロパティを設定します。

EPG のサイトローカル プロパティの設定で説明しているように、テンプレート レベルの設定に加えて、EPG の 1 つ以上のサイトローカル プロパティを定義することもできます。

- EPG のサイトローカル プロパティの設定

EPG のサイトローカル プロパティの設定

テンプレートでオブジェクトを作成するときにオブジェクトに対して通常設定するテンプレート レベルのプロパティに加えて、テンプレートを割り当てる各サイトに固有の 1 つ以上のプロパティを定義することもできます。

オブジェクトを複数のサイトに展開すると、同じテンプレート レベルの設定がすべてのサイトに展開され、サイトローカルの設定はそれらの特定のサイトにのみ展開されます。

始める前に

次のものが必要です。

- アプリケーション プロファイルと EPG の設定の説明に従って作成されたアプリケーション プロファイルとEPG。テンプレートレベルでプロパティが設定されていることも必要です。

- ブリッジ ドメインを含むテンプレートを 1 つ以上のサイトに割り当てていること。

手順

ステップ 1

EPGでテンプレートを含むスキーマを開きます。

ステップ 2

左側のサイドバーで、設定する特定のサイトの下の EPG を含むテンプレートを選択します。

ステップ 3

メインペインで、EPG を選択します。

ほとんどのフィールドでは、テンプレート レベルで設定した値が表示されますが、ここでは編集できません。

ステップ 4

EPG に 1 つ以上のサブネットを追加します。

1. [+ サブネットの追加 (+ Add Subnet)] をクリックします。

[サブネットの新規追加 (Add New Subnet)] ウィンドウが開きます。

2. サブネットの ゲートウェイ IP アドレスと追加するサブネットの説明を入力します。

3. サブネットの [範囲 (Scope)] を選択します。

これはサブネットのネットワーク可視性です。

- [VRF に対してプライベート (Private to VRF)]：サブネットが L3Out を介して外部ネットワーク ドメインにアナウンスされないようにします。

- 外部にアドバタイズ (Advertised Externally)：サブネットは L3Out を介して外部ネットワークドメインに向けてアナウンスできます。

4. （任意）[VRF 間で共有 (Shared Between VRFs)] をオンにします。

[VRF 間で共有 (Shared Between VRF)]：サブネットは、同じテナント内で、または共有サービスの一部としてテナントを越えて、複数のコンテキスト（VRF）で共有し、それらにエクスポートすることができます。共有サービスの例は、別のテナントの別のコンテキスト（VRF）に存在するEPGへのルーテッド接続です。これにより、トラフィックはコンテキスト（VRF）間で双方向に通過できます。共有サービスを提供する EPG は（EPG ではなく）BD でサブネットを設定する必要があり、そのスコープは外部にアドバタイズされ、VRF 間で共有されるように設定する必要があります。

共有サブネットは、通信に含まれるコンテキスト（VRF）全体で一意でなければなりません。EPG 下のサブネットがレイヤ 3 外部ネットワーク共有サービスを提供する場合、このようなサブネットは、ACI ファブリック内全体でグローバルに一意である必要があります。

5. （オプション）[デフォルトの SVI ゲートウェイなし (No Default SVI Gateway)] を有効にします。

このオプションを有効にすると、リーフ ルートにプロキシ ルート（スパイン プロキシへのサブネット ルート）だけがプログラムされ、SVI は作成されません。つまり、SVI はゲートウェイとして使用できません。

EPG サブネットではこのオプションを有効にすることをお勧めします。このオプションは、ルート リークにのみ使用し、BD サブネットではこのオプションを無効のままにして、SVI をゲートウェイとして使用できるようにします。

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

ステップ 5

1 つ以上のスタティックポートを追加します。

1. [+ スタティック ポートの追加 (+Static Port)] をクリックします。

2. [パスタイプ (Path Type)] ドロップダウンから、ポートのタイプを選択します。

3. 物理インターフェイスを設定する場合は、インターフェイスのポッドとリーフ1を選択します。

4. インターフェイスの[パス (Path)]を指定します。

5. [ポート カプセル化 VLAN (Port Encap VLAN)] を選択します。

EPG のドメインでポート カプセル化を手動で設定する場合、VLAN ID　はダイナミック VLAN プール内のスタティック VLAN ブロックに属している必要があります。

EPG でテンプレート レベルでのマイクロセグメンテーションが有効になっている場合、プライマリ MICRO-SEG VLAN が設定されると、ポート カプセル化 VLAN はプライマリ VLAN の独立したセカンダリ VLAN として設定されます。トラフィックはセカンダリ VLAN を使用してホストからリーフに送信され、リーフからホストへのリターン トラフィックはプライマリ VLAN を使用して送信されます。

6. （任意）プライマリ MICRO-SEG VLAN (Primary MICRO-SEG VLAN) を選択します。

マイクロセグメンテーションの VLAN 識別子

7. （オプション）[展開の即時性 (Deployment Immediacy)] を選択します。

ポリシーがリーフ ノードにダウンロードされたときに、ポリシーがハードウェア ポリシー CAM にプッシュされるタイミングは、展開の即時性によって指定できます。

- [即時（Immediate）]：リーフ ソフトウェアにダウンロードされたポリシーがハードウェアのポリシー CAM ですぐにプログラミングされるように指定します。

- [オン デマンド（On Demand）]：最初のパケットがデータ パス経由で受信された場合にのみポリシーがハードウェアのポリシー CAM でプログラミングされるように指定します。このプロセスは、ハードウェアの領域を最適化するのに役立ちます。

8. （オプション）[モード (Mode)] を選択します。

パスのスタティック アソシエーションのモードを選択します。EPG のタグ付けとは、EPG で次のようにスタティック パスを設定することです。

- [トランク (Trunk)]：これはデフォルトの展開モードです。ホストからのトラフィックに VLAN ID がタグ付けされている場合、このモードを選択します。

- [アクセス (802.1P) (Access (802.1P))：ホストからのトラフィックが 802.1P タグでタグ付けされている場合、このモードを選択します。アクセス ポートにネイティブ 802.1p モードの EPG を 1 つ設定すると、そのパケットはタグなしの状態でポートを退出します。ネイティブ 802.1p モードの EPG を 1 つと、VLAN タグが付いた複数の EPG をアクセス ポートに設定すると、ネイティブ 802.1p モードで設定された EPG については、そのアクセス ポートを退出するすべてのパケットに VLAN 0 がタグ付けされ、退出する他のすべての EPG パケットにはそれぞれの VLAN タグが付けられます。1 つのアクセス ポートにつき、ネイティブ 802.1p EPG は 1 つだけ許可されることに注意してください。

- [アクセス (タグなし) (Access (Untagged))]：ホストからのトラフィックがタグ付けされていない場合（VLAN ID なし）、このモードを選択します。ある EPG が使用するすべてのポートについて、この EPG にタグ付けしないようリーフ スイッチを設定すると、パケットはタグなしの状態でスイッチから送出されます。EPG をタグなしとして展開する際は、その EPG を同じスイッチの他のポート上にタグ付きとして展開することは避ける必要があることに注意してください。

ステップ 6

1 つ以上のスタティック リーフノードを追加します。

1. [+ スタティック リーフの追加 (+Static Leaf)] をクリックします。

2. [リーフ (Leaf)] ドロップダウンから、追加するリーフ ノードを選択します。

3. （任意）[VLAN] フィールドに、タグ付きトラフィックの VLAN ID を入力します。

ステップ 7

1 つ以上のドメイン ノードを追加します。

1. [+ ドメイン (+Domain)] をクリックします。

2. [ドメイン関連付けタイプ (Domain Association Type)] を選択します。

これは、追加するドメインのタイプです。

- VMM

- Fibre Channel

- L2 外部

- L3 外部

- 物理

3. [ドメイン プロファイル (Domain Profile)] の名前を選択します。

4. [展開の即時性 (Deployment Immediacy)] を選択します。

導入の即時性で、ポリシーがプッシュされるタイミングを指定できます。

- [即時（Immediate）]：リーフ ソフトウェアにダウンロードされたポリシーがハードウェアのポリシー CAM ですぐにプログラミングされるように指定します。

- [オン デマンド（On Demand）]：最初のパケットがデータ パス経由で受信された場合にのみポリシーがハードウェアのポリシー CAM でプログラミングされるように指定します。このプロセスは、ハードウェアの領域を最適化するのに役立ちます。

5. [解決の即時性 (Resolution Immediacy)] を選択します。

ポリシーをすぐに解決するか、必要に応じて解決するかを指定します。次のオプションがあります。

- [即時 (Immediate)]：ハイパーバイザが VMware vSphere Distributed Switch（VDS）に接続されると、EPG ポリシーがリーフ スイッチ ノードにプッシュされるように指定します。LLDP または OpFlex 権限は、ハイパーバイザ/リーフ ノード接続を解決するために使用されます。

- [オン デマンド (On Demand)]：ハイパーバイザが VDS に接続され、VM がポート グループ（EPG）に配置されている場合にのみ、EPG ポリシーがリーフ スイッチノードにプッシュされるように指定します。

- [事前プロビジョニング (Pre-provision)]：ハイパーバイザが VDS に接続される前でも、EPG ポリシーがリーフ スイッチ ノードにプッシュされるように指定します。スイッチ上の設定がダウンロードにより事前プロビジョニングされます。

コントラクトとフィルタの設定

ここでは、コントラクトとフィルタを設定し、フィルタをコントラクトに割り当てる方法について説明します。フィルタはアクセス コントロール リスト (ACL) に似ています。これは EPG に関連付けられた契約を通して、トラフィックをフィルタします。

手順

ステップ 1

スキーマを選択し、コントラクトとフィルタを作成するテンプレートを選択します。

コントラクトは、適用するオブジェクト（EPG および外部 EPG）と同じテンプレートでも異なるテンプレートでも作成できます。コントラクトを使用するオブジェクトが異なるサイトに展開されている場合は、複数のサイトに関連付けられたテンプレートでコントラクトを定義することをお勧めします。ただし、これは必須ではありません。コントラクトとフィルタが Site1 のローカル オブジェクトとしてのみ定義されている場合でも、Site2 のローカル EPG または外部 EPG がそのコントラクトを使用または提供する必要がある場合、NDOはそれらのオブジェクトをリモートSite2に作成します。

ステップ 2

フィルタを作成します。

1. メインペインで、[+ オブジェクトの作成 (+Create Object)] > [フィルタ (Filter)]を選択します。

または、[フィルタ (Filters)] エリアまでスクロール ダウンし、タイルの上にマウスを移動して、[フィルタの追加 (Add Filter)] をクリックします。

2. 右側のペインで、フィルタの [表示名 (Display Name)] を入力します。

3. （任意）[説明 (Description)] を入力します。

ステップ 3

フィルタ エントリを作成します。

1. 右側のペインで、[+ エントリ (+ Entry)] をクリックします。

フィルタ エントリは、ネットワーク トラフィックの分類プロパティの組み合わせです。次の手順の説明に従って、1 つ以上のオプションを指定できます。

2. フィルタの [名前 (Name)] を指定します。

3. [イーサー タイプ (Ether Type)] を選択します。

たとえば [ip] です。

4. [IP プロトコル (IP Protocol)] を選択します。

たとえば [icmp] です。

5. [宛先ポート範囲の開始 (Destination Port Range From)] と [宛先ポート範囲の終了 (Destination Port Range To)] を選択します。

宛先ポート範囲の開始と終了です。開始フィールドと終了フィールドに同じ値を指定すれば、単一のポートの指定になります。または、0 から 65535 の範囲内で、ポートの範囲を定義することもできます。また、特定のポート番号（http など）の代わりに、いずれかのサーバ タイプを指定することもできます。

6. [フラグメントのみの一致 (Match only fragment)] オプションを有効にします。

有効の場合、オフセットが 0 より大きいすべての IP フラグメント（最初のフラグメントを除くすべての IP フラグメント）にこのルールが適用されます。無効の場合、TCP/UDP ポート情報は最初のフラグメントでしかチェックできないため、オフセットが 0 より大きい IP フラグメントにルールは適用されません。

7. [ステートフル (Stateful)] オプションを有効にします。

このオプションを有効にする場合には、プロバイダーからコンシューマに戻るすべてのトラフィックは、常にパケットに ACK ビットが設定されている必要があります。そうでないと、パケットはドロップされます。

8. [ARP フラグ (ARP flag)]：（Address Resolution Protocol）を指定します。

ARPフラグは、ARP の特定のフィルタを作成するときに使用され、ARP 要求または ARP 応答を指定できます。

9. [送信元ポート範囲の開始 (Source Port Range From)] と [送信元ポート範囲の終了 (Source Port Range To)] を指定します。

送信元ポート範囲の開始と終了です。開始フィールドと終了フィールドに同じ値を指定すれば、単一のポートの指定になります。または、0 から 65535 の範囲内で、ポートの範囲を定義することもできます。また、特定のポート番号（http など）の代わりに、いずれかのサーバ タイプを指定することもできます。

10. [TCP セッション ルール (TCP session rules)] を指定します。

TCPセッションルール は、TCPトラフィックのフィルタを作成するときに使用され、ステートフル ACL の動作を設定できます。

11. [保存 (Save)] をクリックしてフィルタを保存します。

12. このフィルタの追加のフィルタ エントリを作成するには、この手順を繰り返します。

フィルタごとに複数のフィルタ エントリを作成して割り当てることができます。

ステップ 4

コントラクトの作成

1. メインペインで、[+ オブジェクトの作成 (+Create Object)] > [コントラクト (Contract)]を選択します。

または、[コントラクト (Contract)] エリアまでスクロール ダウンし、タイルの上にマウスを移動して、[コントラクトの追加 (Add Contract)] をクリックします。

2. 右側のペインで、コントラクトの表示名を指定します。

3. （任意）[説明 (Description)] を入力します。

4. コントラクトの適切な [範囲 (Scope)] を選択します。

コントラクトの範囲によって、コントラクトのアクセシビリティが制限されます。契約は、プロバイダ EPG の範囲外のコンシューマ EPG には適用されません。

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

- vrf

- テナント

- global

5. コンシューマからプロバイダーへの方向とプロバイダーからコンシューマへの方向の両方に同じフィルタを適用する場合は、[両方向に適用 (Apply both directions)] ノブを切り替えます。

このオプションを有効にした場合は、フィルタを 1 回だけ指定することが必要となり、両方向のトラフィックに適用されます。このオプションを無効のままにした場合は、各方向に 1 つずつ、2 セットのフィルタ チェーンを指定する必要があります。

（注）

[両方向に適用 (Apply both directions)] を有効にしてコントラクトを作成および展開する場合は、単にオプションを無効にしたり、変更を適用して再展開したりすることはできません。すでに展開されているコントラクトでこのオプションを無効にするには、コントラクトを削除し、テンプレートを展開してから、オプションを無効にしてコントラクトを再作成し、ファブリックの設定を正しく変更する必要があります。

6. （オプション）[サービス グラフ (Service Graph)] ドロップダウンから、このコントラクトのサービスグラフを選択します。

7. （オプション）[QoS レベル (QoS Level)] ドロップダウンから、このコントラクトの値を選択します。

この値には、このコントラクトを使用してトラフィックに割り当てられる ACI QoS レベル を指定します。詳細については、IPN 全体での QoS の保持を参照してください。

これを [未指定 (Unspecified)] のままにすると、デフォルトの QoS レベル 3 がトラフィックに適用されます。

ステップ 5

コントラクトにフィルタを割り当てる

1. 右側のペインで、[フィルタ チェーン (Filter Chain)] 領域までスクロールし、[+ フィルタ (+ Filter)] をクリックしてフィルタをコントラクトに追加します。

2. 開いた [フィルタ チェーンの追加] ウィンドウで、[名前 (Name)]ドロップダウン メニューから前の手順で追加したフィルタを選択します。

3. フィルタの [アクション (Action)] を選択します。

フィルタを追加するときに、フィルタ条件に一致するトラフィックを許可するか拒否するかを選択できます。[拒否 (deny)] フィルタの場合、[デフォルト (default)]、[低 (low)]、[中 (medium)]、または [高 (high)] の 4 段階のレベルのいずれかにフィルタの優先順位を設定できます。[許可 (permit)] フィルタは常にデフォルトの優先順位を持ちます。ACIコントラクトとフィルタの詳細については、『Cisco ACI Contract Guide』を参照してください。

4. [保存 (Save)] をクリックして、フィルタをコントラクトに追加します。

5. コントラクトで [両方向に適用 (Apply both directions)] オプションを無効にした場合は、他のフィルタ チェーンに対してこの手順を繰り返します。

6. （オプション）複数のフィルタを作成して各コントラクトに割り当てることができます。

同じコントラクトに追加のフィルタを作成する場合：

- ステップ 2 とステップ 3 を繰り返して、フィルタ エントリとともに別のフィルタを作成します。

- この手順を繰り返して、このコントラクトに新しいフィルタを割り当てます。

オンプレミス外部接続の設定

Cisco ACI では、境界リーフ スイッチを介してオンプレミス ACI ファブリックの外部のネットワークへの接続を確立できます。この接続は、セキュリティとルートマップを定義するために必要な設定オプションを提供する L3Out と外部 EPG の 2 つの構造を使用して定義されます。

このセクションでは、Nexus Dashboard Orchestrator GUI を使用して L3Out と外部 EPG を追加する方法について説明します。次に、Orchestrator で、テンプレートを展開する APIC サイトにおいてオブジェクトを作成します。Orchestrator から L3Out を作成する場合、APIC では L3Out コンテナ オブジェクトのみが作成されることに注意してください。この場合も、サイトの APIC で、完全な L3Out の構成 (ノード、インターフェイス、ルーティングプロトコルなど) を直接実行する必要があります。

ほとんどの場合、L3Out は APIC レベルで直接作成され、その後、Orchestrator で作成した外部 EPG に関連付けられます。L3Out をOrchestrator から作成した VRF に直接関連付ける場合には、ここで両方を作成すると便利です。

始める前に

- スキーマとテンプレートの作成の説明に従って、スキーマとテンプレートを作成し、テンプレートにテナントを割り当てる必要があります。

- VRF の設定の説明に従って、L3Out の VRF を作成する必要があります。

手順

ステップ 1

編集するスキーマとテンプレートに移動します。

ステップ 2

L3Out を作成します。

1. [スキーマ編集 (schema edit)] ビューで、[L3Out] エリアまで下にスクロールし、+をクリックして新しい L3Out を追加します。

2. 右側のプロパティ ペインで、L3Out の [表示名 (Display Name)] を入力します。

3. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、先ほど作成した VRF を選択します。

ステップ 3

外部 EPG を作成します。

1. [スキーマ編集 (Schema edit)] ビューで、[外部 EPG (External EPG)] エリアまでスクロールし、[+ をクリックして、新しい外部 EPG をクリックします。

2. 右側のプロパティ ペインで、サイト タイプとして [オンプレミス (On-Prem)] を選択します。

ステップ 4

外部 EPG の基本的なプロパティを設定します。

1. 右側のプロパティ サイドバーで、外部 EPG の表示名を指定します。

2. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、先ほど作成した VRF を選択します。

これは、L3Out に関連付けた VRF と同じである必要があります。

3. [+ コントラクト (+ Contract)] をクリックして、外部 EPG が他の EPG と通信するためのコントラクトを追加します。

すでにコントラクトを作成している場合は、ここでコントラクトを割り当てることができます。それ以外の場合、後ほど作成する予定のコントラクトは、この画面に戻って割り当てることができます。

コントラクトを割り当てる場合：

- 契約をプロバイダとしての外部 EPG に関連付ける場合には、外部 EPG に関連付けられているテナントから、コントラクトだけを選択します。その他のテナントからは、コントラクトを選択しないでください。

- コントラクトをコンシューマとしての外部 EPG に関連付ける場合には、利用可能な任意のコントラクトから選択できます。

ステップ 5

オンプレミス ファブリックの外部 EPG を設定する場合は、[サイト タイプ (Site Type)]を [オンプレミス (on-prem)] に設定し、外部 EPG のオンプレミス プロパティを設定します。

1. [L3Out] ドロップダウン メニューから、前の手順で作成した L3Out を選択します。

（注）

テンプレート レベルまたはサイトローカル レベルで L3Out を選択できます。サイトローカル レベルで外部 EPG の L3Out を設定することを推奨します。これを行うには、割り当てられているサイトの下の左側のサイドバーでテンプレートを選択します。次に、外部 EPG を選択し、L3Out をそれに関連付けます。

2. [+ サブネット (+Subnet)] をクリックしてサブネットを追加します。

これは、分類サブネットまたはルート制御に使用されるサブネットです。

3. [サブネット追加 (Add Subnet)] ウィンドウで、サブネットのプレフィックスを入力します。

4. 必要な [ルート制御 (Route Control)] オプションを選択します。

次のいずれかのオプションを 1 つ、または複数選択できます。

- [エクスポート ルート制御 (Export Route Control)] より、ルートマップを有効にして、指定されたサブネット プレフィックスに一致する外部プレフィックスを L3Out からアドバタイズできるようにしいます。これらは、中継ルーティングの使用例で他の L3Out から学習したプレフィックスです。

0.0.0.0/0 サブネットを追加し、エクスポート ルート制御オプションを有効にすると、[集約エクスポート (Aggregate Export)] オプションが使用可能になります。これにより、他の L3Out から学習したすべての外部プレフィックスをアドバタイズできます。このオプションを無効のままにすると、他の L3Out から学習したデフォルト ルートのみがこの L3Out からアドバタイズされます。

- [インポート ルート制御 (Import Route Control)] は、入力ルートマップを設定して、L3Out からファブリックにインポートするプレフィックスを制御します。[インポート ルート制御 (Import Route Control)] は、L3Out でルーティング プロトコルとして BGP を使用する場合にのみ使用できます。

0.0.0.0/0 サブネットを追加し、インポート ルート制御オプションを有効にすると、[集約インポート (Aggregate Import)] オプションが使用可能になります。これは、入力ルートを除き、エクスポート ルート制御の場合と同様に機能します。

- [共有ルート制御 (Shared Route Control)] は、共有 L3Out の使用例で使用され、外部ルータから学習したプレフィックスを、この L3Out を使用する他の VRF にアドバタイズできます。

共有ルート制御オプションを有効にすると、[集約教諭ルート] オプションが使用可能になります。繰り返しますが、これは前の2つの集約ルートオプションに似ています。ただし、0.0.0.0/0 以外のサブネットで使用できます。

5. [外部 EPG 分類 (External EPG Classification)] オプションを選択します。

外部エンティティをこの特定の外部 EPG にマッピングできるようにするには、設定されたサブネットの [外部 EPG 向けの外部サブネット(External Subnets for External EPG)] オプションをオンにする必要があります。これにより、これらの外部ネットワークとファブリック内で定義された EPG に属するエンドポイント間にセキュリティ ポリシー（コントラクト）を適用できます。0.0.0.0/0 プレフィックスに対してこのフラグを有効にすると、すべての外部宛先がこの外部 EPG の一部と見なされます。

このオプションを有効にすると、[共有セキュリティインポート　(Shared Security Import) ]オプションが使用可能になり、サブネットから VRF 間（共有サービス）での使用例のエンドポイントへのアクセスが可能になります。

これらの両方のオプションでは、アクセスは引き続きコントラクト ルールに従います。

ステップ 6

クラウド ファブリックの外部 EPG を設定する場合は、[サイト タイプ (Site Type)]を [クラウド (cloud)] に設定し、外部 EPG のクラウド プロパティを設定します。

1. [アプリケーション プロファイル (Application Profile)]ドロップダウンから、アプリケーション プロファイルを選択します。

2. [+ セレクタの追加 (+ Add Selector)] をクリックして、EPG のクラウド エンドポイント セレクタを追加します。

ステップ 7

（オプション）優先グループにこの外部EPGを含める場合は、[優先グループに含める (Include in preferred group)] チェックボックスをオンにします。

EPG 優先グループの詳細については、EPG 優先グループを参照してください。

スキーマの表示

1 つまたは複数のスキーマを作成すると、[ダッシュボード (Dashboard)] および [スキーマ (Schemas)] ページの両方に表示されます。

これら 2 つのページで使用可能な機能を使用して、展開時の使用率とスキーマの状態をモニタできます。Nexus Dashboard Orchestrator GUI を使用して、実装されたスキーマ ポリシーの特定の領域にアクセスして編集することもできます。

サイトへのテンプレートの割り当て

ここでは、サイトにテンプレートを割り当てる方法について説明します。

始める前に

このドキュメントの前のセクションで説明したように、作成されたサイトには、展開するスキーマ、テンプレート、およびオブジェクトが必要です。

手順

ステップ 1

展開する 1 つ以上のテンプレートを含むスキーマに移動します。

ステップ 2

左側のペインで、サイトの横にある [+] のアイコンをクリックします。

ステップ 3

[サイトの追加（Add Sites）] ウィンドウで、テンプレートを展開するサイトの横のチェックボックスをオンにします。

ステップ 4

各サイトの横にある [テンプレートに割り当て（Assign to Template）] ドロップダウンから、1 つ以上のテンプレートを選択します。

テンプレートの展開は、関連付けられているすべてのサイトに一度に1 つずつ行いますが、サイトへの関連付けは、一度に複数のテンプレートで行えます。

ステップ 5

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

ステップ 6

他のサイトに対して上記の手順を繰り返します。

一度に 1 つのテンプレートを展開するため、設定を展開する少なくとも 1 つのサイトにテンプレートを関連付ける必要があります。

テンプレートのバージョニング

リリース 3.4(1) では、テンプレートのバージョン管理のサポートが追加されています。テンプレートが保存されるたびに、新しいバージョンのテンプレートが作成されます。NDO UI 内から、テンプレートのすべての設定変更の履歴を、変更者と変更日時に関する情報とともに表示できます。以前のバージョンを現在のバージョンと比較することもできます。

新しいバージョンはスキーマ レベルではなくテンプレート レベルで作成されるため、各テンプレートを個別に設定、比較、ロールバックできます。

- タギング テンプレート

- 履歴の表示と以前のバージョンの比較

- 以前の製品バージョンへの復元

タギング テンプレート

任意の時点で、テンプレートの現在のバージョンに「ゴールデン」のタグを付けることができます。たとえば、完全に検証された設定で確認、承認、および展開されたバージョンを示すために、今後の参照用に選択できます。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)]ビューで、確認するテンプレートを選択します。

ステップ 5

テンプレートのアクション（...）メニューから、[ゴールデンとして設定 (Set as Golden)] を選択します。

テンプレートがすでにタグ付けされている場合、オプションは [ゴールデンの削除 (Remove Golden)] に変更され、現在のバージョンからタグを削除できます。

タグ付けされたバージョンは、テンプレートのバージョン履歴画面でスターアイコンで示されます。

履歴の表示と以前のバージョンの比較

ここでは、テンプレートの以前のバージョンを表示し、現在のバージョンと比較する方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)]ビューで、確認するテンプレートを選択します。

ステップ 5

テンプレートのアクション（...）メニューから、[履歴の表示 (View History)] を選択します。

ステップ 6

[バージョン履歴 (Version History)] ウィンドウで、適切な選択を行います。

1. [ゴールデン バージョン (Golden Versions)] チェックボックスをオンにして、以前のバージョンのリストをフィルタリングし、Golden としてマークされていたこのテンプレートのバージョンのみを表示します。

「Golden」としてのテンプレートのタグ付けについては、タギング テンプレートを参照してください。

2. 以前のバージョンのリストをフィルタリングして、サイトに展開されていたこのテンプレートのバージョンのみを表示するには、[展開済みバージョン (Deployed Versions)]チェックボックスをオンにします。

新しいテンプレート バージョンは、テンプレートが変更され、スキーマが保存されるたびに作成されます。ある時点でサイトに実際に展開されたテンプレートのバージョンのみを表示するように選択できます。

3. 特定のバージョンをクリックして、現在のバージョンと比較します。

選択したバージョンは、常にテンプレートの現在のバージョンと比較されます。[ゴールデンバージョン (Golden Versions)] または [導入済みバージョン (Deployed Versions)] フィルタを使用してリストをフィルタリングした場合でも、導入済みまたはゴールデンとしてタグ付けされていない場合でも、現在のバージョンが常に表示されます。

4. [編集 (Edit)] アイコンの上にマウスを置くと、バージョンの作成者と作成日時に関する情報が表示されます。

ステップ 7

[OK] をクリックして、バージョン履歴ウィンドウを閉じます。

以前の製品バージョンへの復元

ここでは、以前のバージョンのテンプレートを復元する方法について説明します。テンプレートを元に戻す場合、次のルールが適用されます。

- ターゲット バージョンが存在しないオブジェクトを参照している場合、復元操作は許可されません。

- ターゲットバージョンが NDO で管理されなくなったサイトを参照している場合、復元操作は許可されません。

- 現在のバージョンが、ターゲット バージョンが展開されていない 1 つ以上のサイトに展開されている場合、復元操作は許可されません。

テンプレートを元に戻す前に、まずそれらのサイトから現在のバージョンを展開解除する必要があります。

- ターゲット バージョンが、現在のバージョンが展開されていない 1 つ以上のサイトに展開されている場合、復元操作は許可されます。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)]ビューで、確認するテンプレートを選択します。

ステップ 5

[アクション (Actions)] メニューから、[バージョンの復元 (Restore Version)] を選択します。

ステップ 6

[バージョンの復元 (Restore Version)] ウィンドウで、復元する以前のバージョンのいずれかを選択します。

[ゴールデン バージョン (Golden Versions)] チェックボックスと[展開済みバージョン (Deployed Versions)] チェックボックスを使用して、バージョンのリストをフィルタリングできます。

バージョンを選択すると、そのバージョンのテンプレート設定をテンプレートの現在のバージョンと比較できます。

ステップ 7

[復元 (Restore) ] をクリックして、選択したバージョンを復元します。

以前のバージョンを復元すると、前の手順で選択したバージョンと同じ設定の新しいバージョンのテンプレートが作成されます。

たとえば、最新のテンプレートバージョンが 3 で、バージョン 2 を復元すると、バージョン 4 が作成されます。バージョン 2 の設定と同じだからです。復元を確認するには、テンプレートのバージョン履歴を参照し、現在の最新バージョンと復元時に選択したバージョンを比較します。

テンプレートのレビューと承認（変更管理）が無効になっており、アカウントにテンプレートを展開するための適切な権限がある場合は、復元したバージョンを展開できます。

ただし、変更制御が有効になっている場合は、次のようになります。

- 以前に展開したバージョンに戻し、アカウントにテンプレートを展開するための正しい権限がある場合は、すぐにテンプレートを展開できます。

- 以前に展開されていなかったバージョンに戻す場合、またはアカウントにテンプレートを展開するための適切な権限がない場合は、復元されたバージョンを展開する前にテンプレートの承認を要求する必要があります。

レビューと承認プロセスに関する追加情報については、テンプレートのレビューと承認セクションを参照してください。

テンプレートのレビューと承認

リリース 3.4(1) では、テンプレートのレビューと承認（変更管理）のワークフローのサポートが追加されます。これにより、テンプレートの設計者、レビュー担当者、承認者、およびテンプレートの導入者に指定されたロールを設定し、また、導入した設定が検証プロセスを確実にパスできるようにします。

テンプレート設計者は、NDO UI 内から、作成したテンプレートのレビューを要求できます。その後、レビュー担当者は、テンプレートのすべての設定変更の履歴と、誰がいつ変更したかに関する情報を表示できます。この時点で、テンプレートの現在のバージョンを承認または拒否できます。テンプレート設定が拒否された場合、テンプレート設計者は必要な変更を行い、レビューを再要求できます。テンプレートが承認されると、展開担当者のロールを持つユーザがサイトに展開できます。最後の点として、導入者自身が承認済みテンプレートの導入を拒否し、レビュー プロセスを最初からやり直すことができます。

ワークフローはスキーマ レベルではなくテンプレート レベルで実行されるため、各テンプレートを個別に設定、確認、承認できます。

（注）

レビューと承認のワークフローは、Nexus Dashboard で定義されたユーザ ロールに依存するため、この機能を使用するには、Nexus Dashboard リリース2.1(1) 以降を実行する必要があります。Nexus Dashboard リリース 2.0.2 で Nexus Dashboard Orchestrator を展開した場合、プラットフォームをアップグレードするまで、確認と承認の機能は無効になります。

- テンプレート承認要件の有効化

- 必要なロールを持つユーザの作成

- テンプレートのレビューと承認の要求

- テンプレートのレビューと承認

テンプレート承認要件の有効化

テンプレートの設定と展開に確認と承認のワークフローを使用するには、Nexus Dashboard Orchestrator のシステム設定でこの機能を有効にする必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[インフラストラクチャ (Infrastructure)] > [システムの設定 (System Configuration)]を選択します。

ステップ 3

[変更制御 (Change Control)] タイルで、[編集 (Edit)] アイコンをクリックします。

ステップ 4

[変更制御 (Change Control)] ウィンドウで、[変更制御ワークﾌー (Change Control Workflow)] チェックボックスをオンにして機能を有効にします。

ステップ 5

[承認者 (Approvers)] フィールドに、テンプレートを展開する前に必要な一意の承認の数を入力します。

ステップ 6

[保存（Save）] をクリックして、変更内容を保存します。

必要なロールを持つユーザの作成

テンプレートの設定と展開のため、レビューと承認のワークフローを実施する前に、NDO サービスが展開されている Nexus ダッシュボードで必要な権限を持つユーザーを作成する必要があります。

手順

ステップ 1

Nexus Dashboard の GUI にログインします。

NDO GUI でユーザーを作成または編集することはできません。サービスが展開されている Nexus ダッシュボード クラスタに直接ログインする必要があります。

ステップ 2

左のナビゲーション メニューから、[管理 (Administrative)] > [ユーザー (Users)]を選択します。

ステップ 3

必要なユーザーを作成します。

ワークフローは、テンプレート設計者、承認者、および展開者という 3 つの異なるユーザー ロールに依存します。各ロールを異なるユーザーに割り当てることも、同じユーザーにロールの組み合わせを割り当てることもできます。管理者権限を持つユーザは、3 つのアクションすべてを実行できます。

Nexus Dashboard にはデザイナー ロールが事前定義されていないため、デザイナーの義務は、デフォルトの管理者ユーザーロールに加えて、書き込み権限を持つテナント マネージャーまたはサイト マネージャー ユーザーに割り当てられます。

- テナント マネージャーは、デザイナーが特定のテナント（またはテナントのサブセット）にのみ関連付けられているテンプレートに変更を加える必要がある場合に使用する必要があります。この場合、ユーザーを特定のテナントにマッピングする必要があります。

- サイト マネージャーは、デザイナーが異なるテナントに属するテンプレートに変更を加える必要がある場合使用する必要があります。

デザイナー ロールとは対照的に、Nexus Dashboard には、ユーザーに関連付けることができる事前定義された承認者および展開者の役割があります。承認者および展開者のロールは、設計上、特定のテナントにバインドされていません。ただし、デザイナーと承認者（またはデザイナーと展開者）の両方の権限を持つユーザーロールを作成する場合は、上記と同じガイドラインに従ってください。

ローカルまたはリモートの Nexus ダッシュボード ユーザーのユーザーとその権限の設定の詳細については、 『Nexus Dashboard User Guide』を参照してください。

承認者ロールを持つ別個のユーザーが、テンプレート承認要件の有効化で設定した承認の最小数と同数以上必要です。

（注）

変更制御ワークフロー機能を無効にすると、承認者と展開者のユーザーは Nexus Dashboard Orchestrator に読み取り専用でアクセスできます。

テンプレートのレビューと承認の要求

ここでは、テンプレートのレビューと承認を要求する方法について説明します。

始める前に

次のものが必要です。

- 承認要件のグローバル設定を有効にした（テンプレート承認要件の有効化を参照）。

- 承認者ロールと展開者ロールを使用してNexusダッシュボードでユーザを作成または更新した（必要なロールを持つユーザの作成を参照）。

- 1 つ以上のポリシー設定を含むテンプレートを作成し、1 つ以上のサイトに割り当てた。

手順

ステップ 1

テナント マネージャ、サイト マネージャ、または管理者 ロールを持つユーザーとして Nexus Dashboard Orchestrator GUI にログインします。

ステップ 2

テナント マネージャ ロールを割り当てた場合は、ユーザーをテナントに関連付けます。

サイト マネージャ または 管理者 ロールを使用していた場合は、この手順をスキップしてください。

テナント マネージャ ロールを割り当てる場合は、ユーザーが管理する特定のテナントにユーザーを関連付ける必要もあります。

1. 左型のナビゲーションメニューから、[アプリケーション管理（Application Management）]> > [テナント（Tenants）] を選択します。

2. ユーザーが管理するテナントを選択します。

3. Nexus Dashboard で作成したデザイナー ユーザーの横にあるチェックボックスをオンにします。

4. ユーザーが管理する他のすべてのテナントについて、この手順を繰り返します。

ステップ 3

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 4

承認を要求するテンプレートを含むスキーマをクリックします。

ステップ 5

スキーマビューで、テンプレートを選択します。

ステップ 6

メイン ペインで、[承認のために送信 (Send for Approval)] をクリックします。

[承認のために送信 (Send for Approval)] ボタンは、次の場合には使用できません。

- グローバル変更制御オプションが有効になっていない

- テンプレートにポリシー設定がないか、どのサイトにも割り当てられていない

- ユーザにテンプレートを編集する権限がない

- テンプレートは承認のためにすでに送信されている

- テンプレートが承認者ユーザによって拒否された

テンプレートのレビューと承認

ここでは、テンプレートのレビューと承認を要求する方法について説明します。

始める前に

次のものが必要です。

- 承認要件のグローバル設定を有効にした（テンプレート承認要件の有効化を参照）。

- 承認者ロールと展開者ロールを使用してNexusダッシュボードでユーザを作成または更新した（必要なロールを持つユーザの作成を参照）。

- 1 つ以上のポリシー設定を含むテンプレートを作成し、1 つ以上のサイトに割り当てた。

- テンプレートのレビューと承認の要求に記載されているように、スキーマエディタによってテンプレートの承認が要求されました。

手順

ステップ 1

承認者 (Approver) または管理者 (admin) ロールを持つユーザとして Nexus Dashboard Orchestrator GUIにログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

確認して承認するテンプレートを含むスキーマをクリックします。

ステップ 4

スキーマビューで、テンプレートを選択します。

ステップ 5

メインペインで、[承認 (Approve)] をクリックします。

すでにテンプレートを承認または拒否している場合は、テンプレート デザイナが変更を行い、再確認のためにテンプレートを再送信するまで、このオプションは表示されません。

ステップ 6

[テンプレートの承認 (Approving template)] ウィンドウでテンプレートを確認し、[承認 (Approve)] をクリックします。

承認画面には、テンプレートがサイトに展開するすべての変更が表示されます。

[バージョン履歴の表示 (View Version History)] をクリックすると、完全なバージョン履歴と、バージョン間で行われた増分変更を表示できます。バージョン履歴の詳細については、履歴の表示と以前のバージョンの比較を参照してください。

[展開計画 (Deployment Plan)] をクリックして、このテンプレートから展開される設定の可視化と XML を表示することもできます。[展開計画 (Deployment Plan)] ビューの機能は、現在展開されている設定の表示で説明した、すでに導入されているテンプレートの [展開ビュー (Deployed View)] に似ています。

テンプレートの展開

ここでは、新しいポリシーまたは更新されたポリシーを ACI ファブリックに展開する方法について説明します。

始める前に

このドキュメントの前のセクションで説明したように、作成されたサイトには、展開するスキーマ、テンプレート、およびオブジェクトが必要です。

テンプレートのレビューと承認で説明しているように、テンプレートの確認と承認が有効になっている場合は、必要な数の承認者によってテンプレートがすでに承認されている必要があります。

手順

ステップ 1

展開するテンプレートを含むスキーマに移動します。

ステップ 2

左側のサイドバーで、展開するテンプレートを選択します。

ステップ 3

テンプレート編集ビューの右上で、[展開（Deploy）]をクリックします。

[サイトに展開 (Deploy to Sites)] ウィンドウが開き、展開するオブジェクトの概要が表示されます。

ステップ 4

テンプレートに変更を加えた場合は、[展開の計画（Deployment Plan）] を確認して新しい構成を確認します。

以前にこのテンプレートを展開したが、それ以降に変更を加えていない場合は、[展開] の概要に変更がないことが示され、テンプレート全体を再展開することを選択できます。この場合は、この手順をスキップできます。

[サイトに展開 (Deploy to Sites)] ウィンドウには、サイトに展開される構成の違いの概要が表示されます。次のスクリーンショットは、サイト 2 の既存の EPG（EPG1-S2）にコンシューマコントラクトを追加する簡単な例を示しています。

情報目的で [作成日 (Created)]、[変更日 (Modified)]、および [削除済み (Deleted)] チェックボックスを使用してビューをフィルタリングすることもできますが、[展開 (Deploy)]をクリックするとすべての変更が展開されることに注意してください。

ここでは、次のことも選択できます。

- [バージョン履歴の表示 (View Version History)] を選択すると、完全なバージョン履歴とバージョンアップグレードで行われた更新内容を表示します。バージョン履歴の詳細については、履歴の表示と以前のバージョンの比較を参照してください。

- [展開プラン (Deployment Plan)]を確認して、このテンプレートから展開される構成の可視化と XML ペイロードを表示します。

この機能により、テンプレートに変更を加えて 1 つ以上のサイトに展開した後に、Orchestrator がマルチサイトドメインの一部であるさまざまなファブリックにプロビジョニングする構成の変更を、より適切に可視化できます。

テンプレートとサイト構成に加えられた特定の変更のリストを引き続き提供していた Multi-Site Orchestrator の以前のリリースとは異なり、展開プランでは、テンプレートの展開によってさまざまなファブリック全体にプロビジョニングされる、すべてのオブジェクトに対する完全な可視性が提供されます。たとえば、変更内容によっては、特定の変更が 1 つのサイトのみに適用された場合でも、シャドウオブジェクトが複数のサイトに作成される場合があります。

（注）

テンプレートを展開する前に、この手順で説明されているように、展開プランを使用して変更を確認することをお勧めします。構成変更の視覚的に示すことは、意図しない構成変更の展開による潜在的なエラーを低減するのに役立ちます。

1. [展開プラン（Deployment Plan）] ボタンをクリックします。

前のステップで示したのと同じ例で続けると、コンシューマコントラクトがサイト 2 の既存の EPG に追加され、展開計画では、サイト 2 への変更の結果として、サイト 1 に展開される追加の変更があることも確認できます。

2. 最初にリストされたサイトで変更を確認します。

強調表示された凡例に基づいて、Orchestrator がサイト 2 の EPG に追加したコントラクトに必要なシャドウ オブジェクトをサイト 1 に作成することがわかります。

3. 前のサブステップを繰り返して、他のサイトの変更を確認します。

ここでは、コントラクト（C1-EFT）をサイト 2 に割り当てたときに、サイト 2 の EPG（EPG1-S2）に明示的に加えた変更と、そのコントラクトを提供している他のサイトの EPG（EPG1-S1）のシャドウオブジェクトを確認できます。

4. （オプション）[ペイロードの表示（View Payload）] をクリックすると、各サイトの XML ペイロードを表示できます。

新規および変更されたオブジェクトの視覚的表現に加えて、各サイトの変更について [ペイロードの表示（View Payload）] を選択することもできます。

5. 変更の確認が完了したら、[X] アイコンをクリックして [展開プラン（Deployment Plan）] 画面を閉じます。

ステップ 5

[サイトに展開（Deploy to sites）] ウィンドウで、[展開（Deploy）] をクリックしてテンプレートを展開します。

テンプレートの展開解除

ここでは、サイトからテンプレートを展開解除する方法について説明します。

始める前に

- テンプレートを最後に展開してから、テンプレートに変更を加えていないことを確認します。

最後に展開された後に変更されたテンプレートを展開解除すると、テンプレートに展開されたオブジェクトのセットが、テンプレートに変更を加えた後に展開解除しようとするオブジェクトのセットと異なるため、設定がずれる可能性があります。

手順

ステップ 1

展開解除するテンプレートを含むスキーマを選択します。

ステップ 2

[サイト (SITES)] の下の左側のサイドバーで、展開を解除するテンプレートを選択します。

ステップ 3

テンプレートを展開解除します。

1. テンプレートの横にある [その他のオプション (More options) ( ...)] メニューをクリックします。

2. [テンプレートの展開解除 (Undeploy Template)] をクリックします。

サイトからのテンプレートの関連付け解除

展開を解除せずに、サイトからテンプレートの関連付けを解除することもできます。これにより、NDO からサイトに展開された設定を保持しながら、スキーマのテンプレートとサイトの関連付けを削除できます。管理対象オブジェクトとポリシーの所有権が NDO からサイトのコントローラに移されます。

始める前に

- テンプレートとその設定がサイトにすでに展開されている必要があります。

- テンプレートは、単一のサイトにのみ展開し、サイト間で展開しないようにする必要があります。

- テンプレートで定義されたオブジェクトは、他のサイトのシャドウ オブジェクトとして展開しないでください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

関連付けを解除するテンプレートを含むスキーマをクリックします。

ステップ 4

スキーマ ビューで、関連付けを解除する特定のサイトの下のテンプレートを選択します。

ステップ 5

[アクション (Actions)] メニューから [テンプレートの関連付け解除 (Disassociate Template)] を選択します。

ステップ 6

確認ウィンドウで、[アクションの確認 (Confirm Action)] をクリックします。

設定のばらつき

APIC ドメインに実際に展開された設定が、Nexus Dashboard Orchestrator でそのドメインに対して定義された設定と異なる場合があります。これらの設定の不一致は、設定のばらつきと呼ばれ、次の図に示すように、スキーマ ビューのテンプレート名の横に感嘆符で示されます。

設定のばらつきは、さまざまな理由で発生する可能性があります。設定のばらつきを解決するために必要な実際の手順は、その原因によって異なります。最も一般的なシナリオとその解決策を次に示します。

- NDO で設定が変更された：NDO GUIでテンプレートを変更すると、変更をサイトに展開するまでは、設定のばらつきとして表示されます。

このタイプの設定のずれを解決するには、テンプレートを展開して変更をサイトに適用するか、スキーマの変更を元に戻します。

- 設定がサイトの APIC で直接変更された：NDO から展開されたオブジェクトは、サイトの APIC で警告アイコンとテキストで示されます。管理ユーザー、設定のずれの原因に対し、引き続き変更を加えられます。

- ローカルの変更を取り消す場合は、NDO からテンプレートを再展開して、サイトレベルで行われた手動の変更を上書きします。

- ローカルの変更を保持する場合は、変更したオブジェクトをサイトから NDO テンプレートにインポートし、スキーマを保存して、サイトに再展開します。

- NDO 設定がバックアップから復元された：NDO のバックアップから設定を復元すると、バックアップが作成されたときのオブジェクトとその状態のみが復元され、復元された設定は自動的に再展開されません。そのため、バックアップが作成されてから設定に変更が加えられた場合、バックアップを復元すると設定がずれる可能性があります。

- バックアップ以降の変更を保存する場合は、設定の復元後に変更したオブジェクトをサイトから NDO テンプレートにインポートし、スキーマを保存して、サイトに再展開します。

- 変更を保持しない場合は、NDO からテンプレートを再展開して、サイトレベルで設定の不一致を上書きします。

これにより、NDO から管理できるオブジェクトおよびオブジェクトのプロパティの設定を上書きできることに注意してください。 APIC レベルで設定され、NDO から直接管理できない追加のオブジェクトとプロパティは削除されません。

- NDO 設定は、古いリリースで作成されたバックアップから復元された：新しいリリースで、以前のリリースではサポートされていなかったオブジェクト プロパティのサポートが追加された場合、これらのプロパティによって設定がずれる可能性があります。通常、これは、サイトの APIC で新しいプロパティが変更され、値がデフォルトと異なる場合に発生します。

- オブジェクトのプロパティをデフォルト値にリセットする場合は、テンプレートを再展開します。

- 新しくサポートされたオブジェクト プロパティにすでに設定されているカスタム値を保持する場合は、変更したオブジェクトをサイトから NDO テンプレートにインポートし、スキーマを保存して、テンプレートをサイトに再展開します。

- NDO が以前のリリースからアップグレードされた：このシナリオは、新しいオブジェクト プロパティが新しいリリースに追加された場合に、既存の設定がずれている可能性がある、前のシナリオと似ています。

- オブジェクトのプロパティをデフォルト値にリセットする場合は、テンプレートを再展開します。

- 新しくサポートされたオブジェクト プロパティにすでに設定されているカスタム値を保持する場合は、変更したオブジェクトをサイトから NDO テンプレートにインポートし、スキーマを保存して、テンプレートをサイトに再展開します。

スキーマの複製

このセクションでは、[スキーマ (Schemas)] 画面の [スキーマの複製 (Clone Schema)] 機能を使用して、既存のスキーマとそのすべてのテンプレートのコピーを作成する方法について説明します。

（注）

テンプレートを複製し、異なる構成で同じサイトに展開しようとすると、名前の重複エラーが原因で展開が失敗する可能性があります。複製されたテンプレートのオブジェクト名を変更すると、表示名のみが更新されます。データベース レコードは変更されないため、このシナリオでは展開が失敗します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

複製するスキーマを選択します。

1. 左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

2. 複製するスキーマ名の横にある [アクション (Actions)] メニューから、[スキーマの複製 (Clone Schema)] を選択します。

ステップ 3

新しいスキーマの名前を入力し、[複製 (Clone)] をクリックします。

[複製 (Clone)] をクリックすると、UI に [<スキーマ名の複製に成功しました (Cloning of <schema-name> was successful)] というメッセージが表示され、新しいスキーマが [スキーマ (Schemas)] 画面に表示されます。

新しいスキーマは、元のスキーマとまったく同じテンプレート（およびそのテナントの関連付け）、オブジェクト、およびポリシー設定で作成されます。

テンプレート、オブジェクト、および設定はコピーされますが、サイトの関連付けは保持されないため、それらを展開するサイトに複製されたスキーマのテンプレートを再度関連付ける必要があります。同様に、テンプレート オブジェクトをサイトに関連付けた後に、テンプレート オブジェクトのサイト固有の設定を指定する必要があります。

ステップ 4

（オプション）スキーマとそのすべてのテンプレートがコピーされたことを確認します。

2 つのスキーマを比較することで、操作が正常に完了したことを確認できます。

テンプレートの複製

ここでは、スキーマ ビューで [テンプレートの複製 (Clone Template)]機能を使用して既存のテンプレートのコピーを作成する方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

複製するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)] ビューで、[テンプレートのクローン (Clone Template)] ダイアログを開きます。

1. 複製するテンプレートを選択します。

2. [アクション (Actions)] メニューから [テンプレートのクローン (Clone Template)] を選択します。

ステップ 5

クローンの複製先の詳細を入力します。

1. [複製先テナント (Destination Tenant)] ドロップダウンから、ターゲット テナントを選択します。

デフォルトでは、現在のテンプレートのテナントが選択されています。テナントを変更すると、代わりに新しいテンプレートが選択したテナントに割り当てられます。

複製先テナントはすでに存在している必要があります。テンプレートを複製して新しいテナントに割り当てる場合は、まず[テナント (Tenants)] ページでテンプレートを作成してから、テンプレートに戻って複製する必要があります。

（注）

異なるテナント間で複製する場合、他のテンプレートのオブジェクトを参照するオブジェクトをテンプレートに含めることはできません。

2. [複製先スキーマ (Destination Schema)]ドロップダウンから、テンプレートのクローンを作成するスキーマの名前を選択します。

このテンプレートのクローンを含めるために、同じスキーマまたは異なるスキーマを選択できます。まだ存在しないスキーマにテンプレートを複製する場合は、スキーマの名前を入力し、[作成 (Create) <schema-name>]オプションを選択して新しいスキーマを作成できます。

（注）

異なるスキーマ間で複製する場合、テンプレートには他のテンプレートのオブジェクトを参照するオブジェクトを含めることはできません。

3. [テンプレート名（Template Name）] フィールドに、テンプレートの名前を入力します。

4. [保存 (Save)] をクリックして、クローンを作成します。

新しいテンプレートが、選択したテナントと元のテンプレートとまったく同じオブジェクトおよびポリシー設定で複製先スキーマに作成されます。

選択した複製先スキーマがソーステンプレートと同じスキーマである場合、スキーマ ビューがリロードされ、新しいテンプレートが左側のサイドバーに表示されます。別のスキーマを選択した場合は、そのスキーマに移動して新しいテンプレートを表示および編集できます。

テンプレート オブジェクトと設定はコピーされますが、サイトの関連付けは保持されないため、複製したテンプレートを展開するサイトに再度関連付ける必要があります。同様に、テンプレート オブジェクトをサイトに関連付けた後に、テンプレート オブジェクトのサイト固有の設定を指定する必要があります。

テンプレート間でのオブジェクトの移行

ここでは、テンプレートまたはスキーマ間でオブジェクトを移動する方法について説明します。1 つ以上のオブジェクトを移動すると、次の制約事項が適用されます。

- テンプレート間で移動できるのは、EPG および Bridge Domain (BD) オブジェクトのみです。

- クラウド APIC サイトとの間でのオブジェクトの移行はサポートされていません。

オンプレミスサイト間でのみオブジェクトを移行できます。

- 送信元と宛先のテンプレートは同じスキーマにも異なるスキーマにもすることができますが、テンプレートは同じテナントに割り当てる必要があります。

- 宛先テンプレートが作成され、少なくとも 1 つのサイトに割り当てられている必要があります。

- 宛先テンプレートが展開されておらず、他のオブジェクトがない場合、そのテンプレートは、オブジェクトの移行後に自動的に展開されます。

- 1 つのオブジェクト移行を開始すると、同じ送信元またはターゲット テンプレートを含む別の移行を実行することはできません。テンプレートがサイトに展開されると、移行が完了します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左のナビゲーションメニューから [スキーマ(Schemas)] を選択します。

ステップ 3

移行するオブジェクトが含まれているスキーマをクリックします。

ステップ 4

[スキーマ (Schema)] ビューで、移行するオブジェクトが含まれているテンプレートを選択します。

ステップ 5

メインペインの右上にある [選択 (Select)] をクリックします。

これにより、移行する 1 つ以上のオブジェクトを選択できます。

ステップ 6

移行する各オブジェクトをクリックします。

選択したオブジェクトには、右上隅にチェックマークが表示されます。

ステップ 7

メインペインの右上にある [アクション (actions)] (...) アイコンをクリックし、[オブジェクトの移行 ( Migrate Objects)] を選択します。

ステップ 8

[オブジェクトの移行 (Migrate objects)] ウィンドウで、オブジェクトを移動する宛先スキーマとテンプレートを選択します。

リストには、少なくとも 1 つのサイトが接続されているテンプレートのみが表示されます。ドロップダウン リストにターゲット テンプレートが表示されない場合は、ウィザードをキャンセルし、そのテンプレートを少なくとも 1 つのサイトに割り当てます。

ステップ 9

[OK] をクリックし、[はい (YES)] をクリックしてオブジェクトを移動することを確認します。

オブジェクトは、ソーステンプレートから選択した宛先テンプレートに移行されます。設定を展開すると、ソーステンプレートが展開され、宛先テンプレートが展開されているサイトに追加されるサイトから、オブジェクトが削除されます。

ステップ 10

移行が完了したら、ソースと宛先の両方のテンプレートを再展開します。

宛先テンプレートが展開されておらず、他のオブジェクトがない場合、そのテンプレートはオブジェクトの移行後に自動的に展開されるため、この手順をスキップできます。

現在展開されている設定の表示

特定のテンプレートからサイトに現在展開されているすべてのオブジェクトを表示できます。任意のテンプレートを何度でも展開、展開解除、更新、および再展開できますが、この機能では、これらすべてのアクションの結果としての最終的な状態のみが表示されます。たとえば、Template1 に VRF1 オブジェクトのみが含まれ、Site1 に展開されている場合、API はそのテンプレートの VRF1 蚤を返します。その後、BD1 を追加して再展開すると、その時点から、API は BD1 と VRF1 の両方のオブジェクトを返すようになります。

この情報は Orchestrator データベースから取得されるため、サイトのコントローラで直接行われた変更によって発生する可能性のある設定の変動は考慮されません。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

左側のサイドバーで、テンプレートを選択します。

ステップ 5

そのテンプレートの [展開ビュー (Deployed View)] を開きます。

1. テンプレートの名前の横にある [アクション (Actions)] メニューをクリックします。

2. [展開ビュー (Deployed View)] をクリックします。

ステップ 6

[展開ビュー (Deployed View)] 画面で、情報を表示するサイトを選択します。

サイトにすでに展開されているものと、テンプレートで定義されているものとのテンプレート設定の比較がグラフィカルに表示されます。

1. 色分けされた凡例は、この時点でテンプレートを展開する場合に作成、削除、または変更されるオブジェクトを示します。

テンプレートの最新バージョンがすでに展開されている場合、ビューには色分けされたオブジェクトは含まれず、現在展開されている設定が表示されます。

2. サイト名をクリックすると、その特定のサイトの設定を表示できます。

3. [XML/JSON 表示 (View XML/JSON)] をクリックすると、選択したサイトに展開されているすべてのオブジェクトの XML 設定が表示されます。

スキーマの概要と展開ビジュアライザ

1つ以上のオブジェクトが定義され、1つ以上のACIファブリックに展開されたスキーマを開くと、スキーマの [概要 (Overview)] ページに展開の概要が表示されます。

スキーマの概要

このページには、次の詳細が表示されます。

1. [一般 (General)]：名前や説明など、スキーマの一般情報を提供します。

2. [監査ログ (Audit Log)]：スキーマで実行されたアクションの監査ログの概要を提供します。

3. [サイト (Sites)] > [正常性 (Health)]：サイトの正常性ステータスでソートされた、このスキーマのテンプレートに関連付けられているサイトの数を提供します。

4. [サイト (Sites)] > [タイプ (Type)]：サイトのタイプでソートされた、このスキーマのテンプレートに関連付けられているサイトの数を提供します。

5. [テンプレートとサイトの関連付け (Template to Site Associations)] > [展開ステータス ( Deployment Status)]：1 つ以上のサイトに関連付けられているこのスキーマ内のテンプレートの数とその展開ステータスを提供します。

6. [テンプレートとサイトの関連付けの整合性（Template to Site Associations Consistency）]：展開されたテンプレートで実行された整合性チェックの数とそのステータスを提供します。 >

7. [アプリケーション管理 (Application Management)]：このスキーマのテンプレートに含まれる個々のオブジェクトの概要を提供します。

[トポロジ (Topology)] タイルでは、次の図に示すように、1 つ以上のオブジェクトを選択してダイアグラムに表示することで、トポロジ ビジュアライザを作成できます。

展開ビジュアライザ

1. 凡例 (Legent)：次のトポロジ図に表示するポリシーオブジェクトを選択できます。

2. [フィルタ (Filter)]：表示されるオブジェクトを名前に基づいてフィルタリングできます。

3. [トポロジ図 (Topology Diagram)]：サイトに割り当てられているすべてのスキーマ テンプレートで設定されたポリシーを視覚的に表示します。

上記の [設定オプション (Configuration Options)] を使用して、表示するオブジェクトを選択できます。

また、オブジェクトの上にマウスを置くと、すべての依存関係を強調表示できます。

最後に、図内の任意のオブジェクトをクリックすると、他のオブジェクトとの関係だけが表示されます。たとえば、テンプレートをクリックすると、その特定のテンプレート内のすべてのオブジェクトのみが表示されます。

シャドウ オブジェクト

プロバイダとコンシューマーが異なる VRF にあり、テナント コントラクトを介して通信する拡張 VRF または共有サービスの使用例で、サイト ローカル EPG 間にコントラクトが存在する場合、EPG とブリッジ ドメイン (BD) はリモート サイトにミラーリングされます。ミラーされたオブジェクトは、これらのサイトのそれぞれの APIC で展開されているかのように表示される一方で、実際にはサイトの １つでだけ展開されています。これらのミラーされたオブジェクトは、「シャドウ」オブジェクトと呼ばれます。

（注）

シャドウ オブジェクトは、APIC GUI を使用して削除する必要があります。

たとえば、テナントと VRF が Site1 と Site2 の間でストレッチされ、プロバイダ EPG とそのブリッジ ドメインが Site2 のみに展開され、コンシューマ EPG とそのドメインが Site1 のみに展開される場合、対応するシャドウ ブリッジ ドメインと EPG は次の図のように展開されます。これらは、直接展開されている各サイトでの名前と同じ名前で表示されます。

基本的なシャドウ EPG

次のオブジェクトはシャドウ オブジェクトになる場合があります。

- VRF

- ブリッジ ドメイン (BD)

- L3Out

- 外部 EPG

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

- アプリケーション EPG

- コントラクト（ハイブリッド クラウド展開）

ファブリックが APIC リリース 5.0(2) 以降で実行されている場合、APIC GUI でシャドウ オブジェクトを選択すると、 が表示されます。これはサイト間ポリシーをサポートするために、MSC からプッシュされたシャドウ オブジェクトです。このオブジェクトを変更または削除しないでください。 メイン GUI ペイン上部の警告。さらに、VMM ドメインの一部ではないシャドウ EPG にはスタティック ポートがないいぽプで、シャドウ BD は、APIC GUI で [デフォルト SVI ゲートウェイなし (No Default SVI Gateway)]のオプションがあります。

シャドウ オブジェクトのその他の使用例

シャドウ オブジェクトは、次の図に示すように、[優先グループ (Preferred Group)]、[vzAny]、[レイヤ3マルチキャスト (Layer 3 Multicast)]、およびハイブリッド クラウドなど、さまざまな使用例でも作成されます。

優先グループ

マルチキャストの場合、シャドウ オブジェクトは、マルチキャスト ソースが接続され、オプションが EPG レベルで明示的に設定されている EPG/BDに対してのみ作成されます。

L3 マルチキャスト

ハイブリッド クラウド展開の場合、ストレッチされたオブジェクトであっても、暗黙のコントラクトが存在するシャドウ オブジェクトを作成します。たとえば、EPG がオンプレミス サイトとクラウド サイトの間でストレッチされた場合、シャドウ外部 EPG は各サイトで作成され、ストレッチされた EPG とシャドウ外部 EPG の間に暗黙的なシャドウ コントラクトが作成されます。

ハイブリッドクラウド

Cisco APIC リリース 5.2(3) 以降、シャドウ オブジェクトは Cisco APIC GUI で一意のアイコンで示されます。通常の Orchestrator で作成されたオブジェクトは緑のクラウドの記号で表示されますが、シャドウ オブジェクトはグレーのクラウドのアイコンで表示されます。

- APIC GUI でシャドウ オブジェクトを非表示にする

APIC GUI でシャドウ オブジェクトを非表示にする

APIC リリース 5.0(2) 以降では、オンプレミス サイトの APIC GUI で Nexus Dashboard Orchestrator によって作成されたシャドウ オブジェクトを表示するか非表示にするかを選択できます。Cloud APIC のシャドウ オブジェクトは常に非表示です。

GUI からシャドウ オブジェクトを非表示にするには、次の点に注意してください。

- このオプションは、Orchestrator からグローバルに設定することはできません。また、このセクションで説明するように、各サイトの APIC で直接設定する必要があります。

- シャドウ オブジェクトを表示するオプションはすべての新しい APIC リリース 5.0(2) のインストールとアップグレードのデフォルトでオフに設定されているため、以前に表示されていたオブジェクトが非表示になる可能性があります。

- シャドウ オブジェクトの非表示は、Orchestrator リリース 3.0 (2) 以降で使用可能な、Nexus Dashboard Orchestrator によって設定されるフラグに依存しています。

- シャドウ オブジェクトが以前の Orchestrator バージョンによって展開されている場合は、必要なタグがなく、APIC GUI に常に表示されます。

- Shadow オブジェクトが Orchestrator バージョン 3.0(2) 以降で導入されている場合は、タグが付けられ、APIC GUI 設定を使用して非表示または表示にできます。

- Nexus Dashboard Orchestrator をアップグレードする前に、各ファブリックを APIC リリース 5.0(2) にアップグレードすることをお勧めします。

Nexus Dashboard Orchestrator をリリース 3.0(2) にアップグレードすると、APIC リリース 5.0(2) 以降を実行しているサイトに展開されたオブジェクトは、適切なタグでタグ付けされ、再展開しなくても、APIC GUI を使用して表示または非表示にできます。

ファブリックの APIC の前に Orchestrator をアップグレードする場合、サイトのオブジェクトはタグ付けされず、フラグを設定するためにファブリックをアップグレードした後に設定を手動で再展開する必要があります。

- リリース 5.0(2) よりも前のリリースにファブリックをダウングレードした場合、シャドウ オブジェクトは非表示にならず、APIC GUI に異なるアイコンが表示されることがあります。

手順

ステップ 1

サイトの APIC にログインします。

ステップ 2

右上隅にある [マイ プロファイルの管理 (Manage my profile)] アイコンをクリックし、[設定 (Settings)] を選択します。

ステップ 3

[アプリケーション設定 (Application Settings)] ウィンドウで、[非表示のポリシーを表示 (Show Hidden Policies)] チェックボックスをオンまたはオフにします。

この設定はユーザ プロファイルに保存され、ユーザごとに個別に有効または無効になります。

ステップ 4

その他の APIC サイトについては、このプロセスを繰り返します。

PartII. 操作

- 監査ログ

- バックアップと復元

- サイトのアップグレード

- [Tech Support]

Chapter5. 監査ログ

- 監査ログ

監査ログ

Nexus Dashboard Orchestrator のシステム ロギングは、最初に Orchestrator クラスタをデプロイしたときに自動的に有効になり、環境内で発生したイベントと障害をキャプチャします。

GUI 内で直接 Nexus Dashboard Orchestrator のログを表示するには、メインのナビゲーション メニューから [操作 (Operations)] > [監査ログ (Audit logs)] を選択します。

[監査ログ (Audit Logs)] ページで、最新のフィールドをクリックして、ログを表示する特定の期間を選択できます。たとえば、2017 年 11 月 14日から 2017 年 11 月 17日までの範囲を選択し、[適用 (Apply)] をクリックすると、この期間の監査ログの詳細が [監査ログ (Audit Logs)] ページに表示されます。

次の基準に従ってログの詳細のフィルタ処理を行うには、[フィルタ (Filter)] アイコンをクリックします。

- ユーザ(User): ユーザ タイプに基づいて監査ログのフィルタ処理を行うには、このオプションを選択し、[適用 (Apply)] をクリックします。

- タイプ (Type)：監査ログをポリシータイプ（サイト、ユーザ、テンプレートなど）でフィルタリングするには、このオプションを選択して、[適用 (Apply)] をクリックします。

- アクション(Action): アクションに基づいて監査ログをフィルタ処理するには、このオプションを選択します。使用可能なアクションとしては作成、更新、削除、追加、関連付け、関連付けの解除解除、展開、展開の解除、ダウンロード、アップロード、復元、ログイン、ログの失敗があります。アクションに従ってログの詳細をフィルタ処理するには、アクションを選択して Apply をクリックします。

Chapter6. バックアップと復元

- 設定のバックアップと復元

- バックアップと復元に関するガイドライン

- バックアップのリモート ロケーションの設定

- バックアップのアップロード

- バックアップの作成

- バックアップの復元

- バックアップのダウンロード

- バックアップ スケジューラ

設定のバックアップと復元

Nexus Dashboard Orchestrator の障害またはクラスタの再起動からのリカバリを容易にする、Orchestrator 設定のバックアップを作成できます。Orchestrator の各アップグレードまたはダウングレードの前で、各設定の変更または展開後に、設定のバックアップを作成することを推奨します。バックアップは常に、Nexus Dashboard Orchestratorで定義されているリモート サーバ（Nexus Dashboard クラスタ以外）に作成されます。定義については、続くセクションで説明します。

バックアップと復元に関するガイドライン

設定のバックアップを保存および復元する際には、次のガイドラインが適用されます。

- より新しいリリースから作成されたバックアップのインポートおよび復元はサポートされていません。

たとえば、Nexus Dashboard Orchestrator を以前のリリースにダウングレードした場合、それ以降のリリースで作成された設定のバックアップを復元することはできません。

- リリース 3.2(1) より前のリリースで作成された設定バックアップの復元は、Nexus Dashboard へのクラスタ移行中のワンタイム ステップとしてサポートされます。

VMware ESX または Application Services Engine 展開で、 Multi-Site Orchestrator リリースからバックアップしていた場合、その後の復元はサポートされていません。

- バックアップを保存すると、設定は展開されたのと同じ状態で保存されます。バックアップを復元すると、展開されたすべてのポリシーが展開済みとして表示されますが、展開されていなかったポリシーは未展開の状態のままになります。

- バックアップ アクションを復元すると、Nexus Dashboard Orchestrator でのデータベースは復元されますが、各サイトのコントローラ（APIC、Cloud APIC、または DCNM など） データベースは変更されません。したがって、Nexus Dashboard Orchestrator と 各サイトのコントローラ間のポリシーが食い違う可能性を避けるため、Nexus Dashboard Orchestrator データベースを復元した後には、既存のスキーマを再展開する必要があります。

- バックアップはリモート ロケーションで作成する必要があります。

リリース 3.4(1) よりも前のリリースでは、クラスタを最初に展開したとき、作成していたバックアップは、各ノードのローカル ディスク上のデフォルトの場所に保存され、さらに Orchestrator クラスタ外のリモート ロケーションを設定して、そこにバックアップを再配置するオプションがありました。

リリース 3.4(1) 以降では、ローカル ディスク オプションは廃止されたので、すべてのバックアップは　Nexus ダッシュボード クラスタ外のリモート ロケーションに作成する必要があります。次のセクションの説明に従って、NDO GUI を使用してリモート SCP または SFTP ロケーションを設定し、そこにバックアップ ファイルをエクスポートできます。

リリース 3.3(1) 以前からリリース 3.4(1) 以降に初めてアップグレードする場合は、古いローカル バックアップのダウンロードとインポート の説明に従って、以前に作成したローカル バックアップをダウンロードできます。その後、リモート ロケーションを経由して、これらのバックアップを Nexus Dashboard Orchestrator に再インポートできます。

（注）

ローカル バックアップは復元できません。

- 設定のバックアップを作成してリモートサーバにエクスポートするときには、ファイルは最初に Orchestrators ローカル ドライブに作成され、その後リモートの場所にアップロードされ、最後にローカル ストレージから削除されます。十分なローカル ディスク領域がない場合、バックアップは失敗します。

- リリース 3.4(1) 以降にアップグレードする前に、ローカル バックアップを取得できるようバックアップ スケジューラを有効にしていた場合、アップグレード後に無効になります。

バックアップ以降の設定変更はありません

バックアップが作成されてから復元されるまでの間にポリシーの変更がない場合は、追加の考慮事項は必要ありません。また、バックアップの復元 の説明に従って設定を復元するだけです。

バックアップ以降に作成、変更、または削除されたサイト、オブジェクトまたはポリシー

設定のバックアップが作成されてから復元された時間までの間に設定変更が行われた場合は、次の点を考慮してください。

- バックアップを復元しても、サイトのオブジェクト、ポリシー設定は変更されません。バックアップ以降に作成および展開された新しいオブジェクトまたはポリシーは、展開されたままになります。古い設定を回避するには、バックアップを復元した後に手動でこれらを削除する必要があります。

または、すべてのポリシーを最初に展開解除することもできます。これにより、バックアップから設定が復元された後に、古いオブジェクトの潜在的な問題が回避されます。ただし、これにより、これらのポリシーによって定義されたトラフィックまたはサービスの中断が発生します。

- 設定のバックアップを復元するために必要な手順については、バックアップの復元 で説明しています。

- 復元した設定バックアップが、サイトに展開される前に保存されたものであった場合、未展開状態で復元されるので、必要に応じてサイトに展開できます。

- 復元した設定バックアップが、設定がすでに展開されているときに保存されたものであった場合、サイトにどの設定もまだ存在していなかったとしても、展開済み状態で復元されます。この場合、設定を各サイトに適切にプッシュするには、それを再展開して、Nexus Dashboard Orchestrator の設定をサイトと同期させる必要があります。

- バックアップの作成時に管理されていたサイトが Nexus ダッシュボードに存在しない場合、復元は失敗します。

- バックアップ後にサイトのステータス（管理対象と非管理対象）を変更していて、サイトが Nexus ダッシュボードにまだ存在している場合、ステータスはバックアップ時の状態に復元されます。

- 古いローカル バックアップのダウンロードとインポート

古いローカル バックアップのダウンロードとインポート

3.4(1) より前のリリースでは、オーケストレータのローカルディスクでの設定バックアップの作成がサポートされていました。リリース 3.4(1) 以降にアップグレードする前に、ローカル バックアップをダウンロードしておくことを推奨します。ただし、ローカル バックアップはアップグレード後も引き続きダウンロードできます。

アップグレード後に古いバックアップをダウンロードすることはできますが、UI で直接バックアップを復元することはできません。このセクションでは、このようなバックアップを Orchestrator GUI からローカルマシンにダウンロードし、今度はリモートロケーションを使用して Nexus Dashboard Orchestrator GUI に再インポートする方法について説明します。

始める前に

次の設定が済んでいる必要があります。

- リリース 3.3(1) 以前からリリース 3.4(1) 以降にアップグレードされていること。新しいリリースでは、ローカルバックアップはサポートされなくなりました。

- バックアップのリモート ロケーションの設定 の説明に従って、バックアップのためのリモート ロケーションが追加されていること。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[操作 (Operations)] > [バックアップと復元 (Backups & Restore)]を選択します。

ステップ 3

メイン ウィンドウで、ダウンロードするバックアップの隣のアクション (...) アイコンをクリックし、[ダウンロード (Download)]を選択します。

これにより、バックアップファイルがシステムにダウンロードされます。

ステップ 4

Nexus Dashboard Orchestrator GUIでダウンロードしたバックアップを削除します。

以前のバージョンから既存のローカルバックアップを削除せずにバックアップを再インポートしようとすると、同じ名前のバックアップファイルがすでに存在するため、アップロードが失敗します。

ダウンロードしたバックアップを削除するには、バックアップの横にあるアクション（...）メニューをクリックし、[削除 (Delete)] を選択します。

ステップ 5

バックアップをリモートの場所にインポートします。

バックアップのアップロードに記載されているように、リモート ロケーションを使用してダウンロードしたバックアップ ファイルを Nexus Dashboard Orchestrator に再アップロードします。

バックアップのリモート ロケーションの設定

このセクションでは、設定バックアップをエクスポートできる Nexus Dashboard Orchestrator のリモート ロケーションの設定方法を説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[操作 (Operations)] > [リモート ロケーション (Remote Loacation)]を選択します。

ステップ 3

メイン ウィンドウの右上隅で、[リモート ロケーションの追加 (Add Remote Location)] をクリックします。

[新規リモート ロケーションの追加 (Add New Remote Location)] 画面が表示されます。

ステップ 4

リモート ロケーションの名前と説明 (任意) を入力します。

現在、2 つのプロトコルが設定バックアップのリモート エクスポートに対してサポートされています。

- SCP

- ステップ

（注）

SCPは Windows 以外のサーバーでのみサポートされます。リモートロケーションが Windows サーバーの場合は、SFTP プロトコルを使用する必要があります。

ステップ 5

リモート サーバのホスト名または IP アドレスを指定します。

[プロトコル (Protocol)] セクションに基づいて、指定するサーバーでは SCP または SFTP 接続を許可する必要があります。

ステップ 6

バックアップを保証するリモート サーバーのディレクトリにフル パスを指定します。

パスの先頭にはスラッシュ (/) 文字を使用し、ピリオド (.) とバックスラッシュ (\) を含むことはできません。例: /backups/multisite

（注）

ディレクトリは、リモート サーバにすでに存在しなければなりません。

ステップ 7

リモート サーバに接続するために使用するポートを指定します。

デフォルトで、ポートは 22 に設定されます。

ステップ 8

リモート サーバに接続するときに使用される認証タイプを指定します。

次の 2 つの認証方式のうちの 1 つを使用して設定できます。

- パスワード—リモート サーバにログインするために使用されるユーザ名とパスワードを指定します。

- SSH プライベート ファイル—ユーザ名とリモート サーバにログインするために使用される SSH キー/パスフレーズのペアを指定します。

ステップ 9

[保存 (Save)] を使用して、リモート サーバを追加します。

バックアップのアップロード

ここでは、以前にダウンロードした既存の設定バックアップをアップロードし、Nexus Dashboard Orchestratorで設定されたリモートロケーションのいずれかにインポートする方法について説明します

始める前に

次の設定が済んでいる必要があります。

- バックアップの作成 および バックアップのダウンロード の説明に従って、設定のバックアップを作成されていること。

リリース 3.4(1) 以降で作成したバックアップなど、バックアップがすでにリモート ロケーションにある場合は、ローカル マシンにダウンロードして、別のリモート ロケーションにアップロードできます。

- バックアップのリモート ロケーションの設定 の説明に従って、バックアップのためのリモート ロケーションが追加されていること。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[操作 (Operations)] > [バックアップと復元 (Backups & Restore)]を選択します。

ステップ 3

メインペインで、[アップロード (Upload)] をクリックします。

ステップ 4

開いた [ファイルからのアップロード (Upload from file)] ウィンドウで、[ファイルを選択 (Select File)] を選択して、インポートするバックアップ ファイルを選択します。

バックアップをアップロードすると、[バックアップ (Backups)] ページに表示されるバックアップのリストに追加されます。

ステップ 5

[リモート ロケーション (Remote location)] ドロップダウンメニューから、リモート ロケーションを選択します。

ステップ 6

(オプション) リモート ロケーションのパスを更新します。

リモート バックアップのロケーションを作成するときに設定したリモート サーバ上のターゲット ディレクトリが、[リモート パス (Remote Path)] フィールドに表示されます。

パスにはサブディレクトリを追加することができます。ただし、ディレクトリはデフォルトの設定済みパスの下にある必要があり、すでにリモート サーバで作成されている必要があります。

ステップ 7

[アップロード (Upload)] をクリックしてファイルをインポートします。

バックアップのインポートは、[バックアップ (Backups)] ページに表示されたバックアップのリストにそれを追加します。

バックアップは NDO UI に表示されますが、リモート サーバーにのみ存在することに注意してください。

バックアップの作成

ここでは、Nexus Dashboard Orchestrator 設定の新しいバックアップを作成する方法について説明します。

始める前に

バックアップのリモート ロケーションの設定の説明に従って、最初にリモートロケーションを追加する必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

バックアップを新規作成します。

1. 左側のナビゲーション ペインで、[操作 (Operations)] > [バックアップと復元 (Backups & Restore)]を選択します。

2. メイン ウィンドウ ペインで、[新規バックアップ (New Backup)] をクリックします。

[新規バックアップ (New Backup)] ウィンドウが開きます。

ステップ 3

バックアップ情報を指定します。

1. バックアップの [名前 (Name)] とオプションの [メモ (Notes)] を指定します。

名前には、最大 10 文字の英数字を使用できますが、スペースまたはアンダースコア (_) は使用できません。

2. [リモート ロケーション (Remote location)] ドロップダウンから、バックアップ用に設定したリモート ロケーションを選択します。

3. [リモートパス (Remote Path)] では、デフォルトのターゲット ディレクトリのままにするか、またはパスにサブディレクトリを追加することができます。

ディレクトリはデフォルトの設定済みパスの下にある必要があり、すでにリモート サーバーで作成されている必要があることに注意してください。

4. [保存（Save）] をクリックして、バックアップを作成します。

バックアップの復元

このセクションでは、Orchestrator 設定を前の状態に復元する方法について説明します。

始める前に

バックアップ アクションを復元すると、Nexus Dashboard Orchestrator でのデータベースは復元されますが、各サイトのコントローラデータベースは変更されません。したがって、Nexus Dashboard Orchestrator と 各サイトのポリシーが食い違う可能性を避けるため、Nexus Dashboard Orchestrator データベースを復元した後には、既存のスキーマを再展開する必要があります。

特定の構成の不一致とそれぞれに関連する望ましい復元手順の詳細は、バックアップと復元に関するガイドラインを参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

必要に応じて、既存のポリシーの展開を解除します。

バックアップが作成されたときから現在の設定までに、設定に新しいオブジェクトまたはポリシーが追加されている場合は、この手順を実行することをお勧めします。追加情報については、バックアップと復元に関するガイドライン を参照してください。

ステップ 3

左側のナビゲーション メニューで、[操作 (Operations)] > [バックアップと復元 (Backups & Restore)]を選択します。

ステップ 4

メイン ウィンドウで、復元するバックアップの隣のアクション (...) アイコンをクリックし、[このバックアップにロールバック (Rollback to this backup)] を選択します。

選択したバックアップのバージョンが、実行中の Nexus Dashboard Orchestrator のバージョンと異なる場合、ロールバックが原因で、バックアップされたバージョンには存在しない機能が削除される可能性があります。

ステップ 5

[はい (Yes)] をクリックして、選択したバックアップを復元することを確認します。

[はい (Yes)] をクリックすると、システムは現在のセッションを終了して、ユーザはログアウトされます。

（注）

設定の復元プロセス中に複数のサービスが再起動されます。その結果、復元された設定が NDO GUI に正しく反映されるまでに最大 10 分の遅延が発生することがあります。

ステップ 6

必要に応じて、設定を再展開します。

復元された設定を APIC サイトと同期する際には、この手順を実行することをお勧めします。追加のコンテキストは、バックアップと復元に関するガイドライン にあります。

バックアップのダウンロード

ここでは、Nexus Dashboard Orchestrator からバックアップをダウンロードする方法について説明します。

始める前に

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[操作 (Operations)] > [バックアップと復元 (Backups & Restore)]を選択します。

ステップ 3

メイン ウィンドウで、ダウンロードするバックアップの隣のアクション (...) アイコンをクリックし、[ダウンロード (Download)]を選択します。

これにより msc-backups-<タイムスタンプ>.tar.gz 形式でシステムにバックアップ ファイルがをダウンロードされます。その後、ファイルを抽出してその内容を表示することができます。

バックアップ スケジューラ

ここでは、定期的に完全な設定バックアップを実行するバックアップスケジューラを有効または無効にする方法について説明します。

始める前に

バックアップのリモート ロケーションの設定 の説明に従って、バックアップのためのリモート ロケーションを追加してある必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[操作 (Operations)] > [バックアップと復元 (Backups & Restore)]を選択します。

ステップ 3

メイン ペインの右上にある [スケジューラ (Scheduler)] をクリックします。

[バックアップ スケジューラ設定 (Backup Scheduler Settings)] ウィンドウが開きます。

ステップ 4

バックアップ スケジューラをセットアップします。

1. [スケジューラの有効化 (Enable Scheduler)] チェックボックスをオンにします。

2. [開始日の選択 (Select Start Date)] フィールドに、スケジューラを開始する日を指定します。

3. [時間の選択 (Select Time)] フィールドに、スケジューラを開始する時刻を入力します。

4. [頻度の選択 (Select Frequency)] ドロップダウンから、バックアップを実行する頻度を選択します。

5. [リモート ロケーション (Remote Location)] ドロップダウンから、バックアップを保存する場所を選択します。

6. （オプション）[リモート パス (Remote Path)] フィールドで、バックアップが保存されるリモート ロケーションのパスを更新します。

リモート バックアップのロケーションを作成するときに設定したリモート サーバ上のターゲット ディレクトリが、[リモート パス (Remote Path)] フィールドに表示されます。

パスにはサブディレクトリを追加することができます。ただし、ディレクトリはデフォルトの設定済みパスの下にある必要があり、すでにリモート サーバで作成されている必要があります。

7. [OK] をクリックして終了します。

ステップ 5

バックアップ スケジューラを無効にする場合は、上記の手順で [スケジューラの有効化 (Enable Scheduler)]チェックボックスをオフにします。

Chapter7. サイトのアップグレード

- 概要

- 注意事項と制約事項

- コントローラとスイッチ ノードのファームウェアをサイトにダウンロードする

- コントローラのアップグレード

- ノードのアップグレード

概要

（注）

この機能は、Cisco APIC サイトでのみサポートされます。Cisco Cloud APIC または Cisco DCNM ファブリックではサポートされません。

リリース 3.1(1) よりも前は、Cisco Multi-Site を導入する際に、各サイトの APIC クラスタおよびスイッチ ノード ソフトウェアをサイト レベルで個別に管理する必要がありました。Multi-Site ドメイン内のサイトの数が増えると、リリースのライフ サイクルとアップグレードは、リリースと機能の互換性のために手動で調整および管理する必要があるため、複雑になる可能性があります。

リリース 3.1(1) 以降、Cisco Nexus Dashboard Orchestrator は、すべてのサイトのソフトウェア アップグレードを単一のポイントから管理できるワークフローを提供します。複数のサイト管理者がソフトウェア アップグレードを手動で調整する必要がなく、アップグレードに影響する可能性のある、潜在的な問題を把握できます。

[操作 (Operations)] > [サイトのファームウェア (Sites Firmware)]に移動して、サイトのアップグレード画面にアクセスできます。このページには 4 つのタブがあります。このセクションと次のセクションで説明します。

[概要 (Overview)] タブには、Multi-Site ドメイン内のサイトと、展開されている、または展開の準備ができているファームウェア バージョンに関する情報が表示されます。[サイト ファームウェア (Sites Firmware)] サービスは、5 分ごとにサイトをポーリングして、アップグレード ポリシーの最新のステータスなどの新しいデータまたは変更されたデータを探します。メイン ペインの右上隅にある [更新 (Refresh)] ボタンをクリックすると、手動で更新をトリガーできます。

サイトのファームウェアの概要

ページは次の 3 つの領域に分かれています。

- [ファームウェア アップデートの概要 (Firmware Update Summary)]：Cisco APICおよびスイッチ ファームウェアを含む、Multi-Site ドメイン内のすべてのサイトに存在するファームウェア イメージの全体的な概要を提供します。

イメージのタイプごとに、各状態のイメージ数を含む、固有の情報が表示されます。

- [完了 (Completed)]：イメージは現在、コントローラまたはスイッチに展開されています。

- [ダウンロード中 (Downloading)]（スイッチノードのみ）：イメージはスイッチ ノードにダウンロード中です。

- [インストールの準備完了 (Ready to Install)]（スイッチノードのみ）：イメージはスイッチノードに正常にダウンロードされ、インストールの準備ができています。

- [インストール (Installing)]：コントローラまたはスイッチノードに現在イメージを展開中です。

- [未サポート (Not Supported)]：リリース 4.2(5) より前のリリースなど、リモート ファームウェア アップグレードをサポートしていないイメージ。

- [サイト固有の情報 (Site-specific information) ]：ページの追加のセクションには、個々のサイトに関する情報が表示されます。これには、現在展開されているソフトウェアのバージョンと、コントローラまたはノードの数が含まれます。

注意事項と制約事項

Nexus Dashboard Orchestrator からファブリック アップグレードを実行する場合、次の制限が適用されます。

- 「Upgrade and Downgrading the Cisco APIC and Switch Software」（『Cisco APIC Installation、Upgrade、and Downgrade Guide』）に記載されている Cisco APIC アップグレード プロセスに固有のガイドライン、推奨事項、および制限事項を確認し、それに従う必要があります。

- Nexus Dashboard Orchestrator を Cisco Nexus Dashboard に展開する必要があります。

サイトのアップグレード機能は、VMware ESXのNDO導入では使用できません。また、 『Cisco APIC Installation、Upgrade、and Downgrade Guide』に記載されている標準のアップグレード手順に従う必要があります。

- ファブリックは、Cisco APIC リリース 4.2(5) 以降を実行している必要があります。

以前の APIC リリースを実行しているファブリックは、アップグレード ワークフロー中に選択できません。『Cisco APIC Installation、Upgrade、and Downgrade Guide』に記載されている標準のアップグレード手順に従います。

- サイトのアップグレードは、これらのファブリックを管理するサイト管理者と調整することを推奨します。潜在的な問題が発生した場合は、トラブルシューティングのためにコントローラまたはスイッチ ノードにアクセスする必要があります。

- アップグレード プロセスの途中でファブリック スイッチ ノードが非アクティブ状態になった場合（たとえば、ハードウェアまたは電源障害）、プロセスは完了できません。この間、ノード アップグレード ポリシーを削除または変更することはできません。これは、NDO がノードがダウンしたか、または単にアップグレードのリブート中かを区別できないためです。

この問題を解決するには、非アクティブ ノードを APIC から手動でデコミッションする必要があります。この時点で、NDO アップグレードポリシーは変更を認識し、失敗ステータスを返します。その後、NDO のアップグレード ポリシーを更新してスイッチを削除し、アップグレードを再実行できます。

コントローラとスイッチ ノードのファームウェアをサイトにダウンロードする

アップグレードを実行する前に、コントローラとスイッチ ソフトウェアをファブリック内のすべてのサイト コントローラにダウンロードする必要があります。次の手順を完了すると、後ほど、ダウンロードしたイメージを使用してアップグレード プロセスを開始できます。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

ファームウェア ダウンロードをセットアップします。

1. 左側のナビゲーション ペインで[操作 (Operations)] > [サイト ファームウェア (Sites Firmware)]を選択します。

2. メインウィンドウで [ダウンロード (Downloads)] タブを選択します。

3. [ダウンロードのセットアップ (Setup Downloads)] タブをクリックします。

以前に 1 つ以上ダウンロードをセットアップしていた場合は、代わりに、メインペインの右上にある [ダウンロードのセットアップ (Setup Downloads)] ボタンをクリックします。

[イメージを APIC へダウンロード (Download Image to APIC)] 画面が表示されます。

ステップ 3

サイトを選択します。

ここで選択したすべてのサイトの Cisco APIC にイメージがダウンロードされます。

1. [サイトの選択 (Select Sites)] をクリックします。

2. [サイトの選択 (Select Sites)] ウィンドウで、1 つ以上のサイトをオンにし、[追加して閉じる (Add and Close)] をクリックします。

3. [次へ（Next）] をクリックして続行します。

ステップ 4

詳細を入力します。

1. [名前 (Name)] を入力します。

ダウンロードを追跡するためのわかりやすい名前を指定します。

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

HTTP または SCP 経由でイメージをダウンロードすることを選択できます。

3. [+ URLの追加 (+ Add URL)] をクリックして、イメージの場所を指定します。

APIC とスイッチ ファームウェア イメージの両方を提供できます。

4. SCP を選択した場合は、認証情報を入力します。

ログインする [ユーザ名 (Username)]（admin など）を入力する必要があります。

[認証タイプ (Authentication Type)] を選択します。

- パスワード認証の場合は、前に指定したユーザ名のパスワードを入力します。

- SSH キー認証の場合は、SSH キーと SSH キー パスフレーズを入力する必要があります。

5. [次へ（Next）] をクリックして続行します。

ステップ 5

確認画面で情報を確認し、[送信（Submit）]をクリックして続行します。

表示される [ダウンロード中 (Downloading)] 画面で、イメージのダウンロードのステータスを確認できます。

ステータスをクリックして、進行状況の詳細を表示することもできます。

すべてのダウンロードが完了すると、[完了 (Completed)] 画面に移行します。[ダウンロード (Downloading)] 画面で待機する必要はありません。前の手順で指定したダウンロード名をクリックすると、[ダウンロード (Downloads)] タブからいつでも戻ることができます。

コントローラのアップグレード

ここでは、サイトの APIC クラスタのソフトウェア アップグレードを設定する方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

APIC クラスタのアップグレードをセットアップします。

1. 左側のナビゲーション ペインで[操作 (Operations)] > [サイト ファームウェア (Sites Firmware)]を選択します。

2. メインウィンドウで [コントローラ (Controllers)] タブを選択します。

3. [更新のセットアップ (Setup Update)] をクリックします。

以前に 1 つ以上の更新を設定している場合は、代わりにメイン ペインの右上にある [更新のセットアップ (Setup Update)] ボタンをクリックします。

[サイト ファームウェアの更新のセットアップ（Setup Site Firmware Update ）] 画面が開きます。

ステップ 3

アップグレードの詳細を入力します。

1. [名前 (Name)] を入力します。

これは、いつでもアップグレードの進行状況を追跡するために使用できる、コントローラのアップグレード ポリシー名です。

2. [サイトの選択 (Select Sites)] をクリックします。

[サイトの選択 (Select Sites)] ウィンドウが表示されます。

3. [サイトの選択 (Select Sites)] ウィンドウで、1 つ以上のサイトをオンにし、[追加して閉じる (Add and Close)] をクリックします。

4. [次へ（Next）] をクリックして続行します。

ステップ 4

[バージョンの選択 (Version Selection)] 画面で、アップロードしたファームウェア バージョンを選択し、[次へ (Next)] をクリックします。

ここで使用可能にするためには、ファームウェアをサイトにダウンロードする必要があります。前のセクションで設定したダウンロードが正常に完了したものの、ここでイメージを使用できない場合は、[ファームウェアの更新のセットアップ (Setup Site Firmware Update)] 画面を閉じ、[操作 (Operations)] > [サイトのファームウェア (Sites Firmware)] > [コントローラ (Controllers)]タブに戻り、[更新 (Refresh)] ボタンをクリックして、使用可能な最新情報をリロードします。それからサイトのアップグレード手順をもう一度開始します。

ステップ 5

[確認 (Validation)] 画面で情報を確認し、[次へ (Next)] をクリックします。

障害がないことを確認し、アップグレードに影響する可能性がある追加情報を確認します。

ステップ 6

[確認 (Confirmation)] 画面で情報を確認し、[送信 (Submit)] をクリックしてアップグレードを開始します。

ステップ 7

[インストールの準備完了 (Ready to Install)]画面で、[インストール (Install)] をクリックします。

アップグレード プロセス中に NDO からサイトへの接続が失われると、GUI には、接続が失われる前の、アップグレードの最新の既知ステータスが表示されます。接続が再確立されると、アップグレードのステータスが更新されます。接続が失われた後、メインペインの右上にある [更新 (Refresh)] ボタンをクリックすると、手動で更新できます。

ノードのアップグレード

ここでは、サイトのスイッチ ノードのソフトウェア アップグレードを設定する方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

スイッチ ノードのアップグレードをセットアップします。

1. 左側のナビゲーション ペインで[操作 (Operations)] > [サイト ファームウェア (Sites Firmware)]を選択します。

2. メイン ウィンドウで [ノード (Node)] タブを選択します。

3. [更新のセットアップ (Setup Update)] をクリックします。

以前に 1 つ以上の更新を設定している場合は、代わりにメイン ペインの右上にある [更新のセットアップ (Setup Update)] ボタンをクリックします。

[ノード ファームウェアの更新のセットアップ（Setup Node Firmware Update ）] 画面が開きます。

ステップ 3

アップグレードの詳細を入力します。

1. [名前 (Name)] を入力します。

これは、いつでもアップグレードの進行状況を追跡するために使用できるアップグレードポリシー名です。

2. [ノードの選択 (Select Nodes)] をクリックします。

[ノードの選択 (Select Nodes)] ウィンドウが表示されます。

3. サイトを選択し、そのサイトのスイッチノードを選択して、[追加して閉じる (Add and Close)] をクリックします。

一度に 1 つのサイトからスイッチノードを追加できます。他のサイトからスイッチを追加する場合は、この手順を繰り返します。

4. 他のサイトのノードについて、前のサブステップを繰り返します。

5. [次へ（Next）] をクリックして続行します。

ステップ 4

[バージョンの選択 (Version Selection)] 画面で、アップロードしたファームウェア バージョンを選択し、[次へ (Next)] をクリックします。

ここで使用可能にするためには、ファームウェアをサイトにダウンロードする必要があります。前のセクションで設定したダウンロードが正常に完了したものの、ここでイメージを使用できない場合は、[ファームウェアの更新のセットアップ (Setup Site Firmware Update)] 画面を閉じ、[操作 (Operations)] > [サイトのファームウェア (Sites Firmware)] > [ノード (Nodes)]タブに戻り、[更新 (Refresh)] ボタンをクリックして、使用可能な最新情報をリロードします。それからサイトのアップグレード手順をもう一度開始します。

ステップ 5

[検証 (Validation)] 画面で、障害が発生していないことを確認し、[次へ (Next)] をクリックします。

障害がないことを確認し、アップグレードに影響する可能性がある追加情報を確認します。

（注）

リリース 5.0(1) より前のリリースを実行しているサイトはノード検証をサポートしていないため、NDO からのアップグレードを開始する前に、サイトの APIC でスイッチ ノードの障害をチェックすることを推奨します。

ステップ 6

[確認 (Confirmation)] 画面で情報を確認し、[送信 (Submit)] をクリックして続行します。

これにより、選択したすべてのノードにイメージが事前にダウンロードされます。ダウンロードが完了すると、画面が [ インストール準備完了 (Ready to Install)] に遷移し、次の手順に進むことができます。

ステップ 7

（オプション）[詳細設定 (Advanced Settings)]を変更します。

（注）

詳細オプションを変更する前に、 Upgrade and Downgrading the Cisco APIC and Switch Software（Cisco APIC Installation、Upgrade、and Downgrade Guide）で説明されているCisco APICアップグレードプロセスのガイドライン、推奨事項、および制限事項を確認してください。

[インストールの準備完了 (Ready to Install)]画面で、[詳細設定 (Advanced Settings)]メニューを開いて追加のオプションを表示できます。

- [互換性チェックを無視 (Ignore Compatibility Check)]：デフォルトでは、このオプションは[いいえ (No)]に設定され、互換性チェックが有効になっています。システムの現在実行中のバージョンから指定された新しいバージョンへのアップグレードパスがサポートされているかどうかが確認されます。

[互換性チェックを無視 (Ignore Compatibility Check)] フィールドで [はい (Yes)] にして互換性チェック機能を無効にした場合、システムでサポートされていないアップグレードが実行されるリスクがあり、システムが利用できない状態になる可能性があります。

- [グレースフル チェック (Graceful Check)]：デフォルトでは、このオプションは [いいえ (No)] に設定されています。アップグレードプロセスでのアップグレード実行前には、どのスイッチもグレースフル挿入/取り外し（GIR）モードになりません。

このオプションを有効にすると、アップグレードの実行中にノードをグレースフルに（GIRを使用して）ダウンさせることができ、アップグレードによるトラフィック損失が減少します。

- [実行モード (Run Mode)]：デフォルトでは、このオプションは [失敗時に続行 (Continue on Failure)] に設定されており、ノードのアップグレードが失敗すると、次のノードに進みます。または、このオプションを [失敗時に一時停止 (Pause on Failure)]に設定すると、いずれかのノードのアップグレードが失敗した場合にアップグレード プロセスを停止できます。

ステップ 8

[Failed] とマークされたノードをアップグレードから削除します。

アップグレードポリシーに、ファームウェアのダウンロードに失敗した 1 つ以上のノードが含まれている場合、アップグレードを続行できません。[失敗 (Failed)] ステータスにカーソルを合わせると、詳細情報と失敗の理由が表示されます。

アップグレードからノードを削除するには、[アップデートの詳細を編集 (Edit Update Details)] のリンク（[インストールの準備完了 (Ready to Install)] 画面）をクリックします。

ステップ 9

[インストール (Install)] をクリックしてアップグレードを開始します。

アップグレード プロセス中に NDO からサイトへの接続が失われると、GUI には、接続が失われる前の、アップグレードの最新の既知ステータスが表示されます。接続が再確立されると、アップグレードのステータスが更新されます。接続が失われた後、メインペインの右上にある [更新 (Refresh)] ボタンをクリックすると、手動で更新できます。

Chapter8. [Tech Support]

- テクニカル サポートおよびシステム ログ

- システム ログのダウンロード

- 外部アナライザへのストリーミング システム ログ

テクニカル サポートおよびシステム ログ

Nexus Dashboard Orchestrator のシステム ロギングは、最初に Orchestrator クラスタをデプロイしたときに自動的に有効になり、環境内で発生したイベントと障害をキャプチャします。

追加のツールを使用して重要なイベントを遅延なく迅速に解析、表示、応答する必要がある場合は、いつでも、ログをダウンロードするか、Splunk などの外部ログ アナライザにストリーミングするかを選択できます。

リリース 3.3(1) 以降、テクニカル サポートログは 2 つの部分に分割されています。

- 以前のリリースと同じ情報を含む、オリジナルのデータベース バックアップ ファイル

- 可読性を高めた、JSON ベースのデータベース バックアップ

各バックアップ アーカイブには、次の内容が含まれています。

- xxxx：バックアップ時に使用可能なコンテナ ログ用の xxxx 形式の 1 つ以上のファイル。

- msc-backup-<date>_temp：以前のリリースと同じ情報を含む、オリジナルのデータベース バックアップ。

- msc-db-json-<date>_temp：JSON 形式のバックアップコンテンツ。

例：

msc_anpEpgRels.json
msc_anpExtEpgRels.json
msc_asyncExecutionStatus.json
msc_audit.json
msc_backup-versions.json
msc_backupRecords.json
msc_ca-cert.json
msc_cloudSecStatus.json
msc_consistency.json
...

システム ログのダウンロード

このセクションでは、Nexus Dashboard Orchestrator により管理されているすべてのスキーマ、サイト、テナント、およびユーザのトラブルシューティング レポートとインフラストラクチャ ログ ファイルを生成します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[システムログ (System Logs)] 画面を開きます。

1. メインメニューで、[操作 (Operations)] > [テクニカル サポート (Tech Support)]を選択します。

2. [システム ログ (System Logs)] フレームの右上隅にある編集ボタンをクリックします。

ステップ 3

[ログのダウンロード (Download Log)] ボタンをクリックしてログをダウンロードします。

アーカイブがシステムにダウンロードされます。この章の最初のセクションで説明されているすべての情報を含んでいます。

外部アナライザへのストリーミング システム ログ

Nexus Dashboard Orchestrator を使用すると、Orchestrator ログを外部のログアナライザー ツールにリアルタイムで送信できます。生成されたイベントをストリーミングすることにより、追加のツールを使用して、遅延なしで重要なイベントをすばやく解析、表示、および対応できます。

ここでは、Nexus Dashboard Orchestrator が外部アナライザツール (Splunk や syslog など) にログをストリーミングできるようにする方法について説明します。

始める前に

- このリリースでは、外部ログ アナライザーとして Splunk と syslog のみがサポートされています。

- このリリースでは、Application Services Engine 展開で Nexus Dashboard Orchestrator の syslog のみがサポートされます。

- このリリースは、最大 5 台の外部サーバをサポートします。

- Splunk を使用する場合は、ログ アナライザー サービス プロバイダをセットアップして構成します。

外部ログ アナライザーの設定方法の詳細については、マニュアルを参照してください。

- Splunk を使用する場合は、サービス プロバイダの認証トークンを取得します。

分裂サービスの認証トークンの取得については、「分裂」のマニュアルで詳しく説明していますが、要するに、[設定 (Settings)] > [ データ入力 (Data Inputs)] > [HTTP イベントコレクタ (Data input HTTP Event Collector])を選択し、[新規トークン (New token)] をクリックして、認証トークンを取得できます。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[システムログ (System Logs)] 画面を開きます。

1. メインメニューで、[操作 (Operations)] > [テクニカル サポート (Tech Support)]を選択します。

2. [システム ログ (System Logs)] フレームの右上隅にある編集ボタンをクリックします。

ステップ 3

[システムログ (System Logs)] ウィンドウで、外部ストリーミングを有効にし、サーバを追加します。

1. [外部ストリーミング (External Streaming)] ノブを有効にします。

2. [すべてのログ (All Logs)] をストリーミングするか、[監査ログ (Audit Logs)] のみをストリーミングするかを選択します。

3. [サーバーの追加 (Add Server)] をクリックして、外部ログ アナライザ サーバーを追加します。

ステップ 4

Splunk サーバーを追加します。

Splunk サービスを使用する予定がない場合は、この手順をスキップします。

1. サーバーのタイプとして [Splunk] を選択します。

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

3. Splunk サービスから取得したサーバ名または IP アドレス、ポート、および認証トークンを入力します。

Splunk サービスの認証トークンの取得については、Splunk のマニュアルで詳しく説明していますが、要するに、[設定 (Settings)] > [ データ入力 (Data Inputs)] > [HTTP イベントコレクタ (HTTP Event Collector)] を選択し、[新規トークン (New token)] をクリックして、認証トークンを取得できます。

4. チェックマーク アイコンをクリックして、サーバーの追加を終了します。

ステップ 5

syslog サーバーを追加します。

syslog を使用しない場合は、この手順をスキップします。

1. サーバーのタイプとして [syslog] を選択します。

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

3. サーバー名または IP アドレス、ポート番号、およびストリーミングするログ メッセージのシビラティ（重大度）を指定します。

4. チェックマーク アイコンをクリックして、サーバーの追加を終了します。

ステップ 6

複数のサーバーを追加する場合は、この手順を繰り返します。

このリリースは、最大 5 台の外部サーバ0をサポートします。

ステップ 7

[保存（Save）] をクリックして、変更内容を保存します。

PartIII. インフラストラクチャ管理

- システム設定

- NDO サービスのアップグレードまたはダウングレード

- Cisco ACI サイトの設定

- サイトの追加と削除

- インフラ一般設定

- Cisco APIC サイトのインフラの設定

- Cisco Cloud APIC サイトのインフラの設定

- ACI サイト向けのインフラ設定の展開

- CloudSec 暗号化

Chapter9. システム設定

- システム設定

- システム エイリアスとバナー

- ログイン試行回数とロックアウト時間

システム設定

次のセクションで説明するように、Multi-Site Orchestrator に対して設定できる、 管理 > システム設定で使用可能なグローバルシステム設定が多数あります。

システム エイリアスとバナー

このセクションでは、Nexus Dashboard Orchestrator のエイリアスを設定する方法と、次の図に示すように、GUI 全体で画面の上部に表示されるカスタムのバナーを有効にする方法について説明します。

システム バナーの表示

手順

ステップ 1

Orchestrator にログインします。

ステップ 2

左側のナビゲーション ペインから[管理 (Admin)] > [システム設定 (System Configuration)] を選択します。.

ステップ 3

[編集 (Edit)] のアイコンをクリックします。これは [システム エイリアスとバナー System Alias & Banners)] 領域の右にあります。

[システム エイリアスとバナー System & Banners)] の設定ウィンドウが表示されます。

ステップ 4

[エイリアス (Alias)] フィールドで、システムのエイリアスを指定します。

ステップ 5

GUI バナーを有効にするかどうかを選択します。

ステップ 6

バナーを有効にする場合には、バナーに表示されるメッセージを指定する必要があります。

ステップ 7

バナーを有効にする場合には、バナーのシビラティ（重大度）を意味する色を選択する必要があります。

ステップ 8

[保存（Save）] をクリックして、変更内容を保存します。

ログイン試行回数とロックアウト時間

Orchestrator がログイン試行を連続して失敗したことが検出されると、そのユーザは、不正アクセスを防ぐために、システムからロックアウトされます。ログイン試行が失敗した場合の処理方法は設定できます。たとえば、何回失敗するとロックアウトされるか、およびロックアウトの長さなどがあります。

（注）

この機能は、リリース 2.2(1) 以降を最初にインストールしたとき、アップグレードしたときにデフォルトで有効になります。

手順

ステップ 1

Orchestrator にログインします。

ステップ 2

左側のナビゲーション ペインから[管理 (Admin)] > [システム設定 (System Configuration)] を選択します。.

ステップ 3

[試行の失敗&ロックアウト時間 (Fail Attempts & Lockout Time)]エリアの右側にある [編集 (Edit)] アイコンをクリックします。

これにより、[試行の失敗&ロックアウト時間 (Fail Attempts & Lockout Time)] 設定ウィンドウが表示されます。

ステップ 4

[試行の失敗の設定 (Fail Attempts Settings)] ドロップダウンから、ユーザが何回試行に失敗するとロックアウトされるかを選択します。

ステップ 5

[ロックアウト時間 (分) (Lockout Time (Minutes)] ドロップダウンから、ロックアウトの長さを選択します。

これは、トリガーされた後の、基本的なロックアウト期間を指定します。このタイマーは、さらにログイン試行が連続して失敗するたびに、3 ずつ延長されます。

ステップ 6

[保存（Save）] をクリックして、変更内容を保存します。

Chapter10. NDO サービスのアップグレードまたはダウングレード

- 概要

- 前提条件とガイドライン

- Cisco App Store を使用した NDO サービスのアップグレード

- NDO サービスの手動アップグレード

概要

ここでは、Cisco Nexus Dashboard　に導入されている　Cisco Nexus Dashboard Orchestrator　リリース 3.2(1) 以降をアップグレードまたはダウングレードする方法について説明します。

VMware ESX VM または Cisco Application Services Engine に導入されている以前のリリースを実行している場合は、「Nexus ダッシュボードへの既存のクラスタの移行」の章の説明に従って、新しいクラスタを導入し、既存のクラスタから設定を転送する必要があります。 Nexus Dashboard Orchestrator 導入ガイド。

前提条件とガイドライン

Cisco Nexus Dashboard Orchestrator クラスタをアップグレードまたはダウングレードする前に、次の手順を実行します。

- リリース 3.2(1) より前のリリースからのステートフル アップグレードはサポートされていません。

以前のリリースからアップグレードする場合は、この章の残りの部分をスキップし、 『Nexus Dashboard Orchestrator Deployment Guide』の「Migrating Existing Cluster to Nexus Dashboard」の項に記載されている手順に従ってください。

- 現在の Nexus ダッシュボードクラスタが正常であることを確認します。

Nexus ダッシュボード クラスタの状態は、次の 2 つの方法のいずれかで確認できます。

- Nexus ダッシュボード GUI にログインし、[システム概要（System Overview）] ページでシステムステータスを確認します。

- いずれかのノードに直接 rescue-user としてログインし、次のコマンドを実行します。

# acs health
All components are healthy

- 現在の Cisco Nexus Dashboard Orchestrator が正常に動作していることを確認します。

Nexus Dashboard Orchestrator サービスのステータスは、[設定 (Settings)] > [システムステータス (System Status)] に移動して確認できます。

次に、すべてのノードとサービスのステータスが正常であることを確認します。

- NDO サービスのアップグレードは次のいずれかの方法で実行できます。

- Cisco App Store を使用した NDO サービスのアップグレードの説明に従って、Nexus ダッシュボードの App Store を使用します。

この場合、Cisco DC App Center は、管理ネットワークを介して直接、またはプロキシ設定を使用して Nexus ダッシュボードから到達可能である必要があります。Nexusダッシュボードのプロキシ設定については、『Nexus Dashboard User Guide』を参照してください。

（注）

App Storeでは、サービスの最新バージョンにのみアップグレードできます。つまり、すでにリリース 3.4(1) が使用可能になっている場合、App Store を使用してリリース 3.3(1) にアップグレードすることはできません。以下に説明する手動アップグレード プロセスに従う必要があります。

- NDO サービスの手動アップグレードの説明に従って、新しいアプリケーション イメージを手動でアップロードします。

この方法は、DC App Center への接続を確立できない場合、または使用可能な最新リリースではないアプリケーションのバージョンにアップグレードする場合に使用できます。

- Nexus Dashboard Orchestrator をリリース 3.3(1) 以降にアップグレードした後に新しい Cloud APIC サイトを追加および管理する場合は、それらのサイトが Cloud APIC リリース 5.2(1) 以降を実行していることを確認してください。

以前のリリースを実行しているクラウド APIC サイトのオンボーディングと管理は、Nexus Dashboard Orchestrator 3.3(1) ではサポートされていません。

- リリース 3.3(1) より前のリリースへのダウングレードはサポートされていません。

以前のリリースにダウングレードする場合は、以前のリリースでサポートされているプラットフォームに新しい Nexus Dashboard Orchestrator クラスタを展開してから、古い設定のバックアップを復元する必要があります。リリース 3.3(1) 以降で作成されたバックアップを古い NDO クラスタに復元することはサポートされていません。

Nexus Dashboard Orchestrator の以前のリリースにダウングレードする場合は、すべてのクラウド APIC サイトをリリース 5.2(1) より前のリリースにダウングレードする必要もあります。

Cisco App Store を使用した NDO サービスのアップグレード

ここでは、Cisco Nexus Dashboard Orchestrator リリース 3.2(1) 以降をアップグレードする方法について説明します。

始める前に

- 前提条件とガイドラインで説明している前提条件をすべて満たしていることを確認します。

- Cisco DC App Center が Nexus ダッシュボードから管理ネットワーク経由で直接、またはプロキシ設定を使用して到達可能であることを確認します。

Nexusダッシュボードのプロキシ設定については、 『Nexus Dashboard User Guide』を参照してください。

手順

ステップ 1

Nexus Dashboard にログインします。

ステップ 2

左のナビゲーションメニューから [サービス カタログ (Service Catalog)] を選択します。

ステップ 3

App Store を使用してアプリケーションをアップグレードします。

1. [サービス カタログ (Service Catalog)] 画面で [アプリ ストア (App Store)] タブを選択します。

2. [Nexus ダッシュボード オーケストレータ (Nexus Dashboard Orchestrator)]タイルで、[アップグレード (Upgrade)]をクリックします。

3. 開いた [ライセンス契約 (License Agreement)] ウィンドウで、[同意してダウンロード (Agree and Download)] をクリックします。

ステップ 4

新しいイメージが初期化されるまで待ちます。

新しいアプリケーションイメージが使用可能になるまでに最大 20 分かかることがあります。

ステップ 5

新しい画像をアクティブにします。

1. [サービス カタログ (Service Catalog)] 画面で、[インストール済みサービス (Installed Services)] タブを選択します。

2. [Nexus Dashboard Orchestrator]タイルの右上にあるメニュー（...）をクリックし、[利用可能なバージョン (Available Versions)] を選択します。

3. [Available Versions]ウィンドウで、新しいイメージの横にある [アクティベート (Activate)] をクリックします。

（注）

新しいイメージをアクティブにする前に、現在実行中のイメージを無効にしないでください。イメージ アクティベーション プロセスは、現在実行中のイメージを認識し、現在実行中のアプリケーション バージョンに必要なアップグレード ワークフローを実行します。

すべてのアプリケーション サービスが起動し、GUI が使用可能になるまでに、さらに最大 20 分かかる場合があります。このページは、プロセスが完了した時点で自動的に再ロードされます。

ステップ 6

（任意）古いアプリケーション イメージを削除します。

ダウングレードする場合に備えて、古いアプリケーション バージョンを保持しておくこともできます。または、この手順の説明に従って削除することもできます。

1. [サービス カタログ (Service Catalog)] 画面で、[インストール済みサービス (Installed Services)] タブを選択します。

2. [Nexus Dashboard Orchestrator]タイルの右上にあるメニュー（...）をクリックし、[利用可能なバージョン (Available Versions)] を選択します。

3. 使用可能なバージョンのウィンドウで、削除するイメージの横にある削除アイコンをクリックします。

ステップ 7

アプリを起動します。

アプリケーションを起動するには、Nexus ダッシュボードの [サービスカタログ (Service Catalog)] ページのアプリケーションタイルで [開く (Open)] をクリックします。

シングルサインオン（SSO）機能を使用すると、Nexus ダッシュボードで使用したものと同じクレデンシャルを使用してアプリケーションにログインできます。

NDO サービスの手動アップグレード

ここでは、Cisco Nexus Dashboard Orchestrator リリース 3.2(1) 以降をアップグレードする方法について説明します。

始める前に

- 前提条件とガイドラインで説明している前提条件をすべて満たしていることを確認します。

手順

ステップ 1

ターゲットのリリース イメージをダウンロードします。

1. DC App Center で Nexus Dashboard Orchestrator ページを参照します。

https://dcappcenter.cisco.com/nexus-dashboard-orchestrator.html

2. [バージョン (Version)] ドロップダウンから、インストールするバージョンを選択し、[ダウンロード (Download)] をクリックします。

3. [同意してダウンロード (Agree and download)] をクリックしてライセンス契約に同意し、イメージをダウンロードします。

ステップ 2

Nexus Dashboard にログインします。

ステップ 3

Nexus ダッシュボードにイメージをアップロードします。

1. 左のナビゲーションメニューから [サービス カタログ (Service Catalog)] を選択します。

2. Nexus ダッシュボードの [サービス カタログ (Service Catalog)] 画面で、[インストール済みサービス (Installed Services)] タブを選択します。

3. メインペインの右上にある [アクション (Actions)] メニューから、[アプリケーションのアップロード (Upload App)] を選択します。

4. [アプリケーションのアップロード (Upload App)] ウィンドウで、イメージの場所を選択します。

アプリケーション イメージをシステムにダウンロードした場合は、[ローカル (Local)] を選択します。

サーバでイメージをホストしている場合は、[リモート (Remote)] を選択します。

5. ファイルを選択します。

前のサブステップで [ローカル (Local)] を選択した場合は、[ファイルの選択 (Select File)] をクリックし、ダウンロードしたアプリケーションイメージを選択します。

[リモート (Remote)] を選択した場合は、イメージ ファイルのフル URL を指定します。http://<ip-address>:<port>/<full-path>/cisco-mso-<version>.aci のようになります。

6. [アップロード (Upload)] をクリックして、アプリケーションをクラスタに追加します。

アップロードの進行状況バーとともに新しいタイルが表示されます。イメージのアップロードが完了すると、Nexus ダッシュボードは新しいイメージを既存のアプリケーションとして認識し、新しいバージョンとして追加します。

ステップ 4

新しいイメージが初期化されるまで待ちます。

新しいアプリケーションイメージが使用可能になるまでに最大 20 分かかることがあります。

ステップ 5

新しい画像をアクティブにします。

1. [サービス カタログ (Service Catalog)] 画面で、[インストール済みサービス (Installed Services)] タブを選択します。

2. [Nexus Dashboard Orchestrator]タイルの右上にあるメニュー（...）をクリックし、[利用可能なバージョン (Available Versions)] を選択します。

3. [Available Versions]ウィンドウで、新しいイメージの横にある [アクティベート (Activate)] をクリックします。

（注）

新しいイメージをアクティブにする前に、現在実行中のイメージを無効にしないでください。イメージ アクティベーション プロセスは、現在実行中のイメージを認識し、現在実行中のアプリケーション バージョンに必要なアップグレード ワークフローを実行します。

すべてのアプリケーション サービスが起動し、GUI が使用可能になるまでに、さらに最大 20 分かかる場合があります。このページは、プロセスが完了した時点で自動的に再ロードされます。

ステップ 6

（任意）古いアプリケーション イメージを削除します。

ダウングレードする場合に備えて、古いアプリケーション バージョンを保持しておくこともできます。または、この手順の説明に従って削除することもできます。

1. [サービス カタログ (Service Catalog)] 画面で、[インストール済みサービス (Installed Services)] タブを選択します。

2. [Nexus Dashboard Orchestrator]タイルの右上にあるメニュー（...）をクリックし、[利用可能なバージョン (Available Versions)] を選択します。

3. 使用可能なバージョンのウィンドウで、削除するイメージの横にある削除アイコンをクリックします。

ステップ 7

アプリを起動します。

アプリケーションを起動するには、Nexus ダッシュボードの [サービスカタログ (Service Catalog)] ページのアプリケーションタイルで [開く (Open)] をクリックします。

シングルサインオン（SSO）機能を使用すると、Nexus ダッシュボードで使用したものと同じクレデンシャルを使用してアプリケーションにログインできます。

Chapter11. Cisco ACI サイトの設定

- ポッド プロファイルとポリシー グループ

- すべての APIC サイトのファブリック アクセス ポリシーの設定

- リモート リーフ スイッチを含むサイトの設定

- Cisco Mini ACI ファブリック

ポッド プロファイルとポリシー グループ

各サイトの APIC には、ポッド ポリシー グループを持つポッド プロファイルが 1 つ必要です。サイトにポッド ポリシー グループがない場合は、作成する必要があります。通常、これらの設定はすでに存在していて、ファブリックを最初に展開したときに設定したとおりになっているはずです。

手順

ステップ 1

サイトの APIC GUI にログインします。

ステップ 2

ポッド プロファイルにポッド ポリシー グループが含まれているかどうかを確認します。

[ファブリック (Fabric)] > [ファブリック ポリシー (Fabric Policies)] > [ポッド (Pods)] > [プロファイル (Profiles)] > [ポッドのプロファイルのデフォルト (Pod Profile default)]に移動します。

ステップ 3

必要であれば、ポッド ポリシー グループを作成します。

1. [ファブリック (Fabric)] > [ファブリック ポリシー (Fabric Policies)] > [ポッド (Pods)] > [ポリシー グループ (Policy Groups)]に移動します。

2. [ポリシー グループ (Policy Groups)] を右クリックし、[ポッド ポリシー グループの作成 (Create Pod Policy Groups)] を選択します。

3. 適切な情報を入力して、[Submit] をクリックします。

ステップ 4

新しいポッド ポリシー グループをデフォルトのポッド プロファイルに割り当てます。

1. [ファブリック (Fabric)] > [ファブリック ポリシー (Fabric Policies)] > [ポッド (Pods)] > [プロファイル (Profiles)] > [ポッド プロファイルのデフォルト (Pod Profile default)] に移動します。

2. デフォルトのプロファイルを選択します。

3. 新しいポッド ポリシー グループを選択し、[更新 (Update)] をクリックします。

すべての APIC サイトのファブリック アクセス ポリシーの設定

APIC ファブリックを Nexus Dashboard Orchestrator に追加し、Nexus Dashboard Orchestrator により管理できるようにするには、サイトごとに設定することが必要な、ファブリック固有の多数のアクセス ポリシーがあります。

- ファブリック アクセス グローバル ポリシーの設定

- ファブリック アクセス インターフェイス ポリシーの設定

ファブリック アクセス グローバル ポリシーの設定

このセクションでは、Nexus Dashboard Orchestrator に追加し、管理する前に、APIC サイトごとに作成する必要があるグローバル ファブリック アクセス ポリシーの設定について説明します。

手順

ステップ 1

サイトの APIC GUI に直接ログインします。

ステップ 2

メイン ナビゲーション メニューから、[ファブリック (Fabric)] > [アクセス ポリシー (Access Policies)] を選択します。

サイトを Nexus Dashboard Orchestrator に追加するには、いくつかのファブリックポリシーを設定する必要があります。APIC の観点からは、ベアメタル ホストを接続していた場合と同様に、ドメイン、AEP、ポリシー グループ、およびインターフェイス セレクタを設定することができます。同じマルチサイト ドメインに属するすべてのサイトに対して、スパイン スイッチ インターフェイスをサイト間ネットワークに接続するための同じオプションを設定する必要があります。

ステップ 3

VLAN プールを指定します。

最初に設定するのは、VLAN プールです。レイヤ 3 サブインターフェイスは VLAN 4 を使用してトラフィックにタグを付け、スパインスイッチをサイト間ネットワークに接続します。

1. 左側のナビゲーション ツリーで、[プール (Pools)] > [VLAN] を参照します。

2. [VLAN] カテゴリを右クリックし、[VLAN プールの作成 (Create VLAN Pool)] を選択します。

[VLAN プールの作成 (CREATE VLAN Pool)] ウィンドウで、次の項目を指定します。

- [名前 (name )] フィールドで、VLAN プールの名前 (たとえば、 msite) を指定します。

- [Allocation Mode (割り当てモード)]の場合は、[スタティック割り当て(Static Allocation)]を指定します。

- [Encap ブロック(Encap Blocks)] の場合は、単一の VLAN 4 だけを指定します。両方の [Range (範囲)] フィールドに同じ番号を入力することによって、単一の VLAN を指定できます。

ステップ 4

接続可能アクセス エンティティ プロファイル (AEP) を作成します。

1. 左側のナビゲーションツリーで、[グローバル ポリシー (Global Policies)] > [接続可能なアクセス エントリ プロファイル (Attachable Access Entity Profiles)] を参照します。

2. [接続可能なアクセス エンティティ プロファイル (Attachable Access Entry Profiles)] を右クリックして、[接続可能なアクセス エンティティ プロファイルの作成 (Create Attachable Access Entity Profiles)] を選択します。

[接続可能アクセス エンティティ プロファイルの作成(Create Attachable Access Entity Profiles)]] ウィンドウで、AEP の名前 (例: msite-aep) を指定します。

3. [次へ(Next)]] をクリックして [送信(Submit)] します。

インターフェイスなどの追加の変更は必要ありません。

ステップ 5

ドメインを設定します。

設定するドメインは、このサイトを追加するときに、Nexus Dashboard Orchestratorから選択するものになります。

1. ナビゲーション ツリーで、[物理的ドメインと外部ドメイン (Physical and External Domains)] > [外部でルーテッド ドメイン (External Routed Domains)] を参照します。

2. [外部ルーテッド ドメイン(External Routed Domains)] カテゴリを右クリックし、[レイヤ 3 ドメインの作成 (Create Layer 3 Domain)] を選択します。

[レイヤ 3 ドメインの作成 (Create Layer 3 Domain)] ウィンドウで、次の項目を指定します。

- [名前 (name)] フィールドで、ドメインの名前を指定します。たとえば、 msite-l3です。

- 関連付けられている接続可能エンティティ プロファイルの場合は、ステップ 4で作成した AEP を選択します。

- VLAN プールの場合は、ステップ 3で作成した VLAN プールを選択します。

3. [送信 (Submit)] をクリックします。

セキュリティ ドメインなどの追加の変更は必要ありません。

次のタスク

グローバル アクセス ポリシーを設定した後も、ファブリック アクセス インターフェイス ポリシーの設定 の説明に従って、インターフェイス ポリシーを追加する必要があります。

ファブリック アクセス インターフェイス ポリシーの設定

このセクションでは、各 APIC サイトの Nexus Dashboard Orchestrator で行わなければならないファブリック アクセス インターフェイスの設定について説明します。

始める前に

サイトの APIC では、ファブリック アクセス グローバル ポリシーの設定 の説明に従って、VLAN プール、AEP、および ドメインなどのグローバル ファブリック アクセス ポリシーを設定しておく必要があります。

手順

ステップ 1

サイトの APIC GUI に直接ログインします。

ステップ 2

メイン ナビゲーション メニューから、[ファブリック (Fabric)] > [アクセス ポリシー (Access Policies)] を選択します。

前のセクションで設定した VLAN、AEP、およびドメインに加えて、サイト間ネットワーク (ISN) に接続するファブリックのスパイン スイッチ インターフェイスに対してインターフェイス ポリシーを作成します。

ステップ 3

スパイン ポリシー グループを設定します。

1. 左ナビゲーション ツリーで、[インターフェイス ポリシー (Interface Policie)] > [ポリシー グループ (Policy Groups)] > [スパイン ポリシー グループ (Spine Policy Groups)] を参照します。

これは、ベアメタル サーバを追加する方法と類似していますが、リーフ ポリシー グループの代わりにスパイン ポリシー グループを作成する点が異なります。

2. [スパイン ポリシー グループ (Spine Policy Groups)] カテゴリーを右クリックして、[スパイン アクセス ポート ポリシー グループの作成 (Create Spine Access Port Policy Group)] を選択します。

[スパイン アクセス ポリシー グループの作成 (Create Spine Access Port Policy Group)]ウィンドウで、以下のとおり指定します。

- [名前 (Name)] フィールドの場合、ポリシー グループの名前を指定します。たとえば Spine1-PolGrp です。

- [リンク レベル ポリシー (Link Level Policy)] フィールドには、スパイン スイッチと ISN の間のリンク ポリシーを指定します。

- [CDP ポリシー (CDP Policy)] の場合、CDP を有効にするかどうかを選択します。

- [添付したエンティティ プロファイル (Attached Entity Profiel)]の場合、前のセクションで設定した AEP を選択します。たとえば msite-aep です。

3. [送信 (Submit)] をクリックします。

セキュリティ ドメインなどの追加の変更は必要ありません。

ステップ 4

スパイン プロファイルを設定します。

1. 左ナビゲーション ツリーで、[インターフェイス ポリシー (Interface Policies)] > [ポリシー グループ (Profiles)] > [スパイン ポリシー グループ (Spine Profiles)] を参照します。

2. [プロファイル (Profiles)] カテゴリを右クリックし、[スパイン インターフェイス プロファイルの作成 (Create Spine Interface Profile] を選択します。

[スパイン インターフェイス プロファイルの作成 (Create Spine Interface Profile)] ウィンドウで、次のとおり指定します。

- [名前 (name)] フィールドに、プロファイルの名前 (Spine1など) を指定します。

- [インターフェイス セレクタ (Interface Selectors)]では、+ 記号をクリックして、ISN に接続されるスパイン スイッチ上のポートを追加します。次に、[スパイン アクセス ポート セレクターの作成 (Create Spine Access Port Selector)] ウィンドウで、次のように指定します。

- [名前 (name)] フィールドに、ポート セレクタの名前を指定します (例: Spine1)。

- [インターフェイス ID (Interface IDs)] に、ISN に接続するスイッチ ポートを指定します (例5/32)。

- [インターフェイス ポリシー グループ (Interface Policy Group)] に、前の手順で作成したポリシー グループを選択します (例: Spine1-PolGrp)。

それから、[OK] をクリックして、ポート セレクタを保存します。

3. [送信 (Submit)] をクリックしてスパイン インターフェイス プロファイルを保存します。

ステップ 5

スパイン スイッチ セレクタ― ポリシーを設定します。

1. 左ナビゲーション ツリーで、[スイッチ ポリシー (Switch Policies)] > [プロファイル (Profiles)] > [スパイン プロファイル (Spine Profiles)] を参照します。

2. [スパイン プロファイル (Spine Profiles)[ カテゴリを右クリックし、[スパイン プロファイルの作成 (Create Spine Profile)] を選択します。

[スパイン インターフェイス プロファイルの作成 (Create Spine Interface Profile)] ウィンドウで、次のように指定します。

- [名前 (name)] フィールドに、プロファイルの名前を指定します (例: Spine1)。

- [スパインセレクタ (Spine Selectora)]で、[+] をクリックしてスパインを追加し、次の情報を入力します。

- [名前 (name)] フィールドで、セレクタの名前を指定します (例: Spine1) 。

- [ブロック (Blocks)] フィールドで、スパイン ノードを指定します (例: 201)。

3. [更新 (Update)] をクリックして、セレクタを保存します。

4. [次へ (Next)] をクリックして、次の画面に進みます。

5. 前の手順で作成したインターフェイス プロファイルを選択します。

たとえば、Spine1-ISNなどです。

6. [完了 (Finish)] をクリックしてスパイン プロファイルを保存します。

リモート リーフ スイッチを含むサイトの設定

リリース 2.1(2) 以降、Multi-Site アーキテクチャはリモート リーフ スイッチを持つ APIC サイトをサポートします。次のセクションでは、Nexus Dashboard Orchestrator がこれらのサイトを管理できるようにするために必要な注意事項、制限事項、および設定手順を説明します。

- リモート リーフの注意事項と制限事項

- リモート リーフ スイッチのルーティング可能なサブネットの設定

- リモート リーフ スイッチの直接通信の有効化

リモート リーフの注意事項と制限事項

Nexus Dashboard Orchestrator により管理されるリモート リーフをもつ APIC サイトを追加する場合、次の制約が適用されます。

- Cisco APICはリリース 4.2(4) 以降にアップグレードする必要があります。

- このリリースでは、物理リモート リーフ スイッチのみがサポートされます

- -EX および -FX 以降のスイッチのみが、マルチサイトで使用するリモートリーフスイッチとしてサポートされています。

- リモートリーフは、IPN スイッチを使用しないバックツーバック接続サイトではサポートされていません

- 1 つのサイトのリモート リーフ スイッチで別のサイトの L3Out を使用することはできません

- あるサイトと別のサイトのリモート リーフ間のブリッジ ドメインの拡張はサポートされていません。

また、Nexus Dashboard Orchestrator でサイトを追加して管理するには、その前に次のタスクを実行する必要があります。

- 次の項で説明するように、リモートリーフの直接通信をイネーブルAPICにし、サイト内でルーティング可能なサブネットを直接設定する必要があります。

- リモート リーフ スイッチに接続しているレイヤ 3 ルータのインターフェイスに適用されている DHCP リレー設定で、Cisco APIC ノードのルーティング可能な IP アドレスを追加する必要があります。

各 APIC ノードのルーティング可能な IP アドレスは、[ルーティング可能 IP (Routable IP)] フィールド (APIC GUI の [システム (System)] > [コントローラ (Controllers)] > <コントローラ名>画面) に表示されます。

リモート リーフ スイッチのルーティング可能なサブネットの設定

1 つ以上のリモート リーフ スイッチを含むサイトを Nexus Dashboard Orchestrator に追加するには、その前に、リモート リーフ ノードが関連付けられているポッドのルーティング可能なサブネットを設定する必要があります。

手順

ステップ 1

サイトの APIC GUI に直接ログインします。

ステップ 2

メニュー バーから、[ファブリック (Fabric)] > [インベントリ (Inventory)] を選択します。

ステップ 3

[ナビゲーション (Navigation)] ウィンドウで、[ポッド ファブリック セットアップ ポリシー (Pod Fabric Setup Policy)] をクリックします。

ステップ 4

メイン ペインで、サブネットを設定するポッドをダブルクリックします。

ステップ 5

ルーティング可能なサブネットエリアで、 + 記号をクリックしてサブネットを追加します。

ステップ 6

IPアドレスと予約アドレスの数を入力し、状態をアクティブまたは非アクティブに設定してから、[更新 (Update)] をクリックしてサブネットを保存します。

ルーティング可能なサブネットを設定する場合は、 /22~/29の範囲のネットマスクを指定する必要があります。

ステップ 7

[送信（Submit）] をクリックして設定を保存します。

リモート リーフ スイッチの直接通信の有効化

1 つ以上のリモート リーフ スイッチを含むサイトを Nexus Dashboard Orchestrator に追加するには、その前に、そのサイトに対して直接リモート リーフ通信を設定する必要があります。リモートリーフ直接通信機能に関する追加情報については、Cisco APIC レイヤ 3 ネットワーク コンフィギュレーション ガイドを参照してください。ここでは、Multi-Site との統合に固有の手順とガイドラインの概要を説明します。

（注）

リモート リーフ スイッチの直接通信を有効にすると、スイッチは新しいモードでのみ機能します。

手順

ステップ 1

サイトの APIC に直接ログインします。

ステップ 2

リモート リーフ スイッチの直接トラフィック転送を有効にします。

1. メニュー バーから、[システム (System)] > [システムの設定 (System Settings)] に移動します。

2. 左側のサイドバーのメニューから [ファブリック全体の設定 (Fabric Wide Setting)] を選択します。

3. [リモート リーフ 直接トラフィック転送 (Enable Remote Leaf Direct Traffice Forwarding)] チェックボックスをオンにします。

（注）

有効にした後は、このオプションを無効にすることはできません。

4. [送信 (Submit)] をクリックして変更を保存します。

Cisco Mini ACI ファブリック

Cisco Multi-Site は、追加の設定を必要とせずに、一般的なオンプレミス サイトとして Cisco Mini ACI ファブリックをサポートします。ここでは、Mini ACI ファブリックの概要について説明します。このタイプのファブリックの導入と設定に関する詳細情報は、『Cisco Mini ACI ファブリックおよび仮想 APIC』に記述されています。

Cisco ACI リリース 4.0(1) では、小規模導入向けに Mini ACI ファブリックが導入されました。Mini ACI ファブリックは、仮想マシンで実行される1つの物理 APIC と 2 つの仮想 APIC（vAPIC）で構成される Cisco APIC クラスタで動作します。これにより、APIC クラスタの物理的なフットプリントとコストが削減され、ACI ファブリックを、物理的な設置面積や初期コストのために、フルスケールの ACI インストールが実用的でないような、ラック スペースや初期予算が限られたシナリオ（コロケーション施設やシングルルームデータセンターなど）に導入できるようになります。

次の図に、物理 APIC と 2 つの仮想 APIC（vAPIC）を備えたミニCisco ACIファブリックの例を示します。

Cisco Mini ACI ファブリック

Chapter12. サイトの追加と削除

- Cisco NDO と APIC の相互運用性のサポート

- Cisco ACI サイトの追加

- サイトの削除

- ファブリック コントローラへの相互起動

Cisco NDO と APIC の相互運用性のサポート

Cisco Nexus Dashboard Orchestrator（NDO）では、すべてのサイトで特定のバージョンの APIC を実行する必要はありません。各サイトの APIC クラスタと NDO 自体は、Nexus Dashboard Orchestrator サービスがインストールされている Nexus ダッシュボードにファブリックをオンボードできる限り、相互に独立してアップグレードし、混合動作モードで実行することができます。そのため、常に Nexus Dashboard Orchestrator の最新リリースにアップグレードしておくことをお勧めします。

ただし、1 つまたは複数のサイトで APIC クラスタをアップグレードする前に NDO をアップグレードすると、新しい NDO の機能の一部が、以前の APIC リリースでまだサポートされていないという状況が生じ得ることに注意してください。この場合、各テンプレートでチェックが実行され、すべての設定済みオプションがターゲットサイトでサポートされていることを確認します。

このチェックは、テンプレートを保存するか、テンプレートを展開するときに実行されます。テンプレートがすでにサイトに割り当てられている場合、サポートされていない設定オプションは保存されません。テンプレートがまだ割り当てられていない場合は、サイトに割り当てることができますが、サイトがサポートしていない設定が含まれている場合は、スキーマを保存したり展開したりすることはできません。

サポートされていない設定が検出されると、エラーメッセージが表示されます。例: この APIC サイトバージョン<site version>は、NDO ではサポートされていません。この<feature>に必要な最小バージョンは<required-version>以降です。

次の表に、各機能と、それぞれに必要な最小限の APIC リリースを示します。

（注）

次の機能の一部は、以前の Cisco APIC リリースでサポートされていますが、Nexus ダッシュボードにオンボードし、このリリースの Nexus Dashboard Orchestrator で管理できる最も古いリリースは、リリース 4.2(4) です。

機能

最小バージョン

ACI マルチポッドのサポート

リリース 4.2(4)

サービス グラフ (L4 ~ L7 サービス)

リリース 4.2(4)

外部 EPG

リリース 4.2(4)

ACI 仮想エッジ VMM のサポート

リリース 4.2(4)

DHCP Support

リリース 4.2(4)

整合性チェッカー

リリース 4.2(4)

vzAny

リリース 4.2(4)

ホストベースのルーティング

リリース 4.2(4)

CloudSec 暗号化

リリース 4.2(4)

レイヤ 3 マルチキャスト

リリース 4.2(4)

OSPF の MD5 認証

リリース 4.2(4)

EPG 優先グループ

リリース 4.2(4)

サイト内 L3Out

リリース 4.2(4)

QoS の優先順位

リリース 4.2(4)

コントラクト QoS 優先順位

リリース 4.2(4)

シングル サインオン（SSO）

リリース 5.0(1)

マルチキャスト ランデブー ポイント（RP）のサポート

リリース 5.0(1)

AWS および Azure サイトのトランジット ゲートウェイ（TGW）サポート

リリース 5.0(1)

SR-MPLS サポート

リリース 5.0(1)

クラウド ロードバランサ 高可用性ポート

リリース 5.0(1)

UDR を使用したサービスグラフ（L4-L7 サービス）

Release 5.0(2)

クラウドでのサードパーティ デバイスのサポート

Release 5.0(2)

クラウド ロードバランサのターゲット接続モード機能

Release 5.1(1)

Express Route 経由で到達可能な非 ACI ネットワークの Azure でのセキュリティおよびサービス挿入サポート

Release 5.1(1)

CSR プライベート IP サポート

Release 5.1(1)

Azure のクラウド ネイティブ サービスの ACI ポリシー モデルと自動化の拡張

Release 5.1(1)

Azure の単一 VNET 内での複数の VRF サポートによる柔軟なセグメンテーション

Release 5.1(1)

Azure PaaS および サードパーティ サービスのプライベート リンク自動化

Release 5.1(1)

ACI-CNI を使用した Azure での OpenShift 4.3 IPI

Release 5.1(1)

クラウド サイト アンダーレイの設定

リリース 5.2(1)

Cisco ACI サイトの追加

ここでは、Nexus Dashboard GUI を使用して Cisco APIC または Cloud APIC サイトを追加し、そのサイトを Nexus Dashboard Orchestrator で管理できるようにする方法について説明します。

始める前に

- この章の前のセクションで説明したように、オンプレミスの ACI サイトを追加する際には、各サイトの APIC でサイト固有の構成を完了している必要があります。

- 追加するサイトがリリース 4.2(4) 以降を実行していることを確認する必要があります。

手順

ステップ 1

Nexus ダッシュボード GUI にログインします。

ステップ 2

新サイトを追加します。

1. 左のナビゲーションメニューから [サイト (Sites)] を選択します。

2. メインペインの右上にある[アクション (Actions)] > [サイトの追加 (Add Site)]をクリックします。

ステップ 3

サイト情報を入力します。

1. [サイトのタイプ (Site Type)] で、追加する ACI ファブリックのタイプに応じて [ACI] または [クラウド ACI (Cloud ACI)] を選択します。

2. コントローラ情報を入力します。

ACI ファブリックを現在管理している APIC コントローラについて、[ホスト名/IP アドレス (Host Name/IP Address)]、[ユーザー名 (User Name)]、および [パスワード (Password)] を入力する必要があります。用です。

（注）

APIC ファブリックでは、Nexus Dashboard Orchestrator サービスのみでサイトを使用する場合、APIC のインバンドまたはアウトオブバンド IP アドレスを指定できます。Nexus Dashboard Insights でもサイトを使用する場合は、インバンド IP アドレスを指定する必要があります。

Cisco APIC によって管理されるオンプレミス ACI サイトの場合、このサイトを Nexus Insights などのデイ 2 オペレーション アプリケーションで使用する場合は、追加する Nexus ダッシュボードをファブリックに接続するために使用するインバンド EPG 名も指定する必要があります。それ以外の場合、このサイトを Nexus Dashboard Orchestrator でのみ使用する場合は、このフィールドを空白のままにすることができます。

3. [追加 (Add)] をクリックして、サイトの追加を終了します。

この時点で、サイトは Nexus ダッシュボードで使用できるようになりますが、次の手順で説明するように、Nexus Dashboard Orchestrator の管理用にそれらのサイトを有効にする必要があります。

ステップ 4

他のサイトに対して上記の手順を繰り返します。

ステップ 5

Nexus ダッシュボードの [サービス カタログ (Service Catalog)] から、Nexus Dashboard Orchestratorサービスを開きます。

Nexus ダッシュボード ユーザーのクレデンシャルを使用して自動的にログインします。

ステップ 6

Nexus Dashboard Orchestrator GUIで、サイトを管理します。

1. 左のナビゲーションメニューから 、[インフラストラクチャ (Infrastructure)] > [サイト (Sites)]を選択します。

2. メインペインで、NDOで管理する各ファブリックの [状態 (State)] を [非管理対象 (Unmanaged)] から [管理対象 (Managed)] に変更します。

サイトの削除

ここでは、Nexus Dashboard Orchestrator GUI を使用して 1 つ以上のサイトのサイト管理を無効にする方法について説明します。サイトは Nexus ダッシュボードに残ります。

始める前に

削除するサイトに関連付けられているすべてのテンプレートが展開されていないことを確認する必要があります。

手順

ステップ 1

Nexus Dashboard Orchestrator GUI を開きます。

Nexus ダッシュボードのサービス カタログから NDO サービスを開きます。Nexus ダッシュボード ユーザーのクレデンシャルを使用して自動的にログインします。

ステップ 2

サイトのアンダーレイ設定を削除します。

1. 左側のナビゲーション メニューで、[インフラストラクチャ（Infrastructure）] > [インフラの設定（Infra Configuration）]を選択します。

2. メイン ペインにある [インフラの設定（Configure Infra）] をクリックします。

3. 左側のサイドバーで、管理対象から外すサイトを選択します。

4. 右側のバーの [オーバレイの設定 (Overlay Configuration)] タブで、[Multi-Site] ノブを無効にします。

5. 右側のサイドバーで、[アンダーレイ設定 (Underlay Configuration)] タブを選択します。

6. サイトからすべてのアンダーレイ設定を削除します。

7. [展開 (Deploy)] をクリックして、アンダーレイとオーバーレイの設定変更をサイトに展開します。

ステップ 3

Nexus Dashboard Orchestrator GUI で、サイトを無効にします。

1. 左のナビゲーションメニューから 、[インフラストラクチャ (Infrastructure)] > [サイト (Sites)]を選択します。

2. メインペインで、NDOで管理する各ファブリックの [状態 (State)] を [管理対象 (Managed)] から [非管理対象 (Unmanaged)] に変更します。

（注）

サイトが 1 つ以上の展開済みテンプレートに関連付けられている場合、それらのテンプレートを展開解除するまで、その状態を [非管理対象 (Unmanaged)] に変更することはできません。

ステップ 4

Nexus ダッシュボードからサイトを削除します。

このサイトを管理したり、他のアプリケーションで使用したりする必要がなくなった場合は、Nexus ダッシュボードからもサイトを削除できます。

（注）

この時点で、このサイトは、Nexus Dashboard クラスタにインストールされているどのアプリケーションでも使用されていてはならないことに注意してください。

1. NexusダッシュボードGUIの左側のナビゲーションメニューから、[サイト (Sites)] を選択します。

2. 削除するサイトを1つ以上選択します。

3. メインペインの右上にある[アクション (Actions)] > [サイトの削除 (Delete Site)]をクリックします。

4. サイトのログイン情報を入力し、[OK] をクリックします。

Nexus ダッシュボードからサイトが削除されます。

ファブリック コントローラへの相互起動

Nexus Dashboard Orchestrator は現在、ファブリックのタイプごとに多数の設定オプションをサポートしています。追加の多くの設定オプションでは、ファブリックのコントローラに直接ログインする必要があります。

NDO の[インフラストラクチャ (Infrastucture)] > [サイト (Sites)]画面から特定のサイト コントローラの GUI にクロス起動するには、サイトの横にあるアクション（...）メニューを選択し、ユーザー インターフェイスで [開く (Open)] をクリックします。クロス起動は、ファブリックのアウトオブバンド（OOB）管理IPで動作することに注意してください。

Nexus Dashboardとファブリックで同じユーザが設定されている場合、Nexus Dashboardユーザと同じログイン情報を使用して、ファブリックのコントローラに自動的にログインします。一貫性を保つために、Nexusダッシュボードとファブリック全体で共通のユーザによるリモート認証を設定することを推奨します。

Chapter13. インフラ一般設定

- インフラ設定ダッシュボード

- インフラの設定: 一般設定

インフラ設定ダッシュボード

[インフラ設定 (Infra Configuration)] ページには、Nexus Dashboard Orchestrator 展開環境のすべてのサイトとサイト間接続の概要が表示されます。

インフラ設定の概要

1. [全般設定 (General Settings)] タイルには、BGP ピアリング タイプとその設定に関する情報が表示されます。

詳細については、次のセクションで説明します。

2. [オンプレミス (On-Premises)] タイルには、ポッドとスパイン スイッチの数、OSPF 設定、およびオーバーレイ IP とともに、Multi-Site ドメインの一部であるすべてのオンプレミス サイトに関する情報が表示されます。

サイト内のポッドの数を表示する[ポッド (Pods)] タイルをクリックすると、各ポッドのオーバーレイ ユニキャスト TEP アドレスに関する情報を表示できます。

詳細については、Cisco APIC サイトのインフラの設定を参照してください。

3. [クラウド (Cloud)] タイルには、Multi-Site ドメインの一部であるすべてのクラウド サイトに関する情報と、リージョン数および基本的なサイト情報が表示されます。

詳細については、Cisco Cloud APIC サイトのインフラの設定を参照してください。

次のセクションでは、全般的なファブリック インフラ設定を行うために必要な手順について説明します。ファブリック固有の要件と手順は、管理するファブリックの特定のタイプに基づいて、次の章で説明します。

インフラの設定を進める前に、前のセクションで説明したようにサイトを設定して追加する必要があります。

加えて、スパイン スイッチの追加や削除、またはスパイン ノード ID の変更などのインフラストラクチャの変更には、一般的なインフラの設定手順の一部として、サイト接続性情報の更新 に記載されているような、 Nexus Dashboard Orchestrator のファブリック接続情報の更新が必要です。

インフラの設定: 一般設定

ここでは、すべてのサイトの一般的なインフラ設定を構成する方法について説明します。

（注）

次の設定には、すべてのサイトに適用されるものと、特定のタイプのサイト（クラウド APIC サイトなど）に必要なものとがあります。各サイト固有のサイト ローカル設定に進む前に、インフラ一般設定で必要なすべての設定を完了していることを確認します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[インフラストラクチャ（Infrastructure）] > [インフラの設定（Infra Configuration）]を選択します。

ステップ 3

メイン ペインにある [インフラの設定（Configure Infra）] をクリックします。

ステップ 4

左側のサイドバーで、[全般設定（General Settings）]を選択します。

ステップ 5

[コントロール プレーン設定（Control Plane Configuration）] を指定します。

1. [コントロール プレーン設定（Control Plane Configuration）] タブを選択します。

2. [BGP ピアリング タイプ（Bgp Peering Type）] を選択します。

- full-mesh：各サイトのすべてのボーダー ゲートウェイ スイッチは、リモート サイトのボーダー ゲートウェイ スイッチとのピア接続を確立します。

[フルメッシュ] 構成では、Nexus Dashboard Orchestrator は ACI 管理ファブリックのスパイン スイッチと DCNM 管理ファブリックのボーダー ゲートウェイを使用します。

- [route-reflector]：route-reflector オプションを使用すると、各サイトが MP-BGP EVPN セッションを確立する 1 つ以上のコントロール プレーン ノードを指定できます。ルート リフレクタ ノードを使用すると、NDO によって管理されるすべてのサイト間で MP-BGP EVPN フル メッシュ隣接関係が作成されなくなります。

ACIファブリックの場合、[route-reflector] オプションは、同じ BGP ASN の一部であるファブリックに対してのみ有効です。

3. [キープアライブ間隔 (秒) (Keepalive Interval (Seconds))] フィールドに、キープアライブ間隔を秒単位で入力します。

デフォルト値を維持することを推奨します。

4. [保留間隔 (秒) (Hold Interval (Seconds))] フィールドに、保留間隔を秒単位で入力します。

デフォルト値を維持することを推奨します。

5. [失効間隔 (秒) (Stale Interval (Seconds))] フィールドに、失効間隔を秒単位で入力します。

デフォルト値を維持することを推奨します。

6. [グレースフル ヘルパー (Graceful Helper)] オプションをオンにするかどうかを選択します。

7. [AS 上限（Maximum AS Limit）]を入力します。

デフォルト値を維持することを推奨します。

8. [ピア間のBGP TTL（BGP TTL Between Peers）] を入力します。

デフォルト値を維持することを推奨します。

9. [OSPF エリア ID (OSPF Area ID)] を入力します。

クラウド APIC サイトがない場合、このフィールドは UI に表示されません。

これは、以前の Nexus Dashboard Orchestrator リリースでサイト間接続用にクラウド APIC で以前に設定した、オンプレミス IPN ピアリング用のクラウドサイトで使用される OSPF エリア ID です。

ステップ 6

[IPN デバイス情報] を入力します。

オンプレミスとクラウド サイト間のサイト間接続を設定する予定がない場合は、この手順をスキップできます。

後のセクションで説明するように、オンプレミスとクラウド サイト間のサイト アンダーレイ接続を設定する場合は、クラウド CSR への接続を確立するオンプレミス IPN デバイスを選択する必要があります。これらのIPNデバイスは、オンプレミスサイトの設定画面で使用可能になる前に、ここで定義する必要があります。詳細はインフラの設定: オンプレミス サイトの設定を参照してください。

1. [デバイス (Devices)] タブを選択します。

2. [IPN デバイスの追加 (Add IPN Device)] をクリックします。

3. IPN デバイスの [名前（Name）] と [IPアドレス（IP Address）] を入力します。

指定した IP アドレスは、IPN デバイスの管理 IP アドレスではなく、クラウド APIC の CSR からのトンネル ピア アドレスとして使用されます。

4. チェック マーク アイコンをクリックして、デバイス情報を保存します。

5. 追加する IPN デバイスについて、この手順を繰り返します。

ステップ 7

[外部 デバイス（External Devices）] 情報を入力します。

クラウド APIC サイトがない場合、このタブは UI に表示されません。

Multi-Site ドメインにクラウド APIC サイトがない場合、またはクラウド サイトとブランチ ルータまたはその他の外部デバイス間の接続を設定する予定がない場合は、この手順をスキップできます。

次の手順では、クラウド サイトからの接続を設定するブランチ ルータまたは外部デバイスに関する情報を指定する方法について説明します。

1. [外部デバイス（External Devices）] タブを選択します。

このタブは、Multi-Site ドメインに少なくとも 1 つのクラウドサイトがある場合にのみ使用できます。

2. [外部デバイスの追加（Add External Device）] をクリックします。

[外部デバイスの追加（Add External Device）] ダイアログが開きます。

3. デバイスの [名前（Name）]、[IP アドレス（IP Address）]、および [BGP 自律システム番号（BGP Autonomous System Number）] を入力します。

指定した IP アドレスは、デバイスの管理 IP アドレスではなく、クラウド APIC の CSR からのトンネル ピア アドレスとして使用されます。接続は、IPSec を使用してパブリック インターネット経由で確立されます。

4. チェック マーク アイコンをクリックして、デバイス情報を保存します。

5. 追加する IPN デバイスについて、この手順を繰り返します。

すべての外部デバイスを追加したら、次の手順を完了して、IPSec トンネル サブネット プールにこれらのトンネルに割り当てられる内部 IP アドレスを指定します。

ステップ 8

[IPSecトンネル サブネット プール（IPSec Tunnel Subnet Pools）] 情報を入力します。

クラウド APIC サイトがない場合、このタブは UI に表示されません。

ここで指定できるサブネットプールには、次の 2 つのタイプがあります。

- 外部サブネット プール：クラウド サイトの CSR と他のサイト（クラウドまたはオンプレミス）間の接続に使用されます。

これらは、Nexus Dashboard Orchestrator によって管理される大規模なグローバル サブネット プールです。Orchestrator は、これらのプールからより小さなサブネットを作成し、サイト間 IPsec トンネルと外部接続 IPsec トンネルで使用するサイトに割り当てます。

1 つ以上のクラウド サイトから外部接続を有効にする場合は、少なくとも 1 つの外部サブネット プールを提供する必要があります。

- サイト固有のサブネット プール：クラウド サイトの CSR と外部デバイス間の接続に使用されます。

これらのサブネットは、外部接続 IPsec トンネルが特定の範囲内にあることが必要な場合に定義できます。たとえば、外部ルータに IP アドレスを割り当てるために特定のサブネットがすでに使用されており、それらのサブネットを NDO およびクラウド サイトの IPsec トンネルで引き続き使用する場合です。これらのサブネットは Orchestrator によって管理されず、各サブネットはサイト全体に割り当てられ、外部接続 IPsec トンネルにローカルで使用されます。

名前付きサブネット プールを指定しない場合でも、クラウド サイトの CSR と外部デバイス間の接続を設定すると、外部サブネット プールが IP 割り当てに使用されます。.

（注）

両方のサブネット プールの最小マスク長は /24 です。

1 つ以上の外部サブネット プールを追加するには：

1. [IPSec トンネル サブネット プール（IPSec Tunnel Subnet Pools）] タブを選択します。

2. [外部サブネット プール（External Subnet Pool）] エリアで、[+ IP アドレスの追加（+Add IP Address）] をクリックして、1 つ以上の外部サブネット プールを追加します。

このサブネットは、以前の Nexus Dashboard Orchestrator リリースでサイト間接続用にクラウド APIC で以前に設定した、オンプレミス接続に使用されるクラウド ルータの IPsec トンネル インターフェイスとループバックに対処するために使用されます。

サブネットは、他のオンプレミス TEP プールと重複してはならず、0.xxx または 0.0.xxで 始まってはならず、/16 と /24 の間のネットワーク マスク（30.29.0.0/16 など）が必要です。

3. チェックマーク アイコンをクリックして、サブネット情報を保存します。

4. 追加するサブネット プールについて、これらのサブステップを繰り返します。

1つ以上の名前付きサブネット プールを追加するには、次の手順を実行します。

1. [IPSec トンネル サブネット プール（IPSec Tunnel Subnet Pools）] タブを選択します。

2. [名前付きサブネット プール（Named Subnet Pool）] エリアで、[+ IP アドレスの追加（+Add IP Address）] をクリックして、1 つ以上の外部サブネット プールを追加します。

[名前付きサブネットプールの追加（Add Named Subnet Pool）] ダイアログが開きます。

3. サブネットの [名前（Name）] を入力します。

後ほど、サブネットプールの名前を使用して、IP アドレスを割り当てるプールを選択できます。

4. [+ IP アドレスの追加 (+ Add IP Address)]をクリックして、1 つ以上のサブネット プールを追加します。

サブネットには /16 と /24 の間のネットワークが必要で、0.x.x.x または 0.0.x.x で始めることはできません。たとえば、30.29.0.0/16 のようにします。

5. チェックマーク アイコンをクリックして、サブネット情報を保存します。

同じ名前付きサブネット プールに複数のサブネットを追加する場合は、この手順を繰り返します。

6. [保存（Save）] をクリックして、名前付きサブネット プールを保存します。

7. 追加する名前付きサブネット プールについて、これらのサブステップを繰り返します。

次のタスク

全般的なインフラ設定を構成した後も、管理するサイトのタイプ（オンプレミス ACI、クラウド ACI、またはオンプレミス ファブリック）に基づいて、サイト固有の設定に関する追加情報を指定する必要があります。次の項で説明する手順に従って、サイト固有のインフラストラクチャ設定を行います。

Chapter14. Cisco APIC サイトのインフラの設定

- サイト接続性情報の更新

- インフラの設定: オンプレミス サイトの設定

- インフラの設定: ポッドの設定

- インフラの設定: スパイン スイッチ

サイト接続性情報の更新

スパインの追加や削除、またはスパイン ノードの ID 変更などのインフラストラクチャへの変更が加えられた場合、Multi-Site ファブリック接続サイトの更新が必要になります。このセクションでは、各サイトの APIC から直接最新の接続性情報を取得する方法を説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[メイン メニュー (Main menu)] で、[インフラストラクチャ (Infrastructure)] > [インフラの設定 (Infra Configuration)]を選択します。

ステップ 3

右上にある [インフラの構成 (Infra Configuration)] ビューで、[インフラの設定 (Configure Infra)] ボタンをクリックします。

ステップ 4

左側のペインの [サイト (Sites)] の下で、特定のサイトを選択します。

ステップ 5

メイン ウィンドウで、APIC からファブリック情報を取得するために [更新 (Refresh)] ボタンをクリックします。

ステップ 6

（オプション）オンプレミス サイトの場合、廃止されたスパイン スイッチノードの設定を削除する場合は、[確認 (Confirmation)] ダイアログでチェックボックスをオンにします。

このチェックボックスを有効にすると、現在使用されていないスパイン スイッチのすべての設定情報がデータベースから削除されます。

ステップ 7

最後に、[はい (Yes)] をクリックして確認し、接続情報をロードします。

これにより、新しいスパインや削除されたスパインを検出し、すべてのサイトに関連したファブリックの接続を APIC からインポートし直します。

インフラの設定: オンプレミス サイトの設定

ここでは、オンプレミス サイトにサイト固有のインフラ設定を構成する方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[インフラストラクチャ（Infrastructure）] > [インフラの設定（Infra Configuration）]を選択します。

ステップ 3

メイン ペインにある [インフラの設定（Configure Infra）] をクリックします。

ステップ 4

左側のペインの [サイト (Sites)] の下で、特定のオンプレミス サイトを選択します。

ステップ 5

[オーバーレイ設定 (Overlay Configuration)] を指定します。

1. 右側の <サイト (Site)> [設定 (Settings)] ペインで、[オーバレイ設定 (Overlay Configuration)] タブを選択します。

2. 右側の <サイト (Site)> [設定 (Settings)] ペインで、[マルチサイト (Multi-Site)] ノブを有効にします。

これは、オーバーレイ接続がこのサイトと他のサイト間で確立されるかどうかを定義します。

3. (オプションｎ) [CloudSec 暗号化 (CloudSec Encryption)] ノブを有効にして、サイトを暗号化します。

CloudSec 暗号化は、サイト間トラフィックの暗号化機能を提供します。この機能の詳細については、 Cisco Multi-Site Configuration Guide の「Infrastructure Management」の章を参照してください。

4. [オーバレイ マルチキャスト TEP (Overlay Multicast TEP)] を指定します。

このアドレスは、サイト間の L2 BUM および L3 マルチキャスト トラフィックのために使用されます。この IP アドレスは、単一のポッドまたはマルチポッド ファブリックであるかどうかには関わりなく、同じファブリックの一部であるすべてのスパイン スイッチに展開されます。

このアドレスは、元のファブリックのインフラ TEP プールのアドレス空間または 0.x.x.x の範囲から取得することはできません。

5. （オプション）[外部ルート ドメイン (External Routed Domain)] ドロップダウンから、使用するドメインを選択します。

Cisco APIC GUI で作成した外部ルータ ドメインを選択します。使用している APIC リリースに固有の詳細については、『Cisco APIC Layer 3 Networking Configuration Guide』を参照してください。

6. [BGP 自律システム番号 (BGP Autonomous System Number)] を指定します。

7. （オプション）[BGP パスワード (BGP Password)] を指定します。

8. （オプション）サイトの [SR-MPLS 接続 (SR-MPLS Connectivity)]を有効にします。

サイトが MPLS ネットワークを介して接続されている場合には、[SR-MPLS 接続性 (SR-MPLS Connectivity)] ノブを有効にして、セグメント ルーティング グローバル ブロック (SRGB) の範囲を指定します。

セグメント ルーティング グローバル ブロック（SRGB）は、ラベル スイッチング データベース (LSD) でセグメント ルーティング (SR) 用に予約されているラベル値の範囲です。これらの値は SR 対応ノードへのセグメント識別子（SID）として割り当てられ、ドメイン全体でグローバルな意味を持ちます。

デフォルトの範囲は 16000 ～ 23999 です。

サイトのMPLS接続を有効にする場合は、 『Cisco Multi-Site Configuration Guide for ACI Fabrics』の「Sites Connected via SR-MPLS」の章で説明されている追加設定を行う必要があります。

ステップ 6

[アンダーレイ設定 (Underlay Configuration)] を指定します。

サイトと IPN 間のアンダーレイ接続に OSPF プロトコルを使用する場合は、次の設定が必要です。代わりに BGP を使用する場合は、この手順を省略できます。BGP アンダーレイの設定は、インフラの設定: スパイン スイッチで説明されているように、ポート レベルで行われます。

1. 右側の <サイト (Site)> [設定 (Settings)] ペインで、[アンダーレイ設定 (Underlay Configuration)] タブを選択します。

2. [OSPF エリア ID (OSPF Area ID)] を入力します。

3. ドロップダウン メニューから [OSPF エリア タイプ (OSPF Area Type)]を選択します。

OSPF エリアタイプは、次のいずれかになります。

- nssa

- regular

4. サイトの OSPF ポリシーを設定します。

既存のポリシー (たとえば msc-ospf-policy-default) をクリックして修正することも、[+ ポリシー追加(+Add Policy)] をクリックして新しい OSPF ポリシーを追加することもできます。それから、[ポリシーの追加/更新(Add/Update Policy)] ウィンドウで、以下を指定します。

- [ポリシー名（Policy Name）] フィールドにポリシー名を入力します。

- [(ネットワーク タイプ (Network Type)] フィールドで、[ブロードキャスト (broadcast)]、[ポイントツーポイント (point-to-point)]、または [未指定 (unspecified)] のいずれかを選択します。

デフォルトは [ブロードキャスト (broadcast)] です。

- [優先順位 (Priority)] フィールドに、優先順位番号を入力します。

デフォルトは 1 です。

- [インターフェイスのコスト (Cost of Interface)] フィールドに、インターフェイスのコストを入力します。

デフォルト値は 0 です。

- [インターフェイス コントロール(Interface Controls)] ドロップダウン メニューで、以下のいずれかを選択します。

- アドバタイズサブネット (advertise-subnet)

- BFD (bfd)

- MTU 無視 (mtu-ignore)

- 受動的参加 (passive-participation)

- [Hello 間隔 (秒) (Hello Interval (Seconds))] フィールドに、hello 間隔を秒単位で入力します。

デフォルト値は 10 です。

- [Dead 間隔 (秒) (Dead Interval (Seconds))] フィールドに、dead 間隔を秒単位で入力します。

デフォルト値は 40 です。

- [再送信間隔 (秒) (Retransmit Interval (Seconds))] フィールドに、再送信間隔を秒単位で入力します。

デフォルト値は 5 です。

- [転送遅延 (秒) (Transmit Delay (Seconds))] フィールドに、遅延を秒単位で入力します。

デフォルトは 1 です。

ステップ 7

オンプレミスとクラウド サイト間のサイト間接続を設定します。

オンプレミス サイトとクラウド サイトの間にサイト間接続を作成する必要がない場合（たとえば、導入にクラウドのみまたはオンプレミス サイトのみが含まれる場合）は、この手順をスキップします。

オンプレミスとクラウド サイト間のアンダーレイ接続を設定する場合は、クラウド APIC の CSR がトンネルを確立する IPN デバイスの IP アドレスを指定し、クラウド サイトのインフラ設定を行う必要があります。

1. [+ IPN デバイスの追加 (+ Add IPN Device)] をクリックして、IPNデバイスを指定します。

2. ドロップダウンから、前に定義した IPN デバイスのいずれかを選択します。

IPNデバイスは、[一般設定 (General Settings)] > [IPN デバイス (IPN Devices)]リストですでに定義されている必要があります。 インフラの設定: 一般設定を参照してください。

3. クラウド サイトのサイト間接続を設定します。

クラウド サイトからこのオンプレミス サイトへの以前に設定された接続はすべてここに表示されますが、追加の設定は、Cisco Cloud APIC サイトのインフラの設定の説明に従ってクラウド サイト側から行う必要があります。

次のタスク

必要なサイト間接続情報をすべて設定しましたが、まだサイトにプッシュされていません。インフラ設定の展開の説明に従って、設定を展開する必要があります。

インフラの設定: ポッドの設定

このセクションでは、各サイトでポッド固有の設定を行う方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

メイン メニューで [サイト] をクリックします。

ステップ 3

[サイト] ビューで、[インフラの構築] をクリックします。

ステップ 4

左側のペインの [サイト (Sites)] の下で、特定のサイトを選択します。

ステップ 5

メイン ウィンドウで、ポッドを選択します。

ステップ 6

右の [ポッドのプロパティ (Pod Properties)] ペインで、ポッドについてオーバーレイ ユニキャスト TEP を追加できます。

この IP アドレスは、同じポッドの一部であるすべてのスパイン スイッチに展開され、レイヤ 2 およびレイヤ 3 ユニキャスト通信用の VXLAN カプセル化トラフィックの送信と受信に使用されます。

ステップ 7

[+ TEP プールの追加 (+Add TEP Pool)] をクリックして、ルーティング可能な TEP プールを追加します。

外部ルーティング可能な TEP プールは、IPN 経由でルーティング可能な IP アドレスのセットを APIC ノード、スパイン スイッチ、および境界リーフ ノードに割り当てるために使用されます。これは、Multi-Site アーキテクチャを有効にするために必要です。

以前に APIC でファブリックに割り当てられた外部 TEP プールは、ファブリックが Multi-Site ドメインに追加されると、NDO によって自動的に継承され、GUI に表示されます。

ステップ 8

サイトの各ポッドに対してこの手順を繰り返します。

インフラの設定: スパイン スイッチ

このセクションでは、Cisco Multi-Site のために各サイトのスパイン スイッチを設定する方法について説明します。スパイン スイッチを設定する場合、各サイトのスパインと ISN 間の接続を設定することで、Multi-Site ドメイン内のサイト間のアンダーレイ接続を効果的に確立できます。

リリース 3.5(1) より前は、OSPF プロトコルを使用してアンダーレイ接続が確立されていました。一方、このリリースでは、OSPF、BGP（IPv4 のみ）、または混合プロトコルを使用できます。混合とは、一部のサイトではサイト間アンダーレイ接続に OSPF を使用し、一部のサイトでは BGP を使用することです。両方ではなく OSPF または BGP のいずれかを設定することを推奨します。両方のプロトコルを設定した場合には、BGP が優先され、OSPF はルート テーブルにインストールされません。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

メイン メニューで [サイト] をクリックします。

ステップ 3

[サイト] ビューで、[インフラの構築] をクリックします。

ステップ 4

左側のペインの [サイト (Sites)] の下で、特定のサイトを選択します。

ステップ 5

メイン ウィンドウで、ポッド内のスパイン スイッチを選択します。

ステップ 6

右側の [<スパイン> 設定 (Settings)] ペインで、[+ ポート追加(Add Port)] をクリックします。

ステップ 7

[ポートの追加 (Add Port)] ウィンドウで、アンダーレイの接続情報を入力します。

IPN 接続用に APIC で直接設定されているポートがインポートされ、リストに表示されます。NDO から設定する新しいポートについては、次の手順を使用します。

1. 次の一般情報を指定します。

- [イーサネット ポート ID (Ethernet Port ID)] フィールドに、ポート ID、たとえば 1/29 を入力します。

これは、IPN への接続に使用されるインターフェイスです。

- [IP アドレス (IP Address)] フィールドに、IP アドレス/ネットマスクを入力します。

Orchestrator によって、指定された IP アドレスを持ち、指定されたポートを使用する、VLAN 4 のサブインターフェイスが作成されます。

- [MTU] フィールドに、サーバの MTU を入力します。MTUを9150Bに設定する継承を指定するか、576 〜 9000 の値を選択します。

スパイン ポートの MTU は、IPN 側の MTU と一致させる必要があります。

2. アンダーレイ接続に OSPF プロトコルを使用する場合は、OSPF を設定します。

代わりに、アンダーレイ接続に BGP プロトコルを使用する場合は、この部分をスキップし、次のサブステップで必要な情報を入力します。

- [OSPF] を [有効 (Enabled)] に設定します。

OSPF 設定が使用可能になります。

- [OSPF ポリシー (OSPF Policy)] ドロップダウンで、インフラの設定: オンプレミス サイトの設定 で設定したスイッチの OSPF ポリシーを選択します。

OSPF ポリシーの OSPF 設定は、IPN 側と一致させる必要があります。

- [OSPF 認証 (OSPF Authentication)] では、[なし (none)] または以下のいずれかを選択します。

- MD5

- Simple

- [BGP] を [無効 (Disabled)] に設定します。

3. アンダーレイ接続に BGP プロトコルを使用する場合は、BGP を設定します。

アンダーレイ接続に OSPF プロトコルを使用しており、前のサブステップですでに設定している場合は、この部分をスキップします。

- [OSPF] を [無効 (Disabled)] に設定します。

両方ではなく OSPF または BGP のいずれかを設定することを推奨します。両方のプロトコルを設定した場合には、BGP が優先され、OSPF はルート テーブルにインストールされません。ISN デバイスとの EBGP 隣接関係だけがサポートされるからです。

- [BGP] を [有効 (Enabled)] に設定します。

BGP 設定が使用可能になります。

- [ピア IP (Peer IP)] フィールドに、このポートの BGP ネイバーの IP アドレスを入力します。

BGP アンダーレイ接続では、IPv4 IP アドレスのみがサポートされます。

- [ピア AS 番号 (Peer AS Number)] フィールドに、BGP ネイバーの自律システム（AS）番号を入力します。

このリリースでは、ISN デバイスとの EBGP 隣接関係のみがサポートされます。

- [BGP パスワード (BGP Password)] フィールドに、BGP ピア パスワードを入力します。

- 必要に応じて追加のオプションを指定します。

- [双方向フォワーディング検出 (Bidirectional Forwarding Detection)]：双方向フォワーディング検出（BFD）プロトコルを有効にして、このポートと IPN デバイスの物理リンクの障害を検出します。

- [管理状態 (Admin State)]：ポートの管理状態を有効に設定します。

ステップ 8

IPN に接続するすべてのスパイン スイッチおよびポートに対してこの手順を繰り返します。

Chapter15. Cisco Cloud APIC サイトのインフラの設定

- クラウド サイト接続性情報の更新

- インフラの設定: クラウド サイトの設定

クラウド サイト接続性情報の更新

CSR やリージョンの追加や削除などのインフラストラクチャの変更には、Multi-Site ファブリック接続サイトの更新が必要です。このセクションでは、各サイトの APIC から直接最新の接続性情報を取得する方法を説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[メイン メニュー (Main menu)] で、[インフラストラクチャ (Infrastructure)] > [インフラの設定 (Infra Configuration)]を選択します。

ステップ 3

右上にある [インフラの構成 (Infra Configuration)] ビューで、[インフラの設定 (Configure Infra)] ボタンをクリックします。

ステップ 4

左側のペインの [サイト (Sites)] の下で、特定のサイトを選択します。

ステップ 5

メインウィンドウで [更新 (Refresh)] ボタンをクリックして、新規または変更されたCSRおよびリージョンを検出します。

ステップ 6

最後に、[はい (Yes)] をクリックして確認し、接続情報をロードします。

これにより、新規または削除された CSR およびリージョンが検出されます。

ステップ 7

[導入 (Deploy)] をクリックして、クラウドサイトの変更を、接続している他のサイトに伝達します。

クラウドサイトの接続を更新し、CSR またはリージョンが追加または削除された後、インフラ設定を展開して、そのクラウドサイトへのアンダーレイ接続がある他のサイトが更新された設定を取得する必要があります。

インフラの設定: クラウド サイトの設定

ここでは、クラウド APIC サイトにサイト固有のインフラ設定を構成する方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[メイン メニュー (Main menu)] で、[インフラストラクチャ (Infrastructure)] > [インフラの設定 (Infra Configuration)]を選択します。

ステップ 3

メインペインの右上にある [インフラの設定 (Configure Infra)] をクリックします。

ステップ 4

左側のペインの [サイト (Sites)] の下で、特定のクラウド サイトを選択します。

ステップ 5

[サイト間接続 (Inter-Site Connectivity)] 情報を入力します。

[オーバーレイ設定 (Overlay Configuration)] を入力します。

1. 右側の [<Site> 設定 (Settings)] ペインで、[サイト間接続 (Inter-Site Connectivity)] タブを選択します。

2. [オーバーレイ設定 (Overlay Configuration)] 領域で、[Multi-Site] ノブを有効にします。

これは、オーバーレイ接続がこのサイトと他のサイト間で確立されるかどうかを定義します。

3. （オプション）[BGP パスワード (BGP Password)] を指定します。

[サイト間接続 (Inter-Site Connectivity)] 情報を入力します。

1. [アンダーレイ設定 (Underlay Configuration)] 領域で、[接続の追加 (Add Connectivity)] をクリックします。

2. [サイト (Site)] ドロップダウンから、接続を確立するサイトを選択します。

3. .[接続タイプ (Connection Type)] ドロップダウンから、サイト間の接続のタイプを選択します。

次のオプションを使用できます。

- [パブリックインターネット (Public Internet)]：2 つのサイト間の接続は、インターネットを介して確立されます。

このタイプは、任意の 2 つのクラウド サイト間、またはクラウド サイトとオンプレミス サイト間でサポートされます。

- [プライベート接続 (Private Connection)]：2 つのサイト間のプライベート接続を使用して接続が確立されます。

このタイプは、クラウド サイトとオンプレミス サイトの間でサポートされます。

- [クラウド バックボーン (Cloud Backbone)]：クラウド バックボーンを使用して接続が確立されます。

このタイプは、Azure-to-AzureやAWS-to-AWSなど、同じタイプの 2 つのクラウド サイト間でサポートされます。

複数のタイプのサイト（オンプレミス、AWS、Azure）がある場合、サイトの異なるペアは異なる接続タイプを使用できます。

4. （オプション）[IPsec] を有効にします。

次のオプションを使用できます。

- パブリック インターネット接続の場合、IPsec は常に有効です。

- クラウド バックボーン接続の場合、IPsec は常に無効です。

- プライベート接続の場合、IPsec は有効または無効にすることができます。

5. IPsec を有効にする場合は、IKE バージョンを選択します。

IP Security（IPSec）プロトコル確立のためのインターネット キー エクスチェンジ（IKE）構成に応じて、使用するプロトコルのバージョンとして IKEv1（バージョン 1）または IKEv2（バージョン 1）を選択できます。

6. [保存 (Save)] をクリックして、サイト間接続構成を保存します。

Site1 から Site2 への接続情報を保存すると、Site2 から Site1 へのリバース接続が自動的に作成されます。これは、他のサイトを選択し、[アンダーレイ設定 (Underlay Configuration)] タブを選択することで確認できます。

7. 他のサイトのサイト間接続を追加するには、この手順を繰り返します。

Site1 から Site2 へのアンダーレイ接続を確立すると、リバース接続が自動的に行われます。

ただし、Site1 から Site3 へのサイト間接続も確立する場合は、そのサイトに対してもこの手順を繰り返す必要があります。

ステップ 6

[外部接続 (External Connectivity)] 情報を入力します。

NDO によって管理されていない外部サイトまたはデバイスへの接続を設定する予定がない場合は、この手順をスキップできます。そうでなければ、次の情報を入力します。

1. 右側の [<Site> 設定 (Settings)] ペインで、[外部接続 (External Connectivity)] タブを選択します。

2. [外部接続の追加 (Add External Connectivity)] をクリックします。

[外部接続の追加 (Add External Connectivity)] ダイアログが開きます。

3. [VRF] ドロップダウンから、外部接続に使用する VRF を選択します。

これは、クラウド ルートをリークするために使用される VRF です。[リージョン (Regions)] セクションには、この設定を適用する CSR を含むクラウド リージョンが表示されます。

4. [外部デバイス (External Devices)] セクションの [名前 (Name)] ドロップダウンから、外部デバイスを選択します。

これは、一般的なインフラストラクチャ設定時に[一般設定 (General Settings)] > [外部デバイス (External Devices)] リストに追加した外部デバイスであり、インフラの設定: 一般設定の説明に従ってすでに定義されている必要があります。

5. [トンネル IKE バージョン (Tunnel IKE Version) ] ドロップダウンから、クラウド サイトの CSR と外部デバイス間の IPSec トンネルの確立に使用する IKE バージョンを選択します。

6. （任意）[トンネル サブネット プール (Tunnel Subnet Pool)] ドロップダウンから、名前付きサブネット プールのいずれかを選択します。

名前付きサブネット プールは、クラウド サイトの CSR と外部デバイス間の IPSec トンネルに IP アドレスを割り当てるために使用されます。ここで名前付きサブネット プールを指定しない場合、外部サブネット プールが IP 割り当てに使用されます。

外部デバイス接続用の専用サブネット プールを提供することは、特定のサブネットがすでに外部ルータに IP アドレスを割り当てるために使用されており、それらのサブネットを NDO およびクラウド サイトのIPSecトンネルに引き続き使用する場合に役立ちます。

この接続に特定のサブネット プールを提供する場合は、インフラの設定: 一般設定の説明に従って作成済みである必要があります。

7. （オプション）[事前共有キー (Pre-Shared Key)] フィールドに、トンネルの確立に使用するカスタム キーを入力します。

8. 必要に応じて、同じ外部接続（同じ VRF ）に対して追加する外部デバイスについて、前のサブステップを繰り返します。

9. 必要に応じて、追加の外部接続（異なる VRF ）に対してこの手順を繰り返します。

CSR と外部デバイス間のトンネルエンドポイントには 1 対 1 の関係があるため、異なる VRF を使用して追加の外部接続を作成できますが、同じ外部デバイスに追加の接続を作成することはできません。

次のタスク

必要なサイト間接続情報をすべて設定しましたが、まだサイトにプッシュされていません。インフラ設定の展開の説明に従って、設定を展開する必要があります。

Chapter16. ACI サイト向けのインフラ設定の展開

- インフラ設定の展開

- オンプレミスとクラウド サイト間の接続の有効化

インフラ設定の展開

ここでは、各 APIC サイトにインフラ設定を展開する方法について説明します。

手順

ステップ 1

メインペインの右上にある [展開 (deploy)] をクリックして、設定を展開します。

オンプレミスまたはクラウドサイトのみを設定した場合は、[展開 (Deploy)] をクリックしてインフラ設定を展開します。

ただし、オンプレミスとクラウド サイトの両方がある場合は、次の追加オプションを使用できます。

- [展開 & IPN デバイス設定ファイルをダウンロード (Deploy & Download IPN Device config files):] オンプレミスの APIC サイトと クラウド APIC サイトの両方に設定をプッシュし、オンプレミスとクラウド サイト間のエンドツーエンド インターコネクトを有効にします。

さらに、このオプションでは、IPN デバイスから Cisco クラウド サービス ルータ（CSR）への接続できるようにするための設定情報を含む zip ファイルをダウンロードします。すべてまたは一部の設定ファイルのどちらをダウンロードするかを選択できるようにするための、フォローアップ画面が表示されます。

- [展開 & IPN デバイス設定ファイルをダウンロード (Deploy & Download IPN Device config files):] 両方のクラウド APIC サイトに設定をプッシュし、クラウド サイトと外部デバイス間のエンドツーエンド インターコネクトを有効にします。

さらに、このオプションでは、外部デバイスから、自分のクラウドサイトに展開された Cisco クラウド サービス ルータ（CSR）へ接続できるようにするための、設定情報を含む zip ファイルをダウンロードします。すべてまたは一部の設定ファイルのどちらをダウンロードするかを選択できるようにするための、フォローアップ画面が表示されます。

- [IPN デバイス設定ファイルのみをダウンロード (Download IPN Device config files only):] 構成情報を含む zip ファイルをダウンロードします。これは、IPN デバイスから Cisco Cloud Services Router（CSR）への接続を、構成を展開することなく可能にするために用いるものです。

- [外部デバイス設定ファイルのみをダウンロード (Download External Device config files only):] 構成情報を含む zip ファイルをダウンロードします。これは、外部デバイスから Cisco Cloud Services Router（CSR）への接続を、構成を展開することなく可能にするために用いるものです。

ステップ 2

確認ウィンドウで [はい (Yes)] をクリックします。

[展開が開始されました。個々のサイトの展開ステータスメッセージについては、左側のメニューを参照してください (Deployment started, refer to left menu for individual site deployment status)] というメッセージにより、インフラ構成の展開が開始されたことが示されます。左側のペインのサイト名の横に表示されるアイコンで、各サイトの進行状況を確認できます。

次のタスク

インフラ オーバーレイとアンダーレイの構成設定が、すべてのサイトのコントローラとクラウド CSR に展開されます。残った最後の手順では、サイト接続性情報の更新で説明するように、IPN デバイスをクラウド CSR のトンネルを使用して設定します。

オンプレミスとクラウド サイト間の接続の有効化

オンプレミス サイトまたはクラウド サイトのみがある場合は、このセクションをスキップできます。

ここでは、オンプレミス APIC サイトとクラウド APIC サイト間の接続を有効にする方法について説明します。

デフォルトでは、Cisco Cloud APIC は冗長 Cisco Cloud サービス ルータ 1000V のペアを展開します。この項の手順では、2 つのトンネルを作成します。1 つはオンプレミスの IPsec デバイスからこれらの各 Cisco Cloud サービス ルータ 1000V 対する IPsec トンネルです。複数のオンプレミス IPsec デバイスがある場合は、各オンプレミスデバイスの CSR に同じトンネルを設定する必要があります。

次の情報は、オンプレミスの IPsec ターミネーション デバイスとして Cisco Cloud サービス ルータ1000V のコマンドを提供します。別のデバイスまたはプラットフォームを使用している場合は、同様のコマンドを使用します。

手順

ステップ 1

クラウド サイトに導入された CSR とオンプレミスの IPsec ターミネーション デバイスとの間の接続を有効にするために必要な必要な情報を収集します。

インフラ設定の展開の手順の一部として、Nexus Dashboard Orchestrator の [IPN デバイス設定ファイルの展開とダウンロード (Deploy＆Download IPN Device config files)] オプションまたは [IPN デバイス設定ファイルのダウンロード (IPN Device config files only)] オプションを使用して、必要な設定の詳細を取得できます。

ステップ 2

オンプレミスの IPsec デバイスにログインします。

ステップ 3

最初の CSR のトンネルを設定します。

最初の CSR の詳細は、Nexus Dashboard Orchestrator からダウンロードした ISN デバイスのコンフィギュレーションファイルで確認できますが、次のフィールドには、特定の展開の重要な値が示されます。

- <first-csr-tunnel-ID>：このトンネルに割り当てる一意のトンネル ID です。

- <first-csr-ip-address>：最初の CSR の 3 番目のネットワーク インターフェイスのパブリック IP アドレスです。

トンネルの宛先は、アンダーレイ接続のタイプによって異なります。

- アンダーレイがパブリック インターネット経由の場合、トンネルの宛先はクラウド ルータ インターフェイスのパブリック IP です。

- アンダーレイがプライベート接続（AWS の DX や Azure の ER など）を介している場合、トンネルの宛先はクラウド ルータ インターフェイスのプライベート IP です。

- <first-csr-preshared-key>：最初の CSR の事前共有キーです。

- <onprem-device-interface>：Amazon Web Services に展開された Cisco Cloud サービス ルータ 1000V への接続に使用されるインターフェイスです。

- <onprem-device-ip-address>：Amazon Web Services に展開された Cisco Cloud サービス ルータ 1000V への接続に使用される、<interface> インターフェイスの IP アドレスです。

- <peer-tunnel-for-onprem-IPsec-to-first-CSR>：最初のクラウド CSR に対してオンプレミスの IPsec デバイスのピア トンネル IP アドレスとして使用されます。

- <process-id> ：OSPF プロセス ID です。

- <area-id>：OSPF エリア ID です。

次の例は、Nexus Dashboard Orchestrator リリース 3.3(1) および Cloud APIC リリース 5.2(1) 以降でサポートされている IKEv2 プロトコルを使用したサイト間接続設定を示しています。IKEv1 を使用している場合は、NDO からダウンロードした IPN 設定ファイルの外観が若干異なる場合がありますが、原則は同じです。

crypto ikev2 proposal ikev2-proposal-default
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha512 sha384 sha256 sha1
group 24 21 20 19 16 15 14 2
exit

crypto ikev2 policy ikev2-policy-default
proposal ikev2-proposal-default
exit

crypto ikev2 keyring key-ikev2-infra:overlay-1-<first-csr-tunnel-id>
peer peer-ikev2-keyring
address <first-csr-ip-address>
pre-shared-key <first-csr-preshared-key>
exit
exit

crypto ikev2 profile ikev2-infra:overlay-1-<first-csr-tunnel-id>
match address local interface <onprem-device-interface>
match identity remote address <first-csr-ip-address> 255.255.255.255
identity local address <onprem-device-ip-address>
authentication remote pre-share
authentication local pre-share
keyring local key-ikev2-infra:overlay-1-<first-csr-tunnel-id>
lifetime 3600
dpd 10 5 on-demand
exit

crypto ipsec transform-set infra:overlay-1-<first-csr-tunnel-id> esp-gcm 256
mode tunnel
exit

crypto ipsec profile infra:overlay-1-<first-csr-tunnel-id>
set pfs group14
set ikev2-profile ikev2-infra:overlay-1-<first-csr-tunnel-id>
set transform-set infra:overlay-1-<first-csr-tunnel-id>
exit

interface tunnel 2001
ip address <peer-tunnel-for-onprem-IPsec-to-first-CSR> 255.255.255.252
ip virtual-reassembly
tunnel source <onprem-device-interface>
tunnel destination <first-csr-ip-address>
tunnel mode ipsec ipv4
tunnel protection ipsec profile infra:overlay-1-<first-csr-tunnel-id>
ip mtu 1400
ip tcp adjust-mss 1400
ip ospf <process-id> area <area-id>
no shut
exit

例:

crypto ikev2 proposal ikev2-proposal-default
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha512 sha384 sha256 sha1
group 24 21 20 19 16 15 14 2
exit

crypto ikev2 policy ikev2-policy-default
proposal ikev2-proposal-default
exit

crypto ikev2 keyring key-ikev2-infra:overlay-1-2001
peer peer-ikev2-keyring
address 52.12.232.0
pre-shared-key 1449047253219022866513892194096727146110
exit
exit

crypto ikev2 profile ikev2-infra:overlay-1-2001
! Please change GigabitEthernet1 to the appropriate interface
match address local interface GigabitEthernet1
match identity remote address 52.12.232.0 255.255.255.255
identity local address 128.107.72.62
authentication remote pre-share
authentication local pre-share
keyring local key-ikev2-infra:overlay-1-2001
lifetime 3600
dpd 10 5 on-demand
exit

crypto ipsec transform-set infra:overlay-1-2001 esp-gcm 256
mode tunnel
exit

crypto ipsec profile infra:overlay-1-2001
set pfs group14
set ikev2-profile ikev2-infra:overlay-1-2001
set transform-set infra:overlay-1-2001
exit

! These tunnel interfaces establish point-to-point connectivity between the on-prem device and the cloud Routers
! The destination of the tunnel depends on the type of underlay connectivity:
! 1) The destination of the tunnel is the public IP of the cloud Router interface if the underlay is via internet
! 2) The destination of the tunnel is the private IP of the cloud Router interface if the underlay is via private
connectivity like DX on AWS or ER on Azure

interface tunnel 2001
ip address 5.5.1.26 255.255.255.252
ip virtual-reassembly
! Please change GigabitEthernet1 to the appropriate interface
tunnel source GigabitEthernet1
tunnel destination 52.12.232.0
tunnel mode ipsec ipv4
tunnel protection ipsec profile infra:overlay-1-2001
ip mtu 1400
ip tcp adjust-mss 1400
! Please update process ID according with your configuration
ip ospf 1 area 0.0.0.1
no shut
exit

ステップ 4

2 番目、および設定する必要があるその他の CSR について、これらの手順を繰り返します。

ステップ 5

オンプレミスの IPsec デバイスでトンネルがアップしていることを確認します。

現在のステータスを表示するには、次のコマンドを使用します。両方のトンネルがアップとして表示されていない場合は、この項の手順で入力した情報を確認して、問題が発生している可能性がある場所を確認します。両方のトンネルがアップとして表示されるまで、次のセクションに進まないでください。

ISN_CSR# show ip interface brief | include Tunnel
Interface              IP-Address      OK? Method Status                Protocol
Tunnel1000             30.29.1.2         YES manual up                    up
Tunnel1001             30.29.1.4         YES manual up                    up

Chapter17. CloudSec 暗号化

- Cisco ACI CloudSec 暗号化

- 要件と注意事項

- CloudSec 暗号化に関する用語

- CloudSec の暗号化と復号の処理

- CloudSec 暗号化キーの割り当てと配布

- CloudSec 暗号化の Cisco APIC の設定

- Nexus Dashboard Orchestrator GUI を使用した CloudSec 暗号の有効化

- スパイン スイッチ メンテナンス中のキー再生成プロセス

Cisco ACI CloudSec 暗号化

ほとんどの Cisco ACI 展開で、ディザスタリカバリとスケーリングに対処する Multi-Site アーキテクチャを採用しているため、ローカル サイト内で MACsec 暗号化を使用する現在のセキュリティ実装は、複数のサイトにわたるデータセキュリティと整合性を保証するには不十分になっています。それらのサイトは、安全でない外部 IP ネットワークによって接続されており、個別のファブリックを相互接続しているからです。Nexus Dashboard Orchestrator リリース 2.0(1) は、トラフィックのサイト間暗号化を提供するために設計された CloudSec 暗号化を導入しています。

Multi-Site トポロジはサイト間の接続を提供するために、3 つのトンネル エンドポイント (TEP) IP アドレスを使用します。これらの TEP アドレスは、 Nexus Dashboard Orchestrator の管理者により設定され、各サイトの Cisco APIC にプッシュ ダウンされ、その後スパイン スイッチで設定されます。これらの 3 つのアドレスは、トラフィックがリモートサイトに送信されるタイミングを決定するために使用されます。この場合、2 つのスパイン スイッチ間に暗号化された CloudSec トンネルが作成され、サイト間ネットワーク (ISN) を介して 2 つのサイト間の物理接続が提供されます。

次の図は、ローカル サイト トラフィックの MACsec とサイト間トラフィックの暗号化に CloudSec を組み合わせた全体的な暗号化アプローチを示しています。

CloudSec 暗号化

要件と注意事項

CloudSec 暗号化を設定する場合は、次の注意事項が適用されます。

- CloudSec は、Nexus 9000 サイト間ネットワーク（ISN）インフラストラクチャを使用して検証されています。ISN インフラストラクチャがさまざまなデバイスで構成されている場合、またはデバイスが不明な場合（サービス プロバイダーから購入した回線の場合など）、ASR1K ルーターは、ACI スパイン、または Nexus 9000 ISN ネットワークに直接接続するファースト ホップ デバイスである必要があります。パディング フィックスアップが有効になっている ASR1K ルーターにより、CloudSec トラフィックはサイト間の任意の IP ネットワークを通過できます。

ASR1K ルーターを構成するには：

1. デバイスにログインします。

2. UDP ポートを構成します。

ASR1K(config)# platform cloudsec padding-fixup dst-udp-port 9999

3. 設定を確認します。

ASR1K# show platform software ip rp active cloudsec
CloudSec Debug: disabled
CloudSec UDP destination port: enabled
1st UDP destination port: 9999
2nd UDP destination port: 0
3rd UDP destination port: 0

ASR1K# show platform software ip fp active cloudsec
CloudSec Debug: disabled
CloudSec UDP destination port: enabled
1st UDP destination port: 9999
2nd UDP destination port: 0
3rd UDP destination port: 0

- CloudSec 暗号化を無効にしようとしたときに 1 つ以上のスパインスイッチがダウンした場合、スイッチがアップするまで、これらのスイッチでディセーブルプロセスは完了しません。これにより、スイッチが再起動したときにパケットがドロップされることがあります。

CloudSec 暗号化を有効または無効にする前に、ファブリック内のすべてのスパインスイッチが稼働していること、または完全に停止していることを確認することを推奨します。

- CloudSec 暗号化機能は、次の機能ではサポートされません。

- 高精度時間プロトコル（PTP）

- リモート リーフ ダイレクト

- 仮想ポッド（vPod）

- SDA

- サイト内 L3Out

- その他のルーティング可能な TEP 設定

要件

CloudSec 暗号化機能では、次のものが必要です。

- Cisco ACI スパイン/リーフアーキテクチャと 1 台の Cisco APIC クラスタ（各サイト用）

- 各サイトを管理する Cisco Nexus Dashboard Orchestrator

- ファブリックのデバイス（リーフのみ）ごとに 1 つの Advantage または Premier ライセンス

- デバイスが固定スパインである場合には、暗号化のため、デバイスごとに 1 つの ACI-SEC-XF アドオン ライセンス

- デバイスがモジュール スパインである場合には、暗号化のため、デバイスごとに 1 つの ACI-SEC-XM アドオン ライセンス

次の表に、CloudSec 暗号化に対応したハードウェア プラットフォームとポート範囲を示します。

ハードウェア プラットフォーム

ポート範囲

N9K C9364C スパインスイッチ

ポート 49-64

N9K-C9332C スパインスイッチ

ポート 25-32

N9K-X9736C-FX ラインカード

ポート 29-36

CloudSec がサイトに対して有効になっているが、暗号化がポートでサポートされていない場合、サポートされていないインターフェイスのエラーメッセージで障害が発生します。

CloudSec 暗号化のパケット カプセル化は、DWDM-C SFP10G などの Cisco QSFP から SFP へのアダプタ (QSA) がサポートされている光ファイバで使用されている場合にサポートされます。サポートされている光ファイバの完全なリストは、https://www.cisco.com/c/en/us/support/interfaces-modules/transceiver-modules/products-device-support-tables-list.html のリンクから入手できます。

CloudSec 暗号化に関する用語

CloudSec 暗号化機能は、サイト間の初期キーとキー再生成の要件に対して、安全なアップストリーム対称キーの割り当てと配布方法を提供します。この章では、次の用語を使用します。

- アップストリーム デバイス – CloudSec 暗号化ヘッダーを追加し、ローカルで生成された対称暗号化キーを使用してリモート サイトへの送信時に VXLAN パケット ペイロードの暗号化を行うデバイス。

- ダウンストリーム デバイス – CloudSec 暗号化ヘッダーを解釈し、リモート サイトで生成された暗号化キーを使用して受信時に VXLAN パケットペイロードの復号化を行うデバイス。

- アップストリーム サイト – 暗号化された VXLAN パケットを発信するデータセンター ファブリック。

- ダウンストリーム サイト – 暗号化されたパケットを受信して復号するデータセンター ファブリック。

- TX キー – クリアな VXLAN パケット ペイロードを暗号化するために使用される暗号化キー。ACI では、1 つの TX キーがすべてのリモート サイトに対してアクティブであることができます。

- RX キー – 暗号化された VXLAN パケット ペイロードを復号するために使用される暗号化キー。ACI では、2 つの RX キーをリモート サイトごとにアクティブにできます。

2 つの RX キーをキーの再生成プロセス中に同時にアクティブにすることができます。ダウンストリームサイトは、新しいキーの展開が一定期間終了した後、古い RX キーと新しい RX キーを保持し、いずれかのキーを適切に復号することで、順序どおりでないパケット配信が可能になるようにします。

- 対象キー – 同じ暗号化キーを使用して、アップストリーム デバイスとダウンストリーム デバイスによるパケットストリームの暗号化 (TX キー) と復号 (RX キー) をそれぞれ行う場合。

- キーの再生成 – 古いキーの有効期限が切れた後、すべてのダウンストリーム サイトの古いキーを新しいキーに置き換えるためにアップストリーム サイトによって開始されたプロセス。

- 安全なチャネル識別子 (SCI) – サイト間のセキュリティ関連付けを表す 64 ビット識別子。CloudSec ヘッダーの暗号化されたパケットで送信され、パケットの復号化のためにダウンストリームデバイスの RX キーを取得するために使用されます。

- アソシエーション番号値 (AN) – 暗号化されたパケットのCloudSecヘッダーで送信される2ビットの数値( 0, 1, 2, 3)。これは、復号化のために SCI とともにダウンストリームデバイスでキーを導出するために使用されます。これにより、ダウンストリーム デバイスで複数のキーをアクティブにして、キーの再生成操作の後で、同じアップストリーム デバイスからの異なるキーを使用したパケットの順序どおりでない到着を処理できます。

ACI では、2 つのアクティブな RX キーには 2 つのアソシエーション番号値（0 または 1 1）のみが使用され、TX キーには常に 1 つのアソシエーション番号値（0 または 1）のみが使用されます。

- 事前共有キー (PSK) – CloudSec TX および RX キーを生成するためのランダム シードとして使用するには、Cisco APIC GUI で 1 つ以上のキーを設定する必要があります。複数の PSK が設定される場合、各キーの再生成プロセスはインデックスの順序で次の PSK を使用します。さらに高いインデックスの PSK がない場合、最下位のインデックスの PSK が使用されます。各 PSK は、64文字の長さの16進数ストリングでなければなりません。Cisco APIC は最大256の事前共有キーをサポートします。

CloudSec の暗号化と復号の処理

リリース 2.0(1) 以降では、データ セキュリティと整合性の両方に対応する、完全に統合されたシンプルでコスト効率の高いソリューションを提供するために、Multi-Site は Multi-Site ファブリック間の送信元から宛先への完全なパケット暗号化を可能にする CloudSec 暗号化機能を提供します。

次の図は、CloudSec カプセル化の前後のパケット ダイアグラムと、その後の暗号化および復号化プロセスの説明を示しています。

CloudSec パケット

パケット暗号化

次に、CloudSec が発信トラフィック パケットを処理する方法の概要を示します。

- パケットは、外部 IP ヘッダーとレイヤ 4 宛先ポート情報を使用してフィルタ処理され、一致するパケットは暗号化の対象としてマークされます。

- 暗号化に使用するオフセットは、パケットのフィールドに基づいて計算されます。たとえば、オフセットは、802.1q VLAN があるかどうか、またはパケットが IPv4 または IPv6 パケットであるかどうかによって異なります。

- 暗号キーはハードウェア テーブルでプログラムされ、パケット IP ヘッダーを使用してテーブルから検索されます。

パケットに暗号化のマークが付けられると、暗号キーがロードされ、暗号化を開始するパケットの先頭からのオフセットが判明すると、次の追加の手順が実行されます。

- UDP 宛先ポート番号は、UDP ヘッダーから CloudSec フィールドにコピーされ、パケットが暗号解読されるときにリカバリされます。

- UDP 宛先ポート番号は、CloudSec パケットであることを示すシスコ独自のレイヤ 4 ポート番号 (ポート 9999) で上書きされます。

- [UDP 長(UDP length)] フィールドは、追加されるバイト数を反映するように更新されます。

- CloudSec ヘッダーは、UDP ヘッダーの後に直接挿入されます。

- 整合性チェック値 (ICV) は、ペイロードと CRC の間のパケットの最後に挿入されます。

- ICV では、128 ビットの初期化ベクトルを構築する必要があります。CloudSec の場合、ICV のために送信元 MAC アドレスを使用すると、SCI ごとのプログラム可能な値に置き換えられます。

- CRC は、パケットのコンテンツの変更を反映するように更新されます。

パケットの暗号解読

CloudSec が受信パケットを処理する方法は、上記で説明した発信パケット アルゴリズムと対称的です。

- 受信したパケットが CloudSec パケットである場合は、暗号解読され、ICV が検証されます。

ICV 検証に合格すると、追加フィールドが削除され、UDP 宛先ポート番号が CloudSec ヘッダーから UDP ヘッダーに移動され、CRC が更新され、パケットの暗号解読と CloudSec ヘッダーの削除後に宛先に転送されます。そうでない場合、パケットはドロップされます。

- キー ストアが2つ以上の可能な暗号解読キーを返す場合、CloudSec ヘッダーの Association Number (AN) フィールドを使用して、使用するキーを選択します。

- パケットが CloudSec パケットでない場合、パケットはそのまま残ります。

CloudSec 暗号化キーの割り当てと配布

初期キー構成

CloudSec キーの配布

次に、上記の図に示されている CloudSec 暗号キーの初期割り当ておよび配信プロセスの概要を示します。

- アップストリーム サイトの Cisco APIC は、サイトから送信された VXLAN パケットのデータ暗号化に使用されるためのローカル対称キーを生成します。アップストリーム サイトが暗号化に使用するのと同じキーが、ダウンストリーム リモート受信サイトのパケットの復号に使用されます。

各サイトはほかのサイトに送信するトラフィックのためのアップストリーム サイトです。複数のサイトが存在する場合、各サイトは独自のサイトツーサイトキーを生成し、そのキーを暗号化に使用してからリモートサイトに送信します。

- 生成された対称キーは、ダウンストリーム リモート サイトに配布するために、アップストリーム サイトの Cisco APIC によって Nexus Dashboard Orchestrator (NDO) にプッシュされます。

- NDO はメッセージ ブローカとして機能し、生成された対称キーをアップストリーム サイトの Cisco APIC から収集し、それをダウンストリーム リモート サイトの Cisco APIC に配布します。

- 各ダウンストリーム サイトの Cisco APIC は、受信したキーを、キーを生成したアップストリーム サイトからのトラフィックを受信することを目的としたローカル スパイン スイッチの RX キーとして設定します。

- 各ダウンストリーム サイトの Cisco APIC は、ローカル スパイン スイッチから RX キーの展開ステータスを収集し、NDO にプッシュします。

- NDO は、すべてのダウンストリーム リモート サイトからアップストリーム サイトの Cisco APIC に戻って、主要な展開ステータスを中継します。

- アップストリームサイトはCisco APIC 、すべてのダウンストリーム リモート サイトから受信したキー展開ステータスが成功したかどうかを確認します。

- ダウンストリーム デバイスから受信した展開ステータスが成功した場合、アップストリーム サイトはスパイン スイッチの TX キーとしてローカル対称キーを展開し、ダウンストリーム サイトに送信される VXLAN パケットの暗号化を有効にします。

- ダウンストリーム デバイスから受け取った展開ステータスが失敗した場合、失敗した Cisco APIC サイトで障害が発生し、NDO で構成された「セキュア モード」設定に基づいて処理されます。「セキュアが必須 (must secure)」モードでは、パケットはドロップされ、「セキュアであるべき (should secure)」モードでは、パケットは宛先サイトに平文 (暗号化されていない) で送信されます。

（注）

現在のリリースでは、モードは常に「セキュアであるべき (should secure)」に設定されており、変更できません。

キー再生成プロセス

生成された各 TX / RX キーは、設定された時間が経過すると有効期限が切れます。デフォルトでは、キーの有効期限は 15 分に設定されています。TX/RX キーの初期セットが期限切れになると、キー再生成プロセスが行われます。

キーの再割り当てプロセスには、同じ一般的なキーの割り当てと配布フローが適用されます。キー再生成プロセスは「ブレーク前に作成 (make before break)」ルールに従います。つまり、新しい TX キーがアップストリーム サイトに展開される前に、ダウンストリーム サイトのすべての RX キーが展開されます。これを実現するために、アップストリーム サイトは、ローカル アップストリーム サイトのデバイスに新しい TX キーを構成する前に、ダウンストリーム サイトからの新しい RX キーの展開ステータスを待ちます。

ダウンストリーム サイトが新しい RX キーの展開で障害ステータスを報告した場合、キー再生成プロセスは終了し、古いキーはアクティブなままになります。ダウンストリームサイトは、新しいキーの展開が一定期間終了した後、古い RX キーと新しい RX キーを保持し、いずれかのキーを適切に復号することで、順序どおりでないパケット配信が可能になるようにします。

（注）

スパイン スイッチのメンテナンス中のキー再生成プロセスに関しては、特別な注意が必要です。詳細については、スパイン スイッチ メンテナンス中のキー再生成プロセス を参照してください。

キー再生成プロセスの失敗

ダウンストリーム サイトがキー再生成プロセスによって生成された新しい暗号化キーの展開に失敗した場合、新しいキーは破棄され、アップストリーム デバイスは以前の有効なキーを TX キーとして引き続き使用します。このアプローチにより、アップストリーム サイトは、ダウンストリーム サイトのセットごとに複数の TX キーを維持する必要がなくなります。ただし、このアプローチでは、いずれかのダウンストリーム サイトでキー再生成の展開エラーが発生し続ける場合、キー更新プロセスが遅延する可能性もあります。マルチサイト管理者は、キー再生成を成功させるために、キーの展開の失敗の問題を修正するための行動を取ることが期待されています。

Cisco APICキー管理のロール

Cisco APIC は、キー割り当て (初期キーとキー再配布の両方)、スパイン スイッチからのキー展開ステータス メッセージの収集、および他のサイトへの配布のための各キーのステータスに関する Nexus Dashboard Orchestrator への通知に責任をもちます。

キー管理における Nexus Dashboard Orchestrator の役割

Nexus Dashboard Orchestrator は、アップストリーム サイトから TX キー（初期キーと後続のキーの再生成の両方）を収集し、RX キーとして展開するためにすべてのダウンストリーム サイトに配布します。NDO はまた、ダウンストリーム サイトから RX キーの展開ステータス情報を収集し、成功した RX キー展開ステータスで TX キーを更新するために、アップストリーム サイトに通知します。

アップストリーム モデル

MPLS など、ダウンストリーム キー割り当てを使用する他のテクノロジーとは対照的に、CloudSec のアップストリーム モデルには次の利点があります。

- このモデルはシンプルで、運用とネットワークへの導入が容易です。

- モデルは、マルチサイトのユース ケースに適しています。

- 複数の宛先サイトに送信される複製パケットの各コピーに同じキーと CloudSec ヘッダーを使用できるため、マルチキャスト トラフィックに利点があります。ダウンストリーム モデルでは、各コピーは暗号化中にサイトごとに異なるセキュリティ キーを使用する必要があります。

- 障害が発生した場合のトラブルシューティングが容易になり、複製されたユニキャスト パケットとマルチキャスト パケットの両方に対して、送信元から宛先へのパケットのトレーサビリティが一貫して向上します。

CloudSec 暗号化の Cisco APIC の設定

CloudSec 暗号と復号キーを生成するために、Cisco APIC で使用する 1 個以上の事前共有キー (PSK) を設定する必要があります。PSK は再キー プロセス中のランダム シードとして使用されます。複数の PSK が設定される場合、各再キー プロセスはインデックスの順序で次の PSK を使用します。さらに高いインデックスの PSK がない場合、最下位のインデックスの PSK が使用されます。

暗号キーの生成に対するシードとして PSK が使用されるため、複数の PSK の設定では生成された暗号キーの長時間にわたる脆弱性を下げることにより、追加のセキュリティを提供します。

（注）

Cisco APIC で事前共有キーが設定されていない場合、CloudSec はそのサイトに対して有効にはなりません。その場合、マルチサイトで CloudSec 設定をオンにすると、障害が生じます。

いつでも新しい PSK で前に追加した PSK を更新したい場合、新しいキーを追加するときと同様の手順を繰り返すだけですが、インデックスは既存のものを指定してください。

1 つ以上の事前共有キーを次の 3 通りの方法のいずれかを使用して設定できます。

- GUI を使用した CloudSec 暗号化の Cisco APIC の設定 の説明に従って、Cisco APIC GUI を使用する

- NX-OS Style CLI を使用した CloudSec 暗号化に対する Cisco APIC の設定 の説明に従って、Cisco APIC NX-OS Style CLI を使用する

- REST API を使用した CloudSec 暗号化の Cisco APIC の設定 の説明に従って、Cisco APIC REST API を使用する

- GUI を使用した CloudSec 暗号化の Cisco APIC の設定

- NX-OS Style CLI を使用した CloudSec 暗号化に対する Cisco APIC の設定

- REST API を使用した CloudSec 暗号化の Cisco APIC の設定

GUI を使用した CloudSec 暗号化の Cisco APIC の設定

このセクションは、Cisco APIC GUI を使用して 1 つ以上の事前共有キー (PSK) を設定する方法について説明します。

手順

ステップ 1

APIC にログインします。

ステップ 2

[テナント] > [インフラ] > [ポリシー] > [CloudSec 暗号化]に移動します。

ステップ 3

SA キーの有効期限を指定します。

このオプションは、各キーが有効な時間 (分) を指定します。それぞれの生成された TX/RX キーは、再キー プロセスをトリガした後指定の時間で期限切れになります。期限の時間は、5～1440 分の範囲で入力できます。

ステップ 4

[事前共有キー]テーブルの + アイコンをクリックします。

ステップ 5

追加する事前共有キーのインデックスを指定し、その後、事前共有キー自体を指定します。

[インデックス (Index)] フィールドは、事前共有キーを使用する順序を指定します。最後 (最高位のインデックス) キーが使用された後で、プロセスは最初 (最下位のインデックス) キーで続けられます。Cisco APIC は最大 256 個の事前共有キーをサポートするので、PSK インデックスチは 1 ～ 256 でなければなりません。

各事前共有キーは、64 文字の 16 進数文字列である必要があります。

NX-OS Style CLI を使用した CloudSec 暗号化に対する Cisco APIC の設定

このセクションでは、 Cisco APIC NX OS Style CLI を使用して1つ以上の事前共有キー (PSK) を設定する方法について説明します。

手順

ステップ 1

Cisco APIC NX-OS style CLI にログインします。

ステップ 2

コンフィギュレーション モードを入力します。

例:

apic1# configure
apic1 (config)#

ステップ 3

デフォルト CloudSec プロファイルのコンフィグレーション モードを入力します。

例:

apic1(config)# template cloudsec default
apic1(config-cloudsec)#

ステップ 4

事前共有キー (PSK) の有効期限を指定します。

このオプションは、各キーが有効な時間 (分) を指定します。それぞれの生成された TX/RX キーは、再キー プロセスをトリガした後指定の時間で期限切れになります。期限の時間は、5～1440 分の範囲で入力できます。

例:

apic1(config-cloudsec)# sakexpirytime <duration>

ステップ 5

1 つまたは複数の事前共有キーを指定します。

次のコマンドでは、設定している PSK のインデックスと PSK 文字列自体を指定します。

例:

apic1(config-cloudsec)# pskindex <psk-index>
apic1(config-cloudsec)# pskstring <psk-string>

<psk-index> パラメータは、事前共有キーが使用される順序を指定します。最後 (最上位のインデックス) キーが使用された後で、プロセスは最初 (最下位のインデックス) キーで続けられます。Cisco APIC は最大 256 個の事前共有キーをサポートするので、PSK インデックスチは 1 ～ 256 でなければなりません。

<psk-string>パラメータは、実際の PSK を指定します。これは、64 文字の 16 進数文字列である必要があります。

ステップ 6

(オプション) 現在の PSK 設定を表示します。

現在設定されている PSK の数とその期間を表示するには、次のコマンドを使用します。

例:

apic1(config-cloudsec)# show cloudsec summary

REST API を使用した CloudSec 暗号化の Cisco APIC の設定

このセクションは、Cisco APIC REST API を使用して 1 つ以上の事前共有キー (PSK) を設定する方法について説明します。

手順

PSK 有効期限、インデックス、文字列を設定します。

次の XML POST で、次を置換します。

- 各 PSK の期限をもつ sakExpiryTime の値。

この sakExpiryTime パラメータは各キーが有効な時間 (分) を指定します。それぞれの生成された TX/RX キーは、再キー プロセスをトリガした後指定の時間で期限切れになります。期限の時間は、5～1440 分の範囲で入力できます。

- 設定している PSK のインデックスをもつ インデックス の値。

インデックス パラメータは、事前共有キーが使用される順序を指定します。最後 (最高位のインデックス) キーが使用された後で、プロセスは最初 (最下位のインデックス) キーで続けられます。Cisco APIC は最大 256 個の事前共有キーをサポートするので、PSK インデックスチは 1 ～ 256 でなければなりません。

- 設定している PSK のインデックスをもつ pskString の値。

pskString パラメータは実際の PSK を指定します。これは 16 進文字列で長さ 64 文字でなければなりません。

例:

<fvTenant annotation="" descr="" dn="uni/tn-infra" name="infra" nameAlias="" ownerKey="" ownerTag="">
<cloudsecIfPol descr="cloudsecifp" name="default" sakExpiryTime="10" stopRekey= "false" status="" >
<cloudsecPreSharedKey index="1" pskString="1234567812345678123456781234567812345678123456781234567812345678" status=""/>
</cloudsecIfPol>
</fvTenant>

Nexus Dashboard Orchestrator GUI を使用した CloudSec 暗号の有効化

CloudSec 暗号化は、サイトごとに個別に有効または無効にすることができます。ただし、2 つのサイト間の通信は、この機能が両方のサイトで有効になっている場合にのみ暗号化されます。

始める前に

2 つ以上のサイト間で CloudSec 暗号化を有効にする前に、次のタスクを完了しておく必要があります。

- 『Cisco APIC のインストール、アップグレード、ダウングレード ガイド』で説明されているように、複数のサイトに Cisco APIC クラスタをインストールして設定します。

- 『Cisco Nexus Dashboard Orchestrator インストレーションおよびアップグレード ガイド』の説明に従って、Nexus Dashboard Orchestrator をインストールし、設定します。

- 『Cisco ACI マルチサイト コンフィギュレーション ガイド』の説明に従って、各 Cisco APIC サイトを Nexus Dashboard Orchestrator に追加します。

手順

ステップ 1

Nexus Dashboard Orchestrator にログインします。

ステップ 2

左側のサイドバーから、[サイト (Sites)] ビューを選択します。

ステップ 3

メインウィンドウの右上にある [Infra の構成] ボタンをクリックします。

ステップ 4

左側のサイドバーから、CloudSec 設定を変更するサイトを選択します。

ステップ 5

右側のサイドバーで、[Cloudsec 暗号化 (Cloudsec encryption)] 設定を切り替えて、サイトの CloudSec 暗号化機能を有効または無効にします。

スパイン スイッチ メンテナンス中のキー再生成プロセス

次に、この機能が有効になっているスパイン スイッチの一般的なメンテナンス シナリオでの CloudSec キー再生成プロセスの概要を示します。

- 通常の解放: CloudSec 対応スパイン スイッチがデコミッションされると、 CloudSec キー再生成プロセスが自動的に停止します。解放されたノードが再起動されるか、解放されたノード ID が次から削除されるまで、キー再生成プロセスは再度開始されません: Cisco APIC

- スパイン スイッチのソフトウェア アップグレード: スパイン スイッチがソフトウェアのアップグレードによりリロードされると、CloudSec キー再生成プロセスは自動的に停止します。キー再生成プロセスは、スパイン スイッチのリロードが完了すると、再開されます。

- メンテナンス (GIR モード) : CloudSec キー再生成プロセスは、NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にするに記載されている手順を使用して、手動で停止する必要があります。キー再生成は、ノードがトラフィックを転送する準備が再度整った後にのみ、有効にできます。

- Cisco APICからの解放と削除 : CloudSec キー再生プロセスは、NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にする に記載されている手順を使用して、手動で停止する必要があります。キー再生成は、Cisco APIC からノードが削除された後にのみ有効にできます。

- NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にする

- REST API を使用したキー再生成プロセスの無効化と再有効化

NX-OS Style CLI を使用してキーの再生成プロセスを無効にして再度有効にする

キーの再生成プロセスを手動で停止し再開することが可能です。特定の状況でキーの再生成プロセスを手動で管理することが必要な場合があります。たとえば、でコミッションとメンテナンスの切り替えなどです。このセクションは、 Cisco APIC NX-OS Style CLI を使用して設定を切り替える方法を説明します。

手順

ステップ 1

Cisco APIC NX-OS style CLI にログインします。

ステップ 2

コンフィギュレーション モードを入力します。

例:

apic1# configure
apic1(config)#

ステップ 3

デフォルト CloudSec プロファイルのコンフィグレーション モードを入力します。

例:

apic1(config)# template cloudsec default
apic1(config-cloudsec)#

ステップ 4

キーの再生成プロセスを停止するか、再開します。

キーの再生成を停止するには:

例:

apic1(config-cloudsec)# stoprekey yes

キーの再生成プロセスを再開するには:

例:

apic1(config-cloudsec)# stoprekey no

REST API を使用したキー再生成プロセスの無効化と再有効化

キーの再生成プロセスを手動で停止し再開することが可能です。特定の状況でキーの再生成プロセスを手動で管理することが必要な場合があります。たとえば、でコミッションとメンテナンスの切り替えなどです。このセクションでは、Cisco APICREST API を使用して設定を切り替える方法について説明します。

手順

ステップ 1

キー再生成プロセスは、次のXML メッセージを使用して無効にすることができます。

例:

<fvTenant annotation="" descr="" dn="uni/tn-infra" name="infra" nameAlias="" ownerKey="" ownerTag="">
<cloudsecIfPol descr="cloudsecifp" name="default" sakExpiryTime="10" stopRekey= "true" status="" />
</fvTenant>

ステップ 2

キー再生成プロセスは、次のXML メッセージを使用して有効にすることができます。

例:

<fvTenant annotation="" descr="" dn="uni/tn-infra" name="infra" nameAlias="" ownerKey="" ownerTag="">
<cloudsecIfPol descr="cloudsecifp" name="default" sakExpiryTime="10" stopRekey= "false" status="" />
</fvTenant>

PartIV. 機能と使用例

- DHCPリレー

- サイト間 L3Out

- PBR を使用したサイト間 L3Out

- レイヤ 3 マルチキャスト

- EPG 優先グループ

- IPN 全体での QoS の保持

- SD-WAN の統合

- SR-MPLS 経由で接続されたサイト

- vzAny コントラクト

Chapter18. DHCPリレー

- DHCP リレー ポリシー

- 注意事項と制約事項

- DHCP リレー ポリシーの作成

- DHCP オプション ポリシーの作成

- DHCP ポリシーの割り当て

- DHCP リレー コントラクトの作成

- APIC での DHCP リレー ポリシーの確認

- 既存の DHCP ポリシーの編集または削除

DHCP リレー ポリシー

通常、DHCP サーバが EPG の下に配置されている場合、その EPG 内のすべてのエンドポイントがアクセス権を持ち、DHCP を介して IP アドレスを取得できます。ただし、多くの導入シナリオでは、DHCP サーバが必要なすべてのクライアントと同じ EPG、BD、または VRF に存在していない可能性があります。このような場合、1つの EPG 内のエンドポイントが別のサイトに配置された別の EPG/BD にあるサーバから、またはファブリックに外部に接続され、L3Out 接続を介して到達可能なサーバから IP アドレスを取得できるように、DHCP リレーを設定できます。

Orchestrator GUI で DHCP リレー ポリシーを作成してリレーを設定できます。また、DHCP オプション ポリシーを作成して、特定の設定の詳細を提供するためにリレーポリシーで使用できる追加オプションを設定することもできます。使用可能なすべての DHCP オプションについては、 RFC 2132 を参照してください。

DHCP リレーポリシーを作成する場合は、DHCP サーバが存在する EPG (たとえば、 epg1) または外部 EPG (たとえば、ext epg1) を指定します。DHCP ポリシーを作成した後、それをブリッジドメインに関連付けます。これにより、その EPG 内のエンドポイントが DHCP サーバに到達できるようになります。これにより、別の EPG (たとえば、epg2) に関連付けられます。最後に、リレー EPG (epg1またはepg1) とアプリケーション EPG (epg2) 間の契約を作成し、通信を可能にします。作成した DHCP ポリシーは、ポリシーが関連付けられているブリッジ ドメインがサイトに展開されるときに、APIC にプッシュされます。

注意事項と制約事項

DHCP リレーポリシーは、次の警告でサポートされます。

- DHCP リレーポリシーは、Cisco APIC リリース 4.2(1) 以降を実行しているファブリックでサポートされています。

- DHCP サーバは、DHCP リレー エージェント情報オプション (オプション 82) をサポートしている必要があります。

ACI ファブリックが DHCP リレーとして動作する場合、DHCP リレーエージェント情報オプションは、クライアントの代わりにプロキシする DHCP 要求に挿入されます。応答（DHCP オファー）がオプション 82 なしで DHCP サーバから返された場合、その応答はファブリックによってサイレントにドロップされます。

- DHCP リレー ポリシーは、ユーザ テナントまたは共通テナントでのみサポートされます。DHCP ポリシーは、インフラまたは管理テナントではサポートされていません。

ACI ファブリックで共有リソースとサービスを設定する場合は、共通テナントでこれらのリソースを作成することをお勧めします。これは、どのユーザ テナントでも使用できます。

- DHCP リレー サーバは、DHCP クライアントまたは共通テナントと同じユーザ テナントに存在する必要があります。

サーバとクライアントは、異なるユーザ テナントに配置することはできません。

- DHCP リレー ポリシーは、プライマリ SVI インターフェイスにのみ設定できます。

リレー ポリシーを割り当てるブリッジ ドメインに複数のサブネットが含まれている場合、追加した最初のサブネットは SVI インターフェイスのプライマリ IP アドレスになりますが、追加のサブネットはセカンダリ IP アドレスとして設定されます。複数のサブネットを持つブリッジ ドメインを使用した設定のインポートなどの特定のシナリオでは、SVI のプライマリ アドレスがセカンダリ アドレスの1つに変更されることがあり、そのブリッジ ドメインの DHCP リレーが中断されることがあります。

Show ip interface vrf allコマンドを使用して、SVI インターフェイスの IP アドレスの割り当てを確認できます。

- ブリッジドメインに割り当てた後に DHCP ポリシーを変更し、ブリッジ ドメインを 1 つ以上のサイトに展開した場合は、各サイトの APIC で DHCP ポリシーの変更を更新するために、ブリッジ ドメインを再展開する必要があります。

- L3Out 経由で到達可能な DHCP サーバとの VRF 間 DHCP リレーの場合、DHCP リレー パケットは、DHCP サーバに到達するためにサイト ローカル L3Out を使用する必要があります。異なるサイト (サイト間 L3Out) の L3Out を使用するパケットはサポートされていません。

- 次の DHCP リレー設定はサポートされていません。

- L3Out インターフェイスの DHCP リレー ラベル。

- APIC から既存の DHCP ポリシーをインポートしています。

- グローバルファブリックアクセスポリシーでの DHCP リレーポリシーの設定はサポートされていません

- 同じ DHCP リレーポリシー内の複数の DHCP サーバと EPG。

同じ DHCP リレーポリシーで複数のプロバイダを設定する場合は、それぞれ異なる EPGs または外部 EPGs にする必要があります。

DHCP リレー ポリシーの作成

このセクションでは、DHCP リレー ポリシーの作成方法について説明します。

（注）

ブリッジ ドメインに DHCP ポリシーを割り当て、ブリッジ ドメインを 1 つ以上のサイトに展開した後で DHCP ポリシーに変更を加えた場合、DHCP ポリシーの変更が各サイトの APIC で更新されるように、ブリッジ ドメインを再展開する必要があります。

始める前に

次のものが必要です。

- 環境でセットアップして設定された DHCP サーバ。

- DHCP サーバーがアプリケーション EPG の一部である場合には、その EPG が Nexus Dashboard Orchestrator ですでに作成されている必要があります。

- DHCP サーバーがファブリックの外部にある場合には、DHCP サーバーにアクセスするために使用される L3Out に関連付けられた外部 EPG が、すでに作成されている必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [ポリシー (Policies)] を選択します。

ステップ 3

メイン ペインの右上で[ポリシー追加 (Add Policy)] > > [DHCP ポリシーの作成 (Creating DHCP Policy)]を選択します。

これは、[DHCP の追加] 設定画面を開きます。

ステップ 4

[名前 (Name)] フィールドにポリシーの名前を入力します。

ステップ 5

[テナントの選択] ドロップダウンから、DHCP サーバを含むテナントを選択します。

ステップ 6

(オプション) [説明] フィールドに、このポリシーの説明を入力します。

ステップ 7

タイプ に対して、リレー を選択します。

ステップ 8

[+プロバイダ] をクリックします。

ステップ 9

プロバイダ タイプを選択します。

リレー ポリシーを追加するときには、次の 2 つのタイプのうちの 1 つを選択できます。

- アプリケーション EPG—エンドポイントとして追加する DHCP サーバを含む特定のアプリケーション EPG を指定します。

- L3 外部ネットワーク—DHCP サーバーへのアクセスに使用される L3Out に関連付けられた外部 EPG を指定します。

（注）

Orchestrator をサイトにまだ展開していない場合でも、Orchestratorで作成され、指定したテナントに割り当てられている EPG または外部 EPG を選択できます。展開されていない EPG を選択した場合でも、DHCP リレー構成を完了することができますが、リレーが使用可能になる前に EPG を展開する必要があります。

ステップ 10

ドロップダウン メニューから、EPG または外部 EPG を選択します。

ステップ 11

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

ステップ 12

[保存 (Save)] をクリックして、プロバイダを追加します。

ステップ 13

(オプション) 追加プロバイダがあれば、それを加えます。

追加のそれぞれの DHCP サーバに対して手順 9 ~ 12 を繰り返します。

ステップ 14

[保存 (Save)] をクリックして DHCP リレー ポリシーを保存します。

DHCP オプション ポリシーの作成

このセクションでは、DHCP オプション ポリシーの作成方法について説明します。DHCP オプションは、DHCP サーバとクライアントが交換するメッセージの末尾に追加され、DHCP サーバに追加の設定情報を提供するために使用されます。各 DHCP オプションには、オプションポリシーを追加するときに指定する必要がある特定のコードがあります。DHCP オプションとコードの完全なリストの場合は、RFC 2132 を参照してください。

始める前に

次のものをあらかじめ設定しておく必要があります。

- 環境で DHCP サーバをセットアップして設定します。

- Nexus Dashboard Orchestrator ですでに作成してある DHCP サーバを含む EPG。

- DHCP リレー ポリシーの作成 の説明に従って作成された DHCP リレー ポリシー。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [ポリシー (Policies)] を選択します。

ステップ 3

メイン ペインの右上で[ポリシー追加 (Add Policy)] > > [DHCP ポリシーの作成 (Creating DHCP Policy)]を選択します。

これは、[DHCP の追加] 設定画面を開きます。

ステップ 4

[名前 (Name)] フィールドにポリシーの名前を入力します。

これは、作成しているポリシーの名前であり、特定の DHCP オプションの名前ではありません。各ポリシーには、複数の DHCP オプションが含まれる場合があります。

ステップ 5

[テナントの選択] ドロップダウンから、DHCP サーバを含むテナントを選択します。

ステップ 6

(オプション) [説明] フィールドに、このポリシーの説明を入力します。

ステップ 7

[タイプ] に対して [オプション] を選択します。

ステップ 8

[+オプション (+Options)] をクリックします。

ステップ 9

オプションの名前を指定します。

技術的には要求されていませんが、RFC 2132 にリストされたオプションに同じ名前を使用することをお勧めします。

たとえば、ネーム サーバ が挙げられます。

ステップ 10

オプションの ID を指定します。

RFC 2132 にリストされているとおり、オプション コードを提供する必要があります。

たとえば、ネーム サーバ オプションに対して 5 が挙げられます。

ステップ 11

オプションのデータを指定します。

オプションが値を要求した場合はそれを指定します。

たとえば、[ネーム サーバ] オプションのクライアントに使用可能なネーム サーバのリスト。

ステップ 12

[データ] フィールドの隣のチェックマークをクリックして、オプションを保存します。

ステップ 13

(オプション) 追加オプションを加えるための手順を繰り返します。

ステップ 14

[保存 (Save)] をクリックして DHCP オプション ポリシーを保存します。

DHCP ポリシーの割り当て

この項では、ブリッジ ドメインを作成する方法について説明します。

（注）

ブリッジドメインに割り当てた後に DHCP ポリシーを変更し、ブリッジ ドメインを 1 つ以上のサイトに展開した場合は、各サイトの APIC で DHCP ポリシーの変更を更新するために、ブリッジ ドメインを再展開する必要があります。

始める前に

次のものをあらかじめ設定しておく必要があります。

- DHCP リレー ポリシーの作成 の説明に従って、DHCP リレー ポリシー。

- (オプション) DHCP オプション ポリシーの作成 の説明に従って、DHCP オプション ポリシー。

- スキーマとテンプレートの作成 章の説明に従って、DHCP ポリシーに割り当てられたブリッジ ドメイン。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

ブリッジド メインが定義されているスキーマを選択します。

ステップ 4

[[ブリッジ ドメイン (Bridge domain)] エリアまで下にスクロールし、ブリッジド メインを選択します。

ステップ 5

右側のサイドバーで、下にスクロールして、 [DHCP ポリシー (DHCP Policy)] オプション チェックボックスをオンにします。

ステップ 6

[DHCP リレーポリシー (DHCP Relay policy)] ドロップダウンから、この BD に割り当てる DHCP ポリシーを選択します。

ステップ 7

(オプション)[DHCP オプションポリシー (DHCP Option policy)] ドロップダウンから、オプション ポリシーを選択します。

DHCP オプション ポリシーは、DHCP リレーに渡す追加のオプションを提供します。詳細については、DHCP オプション ポリシーの作成を参照してください。

ステップ 8

リレー経由で DHCP サーバにアクセスする必要があるすべての EPG にブリッジ ドメインを割り当てます。

DHCP リレー コントラクトの作成

DHCP パケットはコントラクトによりフィルタリングされませんが、VRF 内および VRF 間でルーティング情報を伝播するには、多くの場合コントラクトが必要です。DHCP パケットはフィルタリングされませんが、クライアント EPG と DHCP リレー ポリシーでプロバイダとして設定された EPG の間のコントラクトを設定することをお勧めします。

このセクションでは、DHCP サーバーを含む EPG と、リレーを使用する必要のあるエンドポイントを含む EPG の間でコントラクトを作成する方法について説明します。DHCP ポリシーを作成してブリッジ ドメインに、また、ブリッジ ドメインをクライアントの EPG にすでに割り当てている場合でも、クライアントからサーバーへの通信を可能にするルートのプログラミングを有効にするには、コントラクトを作成して割り当てる必要があります。

始める前に

次のものをあらかじめ設定しておく必要があります。

- DHCP リレー ポリシーの作成 の説明に従って、DHCP リレー ポリシー。

- (オプション) DHCP オプション ポリシーの作成 の説明に従って、DHCP オプション ポリシー。

- DHCP ポリシーの割り当て の説明に従って、DHCP ポリシーに割り当てられたブリッジ ドメイン。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左のナビゲーションメニューから [スキーマ(Schemas)] を選択します。

ステップ 3

コントラクトを作成したいスキーマを選択します。

ステップ 4

コントラクトを作成します。

DHCP パケットはコントラクトによってフィルタリングされていないため、特定のフィルタは必要ありませんが、有効なコントラクトが作成され、割り当てられて、適切な BD およびルート展開を保証する必要があります。

1. [コントラクト (Contracts)] エリアまで下方にスクロールし、+ をクリックして、コントラクトを作成します。

2. 右のプロパティのサイドバーでは、コントラクトの表示名を指定します。

3. [範囲 (Scope)] ドロップダウンから、適切な範囲を選択します。

DHCP サーバ EPG とアプリケーション EPG は同じテナントになければならないため、次のうちの 1 つを選択できます。

- vrf。両方の EPG が同じ VRF にある場合

- テナント。EPG が異なる VRF にある場合

4. [両方向に適用 (Apply Both Directions)] ノブをオンのままにすることができます。

ステップ 5

DHCP リレー EPG にコントラクトを割り当てます。

1. EPG が配置されているテンプレートを参照します。

2. DDHCP サーバが常駐する EPG または外部 EPG を選択します。

これは、DHCP リレー ポリシーを作成するときに選択したものと同じ EPG です。

3. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

4. 作成したコントラクトとそのタイプのプロバイダを選択します。

ステップ 6

エンドポイントが DHCP リレー アクセスを必要とするアプリケーション EPG にコントラクトを割り当てます。

1. アプリケーション EPG が配置されているテンプレートを参照します。

2. アプリケーション EPG を選択します。

3. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

4. 作成したコントラクトとそのタイプのコンシューマを選択します。

APIC での DHCP リレー ポリシーの確認

ここでは、Nexus Dashboard を使用して作成および展開した DHCP リレーポリシーが各サイトの APIC に正しくプッシュされることを確認する方法について説明します。作成する DHCP ポリシーは、ポリシーが関連付けられているブリッジ ドメインがサイトに展開しているときに、APIC にプッシュされます。

手順

ステップ 1

サイトの APIC GUI にログインします。

ステップ 2

上部のナビゲーションバーから、[テナント(tenant)] > <テナント名>を選択します。

DHCP ポリシーを展開したテナントを選択します。

ステップ 3

APIC で DHCP リレー ポリシーが設定されていることを確認します。

左側のツリー ビューで、 <テナント名> > ポリシー (Policies) > プロトコル (Protocol) > DHCP > リレー ポリシー(Relay policies)に移動します。次に、設定した DHCP リレー ポリシーが作成されていることを確認します。

ステップ 4

DHCP オプション ポリシーが APIC で設定されていることを確認します。

DHCP オプション ポリシーを設定していない場合は、この手順をスキップできます。

左側のツリー ビューで、 <テナント名> > ポリシー (Policies) > プロトコル (Protocol) > DHCP > オプション ポリシー(Option Policies)に移動します。次に、設定した DHCP オプション ポリシーが作成されていることを確認します。

ステップ 5

DHCP ポリシーがブリッジ ドメインに正しく関連付けられていることを確認します。

左側のツリー ビューで、 <テナント名> > ネットワーク > ブリッジ ドメイン > <ブリッジ ドメイン名> > DHCP リレー ラベルに移動します。展開されたブリッジ ドメインにも DHCP ポリシーが関連付けられていることを確認します。

既存の DHCP ポリシーの編集または削除

このセクションでは、DHCP リレーまたはオプション ポリシーを編集または削除する方法について説明します。

（注）

- ブリッジ ドメインに割り当てた後に DHCP ポリシーを変更し、ブリッジ ドメインを 1 つ以上のサイトに展開した場合は、DHCP ポリシーの変更が各サイトの APIC で更新されるように再展開する必要があります。

- 1つ以上のブリッジ ドメインに関連付けられているポリシーを削除することはできません。最初に、すべてのブリッジ ドメインからポリシーの割り当てを解除する必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左のナビゲーションメニューから [ポリシー] を選択します。

ステップ 3

DHCP ポリシーの横にある [アクション] メニューをクリックし、[編集 (Edit)] または [削除 (Delete)] を選択します。

Chapter19. サイト間 L3Out

- サイト間 L3Out の概要

- サイト内 L3Out のガイドラインと制約事項

- 外部 TEP プールの設定

- サイト間 L3Out および VRF の作成またはインポート

- サイト間 L3Out を使用するための外部 EPG の設定

- サイト間 L3Out のコントラクトの作成

サイト間 L3Out の概要

リリース 2.2(1) 以前、Nexus Dashboard Orchestrator により管理される各サイトでは、トラフィックをファブリックの外にルートするために設定された固有のローカル L3Out が必要で、それによりしばしば 1 つのサイトのエンドポイントと別のサイトの L3Out に接続されたサービス (ファイアウォール、サーバ ロード バランサー、またはメインフレーム) の間のコミュニケーションの欠如を導くことがありました。

リリース 2.2(1) は、1 つのサイトにあるエンドポイントが、外部ネットワーク、メインフレーム、またはサービス ノードなどのリモート L3Out を通じて到達可能なエンティティとの接続を確立する多くのシナリオを有効にする機能を追加します。

このような要素として、次のものが挙げられます。

- サイト間の L3Out：別のサイトの L3Out を使用した 1 つのサイトのアプリケーション EPG のエンドポイント。

- サイト間中継ルーティング：異なるサイトに展開された L3Out（同じ VRF の両方の L3Out）の背後に接続されたエンティティ（エンドポイント、ネットワークデバイス、サービスノードなど）間の通信を確立します。

- サイト間 L3Out の共有サービス：リモート E3Out へのアプリケーション EPG またはサイト間中継ルーティング。

次のセクションは、サイト間 L3Out の使用例の実装に必要なオブジェクトを作成するために実行できる一般的な GUI 手順に分かれています。その後、サポートされる各使用例のシナリオに固有の概要とワークフローを示します。

（注）

「サイト間 L3Out」という用語は、リモート サイトの L3Out 接続を介して到達可能な外部リソースへの通信を可能にする機能を指します。ただし、このドキュメントでは、この用語は特定のリモート L3Out オブジェクトを示すためにも使用されることがあります。

サイト内 L3Out のガイドラインと制約事項

サイト間 L3Out を構成するときは、次のことを考慮する必要があります。

- サイト間 L3Out は IPv4 と IPv6 に対してサポートされています。

- サイト間 L3Out では、Multi-Site トポロジ内のサイト間で常に確立される BGP eVPN セッションに加えて、サイト間 L3Out 機能をサポートするために MP BGP VPNv4（または VPNv6）セッションが作成されます。

- リリース 2.2(1) 以前のリリースからアップグレードしている場合、サイト ローカル レベルの既存の外部 EPG から L3Out への関連付けは保持されます。さらに、Nexus Dashboard Orchestrator は L3Out の作成とテンプレート レベルでの外部 EPG との関連付けをサポートするようになりました。

スキーマ テンプレートで新しい L3Out を作成し、既存の外部 EPG に関連付ける場合：

- L3Out が APIC ですでに定義されている L3Out と同じ名前の場合、Orchestrator その L3Out の所有権を取得しますが、L3Out ノード プロファイル、インターフェース プロファイル、プロトコル設定、またはルート制御設定の構成を管理しません。

（注）

L3Out が APIC にすでに存在する場合は、NDO から同じ名前の新しい L3Out を作成するのではなく、関連付けられた外部 EPG とともに Nexus Dashboard Orchestrator にインポートすることをお勧めします。

次に、Orchestrator からこの L3Out を削除することにすると、それは Orchestrator により管理されなくなりますが、以前から存在する L3Out の構成は APIC に保存されます。

- L3Out が L3Out で定義された APIC とは 異なる名前 がある場合、外部 EPG は、APIC で定義された L3Out から削除され、Orchestrator で定義された L3Out に追加されます。これが APIC で定義された L3Out での唯一の外部 EPG である場合、これにより設定が境界リーフから削除され、トラフィックに影響を与える可能性があります。

- リリース 2.2(1) より前のリリースにダウングレードすることを選択した場合、Orchestrator NDO で作成された L3Out はテンプレートに存在しなくなるため、外部 EPG と L3Out 間のテンプレート レベルの関連付けは削除されます。この場合、サイト ローカル レベルで、外部 EPG と L3Out の関連付けを手動で再構成する必要があります。ダウングレード中、サイトローカルの関連付けは保持されます。

- これで、1 つのサイトのブリッジ ドメインを別のサイトの L3Out に関連付けることができますが、両方が同じ VRF にある必要があります。

この関連付けはサイトローカル レベルで実行され、リモート L3Out から BD サブネットをアドバタイズし、ローカル L3Out に障害が発生した場合でも BD へのインバウンド トラフィックを維持できるようにするために必要です。

- サイト間 L3Out に関連付けられた VRF のポリシー制御施行方向は、デフォルトの入力モードで構成されたままにする必要があります。

- 次のシナリオは、サイト間 L3Out およびリモートリーフ (RL) ではサポートされていません。

- 別々のサイトに関連付けられた RL ペアにデプロイされた L3Out 間のトランジット ルーティング

- リモート サイトに関連付けられた RL ペアに展開された L3Out と通信するサイトに関連付けられた RL ペアに接続されたエンドポイント

- リモート サイトに関連付けられた RL ペアに展開された L3Out と通信するローカル サイトに接続されたエンドポイント

- リモート サイトに展開された L3Out と通信するサイトに関連付けられた RL ペアに接続されたエンドポイント

- 次の他の機能は、ACI Multi-Site のサイト間 L3Out ではサポートされていません。

- 別のサイト L3Out を介して外部ソースからマルチキャストを受信するサイト内のマルチキャスト レシーバー。サイトで外部ソースから受信したマルチキャストが他のサイトに送信されることはありません。サイトのレシーバーが外部ソースからマルチキャストを受信する場合、ローカルの L3Out で受信する必要があります。

- PIM-SM Any Source Multicast (ASM) を使用して外部レシーバーにマルチキャストを送信する内部マルチキャスト ソース。内部マルチキャスト ソースは、ローカル L3Out から外部ランデブー ポイント (RP) に到達できる必要があります

- GOLF

- 外部 EPG の優先グループ

外部 TEP プールの設定

サイト間 L3Out には、各ポッドの境界リーフ スイッチに外部 TEP アドレスが必要です。外部 TEP プールがすでに設定されている場合 (たとえば、リモート リーフなどの別の機能のために) は、同じプールを使用できます。既存の TEP プールは Nexus Dashboard Orchestrator に継承され、インフラストラクチャ設定の一部として GUI に表示されます。それ以外の場合は、この項で説明されているように、GUI で TEP プールを追加できます。

（注）

すべてのポッドに一意の TEP プールを割り当てる必要があり、ファブリック内の他の TEP プールと重複しないようにする必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[インフラストラクチャ（Infrastructure）] > [インフラの設定（Infra Configuration）]を選択します。

ステップ 3

メインペインの右上にある [インフラの設定 (Configure Infra)] をクリックします。

ステップ 4

左側のサイドバーで、設定するサイトを選択します。

ステップ 5

メイン ウィンドウで、サイト内のポッドをクリックします。

ステップ 6

右側のサイドバーで、[+ TEP プールを追加 (+Add TEP Pool)] をクリックします。

ステップ 7

[TEP プールの追加 (Add TEP pool)] ウィンドウで、そのサイトに対して設定する外部 TEP プールを指定します。

（注）

追加しようとしている TEP プールが他の TEP プールまたはファブリックアドレスと重複していないことを確認する必要があります。

ステップ 8

このプロセスを、サイト間の L3Outs を使用する予定のサイトおよびポッドごとに繰り返します。

サイト間 L3Out および VRF の作成またはインポート

ここでは、L3Out を作成し、それを Orchestrator GUI で VRF に関連付ける方法について説明します。これは APIC サイトにプッシュされるか、または APIC サイトの 1 つから既存の L3Out をインポートします。次に、この L3Out を外部 EPG に関連付け、その外部 EPG を使用して特定のサイト間 L3Out の使用例を設定します。

（注）

L3Out に割り当てる VRF は、任意のテンプレートまたはスキーマにすることができますが、L3Out と同じテナントに存在する必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

[スキーマ (schema)] を選択し、VRF と L3Out を作成またはインポートするテンプレートを選択します。

1 つのサイトに関連付けられているテンプレートで L3Out を作成することを推奨します。この場合、そのサイトでのみ L3Out が作成されます。

または、複数のサイトに関連付けられているテンプレートで L3Out を作成することもできます。この場合、すべてのサイトで同じ名前で L3Out が作成されます。これにより、この章で後述するように、いくつかの機能制限が生じる可能性があります。

ステップ 4

新しい VRF と L3Out を作成します。

既存の L3Out をインポートする場合は、この手順をスキップします。

（注）

Orchestrator で L3Out オブジェクトを作成し、それを APIC にプッシュすることはできますが、L3Out の物理設定は APIC で実行する必要があります。

1. [VRF] エリアまで下にスクロールし、+ アイコンをクリックして新しい VRF を追加します。

L3Out に使用する予定の VRF がすでにある場合は、このサブステップをスキップします。

右側のサイドバーで、VRF の名前を入力します (例: vrf-l3out )。

2. [L3Out] 領域まで下にスクロールし、+ アイコンをクリックして新しい L3Out を追加します。

右側のスライダで、必要な情報を入力します。

3. L3Out の名前を指定します (例: l3out-intersite。

4. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、VRF を選択します。

最初のサブステップで作成した VRF を選択するか、既存の VRF を選択します。

ステップ 5

既存の VRF および L3Out をインポートします。

前の手順で新しい L3Out を作成した場合は、この手順をスキップします。

メイン ウィンドウ ペインの [インポート (Import)] をクリックして、

1. メイン テンプレート ビューの上部で、[インポート (Import)] をクリックします。

2. L3Out をインポートするサイトを選択します。

3. [インポート (Import)] ウィンドウの [ポリシー タイプ(Policy Type)] メニューで、[L3Out] を選択します。

4. インポートする L3Out をチェックします。

デフォルトでは、L3Outをインポートすると、対応するVRFもインポートされます。これは、サイト固有のテンプレートでL3Outをインポートする場合、通常は複数のサイトに関連付けられた拡張テンプレートでVRFを定義するため、望ましくない場合があります。この場合、L3Outをインポートする前に[Include Relationships]オプションを無効にします。この場合、インポート後にL3Outを正しいVRFに再マッピングする必要もあります。

5. [インポート（Import）] をクリックします。

6. L3Outのみをインポートした場合は、テンプレートビューでそれを選択し、適切なVRFに関連付けます。

サイト間 L3Out を使用するための外部 EPG の設定

このセクションでは、サイト間 L3Out と関連付ける外部 EPG の作成方法について説明します。その後、この外部 EPG とコントラクトを使用すれば、あるサイトのエンドポイント用の特定のユース ケースを設定し、別のサイトの L3Out を使用することができます。

始める前に

L3Out を作成し、サイト間 L3Out および VRF の作成またはインポートに説明されている方法で VRF と関連付けます。

手順

ステップ 1

外部 EPG を作成するテンプレートを選択します。

複数のサイトと関連付けられているテンプレート内で外部 EPG を作成した場合、その外部 EPG は、それらすべてのサイト上で作成されます。これは、外部 EPG の L3Out が WAN などの一連の共通外部リソースへのアクセスを提供する場合に推奨されます。

単一のサイトと関連付けられているテンプレート内で外部 EPG を作成した場合、その外部 EPG は、そのサイト内でのみ作成されます。これは、外部 EPG の L3Out がそのサイトからのみアクセス可能な外部リソースへのアクセスを提供する場合に推奨されます。

ステップ 2

[外部 EPG (External EPG)] エリアまで下方にスクロールして、+ アイコンをクリックして外部 EPG を追加します。

右側のスライダで、必要な情報を入力します。

1. 外部 EPG の名前を入力します。たとえば [eepg-intersite-l3out] のようにします。

2. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、先ほど作成した、L3Out 用の VRF を選択します。

ステップ 3

外部 EPG を L3Out にマッピングします。

サイトレベルまたはテンプレートレベルで、外部 EPG を L3Out にマッピングできます。通常、各サイトはローカル L3Out を一意の名前で定義するため、外部 EPG 自体が拡張されているかどうかに関係なく、外部 EPG を各サイト固有の L3Out に選択的にマッピングできます。それで、サイトレベルでマッピングを作成することをお勧めします。

L3Out をサイトローカル レベルで外部 EPG に関連付けるには、次の手順に従います。

1. スキーマ ビューの左サイドバーで、外部 EPG が配置されているテンプレートを選択します。

2. [外部 EPG (External EPG)] エリアまで下方にスクロールして、外部 EPG を選択します。

3. 右サイドバーで、[L3Out] ドロップダウンまで下方にスクロールして、作成したサイト間 L3Out を選択します。

この場合、APIC で管理されている L3Out と、オーケストレーションで管理されている L3Out の両方が選択できます。前のセクションでこの目的のため特に作成した L3Out、またはサイトの APIC 内にすでにある L3Out のいずれかを選択します。

サイト レベルまたはテンプレート レベルで、外部 EPG を L3Out にマッピングできます。これにより、複数のサイトで同じ L3Out 名が定義されている展開での設定が容易になりますが、マルチ サイト ドメインやおよび外部ルーテッド ネットワークの一部であるファブリック間で確立できる接続タイプの柔軟性が低下するため、このアプローチは推奨されません。たとえば、特定の BD のサブネットがアドバタイズされる場所を制御することはできません。これは、L3Out に BD をマッピングすると、すべての L3Out が同じ名前を持つため、すべてのサイトのすべての L3Out から BD サブネットがアドバタイズされるためです。

テンプレート レベルで L3Out を外部 EPG に関連付けるには、次の手順を実行します。

1. スキーマ ビューの左サイドバーで、外部 EPG が置かれているテンプレートを選択します。

2. [外部 EPG (External EPG)] エリアまで下方にスクロールして、外部 EPG を選択します。

3. 右サイドバーで、[L3Out] ドロップダウンまで下方にスクロールして、作成したサイト間 L3Out を選択します。

また、テンプレート レベルで L3Out に最初に関連付けられた外部 EPG の設定を、サイトレベルのマッピングに移行することもできます。これを行うには、外部 EPG の VRF 関連付けを削除し、外部 EPG を同じ VRF に再び関連付け、それからサイトレベルで L3Outs をマッピングします。このプロセスがテンプレートを展開する前に一度に完了しておけば、APIC 側で実際に変更が適用されないため、新しい設定をプッシュする際にトラフィックに影響はありません。

ステップ 4

外部 EPG に 1 つ以上のサブネットを設定します。

1. 外部 EPG を選択します。

2. 右側のサイドバーで、[+ サブネットを追加 (+Add Subnet)] をクリックします。

3. [サブネットを追加 (Add Subnet)]ウィンドウで、分類サブネットと必要なオプションを入力します。

設定するプレフィックスとオプションは、使用例によって異なります。

- 着信トラフィックを外部 EPG に属するものとして分類するには、指定したプレフィックスの [外部 EPG の外部サブネット (External Subnets for External EPG)] フラグを選択します。使用例に応じて、内部 EPG またはリモート L3Out 経由で到達可能な外部ネットワーク ドメインとの契約を適用できます。

- この L3Out から（同じサイトまたはリモート サイト内の）別の L3Out から学習した外部プレフィックスをアドバタイズするには、指定したプレフィックスの [エクスポート ルート制御 (Export Route Control)] フラグを選択します。0.0.0.0/0プレフィックスを指定する場合は、L3Outからのすべてのプレフィックスをアドバタイズするために [集約エクスポート (Aggregate Export)] フラグを選択できます。 [集約エクスポート (Aggregate Export)] フラグが有効になっていない場合、デフォルト ルートの 0.0.0.0/0 だけがアドバタイズされます（ボーダー リーフ ノードのルーティング テーブルに存在する場合）。

- 外部ネットワークから受信した特定のルートを除外するには、指定したプレフィックスの [ルート制御のインポート (Import Route Control)] フラグを選択します。0.0.0.0/0 を指定する場合は、[集約インポート (Aggregate Import)] オプションを選択することもできます。

これは、BGP を外部ルータとピアリングする場合にのみ可能であることに注意してください。

- 異なるVRFにルートをリークするには、[共有ルート制御 (Shared Route Control)] と関連する [集約共有ルート(Aggregate Shared Routes)] フラグ、および [共有セキュリティ インポート (Shared Security Import)] フラグを選択します。これらのオプションは、VRF 間共有 L3Out および VRF 間サイト間中継ルーティングの特定の使用例に必要です。

サイト間 L3Out のコントラクトの作成

ここでは、サイトに展開されたアプリケーション EPG と、別のサイトの L3Out に関連付けられた外部 EPG（サイト間 L3Out 機能）との間の通信を可能にするために使用するフィルタとコントラクトを作成する方法について説明します。

手順

ステップ 1

コントラクトとフィルタを作成するためのテンプレートを選択します。

L3Out、VRF、および外部 EPG を作成したのと同じスキーマとテンプレートを使用できます。または、別のスキーマとテンプレートを選択することもできます。

コントラクトは異なるサイトに展開されたオブジェクト（EPG および外部 EPG）に適用されるため、複数のサイトに関連付けられたテンプレートで定義することを推奨します。ただし、これは必須ではありません。コントラクトとフィルタが Site1 のローカル オブジェクトとしてのみ定義されている場合でも、 Site2 のローカル EPG または外部 EPG がそのコントラクトを消費または提供する必要がある場合、NDO はリモート Site2 に対応するシャドウ オブジェクトを作成します。 。

ステップ 2

フィルタを作成します。

1. [Filter (フィルタ)] エリアまでスクロールし、[+] をクリックしてフィルタを作成します。

2. 右側のペインで、フィルタの [表示名 (Display Name)] を入力します。

3. 右側のペインで、[+ エントリ (+ Entry)] をクリックします。

ステップ 3

フィルタの詳細を入力します。

1. フィルタの [名前 (Name)] を指定します。

2. [イーサー タイプ (Ether Type)] を選択します。

たとえば [ip] です。

3. [IP プロトコル (IP Protocol)] を選択します。

たとえば [icmp] です。

4. 他のプロパティは未指定のままにします。

5. [保存 (Save)] をクリックしてフィルタを保存します。

ステップ 4

コントラクトの作成

1. 中央ペインで、[コントラクト (Contracts)] エリアまで下方にスクロールし、[+] をクリックして、コントラクトを作成します。

2. 右側のペインで、コントラクトの [表示名 (Display Name)] を入力します。

3. コントラクトの適切な [範囲 (Scope)] を選択します。

サイト間 L3Out の別の VRF にある共有サービス エンドポイントを設定する場合にはは、その範囲の テナント を選択する必要があります。それ以外の場合、両方が同じ VRF 内にある場合は、範囲を vrf に設定できます。

4. コンシューマからプロバイダーへの方向とプロバイダーからコンシューマへの方向の両方に同じフィルタを適用する場合は、[両方向に適用 (Apply both directions)] ノブを切り替えます。

このオプションを有効にした場合は、フィルタを 1 回だけ指定することが必要となり、両方向のトラフィックに適用されます。このオプションを無効のままにした場合は、各方向に 1 つずつ、2 セットのフィルタ チェーンを指定する必要があります。

ステップ 5

コントラクトにフィルタを割り当てる

1. 右側のペインで、[フィルタ チェーン (Filter Chain)] 領域までスクロールし、[+ フィルタ (+ Filter)] をクリックしてフィルタをコントラクトに追加します。

コントラクトで [両方向に適用 (Apply both directions)] オプションを無効にした場合は、他のフィルタ チェーンに対してこの手順を繰り返します。

2. 開いた [フィルタ チェーンの追加] ウィンドウで、[名前 (Name)]ドロップダウン メニューから前の手順で追加したフィルタを選択します。

3. [保存 (Save)] をクリックして、フィルタをコントラクトに追加します。

アプリケーション EPG のサイト間 L3Out（VRF内）

ここでは、アプリケーション EPG の一部であるエンドポイントが、同じ VRF（intra-VRF）内にある別のサイトに展開された L3Out を介して到達可能な外部ネットワークドメインと通信できるようにするために必要な設定について説明します。

最初の図は、拡大された外部 EPG と、両方のサイトで作成される関連づけられた L3Out を示しています。アプリケーション EPG (EPG1) はサイト 1 で作成され、外部 EPG とのコントラクトがあります。この使用例は、別のサイトの L3Out が外部リソースの共通セットへのアクセスを提供する場合に推奨されます。ポリシー定義と外部トラフィック分類が簡素化され、独立した APIC ドメインの各 L3Out に個別にルートマップポリシーを適用できます。

拡張された外部 EPG

次の 2 番目の図は、同様の使用例を示していますが、外部 EPG は物理 L3Out が配置されているサイトだけに導入されています。アプリケーション EPG とコントラクトは、1 つのサイトの EPG と他方の物理 L3Out 間のトラフィックフローを可能にするのと全く同じ方法で設定します。

拡張されていない (サイトローカルの) 外部 EPG

次の手順では、最も一般的なシナリオである図 1 に示す使用例を実装するために必要な設定について説明します。図 2 に示すユースケースを導入する場合は、若干の変更を加えて手順を調整できます。

始める前に

次のものがすでに設定されている必要があります。

- 3 つのテンプレートを持つスキーマ。

アプリケーションEPGやL3Outsなど、そのサイトに固有のオブジェクトを設定する各サイトのテンプレート（template-site1 や template-site2 など）を作成します。さらに、ストレッチされたオブジェクト（この場合は外部 EPG）に使用する別のテンプレート（template-stretched など）を作成します。

- サイト間 L3Out および VRF の作成またはインポートセクションで説明されている各サイトのL3Outs。

この使用例では、各サイト固有のテンプレートに個別の L3Out がインポートまたは作成されます。

- サイト間 L3Out を使用するための外部 EPG の設定 で説明されているように、サイト間 L3Out の外部 EPG。

この使用例では、外部EPGは、ストレッチされたテンプレート（template-stretched）で定義されたストレッチされたオブジェクトとして設定されます。外部EPGが外部アドレス空間全体へのアクセスを提供すると仮定すると、より具体的なプレフィックスの長いリストを指定しないように、0.0.0.0/0 プレフィックスを分類用に設定することを推奨します。

- サイト間 L3Out のコントラクトの作成 で説明されているように、アプリケーション EPG と L3Out 外部 EPG の間で使用するコントラクト。

ストレッチ テンプレート（template-stretched）でコントラクトとフィルタを作成することをお勧めします。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

アプリケーション EPG とブリッジ ドメインのスキーマとテンプレートを選択します。

この使用例では、テンプレートを Site1 に関連付けます。

ステップ 4

L3Out とは別の VRF に属するアプリケーション EPG とそのブリッジ ドメインを設定します。

サイト間 L3Out を使用する EPG がすでにある場合は、この手順をスキップできます。

通常のように、EPG およびブリッジ ドメインを新規に作成するか、既存のものをインポートします。

ステップ 5

アプリケーション EPG にコントラクトを割り当てます。

1. EPG を選択します。

2. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

3. 前のセクションで作成したコントラクトとそのタイプを選択します。

アプリケーション EPGがコンシューマかプロバイダかを選択できます。

ステップ 6

コントラクトを、リモート L3Out にマップされた外部 EPG に割り当てます。

1. 外部 EPG が配置されている template-stretched を選択します。

2. 外部 EPG を選択します。

3. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

4. 前のセクションで作成したコントラクトとそのタイプを選択します。

アプリケーション EPG をコンシューマとして選択した場合は、外部 EPG のプロバイダを選択します。それ以外の場合は、外部 EPGのコンシューマを選択します。

ステップ 7

アプリケーション EPG のブリッジ ドメインを L3Out に関連付けます。

これにより、BD サブネットを L3Out から外部ネットワーク ドメインにアドバタイズできます。BD に関連付けられたサブネットは、L3Out からアドバタイズされるように [外部アドバタイズ (Advertised Externally)] オプションを使用して設定する必要があります。

1. 左側のサイドバーの [サイト (Sites)] の下で、アプリケーション EPG のテンプレートを選択します。

2. アプリケーション EPG に関連付けられたブリッジ ドメインを選択します。

3. 右側のサイドバーで、[+ L3Out] をクリックします。

4. 作成したサイト間 L3Out を選択します。

図1に示す使用例では、BD を Site1 と Site2 で定義された両方の L3Out に関連付けて、外部ネットワークが両方のパスから EPG にアクセスできるようにします。特定のポリシーを L3Out または外部ルータに関連付けて、特定の L3Out パスが着信トラフィックに通常優先されるようにすることができます。リモート サイトの L3Out を介した最適ではないインバウンド トラフィック パスを回避するために、EPG と BD が（特定の例のように）サイトに対してローカルである場合、これを推奨します。

ステップ 8

スキーマを展開します。

アプリケーション EPG のサイト間 L3Out との共有サービス（Inter-VRF）

ここでは、1 つの VRF のアプリケーション EPG の一部であるエンドポイントが、別のサイトに展開された L3Out を介して到達可能な外部ネットワーク ドメインと通信できるようにするために必要な設定について説明します。これは「共有サービス」とも呼ばれます。

このシナリオは、別のサイトの L3Out が外部リソースの共通セットへのアクセスを提供する場合に推奨されます。ポリシー定義と外部トラフィック分類が簡素化され、独立した APIC ドメインの各 L3Out に個別にルートマップポリシーを適用できます。

ストレッチ外部EPG、サイト ローカル L3Out、およびアプリケーション EPG のいずれかになります。

次の手順では、図 3 に示す使用例を実装するために必要な設定について説明します。

始める前に

次のものがすでに設定されている必要があります。

- 3 つのテンプレートを持つスキーマ。

アプリケーション EPG や L3Outs など、そのサイトに固有のオブジェクトを設定するサイトごとのテンプレート（template-site1 や template-site2 など）を作成します。さらに、ストレッチされたオブジェクト（この場合は外部 EPG）に使用する別のテンプレート（template-stretched など）を作成します。

- サイト間 L3Out および VRF の作成またはインポートセクションで説明されている各サイトのL3Outs。

この使用例では、各サイト固有のテンプレートに個別の L3Out がインポートまたは作成されます。

- サイト間 L3Out を使用するための外部 EPG の設定 で説明されているように、サイト間 L3Out の外部 EPG。

この使用例では、外部EPGは、ストレッチされたテンプレート（template-stretched）で定義されたストレッチされたオブジェクトとして設定されます。外部EPGが外部アドレス空間全体へのアクセスを提供すると仮定すると、より具体的なプレフィックスの長いリストを指定しないように、0.0.0.0/0 プレフィックスを分類用に設定することを推奨します。

この特定の共有サービスの使用例では、リモート L3Out の外部 EPG に関連付けられたサブネットの共有ルート制御フラグと共有セキュリティインポートフラグを有効にする必要があります。外部EPGの分類に 0.0.0.0/0 プレフィックスを使用している場合は、共有ルート制御フラグに加えて、集約共有ルートフラグも有効にします。

- サイト間 L3Out のコントラクトの作成 で説明されているように、アプリケーション EPG と L3Out 外部 EPG の間で使用するコントラクト。

ストレッチ テンプレート（template-stretched）でコントラクトとフィルタを作成することをお勧めします。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

アプリケーション EPG とブリッジ ドメインのスキーマとテンプレートを選択します。

この使用例では、テンプレートを Site1 に関連付けます。

ステップ 4

L3Out とは別の VRF に属するアプリケーション EPG とそのブリッジドメインを設定します。

サイト間 L3Out を使用する EPG がすでにある場合は、この手順をスキップできます。

通常のように、EPG およびブリッジ ドメインを新規に作成するか、既存のものをインポートします。

ステップ 5

アプリケーション EPG にコントラクトを割り当てます。

1. EPG を選択します。

2. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

3. 前のセクションで作成したコントラクトとそのタイプを選択します。

アプリケーション EPGがコンシューマかプロバイダかを選択できます。

（注）

アプリケーション EPG をプロバイダとして設定する場合は、そのルートを L3Out VRF にリークするために、EPG の下でも BD ですでに定義されているサブネットを設定する必要があります。サブネットの BD で使用されるのと同じフラグも EPG で設定する必要があります。さらに、EPG の下のサブネットでは、デフォルト ゲートウェイ機能が BD レベルで有効になっているため、[デフォルト SVI ゲートウェイなし (No default SVI Gateway)] フラグも有効にする必要があります。

ステップ 6

コントラクトを、L3Out にマップされた外部 EPG に割り当てます。

1. 外部 EPG が配置されている template-stretched を選択します。

2. 外部 EPG を選択します。

3. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

4. 前のセクションで作成したコントラクトとそのタイプを選択します。

アプリケーション EPG をコンシューマとして選択した場合は、外部 EPG のプロバイダを選択します。それ以外の場合は、外部 EPGのコンシューマを選択します。

ステップ 7

アプリケーション EPG のブリッジ ドメインを L3Out に関連付けます。

これにより、BD サブネットを L3Out から外部ネットワーク ドメインにアドバタイズできます。BD に関連付けられたサブネットは、L3Out からアドバタイズされるように [外部アドバタイズ (Advertised Externally)] オプションを使用して設定する必要があります。

1. 左側のサイドバーの [サイト (Sites)] の下で、アプリケーション EPG のテンプレートを選択します。

2. アプリケーション EPG に関連付けられたブリッジ ドメインを選択します。

3. 右側のサイドバーで、[+ L3Out] をクリックします。

4. 作成したサイト間 L3Out を選択します。

図1に示す使用例では、BD を Site1 と Site2 で定義された両方の L3Out に関連付けて、外部ネットワークが両方のパスから EPG にアクセスできるようにします。特定のポリシーを L3Out または外部ルータに関連付けて、特定の L3Out パスが着信トラフィックに通常優先されるようにすることができます。リモート サイトの L3Out を介した最適ではないインバウンド トラフィック パスを回避するために、EPG と BD が（特定の例のように）サイトに対してローカルである場合、これを推奨します。

ステップ 8

スキーマを展開します。

サイト間中継ルーティング

このセクションでは、マルチサイト ドメインが分散ルータとして機能し、異なるサイトに展開された L3Out の背後に接続されているエンティティ（エンドポイント、ネットワーク デバイス、サービス ノードなど）間の通信を可能にする使用例について説明します。この機能は通常、サイト間中継ルーティングと呼ばれます。 。サイト間中継ルーティングは、VRF 内および VRF 間のユースケースでサポートされます。

次の図は、異なるサイトに設定されている2つの L3Outs (l3out1 と l3out2) を示しています。各 L3Out はそれぞれの外部 EPG (ExtEPG1 および ExtEPG2) に関連付けられています。2 つの外部 EPG 間のコントラクトにより、2 つの異なるサイトの 2 つの異なる L3Outs の背後にあるエンドポイント間の通信が可能になります。

VRF サイト内中継ルーティング

各サイトの L3Out が異なる VRF にある場合も、同様の設定を使用できます。

VRF サイト間中継ルーティング

図では、外部 EPG と、関連付けられた L3Out がサイトローカルのオブジェクトとして展開される、2 つのシナリオを示しています。サイト間中継ルーティングは、サイト間で EPG がストレッチされていない場合、一方がストレッチされている場合、両方がストレッチされている場合という、すべての組み合わせをサポートしています。

サイト間中継ルーティングを導入する場合、サイト間で定義された異なる外部 EPG が異なる外部アドレス空間へのアクセスを提供する（明らかに重複しない）ことが前提となります。したがって、分類に使用されるプレフィックスの設定には、いくつかのオプションがあります。

- 両方の外部 EPG で同じ 0.0.0.0/0 プレフィックスを定義して、L3Out1 の境界リーフ ノードで受信した着信トラフィックが Ext-EPG1 にマッピングされ、L3Out2 で受信した着信トラフィックが Ext-EPG2 にマッピングされるようにします。L3Out は別のファブリックで定義されているため、この設定で競合の問題は発生しません。

L3Out1で受信した外部プレフィックスは、L3Out2 からアドバタイズする必要があります。その逆も同様です。両方の外部 EPG で 0.0.0.0/0 を分類サブネットとして使用している場合は、[エクスポート ルート制御 (Export Route Control)] および [集約エクスポート (Aggregate Export)] フラグを有効にするだけで十分です。

- 外部 EPG ごとに特定のプレフィックスを定義します。この場合、ローカル外部 EPG とリモート外部 EPG 間のコントラクトのためにシャドウ外部 EPG がそのサイトで作成されるときに、サイトの APIC によって障害が発生するのを回避するために、プレフィックスが重複していないことを確認する必要があります。

特定のプレフィックスを使用する場合は、外部 EPG1 で分類用に設定したの同じプレフィックスを、[エクスポートルート制御 (Export Route Control)] フラグを立てて、外部 EPG2 で設定する必要があります。逆の場合も同じです。

（注）

2 つの分類アプローチのどちらを導入する場合でも、VRF 間シナリオでは、[共有ルート制御 (Shared Route Control)]（加えて [集約共有ルート (Aggregate Shared Routes)] も 0.0.0.0/0 を使用する場合には必要）および [共有セキュリティ インポート (Shared Security Import)] の各フラグを設定する必要があります。

始める前に

次のものがすでに設定されている必要があります。

- 3 つのテンプレートを持つスキーマ。

アプリケーション EPG や L3Outs など、そのサイトに固有のオブジェクトを設定するサイトごとのテンプレート（template-site1 や template-site2 など）を作成します。さらに、ストレッチされたオブジェクト（この場合は外部 EPG）に使用する別のテンプレート（template-stretched など）を作成します。

- サイト間 L3Out および VRF の作成またはインポートセクションで説明されている各サイトのL3Outs。

この使用例では、各サイト固有のテンプレートに個別の L3Out がインポートまたは作成されます。

- 異なるサイトにある2つの異なる L3Outs 用の 2 つの異なる外部 EPG。サイト間 L3Out を使用するための外部 EPG の設定 の説明に従って、同じ手順を使用して両方の外部 EPG を作成できます。

- サイト間 L3Out のコントラクトの作成 で説明されているように、サイトごとに定義された L3Out 外部 EPG の間でコントラクトを使用します。

ストレッチ テンプレート（template-stretched）でコントラクトとフィルタを作成することをお勧めします。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

いずれかの外部 EPG にコントラクトを割り当てます。

1. 外部 EPG が配置されているスキーマとテンプレートを選択します。

2. 外部 EPG を選択します。

3. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

4. 前のセクションで作成したコントラクトとそのタイプを選択します。

コンシューマまたはプロバイダを選択します。

ステップ 4

他の外部 EPG にコントラクトを割り当てます。

1. 外部 EPG が配置されているスキーマとテンプレートを選択します。

2. 外部 EPG が配置されているテンプレートを参照します。

3. 外部 EPG を選択します。

4. 右側のサイドバーで、[+コントラクト (+Contract)] をクリックします。

5. 前のセクションで作成したコントラクトとそのタイプを選択します。

プロバイダまたはコンシューマを選択します。

ステップ 5

適切なサイトにテンプレートを展開します。

Chapter20. PBR を使用したサイト間 L3Out

- PBR を使用したサイト間 L3Out

- サポートされる使用例

- 注意事項と制約事項

- テンプレートの作成

- サービス グラフの設定

- コントラクトのフィルタの作成

PBR を使用したサイト間 L3Out

Cisco Application Centric Infrastructure（ACI）ポリシーベース リダイレクト（PBR）は、ファイアウォールやロード バランサなどのサービス アプライアンス、および侵入防御システム（IPS）のトラフィック リダイレクションを可能にします。一般的な使用例としては、プールしてアプリケーション プロファイルに合わせて調整すること、また容易にスケーリングすることができ、サービス停止の問題が少ないサービス アプライアンスのプロビジョニングがあります。PBR により、コンシューマとプロバイダ エンドポイントの間のコントラクトに基づくサービス アプライアンスの挿入は簡素化されます。このことは、それらすべてが同じ仮想ルーティングおよびフォワーディング（VRF）インスタンスに存在する場合でも成り立ちます。

PBR の展開には、ルート リダイレクト ポリシーおよびクラスタのリダイレクト ポリシーの設定と、これらのポリシーを使用するサービス グラフ テンプレートの作成が含まれます。サービスグラフ テンプレートを展開した後、EPG 間のコントラクトにアタッチして、そのコントラクトに従うすべてのトラフィックが、作成した PBR ポリシーに基づいてサービス グラフ デバイスにリダイレクトされるようにすることができます。これにより、同じ2つのEPG間のどのタイプのトラフィックをL4-L7デバイスにリダイレクトし、どのタイプのトラフィックを直接許可するかを選択できます。

サービス グラフおよびPBRに固有の詳細情報については、 『Cisco APIC Layer 4 to Layer 7 Services Deployment Guide』を参照してください。

マルチサイト展開での PBR のサポート

Cisco Multi-Site は以前より、Cisco APIC リリース 3.2(1) 以降、PBR との EPG 間（East-West）および L3Out-to-EPG（North-South）コントラクトをサポートしています。ただし、サイト間の L3Out-to-EPG（site1の外部エンドポイントから site2 のエンドポイントへのトラフィック）のケースは、両方のサイトにローカル L3Out がある場合にのみサポートされていました。サイト間L3Outの使用例は、サイト間 L3Outの章で説明した例と設定に限定されていました。同様に、PBR とのサービスグラフ統合はありますが、サイト間L3Outはありません。詳細については、 『Cisco Multi-Site and Service Node Integration White Paper』を参照してください。

Cisco APIC リリース 4.2(5) 以降では、サイトを越えて PBRを使用する L3Out-to-EPG（サイト間 L3Out）の使用例が拡張され、アプリケーション EPG にローカル L3Out がない場合や、ローカル L3Out がダウンしている場合に対応できるようになりました。

サポートされる使用例

次の図は、アプリケーション EPG の ACI 内部エンドポイントと、サポートされているサイト間 L3Out with PBR 使用例の別のサイトの L3Out を経由する外部エンドポイント間のトラフィック フローを示しています。

これらの例を設定するワークフローは同じですが、オブジェクトを同じ VRF で作成するか、異なる VRF で作成するか（VRF 間と VRF 内）、およびオブジェクトを展開する場所（ストレッチか非ストレッチか）のみが異なります。

1. L4-L7 デバイスおよび PBR ポリシーの作成と設定の説明に従って、サイトのAPICでL4-L7デバイスを直接作成します。

Nexus Dashboard Orchestrator からデバイスと PBR ポリシーを作成することはできないため、これらのオプションを設定するには、各サイトの APIC に直接ログインする必要があります。

2. テンプレートの作成の説明に従って、必要なテンプレートを作成します。

すべてのサイトに展開されたすべてのオブジェクトを含む単一の拡張テンプレートを作成することをお勧めします。次に、各サイト専用のオブジェクトを含む各サイトの追加テンプレート。

3. サービス グラフの設定の説明に従って、サービスグラフを作成して設定します。

4. コントラクトのフィルタの作成の説明に従って、アプリケーション EPG と別のサイトの L3Out を含む外部 EPG 間のすべてのトラフィックに使用するコントラクトとフィルタを作成します。

5. アプリケーション プロファイルと EPG の作成の説明に従って、VRF とブリッジドメインを使用してアプリケーション EPG を作成します。

アプリケーション EPG を拡張するかどうかに応じて、これらのオブジェクトを異なるテンプレートで作成します。同様に、アプリケーション EPG と L3Out に同じ VRF または異なる VRF を使用することもできます。

6. サイト間 L3Out および VRF の作成またはインポートの説明に従って、L3Out を作成します。

7. サイト間 L3Out を使用するための外部 EPG の設定の説明に従って、L3Out の外部 EPG を作成します。

Inter-VRF と Intra-VRF

アプリケーション EPG と外部 EPG を作成および設定する場合、アプリケーション EPG のブリッジドメインと L3Out に VRF を提供する必要があります。同じ VRF（intra-VRF）を使用するか、異なるVRF（inter-VRF）を使用するかを選択できます。

EPG 間のコントラクトを確立する場合は、1 つの EPG をプロバイダとして指定し、もう 1 つの EPG をコンシューマとして指定する必要があります。

- 両方の EPG が同じ VRF にある場合、どちらか一方がコンシューマまたはプロバイダになることができます。

- EPG が異なる VRF にある場合は、外部 EPG がプロバイダーであり、アプリケーション EPG がコンシューマである必要があります。

拡張された EPG

この使用例は、2 つのサイト間で拡張される単一のアプリケーション EPG と、1 つのサイトでのみ作成される単一の L3Out を示しています。アプリケーション EPG のエンドポイントが L3Out と同じサイトにあるか、他のサイトにあるかに関係なく、トラフィックは同じ L3Out を通過します。ただし、トラフィックは常にエンドポイントのサイトに対してローカルなサービス ノードを通過します。

（注）

外部 EPG が拡張され、各サイトに独自の L3Out があるが、トラフィックの発信元または宛先であるサイトの L3Out がダウンしている場合も、同じフローが適用されます。

インバウンド トラフィック

アウトバウンド トラフィック

サイトローカル EPG

この使用例は、North-South トラフィックに他のサイトの L3Out を使用するサイトローカル アプリケーション EPG を示しています。前の例と同様に、すべてのトラフィックは EPG のサイトローカル サービス グラフ デバイスを使用します。

（注）

外部 EPG が拡張され、各サイトに独自の L3Out があり、EPG のローカル L3Out がダウンしている場合も、同じフローが適用されます。

インバウンド トラフィック

アウトバウンド トラフィック

注意事項と制約事項

サイト間 L3Out を設定する際には次の制約事項が適用されます。

- PBR を使用しないサイト間 L3Out の使用例については、サイト間 L3Outを参照してください。

- PBR を使用したサイト間 L3Out では、次の使用例がサポートされています。

- アプリケーション EPG をコンシューマとする Inter-VRF サイト間 L3Out。

VRF 間コントラクトの場合、L3Out がプロバイダである必要があります。

- アプリケーション EPG がプロバイダまたはコンシューマのいずれかである VRF 内サイト間 L3Out

- PBR を使用したサイト間中継ルーティング（L3Out-to-L3Out）はサポートされていません。

- 上記の使用例は、Cisco APIC リリース 4.2(5) またはリリース 5.1(x) を実行しているサイトでサポートされています。Cisco APIC リリース 5.0(x) を実行しているサイトではサポートされません。

- サポートされるすべてのケースで、アプリケーション EPG をストレッチすることも、ストレッチしないこともできます。

- サービス グラフ デバイスは、サイト間 L3Out 外部 EPG と PBR コントラクトを持つアプリケーション EPG を持たないサイトを含め、各サイトで定義する必要があります。

- ワンアーム展開モデルとツーアーム展開モデルの両方がサポートされています。

ワンアーム展開では、サービス グラフの内部インターフェイスと外部インターフェイスの両方が同じブリッジ ドメインに接続されます。ツーアーム展開では、サービス グラフ インターフェイスは個別の BD に接続されます。

- PBR を使用してロード バランサを設定する場合、ロード バランサと仮想 IP（VIP）の実サーバは同じサイトに存在する必要があります。PBR がディセーブルの場合、ロードバランサと実サーバは異なるサイトに存在できます。

- PBR を設定する場合、宛先は L1、L2、または L3 です。

外部 TEP プールの設定

サイト間 L3Out には、各ポッドの境界リーフ スイッチに外部 TEP アドレスが必要です。外部 TEP プールがすでに設定されている場合 (たとえば、リモート リーフなどの別の機能のために) は、同じプールを使用できます。既存の TEP プールは Nexus Dashboard Orchestrator に継承され、インフラストラクチャ設定の一部として GUI に表示されます。それ以外の場合は、この項で説明されているように、GUI で TEP プールを追加できます。

（注）

すべてのポッドに一意の TEP プールを割り当てる必要があり、ファブリック内の他の TEP プールと重複しないようにする必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[インフラストラクチャ（Infrastructure）] > [インフラの設定（Infra Configuration）]を選択します。

ステップ 3

メインペインの右上にある [インフラの設定 (Configure Infra)] をクリックします。

ステップ 4

左側のサイドバーで、設定するサイトを選択します。

ステップ 5

メイン ウィンドウで、サイト内のポッドをクリックします。

ステップ 6

右側のサイドバーで、[+ TEP プールを追加 (+Add TEP Pool)] をクリックします。

ステップ 7

[TEP プールの追加 (Add TEP pool)] ウィンドウで、そのサイトに対して設定する外部 TEP プールを指定します。

（注）

追加しようとしている TEP プールが他の TEP プールまたはファブリックアドレスと重複していないことを確認する必要があります。

ステップ 8

このプロセスを、サイト間の L3Outs を使用する予定のサイトおよびポッドごとに繰り返します。

L4-L7 デバイスおよび PBR ポリシーの作成と設定

サービス グラフ デバイスを作成し、各サイトの APIC で PBR ポリシーを直接定義する必要があります。

手順

ステップ 1

Cisco APIC にログインします。

ステップ 2

上部のメニューバーで [テナント (Tenants)] をクリックし、デバイスを作成するテナントを選択します。

ステップ 3

L4-L7 デバイスを作成します。

1. 左側のサイドバーで、<tenant-name> > [サービス (Services)] > [L4-L7] カテゴリを展開します。

2. [デバイス (Devices)] カテゴリを右クリックします。

3. [L4-L7 デバイスの作成 (Create L4-L7 Devices)] を選択します。

[L4-L7 デバイスの作成 (Create L4-L7 Devices)] の設定ダイアログが開きます。

ステップ 4

L4-L7 デバイスを設定します。

次の図は、デバイスの設定サンプルを示しています。構成設定は、デバイスのタイプと目的によって異なります。

ステップ 5

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

1. 左側のサイドバーで、<tenant-name> > [ポリシー(Policies)] > [プロトコル (Protocol)] カテゴリを展開します。

2. [L4-L7 ポリシーベース リダイレクト (L4-L7 Policy-Based Redirect)] カテゴリを右クリックします。

3. [L4-L7 ポリシーベース リダイレクトの作成 (Create L4-L7 Policy-Based Redirect)] を選択します。

[L4-L7 ポリシーベース リダイレクトの作成 (Create L4-L7 Policy-Based Redirect)] の設定ダイアログが開きます。

ステップ 6

PBR ポリシーを設定します。

次の図は、宛先 IP と MAC が追加されたサンプル PBR ポリシー設定を示しています。

構成設定は、作成するデバイスとポリシーのタイプと目的によって異なります。たとえば、PBR ポリシーでは、IP-SLA、ハッシュ アルゴリズム、レジリエント ハッシュなどの追加オプションを設定できます。

ステップ 7

他のサイトで必要なデバイスと PBR ポリシーを作成するには、前の手順を繰り返します。

テンプレートの作成

スキーマとテンプレートを作成する場合は、次の方法でテンプレートを分離することをお勧めします。

- すべてのサイト間で拡張されるすべてのオブジェクトを含む、単一の共有テンプレート。

- そのサイトにのみ展開するオブジェクトを含む、サイトごとに 1 つのテンプレート。

この例では、2 つのサイトを使用するため、合計 3 つのテンプレートを作成します。各サイトに 1 つと、ストレッチされた 1 つです。

始める前に

次のものが必要です。

- 注意事項と制約事項を確認し、そこにリストされているすべての前提条件を完了していること。

- 外部 TEP プールの設定およびL4-L7 デバイスおよび PBR ポリシーの作成と設定の説明に従って、個々の APIC サイトの設定を完了していること。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

スキーマを新規作成します。

1. 左側のナビゲーションサイドバーで、[アプリケーション管理 (Application Management)] カテゴリを展開します。

2. [スキーマ (Schemas)] を選択します。

3. [スキーマの追加 (Add Schema)] をクリックして、新しいスキーマを作成します。

[スキーマの編集 (Edit Schema)] ウィンドウが開きます。

ステップ 3

スキーマに名前を付け、テナントを選択します。

1. [名称未設定のスキーマ (Untitled Schema)] をスキーマの名前に置き換えます。

[名称未設定のスキーマ (Untitled Schema)] の名前をクリックして編集します。

2. テンプレートの名前を変更します。

左側のサイドバーで、テンプレートの上にマウスを移動し、[編集 (Edit)] アイコンをクリックします。

たとえば、template-stretchedです。

3. メイン ペインで、[スキーマを作成するエリアをクリックしてテナントを選択してください (To build your schema please click here to select a tenant)] をクリックします。

4. 右側のサイドバーで、[テナントの選択 (Select a Tenant)] ドロップダウンをクリックします。

5. テナントを選択します。

ステップ 4

追加のテンプレートを作成します。

左側のサイドバーで、プラス（+）アイコン（[テンプレート (Templates)] の横にあるもの）をクリックして、サイト固有のテンプレートを追加します。次に、前述の手順と同じ手順に従ってテンプレートに名前を付け、テナントを選択します。

たとえば、template-site1 と template-site2 です。

サービス グラフの設定

次のものが必要です。

- L4-L7 デバイスおよび PBR ポリシーの作成と設定の説明に従い、サイトのAPICごとに直接作成された L4-L7 デバイス。

- テンプレートの作成の説明に従って作成された、これらのオブジェクトを作成するためのテンプレート。

ここでは、サービスグラフの1つ以上のデバイスを設定する方法について説明します。

手順

ステップ 1

サービス グラフを作成するテンプレートを選択します。

template-stretchで単一のサービス グラフを作成しますが、この手順の後半で説明するように、サイトローカルデバイスを設定します。

ステップ 2

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

1. メインペインで、[サービス グラフ (Service Graph)] 領域までスクロールダウンして、[+] アイコンをクリックして新しいコントラクトを作成します。

2. サービス グラフの [表示名 (Display Name)] を入力します。

3. （オプション）[詳細設定 (Advanced Config)] オプションをオンにします。

このオプションでは、最初のサービス グラフ ノードの後にトラフィックを制限するかどうかを設定できます。このオプションを有効にしない場合、デフォルトでは、最初のサービス グラフ ノード以降のすべてのトラフィックが許可されます。

[詳細設定 (Advanced Config)] を有効にする場合は、次の 2 つのオプションのいずれかを選択します。

- [すべて許可 (Allow All)]：契約サブジェクトの特定のフィルタの代わりにデフォルト（permit-all）フィルタを使用します。

これは、[詳細設定 (Advanced Config)] を無効にした場合と同じ動作です。

- [契約からのフィルタ (Filters From Contract)]：コントラクトの件名から特定のフィルタを使用します。

4. 右側のサイドバーで、[サービスノードの定義 (Define Service)]領域までスクロールし、1 つ以上のノードを [デバイスのドロップ (Drop Device)] ボックスにドラッグアンドドロップします。

Multi-Siteは、サービス グラフごとに最大 2 つのノードをサポートします。

ステップ 3

サービス グラフのサイトローカル デバイスを設定します。

この手順は、Multi-Site ドメインの一部であるすべてのサイトに対して実行する必要があります。

1. 左側のサイドバーから、このサービス グラフを展開するサイトの 1 つを選択します。

2. メイン ペインで、作成したサービス グラフを選択します。

3. 右側のサイドバーで、サービス グラフ ノードをクリックします。

4. [デバイスの詳細の選択 (Select Device Details)] ウィンドウで、サイトの APIC で作成したデバイスを選択します。

コントラクトのフィルタの作成

次のものが必要です。

- テンプレートの作成の説明に従って作成された、これらのオブジェクトを作成するためのテンプレート。

このセクションでは、サービスグラフを介してアプリケーション EPG と L3Out 間のトラフィックに使用されるコントラクトとフィルタの作成方法について説明します。

手順

ステップ 1

フィルタを作成します。

1. [Filter (フィルタ)] エリアまでスクロールし、[+] をクリックしてフィルタを作成します。

2. 右側のペインで、フィルタの [表示名 (Display Name)] を入力します。

3. 右側のペインで、[+ エントリ (+ Entry)] をクリックします。

ステップ 2

フィルタの詳細を入力します。

1. フィルタの [名前 (Name)] を指定します。

2. [イーサー タイプ (Ether Type)] と [IP プロトコル (IP Protocol)] を選択します。

たとえば、[ip] と [icmp] です。

3. 他のプロパティは [未指定 (unspecified)] のままにします。

4. [保存 (Save)] をクリックしてフィルタを保存します。

ステップ 3

コントラクトの作成

1. 中央ペインで、[コントラクト (Contracts)] エリアまで下方にスクロールし、[+] をクリックして、コントラクトを作成します。

2. 右側のペインで、コントラクトの [表示名 (Display Name)] を入力します。

3. [範囲 (Scope)] ドロップダウン メニューから、コントラクトの範囲を選択します。

アプリケーション EPG と L3Out が同じ VRF にある場合は、[vrf] を選択します。それ以外の場合は、[inter-VRF] 使用例を設定します。

4. [両方向に適用 (Apply both directions)] が有効になっていることを確認します。

これにより、コンシューマからプロバイダへの方向とプロバイダからコンシューマへの方向の両方に同じフィルタを適用できます。

5. 右側のペインで、[フィルタ チェーン (Filter Chain)] 領域までスクロールし、[+ フィルタ (+ Filter)] をクリックしてフィルタをコントラクトに追加します。

表示される [フィルタ チェーンの追加 (Add Filter Chain)] ウィンドウで、[名前 (Name)] ドロップダウン メニューから前のセクションで追加したフィルタを選択します。
コントラクトで [両方向に適用 (Apply both directions)] オプションを無効にした場合は、他のフィルタ チェーンに対してこの手順を繰り返します。

6. [サービス グラフ (Service Graph)] ドロップダウンから、前のセクションで作成したサービスグラフを選択します。

7. サービス グラフ ノードをクリックしてコネクタを設定します。

ステップ 4

サービス グラフ ノードのコネクタのブリッジ ドメインを選択します。

1. [コンシューマ コネクタ (Consumer Connector)] ブリッジ ドメインを指定します。

2. [プロバイダ コネクタ (Provider Connector)] ブリッジ ドメインを指定します。

3. [完了（Done）] をクリックして保存します。

ステップ 5

コントラクトのサイトローカル プロパティを設定します。

1. 左側のサイドバーで、割り当て先のサイトの下にあるテンプレートを選択します。

2. メイン ペインで、コントラクトを選択します。

3. 右側のサイドバーで、サービス グラフ ノードをクリックします。

4. [クラスタ インターフェイス (Cluster Interface)] を [コンシューマ コネクタ (Consumer Connector)] として選択します。

5. [リダイレクト ポリシー (Redirect Policy)] を [コンシューマ コネクタ (Consumer Connector)] として選択します。

6. [クラスタ インターフェイス (Cluster Interface)] を [プロバイダ コネクタ (Consumer Connector)] として選択します。

7. [リダイレクト ポリシー (Redirect Policy)] を [プロバイダ コネクタ (Consumer Connector)] として選択します。

8. [完了 (Done)]をクリックして、変更内容を保存します。

9. すべてのサイトに対してこの手順を繰り返します。

アプリケーション EPG の VRF およびブリッジ ドメインの作成

ここでは、アプリケーション EPG の VRF およびブリッジ ドメイン (BD) を作成する方法について説明します。

始める前に

次のものが必要です。

- テンプレートの作成の説明に従って作成された、これらのオブジェクトを作成するためのテンプレート。

手順

ステップ 1

VRF および BD を作成するテンプレートを選択します。

VRF および BD を拡張する場合は、template-stretch テンプレートを選択します。それ以外の場合は、サイト固有のテンプレートのいずれかを選択します。

ステップ 2

VRF を作成します。

1. メイン ペインの [VRF] 領域で、プラス (+) 記号をクリックして VRF を追加します。

2. 右側のサイドバーで、フィルタの [表示名 (Display Name)] を入力します。

3. 展開に対して適切である他の VRF 設定を指定します。

ステップ 3

BD を作成します。

1. メイン ペインの [BD] 領域で、プラス (+) 記号をクリックしてBDを追加します。

2. 右側のサイドバーで、フィルタの [表示名 (Display Name)] を入力します。

3. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、前のステップで作成された VRF を選択します。

4. 展開に対して適切である他の BD 設定を指定します。

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

このセクションでは、サービスグラフでサイト間 L3Out を使用するために後で設定するアプリケーション EPG を作成する方法について説明します。

始める前に

次のものが必要です。

- テンプレートの作成の説明に従って作成された、これらのオブジェクトを作成するためのテンプレート。

- コントラクトのフィルタの作成の説明に従って、アプリケーション EPG と外部 EPG の間での通信のために使用するコントラクトを作成していること。

- アプリケーション EPG の VRF およびブリッジ ドメインの作成の説明に従って、EPG に使用する VRF と BD を作成していること

手順

ステップ 1

オブジェクトを作成するテンプレートを選択します。

アプリケーション EPG を拡張する場合は、拡張テンプレートで作成します。アプリケーション EPG をサイトローカルにする場合は、サイト固有のテンプレートで作成します。

ステップ 2

アプリケーション プロファイルと EPG を作成します。

1. メイン ペインで、[+ アプリケーション プロファイル (+ Application profile)] をクリックします。

2. 右側のサイドバーで、プロファイルの [表示名 (Display Name)] を入力します。

3. メイン ペインで、[+ EPGの追加 (+Add EPG)] をクリックします。

ステップ 3

EPG を設定します。

1. メインペインで、アプリケーション EPG を選択します。

2. 右側のサイドバーで、EPG の [表示名 (Display Name)] を入力します。

3. [+コントラクト (+Contract)] をクリックし、コントラクトを選択します。

EPG 通信用に作成したコントラクトを選択し、そのタイプを設定します。

アプリケーション EPG と L3Out 外部 EPG に同じ VRF を使用している場合は、どちらかをコンシューマまたはプロバイダーとして選択できます。ただし、それらが異なるVRFにある場合は、アプリケーション EPG のコントラクトタイプにコンシューマを選択する必要があります。

4. [ブリッジ ドメイン (Bridge Domain)] ドロップダウンで、BD を選択します。

5. 展開に適した他の EPG 設定を指定します。

サイト間 L3Out および VRF の作成またはインポート

ここでは、L3Out を作成し、それを Nexus Dashboard Orchestrator（NDO）GUI で VRF に関連付ける方法について説明します。これは APIC サイトにプッシュされるか、または APIC サイトの 1 つから既存の L3Out をインポートします。次に、この L3Out を外部 EPG に関連付け、その外部 EPG を使用して特定のサイト間 L3Out の使用例を設定します。

（注）

L3Out に割り当てる VRF は、任意のテンプレートまたはスキーマにすることができますが、L3Out と同じテナントに存在する必要があります。

始める前に

次のものが必要です。

- テンプレートの作成の説明に従って作成された、これらのオブジェクトを作成するためのテンプレート。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

[スキーマ (schema)] を選択し、VRF と L3Out を作成またはインポートするテンプレートを選択します。

複数のサイトに関連付けられているテンプレートで L3Out を作成すると、L3Out がそれらすべてのサイトに作成されます。1 つのサイトに関連付けられているテンプレートで L3Out を作成すると、そのサイトでのみ L3Out が作成されます。

ステップ 4

新しい VRF と L3Out を作成します。

既存の L3Out をインポートする場合は、この手順をスキップします。

（注）

NDO で L3Out オブジェクトを作成し、それを APIC にプッシュすることはできますが、L3Out の物理設定は APIC で実行する必要があります。

1. [VRF] エリアまで下にスクロールし、+ アイコンをクリックして新しい VRF を追加します。

右側のサイドバーで、VRF の名前を入力します (例: vrf-l3out )。

2. [L3Out] 領域まで下にスクロールし、+ アイコンをクリックして新しい L3Out を追加します。

右側のスライダで、必要な情報を入力します。

3. L3Out の名前を指定します (例: l3out-intersite。

4. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、前のステップで作成された VRF を選択します。

ステップ 5

既存の L3Out をインポートします。

前の手順で新しい L3Out を作成した場合は、この手順をスキップします。

メインテンプレートビューの上部で [インポート (Import)] をクリックし、インポート元のサイトを選択します。

1. [インポート (Import)] ウィンドウの [ポリシー タイプ(Policy Type)] メニューで、[L3Out] を選択します。

2. インポートする L3Out をチェックします。

3. （オプション）L3Out に関連付けられているすべてのオブジェクトをインポートする場合は、[関係を含める (Include Relationships)] ノブを有効にします。

4. [インポート（Import）] をクリックします。

外部 EPG の設定

このセクションでは、サイト間 L3Out と関連付ける外部 EPG の作成方法について説明します。その後、この外部 EPG とコントラクトを使用すれば、あるサイトのエンドポイント用の特定のユース ケースを設定し、別のサイトの L3Out を使用することができます。

始める前に

次のものが必要です。

- テンプレートの作成の説明に従って作成された、これらのオブジェクトを作成するためのテンプレート。

- サイト間 L3Out および VRF の作成またはインポートの説明に従って作成された、またはインポートされた L3OutとVRF。

手順

ステップ 1

外部 EPG を作成するテンプレートを選択します。

複数のサイトと関連付けられているテンプレート内で外部 EPG を作成した場合、その外部 EPG は、それらすべてのサイト上で作成されます。単一のサイトと関連付けられているテンプレート内で外部 EPG を作成した場合、その外部 EPG は、そのサイト内でのみ作成されます。

ステップ 2

[外部 EPG (External EPG)] エリアまで下方にスクロールして、+ アイコンをクリックして外部 EPG を追加します。

右側のスライダで、必要な情報を入力します。

1. 外部 EPG の名前を入力します。たとえば extEpg のようにします。

2. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、先ほど作成した、L3Out 用の VRF を選択します。

3. [+コントラクト (+Contract)] をクリックし、コントラクトを選択します。

EPG 通信用に作成したコントラクトを選択し、そのタイプを設定します。

アプリケーション EPG と L3Out 外部 EPG に同じ VRF を使用している場合は、どちらかをコンシューマまたはプロバイダーとして選択できます。ただし、それらが異なる VRF にある場合は、外部 EPG のコントラクト タイプのプロバイダを選択する必要があります。

ステップ 3

L3Out をテンプレート レベルで割り当てるには...

外部 EPG 用の L3Out は、テンプレート レベルで選択し、設定できます。その場合、L3Out をサイトローカル レベルで設定することはできません。

1. スキーマ ビューの左サイドバーで、外部 EPG が置かれているテンプレートを選択します。

2. [外部 EPG (External EPG)] エリアまで下方にスクロールして、外部 EPG を選択します。

3. 右サイドバーで、[L3Out] ドロップダウンまで下方にスクロールして、作成したサイト間 L3Out を選択します。

ステップ 4

L3Out をサイトローカル レベルで割り当てるには...

代わりに、L3Out をサイトローカル レベルで外部 EPG に関連付けることもできます。

1. スキーマ ビューの左サイドバーで、外部 EPG が配置されているテンプレートを選択します。

2. [外部 EPG (External EPG)] エリアまで下方にスクロールして、外部 EPG を選択します。

3. 右サイドバーで、[L3Out] ドロップダウンまで下方にスクロールして、作成したサイト間 L3Out を選択します。

この場合、APIC で管理されている L3Out と、オーケストレーションで管理されている L3Out の両方が選択できます。前のセクションでこの目的のため特に作成した L3Out、またはサイトの APIC 内にすでにある L3Out のいずれかを選択します。

Chapter21. レイヤ 3 マルチキャスト

- レイヤ 3 マルチキャスト

- レイヤ 3 マルチキャスト ルーティング

- ランデブー ポイント

- マルチキャスト フィルタ処理

- Layer 3 マルチキャストに関するガイドラインと制限事項

- マルチキャスト ルート マップ ポリシーの作成

- Any-Source Multicast（ASM）マルチキャストの有効化

- ソース固有マルチキャスト（SSM）の有効化

レイヤ 3 マルチキャスト

Cisco マルチキャスト レイヤ 3 マルチキャストは、VRF、ブリッジ ドメイン (BD)、およびマルチキャスト ソースが存在している任意の EPG という、3 つのレベルで有効または無効にできます。

トップ レベルでは、マルチキャスト ルーティングは、任意のマルチキャストが有効な BD を持つ VRF で有効にする必要があります。マルチキャストが有効な VRF では、マルチキャストが有効な BD と、マルチキャスト ルーティングが無効な BD の組み合わせにすることができます。Cisco Nexus Dashboard Orchestrator GUI で VRF のマルチキャスト ルーティングを有効にすると、VRF が拡張されている APIC サイトで有効になります。

いったんマルチキャストで VRF を有効にすると、VRF の下の個別の BD では、マルチキャスト ルーティングを有効にすることができます。BD でレイヤ 3 マルチキャストを設定すると、その BD 上では、プロトコル独立ルーティング (PIM) が有効になります。デフォルトでは、PIM はすべての BD で無効になっています。

特定のサイトローカル EPG に属するソースがリモートサイトにマルチキャスト トラフィックを送信する場合、Nexus Dashboard Orchestrator はシャドウ EPG を作成し、ソース EPG のリモートサイトで対応するサブネット ルートをプログラムする必要があります。リモート Top-of-Rack（TOR）スイッチに適用される設定変更を制限するには、マルチキャスト送信元が存在するローカル EPG でレイヤ 3 マルチキャストを明示的に有効にする必要があります。これにより、これらの EPG に必要な設定のみがリモート サイトにプッシュされます。マルチキャストの受信者が存在する EPG では、レイヤ 3 マルチキャストを有効にする必要はありません。

マルチサイトは、以下のレイヤ 3 マルチキャスト送信元と受信者のすべての組み合わせをサポートしています。

- ACI ファブリック内のマルチキャスト送信元と受信者

- ACI ファブリック外のマルチキャスト送信元と受信者

- ACI ファブリック内のマルチキャスト送信元と外部受信者

- ACI ファブリック内のマルチキャスト受信者と外部送信元

レイヤ 3 マルチキャスト ルーティング

次に示すのは、サイト間レイヤ 3 マルチキャスト ルーティングの高レベルでの概要です。

- マルチキャスト送信元がエンドポイント (EP) として ACI ファブリックに 1 つのサイトで接続され、マルチキャスト フローのストリーミングを開始すると、送信元 VRF の指定フォワーダとして選択された特定のサイトのスパイン スイッチは、すべてのリモート サイトにマルチキャストトラフィックを転送します。これらのサイトでは、ヘッド エンド レプリケーション (HREP) を使用してソースの VRF がストレッチされます。特定のリモートサイトにその特定のグループのレシーバが存在しない場合。トラフィックは受信スパイン ノードでドロップされます。少なくとも 1 つのレシーバがある場合、トラフィックはサイトに転送され、すべてのリーフ ノードに到達します。ここでは VRF が展開されており、その時点でのグループ メンバーシップ情報に基づいてプルーニング/転送が行われます。

- Cisco ACI リリース 5.0(1) よりも前では、マルチキャスト ルーティング ソリューションは、外部マルチキャスト ルータが、PIM-SM エニーソース マルチキャスト（ASM）が展開されたランデブー ポイント（RP）である必要がありました。それぞれのサイトは、指定された拡張 VRF に対し、同じ RP アドレスをポイントしている必要があります。RP は、サイトローカルの L3Out を介して、各サイトに到達できる必要があります。

- 送信元がファブリックの外側、受信者が内側にある場合、受信者は、RP に対する PIM ジョインとしてのサイトローカルの L3Out を介してトラフィックをプルします。送信元は常にサイトローカルの L3Out を介して送信されます。

- 各サイトの受信者には、外部の送信元からのトラフィックを、サイトローカルの L3Out を介して取り込むことが期待されます。そのため、あるサイトの L3Out で受信したトラフィックを他のサイトに送信することはできません。このことは、スパインにおいて、HREP トンネルへ複製中のマルチキャスト トラフィックをプルーニングすることによって行われます。

これを可能にするために、外部送信元から発信され、ローカル L3Out で受信されるすべてのマルチキャスト トラフィックは、外部 VXLAN ヘッダーの特別な DSCP 値で再マーキングされます。スパインはその特定の DSCP 値と一致するため、トラフィックがリモート サイトに複製されることはありません。

- サイトに接続された送信元から発信されたトラフィックは、ローカル L3Out またはリモート サイトに展開された L3Out を介して外部レシーバに送信できます。これに使用される特定の L3Out は、外部ネットワークからその特定のマルチキャストグループの PIM Join を受信したサイトにのみ依存します。

- BD と Nexus Dashboard Orchestrator 上の EPG でマルチキャストが有効にされている場合、BD のすべてのサブネットは、境界リーフ (BL) ノードを含めて、すべてのリーフ スイッチのルーティング テーブルにプログラミングされます。これにより、リーフ スイッチにアタッチされた受信者は、送信側 BD がリーフ スイッチに存在しない場合に、マルチキャスト ソースの到達可能性を判定することができます。BL に対して適切なポリシーが設定されていた場合、サブネットは外部ネットワークにアドバタイズされます。ホストベースのルーティングが BD で設定されている場合、/32 ホストルートがアドバタイズされます。

マルチキャスト ルーティングについての詳細は、IP マルチキャストのセクションを参照してください。これはCisco APIC レイヤ 3 ネットワーク コンフィギュレーション ガイドに記されています。

ランデブー ポイント

マルチキャスト トラフィック ソースは、マルチキャスト アドレス グループにパケットを送信し、そのグループに参加するすべてのユーザーがパケットを受信できるようにします。1 つまたは複数のグループからのトラフィックを受信する受信者はは、通常は Internet Group Management Protocol (IGMP) を使用して、グループへの参加を要求できます。受信者がグループに参加するたびに、そのグループに対してマルチキャスト配信ツリーが作成されます。ランデブー ポイント（RP）は、PIM-SM マルチキャスト ドメイン内にあるルータで、マルチキャスト共有ツリーの共有ルートとして動作します。

ネットワークに冗長 RP 機能を提供する一般的な方法は、ネットワーク内の 2 つ以上の RP が同じエニーキャスト IP アドレスを共有できるようにする、エニーキャスト RP と呼ばれる機能を導入することです。これにより、冗長性とロード バランシングが提供されます。1つの RP デバイスに障害が発生した場合、他の RP はサービスを中断せずに引き継ぐことができます。マルチキャスト ルータは、ネットワーク内のエニーキャスト RP のいずれかに接続して、最も近い RP に転送される join 要求を使用して、マルチキャスト共有ツリーに参加することもできます。

Nexus Dashboard Orchestrator では、次の 2 種類の RP 設定がサポートされています。

- 静的 RP—RP が ACI ファブリックの外部にある場合。

- ファブリックRP：ACI ファブリック内の境界リーフ スイッチがエニーキャストRPとして機能する場合。

任意の数のルータを RP として機能するように設定できます。また、異なるグループ範囲をカバーするようにそれらを設定できます。ACI ファブリック内部で RP を定義する場合には、グループのリストを含むルートマップ ポリシーを作成し、それを VRF に追加するときにこのポリシーを RP にアタッチすることで、RP がカバーするグループを設定できます。ルートマップの作成については マルチキャスト ルート マップ ポリシーの作成 で説明しており、VRF の設定については Any-Source Multicast（ASM）マルチキャストの有効化 で説明しています。

スタティック RP とファブリック RP の両方で、マルチキャストルーティングが有効になっている VRF に PIM 対応境界リーフ スイッチが必要です。L3Out の設定は、L3Out の PIM の有効化を含め、各サイトの APIC から現在ローカルに設定されています。L3Out での PIM の設定の詳細については、Cisco APIC Layer 3 Networking Configuration Guideを参照してください。

マルチキャスト フィルタ処理

マルチキャストフィルタリングは、Cisco APIC リリース 5.0(1) およびNexus Dashboard Orchestrator リリース 3.0(1) 以降で使用可能なマルチキャスト トラフィックのデータプレーン フィルタリング機能です。

Cisco APIC は、誰がマルチキャスト フィードを受信でき、どのソースから受信できるかを制御するために使用できるコントロール プレーン構成をサポートしています。一部の展開で、データプレーン レベルでマルチキャスト ストリームの送信および/または受信を制限することが望ましい場合があります。たとえば、LAN 内のマルチキャスト送信者が特定のマルチキャスト グループにのみ送信できるようにするか、受信者が特定の送信元からのみマルチキャストを受信できるようにする必要がある場合があります。

Nexus Dashboard Orchestrator からのマルチキャスト フィルタリングを構成するには、送信元と宛先のマルチキャスト ルート マップを作成します。それぞれのマップには、マルチキャスト トラフィックの送信元 IP および / またはアクション (許可 (Permit) または 拒否 (Deny)) が関連付けられたグループに基づく 1 つ以上のフィルタ エントリが含まれています。次に、ルートマップをブリッジ ドメインにアタッチして、ブリッジ ドメインでフィルタリングを有効にします。

マルチキャスト ルート マップを作成すると、1 つ以上のフィルタ エンティティを定義できます。一部のエントリは 許可(Permit) アクションで設定でき、その他のエントリは 拒否(Deny) アクションで設定できます。すべてが同じルート マップ内で行われます。各エントリに対して、送信元 IP と グループ IP を提供して、フィルタに一致するトラフィックを定義できます。これらのフィールドの少なくとも 1 つを提供できますが、両方を含むことを選択できます。フィールドの 1 つが空白のままの場合は、すべての値と一致します。

マルチキャスト送信元フィルタリングとマルチキャスト受信先フィルタリングの両方を同じブリッジ ドメインで有効にできます。この例では、1 つのブリッジ ドメインが送信元のみならず、受信先の両方に対してフィルタ処理を提供できます。

BD に対してルート マップを提供しない場合、デフォルト アクションはブリッジ ドメインですべてのマルチキャスト トラフィックを許可することです。しかし、ルート マップを選択する場合、デフォルト アクションはルート マップのフィルタ エントリに明示的に一致しないトラフィックを拒否するように変更されます。

送信元のフィルタ処理

ブリッジ ドメインでトラフィックを送信する任意のマルチキャスト ソースの場合、1 つ以上の送信元とグループ IP フィルタが定義されているルート マップ ポリシーを設定できます。次に、トラフィックはルートマップのすべてのエントリと照合され、次のいずれかのアクションが実行されます。

- トラフィックがルートマップの許可 (Permit) アクションを持つフィルタ エントリと一致する場合、ブリッジドメインはそのソースからそのグループへのトラフィックを許可します。

- トラフィックがルートマップの拒否 (Deny) アクションを持つフィルタ エントリと一致する場合、ブリッジドメインはそのソースからそのグループへのトラフィックを拒否します。

- トラフィックがルート マップの任意のエントリと一致しない場合、デフォルトの 拒否 (Deny) アクションが適用されます。

送信元フィルタは、送信元が接続されている ACI リーフノードで表されるファーストホップ ルータ (FHR) のブリッジ ドメインに適用されます。フィルタは、異なるブリッジ ドメイン内の受信先、同じブリッジ ドメイン内の受信先、および外部受信先がマルチキャストを受信するのを防ぎます。

宛先 (受信先) フィルタ処理

宛先 (受信先) フィルタ処理は、受信先がマルチキャスト処理グループに参加することを妨げません。マルチキャスト トラフィックは、代わりに、送信元 IP とマルチキャスト グループの組み合わせに基づいて、データプレーンで許可またはドロップされます。

送信元フィルタ処理と同様に、マルチキャスト トラフィックが宛先フィルタと一致するとき、次のアクションの一つが起こります。

- トラフィックがルート マップの許可 (Permit) アクションを持つフィルタ エントリと一致する場合、ブリッジ ドメインはその送信元から受信先へのトラフィックを許可します。

- トラフィックがルート マップの拒否 (Deny) アクションを持つフィルタ エントリと一致する場合、ブリッジドメインはその送信元から受信先へのトラフィックを拒否します。

- トラフィックがルート マップの任意のエントリと一致しない場合、デフォルトの 拒否 (Deny) アクションが適用されます。

宛先フィルタは、ACI リーフ ノードが代表する、ラストホップ ルーター (LHR)上のブリッジ ドメインに適用されるため、その他のブリッジ ドメインはマルチキャスト トラフィックを引き続き受信できます。

Layer 3 マルチキャストに関するガイドラインと制限事項

現在のソフトウェアリリースまでは、Cisco Nexus Dashboard Orchestrator を使用して、IGMP または PIM 関連のポリシーなどの特定のマルチキャスト コントロール プレーン フィルタリング ポリシーを各サイトに展開することはできません。したがって、エンドツーエンド ソリューションが機能するためには、各 APIC サイトでの使用例に必要な追加ポリシーを個別に設定する必要があります。各サイトでこれらの設定を構成する方法の詳細については、『 CISCO APIC Layer 3 Network Configuration Guide 』を参照してください。

また、すべてのファブリックの QoS DSCP 変換ポリシーが一貫して設定されていることを確認する必要があります。ACI ファブリックでカスタム QoS ポリシーを作成する場合、ACI QoS レベルと、ファブリックに出入りするパケットのパケットヘッダー DSCP 値との間のマッピングを作成できます。マルチキャストトラフィックがサイト間を通過するには、すべてのサイトで同じACI QoSレベルを同じDSCP値にマッピングする必要があります。各サイトでこれらの設定を構成する方法の詳細については、CISCO APIC and QoS を参照してください。

マルチキャスト フィルタ処理

マルチキャスト フィルタ処理を有効にすると、次の追加のガイドラインが適用されます。

- マルチキャスト フィルタ処理は、IPv4 でのみサポートされています。

- 同じブリッジ ドメインで、マルチキャスト送信元フィルタ処理または受信者フィルタ処理のいずれかまたは両方を有効にできます。

- ブリッジ ドメインにマルチキャスト フィルタを設定しない場合は、そのブリッジドメインで送信元フィルタまたは宛先フィルタ ルート マップを設定しないでください。

デフォルトでは、ルートマップはブリッジ ドメインに関連付けられていません。これは、すべてのマルチキャスト トラフィックが許可されることを意味します。ルートマップがブリッジ ドメインに関連付けられている場合、そのルートマップ内の permit エントリだけが許可され、その他のすべてのマルチキャスト トラフィックはブロックされます。

空のルートマップをブリッジ ドメインに接続すると、ルートマップはデフォルトで deny all を想定するため、すべての送信元とグループがそのブリッジ ドメインでブロックされます。

- マルチキャストフィルタリングは BD レベルで実行され、BD 内のすべての EPG に適用されます。そのため、同じ BD 内の異なる EPG に対して異なるフィルタリング ポリシーを設定することはできません。EPG レベルでより詳細にフィルタリングを適用する必要がある場合は、EPG を個別の BD に設定する必要があります。

- マルチキャスト フィルタ処理は、任意の送信元マルチキャスト (ASM) 範囲にのみ使用することを目的としています。Source-Specific Multicast（SSM）は送信元フィルタリングではサポートされず、受信者フィルタリングでのみサポートされます。

- 送信側と受信側両方のフィルタ処理の場合、ルート マップ エントリはエントリの指定された順序に基づいて照合され、最も小さい番号が最初に一致します。これは、より低い順序のエントリが、リスト内で最長一致でない場合でも、最初に一致することを意味し、より高い順序のエントリは考慮されません。

たとえば、 192.0.3.1/32ソースに対して次のルートマップがあるとします。

順位

送信元 IP

アクション

1

192.0.0.0/16

Permit

2

192.0.3.0/24

拒否

2番目のエントリ (192.0.3.0/24) が送信元 IP と一致する場合でも、最初のエントリ (192.0.0.0/16) は、下位の番号が原因で照合されます。

マルチキャスト ルート マップ ポリシーの作成

このセクションでは、マルチキャスト ルート マップ ポリシーを作成する方法について説明します。ルート マップを作成する理由としては、次のものが考えられます。

- マルチキャスト ソース フィルタリングのためにフィルタのセットを定義する。

- マルチキャスト デスティネーション フィルタリングのためにフィルタのセットを定義する。

- ランデブー ポイント (RP) のためのグループ IP のセットを定義する。

VRF 用の RP を設定する場合、ルート マップを指定しなければ、RP はその VRF のすべてのマルチキャスト グループ範囲（224.0.0.0/4） に合わせて定義されます。または、定義済みのグループまたはグループ範囲を持つルート マップを指定して、RP をそのグループのみに制限することができます。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[メイン メニュー (Main menu)] で、[アプリケーション管理 (Application Management)] > [ポリシー (Policies)] を選択します。

ステップ 3

メイン ペインで、[ポリシーの追加 (Add Policy)] > [マルチキャスト ルート マップ ポリシーの作成 (Create Multicast Route-Map Policy)] を選択します。

ステップ 4

[マルチキャスト ルート マップ ポリシーの追加 (Add Multicast Route-Map Policy)] 画面で、テナントを選択し、ポリシーの名前を指定します。

ステップ 5

ルート マップ エントリを追加するには、[ルート マップ エントリの順序 (Route-Map Entry Order)]の下の [ルートマップ エントリの追加 (Add Route-Map Entry)] をクリックします。

1. [順序 (Order)] と [アクション(Action)]を指定します。

各コンテキストは、1 つ以上の一致基準に基づいてアクションを定義するルールです。

順序は、ルールを評価する順序を決定するために用いられます。

[アクション (Action)] は、一致が検出された場合に実行するアクション (許可 (permit)または拒否 (deny)) を定義します。

2. 必要に応じて、[グループ IP (Group IP)]、[ソース IP (Source IP)]、および [RP IP] 情報を指定します。

このセクションの初めで説明したように、同じマルチキャスト ルート マップのポリシー UI は 2 つの方法で使用できます。マルチキャスト トラフィックのフィルタのセットを設定すること、またはランデブー ポイントの設定をマルチキャスト グループの特定のセットに制限することです。設定する使用例によっては、この画面のフィールドの一部だけを指定すればよい場合もあります。

- マルチキャスト フィルタリングの場合には、フィルタを定義するために、[ソース IP (Source IP)] と [グループ (Group IP)] フィールドを使用します。これらのフィールドの少なくとも 1 つを提供できますが、両方を含むことを選択できます。フィールドの 1 つが空白のままの場合は、すべての値と一致します。

グループ IP の範囲は 224.0.0.0 ～ 239.255.255.255 で、ネットマスクは /8 ～ /32 である必要があります。サブネット マスクを指定する必要があります。

RP IP (ランデブー ポイントの IP) は、マルチキャスト フィルタリング ルート マップでは使用しないので、このフィールドはブランクのままにします。

- ランデブー ポイントの設定では、[グループ IP (Group IP)] フィールドを使用して RP のマルチキャスト グループを定義できます。

グループ IP の範囲は 224.0.0.0 ～ 239.255.255.255 で、ネットマスクは /8 ～ /32 である必要があります。サブネット マスクを指定する必要があります。

ランデブー ポイント設定の場合、RP IP は RP 設定の一部として設定されます。ルート マップをグループ フィルタリングに使用する場合は、ルート マップに RP IP アドレスを設定する必要はありません。この場合には、[RP IP] と [ソース IP (Source IP)] フィールドを空白のままにします。

3. エントリを保存するには、[保存（Save）] をクリックします。

ステップ 6

(オプション) 同じルート ポリシーに複数のエントリを追加する場合は、前の手順を繰り返します。

ステップ 7

[保存 (Save)] をクリックして、ルート マップ ポリシーを保存します。

Any-Source Multicast（ASM）マルチキャストの有効化

以下の手順では、Nexus Dashboard Orchestrator GUI を使用して、VRF、BD、および EPG で ASM マルチキャストを有効にする方法を説明しています。SSMマルチキャストを有効にする場合は、代わりにソース固有マルチキャスト（SSM）の有効化の手順に従います。

始める前に

- Layer 3 マルチキャストに関するガイドラインと制限事項 で説明されている情報を読んで、従っていることを確認してください。

- マルチキャストのフィルタリングを有効にする予定の場合には、マルチキャスト ルート マップ ポリシーの作成 で説明されているように、必要なマルチキャスト ルート マップを作成します。

- ファブリック RP が有効になっている場合、VRF でサイトローカル L3Out の PIM を有効にする必要があります。

これについては、次の手順のステップ 6 で説明します。L3Out 上での PIM の設定の詳細については、Cisco APIC レイヤ 3 ネットワーク コンフィギュレーション ガイドを参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のサイドバーから、[アプリケーション管理 (Application Management)] > [スキーマ (Schemas)]ビューを選択します。

ステップ 3

変更するスキーマをクリックします。

ステップ 4

VRD でレイヤ 3 マルチキャストを有効にします。

まず、サイト間で拡張されている VRF でレイヤ 3 マルチキャストを有効にします。

1. レイヤ 3 マルチキャストを有効にする VRF を選択します。

2. 右のプロパティ サイドバーで、[L3 マルチキャスト (L3 Multicast)] チェックボックスをオンにします。

ステップ 5

1 つ以上のランデブー ポイント (RP) を追加します。

1. VRF を選択します。

2. 右のプロパティ サイドバーで、[ランデブー ポイントの追加 (Add Rendezvous Points)] をクリックします。

3. VRF を選択したまま、右のサイドバーで[ランデブー ポイントの追加 (Add Rendezvous Points)] をクリックします。

4. [ランデブー ポイントの追加 (Add Rendezvous Points)] ウィンドウで、RP の IP アドレスを入力します。

5. RP のタイプを選択します。

- 静的 RP—RP が ACI ファブリックの外部にある場合。

- ファブリック RP—RP が ACI ファブリック内にある場合。

6. (オプション) [マルチキャスト ルートマップ ポリシー (Multicast Route-Map Policy)] ドロップダウンから、以前に設定したルートマップ ポリシーを選択します。

デフォルトでは、入力した RP IP は、ファブリックのすべてのマルチキャスト グループに適用されます。RP を、特定のマルチキャスト グループのセットに制限する場合は、ルート マップ ポリシーでそれらのグループを定義し、ここでそのポリシーを選択します。

ステップ 6

L3Out で PIM を有効にします。

スタティック RP とファブリック RP の両方で、マルチキャストルーティングが有効になっている PIM 対応ボーダー リーフ スイッチが必要です。現在、L3Out 設定は Nexus Dashboard Orchestrator から実行できないため、サイトの APIC で PIM が有効になっていることを直接確認する必要があります。L3Out 上での PIM の設定の詳細については、Cisco APIC レイヤ 3 ネットワーク コンフィギュレーション ガイドを参照してください。

1. サイトの Cisco APIC にログインします。

2. 上部のメニューで [テナント (Tenants)] をクリックし、L3Out を含むテナントを選択します。

3. 左側のナビゲーションメニューで、[ネットワーキング (Networking)] > [L3Outs] > <l3out-name> を選択します。

4. メイン ペインで、[ポリシー (Policy)] タブを選択します。

5. [PIM] オプションを確認します。

Multi-Site は IPv4 マルチキャストのみをサポートします。

ステップ 7

BD でレイヤ 3 マルチキャストを有効にします。

いったん ＶＲＦ で L3 マルチキャストを有効にすると、L3 マルチキャストをブリッジ ドメイン (BD)レベルで有効にすることができます。

1. レイヤ 3 マルチキャストを有効にする BD を選択します。

2. 右のプロパティ サイドバーで、[L3 マルチキャスト (L3 Multicast)] チェックボックスをオンにします。

ステップ 8

(オプション) マルチキャスト フィルタ処理を設定する場合は、送信元と接続先のフィルタ処理のためのルートマップを指定します。

1. BD を選択します。

2. 右のプロパティ サイドバーで、[ルートマップの送信元フィルタ (Route-Map Source Filter)] と [ルートマップの接続先フィルタ (Route-Map Destination Filter)]を選択します。

同じブリッジ ドメインで、マルチキャスト送信元フィルタ処理または受信者フィルタ処理のいずれかまたは両方を有効にできます。

ルート マップを選択しなかった場合、デフォルトの動作は、「ブリッジ ドメインですべてのマルチ トラフィックを許可する」になります。一方、ルート マップを選択すると、デフォルトの動作は、「ルート マップのフィルタ エントリに明示的にマッチしないすべてのトラフィックを拒否」に変わることに注意してください。

ステップ 9

マルチキャスト ソースが 1 つのサイトにあり、他のサイトに拡張されていない場合は、EPG でサイト間マルチキャスト ソース オプションを有効にします。

BD で L3 マルチキャストを有効にしたら、マルチキャスト ソースが接続されている EPG（マルチキャスト対応 BD の一部）でもマルチキャストを有効にする必要があります。

1. レイヤ 3 マルチキャストを有効にする EPG を選択します。

2. 右のサイドバーで、[サイト間マルチキャスト送信元 (Intersite Multicast Source)] チェックボックスをオンにします。

ソース固有マルチキャスト（SSM）の有効化

以下の手順では、Nexus Dashboard Orchestrator GUI を使用して、VRF、BD、および EPG で SSM マルチキャストを有効にする方法を説明しています。ASM マルチキャストを有効にする場合は、代わりにAny-Source Multicast（ASM）マルチキャストの有効化の手順に従います。

始める前に

- Layer 3 マルチキャストに関するガイドラインと制限事項 で説明されている情報を読んで、従っていることを確認してください。

- マルチキャストのフィルタリングを有効にする予定の場合には、マルチキャスト ルート マップ ポリシーの作成 で説明されているように、必要なマルチキャスト ルート マップを作成します。

- サイトローカル レベルでマルチキャスト対応 BD の IGMPv3 インターフェイス ポリシーを設定する必要があることに注意してください。

これについては、次の手順のステップ 8 で説明します。追加情報については、Cisco APIC レイヤ 3 ネットワーク コンフィギュレーション ガイドを参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のサイドバーから、[アプリケーション管理 (Application Management)] > [スキーマ (Schemas)]ビューを選択します。

ステップ 3

変更するスキーマをクリックします。

ステップ 4

VRD でレイヤ 3 マルチキャストを有効にします。

まず、サイト間で拡張されている VRF でレイヤ 3 マルチキャストを有効にします。

1. レイヤ 3 マルチキャストを有効にする VRF を選択します。

2. 右のプロパティ サイドバーで、[L3 マルチキャスト (L3 Multicast)] チェックボックスをオンにします。

ステップ 5

（任意）SSM リスナーのカスタム範囲を設定します。

デフォルトの SSM 範囲は 232.0.0.0/8 で、ファブリック内のスイッチで自動的に設定されます。SSM を使用している場合は、この範囲のグループに参加するようにリスナーを設定することを推奨します。この場合は、この手順をスキップできます。

何らかの理由でリスナー設定を変更しない場合は、最大 4 つの範囲を含むルートマップを作成して、VRF 設定で SSM 範囲を追加できます。新しい範囲を追加すると、その範囲が SSM 範囲になり、ASM に同時に使用できないことに注意してください。

カスタム SSM 範囲の設定は、サイトの APIC で直接行う必要があります。

1. サイトの Cisco APIC にログインします。

2. 上部のメニューで [テナント (Tenants)] をクリックし、VRF を含むテナントを選択します。

3. 左側のナビゲーションメニューで、[ネットワーキング (Networking] > [VRFs] > <VRF-name> > [マルチキャスト (Multicast)]を選択します。

4. メイン ペインで、[パターン ポリシー (Pattern Policy)] タブを選択します。

5. [ルート マップ (Route Map)]ドロップダウン ([ソース固有のマルチキャスト (Source Specific Multicast (SSM))] 領域) から、既存のルート マップを選択するか、[マルチキャストのためのルート マップ ポリシーの作成 (Create Route Map Policy for Multicast)] オプションをクリックして、新しいルート マップ ポリシーを作成します。

既存のルート マップを選択した場合は、ドロップダウンの横にあるアイコンをクリックして、ルート マップの詳細を表示します。

開いたルート マップの詳細ウィンドウまたは [マルチキャストのためのルート マップ ポリシーの作成 (Create Route Map Policy for Multicast)] ウィンドウで [+] をクリックしてエントリを追加します。次に、グループ IP を設定します。新しい範囲を定義するのに必要なのは、グループ IP アドレスだけです。

ステップ 6

（任意）サイトの L3Out で PIM を有効にします。

マルチキャストの送信元や受信者を外部ネットワーク ドメインに接続する場合は、サイトの L3Out でも PIM を有効にする必要があります。現在、L3Out 設定は Nexus Dashboard Orchestrator から実行できないため、サイトの APIC で PIM が有効になっていることを直接確認する必要があります。L3Out 上での PIM の設定の詳細については、Cisco APIC レイヤ 3 ネットワーク コンフィギュレーション ガイドを参照してください。

1. サイトの Cisco APIC にログインします。

2. 上部のメニューで [テナント (Tenants)] をクリックし、L3Out を含むテナントを選択します。

3. 左側のナビゲーションメニューで、[ネットワーキング (Networking)] > [L3Outs] > <l3out-name> を選択します。

4. メイン ペインで、[ポリシー (Policy)] タブを選択します。

5. [PIM] オプションを確認します。

Multi-Site は IPv4 マルチキャストのみをサポートします。

ステップ 7

BD でレイヤ 3 マルチキャストを有効にします。

いったん ＶＲＦ で L3 マルチキャストを有効にすると、L3 マルチキャストをブリッジ ドメイン (BD)レベルで有効にすることができます。

1. レイヤ 3 マルチキャストを有効にする BD を選択します。

2. 右のプロパティ サイドバーで、[L3 マルチキャスト (L3 Multicast)] チェックボックスをオンにします。

ステップ 8

レシーバが接続されているブリッジ ドメインで IGMPv3 インターフェイス ポリシーを有効にします。

SSM を設定しているため、IGMPv3 インターフェイス ポリシーも BD に割り当てる必要があります。デフォルトでは、PIM がイネーブルの場合、IGMP も SVI で自動的にイネーブルになりますが、デフォルト バージョンは IGMPv2 に設定されます。IGMP インターフェイス ポリシーを明示的に IGMPv3 に設定する必要があります。これは、サイトローカル レベルで実行する必要があります。

1. サイトの Cisco APIC にログインします。

2. 上部のメニューで [テナント (Tenants)] をクリックし、BD を含むテナントを選択します。

3. 左側のナビゲーションメニューで、[ネットワーキング (Networking)] > [ブリッジ ドメイン (Bridge Domains)] > <BD-name> を選択します。

4. メイン ペインで、[ポリシー (Policy)] タブを選択します。

5. [IGPM ポリシー (IGMP Policy)] ドロップダウンから IGMP ポリシーを選択するか、[IGMP インターフェイス ポリシーの作成 (Create IGMP Interface Policy)] をクリックして新しいポリシーを作成します。

既存のポリシーを選択した場合は、ドロップダウンの横にあるアイコンをクリックして、ポリシーの詳細を表示します。

開いているポリシーの詳細ウィンドウまたは [マルチキャストのためのルート ポリシーの作成 (Create Route Map Policy for Multicast)] ウィンドウで、[バージョン (Version)] フィールドが [バージョン 3 (Version 3)] に設定されていることを確認します。

ステップ 9

(オプション) マルチキャスト フィルタ処理を設定する場合は、送信元と接続先のフィルタ処理のためのルートマップを指定します。

1. BD を選択します。

2. 右のプロパティ サイドバーで、[ルートマップの送信元フィルタ (Route-Map Source Filter)] と [ルートマップの接続先フィルタ (Route-Map Destination Filter)]を選択します。

同じブリッジ ドメインで、マルチキャスト送信元フィルタ処理または受信者フィルタ処理のいずれかまたは両方を有効にできます。

ルート マップを選択しなかった場合、デフォルトの動作は、「ブリッジ ドメインですべてのマルチ トラフィックを許可する」になります。一方、ルート マップを選択すると、デフォルトの動作は、「ルート マップのフィルタ エントリに明示的にマッチしないすべてのトラフィックを拒否」に変わることに注意してください。

ステップ 10

マルチキャスト ソースが 1 つのサイトにあり、他のサイトに拡張されていない場合は、EPG でサイト間マルチキャスト ソース オプションを有効にします。

BD で L3 マルチキャストを有効にしたら、マルチキャスト ソースが接続されている EPG（マルチキャスト対応 BD の一部）でもマルチキャストを有効にする必要があります。

1. レイヤ 3 マルチキャストを有効にする EPG を選択します。

2. 右のサイドバーで、[サイト間マルチキャスト送信元 (Intersite Multicast Source)] チェックボックスをオンにします。

Chapter22. EPG 優先グループ

- EPG 優先グループ

- 優先グループに対する EPG の設定

EPG 優先グループ

デフォルトでは、Multi-Site アーキテクチャは EPG 間でコントラクトが設定されている場合のみ、EPG 間の通信を許可します。EPG 間にコントラクトがない場合は、EPG 間の通信は明示的に無効になります。優先グループ（PG）機能を使用すると、同じ VRF の一部である複数の EPG を指定して、コントラクトを作成する必要なく、それらの間の完全な通信を可能にすることができます。

優先グループ 対 コントラクト

コントラクト優先グループが設定されている VRF で、EPG に利用可能なポリシー施行には 2 種類あります。

- EPG を含む – 優先グループのメンバーである EPG は、コントラクトなしでグループ内の他のすべての EPG と自由に通信できます。通信は、source-any-destination-any-permit のデフォルト ルールと適切な Multi-Site 変換に基づいています。

- EPG を除外 - 優先グループのメンバーではない EPG は、相互に通信するためにコントラクトが必要です。そうしない場合、デフォルトの source-any-destination-any-deny ルールが適用されます。

コントラクト優先グループ機能を使用すると、拡張 VRF コンテキストのサイト間での EPG 間の通信をより詳細に制御し、設定を容易にすることができます。拡張 VRF の 2 つ以上の EPG がオープン通信を要求する一方で、他は制限された通信しかもてない場合、コントラクト優先グループとフィルタ付きのコントラクトの組み合わせを設定し、EPG 内の通信を正確に制御できます。優先グループから除外されている EPG は、source-any-destination-any-denyデフォルト ルールを上書きするコントラクトがある場合にのみ、他の EPG と通信できます。

拡張 対 シャドウ

複数のサイトの EPG が同じコントラクト優先グループの一部になるように構成されている場合、Nexus Dashboard Orchestrator は他のサイトに各サイトの EPG のシャドウを作成して、EPG からサイト間接続を正しく変換およびプログラムします。次に、コントラクト優先グループポリシーコンストラクトが、EPG 間通信の実際の EPG とシャドウ EPG の間の各サイトに適用されます。

たとえば、Site1 のウェブサービス EPG1 と Site2 のアプリサービス EPG2 がコントラクト優先グループに追加される場合を考察します。次に、EPG1 が EPG2 にアクセスする場合は、最初にサイト 2 のシャドウ EPG1 に変換され、次にコントラクト優先グループを使用して EPG2 と通信できるようになります。適切な BD は、その下の EPG がコントラクト優先グループの一部である場合、拡張されるか、シャドウされます。

VRF 優先グループ設定

優先グループを APIC で直接設定する場合は、個々の EPG で PG メンバーシップを有効にする前に、まず VRF で設定を明示的に有効にする必要があります。VRF の PG 設定が無効になっている場合、EPG はその VRF の優先グループの一部であっても、コントラクトなしでは通信できません。

一方、Nexus Dashboard Orchestrator では、GUI で VRF の PG 設定を管理することはできませんが、代わりに次のように動的に設定を調整します。

- NDO から VRF を作成および管理する場合、NDO は、その VRF に属する EPG が優先グループの一部であるかどうかに基づいて、VRF PG 値を動的に有効または無効にします。

つまり、1 つ以上の EPG を優先グループに追加すると、NDO は VRF の PG 設定を自動的に有効にします。優先グループから最後の EPG を削除すると、NDO は VRF フラグを無効にします。

- VRF で PG オプションを永続的に有効にするには、最初に APIC で VRF の PG を直接有効にしてから、その VRF を NDO にインポートします。

VRF の優先グループからすべての EPG を削除しても、NDO は設定を保持し、自動的に無効にしません。

- 最初に PG 設定を変更せずに APIC から VRF をインポートすると、NDO はオブジェクトを NDO から作成されたかのように管理し、EPG メンバーシップに基づいて PG 設定を動的に上書きします。

制限事項

優先グループは、サイト間 L3Out 外部 EPG ではサポートされません。

優先グループに対する EPG の設定

始める前に

スキーマ テンプレートに 1 つ以上の EPG を追加する必要があります。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[スキーマ (schema)] を選択します。

ステップ 3

変更するスキーマをクリックします。

ステップ 4

優先グループの一部として、スキーマで 1 つ以上の EPG を設定します。

（注）

APIC のいずれかに既存の優先グループがあり、その優先グループから Nexus Dashboard Orchestrator に EPG をインポートすることを計画している場合は、グループ内のすべての EPG をインポートする必要があります。一部の EPG が Nexus Dashboard Orchestrator によって管理され、一部がローカル APIC によって管理される優先グループを設定することはできません。

単一の EPG を追加または削除するには:

1. EPGを選択します。

2. 右側のプロパティ バーで、[優先グループに含める] チェックボックスをオンまたはオフにします。

3. メイン ウィンドウの右上の隅にある [保存] をクリックします。

複数の EPG を一度に追加または削除するには:

1. [アプリケーション プロファイル] タブの右上隅の SELECT をクリックします。

2. 1 つまたは複数のEPGをクリックして選択するか、[すべて選択]をクリックしてすべてのEPGを選択します。

3. [アプリケーション プロファイル (Application Profile)] タブの右上隅の ... をクリックして、[優先グループへの EPG の追加] または [優先グループからの EPG の削除] を選択します。

4. メイン ウィンドウの右上の隅にある [保存] をクリックします。

次のタスク

VRF を選択し、右側のプロパティサイドバーで PREFERRED GROUP EPGS リストを確認すると、優先グループの一部として構成されている EPG の完全なリストを表示できます。

Chapter23. IPN 全体での QoS の保持

- QoS およびグローバル DSCP ポリシー

- DSCP ポリシーの注意事項と制限事項

- グローバル DSCP ポリシーの設定

- EPG およびコントラクトの QoS レベルの設定

QoS およびグローバル DSCP ポリシー

Cisco ACI Quality of Service（QoS）機能を使用すると、ファブリック内のネットワーク トラフィックを分類し、トラフィック フローの優先順位付けとポリシングを行って、ネットワークの輻輳を回避できます。トラフィックがファブリック内で分類されると、QoS 優先度レベルが割り当てられます。この優先度レベルは、ネットワーク全体で最も望ましいパケットフローを実現するためにファブリック全体で使用されます。

Nexus Dashboard Orchestrator のこのリリースは、ソース EPG または特定のコントラクトに基づく QoS レベルの設定をサポートします。追加のオプションは、各ファブリックで直接使用できます。ACI QoSの詳細については、Cisco APICおよびQoS を参照してください。

Cisco ACI ファブリック内でトラフィックが送受信される場合、QoS レベルは VXLAN パケットの外部ヘッダーの CoS 値に基づいて決定されます。マルチポッドやリモート リーフ トポロジなどの特定の使用例では、トラフィックはサイト間ネットワークを通過する必要があります。この場合、Cisco APIC の管理下にないデバイスはパケット内の CoS 値を変更できます。このような場合、パケット内の Cisco ACI QoS レベルと DSCP 値の間のマッピングを作成することで、同じファブリックまたは異なるファブリックの部分間で ACI QoS レベルを維持できます。

DSCP ポリシーの注意事項と制限事項

グローバル DSCP 変換ポリシーを設定する場合は、次の注意事項が適用されます。

（注）

SD-WAN 統合とともにグローバル DSCP 変換ポリシーを使用する場合は、この章をスキップし、注意事項と制限事項の完全なリストを含むすべての情報について、SD-WAN の統合 章を参照してください。

- グローバル DSCP ポリシーは、オンプレミス サイトでのみサポートされます。

- グローバル DSCP ポリシーを定義する場合は、QoS レベルごとに一意の値を選択する必要があります。

- QoS レベルを割り当てる場合、特定のコントラクトまたは EPG 全体に割り当てることができます。

特定のトラフィックに複数の QoS レベルを適用できる場合は、次の優先順位を使用して 1 つだけが適用されます。

- コントラクト QoS レベル：コントラクトで QoS が有効になっている場合は、コントラクトで指定された QoS レベルが使用されます。

- 送信元 EPG QoS レベル：コントラクトに QoS レベルが指定されていない場合、送信元 EPG に設定された QoS レベルが使用されます。

- デフォルトの QoS レベル：QoS レベルが指定されていない場合、トラフィックにはデフォルトでレベル 3 の QoS クラスが割り当てられます。

グローバル DSCP ポリシーの設定

Cisco ACI ファブリック内でトラフィックが送受信される場合、VXLAN パケットの外部ヘッダーの CoS 値に基づいて決定される ACI QoS レベルに基づいて優先順位が付けられます。マルチポッドおよびリモート リーフ トポロジなど、サイト間ネットワークに向けてトラフィックが ACI ファブリックを出ると、QoS レベルは VXLAN カプセル化パケットの外部ヘッダーに含まれる DSCP 値に変換されます。

ここでは、ACI ファブリックを出入りするトラフィックの DSCP 変換ポリシーを定義する方法について説明します。これは、トラフィックが非 ACI ネットワークを通過する必要がある場合に必要です。この場合、Cisco APIC の管理下にないデバイスは、通過するパケットの CoS 値を変更できます。

始める前に

- ACI ファブリック内の Quality of Service（QoS）機能に精通している必要があります。

QoS の詳細については、Cisco APIC and QoS を参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

グローバル DSCP ポリシー設定画面を開きます。

1. [アプリケーション管理 (Application Management)[ > [ポリシー (Policies)] の順に移動します。

2. [グローバル DSCP ポリシー名 (Global DSCP Policy name)] をクリックします。

[ポリシーの編集 (Edit Policy)] ウィンドウが開きます。

ステップ 3

グローバル DSCP ポリシーを更新します。

1. 各 ACI QoS レベルの DSCP 値を選択します。

各ドロップダウンには、使用可能な DSCP 値のデフォルトリストが含まれています。レベルごとに一意の DSCP 値を選択する必要があります。

2. ポリシーを展開するサイトを選択します。

エンドツーエンドの一貫した QoS 動作を実現するために、Multi-Site ドメインの一部であるすべてのサイトにポリシーを展開することを推奨します。

3. 各サイトの展開時にポリシーを有効にするかどうかを選択します。

4. [保存して展開（Save & Deploy）] をクリックします。

保存して展開すると、DSCP ポリシー設定が各サイトにプッシュされます。設定を確認するには、サイトのAPICにログインし、[テナント (Tenants)] > [インフラ (infra)] > [ポリシー (Policies)] > [プロトコル (Protocol)] > [L3 トラフィックの DSCP クラス CoS 変換ポリシー (DSCP class-CoS translation policy for L3 traffic)]に移動します。

次のタスク

グローバル DSCP ポリシーを定義したら、EPG およびコントラクトの QoS レベルの設定 の説明に従って、ACI QoS レベルを EPG またはコントラクトに割り当てることができます。

EPG およびコントラクトの QoS レベルの設定

ここでは、ファブリック内のトラフィックの ACI QoS レベルを選択する方法について説明します。個々のコントラクトまたは EPG 全体に対して QoS を指定できます。

始める前に

- グローバル DSCP ポリシーの設定の説明に従って、グローバル DSCP ポリシーを定義しておく必要があります。

- ACI ファブリック内の Quality of Service（QoS）機能に精通している必要があります。

QoS の詳細については、Cisco APIC and QoS を参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

編集するスキーマを選択します。

1. [アプリケーション管理 (Application Management)[ > [スキーマ (Schemas)] > の順に移動します。

2. 編集するスキーマの名前をクリックするか、[スキーマの追加 (Add Schema)] をクリックして新しいスキーマを作成します。

[ポリシーの編集 (Edit Policy)] ウィンドウが開きます。

ステップ 3

EPG の QoS レベルの選択

1. メイン ペインで、[EPG] エリアまでスクロールダウンして EPG を選択するか、[EPG の追加 (Add EPG)] をクリックして新しい EPG を作成します。

2. 右側のサイドバーで [QoS レベル (QoS Level)]ドロップダウンまでスクロールし、EPG に割り当てる QoS レベルを選択します。

ステップ 4

EPG の QoS レベルの選択

1. メインペインで、[コントラクト (Contract)] 領域までスクロールダウンしてコントラクトを選択するか、[+] アイコンをクリックして新しいコントラクトを作成します。

2. 右側のサイドバーで、[QoS レベル (QoS Level)] ドロップダウンまでスクロールし、コントラクトに割り当てる QoS レベルを選択します。

Chapter24. SD-WAN の統合

- SD-WAN の統合

- SD-WAN 統合の注意事項と制約事項

- vManage コントローラの追加

- グローバル DSCP ポリシーの設定

- EPG およびコントラクトの QoS レベルの設定

SD-WAN の統合

Cisco ソフトウェア定義ワイド エリア ネットワーク（SD-WAN）は、クラウド提供型のオーバーレイ WAN アーキテクチャです。単一のファブリックにより、ブランチをデータセンターとマルチクラウド環境に接続できるのが特長です。Cisco SD-WAN は、アプリケーションの予測可能なユーザエクスペリエンスを保証し、SaaS、IaaS、および PaaS 接続を最適化し、オンプレミスまたはクラウドで統合セキュリティを提供します。分析機能による可視化とインサイトは、問題を切り分けて迅速に解決するために役立ちます。プランニングと what-if シナリオ分析に欠かせない、高度なデータ解析も提供します。

データプレーン側では、SD-WAN は ASR または ISR ルータをエッジデバイスとして展開し（次の図では cEdge として表示）、各ファブリックのスパイン スイッチはこれらのエッジ デバイスに接続します。SD-WANは vManage と呼ばれる別のコントローラによって管理されます。これにより、サービスレベル契約（SLA）ポリシーを定義して、DSCP 値に基づいて SD-WAN 内の各パケットのパスを選択する方法を決定できます。

Multi-Site と SD-WAN の統合

Cisco Nexus Dashboard Orchestrator のリリース 3.0(2) では、SD-WAN 統合のサポートが追加されています。vManage コントローラから SLA ポリシーをインポートし、各 SLA ポリシーに DSCP 値を割り当て、vManage コントローラに DSCP から SLA へのマッピングを通知するように NDO を設定できます。これにより、事前設定された SLA ポリシーを適用して、SD-WAN 上のサイト間トラフィックのパケット損失、ジッター、および遅延のレベルを指定できます。SD-WAN 機能を提供する外部デバイスマネージャとして設定されている vManage コントローラは、SLA ポリシーで指定された損失、ジッター、および遅延パラメータを満たす最適な WAN リンクを選択します。

マルチサイト SD-WAN の統合により、複数のファブリック間のトラフィックが SD-WAN ネットワークを通過できるようになり、リモートサイトからのリターントラフィックが割り当てられた ACI QoS レベルを維持できるようになります。Cisco NDO を vManage に登録すると、SLA ポリシーがインポートされ、ACI QoS レベルを適切な DSCP 値に変換できます。NDO は、SD-WAN を通過するトラフィックに DSCP 変換ポリシーを適用して、リターントラフィックで Quality of Service を有効にします。

リリース 3.0(2) では、NDO GUI で契約および EPG に直接 ACI QoS レベルを割り当てることもできます。トラフィックがファブリックを離れるたびに、その QoS レベルが DSCP 値に変換され、vManage が SD-WAN 経由のトラフィックのパスを選択するために使用されます。

SD-WAN 統合の注意事項と制約事項

Multi-Site と SD-WAN の統合を有効にする場合は、次のガイドラインが適用されます。

- サイト間の east-west トラフィックに対して均一なユーザー QoS レベルと DSCP 変換を有効にするには、各ファブリックのスパイン スイッチを直接または複数のホップを介して SD-WAN エッジ デバイスに接続する必要があります。

これは、リーフ スイッチを SD-WAN エッジ デバイスに接続する必要がある north-south トラフィックの APIC SD-WAN 統合の既存の実装とは対照的です。

- グローバル DSCP ポリシーは、オンプレミス サイトでのみサポートされます。

- SD-WAN 統合は、Cisco Application Services Engine の Nexus Dashboard Orchestrator 展開でのみサポートされます。

詳細については、Deployment Overviewの章（Cisco Nexus Dashboard Orchestrator Installation and Upgrade Guide）を参照してください。

- グローバル DSCP ポリシーを定義する場合は、QoS レベルごとに一意の値を選択する必要があります。

- 既存の DSCP ポリシー値に加えて、vManage から最大 4 つの SLA ポリシーをインポートできます。値は、41、42、43、45、47、49のいずれかです。

- SLA ポリシーは、Cisco vManage ですでに定義されている必要があります。

- QoS レベルを割り当てる場合、特定のコントラクトまたは EPG 全体に割り当てることができます。

特定のトラフィックに複数の QoS レベルを適用できる場合は、次の優先順位を使用して 1 つだけが適用されます。

- コントラクト QoS レベル：コントラクトで QoS が有効になっている場合は、コントラクトで指定された QoS レベルが使用されます。

- 送信元 EPG QoS レベル：コントラクトに QoS レベルが指定されていない場合、送信元 EPG に設定された QoS レベルが使用されます。

- デフォルトの QoS レベル：QoS レベルが指定されていない場合、トラフィックにはデフォルトでレベル 3 の QoS クラスが割り当てられます。

vManage コントローラの追加

このセクションでは、vManage コントローラを Nexus Dashboard Orchestrator に追加して、設定済みの SLA ポリシーをインポートする方法について説明します。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

vManage コントローラを追加します。

1. [インフラストラクチャ (Infrastructure)] > [SD-WAN]に移動します。

2. [ドメイン コントローラの追加 (Add Domain Controller)] をクリックします。

[ドメインの追加 (Add Domain)] ウィンドウが開きます。

ステップ 3

vManage コントローラ情報を入力します。

表示された [エントリの追加 (Add Entry)] ウィンドウで、次の情報を入力します。

- NDO に表示する vManage ドメインの名前。

- デバイスの IP アドレスまたは完全修飾ドメイン名（FQDN）。

- vManage コントローラへのログインで使用するユーザ名とパスワード。

[追加 (Add)] をクリックしてvManageドメインを保存します。vManage コントローラの情報を入力した後、既存の SLA ポリシーのリストがメイン ペインに表示されるまでに最大 1 分かかります。

次のタスク

グローバル DSCP ポリシーの設定の説明に従って、Nexus Dashboard Orchestrator でグローバル DSCP ポリシーを定義します。

グローバル DSCP ポリシーの設定

Cisco ACI ファブリック内でトラフィックが送受信される場合、VXLAN パケットの外部ヘッダーの CoS 値に基づいて決定される ACI QoS レベルに基づいて優先順位が付けられます。トラフィックがスパインスイッチからサイト間ネットワークへの ACI ファブリックを出ると、QoS レベルは VXLAN カプセル化パケットの外部ヘッダーに含まれる DSCP 値に変換されます。

ここでは、ACI ファブリックを出入りするトラフィックの DSCP 変換ポリシーを定義する方法について説明します。これは、トラフィックが非 ACI ネットワークを通過する必要がある場合（たとえば、Cisco APIC の管理下にないデバイスが通過するパケットの CoS 値を変更する可能性がある SD-WAN で区切られた複数のファブリック間）に必要です。

始める前に

- vManage コントローラの追加の説明に従って、vManage コントローラを NDO に追加する必要があります。

- ACI ファブリック内の Quality of Service（QoS）機能に精通している必要があります。

QoS の詳細については、Cisco APIC and QoS を参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

グローバル DSCP ポリシー設定画面を開きます。

1. [アプリケーション管理 (Application Management)[ > [ポリシー (Policies)] の順に移動します。

2. [グローバル DSCP ポリシー名 (Global DSCP Policy name)] をクリックします。

[ポリシーの編集 (Edit Policy)] ウィンドウが開きます。

ステップ 3

グローバル DSCP ポリシーを更新します。

1. 各 ACI QoS レベルの DSCP 値を選択します。

各ドロップダウンには、使用可能な DSCP 値のデフォルト リストと、vManage SLA ポリシーからインポートされた値（Voice-And-Video SLA（42）など）が含まれます。

2. ポリシーを展開するサイトを選択します。

エンドツーエンドの一貫した QoS 動作を実現するために、Multi-Site ドメインの一部であるすべてのサイトにポリシーを展開することを推奨します。

3. 各サイトの展開時にポリシーを有効にするかどうかを選択します。

4. [保存して展開（Save & Deploy）] をクリックします。

保存して展開すると、DSCP ポリシー設定が各サイトにプッシュされます。設定を確認するには、サイトのAPICにログインし、[テナント (Tenants)] > [インフラ (infra)] > [ポリシー (Policies)] > [プロトコル (Protocol)] > [L3 トラフィックの DSCP クラス CoS 変換ポリシー (DSCP class-CoS translation policy for L3 traffic)]に移動します。

次のタスク

グローバルDSCPポリシーを定義した後、の説明に従って、ECIまたはコントラクトにACI QoSレベルを割り当てることができます。 EPG およびコントラクトの QoS レベルの設定

EPG およびコントラクトの QoS レベルの設定

ここでは、ファブリック内のトラフィックの ACI QoS レベルを選択する方法について説明します。個々のコントラクトまたは EPG 全体に対して QoS を指定できます。

始める前に

- vManage コントローラの追加の説明に従って、vManage コントローラを NDO に追加する必要があります。

- グローバル DSCP ポリシーの設定の説明に従って、グローバル DSCP ポリシーを定義しておく必要があります。

- ACI ファブリック内の Quality of Service（QoS）機能に精通している必要があります。

QoS の詳細については、Cisco APIC and QoS を参照してください。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

編集するスキーマを選択します。

1. [アプリケーション管理 (Application Management)[ > [スキーマ (Schemas)] > の順に移動します。

2. 編集するスキーマの名前をクリックするか、[スキーマの追加 (Add Schema)] をクリックして新しいスキーマを作成します。

[スキーマの編集 (Edit Schema)] ウィンドウが開きます。

ステップ 3

EPG の QoS レベルの選択

1. メイン ペインで、[EPG] エリアまでスクロールダウンして EPG を選択するか、[EPG の追加 (Add EPG)] をクリックして新しい EPG を作成します。

2. 右側のサイドバーで [QoS レベル (QoS Level)]ドロップダウンまでスクロールし、EPG に割り当てる QoS レベルを選択します。

EPGからのサイト間トラフィックがSD-WANネットワーク全体で目的のSLAで処理されるように、事前に設定されたグローバルDSCPポリシーに基づいてQoSレベルを選択する必要があります。

ステップ 4

EPG の QoS レベルの選択

1. メインペインで、[コントラクト (Contract)] 領域までスクロールダウンしてコントラクトを選択するか、[+] アイコンをクリックして新しいコントラクトを作成します。

2. 右側のサイドバーで、[QoS レベル (QoS Level)] ドロップダウンまでスクロールし、コントラクトに割り当てる QoS レベルを選択します。

2 つの EPG 間のサイト間トラフィックが SD-WAN ネットワーク全体で目的の SLA で処理されるように、事前に設定されたグローバル DSCP ポリシーに基づいて QoS レベルを選択する必要があります。

Chapter25. SR-MPLS 経由で接続されたサイト

- SR-MPLSおよびマルチサイト

- SR-MPLS テナントの要件と注意事項

- SR-MPLS ルート マップ ポリシーの作成

- SR-MPLS 設定のテンプレートの有効化

- VRF および SR-MPLS L3Out の作成

- サイトローカル VRF 設定の構成

- サイトローカル SR-MPLS L3Out 設定の構成

- MPLS ネットワークにより区切られた EPG 間の通信

- 設定の展開

SR-MPLSおよびマルチサイト

Nexus Dashboard Orchestrator、リリース 3.0(1) および APIC リリース 5.0(1) 以降では、マルチサイト アーキテクチャにより、MPLS ネットワークを介して、サイト数 APIC への接続がサポートされています。

代表的な Multi-Site デプロイでは、サイト間トラフィックは、VXLAN カプセルかを介したサイト間ネットワーク (ISN) を通じて転送されます。

Multi-Site と ISN

リリース 3.0(1), MPLS ネットワークは、WAN を介したサイト間通信を許可する ISN に加えて、またはその代わりに使用できます。

Multi-Site と ISN

次のセクションでは、Nexus Dashboard Orchestrator からこれらのサイトにデプロイされるスキーマを管理するためのガイドライン、制限事項、およびそれ特定の設定について説明します。MPLS ハンドオフ、サポートされている個々のサイトのトポロジ (リモート リーフ サポートなど)、ポリシー モデルは、『Cisco APIC Layer 3 ネットワーキング設定ガイド』で入手可能です。

注意事項と制約事項

Nexus Dashboard Orchestrator により管理される SR-MPLS ネットワークに接続される APIC サイトを追加する場合、次のことにご留意ください。

- ノードの更新など、トポロジーへの変更は、サイト接続性情報の更新 の説明に従ってサイトの構成が更新されるまで、Orchestrator 構成には反映されません。

- SR-MPLS ネットワークに接続されているサイトに展開されているオブジェクトとポリシーは、その他のサイトにストレッチできません。

テンプレートを作成し、テナントを指定するときに、テナントで SR-MPLS オプションを有効にする必要があります。これにより、そのテンプレートを単一の ACI サイトにのみマッピングできるようになります。

- SR-MMPLS ネットワークを通じて接続あれているサイトに展開されているテナントは、SR-MPLS 設定に特別の固有の構成オプションのセットをもちます。テナント構成は、Multi-Site 構成ガイド、リリース 3.1(x) の「テナント管理」の章で説明されています。

サポート対象ハードウェア

SR-MPLS 接続は、以下のプラットフォームに対してサポートされています。

- ボーダー リーフ スイッチ：「FX」、「FX2」、および「GX」 スイッチ モデル。

- スパイン スイッチ:

- ラインカード名の末尾に「LC-EX」、「LC-FX」、および「GX」が付いたモジュラ スパイン スイッチ モデル。

- Cisco Nexus 9000 シリーズ N9K-C9364C および N9K-C9332C 固定スパイン スイッチ。

- DC-PEルータ：

- Network Convergence System（NCS）5500 シリーズ

- ASR 9000 シリーズ

- NCS 540 または 560 ルータ

SR-MPLS インフラ L3Out

次のセクションの説明に従って、SR-MPLS ネットワークに接続されたファブリックの SR-MPLS Infra L3Out を作成する必要があります。SR-MPLS L3Out Infra を作成するときには、次の制約が適用されます。

- 各 SR-MPLS L3Out Infra L3Out には固有の名前が必要です。

- 異なるルーティング ドメインに接続されているロケーションごとに複数の SR-MPLS Infra L3Out を持つこと、その際に同じボーダー リーフ スイッチは複数の L3Out にあること、各ルーティング ドメインに向かって VRF のルーティング ポリシーをエクスポートすることが可能です。

- ボーダー リーフ スイッチが複数の SR-MPLS Infra L3Out にあることができる場合でも、ボーダー リーフ スイッチ/プロバイダ エッジ ルーターの組み合わせは 1 つの SR-MPLS L3Out になければなりません。ユーザ VRF/ボーダー リーフ スイッチ/プロバイダ エッジ ルートの組み合わせに対して 1 つのルーティング ポリシーのみが存在できるからです。

- 複数のポッドおよびリモート ロケーションから SR-MPLS 接続を確立する必要がある場合は、SR-MPLS 接続を使用するポッドおよびリモート リーフ ロケーションのそれぞれに異なる SR-MPLS インフラ L3Out があることを確認します。

- ポッドの 1 つが SR-MPLS ネットワークに直接接続されていないマルチポッドまたはリモートリーフトポロジがある場合、SR-MPLS ネットワークを宛先とするそのポッドのトラフィックは、SR-MPLS L3Out を 持つ別のポッドへの標準 IPN パスを使用します。その後、トラフィックは他のポッドの SR-MPLS L3Out を使用して、SR-MPLS ネットワーク全体の宛先に到達します。

- 複数の VRF からのルートは、1 つの SR-MPLS Infra L3Out から、この SR-MPLS Infra L3Out のノードに接続されているプロバイダ エッジ（PE）ルーターにアドバタイズできます。

PE ルータは、ボーダー リーフに直接接続することも、他のプロバイダー（P）ルータを介して接続することもできます。

- アンダーレイ設定は、1 つのロケーションに対して複数の SR-MPLS Infra L3Out にわたって異なるか、同じ場合があります。

たとえば、両方に対して別のプロバイダ ルーターに接続されたアンダーレイをもつ、ドメイン 1 の PE-1 とドメイン 2 の PE-2 に同じボーダー リーフ スイッチが接続されていると想定します。この場合、2 つの SR-MPLS Infra L3Out が作成されます。PE-1 に対して 1 つと PE-2 に対して 1 つです。しかしアンダーレイの場合、プロバイダ ルーターへの同じ BGP ピアになります。インポート/エクスポート ルートマップは、ユーザ VRF の対応するルート プロファイル設定に基づいて、PE-1 および PE-2 への EVPN セッションに設定されます。

MPLS スイッチングに関するガイドラインと制限事項

次に、MPLS QoS のデフォルトの動作を示します。

- 境界リーフ スイッチ上のすべての受信 MPLS トラフィックは QoS レベル 3（デフォルトの QoS レベル）に分類されます。

- 境界リーフ スイッチは、再マーキングなしで SR-MPLS からのトラフィックの元の DSCP 値を保持します。

- 境界リーフ スイッチは、デフォルトの MPLS EXP（0）のパケットを SR-MPLS ネットワークに転送します。

次に、MPLS カスタム QoS ポリシーを設定する際のガイドラインと制約事項を示します。

- データ プレーン ポリサー（DPP）は、SR-MPLS L3Out ではサポートされていません。

- レイヤ 2 DPP は、MPLS インターフェイスの入力方向で動作します。

- レイヤ 2 DPP は、出力カスタム MPLS QoS ポリシーがない場合、MPLS インターフェイスの出力方向で動作します。

- VRF レベルのポリシングはサポートされていません。

SR-MPLS QoS ポリシーの作成

このセクションでは、MPLS ネットワーク経由で接続されているサイトの SR MPLS QoS ポリシーを設定する方法について説明します。該当するサイトがない場合は、このセクションをスキップできます。

SR MPLS カスタム QoS ポリシーは、MPLS QoS 出力 ポリシーで定義された着信 MPLS EXP 値に基づいて、SR-MPLS ネットワークから送信されるパケットのプライオリティを定義します。これらのパケットは、ACI ファブリック内にあります。また、MPLS QoS 出力ポリシーで定義された IPv4 DSCP 値に基づく MPLS インターフェイスを介して ACI ファブリックから離れるパケットの CoS 値および MPLS EXP 値をマーキングします。

カスタム出力ポリシーが定義されていない場合、デフォルトの Qos レベル（Level3）がファブリック内のパケットに割り当てられます。カスタム出力ポリシーが定義されていない場合、デフォルトの EXP 値（0）がファブリックから離れるパケットにマーキングされます。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[メイン メニュー (Main menu)] で、[アプリケーション管理 (Application Management)] > [ポリシー (Policies)] を選択します。

ステップ 3

メイン ペインで、[ポリシーの追加 (Add Policy)] > [QoS ポリシーの作成 (Create QoS Policy)] を選択します。

ステップ 4

[QoS ポリシーの追加 (Add QoS Policy)] 画面で、ポリシーの名前を入力します。

ステップ 5

入力 QoS 変換ルールを追加するには、[入力ルールの追加 (Add Ingress Rule)] をクリックします。

これらのルールは、MPLS ネットワークから ACI ファブリックに入力されるトラフィックに適用され、着信パケットの EXP ビット値を ACI QoS レベルにマッピングするため、また、パケットが ACI ファブリック内にある間に、VXLAN ヘッダーに DiffServ コードポイント（DSCP）値を設定するためにも使用されます。

値は、境界リーフでカスタム QoS 変換ポリシーを使用して取得されます。再マーキングなしの SR-MPLS からのトラフィックの元の DSCP 値。カスタム ポリシーが定義されていないか、一致していない場合、デフォルトのQoSレベル（Level3）が割り当てられます。

1. [EXP 照合開始 (Match Exp From)] と [EXP 照合終了 (Match EXP To)] フィールドで、照合する入力 MPLS パケットの EXP 範囲を指定します。

2. [キューの優先順位 (Queuing Priority)] ドロップダウンから、マッピングする ACI QoS レベルを選択します。

これは、ACI ファブリック内のトラフィックに割り当てる QoS レベルで、ACI はファブリック内のトラフィックのプライオリティを決めるために使用します。オプションの範囲は Level1 〜 Level6 です。デフォルト値は Level3です。このフィールドで選択しない場合、トラフィックには自動的に Level3 の優先順位が割り当てられます。

3. [DSCP 設定 (Set DSCP)] ドロップダウンから、パケットが ACI ファブリック内にある場合にパケットに割り当てる DSCP 値を選択します。

指定された DSCP 値は、外部ネットワークから受信した元のトラフィックに設定されるため、トラフィックが宛先 ACI リーフ ノードで VXLAN カプセル化解除された場合にのみ再公開されます。

値を [未指定 (Unspecified)] に設定すると、パケットの元の DSCP 値が保持されます。

4. [Cos 設定(Set CoS)] ドロップダウンから、パケットが ACI ファブリック内にある場合にパケットに割り当てる CoS 値を選択します。

指定された CoS 値は、外部ネットワークから受信した元のトラフィックに設定されるため、トラフィックが宛先 ACI リーフ ノードで VXLAN カプセル化解除された場合にのみ再公開されます。

値を [未指定 (Unspecified)] に設定すると、パケットの元の CoS 値が保持されますが、これはファブリックで CoS 保存オプションが有効になっている場合のみです。CoS 保存の詳細については、「Cisco APIC and QoS」を参照してください。

5. チェックマーク アイコンをクリックして、ルールを保存します。

6. 追加の入力 QoS ポリシー ルールについて、この手順を繰り返します。

ステップ 6

出力 QoS 変換ルールを追加するには、[出力ルールの追加 (Add Egress Add Rule)] をクリックします。

これらのルールは、MPLS L3Out 経由で ACI ファブリックから発信されるトラフィックに適用され、パケットの IPv4 DSCP 値を MPLS パケットの EXP 値および内部イーサネットフレームの CoS 値にマッピングするために使用されます。

分類は、EPG および L3Out トラフィックに使用される既存のポリシーに基づいて非境界リーフ スイッチで行われます。カスタム ポリシーが定義されていないか、一致していない場合、デフォルトの EXP 値 0 がすべてのラベルでマークされます。EXP 値は、デフォルト ポリシー シナリオとカスタム ポリシー シナリオの両方でマークされ、パケット内のすべての MPLS ラベルで行われます。

カスタム MPLS 出力ポリシーは、既存の EPG、L3out、および契約 QoS ポリシーをオーバーライドできます。

1. [DSCP 照合開始 (MATCH DSCP From)] と [DSCP 照合終了 (MATCH DSCP To)] ] ドロップダウンを使用して、出力 MPLS パケットのプライオリティを割り当てるために一致させる ACI ファブリックパケットの DSCP 範囲を指定します。

2. [MPLS EXP の設定 (SET MPLS EXP)] ドロップダウンから、出力 MPLS パケットに割り当てる EXP 値を選択します。

3. [CoS の設定(Set CoS)] ドロップダウンから、出力 MPLS パケットに割り当てる CoS 値を選択します。

4. チェックマーク アイコンをクリックして、ルールを保存します。

5. 追加の出力 QoS ポリシー ルールについて、この手順を繰り返します。

ステップ 7

[保存 (Save)] をクリックして、QoS ポリシーを保存します。

次のタスク

QoS ポリシーを作成したら、t-multi-site-infra-config-srmpls.xhtml#Cisco_Task_in_List_GUI.dita_e0aa8798-b526-4b6c-a912-52f4a003d406 の説明に従って mpls 接続を有効にし、MPLS L3Out を設定します。

SR-MPLS インフラ L3Out の作成

このセクションでは、SR-MPLS ネットワーク経由で接続されているサイトの SR-MPLS L3Out を設定する方法について説明します。

- SR-MPLS インフラ L3Out は、境界リーフスイッチで設定され、SR-MPLS ハンドオフに必要なアンダーレイ BGP-LU およびオーバーレイ MP-BGP EVPN セッションを設定するために使用されます。

- SR-MPLS インフラ L3Out は、ポッドまたはリモート リーフ スイッチ サイトにスコープされます。

- 1 つの SR-MPLS インフラ L3Out 内の境界リーフ スイッチまたはリモート リーフ スイッチは、1 つ以上のルーティング ドメイン内の 1 つ以上のプロバイダー エッジ（PE）ルータに接続できます。

- ポッドまたはリモート リーフ スイッチ サイトには、1 つ以上の SR-MPLS インフラ L3Out を設定できます。

始める前に

次のものが必要です。

- Cisco ACI サイトの追加 で説明しているように、MPLS ネットワークを経由して接続されているサイトを追加したこと。

- 必要に応じ、SR-MPLS QoS ポリシーの作成 で説明しているように、SR-MPLS QoS ポリシーを作成したこと。

手順

ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

サイトで SR-MPLS 接続が有効になっていることを確認します。

1. メインのナビゲーション メニューで、[インフラストラクチャ (Infrastructure)] > [インフラの設定 (Infra Configuration)]を選択します。

2. [インフラの設定 (Infra Configuration)] ビューで、[インフラ設定 (Configure Infra)] をクリックします。

3. 左側のペインの [サイト (Sites)] の下で、特定のサイトを選択します。

4. 右側の [<サイト名> 設定 (Settings)] ペインで、[SR-MPLS 接続性 (SR-MPLS Connectivity)] ノブを有効にして、セグメント ルーティング グローバル ブロック (SRGB) の範囲を指定します。

SID インデックスは、MPLS トランスポートループバックの各ノードで設定されます。SID インデックス値は BGP-LU を使用してピア ルータにアドバタイズされ、ピア ルータは SID インデックスを使用してローカル ラベルを計算します。

セグメント ルーティング グローバル ブロック（SRGB）は、ラベル スイッチング データベース (LSD) でセグメント ルーティング (SR) 用に予約されているラベル値の範囲です。SID インデックスは、MPLS トランスポートループバックの各ノードで設定されます。SID インデックス値は BGP-LU を使用してピア ルータにアドバタイズされ、ピア ルータは SID インデックスを使用してローカル ラベルを計算します。

デフォルトの範囲は 16000 ～ 23999 です。

ステップ 3

メインのペインで、 ポッド内の[+SR-MPLS L3Out の追加 (+Add SR-MPLS L3Out)] をクリックします。

ステップ 4

右側の [プロパティ (Properties)] ペインで、SR-MPLS L3Out の名前を入力します。

ステップ 5

（任意）[QoS ポリシー (QoS Policy)] ドロップダウンで、MPLS トラフィックのために作成した QoS ポリシーを選択します。

SR-MPLS QoS ポリシーの作成で作成した QoS ポリシーを選択します。

それ以外の場合、カスタムQoSポリシーを割り当てないと、次のデフォルト値が割り当てられます。

- 境界リーフ スイッチ上のすべての着信 MPLS トラフィックは、QoS レベル 3（デフォルトの QoS レベル）に分類されます。

- 境界リーフ スイッチは次の処理を実行します。

- 再マーキングなしで SR-MPLS からのトラフィックの元の DSCP 値を保持します。

- CoS 保存が有効な場合、テナント トラフィックの元の CoS 値を使用してパケットを MPLS ネットワークに転送します。

- デフォルトの MPLS EXP 値 (0) のパケットを SR-MPLS ネットワークに転送します。

- また、境界リーフ スイッチは、SR ネットワークへの転送中に、アプリケーション サーバから着信するテナント トラフィックの元の DSCP 値を変更しません。

ステップ 6

[L3 ドメイン (L3 Domain)] ドロップダウンで、レイヤ 3 ドメインを選択します。

ステップ 7

BGP 設定を構成します。

サイトの境界リーフ (BL) スイッチとプロバイダエッジ (PE) ルータ間の BGP EVPN 接続について、BGP 接続の詳細を指定する必要があります。

1. [+BGP 接続の追加 (+Add BGP Connectivity)] をクリックします。

2. [BGP 接続の追加 (Add BGP Connectivity)] ウィンドウで詳細を入力します。

[MPLS BGP-EVPN ピア IPv4 アドレス (MPLS BGP-EVPN Peer IPv4 Address)] フィールドで、DC-PE ルータのループバック IP アドレスを入力します。このルータは必ずしも、境界リーフに直接接続されているデバイスとは限りません。

[リモート AS 番号 (Remote AS Number)] に、DC-PEのネイバー自律システムを一意に識別する番号を入力します。自律システム番号は 4 バイトで、1 〜 4294967295 のプレーン形式で指定します。ACIは asplain 形式のみをサポートし、asdot または asdot+ 形式のAS番号はサポートしないことに注意してください。ASN形式の詳細については、『Explaining 4-Byte Autonomous System（AS）ASPLAIN and ASDOT Notation for Cisco IOS』を参照してください。

[TTL] フィールドで、境界リーフと DC-PE ルータ間の複数のホップ数を考慮に入れて、十分大きな値を指定します。たとえば 10 とします。許容範囲は 2 〜 255 ホップです。

（任意）展開に基づいて追加の BGP オプションを有効にします。

3. [保存（Save）] をクリックして BGP 設定を保存します。

4. 追加の BGP 接続があれば、このステップを繰り返します。

通常、2 つの DC-PE ルータに接続することになるので、両方の接続につてい BGP ピア情報を入力します。

ステップ 8

境界リーフ スイッチと、SR-MPLS ネットワークに接続されているポートの設定を構成します。

境界リーフ スイッチについての情報、そして SR-MPLS ネットワークに接続されているインターフェイス ポートの情報を入力する必要があります。

1. [+リーフの追加 (+Add Leaf)] をクリックして、リーフ スイッチを追加します。

2. [リーフの追加 (Add Leaf)] ウィンドウで、[リーフ名 (Leaf Name)] ドロップダウンからリーフ スイッチを選択します。

3. 有効なセグメント ID (SID) オフセットを入力します。

このセクションの後の部分で、インターフェイス ポートを設定する際には、セグメント ルーティングを有効にするかを選択できます。SID インデックスは、MPLS トランスポートループバックの各ノードで設定されます。SID インデックス値は BGP-LU を使用してピア ルータにアドバタイズされ、ピア ルータは SID インデックスを使用してローカル ラベルを計算します。セグメント ルーティングを使用する予定の場合には、この境界リーフのセグメント ID を指定する必要があります。

- 値は、先ほど設定した SRGB の範囲内である必要があります。

- この値は、サイト内のすべての SR-MPLS L3Out で選択したリーフスイッチで同じ必要があります。

- すべてのサイトの複数のリーフに同じ値を使用することはできません。

- 値を更新する必要がある場合は、まず、リーフ内のすべての SR-MPLS L3Out から値を削除し、設定を再展開する必要があります。その後、新しい値で更新し、新しい設定を再展開できます。

4. ローカルの [ルータ ID (Router ID)] を入力します。

ファブリック内で一意なルータ 識別子です。

5. [BGP EVPN ループバック (BGP EVPN Loopback)] アドレスを入力します。

BGP-EVPN ループバックが BGP-EVPN コントロール プレーン セッションに使用されます。このフィールドを使用して、境界リーフ スイッチの EVPN ループバックと DC-PE 間の MP-BGP EVPN セッションを設定し、オーバーレイ プレフィックスをアドバタイズします。MP-BGP EVPN セッションは、BP-EVPN ループバックと BGP-EVPN リモート ピア アドレスの間で確立されます。このアドレスは、[BGP-EVPN リモート IPv4 アドレス (BGP-EVPN Remote IPv4 Address)] フィールドで設定します（前の BGP 接続のステップ）。

BGP-EVPN ループバックと MPLS トランスポート ループバックに異なる IP アドレスを使用できますが、ACI 境界リーフ スイッチの BGP-EVPN と MPLS トランスポート ループバックに同じループバックを使用することを推奨します。

6. [MPLS トランスポート ループバック (MPLS Transport Loopback)] アドレスを入力します。

MPLS トランスポート ループバックは、ACI 境界リーフ スイッチと DC-PE 間のデータ プレーン セッションを構築するために使用されます。MPLS トランスポート ループバックは、境界リーフ スイッチから DC-PE ルータにアドバタイズされるプレフィックスのネクスト ホップになります。

BGP-EVPN ループバックと MPLS トランスポート ループバックに異なる IP アドレスを使用できますが、ACI 境界リーフ スイッチの BGP-EVPN と MPLS トランスポート ループバックに同じループバックを使用することを推奨します。

7. [インターフェイスの追加 (Add Interface)] をクリックして、スイッチ インターフェイスの詳細を入力します。

[インターフェイスのタイプ (Interface Type)] ドロップダウンから、通常のインターフェイスなのか、それともポート チャネルなのかを選択します。ポート チャネル インターフェイスを使用する場合には、それ以前に APIC 上で作成しておく必要があります。

それからインターフェイス、その IP アドレス、および MTU サイズを入力します。サブインターフェイスを使用する場合には、サブインターフェイスの [VLAN ID] を入力します。それ以外の場合には [VLAN ID] フィールドはブランクのままにします。

[BGP ラベル ユニキャスト ピア IPv4 アドレス (BGP-Label Unicast Peer IPv4 Address)] および [BGP ラベル ユニキャスト リモート AS 番号 (BGP-Label Unicast Remote AS Number)] で、ネクスト ホップ デバイス（インターフェイスに直接接続されているデバイス）の BGP-LU ピア情報を指定します。ネクスト ホップ アドレスは、インターフェイスで設定したサブネットの一部である必要があります。

セグメント ルーティング (SR) MPLS を有効にするかどうかを選択します。

（任意）展開に基づいて追加の BGP オプションを有効にします。

最後に、[インターフェイス タイプ (Interface Type)] ドロップダウンの横にあるチェックマークをクリックして、、インターフェイス ポート情報を保存します。

8. MPLS ネットワークに接続されているスイッチのすべてのインターフェイスについて、前のサブステップを繰り返します。

9. [保存 (Save)] をクリックして、リーフ スイッチ情報を保存します。

ステップ 9

MPLS ネットワークに接続されているすべてのリーフ スイッチについて、前のステップを繰り返します。

SR-MPLS テナントの要件と注意事項

Infra MPLS の設定と要件は Day-0 操作の章で説明されていますが、次の制約が SR-MPLS ネットワークに接続されているし後に展開するユーザ テナントに適用されます。

- Day-0 操作の章で説明されているとおり、QoS ポリシーを含む SR-MPLS Infra L3Outs を作成し、設定します。

- ファブリックの 2 つの EPG 間のトラフィックが SR-MPLS ネットワークを通過する必要がある場合:

- 各 EPG とローカル SR-MPLS L3Out で定義された外部EPGの間に、コントラクトを割り当てる必要があります。

- 両方の EPG が同じACI ファブリックの一部であるが、SR-MPLS ネットワークによって分離されている場合（たとえば、マルチポッドまたはリモート リーフの場合)、EPG が異なる VRF に属していること、その間にはコントラクトがないこと、ルートリーキングが設定されていないことが必要です。

- EPG が異なるサイトにある場合、それらは同じ VRF に存在できますが、それらの間で直接設定されたコントラクトがあってはなりません。

EPG が異なるサイトにある場合、各 EPGは単一サイトにのみ展開する必要があることにご留意ください。サイト間の EPG の拡張は、SR-MPLS L3Outs を使用するときはサポートされていません。

- SR-MPLS L3Out のルート マップ ポリシーを設定する場合:

- 各 L3Out は、単一のエクスポート ルート マップがなければなりません。オプションで、単一のインポート ルート マップももつことができます。

- SR-MPLS L3Out に関連付けられたルート マップは、SR-MPLS L3Out からアドバタイズする必要がある、ブリッジ ドメイン サブネットを含むすべてのルートを明示的に定義する必要があります。

- 0.0.0.0/0 プレフィックスを定義し、ルートをアグレゲートしないことにした場合、デフォルトのルートのみを許可します。

しかし、ルート 0 ～ 32 を 0.0.0.0/0 プレフィックスにアグリゲートすることにした場合、VRF のすべてのトラフィックが許可されます。

- 任意のルーティング ポリシーを任意のテナント L3Out に関連付けることができます。

- 移行ルーティングがサポートされますが、一部の制約があります。

- 同じ VRF を使用する 2 つの SR-MPLS ネットワーク間の移行ルーティングはサポートされていません。次の図は、サポートされていない設定の例を示します。

単一の VRF を使用するサポートされていない移行ルーティング設定

- 異なる VRF を使用する 2 つの SR-MPLS ネットワーク間の移行ルーティングはサポートされています。次の図は、サポートされている設定の例を示します。

異なる VRF を使用するサポートされている移行ルーティング設定

SR-MPLS ルート マップ ポリシーの作成

このセクションでは、ルート マップ ポリシーを作成する方法について説明します。ルートマップは、テナントSR-MPLS L3Outからアドバタイズされるルートを指定できる if-then ルールのセットです。ルートマップでは、DC-PE ルータから受信したどのルートを BGP VPNv4 ACI コントロールプレーンに挿入するかを指定することもできます。

MPLS ネットワークに接続されているサイトがない場合は、このセクションをスキップできます。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

[メイン メニュー (Main menu)] で、[アプリケーション管理 (Application Management)] > [ポリシー (Policies)] を選択します。

ステップ 3

メイン ペインで、[ポリシーの追加 (Add Policy)] > [ルート マップ ポリシーの作成 (Create Route Map Policy)] を選択します。

ステップ 4

[ルート マップ ポリシーの追加 (Add Route Map Policy)] 画面で、テナントを選択し、ポリシーの名前を指定します。

ステップ 5

ルート マップ エントリを追加するには、[ルート マップ エントリの順序 (Route-Map Entry Order)]の下の [エントリの追加 (add Entry)] をクリックします。

1. [コンテキストの順序 (Contrext Order)] と [コンテキスト アクション(Context Action)]を指定します。

各コンテキストは、1 つ以上の一致基準に基づいてアクションを定義するルールです。

コンテキストの順序は、コンテキストが評価される順序を決定するために使用されます。値は 0 ～ 9 の範囲内である必要があります。

[アクション (Action)] は、一致が検出された場合に実行するアクション (許可 (permit)または拒否 (deny)) を定義します。

2. IP アドレスまたはプレフィックスに基づいてアクションを照合する場合は、[IP アドレスの追加 (Add IP Address)] をクリックします。

[プレフィックス (prefix)] フィールドに、IP アドレス プレフィックスを入力します。IPv4 と IPv6 の両方のプレフィックスがサポートされています (例:2003:1:1a5:1a5::/64または205.205.0.0/16)。

特定の範囲の IP を集約する場合は、[集約 (aggregate)] チェックボックスをオンにして、範囲を指定します。たとえば、0.0.0.0/0プレフィックスを指定し、ルート 0 ~ 32 を集約するよう選択できます。

3. コミュニティリストに基づいてアクションを照合する場合は、[コミュニティの追加 (Add community)] をクリックします。

[コミュニティ (Community)] フィールドに、コミュニティ文字列を入力します。たとえば、 regular:as2-as2-nn2:200:300 などです。

次に、[範囲 (Scope)] を選択します。

4. [+ アクションの追加 (+Add Action)] をクリックして、コンテキストが一致する必要があるアクションを指定します。

次のアクションのうちの 1 つを選択できます。

- コミュニティの設定

- ルート タグの設定

- ウェイトの設定

- ネクスト ホップの設定

- プリファレンスの設定

- メトリックの設定

- メトリック タイプの設定

アクションを設定したら、チェックマーク アイコンをクリックしてアクションを保存します。

5. (オプション) 前のサブステップを繰り返して、同じコンテキスト エントリ内で複数の一致基準とアクションを指定できます。

6. [保存 (save)] をクリックして、コンテキスト エントリを保存します。

ステップ 6

(オプション) 同じルート ポリシーに複数のエントリを追加する場合は、前の手順を繰り返します。

ステップ 7

[保存 (Save)] をクリックして、ルート マップ ポリシーを保存します。

SR-MPLS 設定のテンプレートの有効化

MPLS を介して接続されたサイトに展開する際に固有のテンプレート構成設定がいくつかあります。テナントの SR MPLS を有効にすると、MPLS サイトで使用できない特定の設定を制限およびフィルタ処理し、そのようなサイトでのみ使用可能な追加の設定を行うことができます。

MPLS 固有の設定を更新する前に、テンプレートのテナント プロパティで SR-MPLS ノブを有効にする必要があります。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

メインのナビゲーション メニューで、[Application Management (アプリケーション管理)] > [スキーマ (Schemas)] を選択します。

ステップ 3

新規作成するか、または SR-MPLS テナントを設定する既存のスキーマを選択します。

ステップ 4

テナントを選択します。

新しいスキーマを作成した場合は、通常と同じようにテナントを選択します。それ以外の場合は、左側のサイドバーで既存のテンプレートをクリックします。

ステップ 5

右側のサイドバーの テンプレート のプロパティで、 SR MPLS ノブを有効にします。

VRF および SR-MPLS L3Out の作成

このセクションでは、MPLS ネットワークで区切られるアプリケーション EPG 間の通信を設定するために使用する VRF、テナント SR-MPLS L3Out、および External EPG を作成する方法を説明します。

始める前に

次のことが必要です。

- SR-MPLS 設定のテンプレートの有効化 で説明しているように、テンプレートを作成して、そのテナントで SR-MPLS を有効にしていること。

手順

ステップ 1

テンプレートを選択します。

ステップ 2

VRF を作成します。

1. メイン ペインで、VRF エリアまで下方にスクロールして、+ 記号をクリックして VRF を追加します。

2. 右のプロパティのサイドバーでは、VRF の名前を指定します。

ステップ 3

SR-MPLS L3Out を作成します。

1. メイン ペインで、SR-MPLS L3Out エリアまで下方にスクロールして、+ 記号をクリックして L3Out を追加します。

2. 右のプロパティのサイドバーでは、L3Out の名前を指定します。

3. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、前のステップの外部 EPG に対して選択した同じ VRF を選択します。

ステップ 4

外部 EPG を作成します。

1. メイン ペインで、[外部 EPG (External EPG)] エリアまで下方にスクロールし、+ 記号をクリックして外部 EPG を追加します。

2. 右のプロパティのサイドバーでは、外部 EPG の名前を指定します。

3. [仮想ルーティングと転送 (Virtual Routing & Forwarding)] ドロップダウンから、前のステップで作成された VRF を選択します。

サイトローカル VRF 設定の構成

SR-MPLS L3Out によって使用される VRF のための BGP ルート情報を設定する必要があります。

始める前に

次のことが必要です。

- SR-MPLS 設定のテンプレートの有効化 で説明しているように、テンプレートを作成して、そのテナントで SR-MPLS を有効にしていること。

- VRF および SR-MPLS L3Out の作成 で説明しているように、VRF とSR-MPLS L3Out を作成していること。

- MPLS サイトにテンプレートを追加していること。

手順

ステップ 1

テンプレートを含むスキーマを選択します。

ステップ 2

スキーマ ビューの左サイドバーの [サイト (Sites)] の下で、サイトローカル プロバティを編集するためにテンプレートを選択します。

ステップ 3

メインペインで、[VRF] エリアまで下にスクロールし、VRF を選択します。

ステップ 4

右プロパティ サイドバーで、[+ BGP ルート ターゲット アドレスを追加 (+Add BGP Route Target Address)] をクリックします。

ステップ 5

BGP 設定を構成します。

1. [アドレス ファミリ (Address Family)] ドロップダウンから、その IPv4 または IPv6 アドレスを選択します。

2. [ルート ターゲット (Route Target)] フィールドで、ルート文字列を設定します。

たとえば、route-target:ipv4-nn2:1.1.1.1:1901 のようにします。

3. [タイプ (Type)] ドロップダウンで、ルートをインポートするのか、それともエクスポートするのかを選択します。

4. [保存 (Save)] をクリックして、ルート情報を保存します。

ステップ 6

(オプション) 上記のステップを繰り返して、その他の BGP ルート ターゲットを追加します。

サイトローカル SR-MPLS L3Out 設定の構成

通常の外部 EPG のサイトローカル L3Out プロパティを設定する場合と同じように、MPLS で接続されているサイトに展開される外部 EPG の SR-MPLS L3Out の詳細を設定する必要があります。

始める前に

次のことが必要です。

- SR-MPLS 設定のテンプレートの有効化 で説明しているように、テンプレートを作成して、そのテナントで SR-MPLS を有効にしていること。

- VRF および SR-MPLS L3Out の作成 で説明しているように、VRF とSR-MPLS L3Out を作成していること。

- サイトローカル VRF 設定の構成 で説明しているように、VRF のサイトローカル プロパティを設定していること。

- MPLS サイトにテンプレートを追加していること。

手順

ステップ 1

テンプレートを含むスキーマを選択します。

ステップ 2

スキーマ ビューの左サイドバーの [サイト (Sites)] の下で、サイトローカル プロバティを編集するためにテンプレートを選択します。

ステップ 3

メインペインで、[SR-Mpls L3Out] エリアまで下にスクロールし、MPLS L3Out を選択します。

ステップ 4

右のプロパティ サイドバーで、[+ SR-MPLS ロケーションの追加 (+Add SR-MPLS Location)] をクリックします。

ステップ 5

SR-MPLS のロケーションの設定を構成します。

1. [SR-MPLS のロケーション (SR-MPLS Location)] ドロップダウンで、そのサイトのインフラを設定する際に作成したインフラ SR-MPLS L3Out を選択します。

2. [外部 EPG (External EPGs)] セクションで、ドロップダウンから外部 EPG を選択し、チェックlマークのアイコンをクリックして追加します。

外部 EPG は複数追加できます。

3. [ルート マップ ポリシー (Route Map Policy)] セクションの下で、前のセクションで作成したルート マップ ポリシーをドロップダウンから選択し、ルートをインポートするかエクスポートをするかを指定してから、チェックマークのアイコンをクリックして追加します。

1 つのエクスポート ルート マップ ポリシーを設定する必要があります。オプションとして、追加のインポート ルート マップ ポリシーを設定することができます。

4. [保存 (Save)] をクリックして、ロケーションを MPLS L3Out に追加します。

ステップ 6

(オプション) 前のステップを繰り返して、その他の SR-MPLS ロケーションを SR-MPLS L3Out に追加します。

MPLS ネットワークにより区切られた EPG 間の通信

通常、2 つの EPG 間の通信を確立するには、1 つの EPG をプロバイダに、もう1つをコンシューマとし、両方の EPG に同じコントラクトを割り当てるだけです。

しかし、2 つの EPG が MPLS ネットワークで区切られている場合には、トラフィックはそれぞれの EPG の MPLS L3Out を通らなければならないので、コントラクトは、それぞれの EPG と、その MPLS L3Out の間に確立します。この動作は、EPG が異なるファブリックに展開されている場合でも、マルチポッドまたはリモード リーフの場合のように、同じサイトに展開されていて、SR-MPLS ネットワークで区切られている場合でも同じです。

始める前に

次のことが必要です。

- MPLS ネットワークに接続されている 1 つ以上のサイトを Orchestrator に追加していること。

- インフラ MPLS の設定を、「ゼロデイ オペレーション」の章で説明しているように構成していること。

- SR-MPLS 設定のテンプレートの有効化 で説明されているとおり、スキーマを作成し、テナントを追加し、SR-MPLS に対してテナントを有効にしていること。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

通常のように、2 つのアプリケーション EPG を作成します。

たとえば、epg1 および epg2 とします。

ステップ 3

2 つの独立した外部 EPG を作成します。

これらの EPG は、特定の導入シナリオに応じて、同じテンプレートに含めることも、異なるテンプレートに含めることもできます。

たとえば、 mpls-extepg-1 および mpls-extepg-2 とします。

ステップ 4

2 つの個別のテナント SR-MPLS L3Out を設定します。

たとえば、mpls-l3out-1 および mpls-l3out-2 とします。

各テナント SR-MPLS L3Out について、サイトローカル VRF 設定の構成 および サイトローカル SR-MPLS L3Out 設定の構成 の説明に従って、VRF、ルート マップ ポリシー、および外部 EPG を設定します。

ステップ 5

ステップ 2 で作成した、2 つのアプリケーション EPG の間のトラフィックを許可するために使用するコントラクトを作成します。

通常のように、コントラクトのためのフィルタを作成して定義する必要があります。

ステップ 6

コントラクトを適切な EPG に割り当てます。

作成した 2 つのアプリケーション EPG 間のトラフィックを許可するため、実際にはコントラクトを 2 回割り当てる必要があります。epg1 とその mpls-l3out-1 の間、そして epg2 とその mpls-l3out-2 の間です。

例として、epg1 が epg2 にサービスを提供する場合、次のようにします。

1. epg1 にタイプ consumer でコントラクトを割り当てます。

2. mpls-l3out-1 にタイプ consumer でコントラクトを割り当てます。

3. epg2 にタイプ consumer でコントラクトを割り当てます。

4. mpls-l3out-1 にタイプ consumer でコントラクトを割り当てます。

設定の展開

1 つの例外を除いて、構成テンプレートを通常どおり MPLS サイトに展開できます。MPLS サイトと別のサイトの間でオブジェクトとポリシーを拡張することはできないため、テンプレートを展開するときに選択できるサイトは 1 つだけです。

手順

ステップ 1

テンプレートを展開するサイトを追加します。

1. [スキーマ (Schema)] 表示の左側のサイドバーで、[サイト (Sites)] の下の + アイコンをクリックします。

2. [サイトの追加 (Add Sites)] ウィンドウで、テンプレートを展開するサイトを選択します。

テンプレートが MPLS 対応の場合、単一サイトのみを選択できます。

3. [テンプレートへの割り当て (Assign to Template)] ドロップダウンからスキーマを作成した 1 つ以上のテンプレートを選択します。

4. [保存 (Save)] をクリックして、サイトを追加します。

ステップ 2

設定を展開する

1. [スキーマ (Schemas)] 表示のメイン ペインで、[サイトに展開 (Deploy to Sites)] をクリックします。

2. [サイトに展開 (Deploy to Sites)] ウィンドウで、サイトにプッシュされる変更を検証し、[展開 (Deploy)] をクリックします。

Chapter26. vzAny コントラクト

- vzAny および Multi-Site

- vzAny およびマルチサイトのガイドラインと制限事項

- コントラクトとフィルタの作成

- コントラクトを消費または提供するための vzAny の設定

- vzAny VRF の一部として EPG を作成する

- 自由な VRF 間通信

- 多対 1 の通信

vzAny および Multi-Site

vzAny管理対象オブジェクトは、各 EPG の個別のコントラクト関係を作成するのではなく、1 つまたは複数のコンテキストに仮想ルーティングと転送 (VRF) のすべてのエンドポイント グループ (EPG) を関連付ける便利な方法を提供します。

Cisco ACI ファブリックでは、コントラクトのルールにより、EPG は他の EPG としか通信できません。EPG とコントラクトの関係によって、EPG がコントラクトのルールに定義された通信を提供するのか、消費するのか、あるいは提供も消費も行うのかが指定されます。VRF 中のすべての EPG にコントラクトのルールを動的に適用することで、vzAny ではEPG とコントラクトとの関係を設定するプロセスが自動化されます。新しい EPG が VRF に追加されるたびに、vzAny コントラクト ルールが自動的に適用されます。vzAny と EPG の「1 対すべて」の関係は、コンテキスト中のすべての EPG にコントラクトのルールを適用するための最も効率的な方法です。

利点

Cisco ACI のポリシー情報は、ファブリックスイッチの TCAM テーブルにプログラムされています。TCAM エントリは、一般的に、コントラクト経由で互いに通信することを許可する EPG の各ペアに固有の特定のものです。このことは、同じコントラクトが再使用された場合でも、複数の TCAM エントリが EPG の各ペアに対して作成されることを意味します。

ポリシー TCAM テーブルのサイズは、使用しているスイッチの生成に応じて異なります。特定の大規模環境では、ポリシーTCAMの使用を考慮し、制限を超えないようにすることが重要です。

vzAny を使用すると、同じ VRF 内のすべての EPG を単一の「グループ」に結合し、単一の TCAM エントリのみを消費しながら、グループ内の個々の EPG ではなく、そのグループとのコントラクト関係を作成できます。これにより、TRF スペースだけでなく、VRF 内の個々の EPG の複数のコントラクト関係の作成に費やす時間を節約できます。

使用例

vzAny には次の 2 つの代表的な使用例があります。

- 自由な VRF 間通信 に記載されているとおり、同じ VRF 内の EPG 間の自由な通信。

- 多対 1 の通信 で詳細に説明するように、多 対 1 の通信により、同じ VRF 内のすべての EPG が単一の EPG から共有サービスを利用できるようになります。

vzAny およびマルチサイトのガイドラインと制限事項

vzAny を使用するときには、次の制約事項および使用上のガイドラインが適用されます。

- 特定の VRF の vzAny オブジェクトを有効にしてコントラクトを提供または消費することを計画している場合は、次の追加の制限が適用されます。

- 特定の VRF の vzAny がコントラクト C1 のコンシューマとして設定されている場合、他の VRF の vzAny オブジェクトを C1 のプロバイダーとして設定してはなりません。

- 特定の VRF の vzAny がコントラクト C1 のプロバイダーとして設定されている場合、他の VRF の vzAny オブジェクトを C1 のコンシューマとして設定してはなりません。

- 特定の VRF の外部 EPG 部分がコントラクト C1 を使用している場合、他の VRF の vzAny オブジェクトを C1 のプロバイダーとして設定してはなりません。

- 特定の VRF の EPG 部分がコントラクト C1 を使用している場合、他の VRF の vzAny オブジェクトを C1 のプロバイダーとして設定してはなりません。

- 特定の VRF の vzAny が契約 C1 のプロバイダーとして設定されている場合、EPG、外部 EPG、または他の VRF の vzAny オブジェクトを C1 のコンシューマとして設定してはなりません。

- 特定の VRF の EPG および外部 EPG オブジェクトは、その VRF の vzAny がすでにコントラクトを使用または提供している場合、優先グループの一部として設定しないでください。

- 特定の VRF 内の EPG または外部 EPG オブジェクトがクラウド サイトに展開されている場合、その VRF の vzAny を設定してコントラクトを消費または提供することはできません。

- vzAny は、ファブリックが Cisco ACI 5.2(4) リリース以降を実行しているマルチサイト ドメインの一部である場合にのみ、VRF 間サイト間 L3Out 設定でサポートされます。

- vzAny は、PBR でサービスグラフに関連付けられているコントラクトを、消費したり、または提供したりすることはできません。

- vzAny は、VRF 内通信を確立するためのコントラクトのプロバイダ、コンシューマ、または両方として設定できます。

- vzAny は、共有サービスのコンシューマとしてのみサポートされていますが、プロバイダとしてはサポートされていません。

- VzAny VRF は、EPG とそれを使用する BD を導入する予定のすべてのサイトに拡張することをお勧めします。

- APIC から既存の vzAny 設定をインポートできます。

（注）

既存の問題 (CSCvt47568) が原因の特定の事例で、Multi-Site Orchestrator から再展開する前にインポートされた設定を変更した場合、APIC で一部の変更が正しく更新されない場合があります。これを回避するには、インポート後すぐに設定を再展開してから、変更を加えます。変更されていない設定を再展開すると、通常どおりに更新できるようになります。

- vzAny プロバイダとコンシューマには、アプリケーション EPG、L3Outs に関連付けられた外部 EPG、インバンドまたはアウトオブバンドアクセスのためのエンドポイントグループが含まれます。

- vzAny は、外部発信トラフィックの 0.0.0.0/0 分類を暗黙に作成し、任意の外部 IP サブネットから発信されたすべてのトラフィックを許可します。VzAny が VRF に使用されている場合は、その VRF の L3Outs 部分に関連付けられた外部 EPG も含まれているため、VRF 自体で指定されたサブネットを含む L3external 分類を作成したことに相当します。

- VRF 内の EPG が別の VRF の EPG から共有サービス コントラクトを消費している場合、プロバイダ VRF の EPG からのトラフィックは、コンシューマー VRF 内でフィルタリングされます。vzAny は、送信元または宛先 EPG のワイルドカードに相当します。

コンシューマ VRF の vzAny と別のプロバイダー VRF の EPG1 の間で共有サービス契約を設定する場合は注意してください。ポリシーの適用（フィルタリング）は常にコンシューマー VRF で実行されるため、プロバイダー VRF の一部である別の EPG2 に関連付けられたサブネットがコンシューマー VRF に漏洩した場合、EPG2 は、明示的にコントラクトを提供しなくても、VRF 全体でコンシューマー EPG との通信を開始します。このガイドラインに従わないと、VRF にわたる EPG 間での意図しないトラフィックが発生する可能性があります。

- 「Allow all」フィルタを使用して、コントラクトのプロバイダとコンシューマの両方として vzAny を使用した VRF を設定することは、非強制 VRF の設定と同じです。これは、その VRF 内のすべての EPG がコントラクトなしで相互に通信できることを意味します。

- コントラクトの範囲がアプリケーション プロファイルの場合、vzAny 設定は無視され、フィルタ ルールが拡張されます。CAM 使用率は、特定のコントラクトがコンシューマとプロバイダ EPG の各ペアの間に展開された場合と同じです。この場合、TCAM スペースの使用には利点がありません。

- 共有サービスの場合は、コンシューマ (vzAny) 側の宛先の分類 (Pctag) を適切に導出するために、EPG の下にプロバイダ EPG 共有サブネットを定義する必要があります。コンシューマとプロバイダの両方のサブネットがブリッジ ドメイン下で定義され、共有サービス コンシューマとして機能する vzAny に対して、BD から BD への共有サービス設定から移行する場合は、少なくとも共有フラグを使用してプロバイダ サブネットを EPG に追加する追加の設定手順を実行する必要があります。ただし、EPG の下のサブネットは接続に必要ではないため、常に No default SVI gatewayフラグをチェックすることを推奨します。

定義済みの BD サブネットの複製として EPG サブネットを追加する場合は、サブネットの両方の定義に同じフラグが定義されていることを確認してください。それをしない場合、エラーが発生する可能性があります。

コントラクトとフィルタの作成

vzAny を使用するときは、基本的にコントラクト関係の単一のポイントを作成します。そのため、そのような関係とコントラクトのフィルタに使用する一般的なコントラクトが必要です。

このセクションでは、特別にこの目的の新しいコントラクトを作成する方法を説明します。代わりに、各 apic サイトで設定した既存の vzAny コントラクトのインポートを選択できます。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[スキーマ (schema)] を選択します。

ステップ 3

コントラクトを作成したいスキーマを選択します。

更新する既存のスキーマがある場合は、メイン ウィンドウ ペインでスキーマの名前をクリックするだけでかまいません。そうではない場合、新しいスキーマを作成する場合は、[スキーマの追加 (Add Schema)] ボタンをクリックして、いつも通り、名前やテナントなど、スキーマ情報を指定してください。

ステップ 4

フィルタを作成します。

1. フィルタ エリアまでスクロールし、+ をクリックしてフィルタを作成します。

2. コントラクトの名前を指定します。

3. [+エントリ (+ Entry)] をクリックし、フィルタ エントリを追加します。

4. [エントリの追加 (Add Entry)] ウィンドウでフィルタの詳細を入力します。

通常、許可するトラフィックの種類を定義する場合と同様に、フィルタの詳細を指定します。

5. [保存 (SAVE)] をクリックして、エントリを追加します。

6. (オプション) 必要な場合は、追加のフィルタ エントリを作成します。

ステップ 5

コントラクトを作成します。

1. コントラクト エリアまで下方へスクロールし、+ をクリックして新しいコントラクトを追加します。

2. コントラクトの名前を指定します。

例: contract-vzany。

3. コントラクトの範囲を選択します

使用例に適切な範囲を選択します。たとえば、クロステナント共有サービスを有効にする場合は、範囲を「グローバル (Global)」に設定します。

4. コントラクトが両方向に適用されるかどうかを選択します。

5. [+フィルタ (+Filter)] をクリックして、1 つ以上のコントラクト フィルタを追加します。

6. [フィルタ チェーンの追加 (Add Filter Chain)] ウィンドウで、前の手順で作成されたフィルタを選択します。

7. [保存 (SAVE)] をクリックして、フィルタを追加します。

8. (オプション) 必要な場合は、手順を繰り返してフィルタを追加します。

9. (オプション) [両方向を適用 (Apply Both Directions)] オプションを無効にする場合、コンシューマーとプロバイダの両方向にフィルタを提供します。

これで、次のセクションの vzAny で使用するコントラクトを作成しました。

コントラクトを消費または提供するための vzAny の設定

ここでは、vzAny VRF を作成する方法、または vzAny の既存の VRF を有効にする方法について説明します。

始める前に

次のものが必要です。

- コントラクトとフィルタの作成の説明に従って、vzAny で使用するコントラクトと1つ以上のフィルタを作成しました。

手順

ステップ 1

Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション ペインで、[スキーマ (schema)] を選択します。

ステップ 3

VzAny VRF のスキーマを選択します。

更新する既存のスキーマがある場合は、メイン ウィンドウ ペインでスキーマの名前をクリックするだけでかまいません。そうではない場合、新しいスキーマを作成する場合は、[スキーマの追加 (Add Schema)] ボタンをクリックして、いつも通り、名前やテナントなど、スキーマ情報を指定してください。

ステップ 4

VRF を作成または選択します。

コントラクトを提供または消費するために vzAny を設定する既存の VRF がある場合は、メイン ウィンドウ ペインで [VRF] をクリックします。それ以外の場合は、新しい VRF を作成する場合、[VRF] エリアまで下にスクロールし、[+] 記号をクリックします。

ステップ 5

[vzAny] を選択します。

右側のサイドバーで、[vzAny] チェックボックスをオンにします。

ステップ 6

vzAny コントラクトを選択します。

[+ Contract] オプションは、[vzAny] チェックボックスを有効にすると使用可能になります。

1. [+コントラクト (+Contract)] をクリックし、新しいコントラクトを追加します。

2. コントラクトを選択します。

コントラクトとフィルタの作成で作成したコントラクトを選択します。

3. 契約タイプを選択します。

使用例に基づいて、契約のコンシューマまたはプロバイダのいずれかを選択できます。

vzAny VRF の一部として EPG を作成する

VzAny のユースケースには、新規作成するか、既存の EPG を使用するかを選択できます。EPG には明示的な vzAny 設定がなく、vzAny VRF の一部であるすべての EPG に対して、無料の通信がデフォルトで許可されています。すでに作成され、構成されているすべての EPG に対して vzAny を有効にしているだけである場合は、このセクションをスキップすることができます。

始める前に

次のものが必要です。

- コントラクトとフィルタの作成の説明に従って、vzAny で使用するコントラクトと1つ以上のフィルタを作成しました。

- コントラクトを消費または提供するための vzAny の設定 の説明に従って、vzAny VRF を作成してコントラクトに割り当てました。

手順

ステップ 1

vzAny VRF の一部として EPG を作成する場合

1. EPG に使用する BD を作成してください。

2. BD 構成サイドバーの [Virtual Routing & Forwarding (仮想ルーティングと転送)] ドロップダウンで、作成する vzAny VRF を選択します。

3. EPG を作成します。

4. EPG 設定サイドバーの [Bridge Domain(ブリッジ ドメイン)] ドロップダウンでは、作成する BD を選択します。

ステップ 2

vzAny VRF の一部として外部 EPG を作成する場合

1. 外部 EPG を作成します。

2. 外部 EPG 構成サイドバーの [Virtual Routing & Forwarding (仮想ルーティングと転送)] ドロップダウンで、作成する vzAny VRF を選択します。

自由な VRF 間通信

このセクションでは、制限の課されない VRF 間通信のための、様々なスキーマの例を示します。示されているすべてのシナリオにおいて、vzAny は permit any フィルタを使用してコントラクトを提供し、消費します。これは基本的に、ポリシーを適用せずに ACI ファブリックをネットワーク接続に使用します。これは、「VRF 非強制」オプションと同等です。

次のすべての使用例では、以下で要約されていものと同じ目的とポリシーを作成する必要があります。ただし、スキーマとテンプレート設計は、サイトの数だけではなく、拡大するオブジェクトに応じて異なります。特定のセクションには、テンプレート レイアウトに関するレコメンデーションが含まれます。

手順

ステップ 1

スキーマを作成します。

ステップ 2

単一の共通テンプレートを作成します。

ステップ 3

EPG が展開されるサイトのそれぞれの組み合わせに対して、追加のテンプレートを作成します。

1つのテンプレートをすべてのサイトに展開する場合は、この手順をスキップできます。このセクションの使用例のダイアグラムは、テンプレートの例を示します。

ステップ 4

共通テンプレート内で、vzAny によって消費/提供されるコントラクトとフィルタを作成します。

この特定の使用例では、コントラクトに 1 つの「permit-any」フィルタルールが必要です。

具体的な手順については、コントラクトとフィルタの作成 を参照してください。

ステップ 5

共通テンプレート内で、VRF を作成し、「permit-any」ルールを使用して以前に定義されたコントラクトを消費して提供するように vzAny を設定します。

これにより、VRF 内の自由な通信を確立できるようになります。

具体的な手順については、コントラクトを消費または提供するための vzAny の設定 を参照してください。

ステップ 6

各サイトのテンプレート内で、そのサイトにのみ展開される EPG を作成して設定します。

すべてのサイトに単一のテンプレートを展開する場合は、代わりに VRF と同じテンプレート内で EPG を作成します。このセクションの使用例のダイアグラムは、テンプレートの例を示します。

これについては、vzAny VRF の一部として EPG を作成するで説明します。

ステップ 7

すべてのサイトに共通のテンプレートを割り当てます。

ステップ 8

各テンプレートを適切なサイトに割り当てます。

ステップ 9

テンプレートを展開します。

- 拡張された EPG

- サイトローカル EPG

- サイト ローカルおよび拡張 EPG の組み合わせ

- VRF 内のサイト間 L3Out

拡張された EPG

次の例は、EPG または 外部 EPG の VRF 内通信を示し、それらのすべてはサイト間で拡張できます。この例では、EPG1 と EPG2 は同じ BD1 にマップされますが、両方の BD が VRF1 の一部である限り、それぞれが異なる BD の一部となる可能性があります。

このケースでは、同じテンプレート内のすべてのオブジェクトを作成し、テンプレートをすべてのサイトに展開できます。

サイトローカル EPG

以下の例は、EPG または 外部 EPG 間の VRF 内通信を示しています。この場合、どの EPG も拡張されていませんが、vzAnyが「permit-any」コントラクトを消費して提供するため、相互に自由に通信できます。

この場合、複数のテンプレートを作成する必要があります。

- 各サイトに展開された共有オブジェクト (VRF、コントラクト) の単一のテンプレート。

- およびそのサイトに展開された EPG と BD を含むサイトごとの個別のテンプレート。

拡張されていないオブジェクトの場合は、シャドウ オブジェクトがほかのサイトで作成されます。

サイト ローカルおよび拡張 EPG の組み合わせ

次の例は、EPG または 外部 EPG の間の VRF 内通信を示しています。一部の EPG は拡張されていますが、他のものは単一のサイトにのみ展開されます。それでも、すべての EPG は相互に自由に通信できます。vzAny は「すべて許可」のコントラクトを消費し、提供するからです。

この場合、複数のテンプレートを作成する必要があります。

- すべてのサイトに展開されている共有オブジェクト (VRF、コントラクト、BD) 用の単一のテンプレート。

- また、これらのサイトにのみ展開されたオブジェクトを含むサイトの組み合わせごとに個別のテンプレートがあります。

拡張されていないオブジェクトの場合は、シャドウ オブジェクトがほかのサイトで作成されます。

VRF 内のサイト間 L3Out

このユース ケースでは、1 つの vzAny VRF 内の複数の EPG 用に、サイト間 L3Out を設定できます。L3Out の外部 EPG が同じ VRF 内に存在する場合には、外部 EPG にプロバイダを明示的に追加する必要はありません。

この点を念頭に置くと、サイト間 L3Out を設定する場合には、ポッドごとにルーティング可能な TEP を設定することが必要になります。追加のサイト間 L3Out の詳細と要件については、サイト間 L3Out の概要 のセクションで説明されています。

この場合、次のように、複数のテンプレートを作成する必要があります。

- まず、1 つまたは複数のサイトに展開されている共有 vzAny オブジェクト (VRF、コントラクト、BD) 用の単一のテンプレートです。

- また、これらのサイトにのみ展開されたオブジェクトを含む、サイトの組み合わせごとの個別のテンプレートです。

多対 1 の通信

以下の 3 つのセクションでは、共有サービスを提供する単一の EPG との同じ vzAny VRF 通信の一部である、複数の EPG のスキーマの例を示します。この例では、1 つ以上のフィルタ ルールを指定できます。

共有サービスを提供する EPG は、個別の VRF 内のものであることも (下の図を参照)、vzAny VRF の一部であることも可能です。

次のすべての使用例では、以下で要約されていものと同じ目的とポリシーを作成する必要があります。ただし、スキーマとテンプレート設計は、サイトの数だけではなく、拡大するオブジェクトに応じて異なります。特定のセクションには、テンプレート レイアウトに関するレコメンデーションが含まれます。

手順

ステップ 1

スキーマを作成します。

ステップ 2

単一の共通テンプレートを作成します。

ステップ 3

EPG が展開されるサイトのそれぞれの組み合わせに対して、追加のテンプレートを作成します。

ステップ 4

共通テンプレート内で、vzAny によって消費され、共有サービスを提供する EPG によって提供される、コントラクトとフィルタを作成します。

これについては、コントラクトとフィルタの作成で説明します。

ステップ 5

共通テンプレート内で、VRF を作成し、前に定義したコントラクトを消費してするよう vzAny を設定します。

これについては、コントラクトを消費または提供するための vzAny の設定で説明します。

ステップ 6

各サイトのテンプレート内で、vzAny VRF の一部となる EPG を作成して設定します。

これについては、vzAny VRF の一部として EPG を作成するで説明します。

ステップ 7

プロバイダ EPG を新規作成して設定するか、既存のプロバイダ EPG または外部 EPG を設定します。

プロバイダ EPG の新規作成と設定、既存のプロバイダ EPG または外部 EPG の設定は、通常どおりの方法で行います。

ステップ 8

プロバイダ EPG にコントラクトを割り当てます。

vzAny が消費するコントラクトの割り当てに加えて、同じコントラクトをプロバイダ EPG に割り当てることも必要になります。

- VzAny VRF 内のプロバイダ EPG

- 独自の VRF でのプロバイダ EPG

VzAny VRF 内のプロバイダ EPG

次の例は、単一のプロバイダ EPG (たとえば、共有サービス) と、同じ VRF 内の他のすべての EPG 間のサービスを消費する VRF 間の通信を示しています。

この場合、複数のテンプレートを作成する必要があります。

- すべてのサイトに展開されている共有オブジェクト (VRF、コントラクト、BD) 用の単一のテンプレート。

- また、これらのサイトにのみ展開されたオブジェクトを含むサイトの組み合わせごとに個別のテンプレートがあります。

次の図は、1つのストレッチ VRF/BD の設定を示しています。代わりに、EPG ごとに専用 BD を設定してマッピングすることもできます。その場合は、シャドウ BD がリモートサイトに展開されます。

独自の VRF でのプロバイダ EPG

次の例は、独自の VRF 内の単一の EPG (たとえば、共有サービス プロバイダ) と、異なる vzAny VRF 内のすべての EPG との間の通信を示しています。プロバイダ EPG は、vzAny VRF のコンシューマ EPG と同じサイトまたは別のサイトに展開できます。

この場合、次のように、複数のテンプレートを作成する必要があります。

- まず、1 つまたは複数のサイトに展開されている共有 vzAny オブジェクト (VRF、コントラクト、BD) 用の単一のテンプレートです。

- また、これらのサイトにのみ展開されたオブジェクトを含む、サイトの組み合わせごとの個別のテンプレートです。

Trademarks

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS REFERENCED IN THIS DOCUMENTATION ARE SUBJECT TO CHANGE WITHOUT NOTICE. EXCEPT AS MAY OTHERWISE BE AGREED BY CISCO IN WRITING, ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS DOCUMENTATION ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.

The Cisco End User License Agreement and any supplemental license terms govern your use of any Cisco software, including this product documentation, and are located at: https://www.cisco.com/c/en/us/about/legal/cloud-and-software/software-terms.html. Cisco product warranty information is available at https://www.cisco.com/c/en/us/products/warranty-listing.html. US Federal Communications Commission Notices are found here https://www.cisco.com/c/en/us/products/us-fcc-notice.html.

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 products and features described herein as in development or available at a future date remain in varying stages of development and will be offered on a when-and if-available basis. Any such product or feature roadmaps are subject to change at the sole discretion of Cisco and Cisco will have no liability for delay in the delivery or failure to deliver any products or feature roadmap items that may be set forth in this document.

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.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.

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)