Meilleures pratiques pour le déploiement de Catalyst 6500 VSS

Introduction

Ce document fournit les meilleures pratiques pour les scénarios de déploiement de Cisco Catalyst 6500 Virtual Switching System (VSS) 1440.

Ce document fournit des conseils de configuration modulaires. Par conséquent, vous pouvez lire chacune des sections indépendamment et apporter des modifications dans une approche par étapes. Ce document suppose une compréhension et une familiarité de base avec l'interface utilisateur du logiciel Cisco IOS®. Il ne couvre pas la conception globale du réseau.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Meilleures pratiques de déploiement VSS

Les solutions que ce document décrit représentent des années d'expérience terrain des ingénieurs Cisco, qui travaillent avec des réseaux complexes et des clients qui font partie des plus grands comptes du marché. Par conséquent, ce document souligne les configurations réelles qui assurent la réussite des réseaux. Ce document traite des solutions suivantes :

• Solutions faciles à gérer et configurées par des équipes d'exploitation du réseau.

• Solutions qui favorisent une forte disponibilité et une forte stabilité.

Haute disponibilité VSS

• Transfert sans arrêt

• Synchronisation OOB MAC

Transfert sans arrêt

Les commutateurs de la gamme Catalyst 6500 prennent en charge la résistance aux défaillances, car ils permettent à un Supervisor Engine redondant de prendre le relai en cas de défaillance du Supervisor Engine principal. Le transfert sans arrêt (NSF) Cisco fonctionne avec la commutation avec état (SSO) afin de réduire le temps d'indisponibilité d'un réseau à ses utilisateurs après une commutation tandis que des paquets IP continuent à être transférés.

Recommandations

• Le transfert sans arrêt est requis pour la convergence de commutation du superviseur à une fraction de seconde.

• Utilisez les temporisateurs Hello et Dead pour les protocoles EIGRP / OSPF quand vous exécutez dans un environnement VSS.

• Si vous exécutez le système avec un logiciel modulaire Cisco IOS, il est recommandé d'opter pour le temporisateur Dead OSPF avec la plus grande valeur.

EIGRP

Switch(config)# router eigrp 100
Switch(config-router)# nsf

Switch# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"

!--- part of the output truncated

EIGRP NSF-aware route hold timer is 240s

!--- indicates that EIGRP is configured to be NSF aware


!--- part of the output truncated

EIGRP NSF enabled

!--- indicates that EIGRP is configured to be NSF capable


!--- rest of the output truncated

OSPF

Switch(config)# router ospf 100
Switch(config-router)# nsf

Switch# show ip ospf
Routing Process "ospf 100" with ID 10.120.250.4
Start time: 00:01:37:484, Time elapsed: 3w2d

!--- part of the output truncated

Supports Link-local Signalling (LLS)

!--- indicates that OSPF is configured to be NSF aware


!--- part of the output truncated

Non-Stop Forwarding enabled, last NSF restart 3w2d ago (took 31 secs)

!--- indicates that OSPF is configured to be NSF capable


!--- rest of the output truncated

Reportez-vous à Configuration de NSF avec le Supervisor Engine SSO pour plus d'informations sur NSF.

Synchronisation OOB MAC

Dans la commutation distribuée, chaque carte de fonction distribuée (DFC) met à jour sa propre table CAM. Cela signifie que chaque DFC apprend les adresses MAC et les vieillit, en fonction de la capacité de CAM à vieillir et de la correspondance avec le trafic de cette entrée particulière. Avec la commutation distribuée, il est normal que le Supervisor Engine ne voie pas le trafic correspondant à une adresse MAC déterminée pendant un moment, ainsi l'entrée peut arriver à expiration. Il existe actuellement deux mécanismes disponibles pour assurer la cohérence des tables CAM entre les différents moteurs, comme DFC, qui est présent dans les modules de ligne, et PFC (Policy Feature Card), qui est présent dans des modules de superviseur :

• Flood to Fabric (FF)

• MAC Notification (MN)

Quand une entrée d'adresse MAC expire sur le PFC, la commande show mac-address address <adresse_MAC> all affiche le DFC ou le PFC qui contient cette adresse MAC. Afin d'empêcher l'expiration d'une entrée sur un DFC ou un PFC, même s'il n'y a pas de trafic pour cette adresse MAC, activez la synchronisation des adresses MAC. Émettez la commande de configuration globale mac-address-table synchronize et la commande privilégiée EXEC clear mac-address-table dynamic afin d'activer la synchronisation. La commande mac-address-table synchronize est disponible à partir des versions 12.2(18)SXE4 et ultérieures du logiciel Cisco IOS. Après avoir activé la synchronisation, il est possible que vous voyiez toujours des entrées qui ne sont pas présentes dans PFC ou DFC. Cependant, le module a un moyen d'apprendre à partir d'autres modules qui utilisent le canal Ethernet Out of Band Channel (EOBC).

