Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general de Multihoming EVPN

Introducción a la multiconexión de EVPN

Una VPN Ethernet (EVPN) se compone de dispositivos perimetrales del cliente (CE) que están conectados a dispositivos perimetrales del proveedor (PE), que forman el borde de la infraestructura MPLS. Un dispositivo CE puede ser un host, un enrutador o un conmutador. Los dispositivos PE proporcionan conectividad de puente virtual de capa 2 entre los dispositivos CE. Puede haber varios EVPN en la red del proveedor. El aprendizaje entre los enrutadores PE se produce en el plano de control mediante BGP, a diferencia del puente tradicional, en el que el aprendizaje se produce en el plano de datos.

Nota:

En versiones anteriores a Junos OS versión 15.1, la compatibilidad con la funcionalidad EVPN en enrutadores de la serie MX se limitaba únicamente a enrutadores que utilizaban interfaces MPC y MIC. A partir de Junos OS versión 15.1, los enrutadores de la serie MX que utilizan DPC se pueden aprovechar para proporcionar compatibilidad con EVPN en la interfaz orientada al dispositivo CE.

La compatibilidad de DPC con EVPN se proporciona con las siguientes consideraciones:

  • Los CPD proporcionan compatibilidad con EVPN en el modo de funcionamiento en espera activa, incluida la compatibilidad con lo siguiente:

    • Instancia de EVPN (EVI)

    • Conmutador virtual

    • Interfaces de enrutamiento y puente integrados (IRB)

  • Los CPC destinados a proporcionar la compatibilidad con el modo de espera activo de EVPN deben ser la tarjeta de línea orientada hacia el dispositivo CE. El dispositivo PE en el dominio EVPN deben ser interfaces MPC o interfaces MIC.

La función de multiconexión de EVPN le permite conectar un sitio de cliente a dos o más dispositivos PE para proporcionar conectividad redundante. Un dispositivo CE puede ser multihost a diferentes dispositivos PE o al mismo dispositivo PE. Un dispositivo de PE redundante puede proporcionar servicio de red al sitio del cliente tan pronto como se detecte una falla. Por lo tanto, la multiconexión de EVPN ayuda a mantener el servicio EVPN y el reenvío de tráfico hacia y desde el sitio de multiconexión en caso de que se produzcan los siguientes tipos de errores de red:

  • Error de vínculo de dispositivo PE a dispositivo CE

  • Error del dispositivo de PE

  • Error de accesibilidad de MPLS entre el dispositivo de PE local y un dispositivo de PE remoto

La Figura 1 ilustra cómo un dispositivo CE puede multihost a dos enrutadores PE. El dispositivo CE 1 es de multiconexión en los enrutadores PE 1 y PE 2. El dispositivo CE 2 tiene dos rutas potenciales para llegar al dispositivo CE 1 y, dependiendo del modo de redundancia multiconexión, solo una ruta o ambas rutas están activas en cualquier momento. El modo de operación de multiconexión también determina qué enrutador o enrutadores PE reenvían el tráfico al dispositivo CE. El tráfico de reenvío del enrutador PE al dispositivo CE (también denominado reenviador designado) utiliza túneles MPLS LSP o GRE para reenviar el tráfico. Si se produce un error en esta ruta, se elige un nuevo reenviador designado para reenviar el tráfico al dispositivo CE 1.

Figura 1: Dispositivo CE multihost a dos enrutadores CE Device Multihomed to Two PE Routers PE

Múltiples funciones de MPLS EVPN compatibles con los conmutadores QFX10000

A partir de Junos OS 17.4R1, los conmutadores QFX10000 admiten multiconexión para MPLS EVPN. Solo se admite el multihoming activo-activo. Se admiten las siguientes subcaracterísticas:

  • Configuración de ESI (solo se admiten la configuración manual de tipo 0 e IFD (interfaces físicas))

  • Uso de alias y ruta de etiquetas

  • Ruta EVPN tipo 4 (ruta de segmento Ethernet)

  • Comunidades extendidas

  • Tráfico BUM

  • Roles de elección de reenviador designado (DF): DF y BDF

QFX10000 conmutadores a través de un núcleo MPLS EVPN solo admiten la instancia de enrutamiento del conmutador predeterminada. No se admite una instancia de EVPN (EVI).

Multiconexión MPLS EVPN en enrutadores ACX5448

A partir de Junos OS versión 19.4R1, los enrutadores ACX5448 admiten multiconexión para MPLS EVPN. Solo se admite el multihoming activo-activo. Para habilitar el multihoming activo-activo de EVPN en ACX5448 enrutador, incluya la instrucción de evpn-mh-profile configuración en el nivel de jerarquía [edit system packet-forwarding-options firewall-profile].

Nota:

Después de cambiar el perfil y confirmarlo, debe reiniciar el proceso de administración del chasis emitiendo el comando de la restart chassis-control CLI para abrir el nuevo perfil.

Aparece una advertencia syslog para reiniciar el PFE.

Descripción de los conceptos de multiconexión de EVPN

La figura 2 muestra una topología de red EVPN simple para definir conceptos de multiconexión de EVPN.

