Présentation de la technologie de stacking Juniper : Virtual Chassis

Les commutateurs de la gamme EX offrent la possibilité de s’empiler logiquement pour être vu tel un chassis unique; cette technologie permet une flexibilité et une évolutivité du chassis. Les ports virutal chassis (VCP) permettent de connecter les commutateurs membres et sont chargés de transmettre toutes les données et de contrôler le trafic entre les commutateurs membres.

Avantages du Virtual Chassis

• Simplifie la configuration et la maintenance: Plusieurs équipements peuvent être gérés comme un seul et même équipement avec les mêmes fonctionnalités ou capacités similaires que les équipements autonomes.
• Augmente la tolérance de panne et la haute disponibilité: Un virtual chassis peut rester actif et le trafic réseau peut être redirigé vers d’autres commutateurs membres lorsqu’un commutateur tombe en panne.
• Stabilise votre réseau et réduit les coûts de mise en réseau en permettant aux équipements réseau de se synchroniser vers un seul équipement logique résilient plutôt qu’avec plusieurs équipements physiques.
• Permet de mettre en place une topologie de réseau de couche 2 simplifiée qui limite ou élimine le besoin de protocoles de prévention en boucle, comme le protocole STP (Spanning Tree Protocol).
• Fournit un modèle flexible pour développer votre réseau: vous pouvez facilement ajouter des commutateurs membres Virtual Chassis (jusqu’à 10 membres par VC) afin d’augmenter le nombre de ports d’accès sur votre réseau afin de prendre en charge un plus grand nombre de serveurs, ordinateurs, téléphones ou autres équipements avec un minimum de complications à la topologie de réseau et à la configuration des commutateurs existants.

Connexion des commutateurs membres avec des ports Virtual Chassis

Le châssis virtuel ne reconnaît pas un commutateur membre tant qu’il n’est pas interconnecté avec le commutateur principal ou interconnecté avec un membre existant du virtual chassis à l’aide de VCP. Les commutateurs EX Series qui peuvent se trouver dans un virtual chassis peuvent prendre en charge une ou plusieurs des options VCP suivantes:

• Des VCP dédiés, des ports qui ne peuvent fonctionner que comme des VCP. Seuls quelques commutateurs ont des VCP dédiés.
• Ports configurés en tant que VCP dans les paramètres d’usine par défaut. Ces ports peuvent également être convertis et utilisés comme ports réseau au lieu d’être des VCP, puis les convertir en VCP si nécessaire.

Lorsqu’un port est définit comme un VCP, il ne peut pas être utilisé à d’autres fins. Si vous souhaitez utiliser le port à un autre usage, vous devez supprimer les paramètres VCP à l’aide de la request virtual-chassis vc-port commande. Vous pouvez exécuter cette commande directement sur le membre dont le paramètre VCP de liaison est à supprimer ou via le membre principal de la configuration Virtual Chassis.

La gamme EX compatible Virtual Chassis

Dans un châssis virtuel EX Series, vous pouvez interconnecter les commutateurs dans les combinaisons suivantes en un seul équipement logique et gérer l’équipement logique comme un châssis unique:

• EX2300, qui comprend jusqu’à quatre commutateurs EX2300 ou quatre commutateurs EX2300 multi-igabit (EX2300-24MP, EX2300-48MP) par VC. À partir de Junos OS version 18.4R1, vous pouvez également combiner les commutateurs de modèles multi-gigabit EX2300 avec les autres commutateurs EX2300 du même Virtual Chassis, qui fonctionne comme un Virtual Chassis non mixte. Sur les commutateurs EX2300, l’utilisation de la fonctionnalité Virtual Chassis nécessite une licence.
• EX3400, qui comprend jusqu’à dix commutateurs par VC.
• EX4300, comprenant jusqu’à dix commutateurs par VC, dont des modèles multi-gigabit (EX4300-48MP). Un commutateur EX4300 Virtual Chassis fonctionne comme un châssis virtuel non mixte s’il se compose uniquement de commutateurs ex4300 multi-gigabit ou de toute combinaison d’autres commutateurs EX4300 à l’exception des modèles multi-gigabit. Un commutateur EX4300 Virtual Chassis fonctionne comme un commutateur Virtual Chassis mixte EX4300 s’il est formé de commutateurs ex4300 multi-gigabit (EX4300-48MP) et de tout autre commutateur ex4300.
• EX4400, qui comprend jusqu’à dix commutateurs par VC.
• EX4600, qui comprend jusqu’à dix commutateurs par VC.
• EX4650, qui comprend jusqu’à quatre commutateurs par VC depuis Junos 20.1R1.

Câblage d’un Virtual Chassis

Il existe plusieurs manière d’effectuer le câblage des ports VCP dans une topologie ring.

Option 1 : En utilisant des câbles DAC court et long

Option 2 : En utilisant des câbles DAC court et long

Option 3 : En utilisant des câbles DAC court et moyen

Rôle de Routing Engine (RE)

