Inhoud

Inleiding

Achtergrond

Afkortingen:

Doel

Topologie

Sites scheiden

Stap 1. Sites in sjablonen scheiden

Stap 2. Bevestig dat de objecten niet worden beheerd door NDO op elke APIC

Stap 3. Lege sjablonen verwijderen

Stap 4. Lege schema's verwijderen

Stap 5. Locaties loskoppelen van huurders

Stap 6. Verwijder Lege Huurder in NDO

Stap 7. NDO-toepassing verwijderen in ND

Stap 8. Verwijder de NDO-app in de ND

Inleiding

Dit document beschrijft de procedure om locaties te scheiden van de Cisco Nexus Dashboard Orchestrator (NDO) en ze lokaal te beheren in APIC’s.

Achtergrond

Het doel is om zowel ND als NDO te elimineren.

Deze procedure is nuttig wanneer klanten de uitbedrijfname van een site nastreven en de configuratie die aanvankelijk was uitgerekt, als lokaal, willen behouden op de site die doorgaat.

Waarschuwing: u wordt erop gewezen dat in dit document de stappen worden beschreven om locaties te scheiden van de Cisco Nexus Dashboard Orchestrator (NDO) en het lokale beheer in APIC's te behouden. Het volgen van deze procedure zonder voldoende begrip en voorzichtigheid kan resulteren in mogelijke risico’ s of complicaties. Het wordt aanbevolen om voorzichtig te zijn en advies van experts te vragen voordat u wijzigingen aanbrengt in uw netwerkconfiguratie.

Afkortingen:

APIC: Toepassingsbeleid Infrastructuurcontroller

ND: Nexus Dashboard

NDO: Nexus Dashboard

VRF: virtuele routing en doorsturen

BD: Bridge Domain

EPG: eindpuntgroep

AP: Toepassingsprofiel

Doel

Het doel van dit proces is om objecten volledig los te koppelen van NDO en ze individueel te beheren vanuit elke APIC-cluster op elke stof.

Topologie

Voor demonstratiedoeleinden, wordt deze topologie opgesteld:

Voorgestelde topologie

In NDO ziet de implementatie er zo uit:

- Huurder niveau: De huurder genaamd Huurder1 is gemaakt van NDO en is geassocieerd met beide sites, genaamd Site1 en Site2:

Validatie van huurdersassociatie met 2 locaties

Het is geassocieerd met 3 templates:

Bevestiging van sjabloonkoppeling aan een huurder

- Schema niveau: Het schema Schema1 bevat de 3 sjablonen:

Validatie van sjablonen in Stretched_Schema

- Sjabloonniveau:

- Stretched_Site1_Site2 is de uitgerekte sjabloon, waar de uitgerekte VRF, genaamd VRF1, is gedefinieerd en is gekoppeld aan beide sites:

Validatie dat sjabloon Stretched_Site1_Site2 wordt uitgerekt in 2 sites

- In de sjabloon met de naam Site1, die alleen aan Site1 is gekoppeld, wordt de lokale BD_Site1 gedefinieerd, en wordt deze gekoppeld aan de uitgerekte VRF1; ook worden AP_Site1 en EPG_Site1 lokaal in deze sjabloon gedefinieerd:

Bevestiging dat sjabloon Site1 lokaal is op één locatie

Validatie dat VRF voor de lokale BD de uitgerekte is

- In de template met de naam Site2, die alleen aan Site2 is gekoppeld, wordt de lokale BD_Site2 gedefinieerd, en is deze gekoppeld aan de uitgerekte VRF1; ook worden AP_Site2 en EPG_Site2 lokaal gedefinieerd in deze template:

Validatie van sjabloon Site 2 om te bevestigen is lokaal

Validatie dat VRF voor de lokale BD de uitgerekte is

U kunt als volgt bevestigen dat de objecten correct zijn geïmplementeerd:

- Op locatie1:

Tenant1 wordt ingezet en beheerd door NDO, evenals de VRF, AP, BD en EPG:

Verificatie van stretch in GUI

Het is ook mogelijk om te bevestigen dat alle MIT objecten de annotatie hebben ingesteld op "orchestrator:msc", betekenis worden beheerd van NDO:

huurder:

{

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

}

}

}

]

}

},

]

}

Voor de VRF kan worden gezien dat naast de annotatie "orchestrator:msc" ook sommige kindereigenschappen worden gezien.

Om deze kinder-objecten beter te begrijpen, is het belangrijk om op te merken dat in NDO, naast de Site-naam, een unieke site-ID is gekoppeld aan elke site in NDO. Om de ID's te bevragen, navigeer in NDO naar Operate > Sites:

Validering van SiteID per site in NDO

Zodra deze informatie wordt uitgelegd, zijn de kindvoorwerpen:

1. fvSiteAssociated: toont de Site-ID van de lokale Site.

2. fvRemoteID: De externe Site-ID's waar het object ook wordt uitgerekt. Dit object is ook nuttig om de vertaling van objecten over sites te kennen; in het geval van deze VRF, kan het segment en de ClassID worden gezien, die overeenkomen met Site 2. Om te bevestigen, kan een vergelijking worden gemaakt vanaf Site 2:

Validatie van segment en classID van externe objecten

Zoals te zien is, zijn het Segment en ClassID van Site 2, opgenomen in de fvRemoteID binnen het VRF-object in Site 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 en 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 de BD, AP en EPG objecten zijn er geen fvRemoteID-onderliggende objecten, omdat deze objecten lokaal belangrijk zijn en niet uitgerekt zijn.

- Op site 2:

Site 2 heeft vrijwel dezelfde uitgangen, alleen het veranderen van de corresponderende externe objecten, dus deze informatie wordt weggelaten.

Sites scheiden

Het wordt aanbevolen om een back-up in NDO, evenals een momentopname in de APIC voordat deze procedure te doen, voor het geval het wordt gewenst om deze later terug te rollen.

Stap 1. Sites in sjablonen scheiden

Deze stap moet op elke sjabloon worden uitgevoerd. Op dezelfde manier als de logica achter de cirkelafhankelijkheden, is het nodig om eerst te beginnen op sjablonen die afhankelijkheden hebben op andere templates, en ten slotte, de sjablonen los te koppelen die geen kruisverwijzing hebben.

In de topologie die in dit document wordt gebruikt, moet de laatste sjabloon die wordt losgekoppeld de Stretched_Site1_Site2 zijn, dit is omdat sjablonen Site1 en Site2 een verwijzing naar het hebben.

Navigeer naar de sjabloon binnen het schema, klik op Actions en navigeer naar Disassociate Site:

Sjabloon loskoppelen

In het volgende venster, kies van de drop-down menuplaats door plaats, aangezien de scheiding één voor één wordt gedaan (voor het geval dat het malplaatje meer dan 2 plaatsen heeft):

Selectie van site van waar te scheiden sjabloon

Klik vervolgens op Disassociate.

Een bericht met de bevestiging wordt weergegeven zodra het is voltooid:

Bericht van bevestiging

Opmerking: Zoals eerder vermeld, herhaal deze procedure voor alle sjablonen op het schema.

Stap 2. Bevestig dat de objecten niet worden beheerd door NDO op elke APIC

Om te bevestigen dat de objecten nog steeds aanwezig zijn in de APIC's, nu met verschillende eigenschappen:

In APIC (voorbeeld op Site 1):

GUI-validatie dat de configuratie blijft bestaan.

Objecten tonen niet meer het Cloud NDO-pictogram naast het, alleen de huurder wordt nog beheerd door 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:" }, } } ] } } ] }

