Solució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 de miembro desconectado no está disponible para reasignación
Problema
Descripción
Desconectó un conmutador del Virtual Chassis, pero el ID de miembro del conmutador desconectado aún se muestra en el resultado de estado. No puede reasignar ese ID de miembro a otro conmutador.
Solución
Cuando desconecta un miembro de una configuración de Virtual Chassis, el principal conserva el ID de miembro y la configuración de miembro en su base de datos de configuración. La salida del show virtual-chassis comando sigue mostrando el ID de miembro del miembro desconectado con un estado de NotPrsnt.
Si desea desconectar permanentemente el conmutador de miembro, puede liberar el ID de miembro mediante el request virtual-chassis recycle comando. Esto también borrará el estado de ese miembro.
El valor predeterminado de la fábrica de carga no se confirma en un chasis virtual de varios miembros
Problema
Descripción
El load factory-default comando falla en un chasis virtual 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 de fábrica predeterminada para el conmutador de la serie EX.
El ID de miembro persiste cuando un conmutador de miembro se desconecta 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 Virtual Chassis.
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 el primer dígito del nombre de interfaz.
Por ejemplo, si el conmutador fue anteriormente miembro 1, sus interfaces se denominan ge-1/0/0 y así sucesivamente.
Para cambiar el ID de miembro del conmutador, de modo que su ID de miembro sea 0, y 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.
Es muy probable que este problema ocurra inmediatamente después de haber cableado un chasis virtual mixto.
Solución
Es posible que el modo Virtual Chassis del conmutador no se establezca mixed en modo. Si el conmutador miembro es un conmutador EX4500 y se cablea en el Virtual Chassis mediante el puerto virtual dedicado (VCP), el modo PIC también se puede establecer en Intraconnect lugar de virtual-chassis.
Para comprobar 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 comprobar 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 al 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 el cambio de configuración del modo Virtual Chassis o pic tenga efecto. Para reiniciar el conmutador miembro (en este caso, ID de miembro 4):
user@switch> request system reboot member 4
El bucle de tráfico desconocido se produce después de configurar un puerto de enlace ascendente como un VCP redundante con un VCP dedicado
Problema
Descripción
En un Virtual Chassis compuesto por conmutadores EX4200, EX4500 o EX4550, 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 mediante un vínculo VCP dedicado y el vínculo redundante se creó convirtiendo puertos de enlace ascendente en VCP.
Este comportamiento puede ocurrir si el vínculo VCP redundante se crea estableciendo los puertos manualmente como VCP o si se invoca la función 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 vínculo VCP dedicado.
Después de la conversión de un puerto de red a un VCP, la tabla de filtro de salida no se actualiza y el VCP redundante permanece habilitado para el reenvío, lo que provoca el comportamiento del bucle. El proceso de reinicio detecta el puerto convertido como VCP y lo activa 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 del 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 VCPs de enlace ascendente convertidos.