Conceptos avanzados de MC-LAG

Beneficios de la sincronización de la configuración

La sincronización de configuraciones le permite propagar, sincronizar y confirmar configuraciones de un dispositivo a otro. Puede iniciar sesión en cualquiera de esos dispositivos para administrar todos los dispositivos, teniendo así un único punto de administración.

Cómo funciona la sincronización de configuración

Utilice grupos de configuración para simplificar el proceso de configuración. Por ejemplo, puede crear un grupo de configuración para el dispositivo local, uno o más para los dispositivos remotos y uno para la configuración global, que es esencialmente una configuración común a todos los dispositivos.

Además, puede crear grupos condicionales para especificar cuándo se sincroniza una configuración con otro dispositivo. Puede habilitar la peers-synchronize instrucción en la [edit system commit] jerarquía para sincronizar las configuraciones y confirmaciones en todos los dispositivos de forma predeterminada. NETCONF sobre SSH proporciona una conexión segura entre los dispositivos, y el Protocolo de copia segura (SCP) copia las configuraciones de forma segura entre ellos.

Cómo habilitar la sincronización de configuración

Para habilitar la sincronización de la configuración, realice los pasos siguientes:

1. Asigne estáticamente el dispositivo local a los dispositivos remotos.

2. Cree grupos de configuración para configuraciones locales, remotas y globales.

3. Crear grupos condicionales.

4. Crear grupos de aplicación.

5. Habilite NETCONF sobre SSH.

6. Configure los detalles del dispositivo y los detalles de autenticación de usuario para la sincronización de la configuración.

7. Habilite la peers-synchronize instrucción o emita el commit peers-synchronize comando para sincronizar y confirmar las configuraciones entre dispositivos locales y remotos.

Cómo se admite la sincronización de configuración

En los enrutadores de la serie MX y Junos Fusion, la compatibilidad con la sincronización de la configuración comenzó con Junos OS versión 14.2R6. En los conmutadores de la serie QFX, la compatibilidad con la sincronización de la configuración comenzó con Junos OS versión 15.1X53-D60.

Grupos de configuración para configuraciones locales, remotas y globales

Puede crear grupos de configuración para configuraciones locales, remotas y globales. El dispositivo local usa un grupo de configuración local, el dispositivo remoto usa un grupo de configuración remoto y un grupo de configuración global entre los dispositivos local y remoto.

Por ejemplo, podría crear un grupo de configuración local denominado Grupo A, que incluiría la configuración utilizada por el dispositivo local (conmutador A), un grupo de configuración remoto denominado Grupo B, que incluiría la configuración utilizada por los dispositivos remotos (conmutador B, conmutador C y conmutador D) y un grupo de configuración global denominado Grupo C, que incluiría la configuración común a todos los dispositivos.

Crear grupos de configuración en el nivel jerárquico [edit groups] .

Creación de grupos condicionales para determinados dispositivos

Puede crear grupos condicionales para especificar cuándo se debe aplicar una configuración determinada a un dispositivo. Si desea aplicar la configuración global a todos los dispositivos en una configuración de cuatro dispositivos, por ejemplo, habilite la when peers [<name of local peer> <name of remote peer> <name of remote peer> <name of remote peer>] instrucción en el nivel de [edit groups] jerarquía. Si, por ejemplo, desea aplicar la configuración global (Grupo C) a los dispositivos locales y remotos (conmutador A, conmutador B, conmutador C y conmutador D), puede ejecutar el set groups Group C when peers [Switch A Switch B Switch C Switch D] comando.

Aplicación de grupos de configuración

Para aplicar grupos de configuración, habilite la apply-groups instrucción en el nivel de [edit] jerarquía. Por ejemplo, para aplicar el grupo de configuración local (Grupo A, por ejemplo), el grupo de configuración remota (Grupo B, por ejemplo) y el grupo de configuración global (Grupo C, por ejemplo), ejecute el set apply-groups [ GroupA GroupB GroupC ] comando.

Detalles de configuración del dispositivo para la sincronización de la configuración

Para sincronizar configuraciones entre dispositivos, debe configurar el nombre de host o la dirección IP, el nombre de usuario y la contraseña de los dispositivos remotos. Para ello, emita el set peers <hostname-of-remote-peer> user <name-of-user> authentication <plain-text-password-string> comando en la [edit system commit] jerarquía del dispositivo local.

Por ejemplo, para sincronizar una configuración del conmutador A al conmutador B, ejecute el comando en el set peers SwitchB user administrator authentication test123 conmutador A.

También debe asignar estáticamente el dispositivo local a los dispositivos remotos. Para ello, emita el set system commit peers

Por ejemplo, para sincronizar una configuración del conmutador A al conmutador B, al conmutador C y al conmutador D, configure lo siguiente en el conmutador A:

Conmutador A

Si solo desea sincronizar configuraciones del conmutador A al conmutador B, al conmutador C y al conmutador D, no necesita configurar la instrucción en los peers conmutadores B, C y D.

Los detalles de configuración de las instrucciones peers también se usan para establecer una conexión NETCONF a través de SSH entre los dispositivos. Para habilitar NETCONF a través de SSH, emita el set system services netconf ssh comando en todos los dispositivos.

Cómo se sincronizan las configuraciones y las confirmaciones entre dispositivos

El dispositivo local (o solicitante) en el que habilita la peers-synchronize instrucción o emite el commit peers-synchronize comando copia y carga su configuración en el dispositivo remoto (o que responde). A continuación, cada dispositivo realiza una comprobación de sintaxis en el archivo de configuración que se está confirmando. Si no se encuentran errores, la configuración se activa y se convierte en la configuración operativa actual en todos los dispositivos. Las confirmaciones se propagan mediante una llamada de procedimiento remota (RPC).

Durante la sincronización de la configuración se producen los siguientes eventos:

1. El dispositivo local envía el archivo sync-peers.conf (la configuración que se compartirá con los dispositivos especificados en el grupo condicional) a los dispositivos remotos.

