J'ai testé pour vous: l'ISSU sur catalyst 6500 sup2T (ou comment upgrader son coeur de réseau sans impact pour les usagers)
4 min read
Objectif du test
J’avais décrit dans un précédent post la possibilité d’upgrader l’accès du réseau avec un minimum d’impact grâce à l’ISSU disponible sur le catalyst 4500. L’objectif ici est de montrer comment on va pouvoir également upgrader le coeur VSS avec un minimum d’impact. On va upgrader le VSS avec l’IOS 15.0(1)SY1 en utilisant le processus ISSU. Le processus est similaire à celui rencontré sur le Catalyst 4500 mis à part que les sup sont maintenant dans 2 châssis différents. On va là aussi passer par les états décrits dans le schéma suivant.
Travail préalable
Il est important de suivre la procédure décrite dans le guide de configuration !!!
Tout d’abord il faut vérifier que les images sont compatibles pour un upgrade en ISSU. Il suffit de regarder une matrice accessible depuis les release notes.
VSS-2T#copy bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin slavebootdisk: Destination filename [s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin]? Copy in progress...CCCCCCCCC... [snip] 91068320 bytes copied in 111.732 secs (815060 bytes/sec)
Upgrade
LoadVersion
Tout d’abord on regarde l’état détaillé pour l’ISSU (ou EFSU – Enhanced fast Software Upgrade) avant le début des opérations. On voit bien que l’on est en 15.0(1)SY sur les 2 cartes sup.
VSS-2T#sh issu state detail
Slot = 1/5
RP State = Active
ISSU State = Init
Boot Variable = N/A
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Variable Store = PrstVbl
Slot = 2/1
RP State = Standby
ISSU State = Init
Boot Variable = N/A
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Ensuite on indique que l’on va entamer l’ISSU et on va spécifier la nouvelle image que l’on veut installer sur les 2 supervisors. On précise a chaque fois la sup2T concernée puis sur quel disque récupérer l’image à chaque fois. Attention car pour chaque supervisor il faut spécifier un emplacement du fichier qui est également sur la supervisor en question. Ca donne ça:
VSS-2T#$issu loadversion 1/5 bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin 2/1 slavebootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin *Apr 18 14:26:57.112: %RF-SW1-5-RF_RELOAD: Peer reload. Reason: ISSU Loadversion *Apr 18 14:26:57.116: %SYS-SW2_STBY-5-RELOAD: Reload requested - From Active Switch. reload peer unit %issu loadversion executed successfully, Standby is being reloaded [snip]
A l’issue de la commande, la carte de standby reload et charge le nouvel IOS:
VSS-2T#sh issu state detail
Slot = 1/5
RP State = Active
ISSU State = Load Version
Boot Variable = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin,12
Operating Mode = sso
Primary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Secondary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Variable Store = PrstVbl
Slot = 2/1
RP State = Standby
ISSU State = Load Version
Boot Variable = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin,12;bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin,12
Operating Mode = sso
Primary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Secondary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
La prochaine étape est de basculer sur la RP standby et donc sur le nouvel IOS en déclanchant le switchover.
RunVersion
La commande “issu runversion” va reloader la carte active pour permettre un switchover vers la carte standby qui tourne le nouvel IOS. Notons qu’à cette étape la carte va redémarrer toujours avec l’ancien IOS pour permettre un rollback simple. Ce n’est que lors de la dernière étape que l’on charge le nouvel IOS sur la carte de standby.
VSS-2T#issu runversion This command will reload the Active unit. Proceed ? [confirm] %issu runversion initiated successfully *Apr 18 14:36:53.340: %RF-SW1-5-RF_RELOAD: Self reload. Reason: Admin ISSU runversion CLI [snip]
Notez qu’à ce moment j’ai du bouger mon cable console sur la nouvelle Sup, d’où l’intérêt de peut-être faire l’opération via connexion ssh. Maintenant le switch est upgradé:
VSS-2T#sh issu state detail
Slot = 2/1
RP State = Active
ISSU State = Run Version
Boot Variable = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin,12;bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin,12
Operating Mode = sso
Primary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Secondary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Variable Store = PrstVbl
Slot = 1/5
RP State = Standby
ISSU State = Run Version
Boot Variable = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin,12
Operating Mode = sso
Primary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Secondary Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin
VSS-2T#sh version
Cisco IOS Software, s2t54 Software (s2t54-ADVENTERPRISEK9-M), Version 15.0(1)SY1, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Thu 16-Feb-12 21:36 by prod_rel_team
AcceptVersion
C’est l’étape la plus simple, on va juste signaler au switch que l’on accepte la nouvelle version. Pour éviter une situation de bloquage, il est possible de configurer un timer pour faire un rollback (abortversion) automatique si cette commande n’est pas tapée à temps.
VSS-2T#issu acceptversion % Rollback timer stopped. Please issue the commitversion command.
CommitVersion
Maintenant que l’on a validé que l’image était bien chargée sur notre sup et qu’il n’y avait pas eu de désastre, la dernière étape consiste à charger la bonne image sur la RP de standby pour terminer le process de mise à jour. Cela se fait via la commande “issu commitversion”. Suite à cette commande la sup de standby va simplement rebooter et charger le nouvel IOS.
VSS-2T#issu commitversion Building configuration... [OK] *Apr 18 15:02:08.352: %RF-5-RF_RELOAD: Peer reload. Reason: ISSU Commitversion *Apr 18 15:02:08.348: %SYS-SW1_STBY-5-RELOAD: Reload requested - From Active Switch. reload peer unit [snip]
Une fois le reload terminé, on regarde à nouveau l’état de notre ISSU et on voit que le nouvel IOS est chargé sur les 2 cartes.
VSS-2T#sh issu state detail
Slot = 2/1
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin,12;bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin,1;
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Variable Store = PrstVbl
Slot = 1/5
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin,12;bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY.bin,1;
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin
Résultats
La procédure a fonctionné sans problèmes. Il convient de bien respecter la procédure et bien vérifier à chaque étape que l’on est dans l’état escompté. Pour le temps de convergence j’ai préféré ne pas donner de chiffres dans la mesure où mon lab un peu simpliste ne pouvait pas reproduire toute la complexité d’un coeur de réseau, avec l’ensemble des protocoles de routage, NSF… N’hésitez pas à communiquer les mesures que vous observez pour vos designs!
Authors
4 commentaires
A quel moment faut-il resetter les cartes d’interfaces (comme lors d’un Full image EFSU upgrade)?
Il n’y a pas besoin de les resetter manuellement. Avec le process ISSU (ou plutot EFSU – Enhanced Fast Software Upgrade pour etre plus exact) on va upgrader les 2 châssis l’un après l’autre et utiliser le VSS et les Multi-Chassis Etherchannel pour éviter les impacts. Donc à chaque fois que l’on va utiliser les commandes loadversion / runversion et commitversion on va redémarrer à chaque fois la sup et les modules d’un châssis, et basculer sur le châssis restant à la vitesse d’une convergence Etherchannel (cad quelques dizaines de millisecondes).
Petite erreur de typo au tout début : “disponible sur le catalyst 4500” 6500 plutôt non (surtout avec une SUP-2T)
En fait non 🙂
J’avais testé il y a peu l’ISSU sur le 4500 dans un scénario à l’accès et je m’attaquais maintenant à un coeur en 6500 VSS. Comme ce n’était pas très clair j’ai tout de même tenté de remettre un peu d’ordre dans l’article. Merci!