Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción de EVPN-MPLS intertrabajando con Junos Fusion Enterprise y MC-LAG

A partir de Junos OS versión 17.4R1, puede usar VPN Ethernet (EVPN) para extender una red de Junos Fusion Enterprise o un grupo de agregación de vínculos multichasis (MC-LAG) a través de una red MPLS a una red de centro de datos o campus. Con la introducción de esta función, ahora puede interconectar sitios de campus y centros de datos dispersos para formar un único puente virtual de capa 2.

La Figura 1 muestra una topología de Junos Fusion Enterprise con dos conmutadores EX9200 que sirven como dispositivos de agregación (PE2 y PE3) a los que los dispositivos satelitales están multihomedes. Los dos dispositivos de agregación usan un vínculo de interchasis (ICL) y el protocolo de control entre chasis (ICCP) de MC-LAG para conectar y mantener la topología empresarial de Junos Fusion. PE1 en el entorno EVPN-MPLS inter trabaja con PE2 y PE3 en Junos Fusion Enterprise con MC-LAG.

Figura 1: EVPN-MPLS intertrabajando con Junos Fusion Enterprise EVPN-MPLS Interworking with Junos Fusion Enterprise

La Figura 2 muestra una topología MC-LAG en la que ce1 del dispositivo de borde del cliente (CE) está multihomeado a PE2 y PE3. PE2 y PE3 usan una ICL y el protocolo ICCP de MC-LAG para conectar y mantener la topología. PE1 en el entorno EVPN-MPLS interworks con PE2 y PE3 en el entorno MC-LAG.

Figura 2: EVPN-MPLS intertrabajando con MC-LAG EVPN-MPLS Interworking with MC-LAG

A lo largo de este tema, la Figura 1 y la Figura 2 sirven como referencias para ilustrar varios escenarios y puntos.

Los casos de uso que se muestran en la Figura 1 y la Figura 2 requieren la configuración de la multiconexión de EVPN en modo activo-activo y MC-LAG en PE2 y PE3. EVPN con multiconexión activo-activo y MC-LAG tienen su propia lógica de reenvío para manejar el tráfico, en particular, el tráfico de difusión, unidifusión desconocida y multidifusión (BUM). A veces, la lógica de reenvío de EVPN con multiconexión activo-activo y MC-LAG se contradigan entre sí y causan problemas. En este tema, se describen los problemas y cómo la función de intertrabajo de EVPN-MPLS resuelve estos problemas.

Nota:

Además de las implementaciones específicas para el trabajo de EVPN-MPLS descritas en este tema, EVPN-MPLS, Junos Fusion Enterprise y MC-LAG ofrecen la misma funcionalidad y función que las funciones independientes.

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

Utilice EVPN-MPLS con Junos Fusion Enterprise y MC-LAG para interconectar sitios dispersos de campus y centros 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 1 y la Figura 2, 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ía tráfico entre sí, lo que causa problemas. La Tabla 1 describe los problemas que surgen y cómo Juniper Networks resuelve los problemas en su implementación de la función de intertrabajo de EVPN-MPLS.

Tabla 1: Tráfico BUM: problemas y resoluciones

Dirección de tráfico BUM

EVPN intertrabajar con Junos Fusion Enterprise y mc-LAG Logic

Problema

Enfoque de implementación de Juniper Networks

Encuadernado norte (PE2 recibe paquete BUM de una interfaz de inicio único o dual conectada localmente).

PE2 inunda el paquete BUM a lo siguiente:

  • Todas las interfaces conectadas localmente, incluida la ICL, para un dominio de difusión en particular.

  • Todos los pares remotos de EVPN para los que PE2 ha recibido rutas de multidifusión inclusivas.

Entre PE2 y PE3, hay dos rutas de reenvío BUM: la ICL MC-LAG y una ruta EVPN-MPLS. Las múltiples rutas de reenvío dan como resultado la duplicación de paquetes y bucles.

  • El tráfico BUM se reenvía solo en la ICL.

  • El tráfico entrante desde el núcleo de EVPN no se reenvía en la ICL.

  • El tráfico entrante desde la ICL no se reenvía al núcleo de EVPN.

Rumbo sur (PE1 reenvía el paquete BUM a PE2 y PE3).

Pe2 y PE3 reciben una copia del paquete BUM e inundan el paquete de todas sus interfaces locales, incluida la ICL.

