Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Solución de problemas de agregación de vínculos de múltiples chasises

Utilice la siguiente información para solucionar problemas de configuración de agregación de vínculos multichasis:

Las direcciones MAC aprendidas en interfaces Ethernet agregadas de múltiples chasis no se eliminan de la tabla de direcciones MAC

Problema

Descripción

Cuando las dos interfaces Ethernet agregadas de multichasis en los dos pares del grupo de agregación de vínculos multichasis (MC-LAG) conectados están inactivas, las direcciones MAC aprendidas en las interfaces Ethernet agregadas de multichasis no se eliminan de la tabla de direcciones MAC.

Por ejemplo, si deshabilita la interfaz Ethernet agregada multichasis (ae0) en ambos pares MC-LAG mediante la ejecución del set interfaces ae0 disable comando y confirma la configuración, la tabla MAC seguirá mostrando las direcciones MAC como aprendidas en las interfaces Ethernet agregadas multichasis de ambos pares MC-LAG.

Solución

Este es el comportamiento esperado.

El par MC-LAG no entra en modo de espera

Problema

Descripción

Un par del grupo de agregación de vínculos multichasis (MC-LAG) no entra en modo de espera si la dirección IP del par MC-LAG especificada en la configuración del Protocolo de control entre chasis (ICCP) y la dirección IP especificada en la configuración de protección multichasis son diferentes.

Solución

Para evitar que no se pueda entrar en el modo de espera, asegúrese de que la dirección IP del par en las configuraciones de ICCP y la dirección IP en las configuraciones de protección de multichasis sean las mismas.

El par MC-LAG secundario con el control de estado establecido en espera se vuelve inactivo

Problema

Descripción

Cuando el vínculo de protección de vínculos de control de interchasis (ICL-PL) y las interfaces Ethernet agregadas de multichasis dejan de funcionar en el par principal del grupo de agregación de vínculos de varios chasis (MC-LAG), las interfaces Ethernet agregadas de multichasis del par MC-LAG secundario con control de estado establecido en modo de espera se vuelven inactivas en lugar de activas.

Solución

Este es el comportamiento esperado.

Los filtros de redireccionamiento tienen prioridad sobre los filtros definidos por el usuario

Problema

Descripción

Grupo de agregación de vínculos de múltiples chasis (MC-LAG) Los filtros de redirección implícita de tolerancia a fallos tienen prioridad sobre los filtros explícitos configurados por el usuario.

Solución

Este es el comportamiento esperado.

El resultado del comando operativo es incorrecto

Problema

Descripción

Después de desactivar el protocolo de control entre chasis (ICCP), la salida del show iccp comando operativo sigue mostrando demonios de cliente registrados, como mcsnoopd, lacpd y eswd.

Por ejemplo:

La show iccp salida del comando siempre muestra los módulos registrados, independientemente de si están configurados o no los pares ICCP.

Solución

Este es el comportamiento esperado.

La conexión ICCP puede tardar hasta 60 segundos en activarse

Problema

Descripción

Cuando la configuración del protocolo de control entre chasis (ICCP) y la configuración de la interfaz de VLAN enrutada (RVI) se confirman juntas, la conexión ICCP puede tardar hasta 60 segundos en activarse.

Solución

Este es el comportamiento esperado.

La antigüedad de la dirección MAC aprendida en una interfaz Ethernet agregada de varios chasis se restablece a cero

Problema

Descripción

Cuando activa y, luego, desactiva un vínculo de protección de vínculos de interchasis (ICL-PL), la antigüedad de la dirección MAC aprendida en la interfaz Ethernet agregada de múltiples chasis se restablece a cero. Los cambios en la interfaz del siguiente salto activan actualizaciones de la dirección MAC en el hardware, que a su vez desencadenan actualizaciones de antigüedad en el motor de reenvío de paquetes. El resultado es que la antigüedad de la dirección MAC se actualiza a cero.

Por ejemplo, la ICL-PL se ha desactivado y el resultado del show ethernet-switching table comando muestra que las direcciones MAC tienen una antigüedad de 0.

