Table des matières

Introduction

Fond

Abréviations :

Objectif

Topologie

Dissocier les sites

Étape 1. Dissocier les sites dans les modèles

Étape 2. Vérifiez que les objets ne sont pas gérés par NDO sur chaque APIC

Étape 3. Supprimer les modèles vides

Étape 4. Supprimer les schémas vides

Étape 5. Dissocier les sites du locataire

Étape 6. Supprimer le locataire vide dans NDO

Étape 7. Supprimer l'application NDO dans ND

Étape 8. Supprimer l'application NDO dans le ND

Introduction

Ce document décrit la procédure pour dissocier des sites de Cisco Nexus Dashboard Orchestrator (NDO) et les garder gérés localement dans les APIC.

Fond

L'objectif est d'éliminer à la fois les ND et les NDO.

Cette procédure est utile lorsque les clients procèdent à la désaffectation d'un site et souhaitent conserver la configuration initialement étendue, en tant que configuration locale, dans le site qui continue.

Avertissement : ce document décrit les étapes à suivre pour dissocier des sites de Cisco Nexus Dashboard Orchestrator (NDO) et assurer la gestion locale dans les APIC. Le fait de suivre cette procédure sans comprendre correctement et sans faire preuve de prudence peut entraîner des risques ou des complications. Il est recommandé d'être prudent et de demander l'avis d'un expert avant d'apporter des modifications à la configuration de votre réseau.

Abréviations :

APIC : contrôleur d'infrastructure de stratégie d'application

ND : Tableau de bord Nexus

NDO : tableau de bord Nexus

VRF : routage et transfert virtuels

BD : domaine de pont

EPG : groupe de terminaux

AP : profil d'application

Objectif

L'objectif de ce processus est de dissocier complètement les objets gérés de NDO et de les gérer individuellement à partir de chaque cluster APIC sur chaque fabric.

Topologie

À des fins de démonstration, cette topologie est déployée :

Topologie proposée

Dans NDO, le déploiement ressemble à ceci :

- Niveau du locataire : le locataire appelé Tenant1 est créé à partir de NDO et est associé aux deux sites, nommés Site1 et Site2 :

Validation de l'association du locataire avec 2 sites

Il a été associé à 3 modèles :

Validation de l'association de modèle à un locataire

- Niveau schéma : le schéma appelé Schéma1 contient les 3 modèles suivants :

Validation des modèles contenus dans Stretched_Schema

- Niveau du modèle :

- Stretched_Site1_Site2 est le modèle étiré, dans lequel le VRF étiré, appelé VRF1, est défini et associé aux deux sites :

Validation de l'extension du modèle Stretched_Site1_Site2 dans 2 sites

- Dans le modèle appelé Site1, associé uniquement à Site1, le BD_Site1 local est défini et associé au VRF1 étendu ; de plus, AP_Site1 et EPG_Site1 sont définis localement dans ce modèle :

Validation du fait que le modèle Site1 est local à un seul site

Validation que le VRF pour le BD local est le VRF étiré

- Dans le modèle appelé Site2, associé uniquement au Site2, le BD_Site2 local est défini et associé au VRF1 étiré ; de plus, AP_Site2 et EPG_Site2 sont localement définis dans ce modèle :

Validation du modèle Site 2 pour confirmer qu'il est local

Validation que le VRF pour le BD local est le VRF étiré

Pour confirmer que les objets sont correctement déployés :

- Sur le site 1 :

Tenant1 est déployé et géré par NDO, ainsi que par VRF, AP, BD et EPG :

Validation de l'extension dans GUI

Il est également possible de confirmer que tous les objets MIT ont l'annotation définie sur "orchestrator : msc", ce qui signifie qu'ils sont gérés à partir de NDO :

Locataire :

{

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

}

}

}

]

}

},

]

}

Pour le VRF, il est possible de voir qu'en plus de l'annotation « orchestrator : msc », certaines propriétés enfants sont également visibles.

Pour mieux comprendre ces objets enfants, il est important de noter que dans NDO, outre le nom du site, un ID de site unique est associé à chaque site dans NDO. Pour interroger les ID, dans NDO, accédez à Operate > Sites :

Validation de SiteID par site dans NDO

Une fois ces informations expliquées, les objets enfants sont :

1. fvSiteAssociated : affiche l'ID du site local.

2. fvRemoteID : ID du site distant auquel l'objet est étendu. Cet objet est également utile pour connaître la traduction d'objets entre les sites ; dans le cas de ce VRF, le segment et l'ID de classe peuvent être vus, correspondant au site 2. Pour confirmer, une comparaison peut être effectuée à partir du site 2 :

Validation des ID de segment et de classe des objets distants

Comme vous pouvez le constater, le Segment et l'ID de classe du site 2 sont contenus dans l'ID fvRemoteID à l'intérieur de l'objet VRF du 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 et 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:" } } }, ] } } ] }

Dans les objets BD, AP et EPG, il n'y a pas d'objets enfants fvRemoteId, car ces objets ont une signification locale et ne sont pas étirés.

- Dans le site 2 :

Le site 2 a des sorties assez similaires, ne changeant que les objets distants correspondants, donc cette information est omise.

Dissocier les sites

Il est recommandé d'effectuer une sauvegarde dans NDO, ainsi qu'un instantané dans le contrôleur APIC avant d'effectuer cette procédure, au cas où vous souhaiteriez restaurer cette procédure ultérieurement.