2. Los dispositivos remotos cargan la configuración, envían los resultados de la carga al dispositivo local, exportan su configuración al dispositivo local y responden que la confirmación se ha completado.

3. El dispositivo local lee las respuestas de los dispositivos remotos.

4. Si se realiza correctamente, la configuración se confirmará.

La sincronización de la configuración no se realiza correctamente si a) el dispositivo remoto no está disponible o b) se puede acceder al dispositivo remoto, pero se producen errores debido a los siguientes motivos:

• La conexión SSH falla debido a problemas de usuario y autenticación.

• Se produce un error en RPC de Junos OS porque no se puede obtener un bloqueo en la base de datos remota.

• Se produce un error al cargar la configuración debido a problemas de sintaxis.

• Error en la comprobación de confirmación.

La peers-synchronize instrucción utiliza el nombre de host o la dirección IP, el nombre de usuario y la contraseña de los dispositivos configurados en la peers instrucción. Con la peers-synchronize instrucción habilitada, simplemente puede emitir el commit comando para sincronizar la configuración de un dispositivo a otro. Por ejemplo, si configuró la peers instrucción en el dispositivo local y desea sincronizar la configuración con el dispositivo remoto, simplemente puede emitir el commit comando en el dispositivo local. Sin embargo, si ejecuta el commit comando en el dispositivo local y no se puede acceder al dispositivo remoto, recibirá un mensaje de advertencia que indica que no se puede acceder al dispositivo remoto y que solo se confirma la configuración del dispositivo local:

Aquí hay un ejemplo de mensaje de advertencia:

Si no tiene la peers instrucción configurada con la información del dispositivo remoto y emite el commit comando, sólo se confirma la configuración en el dispositivo local. Si no se puede acceder al dispositivo remoto y hay otros errores, la confirmación no se realiza correctamente tanto en el dispositivo local como en el remoto.

El commit peers-synchronize comando también utiliza el nombre de host o la dirección IP, el nombre de usuario y la contraseña para los dispositivos configurados en la peers instrucción. Si emite el commit peers-synchronize comando en el dispositivo local para sincronizar la configuración con el dispositivo remoto y se puede acceder al dispositivo remoto, pero hay otros errores, se producirá un error en la confirmación tanto en el dispositivo local como en el remoto.

Ventajas de utilizar la comprobación de coherencia de MC-LAG

• Esta función le ayuda a encontrar inconsistencias de parámetros de configuración entre pares de grupo de agregación de vínculos multichasis (MC-LAG).

Cómo funcionan las comprobaciones de coherencia de MC-LAG

Los siguientes eventos tienen lugar durante la comprobación de coherencia de la configuración después de emitir una confirmación en el par MC-LAG local:

1. Confirme una configuración de MC-LAG en el par local de MC-LAG.

2. ICCP analiza la configuración de MC-LAG y, a continuación, envía la configuración al par de MC-LAG remoto.

3. El par MC-LAG remoto recibe la configuración MC-LAG del par MC-LAG local y la compara con su propia configuración MC-LAG.

   Si hay una incoherencia grave entre las dos configuraciones de MC-LAG, la interfaz MC-LAG se desactiva y se emiten mensajes syslog.

   Si hay una incoherencia moderada entre las dos configuraciones, se emiten mensajes syslog.

Los siguientes eventos tienen lugar durante la comprobación de coherencia de la configuración después de emitir una confirmación en el par MC-LAG remoto:

• Confirme una configuración de MC-LAG en el par MC-LAG remoto.

• ICCP analiza la configuración de MC-LAG y, a continuación, envía la configuración al par local de MC-LAG.

• El par MC-LAG local recibe la configuración del par MC-LAG remoto y la compara con su propia configuración.

  Si hay una incoherencia grave entre las dos configuraciones, la interfaz MC-LAG se desactiva y se emiten mensajes syslog.

  Si hay una incoherencia moderada entre las dos configuraciones, se emiten mensajes syslog.

Requisitos de coherencia de la configuración

Existen diferentes requisitos de coherencia de configuración en función de los parámetros MC-LAG. Los requisitos de coherencia son idénticos o únicos, lo que significa que algunos parámetros deben configurarse de forma idéntica y otros deben configurarse de forma exclusiva en los pares MC-LAG. Por ejemplo, el ID del chasis debe ser único en ambos pares, mientras que el modo LACP debe ser idéntico en ambos pares.

El nivel de cumplimiento de los requisitos de coherencia (idéntico o único) es obligatorio o deseado. Cuando el nivel de aplicación es obligatorio y se configura el parámetro MC-LAG incorrectamente, el sistema desactiva la interfaz y emite un mensaje syslog.

Por ejemplo, recibe un mensaje syslog que dice: “Some of the Multichassis Link Aggregation (MC-LAG) configuration parameters between the peer devices are not consistent. The concerned MC-LAG interfaces were explictly brought down to prevent unwanted behavior.” Cuando corrija la incoherencia y emita una confirmación correcta, el sistema abrirá la interfaz. Cuando se desea la aplicación y configura el parámetro MC-LAG incorrectamente, recibirá un mensaje syslog que dice: "Some of the Multichassis Link Aggregation(MC-LAG) configuration parameters between the peer devices are not consistent. This may lead to sub-optimal performance of the feature." Como se indica en el mensaje syslog, el rendimiento no será óptimo en esta situación. También puede emitir el comando show interfaces mc-ae para mostrar el estado de comprobación de coherencia de configuración de la interfaz Ethernet agregada multichasis.

Si hay varias incoherencias, solo se muestra la primera inconsistencia. Si el nivel de cumplimiento para un parámetro MC-LAG es obligatorio y no configuró ese parámetro correctamente, el comando muestra que la interfaz MC-LAG está inactiva.

Cuando no se puede acceder a pares remotos

