スキーマ

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

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

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

単一スキーマの展開

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

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

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

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

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

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

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

図 1. ネットワーク スキーマ

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

図 2. ポリシー スキーマ

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

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

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

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

図 3. サイトごとに 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"
}

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

始める前に

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

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

手順


ステップ 1

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

ステップ 2

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

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

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

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

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

ステップ 3

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

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

  2. [テンプレート タイプの選択(Select a Template type)] ウィンドウで、テンプレート タイプとして [ACI マルチクラウド(ACI Multi-Cloud)] を選択します。

    • [ACI マルチクラウド(ACI Multi-Cloud)] :Cisco ACI オンプレミスおよびクラウド サイトに使用されるテンプレート。これにより、複数のサイト間でテンプレートとオブジェクトを拡張できます。

      次のセクションでは、主にこのタイプのテンプレートに焦点を当てます。

    • [ネットワーク(Networking)]:Cisco Nexus Dashboard ファブリック コントローラ(以前のデータセンター ネットワーク マネージャ)サイト用に設計されたテンプレート。

      このガイドでは、Cisco ACI およびクラウド ACI サイトの Nexus Dashboard Orchestrator 構成について説明しました。Cisco NDFC サイトの操作については、代わりに『Cisco Nexus Dashboard Orchestrator DCNM ファブリックの構成ガイド』を参照してください。

    • [SR-MPLS]:SR-MPLS 統合用に設計されたテンプレート。

      SR-MPLS の使用例の詳細については、このガイドの「SD-WAN 統合」の章を参照してください。

    • [クラウド ローカル(Cloud Local)]:Google Cloud サイト接続など、特定の Cisco Cloud ACI ユース ケース向けに設計されたテンプレートであり、複数のサイト間で拡張することはできません。

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

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

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

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

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

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

ステップ 4

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

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

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

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

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

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

  4. [保存(Save)] をクリックします。


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) を設定する方法について説明します。

始める前に

手順


ステップ 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 のサイトローカル プロパティの設定

テンプレートでオブジェクトを作成するときにオブジェクトに対して通常設定するテンプレート レベルのプロパティに加えて、テンプレートを割り当てる各サイトに固有の 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. 物理インターフェイスを構成する場合は、[ポッド(Pod)] を選択します。

  4. 単一のポートを構成するか、ポートの範囲を構成するかを選択します。

    インターフェイス設定については、単一のリーフとパスを入力するか、リーフの範囲(例:120 - 125 およびパス)を入力して(例:1/17 - 20)するオプションがあります。また、リーフの範囲を入力して 1 つの単一のパスに関連付けるか、1 つの単一のリーフのパスの範囲を入力するオプションもあります。

    ただし、構成後も UI には個別のポートとして表示され、今後の更新では個別の変更が必要になります。

  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 を使用して、実装されたスキーマ ポリシーの特定の領域にアクセスして編集することもできます。

テンプレート オブジェクトの一括更新

一括更新機能を使用すると、テンプレート内の同じタイプの複数の異なるオブジェクトの複数のプロパティを一度に更新できます。たとえば、各オブジェクトを個別に変更する代わりに、同時に 2 つ以上の EPG にインフラ EPG 分離を適用できます。このワークフローを使用する場合、選択したすべてのオブジェクトは同じタイプである必要があります。たとえば、EPG と BD を同時に更新することはできません。

選択したオブジェクトにすでに別のプロパティ値が構成されている場合、更新により、それらのプロパティが指定した値で上書きされます。この機能により、オンプレミスのテンプレート レベルのオブジェクト プロパティを更新できます。サイトローカル プロパティとクラウド プロパティの更新はサポートされていません。


(注)  


この機能は、Cisco APIC および Cisco DCNM ファブリックでのみサポートされています。 Cisco Cloud APIC サイトではサポートされていません。


手順


ステップ 1

更新するオブジェクトが含まれているスキーマに移行します。

ステップ 2

右上のペインから、[選択(Select)] を選択します。同じタイプのオブジェクトを複数選択できます。

ステップ 3

更新するすべてのオブジェクトを選択した後。

  1. キャンセル オプションの横にある […] を選択します。

  2. ドロップダウンから [編集(Edit)] を選択します。

異なるタイプのオブジェクトを選択した場合、ドロップダウンに [編集(Edit)] オプションは表示されません。

ステップ 4

[編集(Edit)] を選択すると、ポップアップが表示されます。選択したオブジェクトのプロパティのサブセットが表示されます。

