The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the procedure to disassociate sites from the Cisco Nexus Dashboard Orchestrator (NDO) and keep them managed locally in APICs.
The goal is to eliminate both ND and NDO.
This procedure is useful when customers are pursuing the decommission of a site and want to keep the configuration that was initially stretched, as local, in the site that continues up.
Warning: Please be advised that this document outlines the steps to disassociate sites from the Cisco Nexus Dashboard Orchestrator (NDO) and maintain local management in APICs. Proceeding with this procedure without proper understanding and caution may result in potential risks or complications. It is recommended to exercise caution and seek expert guidance before making any changes to your network configuration.
APIC: Application Policy Infrastructure Controller
ND: Nexus Dashboard
NDO: Nexus Dashboard
VRF: Virtual routing and forwarding
BD: Bridge Domain
EPG: EndPoint Group
AP: Application Profile
The purpose of this process is to fully unlink objects managed from NDO and manage them individually from each APIC cluster on every fabric.
For demonstration purposes, this topology is deployed:
In NDO, the deployment looks like this:
It has been associated with 3 templates:
To confirm the objects are correctly deployed:
Tenant1 is deployed and managed by NDO, as well as the VRF, AP, BD and EPG:
It is possible to confirm as well that all the MIT objects have the annotation set to "orchestrator:msc", meaning are managed from 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:"
}
}
}
]
}
},
]
}
For the VRF, it can be seen that besides the "orchestrator:msc" annotation, some children properties are also seen.
To understand better these children objects, it is important to notice that in NDO, besides the Site name, a unique site ID is associated with each site in NDO. To query the IDs, in NDO, navigate to Operate > Sites
:
Once this information is explained, the children objects are:
As can be seen, the Segment and ClassID from Site 2, are contained in the fvRemoteID inside the 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 and 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 the BD, AP, and EPG objects, there are no fvRemoteId children objects, since these objects are locally significant, and are not stretched.
Site 2 has pretty similar outputs, only changing the corresponding remote objects, so this information is omitted.
It is recommended to take a backup in NDO, as well as a snapshot in the APIC before doing this procedure, in case it is desired to roll this back later.
This step needs to be run on each template. Similarly to the logic behind the circle dependencies, it is needed to start first on templates that have dependencies on other templates, and finally, disassociate the templates that do not have any cross reference.
In the topology used in this document, the last template to be disassociated must be the Stretched_Site1_Site2, this, is because templates Site1 and Site2 have a reference to it.
Navigate to the template inside the schema, click on Actions
, and navigate to Disassociate Site
:
In the next window, choose from the drop-down menu site by site, since the disassociation is done one by one (in case the template has more than 2 sites):
Then click on Disassociate.
A message with the confirmation is displayed once it finishes:
Note: As mentioned before, repeat this procedure for all templates on the schema.
To confirm the objects are still present in the APICs, now with different properties:
In APIC (example in Site 1):
Objects do not show the Cloud NDO icon next to it anymore, only the Tenant is still managed by 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:"
},
}
}
]
}
}
]
}
As well as seen from the APIC, the only object that still has the annotation is the tenant object, but the BD, VRF, AP, and EPG objects, have now the annotation property empty. This confirms the objects are not removed from the APIC, they now are managed by each APIC.
Now that all the templates are empty and not associated with any site:
These templates can be safely removed. To remove them, click on Actions
and select Delete Template
as shown in the image:
Once the schema is empty, save the changes:
It is time to remove the empty schema. Navigate to Configure > Tenant Templates
as shown in the image:
And click on the 3 dots next to the schema, and click on Delete
as shown in the image:
Once there are no more schemas, the tenant must show it is no longer associated with any template. To confirm, navigate to Operate > Tenants
:
As can be seen, the number of templates associated with Tenant1 is 0. Click on the 3 dots, and select Edit:
Now, it is needed to unselect the sites. Click on Unselect items
at the top of the table of sites:
Ensure the option to delete the tenant is unchecked before confirming:
When both sites are unchecked, save the changes. Once this is done, confirm the Tenant in each APIC stays in there:
As expected, now the annotation is empty:
"fvTenant":
{
"attributes":
{
"annotation": "",
"descr": "",
"dn": "uni/tn-Tenant1",
"name": "Tenant1",
"nameAlias": "",
"ownerKey": "",
"ownerTag": "",
"userdom": ":all:"
}
}
It is time to remove the Tenant. To do so, navigate to Operate > Tenants
, click on the 3 dots, and click on Delete
as shown in the image:
Confirm, and verify the Tenant Object stays in the APICs.
To remove NDO, the app needs to be disabled first.
in ND, navigate to Admin Console > Services
. The NDO application is displayed there. Click on the 3 dots and select Disable
:
It can take a couple of minutes to be completely disabled.
Then, click on the 3 dots again, and this time click on the option Delete
.
Finally, from ND, remove the Sites. To be able to remove the sites, they must not be consuming any services, so, if any other application is installed, it needs to be removed too:
To remove it, click on the 3 dots, and choose Remove Site
as shown in the image:
Once the sites are completely removed, each fabric is independent now and ND can also be retired.
Note: Once the sites are independent, the L3out for intersite in the infra tenant is still present. It can be manually removed, make sure is only for intersite connectivity.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
30-Nov-2023 |
Initial Release |