Descripción general de la arquitectura de columna colapsada con multiconexión EVPN

Este NCE muestra cómo implementar una arquitectura de spine colapsada para dos centros de datos con dos conmutadores QFX5120 spine y dos conmutadores ToR de capa 2 desplegados como un chasis virtual. Los centros de datos están conectados entre sí a través de los dispositivos spine con interconexión del centro de datos (DCI) de capa 3. Utilice la multiconexión EVPN para convertir múltiples conexiones entre los conmutadores ToR a los dispositivos spine. Los servidores son de multihost a los conmutadores ToR. La figura 1 muestra la arquitectura de columna colapsada completa.

Figura 1: Arquitectura de columna colapsada con multiconexión de EVPN

Para el soporte de multidifusión, ofrecemos:

• Multidifusión de capa 3 en un diseño de QFX5120 columna colapsada mediante EVPN OISM con dominios de puente simétrico.

• Espionaje IGMPv2 de multidifusión de capa 2 en EVPN-VXLAN mediante:

  • Rutas de tipo 6 de etiqueta Ethernet de multidifusión selectiva (SMET) de EVPN

  • La sincronización de unión y salida de EVPN (tipo 7 y tipo 8) enruta cuando un receptor de multidifusión está multihost en la capa 2 a los dispositivos de columna colapsada mediante un ESI-LAG.

En una arquitectura de columna colapsada, los dispositivos de columna actúan como dispositivos de columna vertebral y hoja. Dado que los ToR son solo de capa 2 y no admiten VXLAN, no actúan como dispositivos leaf. La actividad normal del dispositivo leaf se maneja, o contrae, en los dispositivos spine, lo que significa que VXLAN solo es necesaria en los dispositivos spine. La columna contraído funciona como una puerta de enlace de capa 3 y gestiona el tráfico entre las VXLAN mediante interfaces IRB.

En un centro de datos heredado con una arquitectura spine colapsada, los conmutadores ToR deben conectarse a los conmutadores spine con grupos de agregación de vínculos multichasis (MC-LAG) para mejorar la resistencia de la red. MC-LAG proporciona redundancia a nivel de nodo y redundancia a nivel de vínculo. Tradicionalmente, los conmutadores spine de estos centros de datos utilizan el protocolo de control entre chasis (ICCP) para proporcionar la funcionalidad MC-LAG. Sin embargo, MC-LAG con ICCP:

• Es una tecnología propietaria.

• No se puede extender eficientemente la capa 2 entre centros de datos.

• No admite más de dos conmutadores de columna vertebral.

EVPN proporciona una solución de multihoming basada en estándares que escala horizontalmente a través de dos o más conmutadores de spine para obtener resistencia y ancho de banda adicionales en caso de que se produzca un fallo en la columna vertebral. La multiconexión EVPN, también conocida como ESI-LAG, proporciona funcionalidad MC-LAG para los conmutadores ToR de capa 2 y los servidores de esta arquitectura sin los inconvenientes de MC-LAG basado en ICCP.

Una arquitectura de columna vertebral colapsada en la que los conmutadores ToR son multihost es una arquitectura de centro de datos que admite conmutadores ToR heredados cuando no admiten EVPN-VXLAN. La figura 2 muestra una arquitectura de spine colapsada con dos conmutadores spine para simplificar y un dispositivo ToR implementado como un Virtual Chassis (consulte Descripción del Virtual Chassis).

Figura 2: Multiconexión EVPN de conmutadores ToR

Las superposiciones de red se crean encapsulando el tráfico y tunelizándolo a través de una red física. El protocolo de tunelización VXLAN encapsula tramas Ethernet de capa 2 en paquetes UDP de capa 3. VXLAN habilita subredes o segmentos virtuales de capa 2 que pueden abarcar la red física de capa 3 subyacente.

En una red superpuesta VXLAN, cada subred o segmento de capa 2 se identifica de forma única mediante un identificador de red virtual (VNI). Un VNI segmenta el tráfico de la misma manera que un ID de VLAN segmenta el tráfico. Como en el caso de las VLAN, los puntos de conexión dentro de la misma red virtual pueden comunicarse directamente entre sí. Los puntos de conexión en diferentes redes virtuales requieren un dispositivo que admita el enrutamiento entre VNI.

La entidad que realiza la encapsulación y la desencapsulación de VXLAN se denomina extremo de túnel VXLAN (VTEP). Normalmente, a cada VTEP se le asigna una dirección IP única.

EVPN es una de las extensiones de BGP que permite a la red transportar información de accesibilidad de la capa de red (NLRI), como las direcciones MAC de capa 2 y las direcciones IP de capa 3. Esta tecnología de plano de control utiliza MP-BGP para la distribución de puntos finales de direcciones MAC e IP, donde las direcciones MAC se tratan como rutas. EVPN permite a los dispositivos que actúan como VTEP intercambiar información de accesibilidad entre sí sobre sus puntos de conexión.

EVPN proporciona redundancia y reenvío de múltiples rutas a través de un modelo totalmente activo. La capa de acceso puede conectarse a dos o más dispositivos spine y reenviar el tráfico utilizando todos los vínculos. Si se produce un error en un vínculo de acceso o dispositivo spine, el tráfico fluye desde la capa de acceso hacia la capa spine utilizando los vínculos activos restantes. Para el tráfico en la otra dirección, los dispositivos spine remotos actualizan sus tablas de reenvío para enviar tráfico al resto de los dispositivos spine activos conectados al segmento Ethernet multiconexión.