選択したオブジェクトのタイプに基づいて、次のプロパティを更新できます。

  1. [EPG]:ブリッジ ドメイン、コントラクト、EPG タイプ、インフラ EPG、優先グループ。

  2. [コントラクト(Contracts)]:範囲、フィルターチェーン、QOS レベル。

  3. [VRF]:IP データ プレーン学習。

  4. [ブリッジ ドメイン(Bridge Domain)]:仮想ルーティングとフォワーワーディング、L2 ストレッチ、L2 不明なユニキャスト、不明なマルチキャスト フラッディング、IPv6 不明なマルチキャスト フラッディング、複数宛先フラッディング、DHCP ポリシー、ユニキャスト ルーティング。

  5. [外部 EPG(External EPG)]:コントラクト、外部 EPG タイプ、優先グループ。

ステップ 5

すべてのフィールドを選択したら、更新します。[保存(Save)] を選択すると、先ほど行った更新が実装されます。

ステップ 6

更新を保存すると、行った変更を確認できます。


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

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

始める前に

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

手順


ステップ 1

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

ステップ 2

左側のサイドバーで、サイトに割り当てるテンプレートを選択します。

ステップ 3

テンプレートの名前の横にある [アクション(Actions)] メニュー([...])をクリックして、[サイトの追加(Add Sites)] を選択します。

[サイトを <template-name> に追加(Add Sites to <template-name>)] ウィンドウが開きます。

ステップ 4

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

選択したテンプレートのタイプとサイト間のサイト間接続によっては、一部のサイトを割り当てに使用できない場合があることに注意してください。

  • クラウド ローカル テンプレートを割り当てる場合は、単一のクラウド サイトにのみ割り当てることができます。

  • テンプレートを複数のサイトに割り当てる場合、BGP-EVPN プロトコルを使用して、それらのサイト間のサイト間接続を確立する必要があります。パーシャル メッシュ接続があるサイトを選択した場合、サイト間接続がないサイト、または BGP-IPv4 を使用してサイト間接続が確立されているサイトはグレー表示され、割り当てに使用できません。

ステップ 5

[保存(Save)] をクリックします。

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


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

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

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

テンプレート バージョンは、次のルールに従って作成および管理されます。

  • すべてのテンプレート バージョンは、Deployed または Intermediate のいずれかです。

    Deployed — サイトに展開されたテンプレートのバージョン。

    Intermediate — 変更および保存されたが、サイトに展開されていないテンプレートのバージョン。

  • テンプレートごとに最大 20 の Deployed バージョンと 20 の Intermediate バージョンをいつでも保存できます。

  • 20 バージョンの制限を超える新しい Intermediate バージョンが作成されると、最も古い既存の Intermediate バージョンが削除されます。

  • テンプレートが展開され、新しい Deployed バージョンが作成されると、すべての Intermediate バージョンが削除されます。新しい Deployed バージョンが 20 バージョン制限を超えると、最も古い既存の Deployed バージョンが削除されます。

  • バージョンに Golden のタグを付けても、保存されているテンプレート バージョンの数には影響しません。

  • テンプレートごとに無制限のバージョンをサポートしていた以前のリリースから最初にアップグレードする場合、既存のすべてのバージョンはそのまま残ります。

    テンプレートが変更されて保存または展開されると、20 のDeployed および 20 の Intermediate スケールを超えるバージョンは、上記のルールに従って削除されます。

タギング テンプレート

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

手順


ステップ 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)][...])メニューから、[ロールバック(Rollback)] を選択します。

ステップ 6

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

[ゴールデン バージョン (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 に読み取り専用でアクセスできます。


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

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

始める前に

次のものが必要です。

手順


ステップ 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)] ボタンは、次の場合には使用できません。
  • グローバル変更制御オプションが有効になっていない

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

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

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

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


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

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

始める前に

次のものが必要です。

手順


ステップ 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 でそのドメインに対して定義された設定と異なる場合があります。これらの構成の不一致は、[構成のばらつき(Configuration Drifts)] と呼ばれ、次の図に示すように、スキーマ ビューのテンプレート名の横に黄色の注意サインで示されます。


