Comment dissocier des sites de Cisco Nexus Dashboard Orchestrator
Table des matières
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 :
- fvSiteAssociated : affiche l'ID du site local.
- 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 l'illustre 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'à Configure > Tenant Templates comme l'illustre 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 l'illustre 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 sur Delete comme l'illustre 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 l'illustre 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.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
30-Nov-2023 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)