Dominando Cisco Nexus 9000 VXLAN EVPN Multi-Site: Guía de Diseño 2026

La era del dominio Layer 2 "extendido" a través de OTV o VPLS ha terminado, y si usted todavía depende de vPC back-to-back para la conectividad multi-pod, su radio de explosión es una bomba de tiempo. En 2026, la única arquitectura defendible para interconectar centros de datos distribuidos de alto rendimiento es el modelo Nexus 9000 VXLAN EVPN Multi-Site, que aprovecha las funcionalidades de Border Gateway (BGW) basadas en hardware para localizar los dominios de falla mientras mantiene una movilidad de carga de trabajo sin interrupciones.

La Falacia del Fabric Extendido

Durante años, los arquitectos de redes persiguieron el "santo grial" de un fabric único y unificado a través de múltiples sitios físicos. Este enfoque, si bien simplificaba teóricamente vMotion y la consistencia IP, creaba un entorno frágil de "compartir destino". Una única tormenta BUM (Broadcast, Unknown Unicast, Multicast) en el Sitio A podía, y a menudo lo hacía, derribar los Sitios B y C simultáneamente. La implementación de VXLAN EVPN Multi-Site de Cisco NX-OS resuelve esto desacoplando los protocolos internos del sitio de la Inter-Site Network (ISN).

En un diseño Multi-Site estándar, cada sitio opera su propio plano de control BGP EVPN independiente. Los Border Gateways (BGWs) actúan como el punto de terminación para los túneles VXLAN intra-sitio y el punto de origen para los túneles entre sitios. A diferencia del stretching tradicional, el BGW reescribe el Next-Hop y modifica los Route Targets, asegurando que el aprendizaje de MAC/IP esté aislado. Si ocurre un loop en el Sitio A, los mecanismos de Spanning Tree o control de tormentas dentro de ese sitio lo detectan antes de que se propague a través del enlace ISN de alta latencia.

Selección de Hardware: Cloud Scale o Nada

No intente ejecutar Multi-Site en la primera generación de la serie Nexus 9300. Necesita los ASICs Cloud Scale (EX, FX, FX2, FX3, o las series GX/GX2 más nuevas) para soportar la terminación VXLAN-a-VXLAN requerida y las entradas TCAM necesarias para el mapeo L3VNI y L2VNI. Específicamente para la función de Border Gateway, el Nexus 9364C-GX o el 9336C-FX2 son nuestros estándares de oro para densidad de 100G/400G.

La serie 9300-GX es particularmente crítica en 2026 a medida que avanzamos hacia backbones de 400G. Proporcionan los búferes profundos necesarios para manejar las micro-ráfagas que ocurren al pasar de spines internos de alto ancho de banda a circuitos ISN con ancho de banda potencialmente menor. Evite la serie 9200 para roles de BGW; la paridad de características simplemente no está presente para implementaciones complejas de EVPN Multi-Site.

Arquitectura del Border Gateway (BGW)

El Border Gateway es el componente más crítico en este diseño. Tiene dos modelos de implementación principales: BGW Distribuido (Spines como BGWs) o BGW Dedicado (Leafs como BGWs). En TechLeague, recomendamos casi exclusivamente el modelo de BGW Dedicado (Border Leafs) para entornos empresariales de gran escala. Si bien usar Spines como BGWs ahorra unas pocas unidades de rack, obliga a sus spines a mantener una tabla de enrutamiento BGP completa para el mundo externo, aumentando la presión de la CPU y complicando su límite de administración.

Alta Disponibilidad: Anycast BGW vs. vPC BGW

Los ingenieros de la vieja escuela todavía intentan agrupar sus BGWs en un par vPC. Esto es un error. VXLAN EVPN Multi-Site soporta el modelo de Anycast BGW (IP virtual). En esta configuración, múltiples BGWs comparten la misma dirección IP anycast para el VXLAN tunnel endpoint (VTEP). El uso de Anycast BGW permite hasta 6 u 8 rutas ECMP a través de la ISN, proporcionando una resiliencia y un rendimiento mucho mayores que un clúster vPC de dos nodos.

evpn multisite border-gateway 100
  delay-restore time 30
  provision-model anycast-gw
  multisite-id 1

Al utilizar el modelo anycast, elimina la necesidad de un vPC Peer-Link entre gateways, lo que tradicionalmente ha sido un punto de falla en entornos sensibles a la convergencia. Si un BGW falla, la convergencia BGP en la ISN simplemente redirige el tráfico a los otros miembros anycast sin requerir una compleja negociación LACP.

La Red Inter-Sitio (ISN): No la Complique Demasiado

