SUR CETTE PAGE
L'ID d'un membre déconnecté n'est pas disponible pour la réaffectation
Charger la valeur par défaut en usine ne s’applique pas à un virtual Chassis multimembre
L’ID de membre persiste lorsqu’un commutateur membre est déconnecté d’un virtual Chassis
Un commutateur membre ne participe pas à un virtual Chassis mixte
Dépannage d’un châssis virtuel EX Series
Cette rubrique décrit les problèmes de dépannage suivants pour un Virtual Chassis :
L'ID d'un membre déconnecté n'est pas disponible pour la réaffectation
Problème
Description
Vous avez déconnecté un commutateur du virtual Chassis, mais l’ID de membre du commutateur déconnecté s’affiche toujours dans la sortie d’état. Vous ne pouvez pas réaffecter cet ID de membre à un autre commutateur.
Solution
Lorsque vous déconnectez un membre d’une configuration Virtual Chassis, le principal conserve l’ID membre et la configuration des membres dans sa base de données de configuration. La sortie de la show virtual-chassis
commande continue à afficher l’ID de membre du membre déconnecté avec un état de NotPrsnt
.
Si vous souhaitez déconnecter définitivement le commutateur de membre, vous pouvez libérer l’ID de membre à l’aide de la request virtual-chassis recycle
commande. Cela permettra également d’effacer le statut de cet adhérent.
Charger la valeur par défaut en usine ne s’applique pas à un virtual Chassis multimembre
Problème
Description
La load factory-default
commande échoue sur un multimembre Virtual Chassis.
Solution
Cette load factory-default
commande n’est pas prise en charge sur une configuration Virtual Chassis multimembre. Pour savoir comment rétablir les paramètres par défaut définis en usine dans virtual Chassis, reportez-vous à La configuration définie en usine par défaut pour le commutateur EX Series.
L’ID de membre persiste lorsqu’un commutateur membre est déconnecté d’un virtual Chassis
Problème
Description
Les interfaces Gigabit Ethernet conservent leurs numéros d’emplacement précédents lorsqu’un commutateur membre est déconnecté de Virtual Chassis.
Solution
Si un commutateur était précédemment connecté en tant que membre d’une configuration Virtual Chassis, il conserve l’ID de membre qui lui a été attribué en tant que membre de cette configuration, même après avoir été déconnecté et fonctionnant comme un commutateur autonome. Les interfaces configurées alors que le commutateur était membre de la configuration Virtual Chassis conservent l’ancien ID de membre comme premier chiffre du nom de l’interface.
Par exemple, si le commutateur était précédemment membre 1, ses interfaces sont nommées ge-1/0/0
, etc.
Pour modifier l’ID de membre du commutateur, afin que son ID de membre soit 0, et pour renommé les interfaces du commutateur en conséquence :
Pour remplacer l’ID de membre par 0 :
user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
Pour que les interfaces correspondent au nouvel ID de membre :
[edit virtual-chassis] user@switch# replace pattern ge-1/ with ge-0/
Un commutateur membre ne participe pas à un virtual Chassis mixte
Problème
Description
Un commutateur membre d’un Virtual Chassis mixte ne participe pas au Virtual Chassis. La show virtual-chassis
sortie indique l’état Inactive
du commutateur membre ou NotPrsnt
.
Ce problème est plus susceptible de se produire immédiatement après avoir câblé un module Virtual Chassis mixte.
Solution
Le mode Virtual Chassis du commutateur peut ne pas être configuré en mixed
mode. Si le commutateur membre est un commutateur EX4500 et est câblé dans le Virtual Chassis via le port Virtual Chassis dédié (VCP), le mode PIC peut également être configuré à Intraconnect
la place de virtual-chassis
.
Pour vérifier le mode Virtual Chassis :
user@switch> show virtual-chassis mode fpc0: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc1: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc2: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc3: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc4: -------------------------------------------------------------------------- Mixed Mode: Disabled fpc5: -------------------------------------------------------------------------- Mixed Mode: Enabled
Pour modifier le mode Virtual Chassis sur un commutateur membre (dans ce cas, ID de membre 4) en mixed
mode :
user@switch> request virtual-chassis mode mixed member 4
(commutateur EX4500 uniquement) Pour vérifier le mode PIC :
user@switch> show chassis pic-mode fpc0: -------------------------------------------------------------------------- Pic Mode: Not-Applicable fpc1: -------------------------------------------------------------------------- Pic Mode: Not-Applicable fpc2: -------------------------------------------------------------------------- Pic Mode: Not-Applicable fpc3: -------------------------------------------------------------------------- Pic Mode: Not-Applicable fpc4: -------------------------------------------------------------------------- Pic Mode: PIC 3: Intraconnect fpc5: -------------------------------------------------------------------------- Pic Mode: PIC 3: virtual-chassis
Pour changer le mode PIC d’un commutateur virtual-chassis
EX4500 en mode (dans ce cas, ID de membre 4) :
user@switch> request chassis pic-mode virtual-chassis member 4
Le commutateur membre doit être redémarré pour que le mode Virtual Chassis ou le mode PIC changent pour prendre effet. Pour redémarrer le commutateur de membre (dans ce cas, ID de membre 4) :
user@switch> request system reboot member 4
Boucle de trafic inconnue après la configuration d’un port de liaison montante en tant que VCP redondant avec un VCP dédié
Problème
Description
Dans un châssis virtuel composé de commutateurs EX4200, EX4500 ou EX4550, vous observez un looping irrécupérable du trafic unicast ou multicast inconnu suite à l’ajout d’une liaison VCP redondante entre deux commutateurs membres, lorsque les deux membres sont connectés par une liaison VCP dédiée et que la liaison redondante a été créée en convertissant les ports de liaison montante en VCP.
Ce comportement peut se produire si la liaison VCP redondante est créée en définissant les ports manuellement en tant que VCP ou si la fonctionnalité de conversion VCP automatique est invoquée et convertit automatiquement les ports en VCP.
Solution
Redémarrez virtual Chassis pour détecter correctement le VCP converti en tant que liaison redondante avec la liaison VCP dédiée.
Après la conversion d’un port réseau en VCP, la table de filtres de sortie n’est pas mise à jour et le VCP redondant reste activé pour le transfert, ce qui entraîne le comportement de boucle. Le processus de redémarrage détecte le port converti en tant que VCP et le présente comme désactivé pour le transfert.
Il est donc recommandé de ne pas connecter les ports VCP redondants de liaison montante convertis entre les membres déjà connectés par des VCP dédiés sur un Virtual Chassis actif ; prévoyez plutôt d’ajouter des connexions VCP de liaison montante redondantes pendant une période de maintenance pouvant inclure un cycle de redémarrage Virtual Chassis. Cette recommandation s’applique également lors de l’ajout d’un nouveau membre à un module Virtual Chassis actif existant, lorsque vous ajoutez des liaisons VCP redondantes entre le nouveau membre et l’un de ses voisins, qui combinent des VCP dédiés et des VCP de liaison montante convertis.