Interconexión del centro de datos (DCI) / Puertas de enlace EVPN remotas
Puerta de enlace DCI / EVPN Overvew
Históricamente, las empresas han aprovechado la tecnología de interconexión del centro de datos (DCI) como un bloque de construcción para la continuidad del negocio, la recuperación ante desastres (DR) o la continuidad de las operaciones (COOP). Estos casos de uso de disponibilidad de servicios se basaron principalmente en la necesidad de conectar centros de datos separados geográficamente con conectividad de capa 2 para la disponibilidad y el rendimiento de las aplicaciones.
Con el auge de los centros de datos definidos por software (SDDC) altamente virtualizados, la computación en la nube y, más recientemente, la computación de borde, han surgido casos de uso adicionales:
- Expansión de colocación: comparta recursos de computación y almacenamiento para las instalaciones del centro de datos de colocación.
- Agrupación de recursos: comparta y cambie aplicaciones entre centros de datos para aumentar la eficiencia o mejorar la experiencia del usuario final.
- Escalabilidad rápida: expanda la capacidad desde una ubicación con recursos limitados a otra instalación o centro de datos.
- Migración heredada: Mueva las aplicaciones y los datos de equipos y arquitectura antiguos e ineficientes a una arquitectura más eficiente, de mayor rendimiento y rentable.
Con el software de Apstra, puede implementar y administrar una solución DCI que incluya al proveedor que sea simple, flexible y basada en la intención. Apstra utiliza la EVPN MP-BGP basada en estándares con VXLAN, que ha logrado una amplia adopción de software y hardware en la industria de redes. Puede elegir entre una amplia selección de hardware básico rentable, desde proveedores tradicionales hasta ODM de caja blanca y opciones de software que van desde sistemas operativos de red integrados (NOS) de proveedores convencionales hasta opciones de código abierto desagregadas.
EVPN VXLAN es un enfoque basado en estándares (RFC-7432) para construir centros de datos modernos. Incorpora encapsulación de plano de datos (VXLAN) y un plano de control de enrutamiento (familia de direcciones MP-BGP EVPN) para extender dominios de difusión de capa 2 entre hosts, así como dominios enrutados de capa 3 en redes spine-leaf. Basándose en una capa subyacente pura de capa 3 para el enrutamiento del tráfico tunelizado VXLAN entre terminales de túnel VXLAN (VTEP), EVPN introduce una nueva familia de direcciones en la familia de protocolos MP-BGP y admite el intercambio de direcciones MAC/IP entre VTEP. La publicidad de MAC e IP de punto final, así como la "supresión de ARP/ND", elimina la necesidad de una gran mayoría de tráfico de difusión/desconocido/multidifusión (BUM) y se basa en el enrutamiento de unidifusión ECMP de VXLAN, desde el VTEP de origen hasta el VTEP de destino. Esto garantiza una selección de ruta óptima y un reparto eficiente de la carga de las rutas de reenvío para el tráfico de red superpuesto.
Al igual que EVPN VXLAN funciona dentro de un solo sitio para extender la capa 2 entre hosts, la función DCI permite la conectividad de capa 2 entre sitios. La función Apstra DCI permite la extensión de servicios de capa 2 o capa 3 entre centros de datos para recuperación ante desastres, equilibrio de carga de sitios activos o incluso para facilitar la migración de servicios de un centro de datos a otro.
Limitaciones:
-
No se admite EVPN-GW (DCI) entre la estructura EVPN de diferentes proveedores.
-
IPv6 no es compatible con las puertas de enlace EVPN remotas. (Las rutas EVPN reales pueden contener IPv6 tipo 2 y tipo 5).
Opciones de despliegue de DCI
Las siguientes características se aplican a todas las opciones de implementación:
- Puede extender Apstra DCI a otros centros de datos administrados por Apstra, centros de datos no administrados por Apstra o incluso a dispositivos heredados que no son spine-leaf.
- La implementación y el comportamiento de Apstra son los mismos en los tres casos.
- Ya sea que el extremo remoto sea otro GW DCI o un ASBR, Apstra lo transparente.
- Apstra no gestiona ni los GW ni los ASBR.
Puede implementar la interconexión del centro de datos mediante los métodos siguientes. Para obtener ayuda con la selección de la mejor opción para su organización, consulte a su arquitecto de soluciones (SA) o ingeniero de sistemas (SE) de Apstra.
Pasado de rosca
DCI "Over the Top" es una solución transparente, lo que significa que las rutas EVPN están encapsuladas en IP estándar y ocultas del transporte subyacente. Esto hace que la extensión de los servicios sea simple y flexible, y a menudo se elige porque los equipos del centro de datos pueden implementarla con poca o ninguna coordinación con WAN o grupos de proveedores de servicios. Esto reduce los tiempos de implementación y la fricción interna de la empresa. Sin embargo, la desventaja es la escalabilidad y la resistencia. 
Puerta de enlace (GW)
Sobre la base de la capacidad de la puerta de enlace EVPN remota de Apstra, puede especificar opcionalmente que la puerta de enlace EVPN remota sea un sistema genérico externo (etiquetado como un enrutador externo) en el mismo sitio, extendiendo así los atributos de EVPN a dicha puerta de enlace. Esta solución crea un dominio de error por sitio, evitando que los errores afecten a la convergencia en sitios remotos y creando varios dominios de error. Las tablas de puntos finales IP/MAC para sitios remotos se procesan y mantienen en estado en una puerta de enlace genérica del sistema (etiquetada como enrutador externo). También puede implementar QoS WAN y seguridad, junto con optimizaciones que la tecnología de transporte pone a disposición (MPLS TE, por ejemplo). Sin embargo, esta solución es más compleja operativamente y requiere hardware y costos adicionales. 
Enrutador de borde del sistema autónomo (ASBR)
Con la capacidad de la puerta de enlace EVPN remota de Apstra, puede especificar opcionalmente que la puerta de enlace EVPN remota sea un dispositivo de borde WAN ASBR. Esta EVPN de extremo a extremo permite una encapsulación uniforme y elimina el requisito de GW dedicado. Es operacionalmente complejo, pero tiene una mayor escalabilidad en comparación con "DCI Using Gateway" y "Over the Top". 
Implementación
Puede extender zonas de enrutamiento y redes virtuales (VN) para abarcar planos administrados por Apstra (entre pods) o a redes remotas (entre centros de datos) que Apstra no administra. Esta característica introduce el rol de puerta de enlace EVPN (GW), que podría ser un conmutador que participa en la estructura o en los servidores de ruta en un sistema genérico (etiquetado como servidor) que está conectado a la estructura.
- Casos de uso de puertas de enlace EVPN
- Pasado de rosca
- Extensión del plano de datos: capa 3
- Extensión del plano de datos: capa 2
Casos de uso de puertas de enlace EVPN
- Amplíe los dominios de aislamiento de capa 3 (VRF / zonas de enrutamiento) a múltiples pods administrados por Apstra (planos) o extienda a dominios EVPN remotos.
- Proporcionar extensiones de dominio de capa 2 para L2VNI / redes virtuales.
- Ayude a extender el dominio EVPN de Apstra a administrado por Apstra y Apstra a pods no administrados.
- Sin terminación de tráfico VXLAN en los dispositivos spine: conecte sistemas genéricos externos (etiquetados como enrutadores externos) en dispositivos spine. Esto es para admitir conectividad externa IPv4 (subyacente). En este caso, los dispositivos spine no necesitan terminar el tráfico VXLAN, a diferencia de los dispositivos leaf de borde, cuando están conectados a sistemas genéricos externos (etiquetados como enrutadores externos). En pocas palabras, su uso puede intercambiar rutas IPv4 a VTEP remotos (en la zona de enrutamiento/VRF predeterminada) y solo se requiere conectividad de capa 3:
Pasado de rosca
Cuando el emparejamiento BGP EVPN se realiza de forma "exagerada", la puerta de enlace del centro de datos (DC-GW) es una función de transporte IP pura y el emparejamiento BGP EVPN se establece entre puertas de enlace en diferentes centros de datos.
En las siguientes secciones se describen los procedimientos para interconectar dos o más sitios VPN Ethernet (EVPN) basados en BGP de forma escalable a través de una red IP. La motivación es admitir la extensión de sitios EVPN sin tener que depender de tecnologías típicas de interconexión del centro de datos (DCI) como MPLS / VPLS, que a menudo son difíciles de configurar, a veces propietarias y probablemente de naturaleza heredada.
"Over the Top" es una solución simple que solo requiere enrutamiento IP entre centros de datos y una MTU ajustada para admitir la encapsulación VXLAN entre puntos finales de puerta de enlace. En dicha implementación, las rutas EVPN se extienden de extremo a extremo a través de MP-BGP entre sitios. El BGP de múltiples saltos se habilita con la suposición de que habrá varios saltos de capa 3 entre sitios a través de una WAN. De lo contrario, el TTL predeterminado disminuye a 0 y los paquetes se descartan y no llegan al enrutador remoto. Apstra representa automáticamente la configuración necesaria para abordar estas limitaciones. 
Este diseño combina los dominios EVPN-VXLAN independientes y los túneles VXLAN entre sitios. La combinación de dominios EVPN previamente separados en diferentes sitios ofrece la ventaja de extender los servicios de capa 2 y capa 3 (VRF) entre sitios, pero también los convierte en un único dominio de error. Por lo tanto, una falla en un sitio se propaga necesariamente. Además, cada vez que extiende la capa 2 a través de la WAN entre sitios, también está extendiendo el dominio de inundación y, junto con él, todo el tráfico de difusión a través de sus costosos enlaces WAN. En este momento, esta solución no ofrece ningún filtrado ni QoS.
Cuando los planos independientes de Apstra administran sitios individuales (o cuando solo un sitio es administrado por Apstra), debe crear y administrar zonas de enrutamiento extendido (VRF) y redes virtuales (VLAN/subredes definidas de capa 2 o capa 3) de forma independiente en cada sitio. Debe asignar manualmente VRF y VN entre sitios (creando una sobrecarga administrativa).
Si está configurando conexiones P2P entre dos centros de datos (planos) en el mismo controlador Apstra, cada plano debe extraer recursos de diferentes grupos de IP para evitar errores de compilación. Para ello, cree dos grupos de direcciones IP con la misma subred IP, pero con nombres diferentes.
Esta solución "Over the Top" es la más fácil de implementar, no requiere hardware adicional y no introduce ninguna configuración WAN adicional aparte de aumentar la MTU. Es el más flexible y tiene la barrera de entrada más baja. Sin embargo, la desventaja es que hay un solo plano de control EVPN y una anomalía de enrutamiento en un sitio afectará la convergencia y la accesibilidad en los otros sitios. La extensión de los dominios de inundación de la capa 2 también implica que una tormenta de difusión en un sitio se extiende a los otros sitios.
Con cualquier implementación de DCI, se requiere una cuidadosa planificación y coordinación de recursos. Agregar más sitios requiere un aumento exponencial en dicha planificación y coordinación. Los bucles VTEP en la capa subyacente deben filtrarse. Los VNID deben coincidir entre sitios y, en algunos casos, se deben importar destinos de ruta (RT) adicionales. Esto se trata en detalle más adelante en este documento.
Extensión del plano de datos: capa 3
Los identificadores de red VXLAN (VNID) son una parte del encabezado VXLAN que identifica túneles VXLAN únicos, cada uno de los cuales está aislado de los otros túneles VXLAN en una red IP. Los paquetes de capa 3 se pueden encapsular en un paquete VXLAN o las tramas MAC de capa 2 se pueden encapsular directamente en un paquete VXLAN. En ambos casos, un VNID único está asociado a la subred de capa 3 o al dominio de capa 2. Al extender servicios de capa 3 o capa 2 entre sitios, básicamente está uniendo túneles VXLAN entre sitios. Por lo tanto, los VNID deben coincidir entre sitios.
Es importante entender que un VNID en particular se asociará con un solo VRF (o zona de enrutamiento en la terminología de Apstra). Los VNID existen dentro de un VRF. Están vinculados a un VRF. Para los servicios de capa 3, la unión o extensión de cada VNID se realiza con la exportación e importación de RT dentro de una zona de enrutamiento (VRF). Las subredes de capa 3 (rutas) se identifican mediante RT. Todos los VNID se exportan automáticamente en la puerta de enlace EVPN (borde) hacia la WAN. Por el contrario, los RT del mismo valor se importan automáticamente en la puerta de enlace EVPN (borde) que entra en la estructura. Por lo tanto, si coordina los VNID de capa 3 en un sitio para que coincidan con el otro, no se necesita ninguna configuración adicional. 
En la imagen de arriba, no se requiere exportación o importación adicional. Todo se exporta automáticamente (Exportar todo) y, como los RT coinciden, se importan automáticamente.
Sin embargo, si un VNID en DC1 es diferente de un VNID en DC2, debe importar los RT respectivamente. Cada puerta de enlace respectiva sigue importando automáticamente RT del mismo valor. En el ejemplo siguiente, se requiere un paso adicional para agregar manualmente los RT desde el otro sitio. 
Extensión del plano de datos: capa 2
Una red virtual puede ser un servicio puro de capa 2 (la puerta de enlace anycast de capa 3 no se instancia). Puede ser local en rack (VLAN en puertos orientados al servidor contenidos dentro de un rack) o VXLAN (seleccione los racks para extender el dominio de inundación y difusión de capa 2 entre racks). Este dominio de capa 2 tiene su propio VNID y las tramas MAC (a diferencia de los paquetes IP) se encapsulan en el encabezado VXLAN con el VNID del dominio de capa 2.
Se aplican los mismos principios en el sentido de que todos los VNID se exportan a la puerta de enlace EVPN (en este caso, rutas de tipo 2/direcciones MAC) y los RT coincidentes se importan automáticamente. Sin embargo, la ubicación de importación y exportación de RT no se encuentra en el nivel de zona de enrutamiento, sino en la propia red virtual.
Flujo de trabajo de Apstra
- Extensión del plano de control: puerta de enlace EVPN
- Anuncios de rutas VTEP subyacentes
- Crear puertas de enlace remotas o externas
- Zona de enrutamiento mejorada
- Redes virtuales mejoradas
- Representación de topología de puerta de enlace remota
Extensión del plano de control: puerta de enlace EVPN
Apstra utiliza el concepto de "puerta de enlace EVPN". En teoría, este dispositivo puede ser un nodo de estructura leaf, spine o superspine, así como el dispositivo DCI. Las puertas de enlace EVPN separan el lado de la estructura de la red que interconecta los sitios y enmascara los VTEP internos del sitio.
En Apstra, una puerta de enlace EVPN es un dispositivo que pertenece y reside en el borde de una estructura EVPN que también está conectada a una red IP externa. En un plano de EVPN de Apstra, este es siempre un dispositivo de hoja de borde. La puerta de enlace EVPN de un centro de datos establece un emparejamiento BGP EVPN con una puerta de enlace EVPN recíproca, o puertas de enlace, en otro centro de datos. La "otra" puerta de enlace EVPN es la "puerta de enlace EVPN remota" en la terminología de Apstra. Se supone que la puerta de enlace EVPN local es uno de los dispositivos administrados por Apstra en el plano y se selecciona al crear la "puerta de enlace EVPN remota". La puerta de enlace EVPN local será el conmutador de hoja de borde con una o más conexiones de enrutamiento externas para el tráfico que entra y sale de la estructura Clos de EVPN.
Debido a esta capacidad, puede configurar una puerta de enlace EVPN local (siempre un conmutador administrado por Apstra) para emparejarse con un dispositivo que no esté administrado por Apstra, o incluso con un dispositivo que no sea Spine-Leaf, en otro controlador de dominio. El emparejamiento BGP de la puerta de enlace EVPN se usa para transportar todos los atributos de EVPN desde el interior de un pod hasta el exterior del pod. En el entorno de Apstra, cada plano representa un centro de datos. Si dos o más sitios están bajo la administración de Apstra, aún debe configurar cada sitio para que apunte a la(s) "Puerta de enlace EVPN remota(s)" en otros sitios. Le recomendamos que cree varias puertas de enlace EVPN redundantes para cada centro de datos. Actualmente también existe un requisito de malla completa entre las puertas de enlace EVPN, aunque en futuras versiones este requisito se eliminará.
Anuncios de rutas VTEP subyacentes
La accesibilidad subyacente a las direcciones IP VTEP, o una ruta de resumen equivalente, debe establecerse recíprocamente. Cada sitio debe anunciar estos bucles invertidos de VTEP desde la zona de enrutamiento predeterminada hacia los anuncios subyacentes de BGP (IPv4) exportados. Los loopbacks de la directiva de enrutamiento están habilitados de forma predeterminada.
Crear puertas de enlace remotas o externas
De forma predeterminada, ESI MAC msb (byte más significativo) se establece en 2 en todos los planos. Cada plano de Apstra que esté conectado debe tener un msb único para evitar problemas que afecten al servicio. Antes de crear puertas de enlace, cambie ESI MAC msb en consecuencia. (Puede dejar uno de ellos en el valor predeterminado).
La puerta de enlace EVPN remota es una función lógica de la que puede crear instancias en cualquier lugar y dispositivo. Requiere soporte BGP en general, L2VPN/EVPN AFI/SAFI específicamente. Para establecer una sesión BGP con una puerta de enlace EVPN, la conectividad IP, así como la conectividad con el puerto TCP 179 (la IANA asigna puertos TCP BGP), deben estar disponibles.
Para mantener la resistencia, recomendamos tener al menos dos puertas de enlace remotas para el mismo dominio EVPN remoto.
- En el plano, vaya a Puertas de enlace > por etapas > DCI Over the Top o External Gateways (Puertas de enlace externas ) y haga clic en Create Over the Top (Crear puerta de enlace externa o Over the Top o External Gateway).
Se abrirá el cuadro de diálogo Crear sobre la parte superior o puerta de enlace externa .
Introduzca los detalles, según corresponda.
Al extender redes L2 entre estructuras de centros de datos, tiene la opción de intercambiar solo prefijos RT-5 de tipo de ruta EVPN (modelo sin interfaz). Esto resulta útil cuando no es necesario intercambiar todas las rutas de host entre ubicaciones de centros de datos. Esto da como resultado requisitos más pequeños para la base de información de enrutamiento (RIB), también conocida como la tabla de enrutamiento, y la base de información de reenvío (FIB), también conocida como la tabla de reenvío, en equipos DCI.
Seleccione los nodos de puerta de enlace local. Estos son los dispositivos del plano que se configurarán con una puerta de enlace EVPN local. Puede seleccionar uno o más dispositivos para emparejarlos con la puerta de enlace EVPN remota configurada. Puede utilizar la función de consulta para ayudarle a localizar los nodos adecuados. Recomendamos utilizar varios dispositivos de hoja de borde que tengan conexiones directas a sistemas genéricos externos (etiquetados como enrutadores externos).
- Haga clic en Crear para organizar la puerta de enlace y volver a la vista de tabla.
- Cuando esté listo para implementar los dispositivos en el plano, confirme los cambios.
Recomendamos usar varias puertas de enlace EVPN remotas. Para configurar puertas de enlace EVPN remotas adicionales, repita los pasos anteriores.
Si está configurando las puertas de enlace EVPN remotas en otro plano de Apstra, debe configurar e implementar las puertas de enlace EVPN remotas por separado en ese plano.
Una vez implementado el cambio, Apstra monitorea la sesión BGP para las puertas de enlace EVPN remotas. Para ver cualquier anomalía en el plano, vaya a Anomalías > activas.
Zona de enrutamiento mejorada
Las políticas de importación/exportación RT (destino de ruta) en dispositivos que forman parte del servicio extendido rigen la instalación de rutas de EVPN. Especifique políticas de destino de ruta para agregar destinos de ruta de importación y exportación que Apstra usa para las zonas de enrutamiento/VRF. Esto se hace cuando se crean zonas de enrutamiento. Vaya a Zonas de enrutamiento > virtual por etapas > y haga clic en Crear zona de enrutamiento. Para obtener más información, consulte Zonas de enrutamiento.
El destino de ruta predeterminado generado para las zonas de enrutamiento es <L3 VNI>:1. No puede cambiar este valor predeterminado.
Para confirmar que se reciben las rutas correctas en VTEP, asegúrese de que las L3VNI y el destino de ruta sean idénticos entre el plano y los dominios EVPN remotos.
Redes virtuales mejoradas
Puede agregar destinos de ruta de importación y exportación adicionales que Apstra usa para redes virtuales.
El destino de ruta predeterminado que genera Apstra para las redes virtuales es <L2 VNI>:1. No puedes alterar esto.
Para la comunicación intra-VNI se utiliza RT específico L2VNI. El RT de importación se utiliza para determinar qué rutas recibidas son aplicables a un VNI determinado. Para establecer la conectividad, las VNI de capa 2 deben ser las mismas entre el plano y los dominios remotos. Las subredes de SVI deben ser idénticas en todos los dominios.
Representación de topología de puerta de enlace remota
Las puertas de enlace EVPN remotas se representan en la vista de topología como elementos de nube con conexiones de línea punteada a los elementos de plano con los que se establecen las sesiones BGP, como se muestra en la imagen siguiente. (La imagen de abajo es ligeramente diferente de las versiones más recientes). 