Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment reconstruire un fabric Cisco SD-WAN, y compris la sauvegarde et la restauration des configurations de contrôleur pour divers déploiements.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Déploiement vManage
Options DR
Remarque : Pour plus de détails sur le type de reprise après sinistre, consultez ce lien
Combinaisons :
| # | Configuration de vManage | Option DR |
|---|---|---|
| 1 | Autonome (1 noeud) | Pas de DR |
| 2 | Autonome (1 noeud) | DR à noeud unique |
| 3 | Cluster (3 noeuds ou 6 noeuds) | Pas de DR |
| 4 | Cluster (3 noeuds ou 6 noeuds) | Cluster DR de secours |
Ces étapes sont communes à toutes les combinaisons de déploiement. Elles couvrent le processus d'activation des instances de VM et d'application de la configuration CLI de base. Chaque section de combinaison indique le nombre d'instances à déployer et les étapes supplémentaires à effectuer.
Remarque : Cisco a renommé certains termes, qui sont donc interchangeables. Cisco vManage = Cisco Catalyst Manager, Cisco vBond = Cisco Catalyst Validator, Cisco vSmart = Cisco Catalyst Controller
Téléchargez les fichiers OVA pour les contrôleurs SD-WAN à partir de la page de téléchargement du logiciel Cisco ici :
Remarque : Sur les plates-formes ESXi/cloud, faites tourner les contrôleurs vSmart, vBond et vManage à l'aide du fichier OVA. Reportez-vous au document lié et assurez-vous que suffisamment de CPU, de mémoire vive et de disques sont alloués à tous les contrôleurs en fonction du type de déploiement SD-WAN. Accédez ici pour obtenir des informations supplémentaires. Veillez à attribuer un disque secondaire au noeud vManage comme indiqué dans la colonne Taille de stockage* du guide de calcul lié.
For a standalone vManage, choose the persona as COMPUTE_AND_DATA.
For a 3 node cluster, on 3 vManage nodes, the persona is set to COMPUTE_AND_DATA.
For a 6 node cluster, on 3 vManage nodes the persona is COMPUTE_AND_DATA and on rest 3 vManage nodes persona DATA.
Exemple : Choisir 1 pour COMPUTE_AND_DATA

Choisissez le disque secondaire comme indiqué :


Exemple

Remarque : Vous pouvez faire référence à la configuration du vManage existant et configurer le même schéma d'adresse IP ici.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Exemple :

Remarque : Vous pouvez faire référence à la configuration du vBond existant et configurer les mêmes configurations ici.
Conf t
vpn 0
no interface eth0
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
Une fois que vous avez un accès SSH à tous les contrôleurs, configurez ces configurations CLI sur chaque contrôleur.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Remarque : si nous utilisons une URL comme adresse vBond, assurez-vous de configurer les adresses IP du serveur DNS dans la configuration VPN 0 ou assurez-vous qu'elles peuvent être résolues.
Ces configurations sont nécessaires sur tous les contrôleurs pour activer l'interface de transport utilisée pour établir des connexions de contrôle avec les routeurs et le reste des contrôleurs.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Remarque : vous pouvez faire référence aux configurations de votre contrôleur existant et si la configuration est présente, vous pouvez ajouter cette configuration aux nouveaux contrôleurs.
Configurez le protocole de contrôle en tant que TLS uniquement si les routeurs doivent établir des connexions de contrôle sécurisées avec les noeuds vManage à l'aide de TLS. Par défaut, tous les contrôleurs et les routeurs établissent une connexion de contrôle à l'aide de DTLS. Il s'agit d'une configuration facultative requise uniquement sur les noeuds vSmart et vManage, en fonction de vos besoins.
Conf t
security
control
protocol tls
Commit
Assurez-vous que le nombre d'instances actives de Cisco SD-WAN Manager sont identiques au nombre d'instances de Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles exécutent la même version logicielle.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles sont en mesure d'atteindre l'adresse IP de gestion de Cisco SD-WAN Validator.
Assurez-vous que les certificats ont été installés sur les instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que les horloges sur tous les périphériques Cisco Catalyst SD-WAN, y compris les instances Cisco SD-WAN Manager nouvellement installées, sont synchronisées.
Assurez-vous qu'un nouvel ensemble d'IP système et d'ID de site est configuré sur les instances de Cisco SD-WAN Manager nouvellement installées, avec la même configuration de base que le cluster actif.




Dans ce cas, si nous utilisons notre propre autorité de certification, Enterprise certificate authority, sélectionnez Enterprise.


Accédez à Configuration > Devices > Control Components dans le cas des noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Remarque : nous devons utiliser les identifiants admin de vBondor une partie utilisateur de netadmingroup. Vous pouvez le vérifier dans l'interface de ligne de commande de la vBond. Sélectionnez Oui dans la liste déroulante de « Générer CSR » si nous devons installer un nouveau certificat pour vBond.
Remarque : Si le vBond est derrière un périphérique NAT/pare-feu, vérifiez si l'adresse IP de l'interface VPN 0 de vBond est traduite en une adresse IP publique. Si l'adresse IP de l'interface VPN 0 n'est pas accessible depuis vManage, utilisez l'adresse IP publique de l'interface VPN 0 dans cette étape.

Cliquez sur Add vSmart dans le cas de vManage 20.12 ou sur Add Controller dans le cas de vManage 20.15/20.18.
Une fenêtre contextuelle s'ouvre, entrez l'IP de transport VPN 0 de vSmart qui est accessible à partir de vManage.
Vérifiez l'accessibilité à l'aide de la commande ping si elle est autorisée depuis l'interface CLI de vManage vers vSmart IP.
Entrez les informations d'identification de l'utilisateur de vSmart. Notez que nous devons utiliser les informations d'identification d'administration de vSmart ou d'une partie utilisateur du groupe netadmin.
Vous pouvez le vérifier dans l'interface de ligne de commande du vSmart.
Définissez le protocole sur TLS, si nous avons l'intention d'utiliser TLS pour les routeurs afin d'établir des connexions de contrôle avec vSmart. Cette configuration doit également être configurée sur l'interface de ligne de commande des noeuds vSmarts et vManage.
Choisissez Oui dans la liste déroulante de « Générer CSR » si nous devons installer un nouveau certificat pour vSmart.
Remarque : si le vSmart est derrière le périphérique/pare-feu NAT, vérifiez si l'adresse IP de l'interface VPN 0 vSmart est traduite en une adresse IP publique, et si l'adresse IP de l'interface VPN 0 n'est pas accessible à partir de vManage, utilisez l'adresse IP publique de l'adresse IP de l'interface VPN 0 dans cette étape.

Une fois toutes les étapes terminées, vérifiez que tous les composants de contrôle sont accessibles dans Monitor>Dashboard


Vérifiez que la base de données de configuration est en cours d'exécution sur le noeud vManage.
Vous pouvez vérifier la même chose à l'aide de la commande request nms configuration-db status onvManageCLI. Le résultat est le suivant
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
Utilisez cette commande pour collecter la sauvegarde configuration-db à partir du noeud vManage de tête de base de données de configuration identifié.
request nms configuration-db backup path /opt/data/backup/
Le résultat attendu est le suivant :
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiez la sauvegarde configuration-db dans le répertoire /home/admin/ de vManage à l'aide de SCP.
Exemple de sortie de commande scp :
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Pour restaurer la sauvegarde configuration-db, nous devons d'abord configurer les informations d'identification configuration-db. Si vos identifiants configuration-db sont default(neo4j/password), nous pouvons ignorer cette étape.
Pour configurer les informations d'identification configuration-db, utilisez la commande request nms configuration-db update-admin-user. Utilisez le nom d'utilisateur et le mot de passe de votre choix.
Veuillez noter que le serveur d'applications de vManage est redémarré. En raison de laquelle l'interface utilisateur vManage devient inaccessible pendant une courte période.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Publication que nous pouvons poursuivre pour restaurer la sauvegarde configuration-db :
Nous pouvons utiliser la commande request nms configuration-db restore path /home/admin/< > pour restaurer la base de données de configuration dans le nouveau vManage :
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Une fois la base de données de configuration restaurée, assurez-vous que l'interface utilisateur vManage est accessible. Attendez environ 5 minutes, puis essayez d'accéder à l'interface utilisateur.
Une fois connecté à l'interface utilisateur avec succès, assurez-vous que la liste des routeurs Edge, le modèle, les stratégies et toutes les autres configurations qui étaient présentes sur votre interface utilisateur vManage précédente ou existante sont reflétés sur la nouvelle interface utilisateur vManage.
Une fois la base de données de configuration restaurée, nous devons réauthentifier tous les nouveaux contrôleurs (vmanage/vsmart/vbond) dans le fabric.
Remarque : en production réelle, si l'interface IP utilisée pour la ré-authentification est l'interface IP du tunnel, vous devez vous assurer que le service NETCONF est autorisé sur l'interface du tunnel de vManage, vSmart et vBond, ainsi que sur les pare-feu le long du chemin. Le port de pare-feu à ouvrir est le port TCP 830 en tant que règle bidirectionnelle du cluster DR vers tous les vBonds et vSmarts.
Sur l'interface utilisateur vmanage, cliquez sur Configuration > Devices > Controllers


