J’ai testé pour vous: l’ISSU sur Catalyst 4500 (ou comment upgrader son switch d’accès sans impact pour les usagers)
5 min read
Comme je l’annonçais dernièrement, on a maintenant un nouvel IOS sur Catalyst 4500 qui apporte pas mal de fonctionnalités. Je n’ai pas pu résister à l’envie d’upgrader mon lab… voilà comment faire l’opération sans tout casser grâce à ISSU (In-Service Software Upgrade)
Description du LAB
Le lab est simple: je connecte simplement mon 4500E à mon catalyst 6500 (VSS sup2T) via 2 uplinks 10GE situés sur les 2 cartes de supervision du cat4k (pas besoin d’une autre carte avec des interfaces 10GE puisque les ports de la carte de supervision standby sont fonctionnels). Je créé mon MCEC en mode LACP (en passive sur le 4500 et en active sur le 6500).
Un petit schéma pour tout comprendre:
Matériels et logiciels utilisés
Catalyst 4507R+E avec 2 supervisor 6L-E
Upgrade de l’IOS 15.0(2)SG (Enterprise Services) à l’IOS 15.1(1)SG (Enterprise Services)
ISSU
Pré-requis
Suivre le mode opératoire à la lettre! Notamment il faut que les 2 versions soient dans le même feature set pour pouvoir faire de l’ISSU. On va suivre 4 étapes successives (loadversion, runversion, acceptversion, commitversion). Voici petit schéma pour se repérer dans la lecture de l’article:
Vérifiez bien que vous êtes en redundancy mode SSO (Stateful Switch Over)! Sinon ça va être compliqué de faire de l’ISSU…
4507-1#sh module | b Red Mod Redundancy role Operating mode Redundancy status ----+-------------------+-------------------+------------------- 3 Standby Supervisor SSO Active 4 Active Supervisor SSO Standby hot
On peut regarder l’état ISSU avant le démarrage de l’opération:
4507-1#sh issu state Slot = 3 RP State = Active ISSU State = Init Boot Variable = bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,1; Slot = 4 RP State = Standby ISSU State = Init Boot Variable = bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,1;
Télécharger les IOS sur les flashs des sup
Je vous épargne cette étape, on copie le nouvel IOS sur les 2 sup (dans notre disque bootflash: et slavebootflash:) Il est indispensable d’avoir l’IOS sur chacune des sup car ces dernières ne vont pouvoir charger que l’IOS qui est sur le système de fichier local.
Loadversion
Commençons par charger le nouvel IOS sur la sup standby. La commande suivante spécifie globalement les nouveaux IOS à utiliser durant tout le processus ISSU.
4507-1#issu loadversion 3 bootflash:cat4500e-entservicesk9-mz.151-1.SG.bin 4 slavebootflash:cat4500e-entservicesk9-mz.151-1.SG.bin
On peut voir dans les logs que la sup standby redémarre et charge la nouvelle image:
000039: *May 24 12:45:11: %RF-5-RF_RELOAD: Peer reload. Reason: ISSU Loadversion 000040: *May 24 12:45:25: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost 000041: *May 24 12:45:25: %C4K_REDUNDANCY-3-SIMPLEX_MODE: The peer Supervisor has been lost 000042: *May 24 12:48:25: %C4K_REDUNDANCY-6-DUPLEX_MODE: The peer Supervisor has been detected 000043: *May 24 12:48:43: %C4K_IOSMODPORTMAN-6-MODULEONLINE: Module 4 (WS-X45-SUP6L-E S/N: JAE13177T0S Hw: 1.0) is online 000044: *May 24 12:48:43: %C4K_REDUNDANCY-6-MODE: ACTIVE supervisor initializing for sso mode 000045: *May 24 12:48:44: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been established 000046: *May 24 12:49:07: %C4K_REDUNDANCY-5-CONFIGSYNC: The config-reg has been successfully synchronized to the standby supervisor 000047: *May 24 12:49:07: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized to the standby supervisor 000048: *May 24 12:49:07: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor 000049: *May 24 12:49:08: %C4K_REDUNDANCY-5-CONFIGSYNC_RATELIMIT: The vlan database has been successfully synchronized to the standby supervisor 000050: *May 24 12:49:30: %ISSU_PROCESS-7-DEBUG: Peer state is [ STANDBY HOT ]; Please issue the runversion command 000051: *May 24 12:49:30: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded 000052: *May 24 12:49:30: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
Nouvel état ISSU après la fin du loadversion:
4507-1#sh issu state Slot = 3 RP State = Active ISSU State = Load Version Boot Variable = bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,12 Slot = 4 RP State = Standby ISSU State = Load Version Boot Variable = bootflash:cat4500e-entservicesk9-mz.151-1.SG.bin,12;bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,12
J’avais lancé quelques pings avant de taper la commande issu loadversion, pas de paquets perdus. J’en déduis que le trafic de mon ping n’utilisait pas l’uplink 10GE de la carte sup de backup:
mon-ordi$ sudo ping -i 0.01 192.168.168.1 [snip] 39745 packets transmitted, 39745 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.305/2.832/344.467/19.725 ms
RunVersion
Le chargement s’étant bien passé on va déclencher un switchover pour basculer sur la carte qui a chargé le nouvel IOS. Pour cela on reload la carte active avec la commande issu runversion.
4507-1#issu runversion
Comme tout à l’heure j’ai lancé des pings espacés de 10 ms pendant cette opération.
mon-ordi$ sudo ping -i 0.01 192.168.168.1 [snip] 9287 packets transmitted, 9286 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.316/2.840/343.194/19.213 ms
1 seul paquet perdu!!! Coupure inférieure donc à 20 ms.
La carte finit de reloader:
000021: *May 24 12:56:34: %C4K_REDUNDANCY-6-DUPLEX_MODE: The peer Supervisor has been detected 000022: *May 24 12:56:43: %C4K_IOSMODPORTMAN-6-MODULEONLINE: Module 3 (WS-X45-SUP6L-E S/N: JAE13177SSC Hw: 1.0) is online 000023: *May 24 12:56:43: %C4K_REDUNDANCY-6-MODE: ACTIVE supervisor initializing for sso mode 000024: *May 24 12:56:43: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been established [snip] 000033: *May 24 12:57:31: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded 000034: *May 24 12:57:31: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
On peut encore vérifier l’état de l’ISSU: on constate ci-dessous que l’on a bien basculé sur la sup qui a le nouvel IOS.
4507-1#sh issu state Slot = 4 RP State = Active ISSU State = Run Version Boot Variable = bootflash:cat4500e-entservicesk9-mz.151-1.SG.bin,12;bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,12 Slot = 3 RP State = Standby ISSU State = Run Version Boot Variable = bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,12
AcceptVersion
Si tout fonctionne bien, il faut accepter la nouvelle version avant un certain timer configurable (sinon tout explose!)
4507-1#issu acceptversion % Rollback timer stopped. Please issue the commitversion command.
Bien évidemment, pas de pertes de paquets à ce moment là, je donne l’information pour les quelques sceptiques qui seraient arrivés jusque là.
mon-ordi$ sudo ping -i 0.01 192.168.168.1 [snip] 24576 packets transmitted, 24576 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.319/3.189/342.439/22.047 ms
CommitVersion
Dernière opération, il faut maintenant charger le nouvel IOS sur la carte standby (qui était active avant l’ISSU). Pour cela on utilise la commande issu commitversion.
4507-1#issu commitversion Building configuration... Compressed configuration from 9806 bytes to 3763 bytes[OK] 000036: *May 24 13:04:12: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor 000037: *May 24 13:04:12: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized to the standby supervisor %issu commitversion executed successfully 000038: *May 24 13:04:13: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor 000039: *May 24 13:04:14: %RF-5-RF_RELOAD: Peer reload. Reason: ISSU Commitversion 000040: *May 24 13:04:28: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost 000041: *May 24 13:04:28: %C4K_REDUNDANCY-3-SIMPLEX_MODE: The peer Supervisor has been lost [snip] 000050: *May 24 13:08:04: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded 000051: *May 24 13:08:04: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)
On vérifie l’état de l’ISSU et on constate que l’opération est terminée.
4507-1#sh issu state Slot = 4 RP State = Active ISSU State = Init Boot Variable = bootflash:cat4500e-entservicesk9-mz.151-1.SG.bin,12;bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,1; Slot = 3 RP State = Standby ISSU State = Init Boot Variable = bootflash:cat4500e-entservicesk9-mz.151-1.SG.bin,12;bootflash:cat4500e-entservicesk9-mz.150-2.SG4.bin,1;
Pour les sceptiques:
4507-1#sh ver [snip] System image file is "bootflash:cat4500e-entservicesk9-mz.151-1.SG.bin"
Et on regarde une nouvelle fois les pertes de paquets lors de cette dernière opération
mon-ordi$ sudo ping -i 0.01 192.168.168.1 [snip] 53120 packets transmitted, 53120 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.324/3.042/341.921/21.196 ms
Bref, pas de pertes de paquets. Attention, ne pas être en mode etherchannel “On”. Dans ce cas de figure on peut avoir des grosses surprises car il n’y a pas de synchronisation entre les équipements. Cela peut engendrer des pertes de paquets au redémarrage (un équipement commence à utiliser l’etherchannel alors que l’autre n’a pas fini de le monter.
Intéressés ?
Dans un design similaire, 20ms (et je suis large) de coupure lors d’un upgrade vous intéresse? Vous savez donc quelle plateforme adopter… Et jetez un coup d’oeil à nos bundles sur le 4500E vous serez agréablement surpris 😉
Références
Authors
2 commentaires