Sommario

Introduzione

Introduzione

Abbreviazioni:

Obiettivo

Topologia

Dissocia siti

Passaggio 1. Dissocia siti nei modelli

Passaggio 2. Confermare che gli oggetti non siano gestiti da NDO su ciascun APIC

Passaggio 3. Rimuovi modelli vuoti

Passaggio 4. Rimuovi schemi vuoti

Passaggio 5. Dissocia siti dal tenant

Passaggio 6. Rimuovi tenant vuoto in NDO

Passaggio 7. Rimuovi applicazione NDO in ND

Passaggio 8. Rimuovi l'app NDO in ND

Introduzione

In questo documento viene descritta la procedura per dissociare i siti da Cisco Nexus Dashboard Orchestrator (NDO) e mantenerli gestiti localmente in APIC.

Introduzione

L'obiettivo è eliminare sia la DN che le NDO.

Questa procedura è utile quando i clienti stanno cercando di smantellare un sito e desiderano mantenere la configurazione che era stata inizialmente estesa, come locale, nel sito che continua.

Avviso: questo documento descrive i passaggi per dissociare i siti da Cisco Nexus Dashboard Orchestrator (NDO) e mantenere la gestione locale in APIC. L'esecuzione di questa procedura senza una corretta comprensione e cautela può comportare rischi o complicazioni. Si consiglia di prestare attenzione e di consultare gli esperti prima di apportare modifiche alla configurazione della rete.

Abbreviazioni:

APIC: controller dell'infrastruttura dei criteri delle applicazioni

ND: Dashboard Nexus

NDO: Nexus Dashboard

VRF: routing e inoltro virtuali

BD: dominio bridge

EPG: Gruppo endpoint

AP: Profilo applicazione

Obiettivo

Lo scopo di questo processo è scollegare completamente gli oggetti gestiti da NDO e gestirli singolarmente da ogni cluster APIC su ogni fabric.

Topologia

A scopo dimostrativo, viene distribuita la topologia seguente:

Topologia proposta

In NDO, la distribuzione è simile alla seguente:

- Livello tenant: il tenant denominato Tenant1 viene creato da NDO ed è associato a entrambi i siti, denominati Sito1 e Sito2:

Convalida dell'associazione tenant con 2 siti

È stato associato a 3 modelli:

Convalida dell'associazione del modello a un tenant

- Livello schema: lo schema denominato Schema1 contiene i tre modelli riportati di seguito.

Convalida dei modelli contenuti in Stretched_Schema

- Livello modello:

- Stretched_Site1_Site2 è il modello esteso, in cui è definito il VRF esteso, denominato VRF1, associato a entrambi i siti:

Verifica che il modello Stretched_Site1_Site2 sia esteso in 2 siti

- Nel modello denominato Sito1, associato solo al Sito1, il sito BD locale è definito ed è associato al VRF1 esteso. Inoltre, AP_Site1 ed EPG_Site1 sono definiti localmente nel modello:

Verifica che il modello Sito1 sia locale rispetto a un singolo sito

Verifica che il VRF per il BD locale sia esteso

- Nel modello denominato Sito2, associato solo al Sito2, viene definito il sito BD locale 2 associato al VRF1 esteso. Inoltre, AP_Site2 e EPG_Site2 sono definiti localmente nel modello:

Convalida del modello Sito 2 per la verifica locale

Verifica che il VRF per il BD locale sia esteso

Per verificare che gli oggetti siano stati distribuiti correttamente:

- In Sito1:

Tenant1 è implementato e gestito da NDO, oltre che da VRF, AP, BD ed EPG:

Convalida dell'estensione nella GUI

È possibile anche confermare che tutti gli oggetti MIT hanno l'annotazione impostata su "orchestrator:msc", cioè vengono gestiti da NDO:

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

}

}

}

]

}

},

]

}

Per il VRF, oltre all'annotazione "orchestrator:msc", sono visibili anche alcune proprietà secondarie.

Per comprendere meglio questi oggetti figlio, è importante notare che in NDO, oltre al nome del sito, a ogni sito in NDO è associato un ID sito univoco. Per eseguire una query sugli ID, in NDO passare a Operate > Sites:

Convalida di SiteID per sito in NDO

Una volta spiegate queste informazioni, gli oggetti figlio sono:

1. fvSiteAssociated: visualizza l'ID sito del sito locale.

2. fvRemoteID: ID del sito remoto in cui viene esteso anche l'oggetto. Questo oggetto è utile anche per conoscere la traslazione degli oggetti tra i siti; nel caso di questo VRF, è possibile visualizzare il segmento e il ClassID, corrispondente al Sito 2. Per confermare, è possibile eseguire un confronto dal Sito 2:

Convalida di Segment e ClassID degli oggetti remoti

Come si può notare, il segmento e il ClassID del sito 2 sono contenuti nell'oggetto fvRemoteID all'interno dell'oggetto VRF nel sito 1.

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 ed 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:" } } }, ] } } ] }

Negli oggetti BD, AP ed EPG non sono presenti oggetti figlio fvRemoteId, poiché questi oggetti sono significativi a livello locale e non vengono estesi.

- Nel sito 2:

Il sito 2 ha output abbastanza simili, cambiando solo gli oggetti remoti corrispondenti, quindi queste informazioni sono omesse.

Dissocia siti

Si consiglia di eseguire un backup in NDO e una copia istantanea nell'APIC prima di eseguire questa procedura, nel caso in cui si desideri eseguire il rollback in un secondo momento.