Recommandations

Activer la synchronisation hors bande MAC. Elle est utilisée afin de synchroniser des tables d'adresses MAC à travers les moteurs de transfert. Si WS-6708-10G est présent dans le système VSS, la synchronisation MAC est automatiquement activée. Sinon, elle doit être activée manuellement.

Dist-VSS(config)# mac-address-table synchronize
% Current activity time is [160] seconds
% Recommended aging time for all vlans is atleast three times the activity interval

Dist-VSS# clear mac-address-table dynamic
% MAC entries cleared.

Dist-VSS# show mac-address-table synchronize statistics

MAC Entry Out-of-band Synchronization Feature Statistics:
---------------------------------------------------------
Switch [1] Module [4]
---------------------
Module Status:
Statistics collected from Switch/Module   : 1/4
Number of L2 asics in this module         : 1

Global Status:
Status of feature enabled on the switch   : on
Default activity time                     : 160
Configured current activity time          : 480

Terminologie VSS

• Virtual Switch Link (VSL) : canal de port spécial requis pour regrouper deux commutateurs physiques en un seul commutateur virtuel.

• Protocole VSL (VSLP) : s'exécute entre le commutateur actif et le commutateur de secours sur le VSL et comporte deux composants : LMP et RRP

  • Protocole LMP (Link Management Protocol) : s'exécute sur chaque liaison individuelle dans VSL

  • RRP (Role Resolution Protocol) : s'exécute de chaque côté (chaque homologue) du canal de port VSL.

Planification de la capacité pour VSL

Idéalement, dans la configuration VSS à double interface, aucun trafic de données n'est envoyé sur la liaison VSL. Chaque commutateur est programmé pour choisir ses interfaces locales pour le transfert du trafic.

La planification de la capacité supplémentaire de liaison VSL est requise pour le trafic porté par :

• Choisissez les périphériques à interface unique

• SPAN distant d'un commutateur à l'autre

• Trafic du module de service - ” FWSM, ACE, etc.

Reportez-vous à Trafic sur le VSL pour plus d'informations.

Recommandations

• Connectez toujours les périphériques à double interface au VSS.

• Groupez toujours EtherChannel VSL dans l'alimentation de 2, parce qu'elle a de meilleurs résultats de hachage pour le partage de la charge optimisée du trafic.

• La redondance du VSL est encore critique avec la résilience des liaisons VSL.

• Il est recommandé d'avoir au moins une bande passante VSL égale aux liaisons ascendantes connectées à un commutateur physique simple.

Récupération en amont de liaison

La récupération des liaisons en amont (liaisons au noyau) peut être obtenue à travers EtherChannel MultiChassis (MEC) ou la fonctionnalité Equal Cost MultiPath (ECMP).

La convergence MEC est cohérente et independante du nombre de routes. La convergence ECMP dépend pour sa part du nombre de routes. Ce graphique indique l'importance de la perte en session de Voix.

Ces images montrent des scénarios de défaillance de liaison avec MEC et ECMP :

EtherChannel MultiChassis

EtherChannel MultiChassis est un EtherChannel avec des ports qui se terminent sur les deux châssis du VSS. Un VSS MEC peut se connecter à n'importe quel élément du réseau qui prend en charge EtherChannel, tel qu'un hôte, un serveur, un routeur ou un commutateur. Au VSS, un MEC est un EtherChannel avec une capacité supplémentaire. Le VSS équilibre la charge à travers des ports dans chaque châssis indépendamment. Par exemple, si le trafic entre dans le châssis actif, le VSS sélectionne une liaison MEC depuis le châssis actif. Cette capacité MEC assure que le trafic de données ne traverse pas inutilement le VSL.

• L2 MEC active la topologie de boucle libre, double la largeur de bande passante de liaison ascendante car aucune liaison n'est bloquée et fournit une convergence plus rapide que STP.

• L3 MEC fournit des décomptes voisins réduits, un meilleur partage de charge (L2 et L3 pour la monodiffusion et la multidiffusion), l'utilisation réduite de la liaison VSL pour des flux de multicast et une convergence plus rapide qu'ECMP.