Dans une Virtual Chassis, chaque commutateur membre joue l’un des deux rôles, routing engine (RE) ou de carte de ligne (Linecard).

Le routing engine principal (RE) dans le Virtual Chassis:

• Gère les commutateurs membres.
• Exécute les processus de gestion du châssis et les protocoles de contrôle.
• Représente tous les commutateurs membres interconnectés dans la configuration Virtual Chassis réseau. (Le nom d’hôte et les autres propriétés que vous attribuez à ce commutateur lors de la configuration s’appliquent à tous les Virtual Chassis configuration.)

Dans une configuration préprovisionée, on peut définir le rôle des différents membres RE ou Linecard.

Dans une configuration non préprovisionée, le Virtual Chassis sélectionne la RE et les linescard en utilisant la valeur de priorité du rôle principal et les facteurs secondaires dans l’algorithme de choix du rôle principal.

Rôle de Backup

Le membre qui fonctionne dans le rôle de backup dans un Virtual Chassis:

• Maintient un état de préparation à prendre le rôle principal moteur de routage en cas de échec du RE.
• Synchronise avec les principaux en termes d’états de protocole, de tables de communication et d’autres informations, afin qu’il soit prêt à conserver les informations de routage et à maintenir la connectivité du réseau sans interruption en cas d’indisponibilité du principal.

La Virtual Chassis doit avoir au moins deux commutateurs membres pour avoir un membre backup. Si un VC est composé de deux membres, il existe une subtilité; il faut indiquer la commande set virtual-chassis no-split-detection afin de forcer l’algorithme à ne pas éteindre la commutation du membre master quand le backup tombe en panne.

Rôle de linecard

Membre qui joue le rôle de carte de ligne dans un Virtual Chassis:

• Exécute uniquement un sous-ensemble de Junos OS.
• N’exécute pas les protocoles de contrôle du châssis.
• Peut détecter certaines conditions d’erreur (telles qu’un câble non branché) sur n’importe quelle interface qui y a été configurée par le biais de la principale.

La Virtual Chassis doit comporter au moins trois membres pour inclure un membre linecard.

Dans une configuration préprovisionée, vous pouvez configurer un membre avec le rôle de carte de ligne, ce qui signifie qu’il ne peut pas être un membre RE.

Dans une configuration non-préprovisionée, les membres non sélectionnés comme membres principaux ou de secours fonctionnent comme membres de cartes de ligne du Virtual Chassis. Le Virtual Chassis choisit les commutateurs membres principaux et de secours en utilisant la valeur de priorité principale du rôle et les facteurs secondaires dans l’algorithme de choix du rôle principal. Un commutateur avec une priorité primaire de 0 est toujours dans le rôle de carte de ligne.

Configuration d’un Virtual Chassis

no-split-detection

Seulement à appliquer quand un VC est composé de deux membres.

set virtual-chassis no-split-detection

GRES

Graceful Routing Engine Switchover (GRES) est une fonctionnalité de Junos permettant à un commutateur possédant deux RE de continuer de transmettre les paquets, même si une RE tombe en panne. GRES préserve les informations des interfaces et du kernel, le trafic n’est pas interrompu toutefois le GRES ne préserve pas le controle plane. Pour préserver le routage pendant un switchover, GRES doit être combiner avec NSR (Nonstop active routing).

Le processus de préparation au basculement du GRES est le suivant:

1. La RE démarre.
2. Les processus de la plate-forme de routage (comme le processus de châssis [chassisd]) démarre.
3. Le PFE démarre et se connecte au RE.
4. Toutes les informations d’état sont mises à jour dans le système.
5. Le membre backup démarre.
6. Le système détermine si le système GRES a été activé.
7. Le processus de synchronisation du kernel (ksyncd) synchronise le membre backup avec la RE.
8. Une fois la synchronisation terminée, ksyncd met à jour toutes les informations d’état et la table de forwarding.

set chassis redundancy graceful-switchover

NSR

Nonstop active routing (NSR) utilise la même infrastructure que le GRES pour préserver les informations des interfaces et du kernel. Toutefois il permet de synchroniser les informations de routage en effectuant une sauvegarde (de la rpd) sur le membre backup.

set routing-options nonstop-routing

NSB

Nonstop Bridging (NSB) utilise la même infrastructure que le GRES pour préserver les informations des interfaces et du kernel. Toutefois il permet de sauvegarder les informations Layer 2 Control Protocol (L2CP) en faisant tourner le Layer 2 Control Process (l2cpd) sur le membre backup.

set protocols layer2-control nonstop-bridging

Source

Virtual Chassis Cabling Configuration Examples – Complete Hardware Guide for EX 3200 and EX 4200 Switches (juniper.net)

Configuring Nonstop Bridging – TechLibrary – Juniper Networks

Configuring Nonstop Bridging on EX Series Switches (CLI Procedure) – TechLibrary – Juniper Networks

Virtual Chassis Overview for Switches – TechLibrary – Juniper Networks