Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Funcionalidad compatible con EVPN a través de VXLAN

La siguiente funcionalidad es compatible con la encapsulación del plano de datos EVPN a través de VXLAN:

Encapsulación VXLAN

EVPN admite el tipo de encapsulación del plano de datos VXLAN dentro de la misma instancia de EVPN. Para admitir el tipo de encapsulación VXLAN, todos los dispositivos PE EVPN especifican el tipo de túnel como VXLAN en la comunidad extendida de encapsulación BGP. El PE de entrada determina qué tipos de encapsulación usar en función de su propia capacidad de encapsulación y de la que anuncia su dispositivo de PE remoto EVPN.

Cuando EVPN se usa como solución de superposición para la red IP subyacente con encapsulación VXLAN, el paquete de datos se encapsula con un encabezado VXLAN en el dispositivo de PE de entrada y el paquete de datos se desencapsula del encabezado VXLAN en el dispositivo PE de salida. La figura 1 muestra el formato del paquete cuando se reenvía un paquete en el núcleo a través de la red IP subyacente con encapsulación VXLAN:

Figura 1: Red IP subyacente con encapsulación VXLAN Underlay IP Network with VXLAN Encapsulation

Si la red subyacente utiliza el protocolo IPv4 y el direccionamiento IPv4, el encabezado IP externo del paquete VXLAN es un encabezado IPv4. Todas las plataformas compatibles con EVPN-VXLAN funcionan con una red subyacente IPv4.

En las plataformas serie MX y VMX, puede configurar la capa subyacente para que utilice el protocolo IPv6 y el direccionamiento IPv6. En esos casos, el encabezado IP externo del paquete VXLAN es un encabezado IPv6 y se configura la dirección de origen del VTEP como una dirección IPv6. Consulte EVPN-VXLAN con una base IPv6 para obtener detalles sobre el uso de una base IPv6.

Rutas y atributos de BGP de EVPN

Las rutas y atributos BGP de EVPN admiten la encapsulación del plano de datos EVPN a través de VXLAN y se ven afectados de la siguiente manera:

  • Al adjuntar el atributo de comunidad extendida de encapsulación BGP con VXLAN de tipo de encapsulación de túnel en las rutas MAC de EVPN, el dispositivo de PE de salida anuncia la ruta de multidifusión inclusiva de EVPN y la detección automática de EVPN por ruta EVI.

  • Los campos de etiqueta Ethernet para todas las rutas BGP de EVPN se establecen en cero para admitir únicamente el modo basado en el identificador de red VXLAN (VNI).

  • El VNI, también denominado campo VNI en la superposición de EVPN, se coloca en los campos MPLS para la ruta MAC de EVPN, la ruta de multidifusión inclusiva de EVPN y la ruta de detección automática por instancia de EVPN.

  • El campo de etiqueta de identificador de segmento de Ethernet se establece en cero para la ruta de detección automática de EVPN por segmento de Ethernet porque no existe ninguna etiqueta de identificador de segmento de Ethernet para el tipo de encapsulación de VXLAN compatible.

  • Todas las rutas EVPN correspondientes desde el dispositivo PE remoto se resuelven en la tabla inet.0 o :vxlan.inet.0 en lugar de la tabla inet.3 para IPv4. Cuando se utiliza una base IPv6 para la tunelización EVPN-VXLAN, ocurre lo mismo con las tablas inet6.0 y :vxlan.inet6.0.

Procedimiento de multiconexión de EVPN

Puede convertir un servidor sin sistema operativo (BMS) en un par de conmutadores de la parte superior del rack (TOR) de Juniper Networks, por ejemplo, conmutadores QFX5100, a través de una interfaz de grupo de agregación de vínculos (LAG) de capa 2. Debido a la interfaz LAG, solo se reenvía una copia del tráfico BUM desde un BMS al enrutador principal. Para evitar un bucle de capa 2 y la inundación del tráfico BUM al mismo segmento Ethernet al que está conectado el BMS de multiconexión, el tráfico BUM aplica la regla de filtrado de horizonte dividido activo-activo de multiconexión. Para ser totalmente compatible con la función de modo activo-activo multiconexión EVPN, el conmutador TOR de Juniper Networks también anuncia la ruta de alias de EVPN a otros dispositivos EVPN PE.