Reportez-vous à EtherChannels Multichassis pour plus d'informations sur MEC.

Recommandations

• Exécutez toujours L2 ou L3 MEC.

• N'utilisez pas les options marche-arrêt avec PAgP, LACP ou la négociation de protocole de liaison.

  • PAgP - ” Exécuter Desirable-Desirable avec des liaisons MEC.

  • LACP - ” Exécuter Active-Active avec des liaisons MEC.

  • Trunk - ” Exécuter Desirable-Desirable avec des liaisons MEC.

Perte et récupération de liaison VSL

Si le VSL échoue, le châssis de réserve ne peut pas déterminer l'état du châssis actif. Afin de s'assurer que la commutation se produise sans délai, le châssis de réserve suppose que le châssis actif a échoué et lance la commutation pour assurer le rôle actif.

Si le châssis actif initial est encore opérationnel, les deux châssis sont maintenant en activité. Cette situation est appelée un scénario d'activité double. Un scénario d'activité double peut avoir des effets défavorables sur la stabilité du réseau, parce que les deux châssis utilisent les mêmes adresses IP, clés SSH et ID de pont STP. Le système de commutation virtuel (VSS) doit détecter un scénario d'activité double et prendre une mesure de récupération.

Le système de commutation virtuelle prend en charge ces trois méthodes afin de détecter un scénario de double activité :

• PAgP amélioré - ” utilise la messagerie PAgP sur les liaisons MEC afin de communiquer entre les deux châssis via un commutateur voisin. PAgP amélioré est plus rapide que IP BFD, mais il requiert un commutateur voisin qui prenne en charge les améliorations de PAgP.

  

  Table de support d'ePAgP :

  Gamme de périphérique	Logiciel Cisco IOS minimum
  Cisco Catalyst 3750	Cisco IOS 12.2(46)SE
  Cisco Catalyst 4500	Cisco IOS 12.2(44)SE
  Cisco Catalyst 6500	Cisco IOS 12.2(33)SXH
  Cisco Catalyst 6500 VSS	Cisco IOS 12.2(33)SXH1

• IP Bidirectional Forwarding Detection (BFD) : ” utilise la messagerie BFD sur une connexion Ethernet de secours. IP BFD utilise une connexion directe entre les deux châssis et ne requiert pas la prise en charge d'un commutateur voisin. Cette méthode est disponible dans la version du logiciel Cisco IOS 12.2(33)SXH1 et ultérieures.

  

• VSLP dual-active fast-hello - ” utilise des messages Hello spéciaux sur une connexion Ethernet de secours. Fast-Hello d'activité double est plus rapide que IP BFD et ne requiert pas la prise en charge d'un commutateur voisin. Cette méthode est seulement disponible dans les versions 12.2(33)SXI et ultérieures du logiciel Cisco IOS.

  

Vous pouvez configurer chacune des trois méthodes de dépistage pour être en activité en même temps.

Ces graphiques fournissent les informations sur la convergence de quelques protocoles de routage IP en ce qui concerne la convergence à double activité de VSS.

Convergence EIGRP avec des temporisateurs par défaut

Convergence OSPF avec des temporisateurs par défaut

Recommandations

• Activez au moins deux liaisons dans VSL.

• Utilisez MEC avec ePAgP ou MEC avec Fast Hello pour des résultats plus rapides de convergence de perte de liaison VSL.

• Activez ECMP avec IP-BFD.

• Activez ePAgP au centre, si la couche d'accès n'a pas la capacité ePAgP.

• Activez les deux méthodes ePAgP et Fast Hello VSLP basée sur la liaison directe «  battement de coeur », si possible.

