In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird das Verfahren beschrieben, mit dem Standorte vom Cisco Nexus Dashboard Orchestrator (NDO) getrennt und lokal in APICs verwaltet werden.
Ziel ist es, ND und NDO zu eliminieren.
Dieses Verfahren ist nützlich, wenn Kunden die Stilllegung eines Standorts durchführen und die ursprünglich gestreckte Konfiguration lokal am Standort beibehalten möchten.
Warnung: Bitte beachten Sie, dass in diesem Dokument die Schritte beschrieben werden, die erforderlich sind, um Standorte vom Cisco Nexus Dashboard Orchestrator (NDO) zu trennen und die lokale Verwaltung in APICs beizubehalten. Wenn Sie dieses Verfahren ohne Verständnis und Vorsicht durchführen, kann dies zu Risiken oder Komplikationen führen. Es wird empfohlen, Vorsicht walten zu lassen und sich von Experten beraten zu lassen, bevor Sie Änderungen an Ihrer Netzwerkkonfiguration vornehmen.
APIC: Application Policy Infrastructure Controller
ND: Nexus Dashboard
NDO: Nexus Dashboard
VRF: Virtual Routing and Forwarding
BD: Bridge-Domäne
EPG: Endpunktgruppe
AP: Anwendungsprofil
Zweck dieses Prozesses ist die vollständige Trennung der von NDO verwalteten Objekte und deren individuelle Verwaltung von jedem APIC-Cluster in jeder Fabric.
Zu Demonstrationszwecken wird diese Topologie bereitgestellt:
In NDO sieht die Bereitstellung wie folgt aus:
Sie ist mit drei Vorlagen verknüpft:
So bestätigen Sie, dass die Objekte ordnungsgemäß bereitgestellt wurden:
Tenant1 wird über NDO sowie VRF, AP, BD und EPG bereitgestellt und verwaltet:
Es kann auch bestätigt werden, dass alle MIT-Objekte die Anmerkung auf "orchestrator:msc" gesetzt haben, was bedeutet, dass sie von NDO aus verwaltet werden:
Tenant:
{
"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:"
}
}
}
]
}
},
]
}
Für die VRF-Instanz ist ersichtlich, dass neben der Anmerkung "orchestrator:msc" auch einige untergeordnete Eigenschaften angezeigt werden.
Um diese untergeordneten Objekte besser zu verstehen, ist es wichtig zu bemerken, dass in NDO neben dem Standortnamen jeder Website in NDO eine eindeutige Standort-ID zugeordnet ist. Um die IDs abzufragen, navigieren Sie in NDO zu Operate > Sites :
Nachdem diese Informationen erklärt wurden, sind die untergeordneten Objekte:
- fvSiteAssociated: Zeigt die Standort-ID des lokalen Standorts an.
- fvRemoteID: Die IDs des Remote-Standorts, auf die das Objekt ausgedehnt wird. Dieses Objekt ist auch nützlich, um die Übersetzung von Objekten über Standorte hinweg zu kennen. Im Fall dieser VRF-Instanz sind das Segment und die ClassID für Standort 2 sichtbar. Um dies zu bestätigen, kann ein Vergleich von Site 2 durchgeführt werden:
Wie ersichtlich, sind Segment und ClassID von Standort 2 in der fvRemoteID innerhalb des VRF-Objekts von Standort 1 enthalten.
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 und 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:" } } }, ] } } ] }
In den Objekten BD, AP und EPG gibt es keine untergeordneten fvRemoteId-Objekte, da diese Objekte lokal bedeutsam und nicht gestreckt sind.
- An Standort 2:
Standort 2 hat ziemlich ähnliche Ausgaben, nur die entsprechenden Remote-Objekte ändern, sodass diese Informationen weggelassen werden.
Sites trennen
Es wird empfohlen, vor diesem Verfahren ein Backup in NDO sowie einen Snapshot im APIC durchzuführen, falls ein späteres Rollback gewünscht wird.
Schritt 1: Sites in Vorlagen trennen
Dieser Schritt muss für jede Vorlage ausgeführt werden. Ähnlich der Logik hinter den Kreisabhängigkeiten muss zunächst mit Vorlagen begonnen werden, die Abhängigkeiten von anderen Vorlagen aufweisen, und schließlich die Zuordnung der Vorlagen, die keinen Querverweis aufweisen, aufgehoben werden.
In der in diesem Dokument verwendeten Topologie muss die letzte zu trennende Vorlage die Vorlage Stretched_Site1_Site2 sein, da die Vorlagen Site1 und Site2 einen Verweis darauf enthalten.
Navigieren Sie zur Vorlage innerhalb des Schemas, klicken Sie auf
Actions , und navigieren Sie zu
Disassociate Site:
Wählen Sie im nächsten Fenster aus dem Dropdown-Menü Site für Site aus, da die Trennung einer nach der anderen erfolgt (falls die Vorlage mehr als 2 Sites enthält):
Klicken Sie dann auf Disassociieren.
Nach Abschluss des Vorgangs wird eine Nachricht mit der Bestätigung angezeigt:
Hinweis: Wiederholen Sie wie bereits erwähnt dieses Verfahren für alle Vorlagen im Schema.
Schritt 2: Vergewissern Sie sich, dass die Objekte nicht von NDO auf jedem APIC verwaltet werden.
Um zu bestätigen, dass die Objekte in den APICs noch vorhanden sind, jetzt mit unterschiedlichen Eigenschaften:
Im APIC (Beispiel in Standort 1):
Objekte zeigen nicht mehr das Cloud-NDO-Symbol daneben an, nur der Tenant wird noch von NDO verwaltet.
In 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:" }, } } ] } } ] }
Wie aus dem APIC ersichtlich ist das einzige Objekt, das noch über die Anmerkung verfügt, das Tenant-Objekt. Bei den Objekten BD, VRF, AP und EPG ist die Anmerkungseigenschaft jetzt jedoch leer. Dadurch wird bestätigt, dass die Objekte nicht aus dem APIC entfernt, sondern von jedem APIC verwaltet werden.
Schritt 3: Leere Vorlagen entfernen
Da alle Vorlagen leer sind und keiner Website zugeordnet sind, führen Sie Folgendes aus:
Diese Vorlagen können sicher entfernt werden. Um sie zu entfernen, klicken Sie auf
Actions und wählen Sie wie im Bild gezeigt aus
Delete Template:
Speichern Sie die Änderungen nach dem Leeren des Schemas:
Schritt 4: Leere Schemas entfernen
Es ist an der Zeit, das leere Schema zu entfernen.
Configure > Tenant Templates Navigieren Sie wie im Bild dargestellt zu:
Und klicken Sie auf die 3 Punkte neben dem Schema, und klicken Sie auf
Delete, wie im Bild gezeigt:
Schritt 5: Standorte vom Tenant trennen
Sobald keine Schemas mehr vorhanden sind, muss der Tenant zeigen, dass er keiner Vorlage mehr zugeordnet ist. Navigieren Sie zur Bestätigung zu
Operate > Tenants:
Wie ersichtlich, ist die Anzahl der Tenant1 zugeordneten Vorlagen 0. Klicken Sie auf die drei Punkte, und wählen Sie Bearbeiten:
Jetzt ist es erforderlich, die Auswahl der Websites aufzuheben. Klicken Sie auf
Unselect items oben in der Tabelle der Websites:
Vergewissern Sie sich vor der Bestätigung, dass die Option zum Löschen des Tenants deaktiviert ist:
Wenn beide Standorte deaktiviert sind, speichern Sie die Änderungen. Bestätigen Sie anschließend den Tenant für die einzelnen APIC-Aufenthalte:
Die Anmerkung ist jetzt erwartungsgemäß leer:
"fvTenant": { "attributes": { "annotation": "", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" } }
Schritt 6: Leeren Tenant in NDO entfernen
Es ist an der Zeit, den Tenant zu entfernen. Navigieren Sie dazu zu
Operate > Tenants
Delete , klicken Sie auf die drei Punkte, und klicken Sie auf, wie in der Abbildung dargestellt:
Bestätigen Sie, dass das Tenant-Objekt in den APICs verbleibt.
Schritt 7. Entfernen der NDO-Anwendung in ND
Um NDO zu entfernen, muss die App zuerst deaktiviert werden.
Navigieren Sie in ND zu
Admin Console > Services. Die NDO-Anwendung wird dort angezeigt. Klicken Sie auf die drei Punkte, und wählen Sie
Disable:
Es kann ein paar Minuten dauern, bis sie vollständig deaktiviert sind.
Klicken Sie dann erneut auf die 3 Punkte, und klicken Sie diesmal auf die Option
Delete
.
Schritt 8: Entfernen Sie die NDO-Anwendung aus dem ND.
Entfernen Sie abschließend aus ND die Sites. Um die Sites entfernen zu können, dürfen sie keine Dienste nutzen. Wenn also eine andere Anwendung installiert ist, muss sie ebenfalls entfernt werden:
Um es zu entfernen, klicken Sie auf die 3 Punkte, und wählen Sie
Remove Site
wie im Bild gezeigt:
Sobald die Standorte vollständig entfernt sind, ist jede Fabric jetzt unabhängig, und ND kann ebenfalls eingestellt werden.
Hinweis: Sobald die Standorte unabhängig sind, ist das L3out für standortübergreifende Services im Infra-Tenant weiterhin vorhanden. Es kann manuell entfernt werden. Achten Sie darauf, dass es sich nur um eine standortübergreifende Verbindung handelt.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
30-Nov-2023 |
Erstveröffentlichung |