Cuando se emite una confirmación en el par local y no se puede acceder al par remoto, la comprobación de coherencia de la configuración pasará para que el par local pueda aparecer en modo independiente. Cuando aparece el par remoto, ICCP intercambia las configuraciones entre los pares. Si se produce un error en la comprobación de coherencia, la interfaz MC-LAG deja de utilizarse y el sistema le notifica el parámetro que causó la incoherencia. Cuando se corrige la incoherencia y se emite una confirmación correcta, el sistema abre la interfaz.

Habilitación de la comprobación de coherencia de la configuración de MC-LAG

La comprobación de coherencia está habilitada de forma predeterminada. La Tabla 1 proporciona una lista de muestra de parámetros MC-LAG comprometidos que se comprueban para verificar su coherencia, junto con sus requisitos de coherencia (idénticos o únicos), las jerarquías en las que se configuran los parámetros y los niveles de cumplimiento de la comprobación de coherencia (obligatorios o deseados).

Conocer el estado de una comprobación de coherencia de configuración

Los siguientes comandos proporcionan información sobre el estado de la comprobación de coherencia de la configuración:

• Ejecute el comando show multi-chassis mc-lag configuration-consistency list-of-parameters para ver la lista de parámetros MC-LAG confirmados que se comprueban en busca de incoherencias, el requisito de coherencia (idéntico o único) y el nivel de cumplimiento (obligatorio o deseado).

• Emita el comando show multi-chassis mc-lag configuration-consistency para ver la lista de parámetros MC-LAG confirmados que se comprueban en busca de incoherencias, el requisito de coherencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la comprobación de coherencia de la configuración. Los resultados son aprobado o reprobado.

• Emita el comando show multi-chassis mc-lag configuration-consistency global-config para ver el estado de comprobación de coherencia de la configuración para todas las configuraciones globales relacionadas con la funcionalidad MC-LAG, el requisito de coherencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la comprobación de coherencia de la configuración. Los resultados son aprobado o reprobado.

• Emita el comando show multi-chassis mc-lag configuration-consistency icl-config para ver el estado de comprobación de coherencia de la configuración de los parámetros relacionados con el vínculo de control entre chasis, el requisito de coherencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la comprobación de coherencia de la configuración. Los resultados son aprobado o reprobado.

• Emita el comando show multi-chassis mc-lag configuration-consistency mcae-config para ver el estado de comprobación de coherencia de la configuración de los parámetros relacionados con la interfaz Ethernet agregada multichasis, el requisito de coherencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la comprobación de coherencia de la configuración. Los resultados son aprobado o reprobado.

• Emita el comando show multi-chassis mc-lag configuration-consistency vlan-config para ver el estado de la comprobación de coherencia de la configuración de los parámetros relacionados con la configuración de VLAN, el requisito de coherencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la comprobación de coherencia de la configuración. Los resultados son aprobado o reprobado.

• Emita el comando vrrp-config show multi-chassis mc-lag configuration-consistency para ver el estado de comprobación de coherencia de la configuración de los parámetros relacionados con la configuración de VRRP, el requisito de coherencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la comprobación de coherencia de la configuración. Los resultados son aprobado o reprobado.

• Emita el comando show interfaces mc-ae para ver el estado de comprobación de coherencia de la configuración de la interfaz Ethernet agregada multichasis. Si hay varias incoherencias, solo se muestra la primera inconsistencia. Si el nivel de cumplimiento para el parámetro MC-LAG es obligatorio y no configuró ese parámetro correctamente, el comando mostrará que la interfaz MC-LAG está inactiva.

Compatibilidad con la comprobación de coherencia de la configuración de MC-LAG

Tanto los conmutadores de la serie EX como los de la serie QFX admiten la comprobación de consistencia de la configuración MC-LAG.

A partir de Junos OS versión 15.1X53-D60 en conmutadores QFX10000, la comprobación de coherencia de la configuración utiliza el Protocolo de control entre chasis (ICCP) para intercambiar parámetros de configuración de MC-LAG (ID de chasis, ID de servicio, etc.) y comprueba si hay incoherencias de configuración entre los pares de MC-LAG.

Operación PIM con elección de enrutador designado en modo normal

En el modo normal con elección de enrutador designado, las interfaces IRB o RVI en ambos pares MC-LAG se configuran con PIM habilitado. En este modo, uno de los pares MC-LAG se convierte en el enrutador designado a través del mecanismo de elección del enrutador designado PIM. El enrutador designado elegido mantiene el árbol de puntos de encuentro (RPT) y el árbol de ruta más corta (SPT) para que pueda recibir datos del dispositivo de origen. El enrutador designado elegido participa en actividades periódicas de unión y poda de PIM hacia el punto de encuentro o la fuente.

El desencadenante para iniciar estas actividades de unión y poda son los informes de membresía de IGMP que se reciben de los receptores interesados. Los informes IGMP recibidos a través de interfaces Ethernet agregadas de varios chasis (potencialmente hashing en cualquiera de los pares MC-LAG) y los vínculos de base única se sincronizan con el par MC-LAG a través de ICCP.

Ambos pares MC-LAG reciben tráfico en su interfaz entrante (IIF). El enrutador no designado recibe tráfico a través de la interfaz ICL, que actúa como una interfaz de enrutador de multidifusión (mrouter).

Si se produce un error en el enrutador designado, el enrutador no designado tiene que crear todo el árbol de reenvío (RPT y SPT), lo que puede provocar la pérdida de tráfico de multidifusión.

Operación PIM con modo de enrutador designado dual

En el modo de enrutador designado dual, ambos pares MC-LAG actúan como enrutadores designados (activos y en espera) y envían mensajes periódicos de unión y poda aguas arriba hacia el punto de encuentro o fuente y, finalmente, se unen al RPT o SPT.

El par MC-LAG principal reenvía el tráfico de multidifusión a los dispositivos receptores, incluso si el par MC-LAG en espera tiene una métrica de preferencia menor.