• Pendant le processus de perte et de récupération VSL, n'effectuez pas de modifications de configuration.

  • Après la restauration d'au moins une liaison membre VSL, si la configuration de l'ancien châssis ACTIF reste inchangée, l'ancien ACTIF se réinitialise pour démarrer dans l'état de redondance de secours automatique VSS.

    *Apr 6 17:36:33:809: %VSLP-SW1_SP-5-VSL_UP: Ready for Role Resolution with 
    Switch=2, MAC=0013a.30e1.6800 over Te1/5/5
    *Apr 6 17:36:36.109: %dualACTIVE-1-VSL_RECOVERED: VSL has recovered during 
    dual ACTIVE situation: Reloading switch 1
    
    !--- part of output truncated
    
    *Apr 6 17:36:36.145: %VSLP-SW1_SP-5-RPR_MSG: Role change from ACTIVE to HOT_STANDBY and 
    hence need to reload
    *Apr 6 17:36:36.145: %VSLP-SW1_SP-5-RPR_MSG: Reloading the system...
    *Apr 6 17:36:36.145: %SYS-SW1_SP-5-RELOAD: Reload requested Reload Reason: VSLP HA role 
    change from ACTIVE to HOT_STANDBY.

  • Si la configuration est modifiée, marquée telle que modifiée par le processus de synchronisation de configuration, le commutateur ne se recharge pas automatiquement.

  • Le rechargement manuel doit être émis sur l'ancien ACTIF une fois que la configuration a été corrigée et enregistrée. Même si vous entrez seulement le mode de configuration et que vous sortez, la configuration sera marquée telle que modifiée et obligera à une intervention manuelle.

    *Aug 13 04:24:34.716: %dualACTIVE-1-VSL_RECOVERED: VSL has recovered 
    during dual ACTIVE situation: Reloading switch 2
    *Aug 13 04:24:34.716: %VS_GENERIC-5-VS_CONFIG_DIRTY: Configuration has changed. 
    Ignored reload request until configuration is
    	
    	
    	
    	
    		saved

Reportez-vous à la Détection de double activité pour plus d'informations.

Redondance avec des modules de service

La prise en charge du module de service est une exigence essentielle pour placer le VSS sur le campus d'entreprise et le marché du centre de données de l'entreprise. La liste de modules de service qui sont pris en charge dans le système virtuel de commutation est :

Module de service	Version minimum de Cisco IOS	Version minimum de module
Module d'analyse réseau (NAM-1 et NAM-2) (WS-SVC-NAM-1 et WS-SVC-NAM-2)	12.2(33)SXH1	3.6(1 bis)
Moteur de contrôle d'application (ACE10 et ACE20) (ACE10-6500-K9 et ACE20-MOD-K9)	12.2(33)SXI	A2(1.3)
Module de services du système de détection d'intrusion (IDSM-2) (WS-SVC-IDSM2-K9)	12.2(33)SXI	6.0(2)E1
Module de services sans fil (WiSM) (WS-SVC-WISM-1-K9)	12.2(33)SXI	3.2.171.6
Module de services de pare-feu (FWSM) (WS-SVC-FWM-1-K9)	12.2(33)SXI	4.0.4

Des modules de service peuvent être placés dans n'importe lequel des châssis physiques qui comportent un VSS.

Recommandations

• Pour la configuration avec plus d'un module de service d'un type déterminé, configurez-en un pour chaque commutateur physique en vue d'une meilleure disponibilité.

• VSL porte le trafic dans des scénarios la normaux et de basculement et la bande passante de VSL doit être ajustée en fonction.

Reportez-vous à Intégration des modules de service Cisco avec le système de commutation virtuelle 1440 de Cisco Catalyst 6500 pour plus d'informations sur l'intégration du module de service.

Multidiffusion

Les protocoles de multidiffusion IPv4 fonctionnent sur le Supervisor Engine actif. Des paquets des protocoles Internet Group Management Protocol (IGMP) et Protocol Independent Multicast (PIM) reçus sur le Supervisor Engine de réserve sont transmis à travers VSL au châssis actif. Le Supervisor Engine actif envoie des paquets du protocole IGMP et PIM au Supervisor Engine de réserve afin de mettre à jour les informations de la couche 2 pour la commutation avec état (SSO).

Reportez-vous à multicast IPv4 pour plus d'informations.

Recommandations

• Les périphériques connectés doivent toujours être à double interface pour une performance optimale de réplication.

• MEC est recommandé dans l'environnement L3 et L2 pour fournir la convergence déterministe.

• MEC élimine le recalcul de la retransmission par le chemin inverse (RPF) pendant n'importe quelle défaillance de liaison MEC.

• Réplication de sortie avec amélioration locale pour un débit de réplication multicast plus élevé.

• La réplication de sortie requiert des DFC pour des performances optimisées de réplication.

• Classez le VSL pour répondre aux conditions requises en matière de trafic.

Qualtiy de service

Paramètres de QoS VSL

• VSL est un chemin critique de contrôle interne et de communication de données. Par conséquent, les paramètres de QoS sont préconfigurés et des modifications de configuration ne sont pas permises.