Figura 2: Topología Simple EVPN Topology EVPN simple
  • Ethernet segment—Cuando un dispositivo CE es multiconexión a dos o más enrutadores PE, el conjunto de vínculos Ethernet constituye un segmento Ethernet. Un segmento Ethernet aparece como un grupo de agregación de vínculos (LAG) al dispositivo CE.

    Los vínculos de los enrutadores PE1 y PE2 al dispositivo CE1 forman un segmento Ethernet.

    En el multihoming en espera activa, los vínculos que constituyen un segmento Ethernet forman un dominio de puente. En el multihoming activo-activo, un segmento Ethernet aparece como LAG para el dispositivo CE.

  • ESI: un segmento Ethernet debe tener un identificador único distinto de cero, denominado identificador de segmento Ethernet (ESI). El ESI está codificado como un entero de 10 octetos. Cuando se configura manualmente un valor ESI, el octeto más significativo, conocido como byte de tipo, debe ser 00. Cuando se conecta un dispositivo CE de base única a un segmento Ethernet, todo el valor de ESI es cero.

    El segmento Ethernet del dispositivo multihost CE1 tiene asignado un valor ESI de 00:11:22:33:44:55:66:77:88:99. El dispositivo de base única CE2 tiene un valor ESI de 0.

  • EVI—Una instancia de EVPN (EVI) es una instancia de enrutamiento y reenvío de EVPN que abarca todos los enrutadores PE que participan en esa VPN. Un EVI se configura en los enrutadores de PE por cliente. Cada EVI tiene un diferenciador de ruta único y uno o más objetivos de ruta.

    Un EVI se configura en los enrutadores PE1, PE2 y PE3.

  • Ethernet tag: una etiqueta Ethernet identifica un dominio de difusión determinado, como una VLAN. Una instancia de EVPN consta de uno o más dominios de difusión. El proveedor de esa EVPN asigna etiquetas Ethernet a los dominios de difusión de una instancia de EVPN determinada. Cada enrutador PE de esa instancia de EVPN realiza una asignación entre los identificadores de dominio de difusión que entiende cada uno de sus dispositivos CE conectados y la etiqueta Ethernet correspondiente.

  • Ethernet segment route (EVPN Type 4 route)—Los enrutadores PE que están conectados a un dispositivo CE de multihost utilizan mensajes de ruta de segmento Ethernet BGP para descubrir que cada uno de los enrutadores PE está conectado al mismo segmento Ethernet. Los enrutadores PE anuncian la ruta del segmento Ethernet, que consiste en una comunidad extendida de importación de ESI y ES.

    Los enrutadores PE1 y PE2 anuncian una ruta ES con una comunidad extendida de importación de ES (junto con otras comunidades extendidas como el destino de ruta). Los enrutadores PE también construyen un filtro basado en una comunidad extendida de importación ES, lo que da como resultado que solo estos enrutadores PE importen la ruta ES e identifiquen que están conectados al mismo segmento Ethernet.

  • Extended communityUna comunidad extendida es similar en muchos aspectos a una comunidad regular. Las EVPN usan comunidades extendidas porque el valor de comunidad regular de 4 octetos no proporciona suficiente expansión y flexibilidad. Una comunidad extendida es un valor de 8 octetos dividido en dos secciones principales.

  • BUM traffic: este tipo de tráfico se envía a varios destinos, incluido el tráfico de difusión, el tráfico de unidifusión desconocido que se difunde en el segmento Ethernet y el tráfico de multidifusión.

  • DF: cuando un dispositivo CE es multihost en dos o más enrutadores PE, se utilizan uno o todos los enrutadores de PE multihost para llegar al sitio del cliente, según el modo de operación de multiconexión. El enrutador PE que asume la función principal para reenviar el tráfico BUM al dispositivo CE se denomina reenviador designado (DF).

  • BDF—Cada enrutador del conjunto de otros enrutadores PE que anuncian la ruta de autodescubrimiento por segmento Ethernet para el mismo ESI, y que sirve como ruta de respaldo en caso de que el DF encuentre una falla, se denomina reenviador designado de respaldo (BDF). Un BDF también se denomina enrutador que no es DF.

  • DF election—En cada segmento de Ethernet, los enrutadores PE participan en un procedimiento denominado elección del reenviador designado para seleccionar los enrutadores PE DF y BDF.

Modo de operación de multiconexión EVPN

Los diferentes modos de operación para la multiconexión de EVPN incluyen:

  • Único: cuando un enrutador PE está conectado a un sitio de cliente de base única, este modo está en funcionamiento. El modo único es el modo de operación predeterminado y no requiere la configuración de valores de segmento Ethernet.

  • En espera activa: cuando solo un enrutador PE, entre un grupo de enrutadores PE conectados a un segmento Ethernet, puede reenviar tráfico hacia y desde ese segmento Ethernet, se define que el segmento Ethernet funciona en el modo de redundancia en espera activa .

    Para configurar el modo de espera activa, incluya el valor ESI y la single-active instrucción en el nivel de [edit interfaces] jerarquía.

    Nota:

    No se admite el modo de multiconexión en espera activa en conmutadores de la serie QFX ni en configuraciones de EVPN con superposiciones VXLAN. Como resultado, si configura la opción en conmutadores de la single-active serie QFX o en configuraciones de EVPN-VXLAN, el dispositivo ignora ese elemento de configuración.

  • Activo-activo: cuando a todos los enrutadores PE conectados a un segmento Ethernet se les permite reenviar tráfico hacia y desde el segmento Ethernet, se define que el segmento Ethernet funciona en el modo de redundancia activo-activo .

    Nota:

    En Junos OS versión 14.2 y anteriores, el conmutador serie EX9200 solo admite el modo de operación en espera activa para la multiconexión EVPN.

    Nota:

    A partir de Junos OS versión 14.1x53-D30 para conmutadores QFX5100 y Junos OS versión 18.2R1 para conmutadores EX4600, estos conmutadores admiten el modo de operación activo-activo para multiconexión EVPN. En este escenario, los conmutadores QFX5100 y EX4600 funcionan como conmutadores de la parte superior del rack (ToR) en el centro de datos para redes virtuales. La funcionalidad activa/activa de multiconexión EVPN se utiliza para proporcionar acceso a los servidores sin sistema operativo conectados a los conmutadores de la parte superior del rack.

    Nota:

    A partir de Junos OS versión 14.1R4, 14.2, 15.1F6 y 16.1R1, Junos OS admite el modo activo-activo para multiconexión EVPN en enrutadores de la serie MX.

    A partir de Junos OS versiones 16.1R4 y 16.2R2, todos los conmutadores EX9200 admiten el modo activo-activo para multiconexión EVPN.

    A partir de Junos OS versión 17.4R1, los conmutadores QFX10000 admiten el modo activo-activo para multiconexión EVPN.

    Para configurar el modo activo-activo, incluya el valor ESI y la all-active instrucción en el nivel de [edit interfaces] jerarquía.

    La figura 3 muestra una topología de referencia para el multihoming activo-activo de EVPN. El segmento Ethernet ESI1 para el dispositivo CE2 es multihost para los enrutadores PE1, PE2 y PE3. El segmento Ethernet en el dispositivo CE se puede configurar como un grupo de agregación de vínculos (LAG) o como una ruta ECMP. Los dispositivos CE1 y CE3 son los dispositivos perimetrales de cliente de base única y tienen un valor ESI de 0.

Figura 3: Multiconexión Active-Active EVPN Multihoming de EVPN activo-activo

Implementación de EVPN Multihoming