El par MC-LAG en espera también se une al árbol de reenvío y recibe los datos de multidifusión. El par MC-LAG en espera elimina los datos porque tiene una lista de interfaces de salida (OIL) vacía. Cuando el par MC-LAG en espera detecta el error del par MC-LAG principal, agrega la VLAN del receptor al OIL y comienza a reenviar el tráfico de multidifusión.

Para habilitar un enrutador designado dual de multidifusión, ejecute el set protocols pim interface interface-name dual-dr comando en las interfaces VLAN de cada par MC-LAG.

Manejo de fallas

Para garantizar una convergencia más rápida durante los errores, configure la dirección IP en el par MC-LAG principal con una dirección IP más alta o con una prioridad de enrutador designada más alta. De esta forma, se garantiza que el par principal de MC-LAG conserve la pertenencia al enrutador designado si el emparejamiento PIM deja de funcionar.

Para garantizar que el tráfico converge si una interfaz MC-AE deja de funcionar, la interfaz ICL-PL siempre se agrega como un puerto mrouter. El tráfico de capa 3 se inunda a través de la entrada predeterminada o la entrada de espionaje a través de la interfaz ICL-PL, y el tráfico se reenvía en la interfaz MC-AE en el par MC-LAG. Si la interfaz ICL-PL deja de funcionar, la vecindad PIM deja de funcionar. En este caso, ambos pares MC-LAG se convierten en el enrutador designado. El par MC-LAG de respaldo deja caer sus vínculos y se pierde el emparejamiento de enrutamiento. Si la conexión ICCP deja de funcionar, el par MC-LAG de reserva cambia el ID del sistema LACP y desactiva las interfaces MC-AE. El estado de los vecinos de PIM permanece operativo.

Espionaje IGMP en la funcionalidad del modo activo-activo MC-LAG

Se admiten el modo activo-activo del grupo de agregación de vínculos multichasis (MC-LAG) y la supervisión IGMP en modo de espera activa. MC-LAG permite que un dispositivo forme una interfaz LAG lógica con dos o más dispositivos de red. MC-LAG ofrece beneficios adicionales que incluyen redundancia a nivel de nodo, multiconexión y una red de capa 2 sin bucles sin ejecutar el Protocolo de árbol de expansión (STP). Se admiten las siguientes características:

• Sincronización de estado entre pares para espionaje IGMP en un dominio de puente solo con interfaces de capa 2

• Aprendizaje cualificado

• Vínculos multichasis orientados al enrutador

Se admiten las siguientes mejoras en el puente activo-activo y en el Protocolo de redundancia de enrutador virtual (VRRP) sobre enrutamiento y puentes integrados (IRB):

• Compatibilidad con MC-LAG para espionaje IGMP en un conmutador puro de capa 2

• Soporte MC-LAG para espionaje IGMP en dominios puente haciendo aprendizaje calificado

• Soporte para MC-Links como interfaces orientadas al enrutador

Se not admiten las siguientes funciones:

• MC-LAG para instancias VPLS

• Puertos troncales MC-Links

• Modo proxy para activo-activo

• Agregar vínculos entre chasis a interfaces salientes según sea necesario

  Los vínculos entre chasis se pueden agregar a la lista de interfaces salientes como interfaces orientadas al enrutador.

Topología de red normalmente admitida para espionaje IGMP con puente activo-activo MC-LAG

La figura 1 muestra una topología de red típica sobre la que se admite el espionaje IGMP con puente activo-activo MC-LAG.

Figura 1: Red típica sobre la que se admite activo-activo

Las interfaces I3 e I4 son interfaces de base única. Los enlaces multichasis ae0.0 y ae0.1 pertenecen al mismo dominio de puente en ambos chasis. Las interfaces I3, ae0.0 y ae0.1 se encuentran en el mismo dominio de puente en el enrutador activo secundario (S-A). Las interfaces I4, ae0.0 y ae0.1 se encuentran en el mismo dominio de puente en el enrutador activo primario (P-A). Las interfaces I3, I4, ae0.0 y ae0.1 se encuentran en el mismo dominio de aprendizaje que el vínculo entre chasis (ICL) que conecta los dos chasis.

El enrutador activo primario es el chasis en el que el enrutamiento y los puentes integrados se han convertido en PIM-DR. El enrutador activo secundario es el chasis en el que el enrutamiento y el puente integrados no son PIM-DR. El enrutador P-A es el chasis responsable de extraer el tráfico del núcleo IP. Por lo tanto, la elección PIM-DR se utiliza para evitar la duplicación del tráfico de datos.

Los dominios de aprendizaje se describen en Aprendizaje calificado.

Para los altavoces IGMP (hosts y enrutadores) en el dominio de aprendizaje, P-A y S-A juntos deben aparecer como un dispositivo con interfaces I4, I3, ae0.0 y ae0.1.

No se deben enviar paquetes de control duplicados en vínculos multichasis, lo que significa que el paquete de control debe enviarse a través de un solo vínculo.

Actualizaciones de estado del plano de control desencadenadas por paquetes recibidos en el chasis remoto

A continuación se muestran las actualizaciones de estado del plano de control desencadenadas por los paquetes recibidos en el chasis remoto:

• El estado de pertenencia en el enrutamiento de multidifusión de capa 3 se actualiza como resultado de los informes obtenidos en los tramos remotos de los vínculos multichasis y los vínculos S conectados al chasis remoto.

• El estado de pertenencia y la entrada de enrutamiento en la supervisión se actualizan cuando se reciben informes en los tramos remotos de un vínculo multichasis.

Reenvío de datos

Esta discusión asume que el enrutamiento y el puente integrados en el enrutador P-A es el PIM-DR. Extrae el tráfico de las fuentes en el núcleo. El tráfico también puede aparecer en las interfaces de capa 2 en el dominio del puente. Para los hosts conectados directamente al chasis P-A, no hay cambios en la forma en que se entregan los datos.

