Conceptos avanzados de MC-LAG

Beneficios de la sincronización de 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 la 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 otro 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 las confirmaciones entre los dispositivos de forma predeterminada. NETCONF a través de 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 siguientes pasos:

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

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

3. Cree grupos condicionales.

4. Crear grupos de aplicación.

5. Habilite NETCONF a través de 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 los dispositivos locales y remotos.

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 utiliza un grupo de configuración local, el dispositivo remoto utiliza un grupo de configuración remoto y los dispositivos locales y remotos comparten un grupo de configuración global.

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 D) y un grupo de configuración global denominado Grupo C, que incluiría la configuración común a todos los dispositivos.

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

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 [edit groups] nivel de 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 sincronización de 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, ejecute 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 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. A esto, 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 el conmutador B, el conmutador C y el peers conmutador D.

Los detalles de configuración de las instrucciones peers también se utilizan para establecer una conexión NETCONF a través de SSH entre los dispositivos. Para activar NETCONF a través de SSH, ejecute 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 habilite la peers-synchronize instrucción o emita el commit peers-synchronize comando copie y cargue su configuración en el dispositivo remoto (o que responde). Luego, cada dispositivo realiza una verificación de sintaxis en el archivo de configuración que se está confirmando. Si no se encuentra ningún error, 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 está completa.

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

4. Si se realiza correctamente, la configuración se confirma.

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.

• La RPC de Junos OS falla porque no se puede obtener un bloqueo en la base de datos remota.

• La carga de la configuración falla debido a problemas de sintaxis.

• Se produce un 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 que configuró 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 ejecutar 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 en el 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 ejecuta el commit comando, solo 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 ni en el dispositivo local ni 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 de los dispositivos configurados en la peers instrucción. Si ejecuta 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, la confirmación falla tanto en el dispositivo local como en el remoto.

Beneficios de usar MC-LAG Consistency Check

• Esta función le ayuda a encontrar inconsistencias en los parámetros de configuración entre los pares del grupo de agregación de vínculos de varios chasis (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 MC-LAG local.

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

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

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

   Si hay una inconsistencia 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, luego, envía la configuración al par MC-LAG local.

• 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 inconsistencia grave entre las dos configuraciones, la interfaz MC-LAG se desactiva y se emiten mensajes syslog.

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

Requisitos de coherencia de la configuración

Existen diferentes requisitos de coherencia de configuración según los parámetros de 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 única 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énticos o únicos) es obligatorio o deseado. Cuando el nivel de cumplimiento es obligatorio y configura el parámetro MC-LAG incorrectamente, el sistema desconecta 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 inconsistencia y emita una confirmación exitosa, el sistema mostrará la interfaz. Cuando se desea la aplicación y configura el parámetro MC-LAG incorrectamente, recibirá un mensaje syslog que dice: Como se indica en el mensaje syslog, "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." el rendimiento no será óptimo en esta situación. También puede ejecutar el comando show interfaces mc-ae para mostrar el estado de comprobación de coherencia de la configuración de la interfaz Ethernet agregada de multichasis.

Si hay varias inconsistencias, solo se muestra la primera inconsistencia. Si el nivel de cumplimiento de 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 contactar con pares remotos

Cuando se emite una confirmación en el par local y no se puede acceder al par remoto, se superará la comprobación de coherencia de la configuración 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 funcionar y el sistema le notifica el parámetro que ha causado la incoherencia. Cuando corrige la inconsistencia y emite una confirmación exitosa, 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. En la tabla 1 se proporciona una lista de ejemplo de parámetros MC-LAG confirmados que se comprueba la 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 comprobación de coherencia (obligatorios o deseados).

Aprender 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 inconsistencias, el requisito de consistencia (idéntico o único) y el nivel de cumplimiento (obligatorio o deseado).

• Ejecute 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 inconsistencias, el requisito de consistencia (idéntico o único), el nivel de aplicación (obligatorio o deseado) y el resultado de la verificación de consistencia de la configuración. Los resultados son aprobado o reprobado.

• Ejecute el comando show multi-chassis mc-lag configuration-consistency global-config para ver el estado de la comprobación de la coherencia de la configuración para todas las configuraciones globales relacionadas con la funcionalidad de 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 la coherencia de la configuración. Los resultados son aprobado o reprobados.

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