Passaggio 1. Dissocia siti nei modelli

Questo passaggio deve essere eseguito su ogni modello. Analogamente alla logica alla base delle dipendenze dei cerchi, è necessario iniziare prima dai modelli che hanno dipendenze da altri modelli e, infine, dissociare i modelli che non hanno riferimenti incrociati.

Nella topologia utilizzata in questo documento, l'ultimo modello a cui annullare l'associazione deve essere Stretched_Site1_Site2, in quanto i modelli Site1 e Site2 contengono un riferimento a tale modello.

Passare al modello all'interno dello schema, fare clic su Actions e passare a Disassociate Site:

Come dissociare un modello

Nella finestra successiva, scegliere dal menu a discesa sito per sito, poiché la disassociazione viene eseguita una alla volta (nel caso in cui il modello contenga più di 2 siti):

Selezione del sito da cui dissociare il modello

Quindi fare clic su Dissocia.

Al termine, viene visualizzato un messaggio con la conferma:

Messaggio di conferma

Nota: come indicato in precedenza, ripetere questa procedura per tutti i modelli dello schema.

Passaggio 2. Confermare che gli oggetti non siano gestiti da NDO su ciascun APIC

Per confermare che gli oggetti sono ancora presenti negli APIC, ora con proprietà diverse:

In APIC (esempio nel sito 1):

Convalida GUI che la configurazione persiste.

Gli oggetti non mostrano più l'icona NDO del cloud accanto ad esso, solo il tenant è ancora gestito da NDO.

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:" }, } } ] } } ] }

Oltre all'oggetto APIC, l'unico oggetto che dispone ancora dell'annotazione è l'oggetto tenant, ma gli oggetti BD, VRF, AP ed EPG hanno ora la proprietà annotation vuota. Ciò conferma che gli oggetti non vengono rimossi dall'APIC, ma vengono ora gestiti da ciascun APIC.

Passaggio 3. Rimuovi modelli vuoti

Ora che tutti i modelli sono vuoti e non associati ad alcun sito:

Convalida dei modelli in uno stato non associato

Questi modelli possono essere rimossi senza problemi. Per rimuoverli, fare clic su Actions e selezionare Delete Template come mostrato nell'immagine:

Eliminazione del modello

Quando lo schema è vuoto, salvare le modifiche:

Salva le modifiche nello schema vuoto

Passaggio 4. Rimuovi schemi vuoti

È ora di rimuovere lo schema vuoto. PassareConfigure > Tenant Templates a come mostrato nell'immagine:

Passaggi per passare al menu tenant

E fare clic sui 3 punti accanto allo schema, e fare clic su Delete come mostrato nell'immagine:

Elimina lo schema vuoto associato al modello

Passaggio 5. Dissocia siti dal tenant

Se non sono più presenti schemi, il tenant deve indicare che non è più associato ad alcun modello. Per confermare, passare a Operate > Tenants:

Dissocia siti dal tenant

Conferma dell'assenza di modelli associati al tenant

Come si può vedere, il numero di modelli associati a Tenant1 è 0. Fare clic sui 3 punti e selezionare Edit (Modifica):

Modifica proprietà tenant per rimuovere siti

A questo punto, è necessario deselezionare i siti. Fare clic su Unselect items nella parte superiore della tabella dei siti:

Deseleziona siti associati al tenant

Assicurarsi che l'opzione per l'eliminazione del tenant sia deselezionata prima di confermare:

Confermare l'operazione senza il controllo

Se entrambi i siti sono deselezionati, salvare le modifiche. Al termine, confermare il tenant in ogni APIC in cui si trova:

Convalida IGUI che il tenant è ancora configurato, ma non gestito da NDO

Come previsto, ora l'annotazione è vuota:

"fvTenant": { "attributes": { "annotation": "", "descr": "", "dn": "uni/tn-Tenant1", "name": "Tenant1", "nameAlias": "", "ownerKey": "", "ownerTag": "", "userdom": ":all:" } }

Passaggio 6. Rimuovi tenant vuoto in NDO

È ora di rimuovere il tenant. A tale scopo, passare a Operate > Tenants , fare clic sui 3 punti e fare clic su Delete come mostrato nell'immagine:

Elimina tenant vuoto

Confermare e verificare che l'oggetto tenant rimanga negli APIC.

Passaggio 7. Rimuovi applicazione NDO in ND

Per rimuovere NDO, è necessario prima disabilitare l'app.

in ND, passare a Admin Console > Services. L'applicazione NDO viene visualizzata qui. Fare clic sui 3 punti e selezionare Disable:

Disabilita applicazione NDO

Per essere completamente disabilitato possono essere necessari alcuni minuti.

Quindi, fare di nuovo clic sui 3 punti, e questa volta fare clic sull'opzione  Delete .

Passaggio 8. Rimuovi l'app NDO in ND

Infine, da ND, rimuovere i siti. Per poter rimuovere i siti, questi non devono utilizzare alcun servizio, pertanto, se è installata un'altra applicazione, è necessario rimuoverla:

Convalida che i siti non utilizzano il servizio NDO

Per rimuoverlo, fare clic sui 3 punti e scegliere Remove Site come mostrato nell'immagine:

Rimuovi siti in ND

Una volta che i siti sono stati completamente rimossi, ogni fabric è ora indipendente e anche ND può essere ritirato.

Nota: una volta che i siti sono indipendenti, il L3out per intersito nell'infra tenant è ancora presente. Può essere rimosso manualmente. Verificare che sia solo per la connettività tra siti.