Het enige object dat nog steeds de annotatie heeft, is het huurdersobject, maar de BD, VRF, AP en EPG objecten, hebben nu de annotatie eigenschap leeg. Dit bevestigt dat de objecten niet uit de APIC worden verwijderd, ze worden nu beheerd door elke APIC.

Stap 3. Lege sjablonen verwijderen

Nu alle sjablonen leeg zijn en niet gekoppeld aan een site:

Validatie van templates in niet-geassocieerde staat

Deze sjablonen kunnen veilig worden verwijderd. Om ze te verwijderen, klikt u op Actions en selecteert u Delete Template zoals in de afbeelding:

Schrappen van sjabloon

Zodra het schema leeg is, slaat u de wijzigingen op:

Veranderingen in het lege schema opslaan

Stap 4. Lege schema's verwijderen

Het is tijd om het lege schema te verwijderen. Navigeer naar Configure > Tenant Templates zoals in de afbeelding.

Stappen om naar het huurdersmenu te gaan

Klik op de 3 punten naast het schema en klik op Delete zoals in de afbeelding:

Verwijdert leeg schema gekoppeld aan de sjabloon

Stap 5. Locaties loskoppelen van huurders

Zodra er geen schema's meer zijn, moet de huurder tonen dat het niet meer met een sjabloon is geassocieerd. Ga voor bevestiging naar Operate > Tenants:

Vermijd sites van Tenant

Het bevestigen van de Huurder heeft geen sjablonen geassocieerd

Zoals kan worden gezien, is het aantal sjablonen geassocieerd met Tenant1 0. Klik op de 3 punten en selecteer Bewerken:

Bewerk huurderseigenschappen om sites te verwijderen

Nu is het nodig om de selectie van de sites te verwijderen. Klik op Unselect items bovenaan de lijst met sites:

Deselecteer locaties die geassocieerd zijn met de huurder

Zorg ervoor dat de optie om de huurder te verwijderen ongecontroleerd is voordat bevestigen:

Bevestig de bewerking zonder controle

Wanneer beide sites niet zijn ingeschakeld, slaat u de wijzigingen op. Zodra dit is gedaan, bevestig de huurder in elke APIC blijft daar:

IGUI-validatie dat de huurder nog steeds geconfigureerd is, maar niet beheerd wordt via NDO

Zoals verwacht is de annotatie nu leeg:

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

Stap 6. Verwijder Lege Huurder in NDO

Het is tijd om de huurder te verwijderen. Hiervoor navigeer je naar Operate > Tenants , klik je op de 3 punten en klik je op Delete zoals in de afbeelding:

Verwijder lege huurder

Bevestig en controleer of het huurobject in de APIC's blijft.

Stap 7. NDO-toepassing verwijderen in ND

Om NDO te verwijderen, moet de app eerst worden uitgeschakeld.

in ND, navigeer naar Admin Console > Services. De NDO-toepassing wordt hier weergegeven. Klik op de 3 punten en selecteer Disable:

NDO-toepassing uitschakelen

Het kan een paar minuten duren om volledig uitgeschakeld te zijn.

Klik vervolgens nogmaals op de 3 punten en klik deze keer op de optie  Delete .

Stap 8. Verwijder de NDO-app in de ND

Ten slotte, uit ND, verwijder de Sites. Om de sites te kunnen verwijderen, mogen ze geen diensten verbruiken, dus als een andere applicatie is geïnstalleerd, moet deze verwijderd worden naar:

Verificatie dat sites geen gebruik maken van de NDO-service

Om het te verwijderen, klik op de 3 punten en kies Remove Site zoals in de afbeelding:

Sites verwijderen in NLD

Zodra de sites volledig zijn verwijderd, is elke stof nu onafhankelijk en kan ND ook worden teruggetrokken.

Opmerking: Zodra de sites onafhankelijk zijn, is de L3out voor intersite in de infra huurder nog steeds aanwezig. Het kan handmatig worden verwijderd, zorg ervoor dat het alleen voor intersite connectiviteit.