Peut-on mélanger différents modèles Catalyst 9500 dans une paire StackWise Virtual ?

Non. Les deux commutateurs d'un domaine StackWise Virtual doivent être du même numéro de modèle (PID), exécuter la même version d'IOS XE et le même niveau de licence (par exemple, DNA Advantage). Cela garantit une parité complète des fonctionnalités et des performances entre les châssis.

Quelle est la distance maximale pour un StackWise Virtual Link (SVL) ?

La distance physique est dictée par l'optique utilisée (par exemple, un 100G-LR4 permet 10km). Cependant, la véritable contrainte est la latence. Les protocoles du plan de contrôle SVL sont conçus pour une latence quasi nulle, et une limite pratique et sûre est inférieure à 5 millisecondes. Il est fortement recommandé de garder les deux châssis dans le même data center ou salle de communication.

Comment StackWise Virtual gère-t-il la Quality of Service (QoS) ?

Les marquages QoS (DSCP, CoS) sont préservés lorsque les trames transitent par le SVL. Cependant, les politiques de mise en file d'attente, de policing et de shaping sont appliquées par châssis. Cela signifie que le trafic entrant dans le Switch 1 est soumis aux politiques de mise en file d'attente sortante du Switch 1, même si sa destination finale est un port du Switch 2.

Comment la licence est-elle gérée pour une paire StackWise Virtual ?

Les deux commutateurs doivent avoir un niveau de licence Cisco DNA Subscription identique (par exemple, Essentials, Advantage ou Premier). Un seul DNA Center peut gérer la paire comme une entité logique, mais les licences matérielles et logicielles sont achetées et appliquées par châssis.

Puis-je regrouper des ports 40G et 100G dans le même SVL ?

Non. Tous les liens membres au sein du port-channel désigné comme StackWise Virtual Link doivent avoir la même vitesse. Vous ne pouvez pas mélanger des interfaces 40G et 100G dans le même bundle. Vous devez choisir une seule vitesse et provisionner plusieurs interfaces de cette vitesse pour la capacité et la redondance.

Que se passe-t-il spécifiquement du point de vue du secondaire dans un scénario dual-active ?

Si le SVL tombe en panne et que le lien Fast-Hello échoue également, le commutateur secondaire suppose que le primaire est tombé et passe à l'état actif. Cependant, s'il reçoit ensuite un hello ePAgP d'un commutateur aval qui indique que le primaire d'origine est *également* actif, il sait qu'une condition dual-active existe. Il met immédiatement toutes ses interfaces frontales non-SVL en état error-disabled pour éviter les boucles et protéger le réseau.

Une connexion fibre directe est-elle vraiment obligatoire pour le lien Fast-Hello ?

Bien qu'il puisse fonctionner via un commutateur intermédiaire, c'est une violation de conception critique. Le but du lien Fast-Hello est d'être une simple vérification out-of-band de la vivacité du pair. Le faire passer par tout autre appareil introduit un shared fate ; si cet appareil échoue, vous pouvez déclencher une fausse détection dual-active. Un câble DAC direct ou un seul brin de fibre est la seule conception prise en charge et architecturalement saine.

Cisco StackWise Virtual Deep Dive : Conception du Cœur de Campus pour 2026

StackWise Virtual (SVL) est le successeur définitif du Virtual Switching System (VSS) pour la construction de couches de distribution et de cœur de campus d'entreprise résilientes et à large bande passante. Bien que le concept de jumelage de deux châssis en un seul commutateur logique ne soit pas nouveau, la mise en œuvre de SVL sur le matériel moderne des séries Catalyst 9500 et 9600 exige une compréhension nuancée de ses mécanismes sous-jacents, en particulier le StackWise Virtual Link (SVL), la détection dual-active et les processus d'In-Service Software Upgrade (ISSU). Un déploiement SVL réussi dépasse une simple mentalité de "plug-and-play" et nécessite des décisions d'ingénierie précises qui ont des implications significatives pour la stabilité et la performance du fabric.

StackWise Virtual vs. VSS et Backplane Stacking

Il est essentiel de différencier SVL de ses prédécesseurs et de ses cousins de la série Catalyst 9200/9300. VSS, pionnier sur la série Catalyst 6500, nécessitait des châssis identiques, des modules supervisor spécifiques (comme le VS-S2T-10G), et utilisait les port-channels physiques comme Virtual Switch Link (VSL). SVL sur les Catalyst 9500/9600 hérite de cette philosophie mais l'implémente sur l'architecture ASIC UADP moderne avec IOS XE.

