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.
Aucune spécification déterminée n'est requise pour ce document.
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.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
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é.
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.
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
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.
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.
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.
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éfautConvergence 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
01-Dec-2013 |
Première publication |