• VSL est toujours configuré en tant que Trust CoS et la mise en file d'attente d'entrée est activée.

• Seule la confiance et la mise en file d'attente basées sur CoS sont actuellement prises en charge. Des stratégies de service ne sont pas prises en charge par VSL.

• Des stratégies QoS doivent être appliqués à l'interface d'entrée des flux.

• La file d'attente prioritaire est activée par défaut. Une haute priorité est accordée au trafic de contrôle VSS et aux BPDU sur la liaison VSL.

Recommandations

La seule différence entre les options matérielles avec la capacité VSL réside en la configuration de la file d'attente. Puisque la version actuelle du logiciel ne permet pas de modification des paramètres de file d'attente par défaut, n'importe quelle combinaison des ports avec capacité VSL fournit les mêmes résultats de QoS.

Matériel	Mode de file d'attente	Mode confiance	File d'attente de transmission	File d'attente de réception
VSL sur liaisons ascendantes - ” non 10G uniquement (par défaut)	CoS	CoS	1p3q4t (DWRR/SRR)	8q4t
VSL sur liaisons ascendantes - 10G ” uniquement	CoS	CoS	1p7q4t (DWRR/SRR)	2q4t
VSL à travers des liaisons ascendantes et des cartes de ligne	CoS	CoS	1p3q4t [non-10G] (DWRR/SRR) 1p7q4t [10G uniquement] (DWRR/SRR)	2q4t
VSL sur des cartes de ligne	CoS	CoS	1p7q4t (DWRR/SRR)	8q4t

Reportez-vous à Configuration de QoS VSL pour plus d'informations.

SPAN

Dans un domaine virtuel de commutation, le nombre de sessions SPAN est limité par ce que le superviseur actif de commutation virtuelle peut fournir.

Le système virtuel de commutation prend en charge ces capacités SPAN par domaine de commutation virtuelle.

Attribut	Valeur
Sessions SPAN tx	14
Rx/les deux sessions de SPAN	2
Nombre total de sessions SPAN	16

Recommandations

• Si VSL est configuré comme source SPAN locale, le ou les ports de destination SPAN doivent se trouver sur le même châssis que les interfaces VSL.

• VSL ne peut pas être configuré comme destination SPAN.

• VSL ne peut pas être configuré comme source de RSPAN, ERSPAN ou Tx uniquement local SPAN.

• L'en-tête VSL est supprimé par le port de destination SPAN avant que le paquet ne soit transmis et ne peut donc pas être capturé dans les traces de l'analyseur de réseau.

• Lorsque la source et la destination sont toutes deux sur le même châssis (actif ou en veille), le trafic SPAN ne circule pas sur la liaison VSL.

  Afin de capturer le trafic des deux châssis, deux options permettent d'éviter le flux du trafic SPAN sur le VSL :

  • Pour chaque interface source d'un châssis, l'interface de destination doit se trouver sur le même châssis.

    Par exemple, PO20 a gi1/1/1 et gi2/1/1 : vous devez avoir une destination pour chaque châssis.

    Monitor session 1 source interface gi1/1/1
    Monitor session 1 destination interface gi1/1/2
    
    Monitor session 2 source interface gi2/1/1
    Monitor session 2 destination interface gi2/1/2

    Cependant, cela signifie que vous utilisez les deux sessions SPAN locales. Par conséquent, vous ne pouvez utiliser aucune autre session SPAN locale.

  • Vous pouvez utiliser l'interface de destination pour SPAN en tant que MEC (recommandé).

    Le port de destination peut être un MEC.

Divers

Recommandations

• Utilisez un minimum d'une liaison ascendante de superviseur pour VSL afin d'avoir un apport de VSL plus rapide.

• Configure la commande switch accept mode virtual après la conversion de VSS. Sans cette commande, la conversion n'est pas complète.

• Enregistrez la sauvegarde du fichier de configuration dans le disque système actif et de secours automatique : Ceci est d'une grande aide dans des scénarios de remplacement de superviseur.

• Utilisez une seule ID de domaine VSS dans le même réseau. L'ID de domaine VSS en doublon peut entraîner l'incohérence d'EtherChannel.

  Voici un exemple pour modifier l'ID de domaine VSS.

  1. Utilisez la commande switch virtual domain domain-id afin d'initier la modification de l'ID de domaine.

     switch(config)#switch virtual domain 50
     

     Remarque : la configuration de l'ID de domaine 50 n'entre en vigueur qu'après l'exécution de la commande exec du mode de conversion de commutateur.

  2. Utilisez la commande switch convert mode virtual afin de terminer la tâche.

     switch#switch convert mode virtual
     

     Remarque : l'ID de domaine virtuel ne change qu'après avoir enregistré la configuration et rechargé le commutateur.