(注)  


  • 場合によっては、NDO によって管理されるオブジェクトのプロパティの構成がサイトのコントローラで直接変更された場合、上記の構成ドリフトのテンプレート レベルの通知がトリガーされないことがあります。具体的には、次のプロパティの追加(およびその後の削除)では、NDO でドリフト通知が表示されません。

    • EPG または BD のサブネット

    • ブリッジ ドメインの DHCL ラベル

    • EPG の静的ポート構成

    • EPG 間の契約関係

    このような場合でも、設定のばらつきの調整で説明されているように、ドリフト調整ワークフローを手動で実行することで、構成のドリフトを確認できます。

  • NDO からテンプレートを展開すると、そのテンプレート内のオブジェクトのドリフト通知が 60 秒間無効になります。

    ファブリック ポリシーの場合、NDO は、展開後の一定期間、ポリシーの設定のばらつきを検出しません。このタイムアウト ウィンドウ中に受信した通知は処理されず、構成のばらつきは報告されません。このタイムアウト ウィンドウの長さは、次の式を使用して計算できます。

    15 秒 + (600 ミリ秒 *テンプレート内のポリシーの数)

  • 3.7(2g) より前のリリースでは、存在しない DHCP ポリシーをブリッジ ドメインに割り当て、スキーマを保存できました。これは、NDO にすでに存在する DHCP ポリシーのみを BD に割り当てることができるように変更されました。その結果、ポリシーが NDO に存在しない場合、APIC で DHCP ポリシーラベルが割り当てられている BD の NDO と APIC 間の設定のばらつきを調整できない場合があります。DHCP ラベルのインポートはこのリリースではサポートされていないため、最初に APIC に存在するものと同じ名前で NDO で DHCP ポリシーを作成してから、変動調整ワークフローを実行する必要があります。これにより、特定の DHCP ポリシーを APIC でのみ保持し、NDO でインポートするポリシーのみを作成することで残りの設定を調整できます。

    この NDO リリースは、 テナント スコープの DHCP ポリシーのみをサポートしますが、APIC は インフラ スコープもサポートします。そのため、ばらつきの調整ワークフローでは、 インフラ スコープの DCHP ポリシーはインポートされません。


構成のばらつきの原因

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

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

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

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


    (注)  


    APIC でオブジェクトが変更されるたびに、APIC は Nexus Dashboard Orchestrator に通知を送信します。通知を受信すると、Nexus Dashboard Orchestrator は 30 秒のタイマーを開始し(さらに通知が届くのを待ちます)、そのようなタイマーの期限が切れると、APIC への API 呼び出しを実行して、通知を受信したすべてのオブジェクトに加えられた変更に関する詳細情報を取得します。これにより、Nexus Dashboard Orchestrator は、それらのオブジェクトが定義されているすべてのテンプレートの UI にばらつきのシンボルを表示できます。この動作の唯一の例外は、Nexus Dashboard Orchestrator が、特定のテンプレートで定義されたオブジェクトのすべて(またはそのサブセット)の構成を展開する場合です。その場合、60 秒間、Nexus Dashboard Orchestrator は、それらの特定のオブジェクトに関して APIC から受信した通知を無視し、その結果、UI にばらつきのシンボルを表示できません。


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

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

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

    NDO リリース 3.6(1) 以降、テンプレートに対して「ばらつきの調整」ワークフローを実行して、ばらつきの原因をより詳細に把握し、ばらつきを調整できるようにすることをお勧めします。この推奨事項は、このセクションで前述したすべてのばらつきのシナリオに適用されます。NDO 3.6 の新しいばらつきの調整ワークフローの詳細については、以下の「構成のばらつきの調整」セクションを参照してください。

設定のばらつきの調整

NDO リリース 3.6(1) では、Nexus Dashboard Orchestrator で定義されたテンプレート構成と、マルチサイト ドメインのサイト部分の APIC コントローラーでレンダリングされた構成を比較するために実行できるばらつき調整ワークフローのサポートが導入されています。これにより、構成のばらつき(つまり、Nexus Dashbaord Orchestrator または APIC で直接行われた変更)の原因をより明確に把握でき、以下の手順で説明するように、ばらつきを調整する方法をユーザーに選択させることができます。


(注)  


選択した構成が必要ない場合は、スキーマを閉じて再度開くことができます。これにより、元の構成が表示されます。必要に応じて、「Reconcile Drift」フローを再度トリガーできます。[保存(Save)] または [展開(Deploy)] ボタンを選択した後にのみ、スキーマが保存されます。


手順


ステップ 1

設定のばらつきを確認するテンプレートを含むスキーマに移動します。

ステップ 2

テンプレートの [アクション (Actions)] メニューから、[ばらつきの調整 (Reconcile Drift)] を選択します。

[ばらつきの調整 (Reconcile Drift)] ウィザードが開きます。

ステップ 3

[ばらつきの調整 (Reconcile Drift)] 画面で、各サイトのテンプレートレベルの構成を比較し、希望のものを選択します。

テンプレートレベルのプロパティは、テンプレートに関連付けられているすべてのサイトに共通です。Nexus Dashboard Orchestrator で定義されたテンプレート レベルのプロパティを各サイトでレンダリングされた構成と比較し、Nexus Dashboard Orchestrator テンプレートの新しい構成を決定できます。サイト構成の選択は、既存の Nexus Dashboard Orchestrator テンプレートのこれらのプロパティを変更し、その場合、Nexus Dashboard Orchestrator の構成を選択すると、既存の Nexus Dashboard Orchestrator テンプレートの設定はそのまま残されます