Para entregar tráfico a hosts conectados a S-A (que es el que no es DR) en el enlace de base única como I3, confiamos en el enlace entre chasis. El tráfico que llega a P-A se envía a través de ICL a S-A para ser entregado a los enlaces que han reportado intereses en s,g y los enlaces que están orientados hacia el enrutador.

Cuando el tramo ae0 en P-A falla, los hosts conectados al enlace multichasis reciben tráfico a través de ICL. En S-A, el tráfico recibido en ICL se envía a enlaces multichasis en la lista de interfaces salientes para los cuales la contraparte ae en P-A está inactiva.

Topología pura de capa 2 sin enrutamiento ni puentes integrados

La figura 2 muestra que el chasis que se conecta al PIM-DR es el enrutador activo primario (P-A) y el otro es el enrutador activo secundario (S-A).

Figura 2: Configuración de capa 2 sin enrutamiento y puente integrados

Aprendizaje calificado

En esta topología, las interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 e I10 son interfaces de base única. Los enlaces multichasis ae0.0 y ae0.1 pertenecen al mismo dominio de puente en ambos chasis. Las interfaces I10, I1, I7, I3, I5, ae0.0 y ae0.1 están en el mismo dominio de puente, bd1 en P-A. Las interfaces I9, I2, I8, I4, I6, ae0.0 y ae0.1 se encuentran en el mismo dominio de puente, bd1 en S-A.

En esta discusión se asume la siguiente configuración:

• En P-A y S-A, el aprendizaje calificado está activado en bd1.

• Las interfaces I1, I2, I3, ae0.0 e I4 pertenecen a vlan1, dominio de aprendizaje ld1.

• Las interfaces I7, I8, I5, ae0.1 e I6 pertenecen a vlan2, dominio de aprendizaje ld2.

• Las interfaces I9 e I10 pertenecen a vlan3, dominio de aprendizaje ld3.

Para los altavoces IGMP (hosts y enrutadores) en el mismo dominio de aprendizaje ld1, P-A y S-A vinculados deben parecer un solo conmutador.

Para los altavoces IGMP (hosts y enrutadores) en el mismo dominio de aprendizaje, ld2, P-A y S-A vinculados deben parecer un solo conmutador.

Dado que no hay vínculos multichasis en el dominio de aprendizaje ld3, para los altavoces IGMP (hosts y enrutadores) en el dominio de aprendizaje ld3, P-A y S-A no parecerán ser un solo conmutador.

En esta discusión se supone que el vínculo entre chasis ICL1 corresponde al dominio de aprendizaje ld1 y el vínculo entre chasis ICL2 corresponde al dominio de aprendizaje ld2.

Se admite el flujo de paquetes de control, con la excepción de pasar información al IRB.

Reenvío de datos con aprendizaje cualificado

Esta discusión asume un dominio de aprendizaje (LD), ld1, y además asume que la interfaz I1 en el enrutador P-A está conectada al PIM-DR en el dominio de aprendizaje y extrae el tráfico de las fuentes en el núcleo.

Para entregar tráfico a hosts conectados al enrutador S-A (que no es DR) en el enlace de base única como I2, I4 (perteneciente a ld1), confiamos en ICL1. El tráfico que llega al enrutador P-A en la interfaz I1 se envía a través del enlace ICL1 del interchasis al enrutador S-A para ser entregado a los enlaces que han reportado intereses en s,g o los enlaces que están orientados al enrutador en el dominio de aprendizaje ld1.

Cuando la pata de la interfaz ae0 en el enrutador P-A deja de funcionar, los hosts conectados al vínculo multichasis reciben tráfico de la interfaz I1 mediante el enlace entre chasis ICL1. En el enrutador S-A, el tráfico recibido en el enlace ICL1 entre chasis se envía a vínculos multichasis en la lista de interfaces salientes para los cuales la contraparte Ethernet agregada en el enrutador P-A está inactiva.

Se supone además que la interfaz I9 en el enrutador S-A pertenece al dominio de aprendizaje ld3 con intereses en s,g, y que la interfaz I10 en el dominio de aprendizaje ld3 en el enrutador P-A recibe tráfico para s,g. La interfaz I9 no recibe datos en esta topología porque no hay vínculos multichasis (en modo a-a) y, por lo tanto, no hay vínculo entre chasis en el dominio de aprendizaje ld3.

Grupos estáticos en interfaces de base única

Para los vínculos multichasis, la configuración de grupo estático debe existir en ambos tramos y no es necesaria la sincronización con el otro chasis.

No se admite la sincronización de los grupos estáticos en interfaces de base única entre el chasis. Sin embargo, la adición de interfaces lógicas a la lista predeterminada de interfaces salientes admite la entrega de tráfico a la interfaz dentro de una configuración estática.

Interfaces orientadas al enrutador como vínculos multichasis

Las consultas IGMP pueden llegar a cualquiera de las partes de los vínculos multichasis, pero en ambos pares, el vínculo multichasis debe considerarse como de cara al enrutador.

Los informes deben salir una sola vez desde el vínculo multichasis, es decir, desde un solo tramo.

Se proporciona la siguiente compatibilidad de MC-LAG para el espionaje IGMP en IRB:

• Espionaje no proxy

• Las interfaces lógicas deben ser interfaces de salida para todas las rutas, incluida la ruta predeterminada

• Espionaje IGMP en un conmutador puro de capa 2

• Espionaje IGMP en dominios puente haciendo aprendizaje calificado

• Interfaz orientada al enrutador MC-Links

Se not admiten las siguientes características:

• Modo proxy para activo-activo

• Compatibilidad de MC-LAG con instancias VPLS

• Puertos troncales como enlaces multichasis

• Agregar interfaces lógicas a las interfaces salientes según sea necesario.

  Sin embargo, las interfaces lógicas siempre se agregan como una interfaz orientada al enrutador a la lista de interfaces de salida.

Topología MC-LAG compatible