Étape 1. Dissocier les sites dans les modèles

Cette étape doit être exécutée sur chaque modèle. De la même manière que la logique sous-jacente aux dépendances de cercle, il est nécessaire de commencer par les modèles qui ont des dépendances sur d'autres modèles, et enfin, de dissocier les modèles qui n'ont aucune référence croisée.

Dans la topologie utilisée dans ce document, le dernier modèle à dissocier doit être Stretched_Site1_Site2, car les modèles Site1 et Site2 y font référence.

Accédez au modèle à l'intérieur du schéma, cliquez sur Actions et accédez à Disassociate Site:

Comment dissocier le modèle

Dans la fenêtre suivante, choisissez site par site dans le menu déroulant, puisque la dissociation est effectuée un par un (dans le cas où le modèle a plus de 2 sites) :

Sélection du site à partir duquel dissocier le modèle

Cliquez ensuite sur Dissocier.

Un message avec la confirmation s'affiche une fois qu'elle est terminée :

Message de confirmation

Remarque : comme indiqué précédemment, répétez cette procédure pour tous les modèles du schéma.

Étape 2. Vérifiez que les objets ne sont pas gérés par NDO sur chaque APIC

Pour confirmer que les objets sont toujours présents dans les APIC, avec maintenant des propriétés différentes :

Dans APIC (exemple sur le site 1) :

Validation de la configuration par l’interface graphique utilisateur.

Les objets n'affichent plus l'icône NDO du cloud à côté, seul le locataire est toujours géré par NDO.

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

Comme vous pouvez le voir dans l'APIC, le seul objet qui a encore l'annotation est l'objet locataire, mais les objets BD, VRF, AP et EPG ont maintenant la propriété d'annotation vide. Cela confirme que les objets ne sont pas supprimés du contrôleur APIC. Ils sont désormais gérés par chaque contrôleur APIC.

Étape 3. Supprimer les modèles vides

Maintenant que tous les modèles sont vides et ne sont associés à aucun site :

Validation des modèles dans un état non associé

Ces modèles peuvent être supprimés en toute sécurité. Pour les supprimer, cliquez sur Actions et sélectionnez Delete Template comme indiqué dans l'image :

Suppression du modèle

Une fois le schéma vide, enregistrez les modifications :

Enregistrer les modifications sur le schéma vide

Étape 4. Supprimer les schémas vides

Il est temps de supprimer le schéma vide. Naviguez jusqu'à la , comme indiquéConfigure > Tenant Templates dans l'image :

Étapes à suivre pour passer au menu du service partagé

Et cliquez sur les 3 points à côté du schéma, et cliquez sur Delete comme indiqué dans l'image :

Supprimer le schéma vide associé au modèle

Étape 5. Dissocier les sites du locataire

Une fois qu'il n'y a plus de schémas, le locataire doit montrer qu'il n'est plus associé à aucun modèle. Pour confirmer, accédez à Operate > Tenants:

Dissocier les sites du locataire

Confirmation de l'absence de modèles associés au service partagé

Comme vous pouvez le constater, le nombre de modèles associés à Tenant1 est 0. Cliquez sur les 3 points, et sélectionnez Edit :

Modifier les propriétés du locataire pour supprimer des sites

Maintenant, il est nécessaire de désélectionner les sites. Cliquez sur Unselect items en haut du tableau des sites :

Désélectionner les sites associés au locataire

Assurez-vous que l'option de suppression du service partagé est désactivée avant de confirmer :

Confirmer l'opération sans vérification

Lorsque les deux sites ne sont pas cochés, enregistrez les modifications. Une fois que cela est fait, confirmez que le locataire dans chaque APIC reste à l'intérieur :

Validation de l'interface graphique utilisateur indiquant que le service partagé est toujours configuré, mais pas géré depuis NDO

Comme prévu, l'annotation est maintenant vide :

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

Étape 6. Supprimer le locataire vide dans NDO

Il est temps de supprimer le service partagé. Pour ce faire, accédez à Operate > Tenants , cliquez sur les 3 points, puis cliquez sur Delete comme illustré dans l'image :

Supprimer un locataire vide

Vérifiez que l'objet locataire reste dans les APIC.

Étape 7. Supprimer l'application NDO dans ND

Pour supprimer NDO, l'application doit d'abord être désactivée.

dans ND, accédez à Admin Console > Services. L'application NDO s'affiche à cet endroit. Cliquez sur les 3 points et sélectionnez Disable:

Désactiver l'application NDO

Cela peut prendre quelques minutes pour être complètement désactivé.

Ensuite, cliquez à nouveau sur les 3 points, puis cette fois sur l'option  Delete .

Étape 8. Supprimer l'application NDO dans le ND

Enfin, à partir de ND, supprimez les sites. Pour pouvoir supprimer les sites, ils ne doivent pas consommer de services. Par conséquent, si une autre application est installée, elle doit être supprimée également :

Validation que les sites n'utilisent pas le service NDO

Pour le supprimer, cliquez sur les 3 points, et choisissez Remove Site comme indiqué dans l'image :

Supprimer des sites dans ND

Une fois les sites complètement supprimés, chaque fabric est désormais indépendant et ND peut également être retiré.

Remarque : une fois les sites indépendants, le L3out pour intersite dans le locataire infra est toujours présent. Il peut être supprimé manuellement. Assurez-vous que est uniquement destiné à la connectivité intersite.