ステップ 4

[サイト特有のプロパティに移動(Go to Site Specific Properties)] をクリックして、サイトレベルの構成に切り替えます。

特定のサイトの構成を比較するために、サイトを選択できます。テンプレートレベルの設定とは異なり、各サイトの Nexus Dashboard Orchestrator 定義または実際の既存の設定を個別に選択して、そのサイトのテンプレートのサイトローカル プロパティとして保持できます。

ほとんどのシナリオでは、テンプレートレベルとサイトレベルの両方の構成で同じ選択を行いたとしても、ばらつきの調整ウィザードでは、サイトのコントローラで「テンプレートのプロパティ」レベルで定義された構成と Nexus Dashboard Orchestratorで定義された構成またはその逆を選択できます。

ステップ 5

[変更のプレビュー(Preview Changes)] をクリックして、選択内容を確認します。

プレビューは [ばらつきの調整 (Reconcile Drift)] ウィザードの選択肢に基づいて調整された完全なテンプレート構成を表示します。その後、[サイトに展開(Deploy to site)] をクリックして構成を展開し、そのテンプレートのばらつきを調整できます。


スキーマの複製

このセクションでは、[スキーマ (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

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

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


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

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

この情報は 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)] ページに展開の概要が表示されます。

図 4. スキーマの概要

このページには、次の詳細が表示されます。

  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 つ以上のオブジェクトを選択してダイアグラムに表示することで、トポロジ ビジュアライザを作成できます。

図 5. 展開ビジュアライザ
  1. 凡例 (Legent):次のトポロジ図に表示するポリシーオブジェクトを選択できます。

  2. [フィルタ (Filter)]:表示されるオブジェクトを名前に基づいてフィルタリングできます。

  3. [トポロジ図 (Topology Diagram)]:サイトに割り当てられているすべてのスキーマ テンプレートで設定されたポリシーを視覚的に表示します。

    上記の [設定オプション (Configuration Options)] を使用して、表示するオブジェクトを選択できます。

    また、オブジェクトの上にマウスを置くと、すべての依存関係を強調表示できます。

    最後に、図内の任意のオブジェクトをクリックすると、他のオブジェクトとの関係だけが表示されます。たとえば、テンプレートをクリックすると、その特定のテンプレート内のすべてのオブジェクトのみが表示されます。

シャドウ オブジェクト

プロバイダとコンシューマーが異なる VRF にあり、テナント コントラクトを介して通信する拡張 VRF または共有サービスの使用例で、サイト ローカル EPG 間にコントラクトが存在する場合、EPG とブリッジ ドメイン (BD) はリモート サイトにミラーリングされます。ミラーされたオブジェクトは、これらのサイトのそれぞれの APIC で展開されているかのように表示される一方で、実際にはサイトの 1つでだけ展開されています。これらのミラーされたオブジェクトは、「シャドウ」オブジェクトと呼ばれます。


(注)  


シャドウ オブジェクトは、APIC GUI を使用して削除する必要があります。


たとえば、テナントと VRF が Site1 と Site2 の間でストレッチされ、プロバイダ EPG とそのブリッジ ドメインが Site2 のみに展開され、コンシューマ EPG とそのドメインが Site1 のみに展開される場合、対応するシャドウ ブリッジ ドメインと EPG は次の図のように展開されます。これらは、直接展開されている各サイトでの名前と同じ名前で表示されます。

図 6. 基本的なシャドウ 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)]、およびハイブリッド クラウドなど、さまざまな使用例でも作成されます。

図 7. 優先グループ

マルチキャストの場合、シャドウ オブジェクトは、マルチキャスト ソースが接続され、オプションが EPG レベルで明示的に設定されている EPG/BDに対してのみ作成されます。

図 8. L3 マルチキャスト

ハイブリッド クラウド展開の場合、ストレッチされたオブジェクトであっても、暗黙のコントラクトが存在するシャドウ オブジェクトを作成します。たとえば、EPG がオンプレミス サイトとクラウド サイトの間でストレッチされた場合、シャドウ外部 EPG は各サイトで作成され、ストレッチされた EPG とシャドウ外部 EPG の間に暗黙的なシャドウ コントラクトが作成されます。

図 9. ハイブリッドクラウド

Cisco APIC リリース 5.2(3) 以降、シャドウ オブジェクトは Cisco APIC GUI で一意のアイコンで示されます。通常の Orchestrator で作成されたオブジェクトは緑のクラウドの記号で表示されますが、シャドウ オブジェクトはグレーのクラウドのアイコンで表示されます。

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 サイトについては、このプロセスを繰り返します。