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 por VXLAN

La siguiente funcionalidad se admite para la encapsulación del plano de datos de EVPN por VXLAN:

Encapsulación de VXLAN

EVPN admite el tipo de encapsulación de 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 del BGP. El PE de entrada determina qué tipos de encapsulación se deben usar en función de su propia capacidad de encapsulación y la que anuncie su dispositivo de PE remoto EVPN.

Cuando EVPN se utiliza 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 de PE de salida. La Figura 1 muestra el formato del paquete cuando un paquete se reenvía 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 encapsulated packet structure showing outer Ethernet, IP, UDP headers, VXLAN header, and original Ethernet frame. VXLAN

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 que admiten EVPN-VXLAN funcionan con una red subyacente IPv4.

En algunas plataformas, puede configurar la capa subyacente para que utilice el protocolo IPv6 y el direccionamiento IPv6. En esos casos, el encabezado IP externo en el paquete VXLAN es un encabezado IPv6 y configure la dirección de origen VTEP como una dirección IPv6. Consulte EVPN-VXLAN con una base IPv6 para obtener más información sobre el uso de una base IPv6.

Rutas y atributos del BGP de EVPN

Las rutas y los atributos del BGP de EVPN admiten la encapsulación del plano de datos de EVPN por VXLAN y se ven afectados de la siguiente manera:

  • Al asociar el atributo de comunidad extendida de encapsulación de BGP con el tipo de encapsulación de túnel VXLAN 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 rutas de EVPN por EVI.

  • Los campos de etiqueta Ethernet de 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 conocido como campo VNI en la superposición 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 autodescubrimiento por instancia de EVPN.

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

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

Procedimiento de multiconexión de EVPN

Puede migrar varias veces un servidor sin sistema operativo (BMS) a 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 de capa 2 (LAG). Debido a la interfaz LAG, sólo se reenvía una copia del tráfico BUM desde un BMS al enrutador de núcleo. Para evitar que se produzca un bucle de capa 2 y que el tráfico BUM se inunde de vuelta al mismo segmento de Ethernet al que está conectado el BMS multiconexión, el tráfico BUM aplica la regla de filtrado de horizonte dividido activo-activo multiconexión. Para admitir completamente la función de modo activo-activo multiconexión de EVPN, el conmutador TOR de Juniper Networks también anuncia la ruta de alias de EVPN a otros dispositivos PE de EVPN.

La falta de compatibilidad de etiquetas MPLS para EVPN sobre IP con encapsulación de 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 opción de la all-active configuración de la interfaz ESI. No se admiten segmentos de Ethernet de conexión única con EVPN mediante encapsulación VXLAN con la single-active opción.

A partir de la versión 22.2R1 de Junos OS, EVPN agrega soporte de redundancia totalmente activa, alias y retiro masivo de MAC, incluida la integración de VXLAN de plano de datos, para proporcionar conectividad resistente entre centros de datos a sus tecnologías establecidas de interconector 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 el plano de datos VXLAN.

En una topología activa-activa, ambos vínculos se utilizan para equilibrar la carga del tráfico. El tráfico de unidifusión que se origina en el dominio EVPN-MPLS tiene equilibrio de carga a ambas puertas de enlace y se reenvía a través del túnel VXLAN al enrutador final VXLAN remoto. Los paquetes con equilibrio de carga 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 de difusión any como dirección secundaria en las interfaces de circuito cerrado de las puertas de enlace. Cuando establezca la dirección de difusión por proximidad como , vxlan-source-ipse creará el túnel de VXLAN en la dirección de difusión por proximidad y se aprenderá la MAC a partir de la dirección de difusión por proximidad del VTEP.

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

Sesgo local y regla de filtrado de horizonte dividido

Debido a la falta de la etiqueta MPLS, la regla de filtrado de horizonte dividido para el segmento de Ethernet multiconexión 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 de Ethernet multiconexión se basa en el sesgo local de EVPN con encapsulación de plano de datos VXLAN. Cada dispositivo PE EVPN rastrea la dirección IP de su dispositivo PE EVPN multiconexión par para el que comparte el mismo segmento Ethernet. Este seguimiento proporciona la dirección IP 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 dispositivos de PE de entrada como de salida para el tráfico de varios destinos:

  • PE de entrada: responsable de reenviar paquetes de destino múltiple provenientes de cualquiera de sus interfaces de acceso conectadas directamente a sus segmentos de Ethernet multiconexión asociados restantes, independientemente del estado de elección de reenviador designado (DF) del dispositivo de PE de entrada en cuestión.

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

Alias

Cuando 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 de PE de EVPN en el conmutador debe anunciar EVPN por ruta de autodescubrimiento de instancia de EVPN. Este anuncio señala a los dispositivos remotos de PE EVPN que la MAC aprendió del segmento de Ethernet multiconexión desde su dispositivo PE multiconexión par también es accesible. Para la encapsulación de VXLAN, no hay ningún cambio en el procedimiento de EVPN al proporcionar la función de alias de EVPN.

Reenvío de siguiente salto

El demonio de aprendizaje de direcciones de capa 2 (l2ald) crea el próximo salto compuesto de encapsulación VXLAN en la entrada y el siguiente salto compuesto de desencapsulación VXLAN en la salida. El próximo salto compuesto de encapsulación VXLAN reenvía el tráfico de unidifusión de capa 2 al dispositivo de PE remoto con la encapsulación VXLAN. Si hay varias rutas disponibles para comunicarse con una MAC remota (como con el caso activo-activo de EVPN multiconexión), el daemon 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 multirruta de igual costo (ECMP) para el MAC remoto. El próximo salto compuesto de desencapsulación de VXLAN desencapsula el encabezado de túnel de VXLAN en la salida y, luego, 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.

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