El modo de operación de multiconexión en espera activa de EVPN proporciona redundancia para errores de vínculo de acceso y de nodo PE para el dispositivo CE de multiconexión, y se basa en el borrador de EVPN-ietf-l2vpn-evpn-03.

La implementación de Junos OS de los modos de operación activo-espera y activo-activo de multiconexión EVPN incluye lo siguiente:

Nuevas NLRI BGP

Para admitir la multiconexión de EVPN, se han introducido las siguientes rutas nuevas de información de accesibilidad de capa de red (NLRI) BGP:

Ruta de detección automática por segmento de Ethernet

Características de la ruta de detección automática

Las características de la NLRI de la ruta de descubrimiento automático incluyen:

  • Esta es una ruta obligatoria de Tipo 1, utilizada para una convergencia rápida y para publicitar la etiqueta de horizonte dividido. También se conoce como la ruta de retirada masiva.

  • Los distinguidores de ruta de tipo 1 se utilizan con la dirección IP (circuito cerrado) del enrutador PE de origen como valor de diferenciador de ruta.

  • Esta ruta lleva el ESI en el NLRI (distinto de cero cuando se trata de un PE multiconexión, cero en caso contrario).

  • La etiqueta de horizonte dividido es solo por ESI y lleva un NULL explícito (0).

  • El bit en el campo de indicador de espera activa de la comunidad extendida de la etiqueta ESI se utiliza para señalar el modo de espera activa (conjunto de bits).

  • Los valores de etiqueta de 3 bytes en la etiqueta NLRI y Ethernet son cero.

  • Esta ruta es anunciada e importada por todos los enrutadores de PE remotos y de multiconexión que comparten el mismo EVI en el ESI publicitario.

Anuncio de ruta de descubrimiento automático
  • Modo de espera activa

    En el modo de espera activa, el reenviador designado (DF) anuncia la ruta de detección automática por segmento de Ethernet con una etiqueta ESI MPLS de comunidad extendida que tiene el bit de espera establecido en 1. La ruta de detección automática se anuncia según ESI y la etiqueta ESI se establece en 0 cuando el modo de espera activa está en funcionamiento.

    La ruta de detección automática es importada por todos los enrutadores de PE remotos y de multiconexión que forman parte del EVI. Al recibir la ruta de detección automática, los enrutadores PE de la topología de red aprenden que el modo de multiconexión en espera activa está en funcionamiento para el ESI anunciado.

  • Modo activo-activo

    En el modo activo-activo, cada uno de los dispositivos PE multihost anuncia una ruta de detección automática obligatoria por segmento de Ethernet como en el estado de espera activa. Sin embargo, en el estado activo-activo, la ruta de detección automática por segmento de Ethernet se modifica de forma que el bit de espera activo que se lleva en la comunidad extendida de MPLS se borra para indicar que el modo activo-activo está en funcionamiento. La ruta de detección automática por segmento de Ethernet en el modo activo-activo también incluye la etiqueta de horizonte dividido.

    En la figura 3, para el segmento Ethernet ESI1, los enrutadores PE1, PE2 y PE3 anuncian la ruta de detección automática. El enrutador PE4 recibe esta ruta de detección automática.

Retiro de ruta de descubrimiento automático

La ruta de detección automática por retirada del segmento Ethernet puede dar lugar a una retirada masiva. La función de retiro masivo se utiliza cuando hay una falla de vínculo en el ESI o cuando cambia la configuración de ESI.

Cuando falla el vínculo entre un dispositivo CE multihost y un dispositivo PE multihogar, el dispositivo PE retira la ruta de autodescubrimiento por segmento Ethernet. En tal caso, la función de extracción masiva es manejada de las siguientes maneras por los otros dispositivos PE:

  • Dispositivo de PE remoto

    Cuando un dispositivo de PE remoto recibe la actualización de BGP para retiro masivo, se realiza lo siguiente en el dispositivo de PE remoto:

    1. Se elimina el siguiente salto actual para llegar al dispositivo ESI o CE remoto.

    2. Se crea un nuevo salto siguiente a través de los dispositivos PE multihost restantes para llegar al dispositivo ESI o CE remoto.

    3. Todas las rutas MAC detrás del dispositivo CE se actualizan con el siguiente salto recién creado.

    A partir de Junos OS versión 17.4R1, Junos OS admite los próximos saltos de lista dinámica en una red EVPN. Ahora, cuando falla el enlace entre el dispositivo CE y un dispositivo PE multihogar, se actualiza el siguiente salto al ESI o CE, lo que reduce la necesidad de un retiro masivo. Para obtener más información sobre cómo habilitar el próximo salto de lista dinámica, consulte Configuración del próximo salto de lista dinámica.

  • Otro dispositivo de PE multihost

    Como resultado de la extracción masiva, el equilibrio de carga en el dispositivo CE de host múltiple ocurre debido a lo siguiente:

    • Cuando los otros dispositivos PE multihost reciben el mismo conjunto de direcciones MAC en el enlace al ESI en cuestión.

      En este caso, se prefieren las rutas locales. Si se retiran las rutas remotas aprendidas del dispositivo DF PE, no afectará a las rutas que apuntan al ESI local.

    • Cuando los otros dispositivos de PE de host múltiple no han recibido el mismo conjunto de direcciones MAC en el enlace al ESI en cuestión.

      En este caso, los dispositivos PE instalan las rutas MAC que apuntan al ESI en cuestión, aunque los MAC se aprenden remotamente desde el dispositivo DF PE. Cuando el dispositivo de PE DF retira estas rutas, las rutas retiradas se vacían. Los paquetes destinados a las direcciones MAC vacías se inundan en todos los segmentos locales.

Ruta de segmento Ethernet

Características de la ruta por segmentos Ethernet

Las características de NLRI de enrutamiento de segmento Ethernet incluyen:

  • Esta es una ruta EVPN tipo 4. El propósito de esta ruta es permitir que los enrutadores PE conectados al mismo segmento Ethernet se descubran automáticamente entre sí con una configuración mínima al intercambiar esta ruta.

  • Esta ruta está asociada a una comunidad extendida de importación de ES con un valor ESI condensado en 6 bytes, similar a un destino de ruta.

  • Esta ruta es anunciada e importada solo por enrutadores PE que son multihost en el segmento Ethernet publicitario.

Anuncio de ruta de segmento Ethernet

