So trennen Sie Standorte vom Cisco Nexus Dashboard Orchestrator

Einleitung

In diesem Dokument wird das Verfahren beschrieben, mit dem Standorte vom Cisco Nexus Dashboard Orchestrator (NDO) getrennt und lokal in APICs verwaltet werden.

Hintergrund

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.

Abkürzungen:

APIC: Application Policy Infrastructure Controller 

ND: Nexus Dashboard

NDO: Nexus Dashboard

VRF: Virtual Routing and Forwarding

BD: Bridge-Domäne

EPG: Endpunktgruppe

AP: Anwendungsprofil

Ziel

Zweck dieses Prozesses ist die vollständige Trennung der von NDO verwalteten Objekte und deren individuelle Verwaltung von jedem APIC-Cluster in jeder Fabric.

Topologie

Zu Demonstrationszwecken wird diese Topologie bereitgestellt:

Vorgeschlagene Topologie

In NDO sieht die Bereitstellung wie folgt aus:

• Tenant-Ebene: Der Tenant Tenant1 wird aus NDO erstellt und ist beiden Standorten Site1 und Site2 zugeordnet:

Validierung der Tenant-Zuordnung mit 2 Standorten

Sie ist mit drei Vorlagen verknüpft:

Validierung der Vorlagenzuordnung zu einem Tenant

• Schemaebene: Das Schema mit der Bezeichnung Schema1 enthält die drei Vorlagen:

Validierung der in Stretched_Schema enthaltenen Vorlagen

• Vorlagenebene:

• Stretched_Site1_Site2 ist die gestreckte Vorlage, in der die gestreckte VRF-Instanz (VRF1) definiert und beiden Standorten zugeordnet ist:

Validierung, dass die Vorlage Stretched_Site1_Site2 in 2 Sites gestreckt wird

• In der Vorlage Site1, die nur Site1 zugeordnet ist, ist der lokale BD_Site1 definiert und dem gestreckten VRF1 zugeordnet. Außerdem sind AP_Site1 und EPG_Site1 in dieser Vorlage lokal definiert:

Überprüfen, ob die Vorlage Site1 für einen einzelnen Standort lokal ist

Validierung, dass VRF für das lokale BD das gestreckte ist

• In der Vorlage mit dem Namen Site2, die nur Site2 zugeordnet ist, ist der lokale BD_Site2 definiert und mit dem gestreckten VRF1 verknüpft. Außerdem sind AP_Site2 und EPG_Site2 in dieser Vorlage lokal definiert:

Validierung der Vorlage Standort 2 zur Bestätigung ist lokal

Validierung, dass VRF für das lokale BD das gestreckte ist

So bestätigen Sie, dass die Objekte ordnungsgemäß bereitgestellt wurden:

•  An Standort 1:

Tenant1 wird über NDO sowie VRF, AP, BD und EPG bereitgestellt und verwaltet:

Streckungsvalidierung in GUI

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 :

Validierung der Standort-ID pro Standort in NDO

Nachdem diese Informationen erklärt wurden, sind die untergeordneten Objekte:

1. fvSiteAssociated: Zeigt die Standort-ID des lokalen Standorts an.
2. 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:

Validierung von Segment und ClassID von Remoteobjekten

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:

Trennen der Vorlage

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):

Auswahl des Standorts, von dem die Zuordnung der Vorlage aufgehoben werden soll

Klicken Sie dann auf Disassociieren.

Nach Abschluss des Vorgangs wird eine Nachricht mit der Bestätigung angezeigt:

Bestätigungsmeldung

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):

GUI-Validierung, dass die Konfiguration beibehalten wird.

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:

Validierung von Vorlagen in einem nicht zugeordneten Status

Diese Vorlagen können sicher entfernt werden. Um sie zu entfernen, klicken Sie auf Actions und wählen Sie wie im Bild gezeigt ausDelete Template:

Löschen der Vorlage

Speichern Sie die Änderungen nach dem Leeren des Schemas:

Änderungen in leerem Schema speichern

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:

Schritte zum Wechseln zum Tenant-Menü

Und klicken Sie auf die 3 Punkte neben dem Schema, und klicken Sie auf Delete, wie im Bild gezeigt:

Leeres Schema löschen, das der Vorlage zugeordnet ist

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:

Standorte vom Tenant trennen

Bestätigen, dass dem Tenant keine Vorlagen zugeordnet sind

Wie ersichtlich, ist die Anzahl der Tenant1 zugeordneten Vorlagen 0. Klicken Sie auf die drei Punkte, und wählen Sie Bearbeiten:

Mandanteneigenschaften zum Entfernen von Standorten bearbeiten

Jetzt ist es erforderlich, die Auswahl der Websites aufzuheben. Klicken Sie auf Unselect items oben in der Tabelle der Websites:

Auswahl der dem Tenant zugeordneten Standorte aufheben

Vergewissern Sie sich vor der Bestätigung, dass die Option zum Löschen des Tenants deaktiviert ist:

Vorgang ohne Prüfung bestätigen

Wenn beide Standorte deaktiviert sind, speichern Sie die Änderungen. Bestätigen Sie anschließend den Tenant für die einzelnen APIC-Aufenthalte:

IGUI-Validierung, dass der Tenant noch konfiguriert, aber nicht über NDO verwaltet wird

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:

Leeren Tenant löschen

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:

NDO-Anwendung deaktivieren

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:

Validierung, dass Websites den NDO-Dienst nicht verwenden

Um es zu entfernen, klicken Sie auf die 3 Punkte, und wählen Sie Remove Site wie im Bild gezeigt:

Standorte in ND entfernen

Sobald die Standorte vollständig entfernt sind, ist jede Fabric jetzt unabhängig, und ND kann ebenfalls eingestellt werden.