La ISN es a menudo la parte más incomprendida del diseño. No necesita hablar EVPN. De hecho, no debería hacerlo. La ISN es puramente un medio de transporte que proporciona accesibilidad IP entre los VTEPs BGW. Debe soportar un MTU 1550+ (para acomodar el encabezado VXLAN de 50 bytes) y ejecutar un IGP como OSPF o IS-IS.

Los BGWs establecen peerings Multi-Hop MP-BGP EVPN entre sí a través de la ISN. Abogamos firmemente por el uso de BGP Peer Groups para gestionar estas conexiones, especialmente cuando se escala a más de tres sitios. Aquí hay un fragmento de configuración BGW típico para el peering ISN:

router bgp 65001
  neighbor 10.255.255.10 remote-as 65002
    description Peer_to_Site_B_BGW
    update-source loopback1
    ebgp-multihop 5
    address-family l2vpn evpn
      send-community extended
      rewrite-evpn-rt-asn

El comando rewrite-evpn-rt-asn es vital. Permite que el BGW traduzca Route Targets entre sitios, asegurando que las etiquetas se interpreten correctamente a medida que el tráfico se mueve a través de la ISN.

Multicast L3 y Manejo de Tráfico BUM

Manejar el tráfico BUM entre sitios sin colapsar su WAN es el diferenciador entre un administrador junior y un ingeniero senior. Tiene dos opciones: Ingress Replication (IR) o Multicast con Local-Bias. Para diseños de 2026, la Ingress Replication con Multi-Site Optimizations es el estándar, a menos que tenga requisitos muy específicos de multicast de alto ancho de banda. IR crea copias unicast individuales de paquetes BUM para cada sitio remoto, pero el BGW es lo suficientemente inteligente como para enviar solo una copia al sitio remoto, que el BGW remoto luego replica localmente a sus leafs. Esta "Head-end Replication" reduce significativamente la carga de ancho de banda en su ISN.

Si debe usar Multicast en el core, asegúrese de que su ISN soporte PIM-BSR o PIM-RP. Sin embargo, la complejidad de administrar un RP a través de múltiples dominios administrativos generalmente supera las ganancias de eficiencia para el 90% de las empresas.

Seguridad y Política: Micro-segmentación con Group-Based Policy (GBP)

VXLAN EVPN estándar solo transporta la VNI e información L2/L3. Si desea mantener la postura de seguridad entre sitios, debe implementar VXLAN-GPO (Group-Based Policy). Esto le permite transportar SGTs (Scalable Group Tags) en el encabezado VXLAN. Cuando un usuario en el Sitio A (SGT 10) se comunica con un servidor en el Sitio B, el BGW conserva esa etiqueta. Esto permite que sus firewalls o leafs Nexus en el Sitio B apliquen políticas basadas en el SGT en lugar de una dirección IP que podría haber cambiado.

Como detallamos en nuestra guía sobre Nexus ACI vs. Standalone EVPN, la orquestación manual de SGTs en NX-OS es el principal "punto débil" que a menudo lleva a los clientes hacia ACI. Sin embargo, si su operativa es CLI-first, seguir con NX-OS Multi-Site le brinda una mejor visibilidad del plano de control y evita la naturaleza de "caja negra" de APIC.

Verificación y Realidad Operacional

La resolución de problemas en Multi-Site requiere un dominio de los comandos show nve multisite. No solo está verificando la adyacencia; está verificando si el BGW realmente está anunciando el site-id correcto. Un punto de falla común son los Site-IDs no coincidentes dentro del mismo fabric, lo que hace que el BGW deshabilite el VIP Inter-Site para evitar bucles.

# Estado del BGW
show nve multisite border-gateway
# Accesibilidad del sitio remoto
show bgp l2vpn evpn summary
# Verificar mapeo de VNI entre sitios
show nve vni

Espere que la latencia de su ISN juegue un papel en la convergencia BGP. Ajuste sus temporizadores keepalive y holdtime, pero no los configure por debajo del segundo a menos que tenga un enlace de fibra oscura dedicado. En un tránsito WAN estándar de 10ms-20ms, un keepalive de 3 segundos es el "punto ideal" para evitar fluctuaciones durante eventos menores de jitter.

Conclusión

Cisco Nexus 9000 VXLAN EVPN Multi-Site es la única forma de escalar centros de datos modernos sin heredar los riesgos de un dominio Layer 2 gigante y plano. Al utilizar BGWs Anycast y ASICs Cloud Scale, se construye un entorno resiliente y multi-homed que soporta las demandas de alta velocidad de 2026. Si su diseño actual se basa en vPCs extendidos o superposiciones OTV complejas, es hora de reemplazar la plataforma. Para obtener una revisión experta de su diseño de fabric o para incorporar un equipo de ingeniería de Nivel 3 para su implementación, visite nuestra página de precios en techleague.io para ver cómo podemos acelerar la modernización de su infraestructura.