La ruta del segmento Ethernet se intercambia entre todos los enrutadores PE dentro de un centro de datos con la comunidad extendida ES-import. La comunidad extendida de importación de ES se construye en función de los enrutadores PE ESI que son de multiconexión, y la ruta del segmento Ethernet lleva el valor ESI relacionado con el segmento Ethernet en el que los enrutadores PE son de multiconexión.

Las rutas de segmento Ethernet se filtran en función de la comunidad extendida ES-import, de modo que solo los enrutadores PE que tienen multihost en el mismo segmento Ethernet importan esta ruta. Cada enrutador PE que está conectado a un segmento de Ethernet determinado construye una regla de filtrado de importación para importar una ruta que lleve la comunidad extendida ES-import.

Ruta de detección automática por instancia de EVPN

En el modo activo-activo, cada uno de los dispositivos PE multihost anuncia una ruta de detección automática por instancia de EVPN (EVI) con una etiqueta MPLS válida. Esta ruta se anuncia por ESI y es importada por los dispositivos de PE remotos. La etiqueta MPLS incluida en la ruta de descubrimiento automático por EVI se utiliza posteriormente para el aliasing.

Nuevas comunidades extendidas

Una comunidad extendida es similar en muchos aspectos a una comunidad regular. Algunas implementaciones de redes, como las redes privadas virtuales (VPN), utilizan comunidades extendidas porque el valor de comunidad regular de 4 octetos no proporciona suficiente expansión y flexibilidad. Una comunidad extendida es un valor de 8 octetos dividido en dos secciones principales.

Para admitir la multiconexión en espera activa, se han introducido las siguientes comunidades ampliadas:

ESI-Import

Esta comunidad extendida se adjunta a la ruta ES y se rellena a partir del valor ESI-import extraído del valor ESI configurado en la interfaz. Para resolver el problema de un conflicto con otro objetivo de ruta regular, el tipo se establece en 0x06, que ha sido asignado por la IANA.

El destino de ruta comunitaria extendida ESI-import rellena la lista de destinos de ruta de importación configurados para la instancia especial desde la que se anuncia la ruta ES que usa esta comunidad.

Por lo tanto, los enrutadores PE importan las rutas ESI entrantes con el mismo valor de importación ESI en la comunidad extendida, si el enrutador PE está configurado con un segmento Ethernet que tiene el mismo valor ESI. Una vez que el enrutador PE recibe un conjunto de estas rutas ESI que tienen el mismo valor de comunidad extendido ESI-import, la elección de DF y BDF se puede realizar localmente.

Nota:

Cuando la comunidad extendida de importación de ESI no se crea implícitamente, se debe configurar una política para adjuntar todos los destinos de ruta a la ruta de detección automática por segmento de Ethernet.

Horizonte dividido

Con referencia a la figura 3 , por ejemplo, cuando un dispositivo CE que es multihost a dos o más dispositivos PE en un segmento Ethernet (ESI1) y que funciona en el modo de redundancia activa-activa envía un paquete BUM a uno de los dispositivos PE que no son DF (digamos PE1), el dispositivo PE1 reenvía ese paquete a todos o a un subconjunto de los otros dispositivos PE en esa instancia de EVPN, incluido el dispositivo DF PE para ese segmento de Ethernet. En este caso, el dispositivo DF PE al que el dispositivo CE está multiconexión descarta el paquete sin reenviarlo de vuelta al dispositivo CE. Este filtrado se conoce como horizonte dividido.

  • Señalización de horizonte dividido

    La comunidad extendida de horizonte dividido se adjunta a la ruta de detección automática por segmento de Ethernet. El valor de la comunidad extendida es el horizonte dividido o la propia etiqueta de Poisson, que es de 3 bytes y se anuncia como un atributo opaco.

  • Anuncio de horizonte dividido

    • En el modo de espera activa, el bit en espera de la comunidad extendida de horizonte dividido se establece en 1 y la etiqueta de horizonte dividido de ESI se establece en 0.

    • En el modo activo-activo, la comunidad extendida de horizonte dividido se modifica para borrar el bit de espera a 0 e incluye una etiqueta ESI válida utilizada para fines de horizonte dividido.

  • Rutas MPLS de horizonte dividido

    El dispositivo DF PE anuncia una ruta de detección automática por segmento de Ethernet con una etiqueta de horizonte dividido A y una ruta de multidifusión inclusiva con etiqueta B para el reenvío de tráfico BUM. En el DF, el paquete BUM del núcleo puede venir con las siguientes etiquetas:

    • Cuando los dispositivos PE que no son DF reciben un paquete BUM en sus ESI de base única, el paquete BUM se envía al dispositivo PE DF con etiqueta de multidifusión B.

    • Cuando los dispositivos PE que no son DF reciben un paquete BUM en ESI1, el paquete BUM se envía al dispositivo DF PE con dos etiquetas MPLS: la etiqueta de multidifusión B como etiqueta externa y la etiqueta de horizonte dividido A como etiqueta interna.

    En el caso de multiconexión de EVPN, la etiqueta de multidifusión B tiene el bit S establecido en 1 cuando es la única etiqueta de la pila de etiquetas. En este caso, el paquete BUM debe inundarse en todas las ESI locales del dispositivo DF PE. Pero la etiqueta B tiene el bit S establecido en 0 cuando la etiqueta de horizonte dividido A es la etiqueta más interna de la pila de etiquetas. En este caso, los paquetes BUM deben inundarse en todas las ESI locales del dispositivo DF PE, excepto en el ESI, excepto en el ESI, que se asigna a la etiqueta A del horizonte dividido.

    Suponiendo que los paquetes se originaron desde un dispositivo CE multihost a un dispositivo PE no DF en el segmento multihost ESI1, cuando el dispositivo PE sin DF envía este paquete al dispositivo DF PE, primero se inserta la etiqueta ESI que el DF anunció para el dispositivo PE no DF en su ruta de autodescubrimiento por segmento Ethernet. El dispositivo que no es de PE DF también inserta la etiqueta de multidifusión inclusiva que el dispositivo de PE de DF anunciaba en su ruta de multidifusión inclusiva y empuja aún más la etiqueta de LSP. Por lo tanto, el encabezado MPLS contiene dos etiquetas dentro de un campo de 32 bits.

    La funcionalidad básica de EVPN utiliza un salto de tabla siguiente para unir la tabla MPLS con su tabla EVPN EVI correspondiente. En la tabla EVI de EVPN, se realiza la búsqueda en mac para conmutar el paquete.

    Las siguientes rutas están programadas en la tabla mpls.0 para la multidifusión de EVPN:

    • La ruta (etiqueta de multidifusión, S=1) apunta al siguiente salto de tabla EVPN-DIVI.

    • La ruta (etiqueta de multidifusión, S=0) apunta al salto siguiente de la tabla MPLS. Esta ruta devuelve el paquete a la tabla MPLS después de hacer estallar la etiqueta de multidifusión.

    • La ruta (etiqueta de horizonte dividido) apunta al salto siguiente de la tabla EVPN-EVO. Este es el mismo salto de tabla siguiente que utiliza la ruta S=1 de la etiqueta de multidifusión.