Une fois tous les contrôleurs intégrés, procédez comme suit :
Sur tout serveur Cisco SD-WAN Manager du cluster nouvellement actif, effectuez les actions suivantes :
Entrez cette commande pour synchroniser le certificat racine avec tous les périphériques Cisco Catalyst SD-WAN dans le nouveau cluster actif :
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Entrez cette commande pour synchroniser l'UUID du gestionnaire Cisco SD-WAN avec le validateur Cisco SD-WAN :
https://vmanage-url/dataservice/certificate/syncvbond
Une fois le fabric restauré et les sessions de contrôle et bfd activées pour tous les contrôleurs et les arêtes du fabric, nous devons invalider les anciens contrôleurs (vmanage/vsmart/vbond) à partir de l'interface utilisateur
Remarque : Poursuivez avec la section Post Checks présentée ici, qui est commune à toutes les combinaisons de déploiement.
Assurez-vous que le nombre d'instances Cisco SD-WAN Manager actives est identique au nombre d'instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles exécutent la même version logicielle.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles sont en mesure d'atteindre l'adresse IP de gestion de Cisco SD-WAN Validator.
Assurez-vous que les certificats ont été installés sur les instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que les horloges sur tous les périphériques Cisco Catalyst SD-WAN, y compris les instances Cisco SD-WAN Manager nouvellement installées, sont synchronisées.
Assurez-vous qu'un nouvel ensemble d'IP système et d'ID de site est configuré sur les instances de Cisco SD-WAN Manager nouvellement installées, avec la même configuration de base que le cluster actif.




Dans ce cas, si nous utilisons notre propre autorité de certification, Enterprise certificate authority, sélectionnez Enterprise.


Accédez à Configuration > Devices > Control Components dans le cas des noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Remarque : nous devons utiliser les identifiants admin de vBondor une partie utilisateur de netadmingroup. Vous pouvez le vérifier dans l'interface de ligne de commande de la vBond. Sélectionnez Oui dans la liste déroulante « Générer CSR » si nous devons installer un nouveau certificat pour vBond
Remarque : Si le vBond est derrière un périphérique NAT/pare-feu, vérifiez si l'adresse IP de l'interface VPN 0 de vBond est traduite en une adresse IP publique. Si l'adresse IP de l'interface VPN 0 n'est pas accessible depuis vManage, utilisez l'adresse IP publique de l'interface VPN 0 dans cette étape

Cliquez sur Add vSmart dans le cas de vManage 20.12 ou sur Add Controller dans le cas de vManage 20.15/20.18.
Une fenêtre contextuelle s'ouvre, entrez l'IP de transport VPN 0 de vSmart qui est accessible à partir de vManage.
Vérifiez l'accessibilité à l'aide de la commande ping si elle est autorisée depuis l'interface CLI de vManage vers vSmart IP.
Entrez les informations d'identification de l'utilisateur de vSmart. Notez que nous devons utiliser les informations d'identification d'administration de vSmart ou d'une partie utilisateur du groupe netadmin.
Vous pouvez le vérifier dans l'interface de ligne de commande du vSmart.
Définissez le protocole sur TLS, si nous avons l'intention d'utiliser TLS pour les routeurs afin d'établir des connexions de contrôle avec vSmart. Cette configuration doit également être configurée sur l'interface de ligne de commande des noeuds vSmarts et vManage.
Choisissez Oui dans la liste déroulante de « Générer CSR » si nous devons installer un nouveau certificat pour vSmart.
Remarque : si le vSmart est derrière le périphérique/pare-feu NAT, vérifiez si l'adresse IP de l'interface VPN 0 vSmart est traduite en une adresse IP publique, et si l'adresse IP de l'interface VPN 0 n'est pas accessible à partir de vManage, utilisez l'adresse IP publique de l'adresse IP de l'interface VPN 0 dans cette étape.

Une fois toutes les étapes terminées, vérifiez que tous les composants de contrôle sont accessibles dans Monitor>Dashboard


Remarque : Lors de la collecte de la sauvegarde de la base de données de configuration à partir du noeud vManage existant sur lequel la récupération après sinistre est activée, assurez-vous qu'elle est collectée après la suspension et la suppression de la récupération après sinistre sur ce noeud.
Vérifiez qu'aucune réplication de reprise après sinistre n'est en cours. Accédez à Administration > Disaster Recovery et assurez-vous que l'état est Réussite et qu'il n'est pas dans un état transitoire tel que Importation en attente, Exportation en attente ou Téléchargement en attente. Si l'état n'est pas réussi, contactez le TAC Cisco et assurez-vous que la réplication est réussie avant de procéder à la pause de la reprise après sinistre.
Tout d'abord, suspendez la reprise après sinistre et assurez-vous que la tâche est terminée. Supprimez la reprise après sinistre et confirmez que la tâche est terminée.

Contactez le TAC Cisco pour vous assurer que la reprise après sinistre est correctement nettoyée.
Vérifiez que la base de données de configuration est en cours d'exécution sur le noeud vManage.
Vous pouvez vérifier la même chose à l'aide de la commande request nms configuration-db statusonvManageCLI. Le résultat est le suivant
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
Utilisez cette commande pour collecter la sauvegarde configuration-db à partir du noeud vManage de tête de base de données de configuration identifié.
request nms configuration-db backup path /opt/data/backup/
Le résultat attendu est le suivant :
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiez la sauvegarde configuration-db dans le répertoire /home/admin/ de vManage à l'aide de SCP.
Exemple de sortie de commande scp :
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Pour restaurer la sauvegarde configuration-db, nous devons d'abord configurer les informations d'identification configuration-db. Si vos identifiants configuration-db sont default(neo4j/password), nous pouvons ignorer cette étape.
Pour configurer les informations d'identification configuration-db, utilisez la commande request nms configuration-db update-admin-user.Utilisez le nom d'utilisateur et le mot de passe de votre choix.
Veuillez noter que le serveur d'applications de vManage est redémarré. En raison de laquelle l'interface utilisateur vManage devient inaccessible pendant une courte période.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Publication que nous pouvons poursuivre pour restaurer la sauvegarde configuration-db :
Nous pouvons utiliser la commande request nms configuration-db restore path /home/admin/< >pour restaurer la base de données de configuration dans le nouveau vManage :
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Une fois la base de données de configuration restaurée, assurez-vous que l'interface utilisateur vManage est accessible. Attendez environ 5 minutes, puis essayez d'accéder à l'interface utilisateur.
Une fois connecté à l'interface utilisateur avec succès, assurez-vous que la liste des routeurs Edge, le modèle, les stratégies et toutes les autres configurations qui étaient présentes sur votre interface utilisateur vManage précédente ou existante sont reflétés sur la nouvelle interface utilisateur vManage.
Reportez-vous à l’étape 2: Prévérifications dans la combinaison 2 : vManage autonome + DR noeud unique et assurez-vous que nous avons rempli toutes les conditions requises avant de procéder à l'activation de la récupération après sinistre.
Interface de cluster hors bande dans VPN 0
La configuration minimale nue pour vManageavant l'enregistrement de la reprise après sinistre, comme indiqué
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Remarque : si nous utilisons une URL comme adresse vBond, assurez-vous de configurer les adresses IP du serveur DNS dans la configuration VPN 0 ou assurez-vous qu'elles peuvent être résolues.
Ces configurations sont nécessaires pour activer l'interface de transport utilisée pour établir des connexions de contrôle avec les routeurs et le reste des contrôleurs
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurez également l'interface de gestion VPN 512 pour activer l'accès de gestion hors bande au contrôleur.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
commit
Configurez l'interface de service sur le noeud vManage. Cette interface est utilisée pour la communication DR,
conf t
interface eth2
ip address
no shutdown
commit
Assurez-vous que le même sous-réseau IP est utilisé pour l'interface de service sur le vManage principal et le DR vManage
Suivez les étapes décrites à la section Combinaison 2 : vManage autonome + DR à noeud unique Étape 3 : Configurez l'interface utilisateur, les certificats et les contrôleurs embarqués vManage pour installer le certificat sur le vManage Reprise après sinistre.

Une fois rempli, cliquez sur « Suivant ».
Renseignez les détails des contrôleurs vBond.
Les contrôleurs vBond doivent être accessibles dans l'adresse IP spécifiée via Netconf.
Les informations d'identification doivent être celles d'un utilisateur netadmin (dradmin) et ne doivent pas être modifiées une fois le DR configuré.
Pour cela, il est recommandé que vBond ait cet utilisateur dradmin configuré localement ou vous pouvez utiliser l'utilisateur admin pour ajouter le vBond.


Dans le calendrier de réplication, définissez l'intervalle de réplication’.À chaque intervalle de réplication, les données sont répliquées à partir de l'hôte principal vManage vers vManage secondaire. La valeur minimale configurable est de 15 minutes.


Notez que l'interface graphique utilisateur vManage est redémarrée au cours de ce processus.
Une fois terminé, l'état Succès doit être affiché.