Para admitir el transporte sin pérdidas del tráfico FCoE a través de un MC-LAG, debe configurar la clase de servicio (CoS) adecuada en ambos conmutadores con miembros de puerto MC-LAG. La configuración del CoS debe ser la misma en ambos conmutadores MC-LAG, ya que los MC-LAG no contienen información de clase de reenvío y prioridad IEEE 802.1p.

Los conmutadores que no están conectados directamente a hosts FCoE y que actúan como conmutadores de tránsito de paso admiten MC-LAG para el tráfico FCoE en una topología de red en U invertida . La figura 3 muestra una topología en U invertida mediante conmutadores QFX3500.

Figura 3: Topología admitida para un MC-LAG en un conmutador de tránsito FCoE

Los conmutadores independientes admiten MC-LAG. Sistema QFabric Los dispositivos de nodo no admiten MC-LAG. Las configuraciones de Virtual Chassis y Virtual Chassis Fabric (VCF) de modo mixto no admiten FCoE. Solo los VCF de QFX5100 pura (que consisten solo en conmutadores QFX5100) admiten FCoE.

Los puertos que forman parte de una configuración de puerta de enlace FCoE-FC (una estructura de puerta de enlace FCoE-FC virtual) no admiten MC-LAG. Los puertos que son miembros de un MC-LAG actúan como puertos de conmutador de tránsito de paso.

Las siguientes reglas y directrices se aplican a los MC-LAG cuando se utilizan para el tráfico FCoE. Las reglas y directrices ayudan a garantizar el manejo adecuado y las características de transporte sin pérdidas requeridas para el tráfico FCoE.

• Los dos conmutadores que forman el MC-LAG (conmutadores S1 y S2) no pueden utilizar puertos que formen parte de una estructura de puerta de enlace FCoE-FC. Los puertos del conmutador MC-LAG deben ser puertos de conmutador de tránsito de paso a través (utilizados como parte de un conmutador de tránsito intermedio que no está conectado directamente a hosts FCoE).

• Los conmutadores MC-LAG S1 y S2 no se pueden conectar directamente a los hosts FCoE.

• Los dos conmutadores que sirven como dispositivos de acceso para hosts FCoE (conmutadores de tránsito FCoE TS1 y TS2) utilizan LAG estándar para conectarse a los conmutadores MC-LAG S1 y S2. Los conmutadores de tránsito FCoE TS1 y TS2 pueden ser conmutadores independientes o dispositivos de nodo en un sistema QFabric.

• Conmutadores de tránsito TS1 y TS2 deben utilizar puertos de conmutador de tránsito para los hosts FCoE y para los LAG estándar a los conmutadores MC-LAG S1 y S2.

• Active la supervisión de FIP en la VLAN FCoE en los conmutadores de tránsito TS1 y TS2. Puede configurar VN_Port para VF_Port (VN2VF_Port) fisgones o VN_Port para VN_Port (VN2VN_Port) espionaje FIP, dependiendo de si los hosts FCoE necesitan acceder a destinos en la SAN FC (VN2VF_Port fisgones FIP) o destinos en la red Ethernet (VN2VN_Port fisgones FIP).

  La supervisión de FIP debe realizarse en el borde de acceso y no se admite en los conmutadores MC-LAG. No habilite la supervisión FIP en los conmutadores MC-LAG S1 y S2. (No habilite la supervisión FIP en los puertos MC-LAG que conectan los conmutadores S1 y S2 a los conmutadores TS1 y TS2 ni en los puertos LAG que conectan el conmutador S1 a S2.)

  Nota:

  Los conmutadores de agregación QFX10000 de Juniper Networks no admiten la supervisión de FIP, por lo que no se pueden usar como conmutadores de acceso de espionaje FIP (conmutadores de tránsito TS1 y TS2) en esta topología.

• La configuración del CoS debe ser coherente en los conmutadores MC-LAG. Dado que los MC-LAG no contienen información de clase de reenvío ni de prioridad, cada conmutador MC-LAG debe tener la misma configuración de CoS para admitir el transporte sin pérdidas. (En cada conmutador MC-LAG, el nombre, la cola de salida y el aprovisionamiento de CoS de cada clase de reenvío deben ser los mismos, y la configuración del control de flujo basado en prioridades (PFC) debe ser la misma).

• Conmutadores de tránsito (acceso al servidor)
• Conmutadores MC-LAG (agregación FCoE)

Espionaje FIP y puertos de confianza FCoE

Para mantener un acceso seguro, habilite VN2VF_Port espionaje FIP o VN2VN_Port espionaje FIP en los puertos de acceso del conmutador de tránsito conectados directamente a los hosts FCoE. El espionaje de FIP debe realizarse en el borde de acceso de la red para evitar el acceso no autorizado. Por ejemplo, en la figura 3, habilita la supervisión de FIP en las VLAN FCoE en los conmutadores de tránsito TS1 y TS2 que incluyen los puertos de acceso conectados a los hosts FCoE.

No habilite el espionaje FIP en los conmutadores utilizados para crear el MC-LAG. Por ejemplo, en la figura 3, no habilitaría la supervisión de FIP en las VLAN FCoE de los conmutadores S1 y S2.

Configure los vínculos entre conmutadores como puertos de confianza FCoE para reducir la sobrecarga de espionaje FIP y asegurarse de que el sistema realiza el espionaje FIP solo en el borde de acceso. En la topología de ejemplo, configure los puertos LAG TS1 y TS2 del conmutador de tránsito conectados a los conmutadores MC-LAG como puertos de confianza FCoE, configure los puertos MC-LAG del conmutador S1 y S2 conectados a los conmutadores TS1 y TS2 como puertos de confianza FCoE, y configure los puertos del LAG que conectan los conmutadores S1 a S2 como puertos de confianza FCoE.

CoS y puentes de centro de datos (DCB)

Los vínculos MC-LAG no contienen información de clase o prioridad de reenvío. Las siguientes propiedades de CoS deben tener la misma configuración en cada conmutador MC-LAG o en cada interfaz MC-LAG para admitir el transporte sin pérdidas:

• Nombre de la clase de reenvío de FCoE: por ejemplo, la clase de reenvío para el tráfico de FCoE podría utilizar la clase de reenvío predeterminada fcoe en ambos conmutadores MC-LAG.

• Cola de salida FCoE: por ejemplo, la clase de reenvío podría asignarse a la fcoe cola 3 en ambos conmutadores MC-LAG (la cola 3 es la asignación predeterminada para la fcoe clase de reenvío).

• Clasificador: la clase de reenvío para el tráfico FCoE debe asignarse al mismo punto de código IEEE 802.1p en cada interfaz miembro del MC-LAG en ambos conmutadores MC-LAG. Por ejemplo, la clase fcoe de reenvío FCoE podría asignarse al punto 011 de código IEEE 802.1p (el punto 011 de código es la asignación predeterminada para la fcoe clase de reenvío).

• Control de flujo basado en prioridades (PFC): el PFC debe habilitarse en el punto de código FCoE de cada conmutador MC-LAG y aplicarse a cada interfaz MC-LAG mediante un perfil de notificación de congestión.

También debe configurar la selección de transmisión mejorada (ETS) en las interfaces MC-LAG para proporcionar suficientes recursos de programación (ancho de banda, prioridad) para el transporte sin pérdidas. La configuración de ETS puede ser diferente en cada conmutador MC-LAG, siempre y cuando haya suficientes recursos programados para admitir el transporte sin pérdidas para el tráfico FCoE esperado.

El protocolo de descubrimiento de capa de vínculo (LLDP) y el protocolo de intercambio de capacidad de puente de centro de datos (DCBX) deben estar habilitados en cada interfaz miembro de MC-LAG (LLDP y DCBX están habilitados de forma predeterminada en todas las interfaces).

Ventajas de usar EVPN-MPLS con Junos Fusion Enterprise y MC-LAG

Utilice EVPN-MPLS con Junos Fusion Enterprise y MC-LAG para interconectar campus dispersos y sitios de centro de datos para formar un único puente virtual de capa 2.

Manejo del tráfico BUM

En los casos de uso que se muestran en la figura 4 y la figura 5, PE1, PE2 y PE3 son pares de EVPN, y PE2 y PE3 son pares de MC-LAG. Ambos conjuntos de pares intercambian información de control y reenvían tráfico entre sí, lo que causa problemas. En la Tabla 2 se describen los problemas que surgen y la forma en que Juniper Networks los resuelve en su implementación de la función de interfuncionamiento EVPN-MPLS.

Horizonte dividido

En los casos de uso que se muestran en las figuras 4 y 5, el horizonte dividido impide que se reenvíen varias copias de un paquete BUM a un dispositivo CE (dispositivo satelital). Sin embargo, las implementaciones de horizonte dividido de EVPN-MPLS y MC-LAG se contradicen entre sí, lo que provoca un problema. En la Tabla 3 se explica el problema y cómo Juniper Networks lo resuelve en su implementación de la función de interfuncionamiento EVPN-MPLS.

Aprendizaje MAC

EVPN y MC-LAG utilizan el mismo método para aprender direcciones MAC, es decir, un dispositivo PE aprende direcciones MAC de sus interfaces locales y sincroniza las direcciones con sus pares. Sin embargo, dado que tanto EVPN como MC-LAG están sincronizando las direcciones, surge un problema.

En la Tabla 4 se describe el problema y cómo la implementación de interfuncionamiento EVPN-MPLS lo evita. Los casos de uso que se muestran en la Figura 4 y la Figura 5 ilustran el problema. En ambos casos de uso, PE1, PE2 y PE3 son pares de EVPN, y PE2 y PE3 son pares de MC-LAG.

Control del vínculo descendente entre los puertos de enlace en cascada y ascendente en Junos Fusion Enterprise

En Junos Fusion Enterprise que se muestra en la figura 4, suponga que el dispositivo de agregación PE2 recibe un paquete BUM de PE1 y que el vínculo entre el puerto en cascada de PE2 y el puerto de enlace ascendente correspondiente del dispositivo satelital SD1 está inactivo. Independientemente de si el paquete BUM es manejado por MC-LAG o EVPN multihoming activo-activo, el resultado es el mismo: el paquete se reenvía a través de la interfaz ICL a PE3, que lo reenvía a SD1 de base dual.

Para ilustrar con más detalle cómo EVPN con multiconexión activa-activa maneja esta situación con SD1 de base dual, suponga que la interfaz DF reside en PE2 y está asociada con el vínculo descendente y que la interfaz no DF reside en PE3. Normalmente, según EVPN con lógica de reenvío activo-activo multiconexión, la interfaz que no es DF descarta el paquete. Sin embargo, debido al vínculo descendente asociado con la interfaz DF, PE2 reenvía el paquete BUM a través de la ICL a PE3, y la interfaz que no es DF en PE3 reenvía el paquete a SD1.

Compatibilidad con puerta de enlace de capa 3

La función de intertrabajo EVPN-MPLS admite la siguiente funcionalidad de puerta de enlace de capa 3 para dominios de puente extendido y VLAN:

• Interfaces de enrutamiento y puente integrados (IRB) para reenviar tráfico entre los dominios de puente extendido o VLAN.

• Puertas de enlace predeterminadas de capa 3 para reenviar tráfico desde un servidor físico (sin sistema operativo) en un dominio de puente extendido o VLAN a un servidor físico o máquina virtual en otro dominio de puente extendido o VLAN.

Ventajas de las puertas de enlace Anycast

• Con los dos dispositivos Juniper Networks multihost que actúan como puertas de enlace anycast en una red EVPN-MPLS o MC-LAG, un host en la misma red que genera paquetes de capa 3 con destinos en otras redes ahora puede enviar los paquetes a la puerta de enlace anycast local. Al recibir estos paquetes de capa 3, la puerta de enlace anycast enruta los paquetes en la red principal según la búsqueda IP de destino.

