Cisco France Blog
Partager

J’ai testé pour vous: l’ISSU sur Catalyst 4500 (ou comment upgrader son switch d’accès sans impact pour les usagers)


29 May 2012


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

Configuration guide ISSU

Tags:
Laisser un commentaire

0 commentaires