Esta arquitectura utiliza VXLAN como protocolo de encapsulación del plano de datos de superposición y MP-BGP con señalización EVPN como protocolo de plano de control de superposición.

• Superposición del plano de datos
• Superposición del plano de control

Superposición del plano de datos

Esta arquitectura utiliza VXLAN como protocolo de encapsulación del plano de datos de superposición en los conmutadores de columna colapsada. Un conmutador que funciona como puerta de enlace VXLAN de capa 2 o capa 3 actúa como extremo de túnel VXLAN y puede encapsular y desencapsular paquetes de datos.

En una sola implementación de centro de datos con dos conmutadores spine, la superposición VXLAN entre los conmutadores spine se usa para el tráfico entre los dos dispositivos. Por ejemplo, si hay un servidor de base única conectado a uno de los dispositivos spine, la superposición VXLAN transporta el tráfico al otro dispositivo spine, ya sea por diseño o en el caso de un error de vínculo.

Como se muestra en la figura siguiente, el servidor DHCP es de base única en Spine 1. Es posible que el tráfico del cliente DHCP se envíe a Spine 2 debido al uso compartido de la carga. Spine 2 envía el tráfico al servidor DHCP a través de la superposición VXLAN con Spine 1.

Figura 3: Topología de superposición del plano de datos

Superposición del plano de control

MP-BGP con señalización EVPN actúa como el protocolo del plano de control de superposición en este ejemplo. Los conmutadores de columna establecen sesiones de IBGP entre sí. La figura 4 muestra la topología de la red superpuesta.

Figura 4: Topología de superposición del plano de control

En los centros de datos más pequeños, no hay una capa de súper espina, por lo que los conmutadores de columna vertebral están conectados directamente entre sí. Los conmutadores de columna vertebral pueden utilizar un protocolo de enrutamiento dinámico en la capa subyacente. El requisito principal en la red subyacente es que todos los dispositivos spine tengan accesibilidad de circuito cerrado. Puede utilizar cualquier protocolo de enrutamiento de capa 3 para intercambiar direcciones de circuito cerrado entre los dispositivos core y spine.

En este ejemplo, usamos EBGP como el protocolo de enrutamiento subyacente entre los conmutadores de columna vertebral. EBGP ofrece beneficios como un mejor filtrado de prefijos, ingeniería de tráfico y etiquetado de tráfico. La figura 5 muestra la topología de la red subyacente de la columna vertebral.

Figura 5: Topología subyacente de la columna vertebral

Dado que los conmutadores ToR no participan en la estructura EVPN-VXLAN y funcionan solo en la capa 2, puede implementarlos como un chasis virtual. En este ejemplo, los conmutadores ToR se implementan como un chasis virtual de dos miembros.

Los enlaces ascendentes de los conmutadores ToR a los conmutadores spine son puertos LAG troncales de capa 2 con VLAN relevantes para el conmutador ToR. Cada chasis virtual es multihost en dos conmutadores spine mediante multiconexión EVPN. La figura 6 muestra la topología de un Virtual Chassis como un dispositivo ToR que es multihost para los dos dispositivos spine. Para obtener redundancia y una mejor resistencia, esta figura muestra las conexiones de spine a ToR Virtual Chassis que se vinculan a diferentes miembros de Virtual Chassis, por lo que se puede seguir teniendo acceso al dispositivo ToR de Virtual Chassis incluso si uno de los miembros de Virtual Chassis deja de funcionar.

Figura 6: Topología del conmutador ToR

Las conexiones de spine to ToR Virtual Chassis en los vínculos Ethernet agregados multihost también pueden incluir vínculos al mismo miembro de Virtual Chassis, que es como se configura este ejemplo de configuración de red. La figura 7 muestra una vista lógica de la topología multiconexión que coincide con la configuración de este documento.

Figura 7: Topología de multiconexión EVPN del conmutador ToR en este ejemplo de configuración de red

Los servidores del centro de datos de este ejemplo son de host múltiple en los conmutadores ToR que se implementan como un chasis virtual. La conectividad del servidor se puede distribuir entre los dos conmutadores ToR con LAG.

Figura 8: Topología de ToR con servidores multihost

En este ejemplo, estamos implementando dispositivos de seguridad SRX en un clúster de chasis que está conectado a los dispositivos spine para proporcionar seguridad avanzada. En un clúster de chasis, dos firewalls de la serie SRX funcionan como un solo dispositivo para proporcionar redundancia de dispositivo, interfaz y nivel de servicio. Los archivos de configuración y los estados de sesión de tiempo de ejecución dinámico se sincronizan entre los firewalls de la serie SRX en un clúster de chasis. Utilice un clúster de chasis SRX para:

• Evite fallas en un solo dispositivo que provoquen una pérdida de conectividad.

• Proporcione alta disponibilidad entre los dispositivos de seguridad al conectar enlaces de sucursales y sitios remotos a oficinas corporativas más grandes.

• Garantice la conectividad en caso de que falle un dispositivo o enlace.

Figura 9: Implementación del clúster de chasis SRX