Directrices de configuración de la puerta de enlace de Anycast

• En general, al configurar direcciones para una puerta de enlace de anycast:

  • Para las direcciones IPv4 o IPv6, puede especificar cualquier subred.

  • Para las direcciones MAC, puede usar la dirección MAC que el dispositivo de Juniper Networks genera automáticamente (MAC del chasis) o puede configurar explícitamente una dirección MAC mediante la CLI.

  • El esquema de subred de la dirección IP determinará si utiliza la sintaxis de comandos de interfaz IRB o la sintaxis de comandos VGA para configurar la puerta de enlace de anycast.

Para configurar sus dispositivos multihost como puertas de enlace anycast, proporcionamos las siguientes directrices de configuración:

• Directriz 1: Si la dirección IP de las puertas de enlace anycast se encuentra en la subred /30 o /31 (para IPv4), /126 o /127 (para IPv6):

  • Debe configurar la misma dirección IP para la interfaz IRB en cada uno de los dispositivos de host múltiple mediante uno de los siguientes comandos.

  • Debe configurar explícitamente la dirección MAC mediante el siguiente comando:

  • No debe configurar una VGA (direcciones IP y MAC).

• Directriz 2: Si la dirección IP de las puertas de enlace anycast es una subred distinta de /30, /31, /126 o /127, se puede configurar una VGA:

  • Debe configurar la misma dirección IP para VGA en cada uno de los dispositivos de host múltiple mediante uno de los siguientes comandos.

  • Debe configurar explícitamente la dirección MAC mediante uno de los siguientes comandos:

  • Al especificar una dirección MAC para la VGA, no recomendamos utilizar la misma dirección MAC utilizada para VRRP.

Limitaciones de configuración de la puerta de enlace de Anycast

Al configurar la puerta de enlace de anycast mediante las directrices descritas anteriormente en este tema, tenga en cuenta lo siguiente:

• En general, no recomendamos reutilizar una dirección MAC VRRP como dirección MAC para una interfaz IRB. Sin embargo, si debe hacerlo, como es la práctica general al configurar VRRP en dispositivos de Juniper Networks, debe usar una dirección MAC VRRP IPv4 para la familia IPv4 y una dirección MAC VRRP IPv6 para la familia IPv6.

  Dados estos parámetros, la única directriz de configuración con la que funcionará esta limitación es la directriz de configuración 2.

• Al configurar direcciones de puerta de enlace de difusión cualificada mediante la directriz 1 en un entorno EVPN-MPLS, también debe especificar las instrucciones de default-gateway do-not-advertise configuración en una instancia de enrutamiento. Por ejemplo:

• En un entorno EVPN-MPLS, si las direcciones IP de la puerta de enlace anycast se encuentran en subredes diferentes y especifica las direcciones en varias instancias de enrutamiento:

  • Si configuró una dirección IP de puerta de enlace de anycast mediante la directriz de configuración 1 en una instancia de enrutamiento y otra dirección IP de puerta de enlace de anycast mediante la directriz de configuración 2 en una instancia de enrutamiento diferente, también debe especificar las instrucciones de default-gateway no-gateway-community configuración en la instancia de enrutamiento:

    Esta configuración adicional solo se aplica a la instancia de enrutamiento que incluye direcciones IP de puerta de enlace de difusión cualificada que se configuran mediante la directriz 1.

  • Para cada instancia de enrutamiento en la que haya especificado la dirección IP de la puerta de enlace anycast mediante la directriz de configuración 1, se recomienda especificar una única dirección MAC que no sea VRRP.

• La generación automática de ESI está habilitada de forma predeterminada en dispositivos con multiconexión EVPN para la redundancia de puerta de enlace virtual. Se recomienda deshabilitar la generación automática de ESI para redes EVPN-VXLAN con superposiciones de puente enrutado de borde (ERB). En ese caso, puede incluir la no-auto-virtual-gateway-esi instrucción en el nivel jerárquico [edit interfaces irb unit logical-unit-number] .

  A partir de Junos OS versión 22.1R1, los enrutadores MX960, MX2020 y MX10008 también habilitan la generación automática de ESI de forma predeterminada para las ESI de interfaz IRB de puerta de enlace EVPN de capa 3. Sin embargo, la no-auto-virtual-gateway-esi instrucción no se admite con redes EVPN-MPLS. Como resultado, siempre verá ESI generados automáticamente para interfaces IRB en este caso.

• En un entorno EVPN-VXLAN con multiconexión, puede utilizar varias instancias de enrutamiento EVPN en dispositivos perimetrales de proveedor par (PE) que compartan un segmento Ethernet (ES). Cuando se configuran puertas de enlace anycast con la default-gateway instrucción, no se admite mezclar el comportamiento predeterminado (opción de anuncio) con la opción no-gateway-community en los vínculos que participan en el mismo ES.

  Como resultado, si configura la default-gateway instrucción con la no-gateway-community opción en cualquier instancia de enrutamiento EVPN en cualquier dispositivo PE par que comparta un ES, debe configurar esta instrucción:

  • En todas las instancias de enrutamiento que comparten el ES en un dispositivo PE,

  • En todos los dispositivos PE del mismo nivel que comparten el ES

  • Solo con la opción o con el no-gateway-community do-not-advertisearchivo .

  No puede omitir la configuración de la instrucción default-gateway ni incluir la instrucción con la opción advertise en ninguna instancia de enrutamiento en ningún dispositivo PE par.

• Se admite la configuración de una dirección IP de puerta de enlace anycast en interfaces IRB en dispositivos ACX5448. Sin embargo, para las interfaces IRB con direcciones IP /30 o /31 en conexiones entre PE e interfaces de dispositivo perimetral del cliente (CE), el dispositivo CE no tiene suficiente espacio en la piscina para la asignación de direcciones IP de sesión BGP. Como resultado, no admitimos BGP con las direcciones IP anycast /30 y /31 de la interfaz IRB.