• Ejecute el comando show multi-chassis mc-lag configuration-consistency mcae-config para ver el estado de la comprobación de la coherencia de la configuración de los parámetros relacionados con la interfaz Ethernet agregada de 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.

• Ejecute el comando show multi-chassis mc-lag configuration-consistency vlan-config para ver el estado de la comprobación de la 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 la coherencia de la configuración. Los resultados son aprobado o reprobados.

• Ejecute el comando show multi-chassis mc-lag configuration-consistency vrrp-config para ver el estado de la comprobación de la 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 la coherencia de la configuración. Los resultados son aprobado o reprobado.

• Ejecute el comando show interfaces mc-ae para ver el estado de comprobación de coherencia de la configuración de la interfaz Ethernet agregada de multichasis. Si hay varias inconsistencias, 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.

Operación de 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 de 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 el origen.

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

Ambos pares de MC-LAG reciben tráfico en su interfaz entrante (IIF). El enrutador no designado recibe tráfico mediante la interfaz ICL, la cual actúa como 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 causar pérdida de tráfico de multidifusión.

Operación de PIM con modo de enrutador designado dual

En el modo de enrutador designado dual, ambos pares MC-LAG actúan como enrutadores designados (activo y en espera) y envían mensajes periódicos de unión y poda ascendente hacia el punto de encuentro u origen, 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, aun 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 descarta los datos porque tiene una lista de interfaces de salida (OIL) vacía. Cuando el par MC-LAG en espera detecta el fallo principal del par MC-LAG, agrega la VLAN receptora al OIL y comienza a reenviar el tráfico de multidifusión.

Para habilitar un enrutador de doble designación de multidifusión, emita 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 las fallas, 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. Esto garantiza que el par MC-LAG principal conserve la membresía del enrutador designado si el emparejamiento de PIM deja de funcionar.

Para garantizar que el tráfico converja 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 desciende. En este caso, ambos pares MC-LAG se convierten en el enrutador designado. El par MC-LAG de respaldo derriba sus vínculos y se pierde el emparejamiento de enrutamiento. Si la conexión ICCP deja de funcionar, el par MC-LAG de respaldo cambia el ID del sistema LACP y desconecta las interfaces MC-AE. El estado de los vecinos de PIM permanece operativo.

Supervisión IGMP en MC-LAG Funcionalidad del modo activo-activo

Se admite el modo activo-activo del grupo de agregación de vínculos de múltiples chasis (MC-LAG) y la supervisión IGMP en modo activo-en espera. 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, incluyendo 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 supervisión IGMP en un dominio de puente con solo interfaces de capa 2

• Aprendizaje calificado

• Vínculos multichasis orientados al enrutador

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

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

• Soporte MC-LAG para la intromisión IGMP en dominios puente que realizan aprendizaje calificado

• Soporte para MC-Links como interfaces orientadas al enrutador

Se not admiten las siguientes funciones:

• MC-LAG para instancias VPLS

• Puertos troncales de MC-Links

• Modo proxy para activo-activo

• Agregar vínculos de interchasis a interfaces salientes según sea necesario

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

Topología de red típicamente admitida para la supervisión IGMP con puente activo-activo MC-LAG

La Figura 1 muestra una topología de red típica sobre la cual se admite la supervisión 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 una sola conexión. Los vínculos 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 secundario activo (S-A). Las interfaces I4, ae0.0 y ae0.1 se encuentran en el mismo dominio de puente en el enrutador principal activo (P-A). Las interfaces I3, I4, ae0.0 y ae0.1 se encuentran en el mismo dominio de aprendizaje que el vínculo de interchasis (ICL) que conecta los dos chasis.

El enrutador activo principal es el chasis en el que el enrutamiento y el puente integrados se han convertido en PIM-DR. El enrutador activo secundario es el chasis en el cual 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 hablantes IGMP (hosts y enrutadores) en el dominio de aprendizaje, P-A y S-A juntos deben aparecer como un solo dispositivo con interfaces I4, I3, ae0.0 y ae0.1.

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

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

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

• El estado de pertenencia al enrutamiento de multidifusión de capa 3 se actualiza como resultado de los informes aprendidos en tramos remotos de vínculos multichasis y S-links 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

En esta discusión, se supone 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 proceder en interfaces de capa 2 en el dominio de 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 los hosts conectados a S-A (que es el no DR) en el vínculo de una sola conexión como I3, confiamos en el vínculo de interchasis. 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 interés en s,g y los enlaces que están orientados al enrutador.