Accédez à Administration → Reprise après sinistrepour voir l'état de la reprise après sinistre et la date de la dernière réplication des données.

Une fois la base de données de configuration restaurée, nous devons réauthentifier tous les nouveaux contrôleurs (vmanage/vsmart/vbond) dans le fabric
Remarque : en production réelle, si l'interface IP utilisée pour la ré-authentification est l'interface IP du tunnel, vous devez vous assurer que le service NETCONF est autorisé sur l'interface du tunnel de vManage, vSmart et vBond, ainsi que sur les pare-feu le long du chemin. Le port de pare-feu à ouvrir est le port TCP 830 en tant que règle bidirectionnelle du cluster DR vers tous les vBonds et vSmarts .
Sur l'interface utilisateur vmanage, cliquez sur Configuration > Devices > Controllers

Une fois tous les contrôleurs intégrés, procédez comme suit :
Sur tout serveur Cisco SD-WAN Manager du cluster nouvellement actif, effectuez les actions suivantes :
Entrez cette commande pour synchroniser le certificat racine avec tous les périphériques Cisco Catalyst SD-WAN dans le nouveau cluster actif :
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Entrez cette commande pour synchroniser l'UUID du gestionnaire Cisco SD-WAN avec le validateur Cisco SD-WAN :
https://vmanage-url/dataservice/certificate/syncvbond
Une fois le fabric restauré et les sessions de contrôle et bfd activées pour tous les contrôleurs et les arêtes du fabric, nous devons invalider les anciens contrôleurs (vmanage/vsmart/vbond) à partir de l'interface utilisateur
Remarque : Poursuivez avec la section Post Checks présentée ici, qui est commune à toutes les combinaisons de déploiement.
Instances nécessaires :
Étapes:
Assurez-vous que le nombre d'instances Cisco SD-WAN Manager actives est identique au nombre d'instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles exécutent la même version logicielle.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles sont en mesure d'atteindre l'adresse IP de gestion de Cisco SD-WAN Validator.
Assurez-vous que les certificats ont été installés sur les instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que les horloges sur tous les périphériques Cisco Catalyst SD-WAN, y compris les instances Cisco SD-WAN Manager nouvellement installées, sont synchronisées.
Assurez-vous qu'un nouvel ensemble d'IP système et d'ID de site est configuré sur les instances de Cisco SD-WAN Manager nouvellement installées, avec la même configuration de base que le cluster actif.




Dans ce cas, si nous utilisons notre propre autorité de certification, Enterprise certificate authority, sélectionnez Enterprise.


Accédez à Configuration > Devices > Control Components dans le cas des noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Remarque : nous devons utiliser les identifiants admin de vBondor une partie utilisateur de netadmingroup. Vous pouvez le vérifier dans l'interface de ligne de commande de la vBond. Sélectionnez Oui dans la liste déroulante « Générer CSR » si nous devons installer un nouveau certificat pour vBond
Remarque : Si le vBond est derrière un périphérique NAT/pare-feu, vérifiez si l'adresse IP de l'interface VPN 0 de vBond est traduite en une adresse IP publique. Si l'adresse IP de l'interface VPN 0 n'est pas accessible depuis vManage, utilisez l'adresse IP publique de l'interface VPN 0 dans cette étape

Cliquez sur Add vSmart dans le cas de vManage 20.12 ou sur Add Controller dans le cas de vManage 20.15/20.18.
Une fenêtre contextuelle s'ouvre, entrez l'IP de transport VPN 0 de vSmart qui est accessible à partir de vManage.
Vérifiez l'accessibilité à l'aide de la commande ping si elle est autorisée depuis l'interface CLI de vManage vers vSmart IP.
Entrez les informations d'identification de l'utilisateur de vSmart. Notez que nous devons utiliser les informations d'identification d'administration de vSmart ou d'une partie utilisateur du groupe netadmin.
Vous pouvez le vérifier dans l'interface de ligne de commande du vSmart.
Définissez le protocole sur TLS, si nous avons l'intention d'utiliser TLS pour les routeurs afin d'établir des connexions de contrôle avec vSmart. Cette configuration doit également être configurée sur l'interface de ligne de commande des noeuds vSmarts et vManage.
Choisissez Oui dans la liste déroulante de « Générer CSR » si nous devons installer un nouveau certificat pour vSmart.
Remarque : si le vSmart est derrière le périphérique/pare-feu NAT, vérifiez si l'adresse IP de l'interface VPN 0 vSmart est traduite en une adresse IP publique, et si l'adresse IP de l'interface VPN 0 n'est pas accessible à partir de vManage, utilisez l'adresse IP publique de l'adresse IP de l'interface VPN 0 dans cette étape.

Une fois toutes les étapes terminées, vérifiez que tous les composants de contrôle sont accessibles dans Monitor>Dashboard


Remarque : le cluster vManage peut être configuré avec 3 noeuds vManage ou 6 noeuds vManage en fonction du nombre de sites intégrés au fabric SD-WAN. Veuillez vous reporter à votre cluster vManage existant et choisir le nombre de noeuds correspondant.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Remarque : si nous utilisons une URL comme adresse vBond, assurez-vous de configurer les adresses IP du serveur DNS dans la configuration VPN 0 ou assurez-vous qu'elles peuvent être résolues.
Ces configurations sont nécessaires pour activer l'interface de transport utilisée pour établir des connexions de contrôle avec les routeurs et le reste des contrôleurs.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurez également l'interface de gestion VPN 512 pour activer l'accès de gestion hors bande au contrôleur.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configuration facultative :
Conf t
security
control
protocol tls
commit
Configurez l'interface de service sur tous les noeuds vManage, y compris vManage-1 qui a déjà été intégré. Cette interface est utilisée pour la communication de cluster, ce qui signifie la communication entre les noeuds vManager du cluster.
conf t
interface eth2
ip address
no shutdown
commit
Assurez-vous que le même sous-réseau IP est utilisé pour l'interface de service sur tous les noeuds dans le cluster vManage.
Nous pouvons utiliser les mêmes informations d'identification d'administration que les noeuds vManagen pour configurer le cluster vManagen. Sinon, nous pouvons configurer de nouvelles informations d'identification d'utilisateur qui font partie de netadmingroup. Les configurations permettant de configurer de nouvelles informations d'identification utilisateur sont les suivantes :
conf t
system
aaa
user
password
group netadmin
commit
Assurez-vous de configurer les mêmes informations d'identification d'utilisateur sur tous les noeuds vManagenodesqui font partie du cluster.Si nous décidons d'utiliser les informations d'identification d'administrateur, il doit s'agir du même nom d'utilisateur/mot de passe sur tous les noeuds vManagenods.
Accédez à Configuration > Certificates > Control Components en cas de noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Cliquez sur ... pour Manager/vManage et cliquez sur Generate CSR.

Une fois le CSR généré, vous pouvez télécharger le CSR et le faire signer en fonction de l'autorité de certification choisie pour les contrôleurs. Vous pouvez vérifier cette configuration dans Administration > Settings > Controller Certificate Authorization. Si vous choisissez Cisco (recommandé), le CSR est automatiquement téléchargé sur le portail PNP par vManage et une fois le certificat signé, il est installé automatiquement sur le vManage.
Si vous choisissez Manual (Manuel), signez manuellement le CSR à l'aide du portail Cisco PNP en naviguant jusqu'au compte Smart et au compte virtuel de la superposition SD-WAN correspondante. La même procédure s'applique si nous utilisons Digicert et le certificat racine d'entreprise.
Une fois le certificat disponible sur le portail PNP, cliquez sur Installer le certificat dans la même section de vManage, téléchargez le certificat et installez-le.
Effectuez cette étape sur tous les noeuds vManage qui font partie du cluster.
Remarque : Dans le cas d'un cluster à 3 noeuds, les 3 noeuds vManage sont présentés avec compute+data comme personnage.

Remarque : Reportez-vous à cette configuration dans votre cluster existant pour activer SDAVC. Vous devez la vérifier uniquement si elle est requise et si elle n'est nécessaire que sur un noeud vManage du cluster.
Cliquez sur Update.




Ces points doivent être pris en compte avant d'ajouter le noeud suivant au cluster :
Vérifiez ces points sur toutes les interfaces utilisateur des noeuds vManage qui ont été ajoutés au cluster jusqu'à présent :
Une fois tous les contrôleurs intégrés, procédez comme suit :
Remarque : Lors de la collecte de la sauvegarde de la base de données de configuration à partir du cluster vManage existant pour lequel la récupération après sinistre est activée, assurez-vous qu'elle est collectée après la suspension et la suppression de la récupération après sinistre sur ce noeud.
Vérifiez qu'aucune réplication de reprise après sinistre n'est en cours. Accédez à Administration > Disaster Recovery et assurez-vous que l'état est Réussite et qu'il n'est pas dans un état transitoire tel que Importation en attente, Exportation en attente ou Téléchargement en attente. Si l'état n'est pas réussi, contactez le TAC Cisco et assurez-vous que la réplication est réussie avant de procéder à la pause de la reprise après sinistre.
Tout d'abord, suspendez la reprise après sinistre et assurez-vous que la tâche est terminée. Supprimez la reprise après sinistre et confirmez que la tâche est terminée.