Solución

Este es el comportamiento esperado.

La dirección MAC no se aprende de forma remota en una VLAN predeterminada

Problema

Descripción

Solución

Este es el comportamiento esperado.

Las entradas de espionaje aprendidas en interfaces Ethernet agregadas de múltiples chasis no se eliminan

Problema

Descripción

Cuando se configuran interfaces Ethernet agregadas de varios chasis en una VLAN habilitada para la supervisión de multidifusión, las entradas de pertenencia aprendidas en las interfaces Ethernet agregadas de varios chasis en la VLAN no se borran cuando las interfaces de Ethernet agregadas de varios chasis dejan de funcionar. Esto se hace para acelerar el tiempo de convergencia cuando las interfaces suben o suben y bajan.

Solución

Este es el comportamiento esperado.

El ICCP no aparece después de agregar o eliminar una clave de autenticación

Problema

Descripción

La conexión entre chasis (ICCP) no se establece cuando se agrega una clave de autenticación y, luego, se elimina solo en el nivel global de ICCP. Sin embargo, la autenticación funciona correctamente en el nivel del par ICCP.

Solución

Elimine la configuración de ICCP y, luego, agregue la configuración de ICCP.

El estado local es en espera cuando debería estar activo

Problema

Descripción

Si la interfaz Ethernet agregada de varios chasis está inactiva cuando la máquina de estado está en un estado sincronizado, el estado local del par del grupo de agregación de vínculos de varios chasis (MC-LAG) está en espera. Si la interfaz Ethernet agregada de varios chasis desactiva después de que la máquina de estado esté activa, el estado local permanece activo y el estado local indica que la interfaz está inactiva.

Solución

Este es el comportamiento esperado.

Los paquetes se enrollan en el servidor cuando se produce un error en el ICCP

Problema

Descripción

Cuando se habilita la detección de ejecución de copia de seguridad para un grupo de agregación de vínculos de varios chasis (MC-LAG) y los paquetes de detección de ejecución de copia de seguridad se pierden debido a un fallo temporal en el MC-LAG, ambos pares del MC-LAG permanecen activos. Si esto sucede, ambos pares de MC-LAG envían paquetes al servidor conectado.

Solución

Este es el comportamiento esperado.

Ambos pares MC-LAG utilizan el ID del sistema predeterminado después de un reinicio o un cambio de configuración de ICCP

Problema

Descripción

Después de un reinicio o después de que se haya confirmado una nueva configuración del protocolo de control entre chasis (ICCP) y la conexión ICCP no se active, los mensajes del protocolo de control de agregación de vínculos (LACP) transmitidos a través de las interfaces Ethernet agregadas de varios chasis utilizan el ID del sistema predeterminado. El ID del sistema configurado se utiliza en lugar del ID del sistema predeterminado solo después de que los pares MC-LAG se sincronicen entre sí.

Solución

Este es el comportamiento esperado.

No se realizan comprobaciones de confirmación para las interfaces ICL-PL

Problema

Descripción

No hay comprobaciones de confirmación en la interfaz que se configura como un vínculo de protección de vínculos de interchasis (ICL-PL), por lo que debe proporcionar un nombre de interfaz válido para ICL-PL.

Solución

Este es el comportamiento esperado.

Escenario de doble conmutación por error

Problema

Descripción