Cuando el tramo ae0 en P-A deja de funcionar, los hosts conectados al vínculo multichasis reciben tráfico a través de ICL. En S-A, el tráfico recibido en ICL se envía a vínculos de varios chasis en la lista de interfaces de salida para los cuales la contraparte de ae en P-A está inactiva.

Topología pura de capa 2 sin enrutamiento ni puente 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 ni puente integrados

Aprendizaje calificado

En esta topología, las interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 e I10 son interfaces de una sola conexión. Los vínculos 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 se encuentran 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 hablantes IGMP (hosts y enrutadores) en el mismo dominio de aprendizaje, ld1, P-A y S-A vinculados deben aparecer como un solo conmutador.

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

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

Esta discusión asume que el vínculo de interchasis ICL1 corresponde al dominio de aprendizaje ld1 y el vínculo de interchasis ICL2 corresponde al dominio de aprendizaje ld2.

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

Reenvío de datos con aprendizaje calificado

En esta discusión, se asume un dominio de aprendizaje (LD), ld1, y además se 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 los hosts conectados al enrutador S-A (que es el no DR) en el vínculo de una sola conexión como I2, I4 (que pertenece 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 vínculo de interchasis ICL1 al enrutador S-A para ser entregado a los vínculos que han reportado interés en s,g o los vínculos que están orientados hacia el enrutador en el dominio de aprendizaje LD1.

Cuando el tramo ae0 de la interfaz en el enrutador P-A deja de funcionar, los hosts conectados al vínculo multichasis reciben tráfico de la interfaz I1 mediante el vínculo de interchasis ICL1. En el enrutador S-A, el tráfico recibido en el vínculo de interchasis ICL1 se envía a los vínculos de varios chasis en la lista de interfaces de salida para los cuales la contraparte de Ethernet agregada en el enrutador P-A no funciona.

Además, se supone 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 de varios chasis (en modo a-a) y, por lo tanto, no hay vínculo de interchasis en el dominio de aprendizaje ld3.

Grupos estáticos en interfaces de conexión única

En el caso de los vínculos de varios chasis, 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 una sola conexión entre el chasis. Sin embargo, la adición de interfaces lógicas a la lista predeterminada de interfaces de salida admite la entrega de tráfico a la interfaz dentro de una configuración estática.

Interfaces orientadas al enrutador como vínculos de múltiples chasis

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

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

Se proporciona la siguiente compatibilidad MC-LAG para la supervisión IGMP en IRB:

• Espionaje sin proxy

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

• Supervisión IGMP en un conmutador de capa 2 puro

• Espionaje IGMP en dominios de puente que realizan aprendizaje calificado

• Interfaz orientada al enrutador MC-Links

Se not admiten las siguientes características:

• Modo proxy para activo-activo

• Soporte MC-LAG para instancias VPLS

• Puertos de troncalización como vínculos de múltiples chasis

• Agregar interfaces lógicas a 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 de 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 de CoS debe ser la misma en ambos conmutadores MC-LAG, ya que los MC-LAG no llevan información de clase de reenvío ni de 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 de FCoE en una topología de red de U invertida . La figura 3 muestra una topología de U invertida con conmutadores QFX3500.

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

Los conmutadores independientes admiten MC-LAG. Las configuraciones de chasis virtual y de estructura del chasis virtual (VCF) de modo mixto no admiten FCoE. Solo los VCF QFX5100 puros (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 miembros de un MC-LAG actúan como puertos de conmutación de tránsito de paso.

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

• Los dos conmutadores que forman el MC-LAG (conmutadores S1 y S2) no pueden usar puertos que formen parte de una estructura de puerta de enlace FCoE-FC. Los puertos del conmutador MC-LAG deben ser puertos de conmutación de tránsito de paso (se utilizan como parte de un conmutador de tránsito intermedio que no está conectado directamente a los hosts FCoE).

• Los conmutadores MC-LAG S1 y S2 no se pueden conectar directamente a los hosts de 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. Conmutadores de tránsito FCoE TS1 y TS2 pueden ser conmutadores independientes.

• Los conmutadores de tránsito TS1 y TS2 deben usar puertos de conmutación de tránsito para los hosts FCoE y para los LAG estándar para los conmutadores MC-LAG S1 y S2.

• Habilite la supervisión de FIP en la VLAN de FCoE en los conmutadores de tránsito TS1 y TS2. Puede configurar la supervisión de FIP de VN_Port a VF_Port (VN2VF_Port) o la supervisión de FIP de VN_Port a VN_Port (VN2VN_Port), dependiendo de si los hosts de FCoE necesitan acceder a destinos en la SAN FC (VN2VF_Port supervisión FIP) o a destinos en la red Ethernet (VN2VN_Port supervisión 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 de FIP en los conmutadores S1 y S2 de MC-LAG. (No habilite la supervisión de 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 QFX10000 no admiten la supervisión de FIP; por lo tanto, no se pueden utilizar como conmutadores de acceso de supervisión FIP (conmutadores de tránsito TS1 y TS2) en esta topología.

• La configuración de CoS debe ser coherente en los conmutadores MC-LAG. Dado que los MC-LAG no llevan información de clase o prioridad de reenvío, 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)

Supervisión de FIP y puertos de confianza de FCoE

Para mantener un acceso seguro, habilite la supervisión de FIP VN2VF_Port o la supervisión de FIP VN2VN_Port en los puertos de acceso del conmutador de tránsito conectados directamente a los hosts FCoE. La supervisión 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 de FCoE en los conmutadores de tránsito TS1 y TS2 que incluyen los puertos de acceso conectados a los hosts de FCoE.

No habilite la supervisión de 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 de FCoE en los conmutadores S1 y S2.

Configure los vínculos entre conmutadores como puertos de confianza de FCoE para reducir la sobrecarga de supervisión de FIP y garantizar que el sistema realice la supervisión de 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 de FCoE, configure los puertos MC-LAG del conmutador S1 y S2 conectados a los conmutadores TS1 y TS2 como puertos de confianza de FCoE y configure los puertos en el LAG que conecta los conmutadores S1 a S2 como puertos de confianza de FCoE.

CoS y puente de centro de datos (DCB)

Los vínculos MC-LAG no contienen información de clase de reenvío ni de prioridad. 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érdida:

• Nombre de 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 de FCoE: por ejemplo, la clase de reenvío se puede asignar a la cola 3 en ambos conmutadores MC-LAG (la fcoe cola 3 es la asignación predeterminada para la fcoe clase de reenvío).

• Clasificador: la clase de reenvío para el tráfico de 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 a un 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 de 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 se programen recursos suficientes para admitir un transporte sin pérdidas para el tráfico de FCoE esperado.

El protocolo de descubrimiento de capa de vínculo (LLDP) y el protocolo de intercambio de capacidades 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).

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

Use 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 de 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 EVPN, y PE2 y PE3 son pares MC-LAG. Ambos conjuntos de pares intercambian información de control y reenvían tráfico entre sí, lo que genera problemas. En la tabla 2 , se describen los problemas que surgen y cómo Juniper Networks resuelve los problemas en su implementación de la función de interfuncionamiento EVPN-MPLS.

Horizonte dividido

En los casos de uso mostrados en la Figura 4 y la Figura 5, el horizonte dividido impide que varias copias de un paquete BUM se reenvíen 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 genera un problema. En la Tabla 3 , se explica el problema y cómo Juniper Networks lo resuelve en su implementación de la característica de interfuncionamiento EVPN-MPLS.

Aprendizaje de MAC

EVPN y MC-LAG utilizan el mismo método para aprender direcciones MAC, es decir, un dispositivo de 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 del interfuncionamiento EVPN-MPLS lo previene. 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 EVPN, y PE2 y PE3 son pares MC-LAG.

Manejo de vínculos descendentes entre puertos de cascada y ascendentes en Junos Fusion Enterprise

En el 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 en PE2 y el puerto de enlace ascendente correspondiente en el dispositivo satélite SD1 está inactivo. Independientemente de si el paquete BUM lo maneja MC-LAG o la multiconexión activa-activa de EVPN, 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 doble conexión.

Para ilustrar mejor 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 inactivo, y que la interfaz no DF reside en PE3. Por lo general, por EVPN con lógica de reenvío activo-activo de multiconexión, la interfaz que no es DF deja caer 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 no DF en PE3 reenvía el paquete a SD1.

Soporte de 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 extendidos y VLAN:

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

• Puertas de enlace de capa 3 predeterminadas 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.

Comportamiento de MC-LAG específico de la plataforma