La falta de compatibilidad con la etiqueta MPLS para EVPN sobre IP con encapsulación del plano de datos VXLAN afecta a las siguientes funciones del modo activo-activo multiconexión de EVPN:

Nota:

EVPN a través de VXLAN no admite el modo de operación en espera activa. Solo puede configurar el modo activo-activo mediante la all-active opción de configuración de la interfaz ESI. No se admiten segmentos Ethernet de homing único con EVPN que utilicen encapsulación VXLAN con la single-active opción.

A partir de la versión 22.2R1 de Junos OS, EVPN agrega redundancia activa, aliasing y soporte de retirada masiva de MAC, incluida la integración de VXLAN de plano de datos, para proporcionar una conectividad resistente entre los centros de datos a sus tecnologías establecidas de interconexión del centro de datos (DCI). Este nuevo soporte crea una solución DCI de extremo a extremo mediante la integración de la multidifusión EVPN con VXLAN de plano de datos.

En una topología activa-activa, ambos vínculos se usan para equilibrar la carga del tráfico. El tráfico de unidifusión que se origina en el dominio EVPN-MPLS tiene un equilibrio de carga para ambas puertas de enlace y se reenvía a través del túnel VXLAN al enrutador final de VXLAN remoto. Los paquetes de carga equilibrada pueden provenir de cualquiera de las puertas de enlace y causar un problema de cambio de MAC en el enrutador final de VXLAN. Puede superar este problema de flip-flop de MAC configurando una dirección IP anycast como dirección secundaria en las interfaces de circuito cerrado de las puertas de enlace. Cuando establezca la dirección anycast como vxlan-source-ip, se creará el túnel VXLAN en la dirección anycast y el MAC se aprenderá de la dirección anycast del VTEP.

Utilice las siguientes instrucciones para establecer la redundancia activa-activa en el nivel ESI y una dirección anycast en la interfaz lo0. Agregue una dirección secundaria con una IP anycast a la interfaz lo0 e inclúyala como interfaz vxlan-source-ip VTEP en la instancia de enrutamiento y en el secondary-vtep-address pim de protocolos.

Regla de filtrado de horizonte dividido y sesgo local

Debido a la falta de la etiqueta MPLS, la regla de filtrado de horizonte dividido para el segmento Ethernet multihost se modifica y se basa en la dirección IP del dispositivo PE EVPN en lugar de la etiqueta del segmento Ethernet MPLS. Para el tráfico procedente de la interfaz de acceso, cualquier reenvío de tráfico al segmento Ethernet multihost se basa en la sesgo local para EVPN con encapsulación de plano de datos VXLAN. Cada dispositivo PE EVPN rastrea la dirección IP de su dispositivo PE EVPN multihost par para el que comparte el mismo segmento Ethernet. Este seguimiento proporciona la dirección IP del VTEP de origen (en el encabezado IP exterior) para cada paquete VXLAN recibido del otro dispositivo PE EVPN. La regla de filtrado de horizonte dividido se aplica tanto en los dispositivos de PE de entrada como en los de salida para el tráfico multidestino:

  • PE de entrada: responsable de reenviar paquetes de múltiples destinos procedentes de cualquiera de sus interfaces de acceso conectadas directamente a sus segmentos restantes de Ethernet multihost asociados, independientemente del estado de elección del reenviador designado (DF) del dispositivo de PE de entrada del sujeto.

  • PE de salida: no permite el reenvío de ningún paquete de múltiples destinos al mismo segmento de Ethernet de multihost con el que un PE de salida comparte con su dispositivo de PE de entrada, independientemente del estado de elección de DF del dispositivo de PE de salida del sujeto.

Aliasing