Inversement, le StackWise traditionnel, tel qu'observé sur la série Catalyst 9300 avec StackWise-1T, utilise des câbles de backplane propriétaires (par exemple, STACK-T1) pour connecter plusieurs commutateurs dans une topologie en anneau. Cela crée un seul commutateur logique avec un plan de données et un plan de contrôle unifiés, partageant une seule adresse IP. SVL atteint le même résultat logique mais utilise des interfaces Ethernet standard 10/25/40/100G pour l'interconnexion, connue sous le nom de StackWise Virtual Link. Cette distinction est primordiale : SVL est destiné aux paires de commutateurs de distribution/cœur haute performance, tandis que StackWise est destiné à l'empilement de plusieurs commutateurs de couche d'accès dans une armoire de câblage.

Sélection de la Plateforme Matérielle du Cœur : Catalyst 9500 vs. 9600

Le choix entre la série Catalyst 9500 à configuration fixe et la série modulaire Catalyst 9600 pour une paire SVL dépend entièrement de la densité de ports, de l'évolutivité future et du budget. Les deux sont basés sur les ASIC UADP de Cisco, garantissant une parité des fonctionnalités pour les fonctions de cœur de campus.

Catalyst 9500 : Cœur Fixe Haute Performance

La série Catalyst 9500, en particulier les modèles haute performance, est idéale pour les blocs de cœur ou de distribution compacts. Un couplage courant est deux commutateurs C9500-48Y4C, offrant 48 ports SFP28 1/10/25G et 4 ports QSFP 40/100G. Pour des besoins de performance plus élevés, le C9500-32C offre 32 ports QSFP28 40/100G. Ces plateformes, fonctionnant sur UADP 3.0, offrent d'importantes ressources TCAM et de buffer adaptées à la plupart des exigences de cœur d'entreprise. Leur nature fixe signifie que ce que vous achetez est ce que vous obtenez ; une future extension implique un remplacement de châssis, et non l'ajout d'une carte de ligne.

Catalyst 9600 : Échelle Modulaire pour les Grands Campus

Pour les grands campus d'entreprise ou universitaires, le châssis Catalyst 9606R avec une paire de supervisors C9600-SUP-1 est le choix logique. La modularité permet un mélange de cartes de ligne, telles que la C9600-LC-48YL (48 ports 1/10/25G) et la C9600-LC-24C (24 ports 40/100G). Cela permet un modèle de paiement à la croissance et la capacité d'adopter des technologies futures, comme le 400G, via une nouvelle carte de ligne plutôt qu'un remplacement complet du système. Une paire SVL de châssis 9606R offre le nec plus ultra en matière de résilience et d'échelle, capable de prendre en charge des milliers d'utilisateurs et de périphériques.

Dimensionnement du StackWise Virtual Link (SVL)