Tipos de rutas de EVPN más recientes

El modo de multiconexión de EVPN admite los siguientes tipos de rutas EVPN:

  • Ruta de detección automática por segmento de Ethernet

  • Ruta de detección automática por instancia de EVPN (EVI)

  • Ruta de segmento Ethernet

Estos tipos de ruta se ajustan a la siguiente convención de nomenclatura:

<route-type>:<RD>::<esi>::<route-specific>/304

Por ejemplo:

  1. Ruta de detección automática por segmento de Ethernet:1:10.255.0.2:0::112233445566778899::0/304

  2. Ruta de autodescubrimiento por EVI—1:100.100.100.1:1::22222222222222222222::0/304

  3. Ruta de segmento Ethernet:4:10.255.0.1:0::112233445566778899:10.255.0.1/304

Dónde:

  • route-type: tipo de ruta EVPN.

    • 1: Ruta de detección automática por segmento de Ethernet.

    • 1—Ruta de autodescubrimiento por EVI.

    • 4: Ruta de segmentos Ethernet.

    • 5: Ruta con encapsulación VXLAN/MPLS

  • RD—Valor diferenciador de ruta.

    El valor del diferenciador de ruta se establece en la dirección IP del enrutador PE seguido de 0.

  • esi—Identificador de segmento Ethernet. Se muestra como 10 bytes de bytes hexadecimales y no se muestran los 00 bytes iniciales.

  • route-specific: difiere según el tipo de ruta.

    • Ruta de detección automática por segmento de Ethernet y ruta de detección automática por EVI: este valor es una etiqueta MPLS.

      Nota:

      La etiqueta MPLS se muestra en la salida extensiva, aunque no está incluida en el prefijo.

    • Ruta de segmento Ethernet: este valor es la dirección IP de origen.

  • 304: número máximo de bits en una ruta EVPN. Esta información no es muy útil y podría eliminarse de la pantalla. Sin embargo, puede ser útil para identificar rápidamente una ruta EVPN, ya sea visualmente o con operadores coincidentes.

Anuncio de ruta de dirección IP y MAC de proxy multihost

A partir de Junos OS versión 18.4R1, Junos envía anuncios de ruta de direcciones IP y MAC proxy desde PE de multiconexión a un dispositivo CE. Junos utiliza un indicador de proxy en la comunidad extendida de atributos de capa 2 de EVPN para identificar el mensaje como un anuncio de dirección IP y MAC proxy. Un PE que se entera de una dirección MAC e IP envía un anuncio de ruta normal de EVPN tipo 2 (dirección MAC e IP). Los otros PE del segmento Ethernet que se enteran de la nueva ruta desde el PE remoto ahora envían un mensaje de ruta de dirección MAC e IP con el bit de proxy establecido. Si la entrada de la dirección MAC e IP caduca o si el vínculo entre el PE y el CE falla, las entradas deben volver a aprenderse y se puede perder el tráfico. Esto evita la pérdida de tráfico cuando falla una de las conexiones a un dispositivo leaf. MAC de proxy de host múltiple se habilita automáticamente.

Actualización de la tabla de reenvío de MAC

En el multihoming de EVPN en espera activa, las direcciones MAC se tratan como direcciones enrutables y el protocolo MP-IBGP se utiliza para transportar las direcciones MAC del cliente. El aprendizaje de MAC en los enrutadores PE no ocurre en el plano de datos, sino en el plano de control. Esto conduce a un mayor control aplicado en términos del mecanismo de aprendizaje.

Un enrutador PE realiza el aprendizaje de MAC en el plano de datos para paquetes procedentes de una red de cliente para un EVI determinado. Para las direcciones MAC CE que están detrás de otros enrutadores PE, las direcciones MAC se anuncian en BGP NLRI utilizando un nuevo tipo de ruta de anuncio MAC.

El aprendizaje MAC es de dos tipos:

  • Aprendizaje local de MAC: los enrutadores de PE deben admitir el proceso de aprendizaje de MAC local a través de protocolos estándar.

  • Aprendizaje remoto de MAC: una vez que se completa el proceso de aprendizaje local, los enrutadores de PE pueden anunciar la dirección MAC aprendida localmente a los nodos de enrutador de PE remotos a través de MP-IBGP. Este proceso de recibir las direcciones MAC remotas de los clientes conectados a través de MP-IBGP se conoce como el proceso de aprendizaje MAC remoto.

El tipo de ruta de anuncio MAC se utiliza para anunciar direcciones MAC aprendidas localmente en BGP a enrutadores PE remotos. Si se anuncia una dirección MAC individual, el campo de dirección IP corresponde a esa dirección MAC. Si el enrutador PE ve una solicitud ARP para una dirección IP de un dispositivo CE y si el enrutador PE tiene la dirección MAC enlazada para esa dirección IP, el enrutador PE realiza un proxy ARP y responde a la solicitud ARP.

Nota:

El proxy ARP se realiza solo para la puerta de enlace y no para el host.

El campo de etiqueta MPLS depende del tipo de asignación. El enrutador PE puede anunciar una sola etiqueta MPLS para todas las direcciones MAC por EVI, lo que requiere el menor número de etiquetas MPLS y ahorra memoria al enrutador PE. Sin embargo, al reenviar a la red del cliente, el enrutador PE debe realizar una búsqueda MAC que puede causar un retraso y aumentar el número de ciclos de CPU.

Flujo de tráfico

En la multiconexión de EVPN, el flujo de tráfico se realiza en el plano de reenvío. Las rutas de inundación se crean para inundar los paquetes y se utilizan en los siguientes escenarios:

  • Cuando se recibe un paquete en un ESI local

  • Cuando se recibe un paquete desde el núcleo