Cuando se conecta un BMS a un par de conmutadores TOR de Juniper Networks a través de un paquete de interfaz LAG, solo uno de los conmutadores puede aprender la dirección MAC local. Para admitir el equilibrio de carga del tráfico de unidifusión conocido procedente de la VXLAN al BMS entre los conmutadores, el dispositivo PE EVPN del conmutador debe anunciar EVPN por ruta de detección automática de instancias de EVPN. Este anuncio indica a los dispositivos PE EVPN remotos que el MAC aprendido del segmento Ethernet multihost de su dispositivo PE multihost par también es accesible. Para la encapsulación VXLAN, no hay ningún cambio en el procedimiento de EVPN al proporcionar la función de alias de EVPN.

Reenvío del siguiente salto

El demonio de aprendizaje de direcciones de capa 2 (l2ald) crea el siguiente salto del compuesto de encapsulación VXLAN en la entrada y el siguiente salto del compuesto de desencapsulación VXLAN en la salida. El siguiente salto del compuesto de encapsulación VXLAN reenvía el tráfico de unidifusión de capa 2 al dispositivo PE remoto con la encapsulación VXLAN. Si hay varias rutas disponibles para llegar a una MAC remota (como en el caso activo-activo de EVPN multiconexión), el demonio de protocolo de enrutamiento (rpd) informa al l2ald de todas las direcciones IP de VTEP remotas asociadas con la MAC remota. El l2ald es responsable de crear un próximo salto de ruta múltiple (ECMP) de igual costo para la MAC remota. El siguiente salto del compuesto de desencapsulación VXLAN desencapsula el encabezado del túnel VXLAN en la salida y, a continuación, reenvía el tráfico al BMS.

Para tráfico de unidifusión conocido:

  • En la entrada, el rpd no necesita agregar una ruta de etiqueta en la tabla mpls.0.

  • A la salida, el rpd no necesita agregar una ruta de etiqueta para apuntar al siguiente salto de la tabla en la tabla mpls.0.

Método de aprendizaje MAC del plano de control

Una característica exclusiva de EVPN es que el aprendizaje de direcciones MAC entre dispositivos PE se produce en el plano de control. El enrutador de PE local detecta una nueva dirección MAC de un dispositivo CE y, a continuación, utiliza MP-BGP, anuncia la dirección a todos los dispositivos de PE remotos. Este método difiere de las soluciones VPN de capa 2 existentes, como VPLS, que aprenden inundando unidifusión desconocida en el plano de datos. Este método de aprendizaje de MAC del plano de control es un componente crucial de las características y ventajas que ofrece EVPN. Dado que el aprendizaje de MAC se maneja en el plano de control, EVPN tiene la flexibilidad necesaria para admitir diferentes tecnologías de encapsulación de plano de datos entre dispositivos PE. Esta flexibilidad es importante porque no todas las redes troncales pueden estar ejecutando MPLS, especialmente en redes empresariales.

Para el aprendizaje remoto de MAC del plano de control, dado que l2ald crea el siguiente salto del compuesto de encapsulación VXLAN y el siguiente salto del compuesto de desencapsulación VXLAN, el rpd ya no crea un siguiente salto indirecto utilizado en la tabla de reenvío de MAC. El rpd se basa en el mecanismo existente para informar al l2ald de las direcciones MAC remotas aprendidas desde el plano de control. En lugar de informar al l2ald sobre el ID de VLAN y el índice indirecto del próximo salto utilizado por el MAC remoto en la tabla FIB de MAC, el rpd informa al l2ald sobre la dirección IP del VTEP remoto y el identificador de red VXLAN. La ruta MAC aprendida remota del plano de control apunta al siguiente salto compuesto de encapsulación VXLAN o a un siguiente salto ECMP creado por l2ald en la tabla de reenvío de MAC.

