EN ESTA PÁGINA
Los filtros de redireccionamiento tienen prioridad sobre los filtros definidos por el usuario
La conexión ICCP puede tardar hasta 60 segundos en activarse
La dirección MAC no se aprende de forma remota en una VLAN predeterminada
Las entradas de espionaje aprendidas en interfaces Ethernet agregadas multichasis no se eliminan
ICCP no aparece después de agregar o eliminar una clave de autenticación
Los paquetes se conectan en bucle en el servidor cuando se produce un error en ICCP
No se realizan comprobaciones de confirmación para las interfaces ICL-PL
El tráfico de multidifusión inunda la VLAN cuando la interfaz ICL-PL se cae y sube
El tráfico de capa 3 enviado al par MC-LAG en espera no se redirige al par MC-LAG activo
Las entradas de tabla ARP y MAC dejan de estar sincronizadas en una configuración MC-LAG
Solución de problemas de agregación de vínculos multichasis
Utilice la siguiente información para solucionar problemas de configuración de agregación de vínculos multichasis:
Las direcciones MAC aprendidas en las interfaces Ethernet agregadas de varios chasis no se eliminan de la tabla de direcciones MAC
Problema
Descripción
Cuando las dos interfaces Ethernet agregadas de mulitchassis en ambos pares del grupo de agregación de vínculos multichasis conectados (MC-LAG) están inactivas, las direcciones MAC aprendidas en las interfaces Ethernet agregadas multichasis no se eliminan de la tabla de direcciones MAC.
Por ejemplo, si deshabilita la interfaz Ethernet agregada (ae0) de varios chasis en ambos pares MC-LAG emitiendo el set interfaces ae0 disable
comando y confirmando la configuración, la tabla MAC seguirá mostrando las direcciones MAC como aprendidas en las interfaces Ethernet agregadas multichasis de ambos pares MC-LAG.
user@switchA> show ethernet-switching table Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:00:5E:00:53:00 Learn(L) 3:55 ae0.0 (MCAE) v10 00:00:5E:00:53:01 Learn(R) 0 xe-0/0/9.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:03 Static - Router
user@switchB> show ethernet-switching table Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:00:5E:00:53:04 Learn(R) 0 ae0.0 (MCAE) v10 00:00:5E:00:53:05 Learn 40 xe-0/0/10.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:06 Static - Router
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 de varios chasis (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 mismo nivel en las configuraciones de ICCP y la dirección IP en las configuraciones de protección multichasis sean las mismas.
El par secundario de MC-LAG con el control de estado establecido en modo de espera se vuelve inactivo
Problema
Descripción
Cuando el vínculo de protección de vínculos de control entre chasis (ICL-PL) y las interfaces Ethernet agregadas de varios chasis dejan de funcionar en el par principal del grupo de agregación de vínculos de varios chasis (MC-LAG), las interfaces Ethernet agregadas multichasis del par secundario de MC-LAG 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
El resultado del comando operativo es incorrecto
Problema
Descripción
Después de desactivar el protocolo de control entre chasis (ICCP), el resultado del show iccp
comando operativo sigue mostrando demonios de cliente registrados, como mcsnoopd, lacpd y eswd.
Por ejemplo:
user@switch> show iccp Client Application: MCSNOOPD Redundancy Group IDs Joined: None Client Application: lacpd Redundancy Group IDs Joined: 1 Client Application: eswd Redundancy Group IDs Joined: 1
El show iccp
resultado del comando siempre muestra los módulos registrados, independientemente de si los pares ICCP están configurados o no.
Solución
Este es el comportamiento esperado.
La conexión ICCP puede tardar hasta 60 segundos en activarse
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, a continuación, desactiva un vínculo de protección de vínculo entre chasis (ICL-PL), la antigüedad de la dirección MAC aprendida en la interfaz Ethernet agregada multichasis se restablece a cero. Los cambios en la interfaz del salto siguiente desencadenan actualizaciones de dirección MAC en el hardware, que luego desencadenan actualizaciones antiguas 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 la salida del show ethernet-switching table
comando muestra que las direcciones MAC tienen una antigüedad de 0.
user@switch> show ethernet-switching table Ethernet-switching table: 3 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v100 * Flood - All-members v100 00:10:00:00:00:01 Learn(L) 0 ae0.0 (MCAE) v100 00:10:00:00:00:02 Learn(L) 0 ae0.0 (MCAE)
Solución
Este es el comportamiento esperado.
La dirección MAC no se aprende de forma remota en una VLAN predeterminada
Problema
Descripción
En un conmutador QFX3500 que ejecute Junos OS versión 12.3 o anterior, si un par de grupo de agregación de vínculos multichasis (MC-LAG) aprende una dirección MAC en la VLAN predeterminada, el Protocolo de control entre chasis (ICCP) no sincroniza la dirección MAC con la dirección MAC del otro par MC-LAG.
Solución
Este es el comportamiento esperado.
Las entradas de espionaje aprendidas en interfaces Ethernet agregadas multichasis 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 Ethernet agregadas de multichasis 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.
ICCP no aparece después de agregar o eliminar una clave de autenticación
Problema
Descripción
La conexión del protocolo de control entre chasis (ICCP) no se establece cuando se agrega una clave de autenticación y, a continuación, eliminarla sólo en el nivel ICCP global. Sin embargo, la autenticación funciona correctamente en el nivel del mismo nivel del ICCP.
Solución
Elimine la configuración de ICCP y, a continuación, 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 multichasis está inactiva cuando la máquina de estado está sincronizada, el estado local del par del grupo de agregación de vínculos multichasis (MC-LAG) es en espera. Si la interfaz Ethernet agregada multichasis deja de funcionar después de que el equipo de estado esté en estado activo, 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 conectan en bucle en el servidor cuando se produce un error en ICCP
Problema
Descripción
Cuando se habilita la detección de vida 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 vida de copia de seguridad se pierden debido a un error temporal en MC-LAG, ambos pares del MC-LAG permanecen activos. Si esto sucede, ambos pares MC-LAG envían paquetes al servidor conectado.
Solución
Este es el comportamiento esperado.
Ambos pares MC-LAG utilizan el ID de sistema predeterminado después de un reinicio o un cambio en la 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 de sistema predeterminado. El ID de sistema configurado se utiliza en lugar del ID de 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
Escenario de doble conmutación por error
Problema
Descripción
Si los siguientes eventos ocurren en este orden exacto (el protocolo de control entre chasis (ICCP) deja de funcionar y la interfaz Ethernet agregada multichasis en el par del grupo de agregación de vínculos multichasis (MC-LAG) en modo activo deja de funcionar), se produce una doble conmutación por error. En este escenario, 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 multichasis en el MC-LAG en modo activo estuviera activa y bloquea el tráfico del vínculo de protección de vínculos entre chasis (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 se cae y sube
Problema
Descripción
Cuando el vínculo de protección de vínculos entre chasis (ICL-PL) deja de funcionar y aparece, el tráfico de multidifusión se inunda a todas las interfaces de la VLAN. El indicador del motor de reenvío de paquetes Ip4McastFloodMode para la VLAN se cambia a MCAST_FLOOD_ALL. Este problema sólo se produce cuando un grupo de agregación de vínculos multichasis (MC-LAG) está configurado 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 dejan de funcionar
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 Ethernet agregada para abrir la interfaz Ethernet agregada. Al reiniciar LACP, se eliminan las propiedades Ethernet agregadas de varios chasis de la interfaz Ethernet agregada.
Inundación del tráfico ascendente
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 entradas del Protocolo de resolución de direcciones (ARP) para la interfaz 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 ha resuelto la dirección MAC con una dirección MAC diferente (MAC2), es posible que ninguno de los conmutadores de la capa de acceso aprenda la dirección MAC2. A continuación, 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ía periódicamente desde los pares MC-LAG para evitar que las direcciones MAC caducen.
Las entradas de tabla ARP y MAC dejan de estar sincronizadas en una configuración MC-LAG
Problema
Descripción
Las tablas de direcciones ARP y 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 aleteo de vínculos en un grupo MC-LAG.
Solución
Para evitar que las entradas ARP y MAC no estén sincronizadas en una configuración MC-LAG, puede configurar la opción arp-l2-validate en la interfaz IRB del conmutador de la siguiente manera:
user@switch> set interfaces irb arp-l2-validate
La arp-l2-validate
opción solo está disponible en conmutadores de la serie QFX y conmutadores EX4300 a partir de Junos OS versión 15.1R4 y conmutadores EX9200 a partir de Junos OS versión 13.2R4.
Esta opción activa la validación de las entradas de la 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 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.