Contactez le TAC Cisco pour vous assurer que la reprise après sinistre est correctement nettoyée.
Vous pouvez vérifier la même chose à l'aide de la commande requestnmsconfiguration-dbstatus sur vManageCLI. Le résultat est le suivant
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
vManage-3# request nms configuration-db diagnostics
NMS configuration database
Checking cluster connectivity for ports 7687,7474 ...
Pinging vManage node 0 on 169.254.1.5:7687,7474...
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2026-02-18 12:41 UTC
SENT (0.0013s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (0.0022s) Handshake with 169.254.1.5:7474 completed
SENT (1.0024s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (1.0028s) Handshake with 169.254.1.5:7687 completed
SENT (2.0044s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (2.0050s) Handshake with 169.254.1.5:7474 completed
SENT (3.0064s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (3.0072s) Handshake with 169.254.1.5:7687 completed
SENT (4.0083s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (4.0091s) Handshake with 169.254.1.5:7474 completed
SENT (5.0106s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (5.0115s) Handshake with 169.254.1.5:7687 completed
Max rtt: 0.906ms | Min rtt: 0.392ms | Avg rtt: 0.724ms
TCP connection attempts: 6 | Successful connections: 6 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Pinging vManage node 1 on 169.254.2.5:7687,7474...
========== SNIP ==========
Connecting to 10.10.10.3...
+------------------------------------------------------------------------------------+
| type | row | attributes[row]["value"] |
+------------------------------------------------------------------------------------+
| "StoreSizes" | "TotalStoreSize" | 85828934 |
| "PageCache" | "Flush" | 4268666 |
| "PageCache" | "EvictionExceptions" | 0 |
| "PageCache" | "UsageRatio" | 0.09724264705882353 |
| "PageCache" | "Eviction" | 2068 |
| "PageCache" | "HitRatio" | 1.0 |
| "ID Allocations" | "NumberOfRelationshipIdsInUse" | 2068 |
| "ID Allocations" | "NumberOfPropertyIdsInUse" | 56151 |
| "ID Allocations" | "NumberOfNodeIdsInUse" | 7561 |
| "ID Allocations" | "NumberOfRelationshipTypeIdsInUse" | 31 |
| "Transactions" | "LastCommittedTxId" | 214273 |
| "Transactions" | "NumberOfOpenTransactions" | 1 |
| "Transactions" | "NumberOfOpenedTransactions" | 441742 |
| "Transactions" | "PeakNumberOfConcurrentTransactions" | 11 |
| "Transactions" | "NumberOfCommittedTransactions" | 414568 |
| "Causal Cluster" | "IsLeader" | 1 >>>>>>>>> |
| "Causal Cluster" | "MsgProcessDelay" | 0 |
| "Causal Cluster" | "InFlightCacheTotalBytes" | 0 |
+------------------------------------------------------------------------------------+
18 rows
ready to start consuming query after 388 ms, results consumed after another 13 ms
Completed
Connecting to 10.10.10.3...
Displaying the Neo4j Cluster Status
+---------------------------------------------------------------------------------------------------------------------------------+
| name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
+---------------------------------------------------------------------------------------------------------------------------------+
| "neo4j" | [] | "read-write" | "169.254.3.5:7687" | "leader" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.1.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "system" | [] | "read-write" | "169.254.3.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.1.5:7687" | "leader" | "online" | "online" | "" | FALSE | FALSE |
+---------------------------------------------------------------------------------------------------------------------------------+
6 rows
ready to start consuming query after 256 ms, results consumed after another 3 ms
Completed
Total disk space used by configuration-db:
60M .
Utilisez cette commande pour collecter la sauvegarde configuration-db à partir du noeud vManage de tête de base de données de configuration identifié.
request nms configuration-db backup path /opt/data/backup/
Le résultat attendu est le suivant :
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiez la sauvegarde configuration-db dans le répertoire /home/admin/ de vManage à l'aide de SCP.
Exemple de sortie de commande scp :
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Pour restaurer la sauvegarde configuration-db, nous devons d'abord configurer les informations d'identification configuration-db. Si vos identifiants configuration-db sont default(neo4j/password), nous pouvons ignorer cette étape.
Pour configurer les informations d'identification configuration-db, utilisez la commande request nms configuration-db update-admin-user.Utilisez le nom d'utilisateur et le mot de passe de votre choix.
Veuillez noter que le serveur d'applications de vManage est redémarré. En raison de laquelle l'interface utilisateur vManage devient inaccessible pendant une courte période.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Publication que nous pouvons poursuivre pour restaurer la sauvegarde configuration-db :
Nous pouvons utiliser la commande request nms configuration-db restore path /home/admin/< >pour restaurer la base de données de configuration dans le nouveau vManage :
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Une fois la base de données de configuration restaurée, assurez-vous que l'interface utilisateur vManage est accessible. Attendez environ 5 minutes, puis essayez d'accéder à l'interface utilisateur.
Une fois connecté à l'interface utilisateur avec succès, assurez-vous que la liste des routeurs Edge, le modèle, les stratégies et toutes les autres configurations qui étaient présentes sur votre interface utilisateur vManage précédente ou existante sont reflétés sur la nouvelle interface utilisateur vManage.
Une fois la base de données de configuration restaurée, nous devons réauthentifier tous les nouveaux contrôleurs (vmanage/vsmart/vbond) dans le fabric
Remarque : en production réelle, si l'interface IP utilisée pour la ré-authentification est l'interface IP du tunnel, vous devez vous assurer que le service NETCONF est autorisé sur l'interface du tunnel de vManage, vSmart et vBond, ainsi que sur les pare-feu le long du chemin. Le port de pare-feu à ouvrir est le port TCP 830 en tant que règle bidirectionnelle du cluster DR vers tous les vBonds et vSmarts .
Sur l'interface utilisateur vmanage, cliquez sur Configuration > Devices > Controllers

Une fois tous les contrôleurs intégrés, procédez comme suit :
Sur tout serveur Cisco SD-WAN Manager du cluster nouvellement actif, effectuez les actions suivantes :
Entrez cette commande pour synchroniser le certificat racine avec tous les périphériques Cisco Catalyst SD-WAN dans le nouveau cluster actif :
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Entrez cette commande pour synchroniser l'UUID du gestionnaire Cisco SD-WAN avec le validateur Cisco SD-WAN :
https://vmanage-url/dataservice/certificate/syncvbond
Une fois le fabric restauré et les sessions de contrôle et bfd activées pour tous les contrôleurs et les arêtes du fabric, nous devons invalider les anciens contrôleurs (vmanage/vsmart/vbond) à partir de l'interface utilisateur
Remarque : Poursuivez avec la section Post Checks présentée ici, qui est commune à toutes les combinaisons de déploiement.
Qu’est-ce que le DR manuel/en veille froide ? Le serveur de sauvegarde du gestionnaire SD-WAN ou le cluster du gestionnaire SD-WAN est maintenu en veille froide.
Des sauvegardes régulières de la base de données active sont effectuées. Si le cluster principal du gestionnaire SD-WAN ou du gestionnaire SD-WAN tombe en panne, le cluster du gestionnaire SD-WAN ou du gestionnaire SD-WAN de secours est activé manuellement et la base de données de sauvegarde est restaurée.
Instances nécessaires :
Étapes:
Assurez-vous que le nombre d'instances actives de Cisco SD-WAN Manager est identique au nombre d'instances de Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles exécutent la même version logicielle.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles sont en mesure d'atteindre l'adresse IP de gestion de Cisco SD-WAN Validator.
Assurez-vous que les certificats ont été installés sur les instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que les horloges sur tous les périphériques Cisco Catalyst SD-WAN, y compris les instances Cisco SD-WAN Manager nouvellement installées, sont synchronisées.
Assurez-vous qu'un nouvel ensemble d'IP système et d'ID de site est configuré sur les instances de Cisco SD-WAN Manager nouvellement installées, avec la même configuration de base que le cluster actif.




Dans ce cas, si nous utilisons notre propre autorité de certification, Enterprise certificate authority, sélectionnez Enterprise.


Accédez à Configuration > Devices > Control Components dans le cas des noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Remarque : nous devons utiliser les identifiants admin de vBondor une partie utilisateur de netadmingroup. Vous pouvez le vérifier dans l'interface de ligne de commande de la vBond. Sélectionnez Oui dans la liste déroulante « Générer CSR » si nous devons installer un nouveau certificat pour vBond
Remarque : Si le vBond est derrière un périphérique NAT/pare-feu, vérifiez si l'adresse IP de l'interface VPN 0 de vBond est traduite en une adresse IP publique. Si l'adresse IP de l'interface VPN 0 n'est pas accessible depuis vManage, utilisez l'adresse IP publique de l'interface VPN 0 dans cette étape

Cliquez sur Add vSmart dans le cas de vManage 20.12 ou sur Add Controller dans le cas de vManage 20.15/20.18.
Une fenêtre contextuelle s'ouvre, entrez l'IP de transport VPN 0 de vSmart qui est accessible à partir de vManage.
Vérifiez l'accessibilité à l'aide de la commande ping si elle est autorisée depuis l'interface CLI de vManage vers vSmart IP.
Entrez les informations d'identification de l'utilisateur de vSmart. Notez que nous devons utiliser les informations d'identification d'administration de vSmart ou d'une partie utilisateur du groupe netadmin.
Vous pouvez le vérifier dans l'interface de ligne de commande du vSmart.
Définissez le protocole sur TLS, si nous avons l'intention d'utiliser TLS pour les routeurs afin d'établir des connexions de contrôle avec vSmart. Cette configuration doit également être configurée sur l'interface de ligne de commande des noeuds vSmarts et vManage.
Choisissez Oui dans la liste déroulante de « Générer CSR » si nous devons installer un nouveau certificat pour vSmart.
Remarque : si le vSmart est derrière le périphérique/pare-feu NAT, vérifiez si l'adresse IP de l'interface VPN 0 vSmart est traduite en une adresse IP publique, et si l'adresse IP de l'interface VPN 0 n'est pas accessible à partir de vManage, utilisez l'adresse IP publique de l'adresse IP de l'interface VPN 0 dans cette étape.

Une fois toutes les étapes terminées, vérifiez que tous les composants de contrôle sont accessibles dans Monitor>Dashboard


Remarque : le cluster vManage peut être configuré avec 3 noeuds vManage ou 6 noeuds vManage en fonction du nombre de sites intégrés au fabric SD-WAN
Suivez les étapes décrites dans la section « Contrôleurs SD-WAN intégrés avec un seul noeud vManage dans la superposition SD-WAN » pour commencer par activer le fabric SD-WAN avec un noeud vManage et intégrer tous les validateurs (vBond) et contrôleurs (vSmart) requis.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Remarque : si nous utilisons une URL comme adresse vBond, assurez-vous de configurer les adresses IP du serveur DNS dans la configuration VPN 0 ou assurez-vous qu'elles peuvent être résolues.
Ces configurations sont nécessaires pour activer l'interface de transport utilisée pour établir des connexions de contrôle avec les routeurs et le reste des contrôleurs.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurez également l'interface de gestion VPN 512 pour activer l'accès de gestion hors bande au contrôleur.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configuration facultative :
Conf t
security
control
protocol tls
commit
Configurez l'interface de service sur tous les noeuds vManage, y compris vManage-1 qui a déjà été intégré. Cette interface est utilisée pour la communication de cluster, ce qui signifie la communication entre les noeuds vManager du cluster.
conf t
interface eth2
ip address
no shutdown
commit
Assurez-vous que le même sous-réseau IP est utilisé pour l'interface de service sur tous les noeuds dans le cluster vManage.
Nous pouvons utiliser les mêmes informations d'identification d'administration que les noeuds vManagen pour configurer le cluster vManagen. Sinon, nous pouvons configurer de nouvelles informations d'identification d'utilisateur qui font partie de netadmingroup. Les configurations permettant de configurer de nouvelles informations d'identification utilisateur sont les suivantes :
conf t
system
aaa
user
password
group netadmin
commit
Assurez-vous de configurer les mêmes informations d'identification d'utilisateur sur tous les noeuds vManagenodesqui font partie du cluster.Si nous décidons d'utiliser les informations d'identification d'administrateur, elles doivent correspondre au même nom d'utilisateur/mot de passe sur tous les noeuds vManagenods.
Accédez à Configuration > Certificates > Control Components en cas de noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Cliquez sur ... pour Manager/vManage et cliquez sur Generate CSR.

Une fois le CSR généré, vous pouvez télécharger le CSR et le faire signer en fonction de l'autorité de certification choisie pour les contrôleurs. Vous pouvez vérifier cette configuration dans Administration > Settings > Controller Certificate Authorization. Si vous choisissez Cisco (recommandé), le CSR est automatiquement téléchargé sur le portail PNP par vManage et une fois le certificat signé, il est installé automatiquement sur le vManage.
Si vous sélectionnez Manual (Manuel), signez manuellement le CSR à l'aide du portail Cisco PNP en accédant au compte Smart et au compte virtuel de la superposition SD-WAN correspondante.
Une fois le certificat disponible sur le portail PNP, cliquez sur Installer le certificat dans la même section de vManage, téléchargez le certificat et installez-le.
La même procédure s'applique si nous utilisons Digicert et le certificat racine d'entreprise.
Effectuez cette étape sur tous les noeuds vManage qui font partie du cluster.
Remarque : Dans le cas d'un cluster à 3 noeuds, les 3 noeuds vManage sont présentés avec compute+data comme personnage.
Configuration facultative :
Reportez-vous à cette configuration dans votre cluster existant pour Activer SDAVC - Nécessaire d'être coché seulement si elle est requise et n'est nécessaire que sur un noeud vManage du cluster.
Cliquez sur Update.



Ces points doivent être pris en compte avant d'ajouter le noeud suivant au cluster :
Vérifiez ces points sur toutes les interfaces utilisateur des noeuds vManage qui ont été ajoutés au cluster jusqu'à présent :
Vous pouvez activer un cluster vManage supplémentaire en suivant les étapes décrites à l'étape 4 : Créer un cluster vManage. Publiez les messages qui suivent les étapes décrites à l'étape 6 : Config-db Backup/Restore pour restaurer la sauvegarde config-db dans le cluster de secours.
Vous pouvez vérifier la même chose à l'aide de la commande requestnmsconfiguration-dbstatus sur vManageCLI. Le résultat est le suivant
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
vManage-3# request nms configuration-db diagnostics
NMS configuration database
Checking cluster connectivity for ports 7687,7474 ...
Pinging vManage node 0 on 169.254.1.5:7687,7474...
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2026-02-18 12:41 UTC
SENT (0.0013s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (0.0022s) Handshake with 169.254.1.5:7474 completed
SENT (1.0024s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (1.0028s) Handshake with 169.254.1.5:7687 completed
SENT (2.0044s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (2.0050s) Handshake with 169.254.1.5:7474 completed
SENT (3.0064s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (3.0072s) Handshake with 169.254.1.5:7687 completed
SENT (4.0083s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (4.0091s) Handshake with 169.254.1.5:7474 completed
SENT (5.0106s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (5.0115s) Handshake with 169.254.1.5:7687 completed
Max rtt: 0.906ms | Min rtt: 0.392ms | Avg rtt: 0.724ms
TCP connection attempts: 6 | Successful connections: 6 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Pinging vManage node 1 on 169.254.2.5:7687,7474...
========== SNIP ==========
Connecting to 10.10.10.3...
+------------------------------------------------------------------------------------+
| type | row | attributes[row]["value"] |
+------------------------------------------------------------------------------------+
| "StoreSizes" | "TotalStoreSize" | 85828934 |
| "PageCache" | "Flush" | 4268666 |
| "PageCache" | "EvictionExceptions" | 0 |
| "PageCache" | "UsageRatio" | 0.09724264705882353 |
| "PageCache" | "Eviction" | 2068 |
| "PageCache" | "HitRatio" | 1.0 |
| "ID Allocations" | "NumberOfRelationshipIdsInUse" | 2068 |
| "ID Allocations" | "NumberOfPropertyIdsInUse" | 56151 |
| "ID Allocations" | "NumberOfNodeIdsInUse" | 7561 |
| "ID Allocations" | "NumberOfRelationshipTypeIdsInUse" | 31 |
| "Transactions" | "LastCommittedTxId" | 214273 |
| "Transactions" | "NumberOfOpenTransactions" | 1 |
| "Transactions" | "NumberOfOpenedTransactions" | 441742 |
| "Transactions" | "PeakNumberOfConcurrentTransactions" | 11 |
| "Transactions" | "NumberOfCommittedTransactions" | 414568 |
| "Causal Cluster" | "IsLeader" | 1 >>>>>>>>> |
| "Causal Cluster" | "MsgProcessDelay" | 0 |
| "Causal Cluster" | "InFlightCacheTotalBytes" | 0 |
+------------------------------------------------------------------------------------+
18 rows
ready to start consuming query after 388 ms, results consumed after another 13 ms
Completed
Connecting to 10.10.10.3...
Displaying the Neo4j Cluster Status
+---------------------------------------------------------------------------------------------------------------------------------+
| name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
+---------------------------------------------------------------------------------------------------------------------------------+
| "neo4j" | [] | "read-write" | "169.254.3.5:7687" | "leader" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.1.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "system" | [] | "read-write" | "169.254.3.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.1.5:7687" | "leader" | "online" | "online" | "" | FALSE | FALSE |
+---------------------------------------------------------------------------------------------------------------------------------+
6 rows
ready to start consuming query after 256 ms, results consumed after another 3 ms
Completed
Total disk space used by configuration-db:
60M .
Utilisez cette commande pour collecter la sauvegarde configuration-db à partir du noeud vManage de tête de base de données de configuration identifié.
request nms configuration-db backup path /opt/data/backup/
Le résultat attendu est le suivant :
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiez la sauvegarde configuration-db dans le répertoire /home/admin/ de vManage à l'aide de SCP.
Exemple de sortie de commande scp :
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Pour restaurer la sauvegarde configuration-db, nous devons d'abord configurer les informations d'identification configuration-db. Si vos identifiants configuration-db sont default(neo4j/password), nous pouvons ignorer cette étape.
Pour configurer les informations d'identification configuration-db, utilisez la commande request nms configuration-db update-admin-user.Utilisez le nom d'utilisateur et le mot de passe de votre choix.
Veuillez noter que le serveur d'applications de vManage est redémarré. En raison de laquelle l'interface utilisateur vManage devient inaccessible pendant une courte période.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Publication que nous pouvons poursuivre pour restaurer la sauvegarde configuration-db :
Nous pouvons utiliser la commande request nms configuration-db restore path /home/admin/< >pour restaurer la base de données de configuration dans le nouveau vManage :
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Une fois la base de données de configuration restaurée, assurez-vous que l'interface utilisateur vManage est accessible. Attendez environ 5 minutes, puis essayez d'accéder à l'interface utilisateur.
Une fois connecté à l'interface utilisateur avec succès, assurez-vous que la liste des routeurs Edge, le modèle, les stratégies et toutes les autres configurations qui étaient présentes sur votre interface utilisateur vManage précédente ou existante sont reflétés sur la nouvelle interface utilisateur vManage.
Une fois la base de données de configuration restaurée, nous devons réauthentifier tous les nouveaux contrôleurs (vmanage/vsmart/vbond) dans le fabric
Remarque : en production réelle, si l'interface IP utilisée pour la ré-authentification est l'interface IP du tunnel, vous devez vous assurer que le service NETCONF est autorisé sur l'interface du tunnel de vManage, vSmart et vBond, ainsi que sur les pare-feu le long du chemin. Le port de pare-feu à ouvrir est le port TCP 830 en tant que règle bidirectionnelle du cluster DR vers tous les vBonds et vSmarts .
Sur l'interface utilisateur vmanage, cliquez sur Configuration > Devices > Controllers

Une fois tous les contrôleurs intégrés, procédez comme suit :
Sur tout serveur Cisco SD-WAN Manager du cluster nouvellement actif, effectuez les actions suivantes :
Entrez cette commande pour synchroniser le certificat racine avec tous les périphériques Cisco Catalyst SD-WAN dans le nouveau cluster actif :
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Entrez cette commande pour synchroniser l'UUID du gestionnaire Cisco SD-WAN avec le validateur Cisco SD-WAN :
https://vmanage-url/dataservice/certificate/syncvbond
Une fois le fabric restauré et les sessions de contrôle et bfd activées pour tous les contrôleurs et les arêtes du fabric, nous devons invalider les anciens contrôleurs (vmanage/vsmart/vbond) à partir de l'interface utilisateur
Remarque : Poursuivez avec la section Post Checks présentée ici, qui est commune à toutes les combinaisons de déploiement.
Instances nécessaires :
Étapes:
Assurez-vous que le nombre d'instances actives de Cisco SD-WAN Manager est identique au nombre d'instances de Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles exécutent la même version logicielle.
Assurez-vous que toutes les instances Cisco SD-WAN Manager actives et nouvelles sont en mesure d'atteindre l'adresse IP de gestion de Cisco SD-WAN Validator.
Assurez-vous que les certificats ont été installés sur les instances Cisco SD-WAN Manager nouvellement installées.
Assurez-vous que les horloges sur tous les périphériques Cisco Catalyst SD-WAN, y compris les instances Cisco SD-WAN Manager nouvellement installées, sont synchronisées.
Assurez-vous qu'un nouvel ensemble d'IP système et d'ID de site est configuré sur les instances de Cisco SD-WAN Manager nouvellement installées, avec la même configuration de base que le cluster actif.




Dans ce cas, si nous utilisons notre propre autorité de certification, Enterprise certificate authority, sélectionnez Enterprise.


Accédez à Configuration > Devices > Control Components dans le cas des noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Remarque : nous devons utiliser les identifiants admin de vBondor une partie utilisateur de netadmingroup. Vous pouvez le vérifier dans l'interface de ligne de commande de la vBond. Sélectionnez Oui dans la liste déroulante « Générer CSR » si nous devons installer un nouveau certificat pour vBond
Remarque : Si le vBond est derrière un périphérique NAT/pare-feu, vérifiez si l'adresse IP de l'interface VPN 0 de vBond est traduite en une adresse IP publique. Si l'adresse IP de l'interface VPN 0 n'est pas accessible depuis vManage, utilisez l'adresse IP publique de l'interface VPN 0 dans cette étape

Cliquez sur Add vSmart dans le cas de vManage 20.12 ou sur Add Controller dans le cas de vManage 20.15/20.18.
Une fenêtre contextuelle s'ouvre, entrez l'IP de transport VPN 0 de vSmart qui est accessible à partir de vManage.
Vérifiez l'accessibilité à l'aide de la commande ping si elle est autorisée depuis l'interface CLI de vManage vers vSmart IP.
Entrez les informations d'identification de l'utilisateur de vSmart. Notez que nous devons utiliser les informations d'identification d'administration de vSmart ou d'une partie utilisateur du groupe netadmin.
Vous pouvez le vérifier dans l'interface de ligne de commande du vSmart.
Définissez le protocole sur TLS, si nous avons l'intention d'utiliser TLS pour les routeurs afin d'établir des connexions de contrôle avec vSmart. Cette configuration doit également être configurée sur l'interface de ligne de commande des noeuds vSmarts et vManage.
Choisissez Oui dans la liste déroulante de « Générer CSR » si nous devons installer un nouveau certificat pour vSmart.
Remarque : si le vSmart est derrière le périphérique/pare-feu NAT, vérifiez si l'adresse IP de l'interface VPN 0 vSmart est traduite en une adresse IP publique, et si l'adresse IP de l'interface VPN 0 n'est pas accessible à partir de vManage, utilisez l'adresse IP publique de l'adresse IP de l'interface VPN 0 dans cette étape.

Une fois toutes les étapes terminées, vérifiez que tous les composants de contrôle sont accessibles dans Monitor>Dashboard


Remarque : le cluster vManage peut être configuré avec 3 noeuds vManage ou 6 noeuds vManage en fonction du nombre de sites intégrés au fabric SD-WAN
Suivez les étapes décrites dans la section « Contrôleurs SD-WAN intégrés avec un seul noeud vManage dans la superposition SD-WAN » pour commencer par activer le fabric SD-WAN avec un noeud vManage et intégrer tous les validateurs (vBond) et contrôleurs (vSmart) requis.
config t
system
host-name
system-ip
site-id
organization-name
vbond
commit
Remarque : si nous utilisons une URL comme adresse vBond, assurez-vous de configurer les adresses IP du serveur DNS dans la configuration VPN 0 ou assurez-vous qu'elles peuvent être résolues.
Ces configurations sont nécessaires pour activer l'interface de transport utilisée pour établir des connexions de contrôle avec les routeurs et le reste des contrôleurs.
config t
vpn 0
dns primary
dns secondary
interface eth1
ip address
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0
commit
Configurez également l'interface de gestion VPN 512 pour activer l'accès de gestion hors bande au contrôleur.
Conf t
vpn 512
interface eth0
ip address
no shutdown
!
ip route 0.0.0.0/0
!
Commit
Configuration facultative :
Conf t
security
control
protocol tls
commit
Configurez l'interface de service sur tous les noeuds vManage, y compris vManage-1 qui a déjà été intégré. Cette interface est utilisée pour la communication de cluster, ce qui signifie la communication entre les noeuds vManager du cluster.
conf t
interface eth2
ip address
no shutdown
commit
Assurez-vous que le même sous-réseau IP est utilisé pour l'interface de service sur tous les noeuds dans le cluster vManage.
Nous pouvons utiliser les mêmes informations d'identification d'administration que les noeuds vManagen pour configurer le cluster vManagen. Sinon, nous pouvons configurer de nouvelles informations d'identification d'utilisateur qui font partie de netadmingroup. Les configurations permettant de configurer de nouvelles informations d'identification utilisateur sont les suivantes :
conf t
system
aaa
user
password
group netadmin
commit
Assurez-vous de configurer les mêmes informations d'identification d'utilisateur sur tous les noeuds vManagenodesqui font partie du cluster.Si nous décidons d'utiliser les informations d'identification d'administrateur, elles doivent correspondre au même nom d'utilisateur/mot de passe sur tous les noeuds vManagenods.
Accédez à Configuration > Certificates > Control Components en cas de noeuds vManage 20.15/20.18. Dans le cas des versions 20.9/20.12, Configuration > Devices > Controllers
Cliquez sur ... pour Manager/vManage et cliquez sur Generate CSR.

Une fois le CSR généré, vous pouvez télécharger le CSR et le faire signer en fonction de l'autorité de certification choisie pour les contrôleurs. Vous pouvez vérifier cette configuration dans Administration > Settings > Controller Certificate Authorization. Si vous choisissez Cisco (recommandé), le CSR est automatiquement téléchargé sur le portail PNP par vManage et une fois le certificat signé, il est installé automatiquement sur le vManage.
Si vous sélectionnez Manual (Manuel), signez manuellement le CSR à l'aide du portail Cisco PNP en accédant au compte Smart et au compte virtuel de la superposition SD-WAN correspondante.
Une fois le certificat disponible sur le portail PNP, cliquez sur Installer le certificat dans la même section de vManage, téléchargez le certificat et installez-le.
La même procédure s'applique si nous utilisons Digicert et le certificat racine d'entreprise.
Effectuez cette étape sur tous les noeuds vManage qui font partie du cluster.
Remarque : Dans le cas d'un cluster à 3 noeuds, les 3 noeuds vManage sont présentés avec compute+data comme personnage. Dans le cas d'un cluster à 6 noeuds, 3 noeuds vManage sont activés avec compute+data en tant que personnage et 3 noeuds vManage avec des données en tant que personnage.

Configuration facultative :
Reportez-vous à cette configuration dans votre cluster existant pour Activer SDAVC - Nécessaire d'être coché seulement si elle est requise et n'est nécessaire que sur un noeud vManage du cluster.
Cliquez sur Update.



Ces points doivent être pris en compte avant d'ajouter le noeud suivant au cluster :
Vérifiez ces points sur toutes les interfaces utilisateur des noeuds vManage qui ont été ajoutés au cluster jusqu'à présent :
Remarque : Lors de la collecte de la sauvegarde de la base de données de configuration à partir du cluster vManage existant pour lequel la récupération après sinistre est activée, assurez-vous qu'elle est collectée après la suspension et la suppression de la récupération après sinistre sur ce noeud.
Vérifiez qu'aucune réplication de reprise après sinistre n'est en cours. Accédez à Administration > Disaster Recovery et assurez-vous que l'état est Réussite et qu'il n'est pas dans un état transitoire tel que Importation en attente, Exportation en attente ou Téléchargement en attente. Si l'état n'est pas réussi, contactez le TAC Cisco et assurez-vous que la réplication est réussie avant de procéder à la pause de la reprise après sinistre.
Tout d'abord, suspendez la reprise après sinistre et assurez-vous que la tâche est terminée. Supprimez la reprise après sinistre et confirmez que la tâche est terminée.

Contactez le TAC Cisco pour vous assurer que la reprise après sinistre est correctement nettoyée.
Vous pouvez vérifier la même chose à l'aide de la commande requestnmsconfiguration-dbstatus sur vManageCLI. Le résultat est le suivant
vmanage# request nms configuration-db status
NMS configuration database
Enabled: true
Status: running PID:32632 for 1066085s
Native metrics status: ENABLED
Server-load metrics status: ENABLED
vmanage#
vManage-3# request nms configuration-db diagnostics
NMS configuration database
Checking cluster connectivity for ports 7687,7474 ...
Pinging vManage node 0 on 169.254.1.5:7687,7474...
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2026-02-18 12:41 UTC
SENT (0.0013s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (0.0022s) Handshake with 169.254.1.5:7474 completed
SENT (1.0024s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (1.0028s) Handshake with 169.254.1.5:7687 completed
SENT (2.0044s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (2.0050s) Handshake with 169.254.1.5:7474 completed
SENT (3.0064s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (3.0072s) Handshake with 169.254.1.5:7687 completed
SENT (4.0083s) Starting TCP Handshake > 169.254.1.5:7474
RCVD (4.0091s) Handshake with 169.254.1.5:7474 completed
SENT (5.0106s) Starting TCP Handshake > 169.254.1.5:7687
RCVD (5.0115s) Handshake with 169.254.1.5:7687 completed
Max rtt: 0.906ms | Min rtt: 0.392ms | Avg rtt: 0.724ms
TCP connection attempts: 6 | Successful connections: 6 | Failed: 0 (0.00%)
Nping done: 1 IP address pinged in 5.01 seconds
Pinging vManage node 1 on 169.254.2.5:7687,7474...
========== SNIP ==========
Connecting to 10.10.10.3...
+------------------------------------------------------------------------------------+
| type | row | attributes[row]["value"] |
+------------------------------------------------------------------------------------+
| "StoreSizes" | "TotalStoreSize" | 85828934 |
| "PageCache" | "Flush" | 4268666 |
| "PageCache" | "EvictionExceptions" | 0 |
| "PageCache" | "UsageRatio" | 0.09724264705882353 |
| "PageCache" | "Eviction" | 2068 |
| "PageCache" | "HitRatio" | 1.0 |
| "ID Allocations" | "NumberOfRelationshipIdsInUse" | 2068 |
| "ID Allocations" | "NumberOfPropertyIdsInUse" | 56151 |
| "ID Allocations" | "NumberOfNodeIdsInUse" | 7561 |
| "ID Allocations" | "NumberOfRelationshipTypeIdsInUse" | 31 |
| "Transactions" | "LastCommittedTxId" | 214273 |
| "Transactions" | "NumberOfOpenTransactions" | 1 |
| "Transactions" | "NumberOfOpenedTransactions" | 441742 |
| "Transactions" | "PeakNumberOfConcurrentTransactions" | 11 |
| "Transactions" | "NumberOfCommittedTransactions" | 414568 |
| "Causal Cluster" | "IsLeader" | 1 >>>>>>>>> |
| "Causal Cluster" | "MsgProcessDelay" | 0 |
| "Causal Cluster" | "InFlightCacheTotalBytes" | 0 |
+------------------------------------------------------------------------------------+
18 rows
ready to start consuming query after 388 ms, results consumed after another 13 ms
Completed
Connecting to 10.10.10.3...
Displaying the Neo4j Cluster Status
+---------------------------------------------------------------------------------------------------------------------------------+
| name | aliases | access | address | role | requestedStatus | currentStatus | error | default | home |
+---------------------------------------------------------------------------------------------------------------------------------+
| "neo4j" | [] | "read-write" | "169.254.3.5:7687" | "leader" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "neo4j" | [] | "read-write" | "169.254.1.5:7687" | "follower" | "online" | "online" | "" | TRUE | TRUE |
| "system" | [] | "read-write" | "169.254.3.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.2.5:7687" | "follower" | "online" | "online" | "" | FALSE | FALSE |
| "system" | [] | "read-write" | "169.254.1.5:7687" | "leader" | "online" | "online" | "" | FALSE | FALSE |
+---------------------------------------------------------------------------------------------------------------------------------+
6 rows
ready to start consuming query after 256 ms, results consumed after another 3 ms
Completed
Total disk space used by configuration-db:
60M .
Utilisez cette commande pour collecter la sauvegarde configuration-db à partir du noeud vManage de tête de base de données de configuration identifié.
request nms configuration-db backup path /opt/data/backup/
Le résultat attendu est le suivant :
vmanage# request nms configuration-db backup path /opt/data/backup/june18th
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved backup to /opt/data/backup/june18th.tar.gz
sha256sum: 8d0f5af8aee4e70f05e3858be6bdd5e6c136134ae47c383569ec883080f5d359
Removing the temp staging dir :/opt/data/backup/staging
vmanage#
Copiez la sauvegarde configuration-db dans le répertoire /home/admin/ de vManage à l'aide de SCP.
Exemple de sortie de commande scp :
XXXXXXXXX Downloads % scp june18th.tar.gz admin@10.66.62.27:/home/admin/
viptela 20.15.4.1
(admin@10.66.62.27) Password:
(admin@10.66.62.27) Password:
june18th.tar.gz 0% 255KB 47.2KB/s - stalled -
Pour restaurer la sauvegarde configuration-db, nous devons d'abord configurer les informations d'identification configuration-db. Si vos identifiants configuration-db sont default(neo4j/password), nous pouvons ignorer cette étape.
Pour configurer les informations d'identification configuration-db, utilisez la commande request nms configuration-db update-admin-user.Utilisez le nom d'utilisateur et le mot de passe de votre choix.
Veuillez noter que le serveur d'applications de vManage est redémarré. En raison de laquelle l'interface utilisateur vManage devient inaccessible pendant une courte période.
vmanage# request nms configuration-db update-admin-user
configuration-db
Enter current user name:neo4j
Enter current user password:password
Enter new user name:ciscoadmin
Enter new user password:ciscoadmin
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully updated configuration database admin user(this is service node, please repeat same operation on all service/data nodes)
Successfully restarted vManage Device Data Collector
Successfully restarted NMS application server
Successfully restarted NMS data collection agent
vmanage#
Publication que nous pouvons poursuivre pour restaurer la sauvegarde configuration-db :
Nous pouvons utiliser la commande request nms configuration-db restore path /home/admin/< >pour restaurer la base de données de configuration dans le nouveau vManage :
vmanage# request nms configuration-db restore path /home/admin/june18th.tar.gz
Starting backup of configuration-db
config-db backup logs are available in /var/log/nms/neo4j-backup.log file
Successfully saved database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Successfully backup database to /opt/data/backup/configdb-local-tmp-20230623-160954.tar.gz
Configuration database is running in a standalone mode
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Successfully saved cluster configuration for localhost
Successfully saved vManage root CA information for device: "53f95156-f56b-472f-b713-d164561b25b7"
Stopping NMS application server on localhost
Stopping NMS configuration database on localhost
Reseting NMS configuration database on localhost
Loading NMS configuration database on localhost
Starting NMS configuration database on localhost
Waiting for 180s or the instance to start...
NMS configuration database on localhost has started.
Updating DB with the saved cluster configuration data
Successfully reinserted cluster meta information
Successfully reinserted vmanage root ca information
Starting NMS application server on localhost
Waiting for 180s for the instance to start...
Successfully restored database
Une fois la base de données de configuration restaurée, assurez-vous que l'interface utilisateur vManage est accessible. Attendez environ 5 minutes, puis essayez d'accéder à l'interface utilisateur.
Une fois connecté à l'interface utilisateur avec succès, assurez-vous que la liste des routeurs Edge, le modèle, les stratégies et toutes les autres configurations qui étaient présentes sur votre interface utilisateur vManage précédente ou existante sont reflétés sur la nouvelle interface utilisateur vManage.
Précontrôles importants
Deux clusters à 3 noeuds vManage distincts doivent être configurés et opérationnels pour poursuivre la reprise après sinistre. Sur le cluster actif, vous devez avoir des validateurs et des contrôleurs intégrés. Si vous avez des validateurs et des contrôleurs sur le site DR, ils doivent également être intégrés sur le cluster actif et non sur le cluster vManage DR.
Cisco recommande de respecter les conditions suivantes avant d'enregistrer une reprise après sinistre :
Configurations
Pour plus d'informations sur vManage Disaster Recovery, consultez ce lien.
Les deux clusters à 3 noeuds distincts sont déjà créés, à condition que chaque gestionnaire SD-WAN dispose d'une configuration minimale et que la partie certification soit terminée.
Accédez à Administration > Cluster Management sur les deux clusters et vérifiez que tous les noeuds sont à l'état Prêt.
DC vManage

DR vmanage

Accédez à Administration>Reprise après sinistre du cluster vManage principal. Cliquez sur Gérer la reprise après sinistre.

Dans la fenêtre contextuelle, renseignez les détails de vManage principal et secondaire.
Les adresses IP à indiquer sont les adresses IP des interfaces de cluster hors bande. Utilisez de préférence l'adresse IP de l'interface de service VPN 0 de vManage-1 dans chaque cluster.
Les informations d'identification doivent être celles d'un utilisateur netadmin et ne doivent pas être modifiées une fois le DR configuré, sauf si celui-ci est supprimé. Vous pouvez utiliser des informations d'identification d'utilisateur local vManage distinctes pour la reprise après sinistre. Nous devons nous assurer que l'utilisateur local vManage fait partie du groupe netadmin. Même les identifiants d'administrateur peuvent être utilisés ici.

Une fois rempli, cliquez sur Next.
Les contrôleurs vBond doivent être accessibles dans l'adresse IP spécifiée via Netconf.

Une fois rempli, cliquez sur Next.


Définissez la valeur et cliquez sur Save.

Vérification
Accédez à Administration>Disaster Recovery afin de voir l'état de la reprise après sinistre et quand les données ont été répliquées la dernière fois.

Remarque : La réplication peut prendre plusieurs heures en fonction de la taille de la base de données. En outre, quelques cycles peuvent être nécessaires pour réussir la réplication.
Une fois la base de données de configuration restaurée, nous devons réauthentifier tous les nouveaux contrôleurs (vmanage/vsmart/vbond) dans le fabric
Remarque : en production réelle, si l'interface IP utilisée pour la ré-authentification est l'interface IP du tunnel, vous devez vous assurer que le service NETCONF est autorisé sur l'interface du tunnel de vManage, vSmart et vBond, ainsi que sur les pare-feu le long du chemin. Le port de pare-feu à ouvrir est le port TCP 830 en tant que règle bidirectionnelle du cluster DR vers tous les vBonds et vSmarts .
Sur l'interface utilisateur vmanage, cliquez sur Configuration > Devices > Controllers

Une fois tous les contrôleurs intégrés, procédez comme suit :
Sur tout serveur Cisco SD-WAN Manager du cluster nouvellement actif, effectuez les actions suivantes :
Entrez cette commande pour synchroniser le certificat racine avec tous les périphériques Cisco Catalyst SD-WAN dans le nouveau cluster actif :
https://vmanage-url/dataservice/system/device/sync/rootcertchain
Entrez cette commande pour synchroniser l'UUID du gestionnaire Cisco SD-WAN avec le validateur Cisco SD-WAN :
https://vmanage-url/dataservice/certificate/syncvbond
Une fois le fabric restauré et les sessions de contrôle et bfd activées pour tous les contrôleurs et les arêtes du fabric, nous devons invalider les anciens contrôleurs (vmanage/vsmart/vbond) à partir de l'interface utilisateur
Ces contrôles postérieurs s'appliquent à toutes les combinaisons de déploiement.
request platform software sdwan vedge_cloud activate chassis-number token
Vérifiez que les éléments apparaissent comme prévu :
Modèles
Politiques
Page Périphérique (les deux onglets)Liste WAN vEdgeControllers
Applicable aux noeuds vManage :
Contrôles de configuration-DB(Neo4j) :
Exécutez la commande « request nms configuration-db diagnostics » sur tous les noeuds vManage :
1. Vérifier le statut du noeud en ligne et du leadership : (non disponible pour toutes les versions)
«Neo4j» doit montrer 3 noeuds en ligne et 1 leader et 2 suiveurs. «system» doit également afficher 3 noeuds en ligne et 1 point de repère et 2 suiveurs, mais comme ce n'est pas le Db par défaut, l'indicateur par défaut est false. S'il y a moins de 3 entrées dans chaque neo4j et que le système signifie que le noeud est tombé de la grappe. Veuillez contacter le TAC Cisco pour le dépanner.
2. Vérifiez si un noeud est en « quarantaine ».

Aucun des noeuds ne doit être en état de quarantaine.
3. La validation du schéma doit être réussie.

4. Collectez une sauvegarde configuration-db à l'aide de la commande « request nms configuration-db diagnostics » et assurez-vous qu'elle est correcte.

En cas d'incohérence ou d'erreur, contactez le centre d'assistance technique Cisco pour obtenir des informations de dépannage.
Vous pouvez également exécuter ces appels d'API pour confirmer l'état du noeud vmanage pour un cluster (pour tous les noeuds COMPUTE+DATA) - fonctionne uniquement sur les versions 20.12 et ultérieures
go to vshell of the vmanage node ( to be done on all vmanages)
===============================================================
curl -u : -H "Content-Type: application/json" -d '{"statements":[{"statement":"call dbms.cluster.overview"}]}' http://:7474/db/neo4j/tx/commit | jq -r
curl -u : -H "Content-Type: application/json" -d '{"statements":[{"statement":"show databases"}]}' http://:7474/db/neo4j/tx/commit | jq -r Assurez-vous que dans un cluster n'a qu'un seul leader pour neo4j et le système et restez en tant que suiveurs .Assurez-vous que tous les noeuds sont en ligne .Si vous avez un cluster de 3 noeuds (les trois sont CALCULER+DONNÉES), il doit y avoir un seul leader pour neo4j et le système .Toute déviation, vous devez contacter le TAC
5. Recherchez les erreurs de disque, de mémoire et d'E/S dans /var/log/kern.log. Cela doit être vérifié sur tous les noeuds vManage.
6. Vérifiez l'étape lorsque vous formez un nouveau cluster pour vmanage qui n'ont pas de CC entre chaque noeud
Exécutez ssh en tant que vmanage-admin du noeud 1 vers les autres noeuds cluster ip et vice versa, pour vérifier si la clé publique est échangée et si le mot de passe moins ssh fonctionne [le jeton de consentement est requis pour les étapes indiquées ici]
DR-vManage-1:~# ssh -i /etc/viptela/.ssh/id_dsa -p 830 vmanage-admin@
The authenticity of host '[192.168.50.5]:830 ([192.168.50.5]:830)' can't be established.
ECDSA key fingerprint is SHA256:rSpscoYCVC+yifUMHVTlxtjqmyrZSFg93msFdoSUieQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[192.168.50.5]:830' (ECDSA) to the list of known hosts.
viptela 20.9.3.0.31
Password:
Si le résultat vous demande d'entrer le mot de passe, contactez le TAC
Applicable à tous les contrôleurs SD-WAN (vBond, vManage, vSmart) :
Exécutez les commandes sur tous les contrôleurs de la superposition et vérifiez que l'UUID vManage et les numéros de série affichés sont valides pour le fabric actuel :
Commandes vBond :
show orchestrator valid-vsmarts
show orchestrator valid-vmanage-id
Commandes vManage/vSmart :
show control valid-vsmarts
show control valid-vmanage-id
Notez que le résultat de la commande show control valid-vsmarts inclut les numéros de série des noeuds vSmarts et vManage.
Comparez-le à ceux de l'interface utilisateur vManage. Accédez à la section Configuration > Certificates > Controllers.
Si des entrées supplémentaires sont visibles pour l'UUID/le numéro de série qui ne sont pas actuellement intégrés au fabric, nous devons les supprimer. Vous pouvez contacter le centre d'assistance technique de Cisco pour la même question.
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
25-Feb-2026
|
Première publication |
Commentaires