Para la EVPN activa-activa de multiconexión, un par de direcciones IP VTEP remotas están asociadas a la dirección MAC remota. Las direcciones IP de VTEP remoto se obtienen de la ruta MAC recibida del dispositivo de PE remoto o de la ruta de aliasing del dispositivo de PE remoto. Cuando un dispositivo de PE remoto retira una ruta MAC o la ruta de aliasing para el segmento Ethernet de donde aprendió el MAC, el rpd alerta al l2ald sobre el cambio al par de direcciones IP de VTEP remotas en consecuencia. Como resultado, l2ald actualiza el siguiente salto uni-list creado para este MAC. Cuando tanto las rutas MAC remotas como su ruta de alias asociada se retiran o quedan sin resolver, el rpd informa al l2ald sobre la eliminación de este MAC remoto y el l2ald retira este MAC de la tabla de reenvío de MAC.

Contrail vRouters y la tabla L3-VRF

El software de virtualización Contrail crea redes virtuales (VN) asociadas con rutas en una tabla de enrutamiento y reenvío virtual de capa 3 (L3-VRF).

Las siguientes son las rutas asociadas:

Rutas de subred para una interfaz IRB

Para cada par de tablas MAC-(enrutamiento y reenvío virtual) VRF y L3-VRF creadas para una red virtual en un enrutador serie MX, se asocia una interfaz IRB correspondiente con el par de tablas MAC-VRF y L3-VRF. La tabla L3-VRF del enrutador de la serie MX tiene la ruta de subred desde la interfaz IRB asociada a sus redes virtuales locales, así como todas las rutas de subred de las interfaces IRB asociadas con otras redes virtuales dentro de un centro de datos proporcionada por la función de fugas de enrutamiento de Junos OS. Los enrutadores de la serie MX anuncian estas rutas de subred a través de MP-BGP a los nodos de control de Contrail. Como resultado, la tabla L3-VRF n Contrail vRouter contiene el mismo conjunto de rutas de subred para las interfaces IRB en su FIB IP, y las rutas de subred apuntan sus siguientes saltos a los enrutadores de la serie MX.

Rutas de host de máquina virtual

Los enrutadores virtuales Contrail admiten ARP de proxy y anuncian la dirección IP con la ruta MAC EVPN para su máquina virtual (VM). Tanto para Contrail vRouters como para los enrutadores de la serie MX, la tabla L3-VRF de una red virtual contiene todas las rutas de host de VM para aquellas máquinas virtuales que residen en la misma red virtual, así como rutas en todas las demás redes virtuales. el tráfico de red intravirtual e intervirtual entre las máquinas virtuales se reenvía directamente en la capa 3 entre los enrutadores virtuales de Contrail.

Rutas de host de servidor sin sistema operativo

Un conmutador TOR de Juniper Networks, por ejemplo, un conmutador QFX5100, no anuncia la dirección IP con la ruta MAC EVPN para el servidor sin sistema operativo (BMS) al que está conectado. Como resultado del anuncio de ruta MAC EVPN del conmutador, no se instala ninguna ruta de host BMS en la tabla L3-VRF de los enrutadores Contrail vRouters y MX. Sin embargo, las rutas ARP para los BMS se instalan en el kernel del enrutador de la serie MX si el enrutador de la serie MX recibe respuestas ARP de los BMS.

Elección del reenviador designado

Para proporcionar un mejor equilibrio de carga y una topología más flexible, la elección del reenviador designado se determina seleccionando el ID de VLAN mínimo o el ID de red VXLAN para cada segmento de Ethernet en lugar de seleccionar en función de la instancia de EVPN. La figura 2 muestra un ejemplo de topología de elección de reenviador designado.

Figura 2: Topología Designated Forwarder Election Topology de elección del reenviador designado

El dispositivo CE (CE1) tiene un valor de identificador de segmento Ethernet configurado como ES1 y está conectado a dispositivos PE1 y PE2, con VLAN configuradas 100 y 101. El enrutador PE1 se elige como el reenviador designado para las dos VLAN.

El dispositivo CE (CE2) tiene un valor de identificador de segmento Ethernet configurado como ES2 y está conectado a dispositivos PE1 y PE3, con VLAN 201 configurada. El enrutador PE3 se elige como reenviador designado para esta VLAN.

El ID de etiqueta Ethernet puede ser uno de los siguientes:

  • ID de VLAN (para EVPN-MPLS)

  • ID de red VXLAN (para EVPN-VXLAN)

Documentación relacionada