Méthode pour effectuer le reboot d’un VSS Cisco 4500X en toute sécurité.

Guillaume 3 mars 2016 Réseau Laisser un potin

Suite à un bug du protocole Netflow sur des Cisco 4500X en VSS, j’ai dû procéder à un reboot du VSS Cisco, c’est-à-dire des deux switchs. L’occasion de mettre en forme une procédure pour minimiser le temps de coupure de mes switchs d’étages.

Je vous remets une petite explication concernant le système de VSS de Cisco.

Le Virtual Switching System (VSS) est une fonctionnalité Cisco disponible sur les Catalyst 6500 et sur les 4500X entre autre. Il permet de créer un commutateur logique à partir de 2 châssis physiques. Cette technologie permet de déployer une topologie de niveau 2 tout en évitant les problématiques souvent complexes liées au Spanning-Tree et ajouter de la redondance dans les liens optiques vers les switchs d’étages.

Plutôt que de longs discours, voici une illustration du Virtual Switching System (VSS) de Cisco :

Ce qui a provoqué ce reboot forcé de notre VSS Cisco, est à priori un bug dû à NetFlow.

Même si ce bug ne gêne en rien l’utilisation des switchs, celui-ci était embettant car il sature les logs avec le message ci-dessous, rendant impossible la consultation des logs sur le switch :

Jan 19 13:04:00: %C4K_HWFLOWMAN-3-NFEINTERRUPTSTATUS: (Suppressed 6736 times)module: fl InterruptStatus: 0x8
Jan 19 13:04:07: %C4K_HWFLOWMAN-4-NFEFLINTERRUPT: (Suppressed 107983 times)NFE FL ipv6AddrCompTblMemCorrectedEccErr interrupt. rep[0]: 0xE000000, rep[1]: 0x0, rep[2]: 0x0, valid: false, multipleErrorsDetected: false, addr: 0xE, ecc: 0x0

Ce message est dû à un problème de parité sur le moteur Netflow qui doit pouvoir être résolu en redémarrant le VSS :
https://tools.cisco.com/bugsearch/bug/CSCub56668/?referring_site=bugquickviewclick

Voyons ensemble la procédure que j’ai utilisé pour redémarrer ma VSS.

Etape 1 : Enregistrer la configuration.

Avant chaque reboot, j’ai pris l’habitude d’enregistrer la configuration pour éviter toute mauvaise surprise. Il est même nécessaire de disposer du fichier de configuration sur serveur TFTP par exemple. A ce titre vous pouvez consulter ce tutoriel (https://quick-tutoriel.com/script-perl-centreon-permettant-sauvegarder-switch-routeur-cisco/) pour mettre en place un système de sauvegarde de configuration via Centreon.

#Copy running-config startup-config

Etape 2 : Basculer le switch actif en passif.

Utiliser la commande ci-dessous, pour basculer le switch actif en passif et le redémarrer.

#redundancy force-switchover

La bascule est totalement transparente pour l’utilisateur. Généralement au moment de la bascule nous perdons 1 ou 2 pings.

Etape 3 : Vérifier le statut du VSS.

A cette étape il sera nécessaire de se reconnecter au switch car votre connexion SSH sera coupée, vu que nous avons changé de switch. Il est primordial d’attendre que le VSS se reforme avant de rebooter le deuxième switch.

Utiliser la commande suivante pour vérifier le statut du VSS :

#show redundancy

Il est intéressant de vérifier à plusieurs moments le statut du VSS Cisco, pour vérifier les différents états de celui-ci. Ici vous pouvez constater que le deuxième switch n’a pas encore totalement redémarré :

Ligne Communications = Down #Communication avec le deuxième switch perdue
Active Location = Slot 2/1 #Switch actif
Peer (slot : 1/1) = DISABLED state #le deuxième switch n’est pas reconnu

A ce stade, le switch est remonté mais pas le cluster VSS.

Ligne Communications = Up #Communication avec le deuxième ok
Standby Location = Slot 1/1 #Nous devons vérifier le statut du Switch passif
Dans Peer Processor Information -> Current Software state = STANDBY COLD-CONFIG #la configuration est en train de se synchroniser pour former le VSS Cisco

Le VSS est reformé. Vous pouvez basculer d’un switch à un autre sans coupure.

Ligne Communications = Up #Communication avec le deuxième ok
Active Location = Slot 2/1 #Switch actif
Dans Peer Processor Information -> Current Software state = STANDBY HOT #la configuration est synchronisé et le VSS Cisco est formé. Vous pouvez basculer sur l’autre switch sans coupure.

Il est préférable d’exécuter cette commande avant d’effectuer la commande de bascule redundancy force-switchover afin de s’assurer que le switch passif soit bien en STANDBY HOT.

Etape 4 : Vérifier les liens VSL (Virtual Switch Link)

L’élément essentiel de la technologie VSS Cisco est un lien appelé VSL (Virtual Switch Link) permettant de relier deux Catalyst 6500 ou 4500X fédérateurs. Ce lien permet entre autre l’échange de messages de contrôles et de signalisations entre les 2 équipements physiques afin de former un commutateur logique.

La commande suivante permet de vérifier si les liens VSL nécessaire à la formation du VSS sont opérationnels :

#show switch virtual link

Comme vous pouvez le constater, lors du reboot du switch actif, les liens VSL sont DOWN.

Une fois le reboot effectué et les liens montés, vous devriez avoir ceci comme résultat de la commande :

La ligne VSL Status doit être UP sur les deux switchs.

Etape 5 : reboot du deuxième switch.

Une fois que tous les liens sont remontés (VSL ) et que la configuration est en STANDBYHOT, on refait un redundancy force-switchover pour redémarrer le deuxième switch. La pile VSS est ainsi redémarré sans coupure pour vos switchs d’étages et surtout pour vos utilisateurs.

Attention toutefois, pour qu’il n’y ait pas de coupure, il faut que vos switchs d’étages soient raccordés sur les 2 éléments physiques formant le VSS.