Pe2 y PE3 reenvía el paquete BUM fuera de la ICL, lo que da como resultado la duplicación de paquetes y bucles.

Horizonte dividido

En los casos de uso que se muestran en la Figura 1 y la Figura 2, 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 contradigan entre sí, lo que causa un problema. En la tabla 2 se explica el problema y cómo Juniper Networks lo resuelve en su implementación de la función de intertrabajo de EVPN-MPLS.

Tabla 2: Tráfico BUM: problema y resolución relacionados con el horizonte dividido

Dirección de tráfico BUM

EVPN intertrabajar con Junos Fusion Enterprise y mc-LAG Logic

Problema

Enfoque de implementación de Juniper Networks

En dirección norte (PE2 recibe el paquete BUM de una interfaz de doble homed conectada localmente).

  • Por lógica de reenvío de EVPN-MPLS:

    • Solo el reenviador designado (DF) para el segmento de Ethernet (ES) puede reenviar tráfico BUM.

    • No se admite la regla de desviación local, en la que el par local reenvía el paquete BUM y el par remoto lo deja caer.

  • Según la lógica de reenvío DE MC-LAG, se admite la desviación local.

La lógica de reenvío de EVPN-MPLS y MC-LAG se contradigan entre sí y pueden evitar que el tráfico BUM se reenvíe al ES.

Admite la desviación local, lo que ignora el estado de DF y no DF del puerto para el tráfico conmutado localmente.

Rumbo sur (PE1 reenvía el paquete BUM a PE2 y PE3).

El tráfico recibido de PE1 sigue las reglas de reenvío df y no DF de EVPN para un ES mulitomed.

Ninguno.

No se aplica.

Aprendizaje de MAC

EVPN y MC-LAG usan 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 sincronizan las direcciones, surge un problema.

La tabla 3 describe el problema y cómo la implementación de intertrabajo de EVPN-MPLS evita el problema. Los casos de uso que se muestran en la figura 1 y la figura 2 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.

Tabla 3: Aprendizaje de MAC: Problema de sincronización de EVPN y MC-LAG y detalles de implementación

Caso de uso de sincronización MAC

EVPN intertrabajar con Junos Fusion Enterprise y mc-LAG Logic

Problema

Enfoque de implementación de Juniper Networks

Direcciones MAC aprendidas localmente en interfaces de inicio único o doble en PE2 y PE3.

  • Entre los pares de EVPN, las direcciones MAC se sincronizan mediante el plano de control BGP de EVPN.

  • Entre los pares de MC-LAG, las direcciones MAC se sincronizan mediante el plano de control ICCP MC-LAG.

PE2 y PE3 funcionan como pares de EVPN y MC-LAG, lo que da como resultado que estos dispositivos tengan varias rutas de sincronización MAC.

  • Para PE1: utilice direcciones MAC sincronizadas por el plano de control BGP de EVPN.

  • Para PE2 y PE3: utilice direcciones MAC sincronizadas por el plano de control ICCP MC-LAG.

Direcciones MAC aprendidas localmente en interfaces de inicio único o doble en PE1.

Entre los pares de EVPN, las direcciones MAC se sincronizan mediante el plano de control BGP de EVPN.

Ninguno.

No se aplica.

Gestión de enlace descendente entre los puertos en cascada y uplink en Junos Fusion Enterprise

Nota:

Esta sección solo se aplica a EVPN-MPLS que intertrabaje con junos Fusion Enterprise.

En junos Fusion Enterprise que se muestra en la figura 1, 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 satelital SD1 está inactivo. Independientemente de si el paquete BUM es gestionado por MC-LAG o EVPN multiconexión 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 doble casa.

Para ilustrar aún más cómo EVPN con multiconexión activo-activo maneja esta situación con SD1 de doble casa, 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. Por lo general, por EVPN con lógica de reenvío activo-activo multiconexión, la interfaz no 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 que no es DF en PE3 reenvía el paquete a SD1.

Soporte de puerta de enlace de capa 3

La función de intertrabajo de 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 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 una máquina virtual en otro dominio de puente extendido o VLAN.

Tabla de historial de versiones
Lanzamiento
Descripción
17.4R1
A partir de Junos OS versión 17.4R1, puede usar VPN Ethernet (EVPN) para extender una red de Junos Fusion Enterprise o un grupo de agregación de vínculos multichasis (MC-LAG) a través de una red MPLS a una red de centro de datos o campus.