SUR CETTE PAGE
L'ID d'un commutateur membre déconnecté ne peut pas être réaffecté
L’ID de membre est conservé lorsqu’un commutateur membre est déconnecté d’un Virtual Chassis
Un commutateur membre ne fait pas partie d’un Virtual Chassis mixte
Les modifications de configuration liées à l’interface ne sont pas appliquées après le basculement
Dépannage d’un Virtual Chassis EX Series
Cette rubrique décrit les problèmes de dépannage suivants pour un Virtual Chassis :
L'ID d'un commutateur membre déconnecté ne peut pas être réaffecté
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 serveur principal conserve l’ID de membre et la configuration de membre dans sa base de données de configuration. La sortie de la show virtual-chassis commande continue d’afficher l’ID de membre du membre déconnecté avec l’état .NotPrsnt
Si vous souhaitez déconnecter définitivement le commutateur membre, vous pouvez libérer l’ID de membre à l’aide de la request virtual-chassis recycle commande. Cela effacera également le statut de ce membre.
Le chargement par défaut des paramètres d’usine ne valide pas sur un Virtual Chassis à plusieurs membres
Problème
Description
La load factory-default commande échoue sur un Virtual Chassis à plusieurs membres.
Solution
La load factory-default commande n’est pas prise en charge sur une configuration Virtual Chassis à plusieurs membres. Pour plus d’informations sur la restauration des paramètres d’usine par défaut des commutateurs du Virtual Chassis, reportez-vous à la section Restauration de la configuration d’usine par défaut du commutateur EX Series.
L’ID de membre est conservé lorsqu’un commutateur membre est déconnecté d’un Virtual Chassis
Problème
Description
Les interfaces Gigabit Ethernet conservent leurs anciens numéros d’emplacement lorsqu’un commutateur membre est déconnecté du Virtual Chassis.
Solution
Si un commutateur a déjà été 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 qu’il a été déconnecté et qu’il fonctionne comme un commutateur autonome. Les interfaces qui ont été 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 auparavant membre 1, ses interfaces sont nommées ge-1/0/0 , etc.
Pour modifier l’ID de membre du commutateur, de sorte que son ID de membre soit 0, et pour renommer les interfaces du commutateur en conséquence :
Pour modifier l’ID de membre à 0 :
user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
Pour renommer les interfaces afin qu’elles correspondent au nouvel ID de membre :
[edit virtual-chassis] user@switch# replace pattern ge-1/ with ge-0/
Un commutateur membre ne fait pas partie d’un Virtual Chassis mixte
Problème
Description
Un commutateur membre d’un Virtual Chassis mixte ne fait pas partie du Virtual Chassis. La show virtual-chassis sortie indique que l’état du commutateur membre est Inactive ou NotPrsnt.
Ce problème est plus susceptible de se produire immédiatement après le câblage d’un Virtual Chassis mixte.
Solution
Le mode Virtual Chassis du commutateur n’est peut-être pas réglé sur mixed le mode. Si le commutateur membre est un commutateur EX4500 et qu’il est câblé au Virtual Chassis via le port Virtual Chassis dédié (VCP), le mode PIC peut également être défini sur Intraconnect 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 passer au mode Virtual Chassis d’un commutateur membre (dans ce cas, l’ID de membre 4) :mixed
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 passer en mode PIC sur un commutateur virtual-chassis EX4500 (dans ce cas, l’ID de membre 4) :
user@switch> request chassis pic-mode virtual-chassis member 4
Le commutateur membre doit être redémarré pour que la modification du paramètre du mode Virtual Chassis ou du mode PIC soit prise en compte. Pour redémarrer le commutateur membre (dans ce cas, l’ID de membre 4) :
user@switch> request system reboot member 4
Les modifications de configuration liées à l’interface ne sont pas appliquées après le basculement
Problème
Description
Après un basculement fluide du moteur de routage, l’opération de validation des modifications de configuration liées à l’interface réussit, mais les modifications de configuration ne sont pas appliquées. Aucun message d’erreur n’est généré dans le cadre de l’opération de validation.
Solution
Lorsqu’une nouvelle interface membre est ajoutée à un bundle Ethernet agrégé, la validation peut échouer en cas d’incompatibilité de vitesse entre le bundle et la nouvelle interface membre. Après un basculement fluide du moteur de routage, le processus DCD se termine au démarrage en raison de l’échec de la validation. Aucune modification de configuration liée à l’interface n’est désormais appliquée.
Consultez les journaux pour détecter les messages d’erreur liés à une incompatibilité de vitesse entre le bundle Ethernet agrégé et la nouvelle interface membre. Si ces erreurs se produisent pendant le démarrage du DCD, le processus du DCD se ferme.
Pour résoudre ce problème :
Supprimez l’interface membre mentionnée dans le message d’erreur du bundle Ethernet agrégé et validez la configuration.
Redémarrez le processus DCD à l’aide de la
restart interface-controlcommande.Vérifiez que le processus DCD est en cours d’exécution.