Los flujos de tráfico en la multiconexión de EVPN pueden basarse en los dos tipos de tráfico:

  • Tráfico de unidifusión

    El tráfico de unidifusión es una comunicación punto a punto con un emisor y un receptor. En una EVPN de host múltiple, el tráfico de unidifusión se reenvía de la siguiente manera:

    • En modo de espera activa

      • CE al núcleo: el enrutador DF PE aprende y reenvía el tráfico.

      • Núcleo a CE: el enrutador de PE remoto aprende las direcciones MAC del DF y reenvía todo el tráfico de unidifusión al enrutador de PE de DF.

    • En modo activo-activo

      • CE al núcleo: el tráfico tiene un equilibrio de carga para todos los dispositivos PE multihost conectados.

      • Núcleo a CE: el tráfico de los dispositivos de PE remotos tiene un equilibrio de carga para todos los dispositivos de PE de multihost conectados al dispositivo CE remoto.

  • Tráfico BUM

    El tráfico que se envía a varios destinos, incluido el tráfico de difusión, el tráfico de unidifusión desconocido que se difunde en el segmento Ethernet y el tráfico de multidifusión se conoce como tráfico BUM. En una EVPN de host múltiple, el tráfico de BUM se reenvía de la siguiente manera:

    • En modo de espera activa

      • CE al núcleo: el dispositivo CE inunda cualquier tráfico BUM a todos los vínculos del segmento Ethernet. El enrutador DF PE con la ruta activa reenvía los paquetes BUM al núcleo. El enrutador BDF PE en modo de espera elimina todo el tráfico del dispositivo CE, porque el estado de multiconexión EVPN de la interfaz está en estado de bloqueo. Sin embargo, si el dispositivo CE está conectado a los dispositivos PE mediante vínculos o LAG independientes, el tráfico BUM llega a los dispositivos PE DF y BDF.

      • Núcleo a CE: los enrutadores de PE remotos inundan todo el tráfico BUM a los enrutadores PE DF y BDF. Sólo el DF reenvía el tráfico BUM al dispositivo CE. El enrutador BDF PE elimina todo el tráfico, porque el estado de multiconexión EVPN de la interfaz está en estado de bloqueo.

    • En modo activo-activo

      Según los requisitos, la inundación y la conmutación entre ESI locales se pueden habilitar o deshabilitar en el modo activo-activo. Esto se conoce como el comportamiento de no conmutación local.

      El núcleo del servicio EVPN proporciona una conectividad de malla completa entre los dispositivos PE de multiconexión. Debido a esto, EVPN usa un horizonte dividido en el núcleo, por lo que un paquete recibido desde el núcleo nunca se conmuta ni se inunda de nuevo al núcleo. En su lugar, la replicación de entrada se usa para replicar los paquetes en los dispositivos de PE remotos.

      Para inundar paquetes a dispositivos de PE remotos, se utilizan la multidifusión y los siguientes saltos de horizonte dividido. El próximo salto de multidifusión tuneliza el paquete con la etiqueta de multidifusión inclusiva, y el siguiente salto de horizonte dividido tuneliza el paquete con una etiqueta de multidifusión y una etiqueta de horizonte dividido. Se requiere uno de estos próximos saltos por ESI multihost por dispositivo de PE remoto.

      En el modo activo-activo se utilizan las siguientes rutas de inundación:

      • Ruta de inundación de toda la CE

        Esta ruta de inundación es utilizada por los ESI locales para lo siguiente:

        • Inundar el paquete en los ESI locales (cuando se permite la conmutación local).

        • Inundar el paquete a los dispositivos de PE remotos. Los dispositivos de PE remoto inundan el paquete en sus ESI locales.

        Dado que el tráfico BUM solo lo reenvía el reenviador designado (DF) y no los dispositivos PE multihost que no son DF, los que no son DF utilizan el siguiente salto de horizonte dividido para inundar este paquete a otros dispositivos PE. Sin embargo, las ESI locales de multihost para las cuales el dispositivo de PE no es DF no participan en la inundación.

        La ruta de inundación de toda CE no es utilizada por los ESI que no son DF, y el siguiente salto para estas rutas de inundación se crea en consecuencia. En tales casos, se utiliza la ruta de inundación ESI no DF.

      • Ruta de inundación All-VE

        Esta ruta de inundación se utiliza cuando el paquete se recibe desde el núcleo. Se utiliza para inundar el paquete recibido desde el núcleo a los ESI locales. Dado que el paquete recibido del núcleo puede venir únicamente con etiqueta de multidifusión o con etiqueta de multidifusión y etiqueta de horizonte dividido, se deben seguir las reglas de reenvío adecuadas para colocar el paquete en el ESI de multihost que se asigna a la etiqueta de horizonte dividido.

      • Ruta de inundación no DF

        Esta ruta de inundación se utiliza para lo siguiente:

        • Inundar el paquete en los ESI locales.

        • Inundar el paquete a los dispositivos de PE remotos mediante la replicación de entrada con etiqueta SH para el DF para el ESI.

Aliasing

A partir de Junos OS versión 15.1, Junos OS admite el uso de alias en una EVPN. El aliasing es la capacidad de un dispositivo de PE remoto para equilibrar la carga del tráfico de unidifusión de capa 2 en todos los demás dispositivos PE que tienen el mismo segmento Ethernet hacia un dispositivo CE.

Uso de alias en el modo activo-activo

En la figura 3, el alias en el modo activo-activo funciona de la siguiente manera:

  1. ESI1 se configura en los enrutadores PE1, PE2 y PE3. Los enrutadores PE1, PE2 y PE3 anuncian la ruta de detección automática por segmento de Ethernet para ESI1.

  2. El dispositivo CE1 envía tráfico de capa 2 con dirección MAC de origen (MAC1) al enrutador PE1.

  3. El enrutador PE1 aprende la dirección MAC1 en (ESI1, vlan X) y la anuncia a todos los enrutadores PE que usan BGP.

  4. El enrutador PE4 recibe la ruta MAC1 a través de BGP.

  5. Dado que el enrutador PE4 también recibió la ruta de autodescubrimiento por EVI de los enrutadores PE2 y PE3, sabe que se debe acceder a MAC1 a través de los enrutadores PE2 y PE3. El enrutador PE4 crea su estado de reenvío para equilibrar la carga del tráfico de capa 2 para MAC1 entre los enrutadores PE1, PE2 y PE3.