Prevención de bucles IRB superpuestos

Las rutas de túnel de VXLAN se resuelven en la capa subyacente. La superposición utiliza la resolución de ruta subyacente para facilitar la accesibilidad. La capa subyacente, en ciertas condiciones, puede usar la superposición para la accesibilidad, lo que puede dar lugar a bucles de enrutamiento.

Considere un escenario en el que configura tanto VXLAN como una IRB en la misma instancia de enrutamiento, mientras también configura la IRB en el protocolo OSPF o mediante enrutamiento estático. Puede configurar el IRB explícitamente mediante set protocols ospf area # interface irb la opción o la opción set protocols ospf area # interface all"interfaz toda". Cualquiera de los enfoques permite que la capa subyacente utilice la superposición para la resolución de rutas de túnel.

Evite que la capa subyacente resuelva rutas utilizando la superposición configurando la overlay-vxlan-interfaces instrucción. A continuación, configure una política de enrutamiento, como se muestra a continuación:

Examine la tabla :vxlan.inet.0 para comprobar que el sistema bloquea las rutas IRB. En primer lugar, revise un escenario en el que la capa subyacente pueda utilizar rutas superpuestas. La ruta activa utiliza el IRB:

Esta opción es compatible con IPv4 e IPv6. Aquí está la tabla :vxlan.inet6.0 con la ruta IRB:

Observe el mismo resultado cuando la overlay-vxlan-interfaces instrucción impide que la ruta IRB se agregue a la tabla. Aquí se muestran las tablas IPv4 e IPv6:

Método de aprendizaje de MAC del plano de control

Una característica exclusiva de EVPN es que el aprendizaje de la dirección MAC entre dispositivos PE se produce en el plano de control. El enrutador de PE local detecta una nueva dirección MAC en un dispositivo CE y, luego, utiliza MP-BGP para anunciar la dirección a todos los dispositivos de PE remotos. Este método difiere de las soluciones VPN de capa 2 existentes como VPLS, las cuales aprenden al inundar 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 beneficios que ofrece EVPN. Dado que el aprendizaje de MAC se maneja en el plano de control, EVPN cuenta con la flexibilidad necesaria para admitir diferentes tecnologías de encapsulación de plano de datos entre dispositivos PE. Esta flexibilidad es importante, ya que no todas las redes red troncal pueden estar ejecutando MPLS, especialmente en las redes empresariales.

Para el aprendizaje remoto de MAC del plano de control, dado que l2ald crea el próximo salto compuesto de encapsulación VXLAN y el próximo salto compuesto de desencapsulación VXLAN, el RPD ya no crea un próximo salto indirecto que se usa en la tabla de reenvío 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 MAC, el rpd informa al l2ald sobre la dirección IP del VTEP remoto y el identificador de red VXLAN. La ruta de MAC remota del plano de control apunta al próximo salto compuesto de encapsulación de VXLAN o a un próximo salto de ECMP creado por l2ald en la tabla de reenvío de MAC.

Para el EVPN multiconexión activo-activo, un par de direcciones IP VTEP remotas se asocian con 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 alias del dispositivo de PE remoto. Cuando un dispositivo de PE remoto retira una ruta MAC o la ruta de alias para el segmento de Ethernet desde donde aprendió el MAC, el rpd alerta al l2ald sobre el cambio en el par de direcciones IP VTEP remotas según corresponda. Como resultado, l2ald actualiza el próximo salto uni-list construido para esta MAC. Cuando las rutas MAC remotas y su ruta de alias asociada se retiran o dejan de resolverse, 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 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 de la 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 de la interfaz IRB asociada con 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 proporcionadas por la función de pérdida 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 en el 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 próximos saltos a los enrutadores de la serie MX.

Rutas de host de máquina virtual

Los vRouters de Contrail admiten ARP de proxy y anuncian la dirección IP con la ruta MAC de EVPN para su máquina virtual (VM). Tanto para los enrutadores 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 máquina virtual 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 VM se reenvía directamente en la capa 3 entre los vRouters 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 de EVPN para el servidor sin sistema operativo (BMS) al que está conectado. Como resultado del anuncio de ruta MAC de EVPN desde el conmutador, no se instala ninguna ruta de host BMS en la tabla L3-VRF en enrutadores Contrail vRouters y serie 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 de transportista 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 seleccionarlo 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 Network topology with CE devices CE1 and CE2 linked to PE devices PE1, PE2, PE3. Each PE has VLANs configured: PE1 with 100, 101, 201; PE2 with 100, 101; PE3 with 201. CE1 and CE2 use ESIs ES1 and ES2 for redundancy and load balancing. Orange lines show designated links for traffic flow. de elección de reenviador designado

El dispositivo CE (CE1) tiene un valor de identificador de segmento Ethernet configurado igual a ES1 y está conectado a dispositivos PE1 y PE2, con las 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 igual a ES2 y está conectado a dispositivos PE1 y PE3, con la VLAN 201 configurada. Se elige el enrutador PE3 como el reenviador designado para esta VLAN.

El ID de etiqueta de Ethernet puede ser cualquiera de las siguientes opciones:

  • ID de VLAN (para EVPN-MPLS)

  • ID de red VXLAN (para EVPN-VXLAN)

Documentación relacionada