Le SVL est le composant le plus critique de la conception. Il transporte toute la communication du plan de contrôle et tout le trafic de données qui doit traverser les deux châssis (c'est-à-dire le "trafic inter-châssis"). Sous-dimensionner le SVL prive le fabric de bande passante et peut entraîner des performances imprévisibles, tandis que sur-dimensionner gaspille des ports haute vitesse coûteux. Une approche pragmatique du dimensionnement est essentielle.

Considérons un bloc de distribution construit sur une paire SVL de commutateurs C9500-32C. Ce bloc dessert dix stacks de couche d'accès de Catalyst 9300, chacun avec des uplinks dual 40G configurés en Multi-chassis EtherChannel (MEC) vers la paire SVL. La capacité totale d'uplink est de 10 * (2 * 40 Gbps) = 800 Gbps. Une règle empirique courante est de provisionner le SVL avec une capacité égale à 25-50% de la bande passante totale d'uplink connectée, en supposant une distribution uniforme de la terminaison du trafic sur les deux châssis.

Exemple de Calcul :

Bande passante totale d'Uplink : 800 Gbps
Capacité SVL Cible (règle des 30%) : 800 Gbps * 0.30 = 240 Gbps
Implémentation : Un port-channel à trois ports d'interfaces 100G (3 x 100 Gbps = 300 Gbps).

Sur chaque C9500-32C, vous provisionneriez les ports HundredGigE1/0/30, 1/0/31 et 1/0/32 pour le SVL. Cela offre 300 Gbps de bande passante, dépassant l'objectif de 240 Gbps et offrant une redondance N+1 ; la défaillance d'un seul lien laisse encore 200 Gbps de capacité. Exécuter des données critiques et du trafic de contrôle sur un seul lien, même un 100G, est un antipattern de conception. Utilisez toujours un port-channel avec au moins deux membres pour le SVL.

Détection Dual-Active : Le Filet de Sécurité Ultime

Un scénario dual-active est l'état de défaillance le plus catastrophique pour une paire de commutation virtualisée. Il se produit lorsque le SVL tombe en panne et que les deux commutateurs pensent être le châssis actif. Cela entraîne une duplication d'adresses IP, une instabilité de la table d'adresses MAC et des boucles à l'échelle du réseau. SVL utilise un mécanisme de détection multicouche, une évolution du VSS, pour éviter cela.

SVL Keepalives : La méthode principale. Les en-têtes propriétaires Cisco sur le trafic SVL incluent des keepalives. Si ceux-ci ne sont pas reçus pendant la période de timer configurée (les valeurs par défaut sont agressives, de l'ordre de quelques centaines de millisecondes), le commutateur secondaire lance une séquence de basculement.
Fast-Hello : Il s'agit d'un lien out-of-band obligatoire. Il implique une connexion layer-2 directe (par exemple, un seul port SFP 1G sur chaque commutateur, comme Gi1/0/1 <--> Gi1/0/1) dédiée à l'envoi de paquets keepalive UDP. Si le SVL tombe en panne mais que les keepalives Fast-Hello sont toujours reçus, le commutateur secondaire sait que le primaire est toujours actif et entre immédiatement en mode de récupération, désactivant tous ses ports frontaux (sauf le SVL) pour éviter les boucles.
Enhanced PAgP (ePAgP) / MEC : C'est le dernier arbitre et une amélioration significative par rapport à VSS. Si le SVL et les liens Fast-Hello échouent simultanément (par exemple, une défaillance multi-cartes ou une défaillance de commutateur intermédiaire), la paire SVL peut utiliser un commutateur aval pour communiquer. Un TLV PAgP spécial sur le Multi-chassis EtherChannel (MEC) informe chaque membre SVL de l'existence de l'autre. Si un commutateur se voit et voit son pair dans les messages PAgP d'un périphérique aval, mais ne peut pas joindre le pair via le SVL, il sait qu'une condition dual-active existe.

Piège Courant : Le Lien Fast-Hello Partagé

Une erreur courante est de faire passer le lien Fast-Hello par un autre équipement réseau, comme un commutateur de management, pour économiser de la fibre. C'est une faille de conception critique. Si ce commutateur intermédiaire redémarre ou tombe en panne, les deux membres SVL perdent la connectivité Fast-Hello, déclenchant un faux positif. Le lien Fast-Hello DOIT être une connexion directe et dédiée entre les deux châssis SVL — idéalement un seul brin de fibre ou un câble DAC si co-localisé. Faire des économies ici compromet toute la conception de haute disponibilité.

Quand ne PAS Utiliser StackWise Virtual

SVL est un outil puissant, mais ce n'est pas la solution universelle pour toutes les conceptions de campus. L'appliquer dans le mauvais contexte crée plus de problèmes qu'il n'en résout.

EVPN-VXLAN Fabrics : Pour les fabrics de campus avancés employant une overlay EVPN-VXLAN avec un control plane BGP, SVL est le mauvais modèle. Une véritable architecture spine-leaf (CLOS) repose sur des liaisons L3 routées individuellement entre les commutateurs leaf et spine. Chaque commutateur est une entité de routage indépendante. SVL, en revanche, crée un grand domaine L2 avec un seul point de contrôle, ce qui est antithétique aux principes d'un fabric routé.
Cœurs Géographiquement Dispersés : Tenter d'"étirer" une paire SVL entre différents bâtiments ou data centers via DWDM ou fibre noire est une pratique dangereuse. Le protocole SVL est extrêmement sensible à la latence et au jitter. Toute latence supérieure à quelques millisecondes (la limite officielle de Cisco est souvent citée en fonction de la portée optique, mais 5ms est un plafond pratique sûr) peut provoquer une instabilité dans la communication du control plane. Une défaillance du lien longue distance pourrait entraîner une condition dual-active difficile à dépanner. Le domaine de défaillance devient inacceptablement grand.
Petits Déploiements : Pour un scénario simple de top-of-rack ou d'armoire de câblage avec 2 à 4 commutateurs, une paire SVL complète de Catalyst 9500 est excessive. Un stack de Catalyst 9300 utilisant les câbles de backplane dédiés StackWise-1T est beaucoup plus rentable, plus simple à configurer et offre un plan de gestion unifié dans un format plus approprié.

ISSU et Stateful Switchover (SSO)

L'In-Service Software Upgrade (ISSU) est un avantage clé de SVL, permettant des mises à jour logicielles avec une interruption minimale du trafic. Cependant, sa nature "hitless" est souvent mal comprise. Le processus, régi par le Stateful Switchover (SSO), fonctionne en mettant à niveau le châssis standby en premier. Il redémarre avec le nouveau code pendant que le châssis active continue de transférer le trafic. Une fois que le standby est en ligne et synchronisé, un switchover manuel ou automatique est déclenché. Le châssis nouvellement active, exécutant le nouveau code, prend le relais du transfert de trafic. L'ancien châssis active (maintenant standby) est ensuite mis à niveau.

Ce processus maintient le data plane — le transfert se poursuit sur la base des tables FIB et d'adjacence existantes. Cependant, le control plane subit une réinitialisation. Les protocoles de routage comme OSPF et EIGRP, lorsqu'ils sont configurés pour le Non-Stop Forwarding (NSF), effectueront un graceful restart, évitant les flaps de voisins. Les sessions BGP redémarreront également de manière gracieuse. Cependant, ce n'est pas un événement vraiment "invisible". Le processus nécessite IOS XE 17.3.2 ou une version ultérieure et une adhésion stricte à la matrice de compatibilité pour les versions source et destination. Effectuez toujours l'ISSU pendant une fenêtre de maintenance planifiée avec une procédure de rollback documentée.

Migration de Catalyst VSS vers StackWise Virtual

De nombreuses entreprises sont confrontées à la fin de vie de leurs cœurs VSS Catalyst 6500/6800. La migration vers une paire SVL Catalyst 9500/9600 peut être effectuée avec un temps d'arrêt minimal en utilisant une approche swing migration.

Pré-staging : Montez et empilez la nouvelle paire SVL. Configurez le SVL, le Fast-Hello, toutes les SVI, les protocoles de routage, les ACL et les politiques QoS. Gardez les SVI en état shutdown. Les nouveaux port-channels MEC face à la couche d'accès doivent être configurés mais seront vides.
Swing Uplinks (Fenêtre de Maintenance) : Pour chaque commutateur aval ou stack connecté à la paire VSS via MEC, effectuez le swing. Supposons qu'un stack Cat 9300 ait un uplink vers VSS-Active et un vers VSS-Standby.

Déplacez l'uplink du châssis VSS-Standby vers un port du nouveau châssis SVL-Standby. Le port-channel sur le Cat 9300 aura maintenant un lien membre down et un up (vers VSS-Active).
Déplacez l'uplink du châssis VSS-Active vers un port du nouveau châssis SVL-Active. Le port-channel sur le Cat 9300 sera maintenant entièrement connecté au nouveau cœur SVL. Le trafic ne circule toujours pas car les SVI sont down.

Basculement de Routage : C'est l'étape qui affecte le service. Sur le nouveau cœur SVL, exécutez un `no shutdown` sur toutes les SVI du cœur. Simultanément, `shutdown` toutes les SVI sur l'ancien cœur VSS. Cela force tout le trafic routé à traverser le nouveau fabric. Les adjacences de routage des pairs tomberont de l'ancien cœur et se reformeront avec le nouveau.
Décommissionnement : Après une période de surveillance pour assurer la stabilité, mettez hors tension et retirez les anciens châssis VSS.

StackWise Virtual, lorsqu'il est implémenté sur les robustes plateformes Catalyst 9500 et 9600, offre une solution formidable pour construire la prochaine génération de réseaux de campus d'entreprise. Sa force ne réside pas dans la simplicité de son concept, mais dans l'exécution détaillée de ses composants de support : un SVL correctement dimensionné, un lien Fast-Hello physiquement isolé et des MEC correctement configurés. En évitant les pièges courants et en respectant ses limites de conception, les ingénieurs réseau peuvent construire un fabric de cœur et de distribution qui offre la stabilité et la performance requises jusqu'en 2026 et au-delà. Pour discuter d'un plan de migration personnalisé ou d'une revue architecturale pour votre campus, contactez les experts de techleague.io.

Pour en savoir plus sur la conception de campus, consultez nos articles sur EVPN-VXLAN comme Fabric de Campus et une revue de performance du Catalyst 9300X avec StackWise-1T.