Rutas de alias y detección automática

Las rutas de detección automática de los enrutadores PE2 y PE3 pueden venir en cualquier orden. Como resultado, estas rutas se instalan mediante el proceso de capa 2 de la siguiente manera:

  1. Después de recibir MAC1 del enrutador PE1, y si el enrutador PE4 no ha recibido alguna ruta de detección automática, PE4 programa MAC1 con un siguiente salto apuntando hacia el enrutador PE1. Cuando PE4 recibe la ruta de detección automática del enrutador PE2 para el mismo ESI, se instala el siguiente salto para que el tráfico de MAC1 tenga un equilibrio de carga en los enrutadores PE1 y PE2. Cuando PE4 recibe la ruta de detección automática del enrutador PE3 para el mismo ESI, el siguiente salto se actualiza para equilibrar la carga del tráfico de MAC1 entre los enrutadores PE1, PE2 y PE3.

  2. Si el enrutador PE4 ya ha recibido las rutas de detección automática de más de un dispositivo PE (PE1, PE2 y PE3), PE4 instala las rutas MAC con el próximo salto multidestino.

Ruta de alias y etiquetas

Cualquier dispositivo PE que anuncie la ruta de detección automática por EVI con una etiqueta MPLS válida programa la etiqueta anunciada en la tabla de enrutamiento mpls.0. Por ejemplo, si el enrutador PE2 anunciaba la ruta de autodescubrimiento por EVI con la etiqueta A, la entrada mpls.0 es la siguiente:

La ruta de la etiqueta A apunta al siguiente salto de tabla EVPN-EVO.

Cuando el enrutador remoto PE4 envía un paquete de datos de unidifusión al enrutador PE2 con esta etiqueta A, la búsqueda se realiza en la tabla de reenvío del enrutador PE2 y, como resultado de esta búsqueda, el paquete se reenvía en ESI1.

Reenvío de paquetes de unidifusión y alias

Cuando los paquetes de unidifusión para MAC1 provienen del enrutador remoto PE4 al enrutador PE2, puede haber dos casos:

  • El enrutador PE2 también recibió el mismo conjunto de MAC en su enlace a ESI1; en este caso, se prefieren las rutas locales y, como resultado de la búsqueda de MAC, los paquetes se reenvían a ESI1.

  • El enrutador PE2 no ha recibido el mismo conjunto de MAC en su vínculo a ESI1; en este caso, el enrutador PE2 sigue instalando rutas MAC que apuntan a ESI1, aunque las MAC se aprenden de forma remota desde el enrutador PE1. Como resultado, los paquetes se reenvían a ESI1.

Multihoming activo-activo de EVPN y agregación de vínculos multichasis

Cuando un dispositivo CE está configurado con un LAG hacia los dispositivos PE, hay disponibles las dos opciones siguientes para ejecutar LACP en los dispositivos PE:

  • Configure el mismo ID de sistema LACP en todos los dispositivos PE.

  • Configure la agregación de vínculos multichasis en los dispositivos PE.

Cuando la agregación de vínculos multichasis se configura con EVPN, se requiere un conjunto reducido de procedimientos para la agregación de vínculos multichasis activo-activo. Estos procedimientos proporcionan redundancia a nivel de nodo y vínculo. La agregación de enlaces multichasis es completamente transparente para el dispositivo CE y se realiza como LAG puro. La agregación de vínculos multichasis también opera a nivel de puerto. Esto significa esencialmente que si la agregación de vínculos multichasis está configurada como activa-activa, todas las VLAN en los puertos de agregación de vínculos multichasis funcionan en el modo de multiconexión activo-activo.

Cuando se configura la agregación de vínculos multichasis junto con EVPN, se tiene en cuenta lo siguiente:

  • Tanto la agregación de vínculos multichasis como el ESI EVPN deben estar habilitados para funcionar solo en el modo activo-activo.

  • Las siguientes funciones no son necesarias para la agregación de vínculos multichasis con EVPN:

    • Sincronización Mac: se realiza en el plano de control BGP de EVPN.

    • Vinculación de ICL: esto se maneja mediante la función de alias de EVPN.

    • Sincronización ARP: esto lo maneja el plano de control BGP con funcionalidad IRB.

Multihoming activo-activo de EVPN e IRB

Cuando se configura IRB, las rutas EVPN contienen información de MAC e IP. La multiconexión activa-activa requiere sincronización ARP entre los dispositivos de PE de multihost porque las respuestas ARP se pueden aplicar hash a un dispositivo de PE determinado.

Configuración de ejemplo

A continuación se muestra un ejemplo de configuración para la multiconexión en espera activa de EVPN en los siguientes tipos de interfaces:

  • Configuración de interfaz Ethernet

  • Configuración de interfaz de VLAN única

Nota:
  • Un valor ESI de 0 y todos los FF están reservados y no se utilizan para configurar un segmento de Ehernet de host múltiple.

  • No se pueden configurar dos interfaces en el mismo EVI con el mismo valor ESI.

A continuación, se muestra un ejemplo de configuración de instancia de enrutamiento para multiconexión en espera activa de EVPN:

  • Configuración de la instancia de enrutamiento

Nota:

Con la configuración del modo de espera activa, la ruta de detección automática por segmento de Ethernet se anuncia con el bit en espera activa establecido en 1 para cada segmento de Ethernet.

Elección del reenviador designado

El procedimiento de elección del reenviador designado (DF) en EVPN proporciona un mecanismo sólido para elegir un reenviador designado entre los dispositivos que sirven a un segmento de Ethernet de multiconexión. La elección de DF garantiza un reenvío eficiente y eficaz del tráfico, la unidifusión desconocida y la gestión del tráfico de multidifusión (BUM), la alta disponibilidad y la gestión del tráfico. Las características clave incluyen:

  • Algoritmos basados en módulo o en preferencias para la selección de radiofrecuencias.

  • Reelección dinámica de DF provocada por cambios de estado de la red.

  • Roles de DF y DF de copia de seguridad para evitar bucles de tráfico.

El sistema también procesa rutas ESI para optimizar el procesamiento de rutas y utiliza mecanismos de extracción masiva para mantener la integridad de la red. Puede usar estas características y sus configuraciones de CLI para garantizar un flujo de tráfico sin problemas y administrar eficazmente sus escenarios de multiconexión de EVPN.