• Utilisez la commande erase nvram au lieu de la commande write erase afin de réinitialiser la configuration VSS. La commande write erase efface la configuration de démarrage et les variables ROMMon. VSS exige la variable ROMMon switch-id afin de démarrer en mode VSS.

• N'utilisez pas la préemption. Référez-vous à Cisco recommande de ne pas configurer la préemption du commutateur pour plus d'informations.

• N'utilisez pas la commande shutdown pour la simulation de panne VSL, dans la mesure où elle crée une disparité de configuration. Si vous déconnectez un câble, il fournit un scénario de panne plus réaliste.

• Ne modifiez pas l'algorithme de hachage VSL tandis que le système est en mode de production. La modification de l'algorithme requiert que le canal de port soit désactivé puis réactivé, avec les commandes shutdown et no shutdown. Si vous arrêtez un VSL, il entraîne l'interruption du trafic et peut finir en scénario de double activité.

• Configurez le temporisateur d'obsolescence MAC à trois fois la valeur du temporisateur de synchronisation MAC.

  La synchronisation MAC par défaut et les temporisateurs d'obsolescence MAC peuvent entraîner l'inondation inconnue de monodiffusion. Le VSS peut causer l'écoulement asymétrique du trafic de sorte que l'adresse MAC source soit seulement apprise sur un châssis. Le temporisateur d'obsolescence MAC de 300 secondes et du temporisateur de synchronisation MAC de 160 secondes permet jusqu'à 20 secondes d'inondation de monodiffusion inconnue pour n'importe quelle adresse MAC donnée dans un intervalle de 320 secondes. Afin de résoudre ceci, modifiez les temporisateurs de façon à ce que le temporisateur d'obsolescence soit trois fois supérieur au temporisateur de synchronisation, par exemple, mac-address-table aging-time 480.

  L'exemple de sortie de la commande show mac-address-table aging-time est présenté ici :

  switch#sh mac-address-table aging-time
  Vlan Aging Time
  ---- ----------
  Global 480
  no vlan age other than global age configured

• Pour que VSS fonctionne avec la commutation avec état (SSO), les deux moteurs de supervision doivent exécuter la même version logicielle.

• Si vous revenez à un commutateur autonome à partir du mode VSS via la commande switch convert mode standalone, il effectue les tâches suivantes :

  • Convertit le nom de l'interface avec le nom du commutateur/logement/port en logement/port.

  • Supprime les interfaces non locales de la configuration en cours.

  • Supprime les canaux de port VSL et la configuration des ports.

  • Enregistre la configuration en cours dans la configuration initiale

  • Définit la variable COMMUTATEUR_NUMBER SP rommon sur 0.

  • Recharge le commutateur.

• Le redémarrage du commutateur est nécessaire lorsqu'il est strictement nécessaire ; par exemple, une mise à niveau IOS ou une étape de dépannage. Un commutateur qui fonctionne depuis plus de deux ans signifie qu'il s'agit d'un commutateur stable et que la configuration est également stable.

Forum aux questions

Est-il possible d'utiliser deux superviseurs dans chaque châssis avec VSS ?

Oui. Les superviseurs doubles de chaque châssis VSS configuré pour le mode VSS sont pris en charge à partir de SXI4 et des versions ultérieures.

Lors de la suppression des commandes preempt dans les commutateurs de la gamme Catalyst 6500 en mode VSS, les commutateurs seront-ils rechargés ?

La préemption du commutateur n'est pas recommandée. Par conséquent, la suppression des commandes est une bonne pratique et ne provoque pas de rechargement. Pour plus d'informations sur la fonctionnalité de préemption sur VSS, référez-vous à Préemption de commutateur.

Informations connexes

• Pratiques recommandées pour les commutateurs des gammes Catalyst 6500/6000 et Catalyst 4500/4000 exécutant le logiciel Cisco IOS
• Configurer les systèmes de commutation virtuels
• Référence de commande du commutateur virtuel de Cisco IOS
• Prise en charge du produit Système de commutation virtuelle 1440 de Cisco Catalyst 6500
• Commutateurs LAN – Support produit
• Prise en charge de la technologie de commutation LAN
• Support et documentation techniques - Cisco Systems