Introduction
Ce document décrit comment identifier un vEdge avec un certificat expiré qui peut affecter les connexions de contrôle et les connexions de plan de données, et entraîner une perte de service.
Informations générales
Ce problème concerne les plates-formes vEdge 100M, vEdge 100WM, vEdge 100B, vEdge 1000 et vEdge 2000. Cela est dû à un certificat racine public qui a expiré le 9 mai 2023 à 6:57 UTC.
Remarque : cet incident n'affecte pas ces plates-formes :
1. Cloud vEdge, vEdge 5000 et ISR 1100 exécutant Viptela OS
2. Plates-formes de routage Cisco (physiques et virtuelles) exécutant le logiciel SD-WAN XE
vEdge# show control local-properties
personality vedge
sp-organization-name CALO - 100589
organization-name CALO - 100589
root-ca-chain-status Installed
certificate-status Installed
certificate-validity Not Valid - certificate has expired <<<<<<<<<<<<<<<<<<<<
certificate-not-valid-before May 12 17:11:21 2013 GMT
certificate-not-valid-after Jan 19 03:14:07 2038 GMT
Dans le cas où le périphérique a été rechargé après l'heure X (soit 6:57 UTC 9 mai 2023), ceci est également vu :
serial-num BOARD-ID-NOT-INITIALISED
Attention : ce problème s'applique lorsque l'autorisation de certificat de périphérie WAN du matériel est définie sur Certificats d'entreprise ou Certificats de boîte de réception dans vManage.
Ces conditions peuvent avoir un impact sur le système vEdge :
- Perte de connexions à vSmart
- Perte de connexions à vManage
- Saut De Port
- Contrôler les changements de stratégie tels que les changements de topologie dans le réseau
- Effacer la connexion de contrôle
- Volets d'interface
- Rechargement du périphérique
Remarque : lors de l'établissement de la connexion de contrôle, le certificat Onbox est validé par les contrôleurs dans tous les cas. Lorsque des certificats d'entreprise sont utilisés, les certificats Onbox et Enterprise sont validés.
Remarque : pour plus d'informations sur ce comportement, reportez-vous à l'ID de bogue Cisco CSCwf28118.
Précautions à prendre pour éviter les interruptions de service
Afin d'éviter une perte totale de service, ÉVITEZ ces actions dans cette section.
- Recharger le périphérique
- Mettre à jour la stratégie
- Poussoirs de modèle
Attention : le rechargement du périphérique entraîne la réinitialisation des minuteurs de redémarrage en douceur et le routeur ne peut pas se reconnecter au fabric. Sans rechargement, les sessions du plan de données restent actives et le trafic peut passer jusqu'à l'expiration du minuteur de redémarrage en douceur, même lorsque les connexions de contrôle sont désactivées.
Processus de correction
Cisco a publié des versions de mise à niveau du logiciel pour résoudre ce problème de manière permanente. Lisez attentivement l'intégralité du processus avant d'entreprendre une action.
Le processus de haut niveau permettant de résoudre ce problème est le suivant :
- Effectuez des vérifications préalables pour vous préparer à la mise à niveau de votre ou de vos contrôleurs
- Mettre à niveau le ou les contrôleurs SD-WAN vers une version fixe
- Restaurer le contrôle et les connexions BFD entre vEdge et les contrôleurs
- Effectuez des vérifications préalables pour vous préparer à mettre à niveau votre logiciel vEdge
- Mettre à niveau le logiciel vEdge vers une version fixe
- Considérations post-mise à niveau
Trois scénarios sont référencés ici. Les étapes de correction varient en fonction du scénario qui s'applique à chaque serveur vEdge de votre réseau.
Scénario 1 : la connexion de contrôle vEdge est activée et le serveur vEdge N'A PAS été redémarré.
Scénario 2 : la connexion de contrôle vEdge est désactivée et le serveur vEdge N'A PAS été redémarré.
Scénario 3 : la connexion de contrôle vEdge est DÉSACTIVÉE et le serveur vEdge A été redémarré.
Versions logicielles fixes
Cisco continue à travailler à la création et à la validation de versions logicielles fixes aussi rapidement que possible. Cette page est mise à jour à mesure que de nouvelles versions sont validées et publiées sur Cisco.com.
Conseil : utilisez la fonction « Mes notifications » disponible sur la page Software Downloads (Téléchargements de logiciels) sur Cisco.com pour être averti lorsque de nouveaux logiciels sont disponibles pour tout produit Cisco qui vous intéresse.
Utilisez le tableau ci-dessous pour déterminer la version vers laquelle vous pouvez effectuer la mise à niveau en fonction de votre version actuelle. Il est possible que plusieurs chemins de mise à niveau soient pris en charge.
D'autres versions sont ajoutées dès qu'elles sont disponibles. Si votre version n'est pas répertoriée dans la colonne Current Version, il n'y a pas de chemin de mise à niveau disponible pour le moment.
Conseil : il est conseillé de préparer les images logicielles avant la fenêtre de maintenance planifiée. Utilisez Install pour préparer les images avant la fenêtre. Ne cochez pas la case Activate and Reboot pendant ce processus sinon, le périphérique termine la mise à niveau immédiatement après la fin de l'installation. Cela permet de réduire la fenêtre de maintenance.
Remarque : afin de garantir l'intégrité d'une image chez Cisco, les clients peuvent suivre une meilleure pratique commune pour la vérifier avec la somme de contrôle SHA fournie pour l'image. Cisco propose un fichier de hachage en masse comme outil utile pour les clients afin de vérifier à nouveau les images téléchargées à partir de la page Téléchargements de logiciels Cisco. Pour plus d'informations, consultez le site https://www.cisco.com/c/en/us/about/trust-center/downloads.html.
Matrice de recommandations de mise à niveau
Les versions logicielles du tableau ci-dessous sont recommandées en fonction du correctif du problème de certificat expiré. Les mises à niveau en dehors du cadre de ce problème doivent uniquement être effectuées avec les instructions de la documentation du produit et les notes de version de Cisco SD-WAN en fonction de la version vers laquelle vous effectuez la mise à niveau.
Remarque : Cisco vous recommande vivement de ne pas sortir de la catégorie de version actuelle afin d'atténuer l'impact sur la production en raison du problème d'expiration de la certification. Par exemple, si vous êtes actuellement sur 20.3.2, effectuez une mise à niveau vers 20.3.7.1.
La mise à niveau de vEdge 5000, vEdge Cloud et ISR 1100 n'est actuellement pas nécessaire, car ils ne sont pas affectés, par l'ID de bogue Cisco CSCwf28118.
Remarque : dans les environnements à versions mixtes, effectuez les mises à niveau logicielles conformément aux recommandations du tableau ci-dessous, en fonction de l'image actuellement exécutée par le périphérique.
Consultez la matrice de compatibilité pour identifier tout problème de compatibilité contrôleur/périphérie possible et ouvrez une demande de service TAC pour obtenir de l'aide en cas de problème.
Remarque : les clients qui utilisent des images Engineering Special (ES) et qui n'ont pas encore effectué la mise à niveau vers une image avec le correctif doivent ouvrir un rapport de service TAC pour obtenir des conseils supplémentaires.
Compatibilité vEdge-2000
La dernière catégorie d'images logicielles prise en charge pour vEdge-2000 est 20.9.x.
Compatibilité vEdge-100B, vEdge-100M, vEdge-1000
La dernière catégorie d'images logicielles prise en charge pour vEdge-100B, vEdge-100M et vEdge-1000 est 20.6.x. Utilisez la version actuelle et l'image logicielle de la afin d'identifier la version cible recommandée.
Si les serveurs vEdge-100B, vEdge-100M et vEdge-1000 se trouvent déjà sur 20.7.x et versions ultérieures, ouvrez-les à un responsable de service TAC pour obtenir des conseils.
Attention : en raison de l'impact potentiel sur la production, nous conseillons à nos clients de n'exécuter les mises à niveau que pendant une période de maintenance. Assurez et confirmez la stabilité du réseau avant toute modification supplémentaire de la production.
Contrôleur SD-WAN et matrice de compatibilité logicielle vEdge
Remarque : Cisco vous recommande vivement de ne pas sortir de la catégorie de version actuelle afin d'atténuer l'impact sur la production en raison du problème d'expiration de la certification.
Par exemple, si vous êtes actuellement sur 20.3.2, effectuez une mise à niveau vers 20.3.7.1.
Après la mise à niveau pour le correctif de certificat, si vous choisissez de passer d'une catégorie de version à une autre catégorie de version majeure, Cisco vous recommande de passer à la version préférée dans cette catégorie de version.
Par exemple, pour le correctif post-certification : si vous êtes actuellement sur la version 20.3.7.1 et que vous prévoyez de mettre à niveau vers la version 20.6, Cisco vous recommande de mettre à niveau vers la version 20.6.5.2 préférée.
Contrôleurs SD-WAN |
vEdge 100M, vEdge 100B, vEdge 1000 |
vEdge 2000 |
Commutateurs 20.3.3.21 |
Commutateurs 20.3.3.21 |
Commutateurs 20.3.3.21 |
Commutateurs 20.3.4.31 |
20.3.3.21, 20.3.4.31 |
20.3.3.21, 20.3.4.31 |
Commutateurs 20.3.5.11 |
20.3.3.21, 20.3.4.31, 20.3.5.11 |
20.3.3.21, 20.3.4.31, 20.3.5.11 |
Commutateurs 20.3.7.12 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12 |
Commutateurs 20.4.2.3 |
20.3.3.21, 20.3.7.12, 20.4.2.3 |
20.3.3.21, 20.3.7.12, 20.4.2.3 |
Commutateurs 20.6.1.2 |
Commutateurs 20.6.1.2 |
Commutateurs 20.6.1.2 |
Commutateurs 20.6.3.2 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12, 20.4.2.3, 20.6.1.2, 20.6.3.2 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12, 20.4.2.3, 20.6.1.2, 20.6.3.2 |
Commutateurs 20.6.4.1 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.4.2.3, 20.6.1.2, 20.6.3.2, 20.6.4.1 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.4.2.3, 20.6.1.2, 20.6.3.2, 20.6.4.1 |
Commutateurs 20.6.5.22 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12, 20.4.2.3, 20.6.1.2, 20.6.3.2, 20.6.4.1, 20.6.5.22 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12, 20.4.2.3, 20.6.1.2, 20.6.3.2, 20.6.4.1, 20.6.5.22 |
Commutateurs 20.9.3.12 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12, 20.4.2.3, 20.6.1.2, 20.6.3.2, 20.6.4.1, 20.6.5.22 |
20.3.3.21, 20.3.4.31, 20.3.5.11, 20.3.7.12, 20.4.2.3, 20.6.1.2, 20.6.3.2, 20.6.4.1, 20.6.5.22, 20.9.3.12 |
Commutateurs 20.10.1.1 |
20.6.1.2, 20.6.3.2, 20.6.4.1 |
20.6.1.2, 20.6.3.2, 20.6.4.1 |
Commutateurs 20.11.1.1 |
20.6.1.2, 20.6.3.2, 20.6.4.1, 20.6.5.22 |
20.6.1.2, 20.6.3.2, 20.6.4.1, 20.6.5.22, 20.9.3.12 |
1Cette image n'est plus disponible en téléchargement. Elles sont documentées pour les clients qui les ont déjà déployées.
2Indique une version préférée qui contient le correctif de certificat.
Prévérifications à effectuer avant une mise à niveau du contrôleur
Sauvegardez votre contrôleur
- Si le cloud est hébergé, vérifiez que la dernière sauvegarde est effectuée ou lancez une sauvegarde de config db comme mentionné dans l'étape suivante.
- Vous pouvez afficher les sauvegardes en cours et déclencher un snapshot à la demande à partir du portail SSP. Pour plus d'informations, cliquez ici.
- Si vous êtes sur site, effectuez une sauvegarde config-db et un snapshot de VM des contrôleurs.
vManage# request nms configuration-db backup path /home/admin/db_backup
successfully saved the database to /home/admin/db_backup.tar.gz
- Si vous êtes sur site, collectez la commande show running-config et enregistrez-la localement.
- Si vous êtes sur place, assurez-vous de connaître votre mot de passe neo4j et notez votre version actuelle exacte.
Exécuter une vérification AURA
Assurez-vous que l'envoi aux contrôleurs/l'envoi à vBond est terminé
Vérifier l'intervalle de collecte des statistiques vManage
Cisco recommande que l'intervalle de collecte de statistiques dans Administration > Settings soit défini sur le minuteur par défaut de 30 minutes.
Remarque : Cisco recommande que vos vSmarts et vBonds soient joints au modèle vManage avant une mise à niveau.
Vérification de l'espace disque sur vSmart et vBond
Utilisez la commande df -kh | grep boot de vShell pour déterminer la taille du disque.
controller:~$ df -kh | grep boot
/dev/sda1 2.5G 232M 2.3G 10% /boot
controller:~$
Si la taille est supérieure à 200 Mo, procédez à la mise à niveau des contrôleurs.
Si la taille est inférieure à 200 Mo, procédez comme suit :
1. Vérifiez que la version actuelle est la seule répertoriée sous la commande show software.
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
20.9.1 false false true user 2023-05-02T19:16:09-00:00
20.8.1 false false false user 2023-05-10T10:57:31-00:00
2. Vérifiez que la version actuelle est définie comme version par défaut sous la commande show software version.
controller# request software set-default 20.11.1
status mkdefault 20.11.1: successful
controller#
3. Si d’autres versions sont répertoriées, supprimez toutes les versions qui ne sont pas actives à l’aide de la commande request software remove <version>. Cela augmente l'espace disponible pour procéder à la mise à niveau.
controller# request software remove 20.9.1
status remove 20.9.1: successful
vedge-1# show software
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
controller#
4. Vérifiez l'espace disque afin de vous assurer qu'il est supérieur à 200 Mo. Si ce n'est pas le cas, ouvrez une demande de service TAC.
Mettre à niveau vos contrôleurs
Il s'agit d'un résumé des étapes suivantes effectuées pour chacun de ces clients.
Attention : vérifiez que toutes les vérifications préalables sont effectuées et que les sauvegardes sont effectuées comme décrit dans la section précédente.
- Téléchargez la nouvelle version du logiciel dans le référentiel de mise à niveau.
- Assurez-vous que l'image du contrôleur avec le correctif pour ce problème est sélectionnée.
- Mettez à niveau les contrôleurs avec le correctif d'image dans cette séquence.
1. vManage
2. Obligation
3. vSmart
Remarque : si vous procédez à la mise à niveau des contrôleurs par l'interface de ligne de commande, n'oubliez pas d'effectuer la commande « request software upgrade-confirm ».
Mise à niveau autonome vManage
Dans le cas de vManage autonome, les étapes suivantes doivent être suivies :
- Copier l'image dans le référentiel vManage Maintenance> Logiciel
- Mise à niveau avec vManage Maintenance>Mise à niveau logicielle
- Cliquez sur Upgrade, et attendez la fin de la mise à niveau
- Revenez à la même page, cliquez sur vManage, puis sur Activate
Remarque : la mise à niveau de vManage n'a aucun impact sur le réseau de données.
Mise à niveau du cluster vManage
Dans le cas d'une mise à niveau de cluster, les étapes mentionnées dans le guide Cisco SD-WAN Getting Started Guide - Cluster Management [Cisco SD-WAN] - Cisco guide doivent être suivies.
Remarque : la mise à niveau du cluster vManage n'a aucun impact sur le réseau de données.
Attention : si vous avez des questions ou des problèmes lors de la mise à niveau de votre cluster, contactez le TAC avant de continuer.
Mise à niveau vBond
Une mise à niveau vBond utilise le même processus qu'une mise à niveau vManage.
Avertissement : les vBonds doivent être mis à niveau de manière séquentielle. Vérifiez que la mise à niveau a été effectuée sur chaque vBond avant de passer au suivant.
- Copier l'image dans vManage Maintenance > Référentiel logiciel
- Mise à niveau avec vManage Maintenance > Mise à niveau logicielle
- Cliquez sur Upgrade, et attendez la fin de la mise à niveau
- Revenez à la même page, cliquez sur vManage, puis sur Activate
- Vérifiez avec la commande show orchestrator connections sur le vBond
- Vérifiez à l'aide de la commande show control connections sur le vManage
Mise à niveau vSmart
Une mise à niveau vSmart utilise le même processus qu'une mise à niveau vManage.
Avertissement : vSmarts doit être mis à niveau de manière séquentielle. Vérifiez que la mise à niveau a été effectuée sur chaque vSmart avant de passer au suivant.
- Copier l'image dans vManage Maintenance > Référentiel logiciel
- Mettez à niveau le vSmart à partir de vManage UI Maintenance > Software upgrade
- Cliquez sur Upgrade et attendez la fin de la mise à niveau
- Revenez à la même page. Choisissez la vSmart, puis cliquez sur Activate
- Vérifiez que les sessions ont été restaurées après la mise à niveau avec la commande show control connections sur le vSmart
Remarque : lorsque la vSmart redémarre pendant une mise à niveau logicielle, les périphériques redémarrent en douceur sans impact sur le réseau.
Vérifier que les connexions de contrôle sont établies après toutes les mises à niveau du contrôleur
Pour tous les vEdge dans le scénario 1 et le scénario 2 après que le ou les contrôleurs ont été mis à niveau, les connexions de contrôle et BFD doivent être restaurées.
Mettre à niveau vEdge
Remarque : la mise à niveau vEdge est la dernière étape de la procédure de protection complète contre le cycle d'alimentation des routeurs vEdge, décrite dans le scénario 3.
Remarque : il est conseillé de préparer les images logicielles vEdge avant la fenêtre de maintenance planifiée. Utilisez Install pour préparer les images avant la fenêtre. Ne cochez pas la case Activate and Reboot pendant ce processus sinon, le périphérique termine la mise à niveau immédiatement après la fin de l'installation. Cela permet de réduire la fenêtre de maintenance.
Vous pouvez charger les images sur plusieurs vEdge en une seule fois à partir de vManage via :
1. Accédez à l'interface utilisateur vManage. Accédez à Maintenance > Référentiel de logiciels. Charger l'image vEdge. Vous pouvez ensuite naviguer vers Maintenance > Software Upgrade et cliquer sur Upgrade après avoir choisi les périphériques qui ont besoin de la mise à niveau.
2. Accédez à l'interface utilisateur vManage. Accédez à Maintenance > Référentiel de logiciels. Cliquez sur Add new software. Cliquez sur Remote server. Entrez la version du contrôleur, la version vEdge et le chemin complet vers l'URL FTP/HTTP où l'image est stockée. Par exemple, ftp://<nom d'utilisateur>:<mot de passe>@<serveur FTP>/<chemin>/<nom de l'image>. Vous pouvez ensuite naviguer vers Maintenance > Software Upgrade et cliquer sur Upgrade après avoir choisi les périphériques qui ont besoin de la mise à niveau avec l'utilisation de l'option Remote server.
Remarque : choisissez les arêtes par lots en fonction de la bande passante afin de pousser l'image.
Prévérifications avant la mise à niveau vEdge
Attention : si ces vérifications préalables sont ignorées, la mise à niveau vEdge peut échouer en raison d'un espace disque insuffisant.
1. Vérifiez que la version actuelle est la seule répertoriée sous la commande show software.
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
20.9.1 false false true user 2023-05-02T19:16:09-00:00
20.8.1 false false false user 2023-05-10T10:57:31-00:00
2. Vérifiez que la version actuelle est définie comme version par défaut sous la commande show software version.
vedge-1# request software set-default 20.11.1
status mkdefault 20.11.1: successful
vedge-1#
3. Si d’autres versions sont répertoriées, supprimez toutes les versions qui ne sont pas actives à l’aide de la commande request software remove <version>. Cela augmente l'espace disponible pour procéder à la mise à niveau.
vedge-1# request software remove 20.9.1
status remove 20.9.1: successful
vedge-1# show software
VERSION ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
------------------------------------------------------------------------------
20.11.1 true true false auto 2023-05-02T16:48:45-00:00
vedge-1#
4. Utilisez vShell et la commande df -h afin de confirmer qu'il y a suffisamment d'espace disque libre pour effectuer la mise à niveau.
VEDGE-1000-AC-K9# vshel
VEDGE-1000-AC-K9:~$ df -h
Filesystem Size Used Avail Use% Mounted on
none 1.4G 8.0K 1.4G 1% /dev
/dev/sda1 1013M 518M 445M 54% /boot
/dev/loop0 78M 78M 0 100% /rootfs.ro
/dev/sda2 6.0G 178M 5.5G 4% /rootfs.rw
aufs 6.0G 178M 5.5G 4% /
tmpfs 1.4G 300K 1.4G 1% /run
shm 1.4G 48K 1.4G 1% /dev/shm
tmp 600M 84K 600M 1% /tmp
tmplog 120M 37M 84M 31% /var/volatile/log/tmplog
svtmp 1.0M 312K 712K 31% /etc/sv
5. Si /tmp est plein, ouvrez une demande de service TAC pour obtenir de l'aide afin de libérer de l'espace dans le répertoire /tmp/tmp avant la mise à niveau.
Scénario 1 de mise à niveau de vEdge : la connexion de contrôle est active et vEdge N'A PAS été redémarré
Une fois les contrôleurs mis à niveau vers une version comportant le correctif, les périphériques vEdge qui n'ont pas été redémarrés rétablissent automatiquement la connectivité.
Important : une mise à niveau est requise sur les périphériques vEdge dans cet état. Il DOIT être hiérarchisé et planifié dès que possible. Si nécessaire, effectuez vos tâches en dehors des heures de bureau aussi rapidement que possible. Planifiez une mise à niveau du périphérique afin d'éviter tout impact sur le plan de contrôle et de données dû à un redémarrage ou un cycle d'alimentation du périphérique. Le périphérique ne doit pas être redémarré avant la mise à niveau.
Afin de mettre à niveau le vEdge, suivez les étapes indiquées :
- Copiez le nouveau logiciel vEdge dans le référentiel vManage via Maintenance > Software
- Mettre à niveau le serveur vEdge à partir de vManage Maintenance > Mise à niveau logicielle
- Cliquez sur Mise à niveau et attendez la fin de la mise à niveau
- Revenez à la même page. Sélectionnez le serveur vEdge, puis cliquez sur Activer
Validation post-mise à niveau
- Vérifier les connexions de contrôle et les sessions BFD
- Vérification des routes OMP et des routes VPN de service : test de la requête ping de bout en bout sur chaque segment VPN de service entre vEdge et concentrateur/autres noeuds
- Consultez les considérations post-mise à niveau
Mise à niveau vEdge Scénario 2 : la connexion de contrôle est désactivée et vEdge N'A PAS redémarré
Une fois les contrôleurs mis à niveau vers une version comportant le correctif, les périphériques vEdge qui n'ont pas été redémarrés rétablissent automatiquement la connectivité.
Important : une mise à niveau est requise sur les périphériques vEdge dans cet état. Il DOIT être hiérarchisé et planifié dès que possible. Si nécessaire, effectuez vos tâches en dehors des heures de bureau aussi rapidement que possible. Planifiez une mise à niveau du périphérique afin d'éviter tout impact sur le plan de contrôle et de données en raison d'un redémarrage ou d'un cycle d'alimentation du périphérique. Le périphérique ne doit pas être redémarré avant la mise à niveau.
Afin de mettre à niveau le vEdge, suivez les étapes indiquées :
- Copiez le nouveau logiciel vEdge dans le référentiel vManage via Maintenance > Software
- Mettre à niveau le serveur vEdge à partir de vManage Maintenance > Mise à niveau logicielle
- Cliquez sur Mise à niveau et attendez la fin de la mise à niveau
- Revenez à la même page. Sélectionnez le serveur vEdge, puis cliquez sur Activer
Validation post-mise à niveau
- Vérifier les connexions de contrôle et les sessions BFD
- Vérification des routes OMP et des routes VPN de service : test de la requête ping de bout en bout sur chaque segment VPN de service entre vEdge et concentrateur/autres noeuds
- Consultez les considérations post-mise à niveau
Scénario 3 : vEdge, la connexion de contrôle est désactivée, le périphérique redémarré/mis hors tension puis hors tension
Attention : pour récupérer ces périphériques, un accès hors bande est requis.
Ce résultat montre un périphérique vEdge qui a été redémarré après l'expiration du certificat. Utilisez la commande show control local-properties | inc serial et confirmez que le résultat affiche BOARD-ID-NOT-INITIALIZED.
vedge# show control local-properties | inc serial
serial-num BOARD-ID-NOT-INITIALISED
subject-serial-num N/A
enterprise-serial-num No certificate installed
vedge#
Modifier la date/l'heure sur vEdge pour restaurer les connexions de contrôle
Ces étapes nécessitent un accès hors bande au périphérique vEdge, tel que la console ou SSH direct.
Retournez l'horloge au 5 mai 2023 (par exemple la date de #clock set 2023-05-05 time 15:49:00.000) sur vEdge qui dispose d'une connexion de contrôle DOWN.
vedge# clock set date 2023-05-05 time 10:23:00
vedge# show clock
Mon May 5 10:23:37 UTC 2023
vedge#
Attendez 2 à 3 minutes que l'ID de carte s'initialise. Cochez show control local-properties afin de vous assurer que le périphérique a maintenant un numéro affiché dans le résultat.
vedge# show control local-properties | inc serial
serial-num 10024640
subject-serial-num N/A
enterprise-serial-num No certificate installed
vedge#
(Facultatif) Si l'initialisation de l'ID de carte ne se produit pas dans les 2 à 3 minutes, rechargez vEdge et vérifiez la sortie show control local-properties afin de vous assurer que le périphérique a maintenant son numéro de série répertorié dans la sortie
Une fois que l'ID de carte a initialisé, validez le certificat avec la commande show certificate valid
vedge# show certificate validity
The certificate issued by c33d2cf4-e586-4df4-ac72-298422644ba3 is valid from Sep 7 02:50:16 2021 GMT (Current date is Mon May 1 10:25:03 GMT 2023) & valid until Sep 5 02:50:16 2031 GMT
vedge#
Une fois que les connexions de contrôle ont été correctement restaurées, corrigez l'horloge à l'heure actuelle avec le format AAAA-MM-JJ et HH:MM::SS pour la date et l'heure.
Cet exemple est fourni à titre d'illustration uniquement. Réglez toujours la date et l'heure sur l'heure actuelle.
vedge# clock set date YYYY-MM-DD time HH:MM::SS
vedge# show clock
Wed May 10 10:23:37 UTC 2023
vedge#
Vérifiez que les connexions de contrôle sont actives à l'aide de la commande show control connections.
vedge# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR PROXY STATE UPTIME ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 10.3.3.1 10 1 192.168.24.112 12346 192.168.24.112 12346 private1 No up 0:14:33:46 0
vsmart dtls 10.3.3.1 10 1 192.168.24.112 12346 192.168.24.112 12346 private2 No up 0:14:33:46 0
vbond dtls 0.0.0.0 0 0 192.168.28.122 12346 192.168.28.122 12346 private1 - up 0:14:33:47 0
vbond dtls 0.0.0.0 0 0 192.168.28.122 12346 192.168.28.122 12346 private2 - up 0:14:33:47 0
vmanage dtls 10.1.1.1 10 0 192.168.25.209 12346 192.168.25.209 12346 private1 No up 0:14:33:46 0
Remarque : une mise à niveau est requise sur les périphériques vEdge dans cet état. Il DOIT être hiérarchisé et planifié dès que possible. Si nécessaire, effectuez les tâches pendant une fenêtre de maintenance en dehors des heures de bureau. Planifiez une mise à niveau du périphérique pour éviter tout impact dû à un redémarrage ou à un cycle d'alimentation du périphérique. Le périphérique ne doit pas être redémarré avant la mise à niveau.
Pour mettre à niveau le serveur vEdge, procédez comme suit :
- Copiez le correctif de l'image vEdge dans le référentiel vManage via Maintenance > Logiciel
- Mettre à niveau le serveur vEdge à partir de vManage UI Maintenance > Mise à niveau logicielle
- Cliquez sur Upgrade et attendez la fin de la mise à niveau
- Revenez à la même page. Choisissez le serveur vEdge, puis cliquez sur Activer
· Vérifiez que les connexions de contrôle et les sessions BFD sont actives
· Vérifier les routes OMP et les routes VPN de service - Tester la requête ping de bout en bout sur chaque segment VPN de service entre vEdge et Hub/autres noeuds
- Consultez les considérations post-mise à niveau
Procédure de mise à niveau à partir des versions 18.4, 19.x et 20.1 (révisée le 13 mai 2000 UTC)
Toutes les mises à niveau des versions 18.4, 19.x et 20.1.x doivent être mises à niveau vers la version 20.3.7.1.
Cette section a été révisée avec des instructions pour mettre à niveau vManage avec des disques de démarrage inférieurs à 2.5G vers 20.1.3.1 au lieu de 20.1.3.
Le nouveau logiciel 20.1.3.1 vManage inclut les certificats mis à jour et permet aux périphériques de se connecter pendant la deuxième mise à niveau vers 20.3.7.1.
Attention : lisez attentivement cette section avant de continuer. Plusieurs mises à niveau peuvent être nécessaires.
Contrôles avant mise à niveau
Avant de procéder à une mise à niveau, vous devez effectuer toutes les vérifications préalables pour vous assurer que la mise à niveau est réussie.
Ces vérifications préalables à la mise à niveau valident la taille de la base de données, les ressources de calcul et la taille du disque de démarrage.
Vérifier la taille de la base de données via la CLI
Utilisez la commande request nms configuration-db diagnostic | i TotalStoreSize pour obtenir la taille de la base de données en octets.
À partir de vshell, exécutez la commande expr <nombre d'octets> / 1024 / 1024 / 1024 pour convertir cette sortie en une valeur entière en Go.
vmanage# request nms configuration-db diagnostics | i TotalStoreSize
| "StoreSizes" | "TotalStoreSize" | 3488298345 |
vmanage1# vshell
vmanage1:~$ expr 348829834 / 1024 / 1024 / 1024
3
Cet exemple montre que la taille de la base de données est de 3 Go.
STOP : si la taille de votre base de données est supérieure ou égale à 5 Go Ouvrez un TAC SR pour obtenir de l'aide sur cette mise à niveau.
Si la taille de la base de données est inférieure à 5 Go, poursuivez la mise à niveau.
Vérification des ressources de calcul
Assurez-vous que les ressources de calcul sont conformes au guide 20.3 Compute Resources Guide.
- Vérifiez vCPU avec la commande lscpu | CPU grep\ MHz
vmanage1:~$ lscpu | grep CPU\ MHz
CPU MHz: 2999.658
vmanage1:~$
- Vérifiez la mémoire avec les commandes free -g | grep Mem et free —giga | Mém. grep
vmanage1:~$ free -g | grep Mem
Mem: 31 21 7 0 2 9
vmanage1:~$ free --giga | grep Mem
Mem: 33 23 7 0 2 9
vmanage1:~$
- Vérifiez la taille de la troisième partition (/opt/data) avec la commande df -kh
vmanage1:~$ df -kh | grep "/opt/data"
/dev/sdb 108G 24G 79G 23% /opt/data
vmanage1:~$
Si les ressources de calcul ne sont pas conformes à la version 20.3, augmentez-les avant la mise à niveau.
Vérification de l'espace disque de démarrage avec CLI
Utilisez la commande df -kh | grep boot de vShell afin de déterminer la taille du disque.
vmanage# vshell
vmanage:~$ df -kh | grep boot
/dev/sda1 5.0G 4.7G 343M 94% /boot
vmanage:~$
Cet exemple montre que le disque /boot est 5.0G.
Avertissement : si le disque de démarrage vManage est inférieur à 2.5G, vous devez effectuer une mise à niveau progressive via la version 20.1
Mettre à niveau vManage sur les versions 18.4 et 19.x
Effectuer la mise à niveau - vManage Autonome
Si la taille du disque de démarrage est inférieure à 2,5 G, vous devez mettre à niveau vManage vers la version 20.1 avant de continuer.
Si la taille du disque est 2.5G ou plus, vous pouvez mettre à niveau directement vers 20.3.7.1.
Effectuer la mise à niveau - Cluster vManage
Si la taille du disque est inférieure à 2.5G, vous devez mettre à niveau vManage vers la version 20.1.3.1 avant de continuer.
Si la taille du disque est 2.5G ou plus, vous pouvez mettre à niveau directement vers 20.3.7.1.
Mise à niveau vManage 20.1.x
Effectuer la mise à niveau - vManage Autonome ou Cluster
Mettre à niveau vSmart et vBond de 18.4, 19.x ou 20.1 vers 20.3.7.1
vSmarts et vBonds peuvent être mis à niveau directement de toutes les versions vers 20.3.7.1.
Mise à niveau de vEdge de 18.4, 19.x ou 20.1 à 20.3.7.1
Les périphériques vSmarts, vBonds et vEdge peuvent être mis à niveau directement de toutes les versions vers 20.3.7.1.
Considérations post-mise à niveau
Si des modifications ont été apportées à la configuration pour augmenter les minuteurs de redémarrage en douceur et les minuteurs de renouvellement de clé IPSec avant la mise à niveau, il est recommandé de rétablir les paramètres qui étaient en place avant la mise à niveau afin d'éviter tout impact inutile potentiel.
avis spécial
Les clients qui ont mis à niveau leurs contrôleurs vers des versions antérieures à 20.3.7.1 et qui sont en train de mettre à niveau leurs vEdge peuvent contacter le TAC pour accéder aux images vEdge respectives.
Avis concernant le bogue Cisco ID CSCwd46600
Les versions précédentes de ce document recommandaient aux clients de mettre à niveau vers plusieurs versions de 20.3.x (20.3.3.2, 20.3.5.1, 20.3.4.3, 20.3.7.1).
Cisco recommande aux clients qui exécutent l'image 20.3.x de mettre à niveau leurs contrôleurs et leurs vEdge vers l'image 20.3.7.1.
Les périphériques qui exécutent les versions 19.x et 20.3.x antérieures à 20.3.7.1, 20.4 et 20.6x antérieures à 20.6.5.1 peuvent rencontrer l'ID de bogue Cisco CSCwd4600 après la mise à niveau. Afin de résoudre temporairement ce problème, exécutez l'une de ces commandes :
request security ipsec-rekey
ou
request port-hop color
Cependant, il est fortement recommandé aux clients de mettre à niveau leurs contrôleurs et leurs périphériques vEdge vers 20.3.7.1 ou 20.6.5.1.
Les clients qui ont complètement mis à niveau tous les périphériques vEdge vers une version 20.3.x antérieure à 20.3.7.1, 20.3.4.3 ou une version 20.6.x antérieure à 20.6.5.1 en se basant sur les instructions précédentes peuvent choisir de rester sur cette version s'ils n'ont pas été affectés par le bogue. Il est recommandé d'effectuer la mise à niveau vers 20.3.7.1 ou 20.6.5.1 au cours d'une fenêtre de maintenance planifiée à une date ultérieure.
Avis pour la version 20.6.x (révisé le 15 mai 2000 UTC)
Les versions précédentes de ce document recommandaient aux clients d'effectuer une mise à niveau vers plusieurs versions de 20.6.x (20.6.3.2, 20.6.4.1, 20.6.5.2).
Cisco recommande aux clients qui exécutent l'image 20.6.x et dont les trackers sont configurés sur une interface de mettre à niveau leurs contrôleurs et leurs vEdge vers l'image 20.6.5.2.
Les périphériques avec un tracker configuré peuvent rencontrer le bogue Cisco ID CSCvz44093 pendant la mise à niveau. Afin d'éviter l'impact de ce bogue, vous pouvez supprimer la configuration du tracker avant la mise à niveau.
Il est fortement recommandé aux clients de mettre à niveau leurs contrôleurs et leurs périphériques vEdge vers la version 20.6.5.2.
Les clients qui ont complètement mis à niveau tous les périphériques vEdge vers les versions 20.6.3.2 et 20.6.4.1 en se basant sur les recommandations précédentes peuvent choisir de rester sur cette version s'ils n'ont pas été affectés par le bogue.