Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

A partir de Junos OS versión 17.4R1, puede utilizar Ethernet VPN (EVPN) para extender una red de Junos Fusion Enterprise o de 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 característica, ahora puede interconectar campus dispersos y sitios de centros de datos 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 satélite son de multiconexión. Los dos dispositivos de agregación utilizan un vínculo entre chasis (ICL) y el protocolo de protocolo de control entre chasis (ICCP) de MC-LAG para conectar y mantener la topología de Junos Fusion Enterprise. PE1 en el entorno EVPN-MPLS interfunciona con PE2 y PE3 en Junos Fusion Enterprise con MC-LAG.

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

La figura 2 muestra una topología MC-LAG en la que el dispositivo perimetral del cliente (CE) CE1 es multihost para PE2 y PE3. PE2 y PE3 utilizan una ICL y el protocolo ICCP de MC-LAG para conectar y mantener la topología. PE1 en el entorno EVPN-MPLS interfunciona con PE2 y PE3 en el entorno MC-LAG.

Figura 2: Interfuncionamiento de EVPN-MPLS 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 representados en las figuras 1 y 2 requieren la configuración tanto de multiconexión de EVPN en modo activo-activo como de MC-LAG en PE2 y PE3. EVPN con multiconexión activa-activa 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 para EVPN con multiconexión activa-activa y MC-LAG se contradicen entre sí y causan problemas. En este tema se describen los problemas y cómo la función de interfuncionamiento EVPN-MPLS los resuelve.

Nota:

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

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 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ían tráfico entre sí, lo que causa problemas. En la Tabla 1 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.

Tabla 1: Tráfico BUM: problemas y soluciones

Dirección de tráfico BUM

Interfuncionamiento de EVPN con Junos Fusion Enterprise y MC-LAG Logic

Emitir

Enfoque de implementación de Juniper Networks

Enlazado al norte (PE2 recibe un paquete BUM de una o dos interfaces de base única o doble conectadas localmente).

PE2 inunda el paquete BUM a lo siguiente:

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

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

Entre PE2 y PE3, hay dos rutas de reenvío de 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 solo se reenvía en la ICL.

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

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

Hacia el 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ían el paquete BUM fuera de la ICL, lo que da lugar a duplicación de paquetes y bucles.

Horizonte dividido

En los casos de uso que se muestran en las figuras 1 y 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 contradicen entre sí, lo que provoca 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 interfuncionamiento EVPN-MPLS.

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

Dirección de tráfico BUM

Interfuncionamiento de EVPN con Junos Fusion Enterprise y MC-LAG Logic

Emitir

Enfoque de implementación de Juniper Networks

Enlazado al norte (PE2 recibe el paquete BUM desde una interfaz de base dual conectada localmente).

  • Según la lógica de reenvío EVPN-MPLS:

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

    • No se admite la regla de sesgo local, en la que el par local reenvía el paquete BUM y el par remoto lo descarta.

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

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

Admitir sesgo local, ignorando así el estado DF y no DF del puerto para el tráfico conmutado localmente.

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

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

Ninguno.

No aplica.

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 3 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 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: problemas de sincronización de EVPN y MC-LAG y detalles de implementación

Caso de uso de sincronización de MAC

Interfuncionamiento de EVPN con Junos Fusion Enterprise y MC-LAG Logic

Emitir

Enfoque de implementación de Juniper Networks

Direcciones MAC aprendidas localmente en interfaces de base única 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 MC-LAG, las direcciones MAC se sincronizan mediante el plano de control ICCP MC-LAG.

PE2 y PE3 funcionan como pares de EVPN y pares de 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 base única o doble en PE1.

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

Ninguno.

No aplica.

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

Nota:

Esta sección solo se aplica al interfuncionamiento EVPN-MPLS 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 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.

Tabla de historial de cambios

La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.

Lanzamiento
Descripción
17.4R1
A partir de Junos OS versión 17.4R1, puede utilizar Ethernet VPN (EVPN) para extender una red de Junos Fusion Enterprise o de 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.