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.
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.
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.
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.
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:
|
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. |
|
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.
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). |
|
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.
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. |
|
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. |
|
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
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.