Para obtener más información, consulte Elección del reenviador designado de multiconexión EVPN.

ESI en interfaces físicas, Ethernet agregadas y lógicas

En versiones anteriores a Junos OS versión 15.1F6 y 17.1R1 para enrutadores serie MX y Junos OS versión 17.3R1 para conmutadores EX9200, puede especificar un ESI solo en una interfaz Ethernet física o agregada, por ejemplo, set interfaces ae0 esi 00:11:22:33:44:55:66:77:88:99. Si especifica un ESI en una interfaz Ethernet física o agregada, tenga en cuenta que un ESI es un factor en el proceso de elección del reenviador designado (DF). Por ejemplo, suponga que configura la multiconexión EVPN en espera activa en la interfaz Ethernet agregada ae0 y, dado el ESI configurado en ae0 y otros factores determinantes, la elección de DF da como resultado que ae0 esté en el estado inactivo. Además, todas las interfaces lógicas configuradas en la interfaz Ethernet agregada ae0, por ejemplo, set interfaces ae0 unit 1 y set interfaces ae0 unit 2 también están en estado inactivo, lo que hace que las interfaces lógicas ae0.1 y ae0.2 no puedan proporcionar servicios a sus respectivos sitios de cliente (VLAN).

Para utilizar mejor las interfaces lógicas en el modo de multiconexión EVPN activo-espera o activo-activo, a partir de Junos OS versiones 15.1F6 y 17.1R1 para enrutadores serie MX y Junos OS versión 17.3R1 para conmutadores EX9200, puede especificar un ESI en una interfaz lógica. Como resultado, incluso si una interfaz lógica no es DF, otras interfaces lógicas en la misma interfaz Ethernet física o agregada aún pueden proporcionar servicios a sus respectivos sitios de cliente (VLAN).

Para obtener más información, consulte Ejemplo: Configuración de un ESI en una interfaz lógica con multiconexión EVPN.

ESI generados automáticamente

A partir de Junos OS versión 18.4R1, puede configurar interfaces Ethernet agregadas e interfaces lógicas Ethernet agregadas para derivar ESI automáticamente de la configuración LACP. Admitimos esta característica en los siguientes entornos:

  • En dispositivos de Juniper Networks que admitan esta función y tengan multiconexión en modo activo-activo en una red superpuesta EVPN-VXLAN.

  • En los dispositivos de Juniper Networks que admiten esta función y son de multiconexión en modo activo-espera o activo-activo en una red superpuesta EVPN-MPLS.

Para obtener más información, consulte Descripción de las ESI generadas automáticamente en redes EVPN.

Convergencia en una red EVPN

Cuando se producen cambios en la topología de red de un sistema EVPN a gran escala, el tiempo de convergencia puede ser significativo. Puede priorizar las actualizaciones de NLRI que son críticas para la selección de rutas en las políticas de enrutamiento para mejorar la convergencia. En la tabla 1 se enumeran los tipos de ruta NLRI y la prioridad que se debe configurar en la directiva de enrutamiento.

Tabla 1: Prioridad para el tipo de ruta NLRI

Tipo de ruta NLRI

Descripción

Prioridad

Ruta NLRI Tipo 1

Ruta de descubrimiento automático de Ethernet: el tipo 1 admite convergencia y aliasing rápidos, y se utiliza para indicar la retirada masiva de MAC.

Alto

Ruta NLRI Tipo 2

Ruta de anuncio MAC/IP: el tipo 2 se utiliza para anunciar direcciones MAC y direcciones IP en redes EVPN.

Bajo

Ruta NLRI Tipo 3

Etiqueta Ethernet de multidifusión inclusiva: el tipo 3 se utiliza para configurar una ruta para el tráfico BUM.

Bajo

Ruta NLRI Tipo 4

Ruta de segmento Ethernet: EVPN tipo 4 se utiliza en la selección de un reenviador designado.

Alto

Para priorizar el tipo de ruta NLRI, establezca el bgp-output-queue-priority priority for nlri-route-type en el nivel [edit policy-options policy-statement] jerarquía en todos los enrutadores perimetrales y reflectores de ruta del proveedor en la red EVPN. En este ejemplo, se configuró una prioridad alta para la ruta NLRI tipo 1 y la ruta NLRI tipo 4.

Nota:

Hay 17 colas de salida priorizadas: una cola acelerada que tiene la prioridad más alta y 16 colas numeradas para las cuales 1 es la prioridad más baja y 16 es la más alta.

Para obtener más información acerca de cómo configurar directivas de enrutamiento, consulte Guía del usuario de directivas de enrutamiento, filtros de firewall y políticas de tráfico.

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
18.4R1
A partir de Junos OS versión 18.4R1, puede configurar interfaces Ethernet agregadas e interfaces lógicas Ethernet agregadas para derivar ESI automáticamente de la configuración LACP.
17.4R1
A partir de Junos OS versión 17.4R1, Junos OS admite los próximos saltos de lista dinámica en una red EVPN.
16.1R4
A partir de Junos OS versiones 16.1R4 y 16.2R2, todos los conmutadores EX9200 admiten el modo activo-activo para multiconexión EVPN.
16.1R4
A partir de Junos OS versión 17.4R1, los conmutadores QFX10000 admiten el modo activo-activo para multiconexión EVPN.
15.1F6
Para utilizar mejor las interfaces lógicas en el modo de multiconexión EVPN activo-espera o activo-activo, a partir de Junos OS versiones 15.1F6 y 17.1R1 para enrutadores serie MX y Junos OS versión 17.3R1 para conmutadores EX9200, puede especificar un ESI en una interfaz lógica. Como resultado, incluso si una interfaz lógica no es DF, otras interfaces lógicas en la misma interfaz Ethernet física o agregada aún pueden proporcionar servicios a sus respectivos sitios de cliente (VLAN).
15.1
A partir de Junos OS versión 15.1, Junos OS admite el uso de alias en una EVPN.
14,1 x 53-D30
A partir de Junos OS versión 14.1x53-D30 para conmutadores QFX5100 y Junos OS versión 18.2R1 para conmutadores EX4600, estos conmutadores admiten el modo de operación activo-activo para multiconexión EVPN.
14.1R4
A partir de Junos OS versión 14.1R4, 14.2, 15.1F6 y 16.1R1, Junos OS admite el modo activo-activo para multiconexión EVPN en enrutadores de la serie MX.