Sites loskoppelen van Cisco Nexus Dashboard Orchestrator
Inhoud
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:
- fvSiteAssociated: toont de Site-ID van de lokale Site.
- 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 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. Klik op om ze te verwijderen Actions en selecteer Delete Template zoals aangegeven op 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. Naar navigeren Configure > Tenant Templates zoals aangegeven op de afbeelding:
Stappen om naar het huurdersmenu te gaan
Klik op de 3 punten naast het schema en klik op Delete zoals aangegeven op 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 van plaatsen:
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 op de 3 punten en klik op Delete zoals aangegeven op 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 aangegeven op 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.
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
30-Nov-2023 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)