はじめに
このドキュメントでは、Cisco Nexus Dashboard Orchestrator(NDO)からサイトの関連付けを解除し、APICでローカルに管理する手順について説明します。
背景
目標は、NDとNDOの両方を排除することです。
この手順は、お客様がサイトの運用停止を検討していて、最初に拡張された構成を、継続しているサイト内でローカルとして保持したい場合に便利です。
警告:このドキュメントでは、Cisco Nexus Dashboard Orchestrator(NDO)からサイトの関連付けを解除し、APICのローカル管理を維持する手順の概要を説明しています。適切な理解と注意を払わないでこの手順を進めると、潜在的なリスクや合併症が発生する可能性があります。ネットワーク設定を変更する前には、十分に注意し、専門家の指導を受けることをお勧めします。
省略形:
APIC:アプリケーションポリシーインフラストラクチャコントローラ
ND:Nexusダッシュボード
NDO:Nexusダッシュボード
VRF:Virtual Routing and Forwarding(仮想ルーティングおよび転送)
BD:ブリッジドメイン
EPG:エンドポイントグループ
AP:Application Profile(アプリケーションプロファイル)
目的
このプロセスの目的は、NDOから管理されているオブジェクトを完全にリンク解除し、各ファブリック上の各APICクラスタから個別に管理することです。
トポロジ
デモンストレーションの目的で、次のトポロジが展開されます。
トポロジの提案
NDOでは、導入は次のようになります。
- テナントレベル:Tenant1という名前のテナントはNDOから作成され、Site1とSite2という名前の両方のサイトに関連付けられます。
2つのサイトとのテナント関連付けの検証
これは、次の3つのテンプレートに関連付けられています。
テナントへのテンプレートの関連付けの検証
- スキーマ・レベル:Schema1という名前のスキーマには、次の3つのテンプレートが含まれます。
Stretched_Schemaに含まれるテンプレートの検証
- Stretched_Site1_Site2はストレッチテンプレートであり、ここでVRF1と呼ばれるストレッチドVRFが定義され、両方のサイトに関連付けられます。
テンプレートStretched_Site1_Site2が2つのサイトで拡張されていることを検証します
- Site1だけに関連付けられたSite1という名前のテンプレートでは、ローカルのBD_Site1が定義され、拡張されたVRF1に関連付けられています。また、AP_Site1とEPG_Site1はこのテンプレートでローカルに定義されています。
テンプレートSite1が単一サイトに対してローカルであることを検証します。
ローカルBDのVRFが拡張されたものであることを確認します。
- Site2のみと関連付けられたSite2という名前のテンプレートでは、ローカルのBD_Site2が定義され、拡張されたVRF1と関連付けられています。また、AP_Site2とEPG_Site2はこのテンプレートでローカルに定義されています。
ローカルであることを確認するためのテンプレートサイト2の検証
ローカルBDのVRFが拡張されたものであることを確認します。
オブジェクトが正しく配置されていることを確認するには、次の手順を実行します。
Tenant1は、NDO、VRF、AP、BD、およびEPGによって導入および管理されます。
GUIでの拡張の検証
すべてのMITオブジェクトの注釈が「orchestrator:msc」に設定されていること、つまりNDOから管理されていることを確認することもできます。
テナント:
{
"totalCount": "1",
"imdata":
[
{
"fvTenant":
{
"attributes":
{
"annotation": "orchestrator:msc",
"descr": "",
"dn": "uni/tn-Tenant1",
"name": "Tenant1",
"nameAlias": "",
"ownerKey": "",
"ownerTag": "",
"userdom": ":all:"
}
}
}
]
}
VRF:
"fvCtx":
{
"attributes":
{
"annotation": "orchestrator:msc-shadow:no",
"bdEnforcedEnable": "no",
"descr": "",
"ipDataPlaneLearning": "enabled",
"knwMcastAct": "permit",
"name": "VRF1",
"nameAlias": "",
"ownerKey": "",
"ownerTag": "",
"pcEnfDir": "ingress",
"pcEnfPref": "enforced",
"userdom": ":all:",
"vrfIndex": "0"
},
"children":
[
{
"fvSiteAssociated":
{
"attributes":
{
"annotation": "",
"descr": "",
"name": "",
"nameAlias": "",
"ownerKey": "",
"ownerTag": "",
"siteId": "1",
"userdom": ":all:"
},
"children":
[
{
"fvRemoteId":
{
"attributes":
{
"annotation": "",
"descr": "",
"name": "2",
"nameAlias": "",
"ownerKey": "",
"ownerTag": "",
"remoteCtxPcTag": "32770",
"remotePcTag": "2686983",
"siteId": "2",
"userdom": ":all:"
}
}
}
]
}
},
]
}
VRFでは、「orchestrator:msc」注釈以外に、一部の子プロパティも表示されます。
これらの子オブジェクトをよりよく理解するためには、NDOでは、サイト名の他に、一意のサイトIDがNDOの各サイトに関連付けられていることに注意することが重要です。IDを照会するには、NDOでOperate > Sites:に移動します。
NDOでのサイトごとのSiteIDの検証
この情報を説明すると、子オブジェクトは次のようになります。
- fvSiteAssociated:ローカルサイトのサイトIDを表示します。
- fvRemoteID:オブジェクトが拡張されているリモートサイトID。このオブジェクトは、サイト間でのオブジェクトの変換を知る場合にも役立ちます。このVRFの場合、サイト2に対応するセグメントとClassIDを確認できます。確認のため、サイト2から比較を行うことができます。
リモートオブジェクトのセグメントとクラスIDの検証
上記からわかるように、サイト2からのセグメントとクラスIDは、サイト1のVRFオブジェクト内のfvRemoteIDに含まれています。
BD:
"fvBD": { "attributes": { "OptimizeWanBandwidth": "yes", "annotation": "orchestrator:msc-shadow:no", "name": "BD_Site1", ... }, "children": [ ... { "fvSiteAssociated": { "attributes": { "annotation": "", "descr": "", "name": "msc-local", "nameAlias": "", "ownerKey": "", "ownerTag": "", "siteId": "1", "userdom": ":all:" } } }, ] }
APおよびEPG:
"fvAp": { "attributes": { "annotation": "orchestrator:msc-shadow:no", "descr": "", "name": "APP_Site1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "prio": "unspecified", "userdom": ":all:" }, "children": [ { "fvAEPg": { "attributes": { "annotation": "orchestrator:msc-shadow:no", "descr": "", "exceptionTag": "", "floodOnEncap": "disabled", "fwdCtrl": "", "hasMcastSource": "no", "isAttrBasedEPg": "no", "matchT": "None", "name": "EPG_Site1", "nameAlias": "", "pcEnfPref": "unenforced", "prefGrMemb": "exclude", "prio": "unspecified", "shutdown": "no", "userdom": ":all:" }, "children": [ { "fvSiteAssociated": { "attributes": { "annotation": "", "descr": "", "name": "msc-local", "nameAlias": "", "ownerKey": "", "ownerTag": "", "siteId": "1", "userdom": ":all:" } } }, ] } } ] }
BD、AP、およびEPGオブジェクトでは、fvRemoteId子オブジェクトはありません。これらのオブジェクトはローカルで意味を持ち、拡張されないためです。
サイト2の出力はほぼ同じですが、対応するリモートオブジェクトのみが変更されるため、この情報は省略されています。
サイトの関連付け解除
この手順を実行する前に、NDOのバックアップとAPICのスナップショットを作成しておくことをお勧めします。これは、後でロールバックする必要がある場合に備えて行います。
ステップ 1:テンプレート内のサイトの関連付けの解除
この手順は、各テンプレートで実行する必要があります。円の依存関係の背後にあるロジックと同様に、最初に他のテンプレートに依存関係があるテンプレートで開始し、最後に相互参照がないテンプレートの関連付けを解除する必要があります。
このドキュメントで使用するトポロジでは、関連付けを解除する最後のテンプレートはStretched_Site1_Site2である必要があります。これは、テンプレートSite1とSite2にその参照があるためです。
スキーマ内のテンプレートに移動し、Actionsをクリックし、Disassociate Siteに移動します。
テンプレートの関連付け解除方法
次のウィンドウで、サイトごとにドロップダウンメニューから選択します。これは、関連付け解除が1つずつ実行されるためです(テンプレートに2つ以上のサイトがある場合)。
テンプレートの関連付けを解除するサイトの選択
次にDisassociateをクリックします。
完了すると、確認を含むメッセージが表示されます。
確認メッセージ
注:前述のように、スキーマ上のすべてのテンプレートに対してこの手順を繰り返します。
ステップ 2:各APICのオブジェクトがNDOによって管理されていないことを確認します。
オブジェクトがAPIC内に存在していることを確認するため、異なるプロパティを使用します。
APIC内(サイト1内の例):
設定が維持されることをGUIで確認します。
オブジェクトの横にクラウドNDOアイコンが表示されなくなり、テナントだけがNDOによって管理されます。
JSON内:
"fvTenant": { "attributes": { "annotation": "orchestrator:msc", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" }, "children": [ { "fvCtx": { "attributes": { "annotation": "", "bdEnforcedEnable": "no", "descr": "", "ipDataPlaneLearning": "enabled", "knwMcastAct": "permit", "name": "VRF1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "pcEnfDir": "ingress", "pcEnfPref": "enforced", "userdom": ":all:", "vrfIndex": "0" }, "fvBD": { "attributes": { "OptimizeWanBandwidth": "yes", "annotation": "", "arpFlood": "yes", "descr": "", "epClear": "no", "epMoveDetectMode": "", "hostBasedRouting": "no", "intersiteBumTrafficAllow": "yes", "intersiteL2Stretch": "yes", "ipLearning": "yes", "ipv6McastAllow": "no", "limitIpLearnToSubnets": "yes", "llAddr": "::", "mac": "00:22:BD:F8:19:FF", "mcastARPDrop": "yes", "mcastAllow": "no", "multiDstPktAct": "bd-flood", "name": "BD_Site1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "type": "regular", "unicastRoute": "yes", "unkMacUcastAct": "proxy", "unkMcastAct": "flood", "userdom": ":all:", "v6unkMcastAct": "flood", "vmac": "not-applicable" } ... "fvAp": { "attributes": { "annotation": "", "descr": "", "name": "APP_Site1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "prio": "unspecified", "userdom": ":all:" }, "children": [ { "fvAEPg": { "attributes": { "annotation": "", "descr": "", "exceptionTag": "", "floodOnEncap": "disabled", "fwdCtrl": "", "hasMcastSource": "no", "isAttrBasedEPg": "no", "matchT": "None", "name": "EPG_Site1", "nameAlias": "", "pcEnfPref": "unenforced", "prefGrMemb": "exclude", "prio": "unspecified", "shutdown": "no", "userdom": ":all:" }, } } ] } } ] }
APICからわかるように、注釈が付いているオブジェクトはテナントオブジェクトだけですが、BD、VRF、AP、およびEPGオブジェクトの注釈プロパティは空になっています。これにより、オブジェクトがAPICから削除されていないことが確認され、各APICによって管理されるようになります。
ステップ 3:空のテンプレートの削除
すべてのテンプレートが空で、どのサイトにも関連付けられていません。
関連付けられていない状態のテンプレートの検証
これらのテンプレートは安全に削除できます。これらを削除するには、Actionsをクリックし、図に示すようにDelete Templateを選択します。
テンプレートの削除
スキーマが空になったら、変更を保存します。
空のスキーマに対する変更の保存
ステップ 4:空のスキーマの削除
空のスキーマを削除します。図に示すように、Configure > Tenant Templatesに移動します。
テナントメニューへの移動手順
次の図に示すように、スキーマの横にある3つのドットをクリックし、Deleteをクリックします。
テンプレートに関連付けられている空のスキーマを削除します
ステップ 5:テナントからのサイトの関連付けの解除
スキーマがなくなると、テナントはスキーマがどのテンプレートとも関連付けられていないことを示す必要があります。確認するには、Operate > Tenantsに移動します。
テナントからのサイトの関連付けの解除
テナントに関連付けられたテンプレートがないことを確認しています
このように、Tenant1に関連付けられているテンプレートの数は0です。3つのドットをクリックして、Editを選択します。
テナントのプロパティを編集してサイトを削除する
次に、サイトの選択を解除する必要があります。サイトのテーブルの上部にあるUnselect itemsをクリックします。
テナントに関連付けられたサイトの選択解除
確認する前に、テナントを削除するオプションがオフになっていることを確認します。
チェックなしで動作を確認する
両方のサイトのチェックマークを外したら、変更を保存します。これが完了したら、各APICのテナントが残っていることを確認します。
テナントが設定されているが、NDOから管理されていないことをIGUIで検証
予想どおり、注釈は空です。
"fvTenant": { "attributes": { "annotation": "", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" } }
手順 6:NDOの空のテナントの削除
テナントを削除します。これを行うには、Operate > Tenantsに移動し、3つのドットをクリックして、図に示すようにDeleteをクリックします。
空のテナントの削除
テナントオブジェクトがAPICに残っていることを確認します。
手順 7:NDでのNDOアプリケーションの削除
NDOを削除するには、まずアプリを無効にする必要があります。
NDでAdmin Console > Servicesに移動します。NDOアプリケーションが表示されます。3つのドットをクリックして、Disableを選択します。
NDOアプリケーションの無効化
完全に無効になるまでに数分かかる場合があります。
次に、もう一度3つのドットをクリックし、今回はオプションをクリックします Delete .
ステップ 8:NDでNDOアプリケーションを削除する
最後に、NDからサイトを削除します。サイトを削除するには、サイトがサービスを消費していない必要があります。そのため、他のアプリケーションがインストールされている場合は、そのアプリケーションも削除する必要があります。
サイトがNDOサービスを使用していないことの検証
これを削除するには、3つのドットをクリックして、図に示すよRemove Site うに選択します。
NDのサイトを削除
サイトが完全に削除されると、各ファブリックは独立した状態になり、NDも廃止できます。
注:サイトが独立すると、インフラテナントのサイト間のL3outは引き続き存在します。これは手動で削除できます。サイト間接続でだけであることを確認してください。