Si los siguientes eventos ocurren exactamente en este orden (el protocolo de control entre chasis (ICCP) deja de funcionar y la interfaz Ethernet agregada de varios chasis en el par del grupo de agregación de vínculos de varios chasis (MC-LAG) en modo activo deja de funcionar, se produce una doble tolerancia a fallos. En este caso, el par MC-LAG en modo de espera no detecta lo que sucede en el par MC-LAG activo. El par MC-LAG en modo de espera funciona como si la interfaz Ethernet agregada de múltiples chasis en el MC-LAG en modo activo estuviera activa y bloquea el tráfico del vínculo de protección de vínculos de interchasis (ICL-PL). El tráfico ICL-PL no se reenvía.

Solución

Este es el comportamiento esperado.

El tráfico de multidifusión inunda la VLAN cuando la interfaz ICL-PL desciende y sube

Problema

Descripción

Cuando el vínculo de protección de vínculos de interchasis (ICL-PL) deja de funcionar y sube, el tráfico de multidifusión se inunda a todas las interfaces de la VLAN. El indicador de motor de reenvío de paquetes Ip4McastFloodMode para la VLAN se cambia a MCAST_FLOOD_ALL. Este problema solo se produce cuando se configura un grupo de agregación de vínculos de varios chasis (MC-LAG) para la capa 2.

Solución

Este es el comportamiento esperado.

El tráfico de capa 3 enviado al par MC-LAG en espera no se redirige al par MC-LAG activo

Problema

Descripción

Cuando el protocolo de control entre chasis (ICCP) está inactivo, se desconoce el estado de un par MC-LAG remoto. Incluso si el par MC-LAG está configurado como en espera, el tráfico no se redirige a este par porque se supone que este par está inactivo.

Solución

Este es el comportamiento esperado.

Las interfaces Ethernet agregadas desactivan

Problema

Descripción

Cuando una interfaz Ethernet agregada de varios chasis se convierte en una interfaz Ethernet agregada, conserva algunas propiedades de interfaz Ethernet agregada de varios chasis. Por ejemplo, la interfaz Ethernet agregada podría conservar la clave administrativa de la interfaz Ethernet agregada de varios chasis. Cuando esto sucede, la interfaz Ethernet agregada deja de funcionar.

Solución

Reinicie el Protocolo de control de agregación de vínculos (LACP) en el par del grupo de agregación de vínculos de varios chasis (MC-LAG) que aloja la interfaz de Ethernet agregada para abrir la interfaz de Ethernet agregada. Reiniciar LACP elimina las propiedades de Ethernet agregadas de multichasis de la interfaz de Ethernet agregada.

Inundación del tráfico aguas arriba

Problema

Descripción

Cuando la sincronización MAC está habilitada, el par del grupo de agregación de vínculos multichasis (MC-LAG) puede resolver las entradas del Protocolo de resolución de direcciones (ARP) para la interfaz de VLAN enrutada (RVI) de MC-LAG con cualquiera de las direcciones MAC del par MC-LAG. Si el tráfico descendente se envía con una dirección MAC (MAC1), pero el par resolvió la dirección MAC con una dirección MAC diferente (MAC2), es posible que ninguno de los conmutadores de capa de acceso aprenda la dirección MAC2. Entonces podría producirse una inundación del tráfico ascendente para la dirección MAC2.

Solución

Asegúrese de que el tráfico descendente se envíe periódicamente desde los pares MC-LAG para evitar que las direcciones MAC se agoten.

Las entradas de la tabla ARP y MAC no están sincronizadas en una configuración MC-LAG

Problema

Descripción

Las tablas ARP y de dirección MAC en una configuración MC-LAG normalmente permanecen sincronizadas, pero las actualizaciones pueden perderse en situaciones extremas cuando las actualizaciones de tabla ocurren con mucha frecuencia, como cuando se produce una oscilación de vínculos en un grupo MC-LAG.

Solución

Para evitar que las entradas ARP y MAC desincronizen una configuración MC-LAG, puede configurar la opción arp-l2-validate en la interfaz IRB del conmutador de la siguiente manera:

Esta arp-l2-validate opción solo está disponible en conmutadores de la serie QFX.

Esta opción activa la validación de las entradas de tabla ARP y MAC, aplicando automáticamente las actualizaciones si no están sincronizadas. Es posible que desee habilitar esta opción como solución alternativa cuando la red experimente otros problemas que también provoquen la pérdida de la sincronización de ARP y MAC, pero desactívela durante el funcionamiento normal, ya que esta opción podría afectar al rendimiento en las configuraciones de escala.