EN ESTA PÁGINA
El ID de un conmutador miembro desconectado no está disponible para su reasignación
La carga predeterminada de fábrica no se confirma en un chasis virtual de varios miembros
El ID de miembro persiste cuando se desconecta un conmutador miembro de un chasis virtual
Un conmutador miembro no participa en un chasis virtual mixto
Los cambios de configuración relacionados con la interfaz no se aplican después del cambio
Resolución de problemas de un chasis virtual de la serie EX
En este tema se describen los siguientes problemas de solución de problemas para un Virtual Chassis:
El ID de un conmutador miembro desconectado no está disponible para su reasignación
Problema
Descripción
Desconectó un conmutador del Virtual Chassis, pero el ID de miembro del conmutador desconectado sigue apareciendo en la salida de estado. No puede reasignar ese ID de miembro a otro conmutador.
Solución
Cuando se desconecta un miembro de una configuración de Virtual Chassis, la principal conserva el ID de miembro y la configuración de miembro en su base de datos de configuración. El resultado del show virtual-chassis comando continúa mostrando el ID de miembro del miembro desconectado con el estado .NotPrsnt
Si desea desconectar permanentemente el conmutador miembro, puede liberar el ID de miembro mediante el request virtual-chassis recycle comando. Esto también aclarará el estado de ese miembro.
La carga predeterminada de fábrica no se confirma en un chasis virtual de varios miembros
Problema
Descripción
Se load factory-default produce un error en el comando en un Virtual Chassis de varios miembros.
Solución
El load factory-default comando no se admite en una configuración de Virtual Chassis de varios miembros. Para obtener información sobre cómo revertir los conmutadores del Virtual Chassis a la configuración predeterminada de fábrica, consulte Revertir a la configuración predeterminada de fábrica para el conmutador de la serie EX.
El ID de miembro persiste cuando se desconecta un conmutador miembro de un chasis virtual
Problema
Descripción
Las interfaces Gigabit Ethernet conservan sus números de ranura anteriores cuando un conmutador miembro se desconecta del chasis virtual.
Solución
Si un conmutador se había conectado anteriormente como miembro de una configuración de Virtual Chassis, conserva el ID de miembro que se le asignó como miembro de esa configuración, incluso después de desconectarlo y funcionar como conmutador independiente. Las interfaces que se configuraron mientras el conmutador era miembro de la configuración de Virtual Chassis conservan el ID de miembro antiguo como primer dígito del nombre de interfaz.
Por ejemplo, si el conmutador era anteriormente miembro 1, sus interfaces se denominan ge-1/0/0 , etc.
Para cambiar el ID de miembro del conmutador, de modo que su ID de miembro sea 0, y para cambiar el nombre de las interfaces del conmutador en consecuencia:
Para cambiar el ID de miembro a 0:
user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
Para cambiar el nombre de las interfaces para que coincidan con el nuevo ID de miembro:
[edit virtual-chassis] user@switch# replace pattern ge-1/ with ge-0/
Un conmutador miembro no participa en un chasis virtual mixto
Problema
Descripción
Un conmutador miembro en un Virtual Chassis mixto no participa en el Virtual Chassis. El show virtual-chassis resultado indica que el estado del conmutador miembro es Inactive o NotPrsnt.
Este problema es más probable que se produzca inmediatamente después de haber cableado un Virtual Chassis mixto.
Solución
Es posible que el modo de chasis virtual del conmutador no esté configurado en mixed modo. Si el conmutador miembro es un conmutador EX4500 y está cableado al Virtual Chassis a través del puerto Virtual Chassis dedicado (VCP), es posible que el modo PIC también se establezca en Intraconnect en lugar de virtual-chassis.
Para verificar el modo 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
Para cambiar el modo Virtual Chassis en un conmutador miembro (en este caso, ID de miembro 4) al mixed modo:
user@switch> request virtual-chassis mode mixed member 4
(Solo conmutador EX4500) Para verificar el modo 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
Para cambiar el modo PIC en un conmutador EX4500 a virtual-chassis modo (en este caso, ID de miembro 4):
user@switch> request chassis pic-mode virtual-chassis member 4
El conmutador miembro debe reiniciarse para que surta efecto el cambio de configuración del modo Virtual Chassis o del modo PIC. Para reiniciar el conmutador miembro (en este caso, ID de miembro 4):
user@switch> request system reboot member 4
Se produce un bucle de tráfico desconocido después de configurar un puerto de enlace ascendente como VCP redundante con un VCP dedicado
Problema
Descripción
En un chasis virtual compuesto por conmutadores EX4200, EX4500 o EX4550, se observa un bucle irrecuperable de tráfico de unidifusión o multidifusión desconocido tras la adición de un vínculo VCP redundante entre dos conmutadores miembro, cuando los dos miembros están conectados por un vínculo VCP dedicado y el vínculo redundante se creó mediante la conversión de puertos de enlace ascendente en VCP.
Este comportamiento puede producirse si el vínculo VCP redundante se crea estableciendo los puertos manualmente como VCP o si se invoca la característica de conversión automática de VCP y convierte los puertos en VCP automáticamente.
Solución
Reinicie el Virtual Chassis para detectar correctamente el VCP convertido como un vínculo redundante con el enlace VCP dedicado.
Después de la conversión de un puerto de red a un VCP, la tabla de filtros de salida no se actualiza y el VCP redundante permanece habilitado para el reenvío, lo que provoca el comportamiento de bucle. El proceso de reinicio detecta el puerto convertido como VCP y lo muestra como deshabilitado para el reenvío.
Como resultado, no recomendamos conectar puertos VCP de enlace ascendente convertidos redundantes entre miembros ya conectados por VCP dedicados en un Virtual Chassis activo; en su lugar, planee agregar conexiones VCP de enlace ascendente redundantes durante una ventana de mantenimiento que puede incluir un ciclo de reinicio de Virtual Chassis. Esta recomendación también se aplica cuando se agrega un nuevo miembro a un Virtual Chassis activo existente en el que se agregan vínculos VCP redundantes entre el nuevo miembro y uno de sus vecinos que mezclan VCP dedicados y VCP de enlace ascendente convertidos.
Los cambios de configuración relacionados con la interfaz no se aplican después del cambio
Problema
Descripción
Después de un cambio de motor de enrutamiento correcto, la operación de confirmación para los cambios de configuración relacionados con la interfaz se realiza correctamente, pero los cambios de configuración no se aplican. No se generan mensajes de error como parte de la operación de confirmación.
Solución
Cuando se agrega una nueva interfaz miembro a un paquete Ethernet agregado, es posible que se produzca un error en la validación en caso de que la velocidad no coincida entre el paquete y la interfaz miembro nueva. Después de un cambio correcto del motor de enrutamiento, el proceso DCD se cierra al inicio debido a un error de validación. Los cambios de configuración relacionados con la interfaz no se aplican a partir de ese momento.
Compruebe en los registros si hay mensajes de error relacionados con la falta de coincidencia de velocidad entre el paquete Ethernet agregado y la interfaz del nuevo miembro. Si estos errores se producen durante el inicio de DCD, se cierra el proceso de DCD.
Para solucionar este problema:
Quite la interfaz miembro del paquete Ethernet agregado y confirme la configuración.
Reinicie el proceso DCD mediante el
restart interface-controlcomando.Compruebe que el proceso DCD se está ejecutando.