¿Cuál es la principal diferencia en el control plane entre ACI, NSX y VXLAN EVPN?

ACI utiliza un controller APIC propietario y centralizado para programar switches Cisco Nexus. NSX emplea un overlay de software distribuido gestionado por NSX Managers y controllers. VXLAN EVPN con BGP utiliza un protocolo de enrutamiento BGP distribuido y basado en estándares para el intercambio de información del control plane directamente entre dispositivos de red.

¿Qué solución ofrece la mejor micro-segmentación para máquinas virtuales?

El Distributed Firewall (DFW) de VMware NSX se considera generalmente superior para la micro-segmentación de VMs. Aplica políticas directamente en el kernel del hypervisor, proporcionando seguridad granular y consciente de la identidad hasta NICs de VM individuales, independientemente de la topología de red física subyacente.

¿Es el vendor lock-in una preocupación con estas soluciones?

Sí, lo es. Cisco ACI tiene el mayor vendor lock-in, ya que requiere hardware Cisco Nexus específico y su controller APIC. VMware NSX le vincula al ecosistema VMware. VXLAN EVPN con BGP ofrece el menor vendor lock-in, ya que se basa en estándares y es compatible con múltiples proveedores de hardware de red, aunque las herramientas de automatización podrían volverse específicas del proveedor.

¿Qué solución es más adecuada para un alto porcentaje de servidores bare-metal?

Para entornos con una alta densidad de servidores bare-metal, Cisco ACI y NX-OS VXLAN EVPN nativo son generalmente mejores opciones. ACI trata los servidores bare-metal como ciudadanos de primera clase dentro de su modelo EPG. VXLAN EVPN extiende la capa 2 directamente a las NICs de los servidores bare-metal, tratándolos como endpoints regulares en el overlay. NSX, aunque capaz, suele requerir más esfuerzo para integrar cargas de trabajo bare-metal sin problemas en comparación con su integración nativa de VM.

¿Pueden estas soluciones integrarse con entornos de cloud pública?

Sí. El Multi-Site Orchestrator de ACI extiende las políticas entre entornos on-premises y cloud pública (AWS, Azure, Google Cloud) a través de los cloud services controllers. NSX soporta arquitecturas hybrid cloud con NSX Cloud, extendiendo el DFW y las políticas de red a las VPCs de la cloud pública. La integración de VXLAN EVPN con la cloud pública típicamente implica aprovechar IPsec VPN o Direct Connect / ExpressRoute con enrutamiento para formar una red enrutada más grande, o utilizar construcciones de red nativas de la cloud pública.

¿Cuál es la curva de aprendizaje típica para cada solución para un ingeniero de red senior?

ACI tiene una curva de aprendizaje alta debido a su modelo centrado en políticas y orientado a objetos, que requiere un cambio en la forma de pensar de la configuración tradicional por CLI. NSX tiene una curva moderada a alta, especialmente al comprender los componentes distribuidos y las redes overlay. VXLAN EVPN con BGP, aunque basado en estándares, todavía requiere una sólida comprensión de los conceptos de BGP EVPN, enrutamiento/switching y cadenas de herramientas de automatización, lo que lo convierte en una curva moderada pero quizás más alineada con la experiencia de red tradicional.

¿Qué opción es mejor para un data center pequeño o mediano (menos de 16 switches leaf)?

Para despliegues más pequeños, el TCO para ACI y NSX puede ser desproporcionadamente alto debido a los costos del controller/licencias. Un fabric NX-OS VXLAN EVPN bien diseñado a menudo proporciona una solución más rentable y operacionalmente más simple para pymes con sólidas capacidades de ingeniería de red. ACI o NSX podrían justificarse si la micro-segmentación y la automatización avanzadas son primordiales, incluso en escalas más pequeñas.

Cisco ACI 6.x vs VMware NSX 4.2 vs NX-OS VXLAN EVPN: Arquitecturas de Data Center 2026

La elección de una infraestructura de red de data center en 2026 implica más que solo el reenvío de paquetes. Se trata de automatización, estrategia multi-cloud, seguridad granular y gastos operativos (OPEX). Diseccionamos las fortalezas y debilidades de Cisco ACI 6.x, VMware NSX 4.2 y la solución tradicional NX-OS VXLAN EVPN con BGP como control plane. Este no es un ejercicio teórico; estos son los sistemas que sustentan infraestructuras multimillonarias.

Filosofías Arquitectónicas y Control Planes

Cisco ACI (Application Centric Infrastructure) opera sobre un modelo declarativo y basado en políticas, utilizando el Application Policy Infrastructure Controller (APIC). APIC es efectivamente el cerebro, traduciendo las políticas de aplicación de alto nivel en configuraciones de red concretas en los switches Nexus serie 9000 (leaf y spine). Este controller centralizado gestiona todo, desde los VXLAN tunnel endpoints hasta las políticas de security group (EPGs y contracts). El control plane es propietario, estrechamente acoplado con el clúster APIC. ACI 6.x sigue refinando Multi-Site Orchestrator (MSO) para implementaciones multi-fabric y hybrid cloud, centralizando la distribución de políticas en dominios APIC geográficamente dispersos.

VMware NSX-T (ahora simplemente NSX) adopta un enfoque de software-defined networking (SDN), abstraiendo los servicios de red y seguridad del hardware subyacente. Su control plane se distribuye entre NSX Managers (para gestión centralizada) y una red de controllers que programan los vSwitches del hypervisor (por ejemplo, vSphere Distributed Switch, o N-VDS/VDS con componentes específicos de NSX) y los NSX Edges. Aunque NSX puede integrarse con fabrics de red físicos, su fortaleza radica en su estrecha integración con el ecosistema VMware, extendiendo la micro-segmentación y los servicios L4-L7 directamente a la capa del hypervisor. NSX Federation permite la distribución de políticas entre múltiples instancias de NSX Manager.

NX-OS VXLAN EVPN con BGP es un enfoque abierto y basado en estándares. Aprovecha BGP como control plane para la distribución de rutas VXLAN EVPN, logrando un fabric de red distribuido sin un controller SDN propietario. Cada BGP speaker (típicamente switches Cisco Nexus serie 9000, Arista serie 7000 o Juniper serie QFX) actúa como un peer, intercambiando información de alcance MAC e IP sobre la red física (underlay). Esto elimina la preocupación del 'single point of failure' a menudo planteada con los controllers centralizados, aunque traslada la complejidad a la gestión de las configuraciones BGP en muchos dispositivos. La automatización se logra típicamente mediante Ansible, Python u orchestrators externos, no un controller integrado y específico del proveedor.

Escalabilidad y Operaciones Multi-Site

Los fabrics ACI 6.x escalan a cientos de switches leaf y decenas de miles de endpoints. Multi-Pod extiende un único clúster APIC a través de múltiples sitios físicos dentro de un área metropolitana, mientras que Multi-Site Orchestrator (MSO) federa múltiples dominios APIC, permitiendo una implementación de políticas consistente y movilidad de cargas de trabajo a través de data centers geográficamente diversos. Por ejemplo, un fabric ACI de 8 leaf utilizando Nexus 93180YC-FX3 puede escalar hasta 128 leaf con Nexus 9332C-FX2/9364C-FX2 como spines. Una única implementación de MSO puede gestionar hasta 16 fabrics ACI.

Las implementaciones de NSX 4.2 escalan a cientos de NSX Edges y soportan decenas de miles de VMs/cargas de trabajo por instancia de NSX Manager. NSX Federation proporciona una solución multi-site, permitiendo que las políticas se definan una vez y se apliquen consistentemente a través de hasta 3 Global Managers, cada uno gestionando múltiples Local Managers. Esto soporta arquitecturas active-active o active-standby de data centers. Cuando se integra con Tanzu Kubernetes Grid, NSX escala a cientos de miles de contenedores pods, con el NSX Container Plugin (NCP) o Antrea proporcionando servicios de red.

La escalabilidad de VXLAN EVPN depende en gran medida de las capacidades del hardware subyacente y del diseño BGP. Switches modernos como el Nexus 93180YC-FX3 o Arista 7050SX3-48YC12 pueden manejar cientos de miles de entradas MAC/rutas. Un fabric VXLAN EVPN típico puede escalar a cientos de switches leaf con la capacidad de spine adecuada. Multi-site se logra a través de DCI (Data Center Interconnect) utilizando EVPN extendido sobre MPLS o IP, o mediante fabrics standalone con enrutamiento IP/VPN para conectividad L3. La naturaleza distribuida permite un modelo de 'scale-out' sin alcanzar los límites estrictos de un controller central.

Micro-segmentación y Seguridad

La micro-segmentación de ACI es intrínseca a su modelo de políticas. Los Endpoint Groups (EPGs) son agrupaciones lógicas de endpoints (VMs, bare-metal, contenedores) que necesitan políticas de red y seguridad similares. Los Contracts definen la comunicación permitida entre EPGs, operando desde la Capa 2 hasta la Capa 4. Este modelo implementa eficazmente una filosofía Zero Trust, con una postura de 'denegar por defecto' para el tráfico entre EPGs a menos que esté explícitamente permitido por un contract. ACI también se integra con dispositivos de servicio L4-L7 (firewalls como FortiGate 1800F o Palo Alto PA-5440) a través de service graphs, automatizando la inserción y el direccionamiento de políticas.

NSX proporciona robustas capacidades de distributed firewall (DFW) aplicadas directamente en el kernel del hypervisor. Esto permite una micro-segmentación extremadamente granular, hasta NICs de VM individuales, basada en varios atributos como nombre de VM, SO, security tags o grupos de Active Directory. Las reglas de NSX DFW pueden aplicarse al tráfico L2-L7, soportando seguridad a nivel de aplicación. Los NSX Gateway Firewalls (en NSX Edges) proporcionan seguridad perimetral (tráfico North-South), mientras que el DFW maneja East-West. NSX también soporta servicios de seguridad avanzados como IDS/IPS, sandbox e inspección de red a través de la inserción de servicios para partners.

VXLAN EVPN proporciona de forma nativa segmentación de red a través de VNIs (VXLAN Network Identifiers), actuando eficazmente como redes virtuales separadas. Las capacidades de micro-segmentación se logran típicamente a través de firewalls externos para el tráfico North-South y East-West, o a través de policy-based routing (PBR) para redirigir el tráfico a los dispositivos de seguridad. Aunque switches como el Nexus 9000 soportan ACLs y una aplicación de políticas rudimentaria, carecen de las capacidades granulares y conscientes de la identidad de los contracts de ACI o el DFW de NSX. Una micro-segmentación más avanzada en EVPN a menudo se basa en firewalls basados en host (por ejemplo, iptables de Linux, Windows Firewall) o overlays SDN complementarios como Cilium para entornos de Kubernetes.


! Cisco ACI Contract Example (simplified XML)

  


  
     
      
    
  


! NSX DFW Rule Example (Conceptual - via API/UI)
Source: Security_Group_Web_Servers
Destination: Security_Group_DB_Servers
Services: TCP 3306
Action: ALLOW
Applied To: Security_Group_Web_Servers

! NX-OS VXLAN EVPN BGP config snippet for VNI mapping
feature bgp
router bgp 65001
  address-family l2vpn evpn
    retain route-target all
  vrf context Tenant_A
    address-family ipv4 unicast
      route-target export 65001:1001
      route-target import 65001:1001
    address-family ipv6 unicast
      route-target export 65001:1001
      route-target import 65001:1001
  vlan 100
    vn-segment 10001
interface nve1
  no shutdown
  source-interface loopback0
  host-reachability protocol bgp
  member vni 10001
    mcast-group 239.1.1.1

Integración con Cloud-Native (Kubernetes) y Servicios L4-L7

ACI ofrece el plugin ACI CNI para Kubernetes, extendiendo su modelo de políticas a entornos de contenedores. Esto permite que los Kubernetes Pods sean tratados como EPGs de ACI, aplicando directamente las políticas del fabric. Para los servicios L4-L7, los service graphs de ACI pueden automatizar la inserción y configuración de dispositivos físicos o virtuales, dirigiendo el tráfico a través de un FortiGate 1800F o un load balancer como un F5 Big-IP, basándose en los contracts de EPG. Esto proporciona una orquestación centralizada de los servicios de red y seguridad.

NSX tiene una fuerte integración con Kubernetes, especialmente con Antrea (CNI open source) y su propio Container Plugin (NCP). Antrea proporciona políticas de red y seguridad para Kubernetes Pods, aprovechando el DFW de NSX para micro-segmentación y extendiendo la visibilidad de la red. NSX Advanced Load Balancer (anteriormente Avi Networks) se integra completamente para balanceo de carga L4-L7 y servicios WAF, con despliegue y escalado automatizados. NSX también soporta la inserción de servicios para varios dispositivos de seguridad, convirtiéndolo en una plataforma integral para cargas de trabajo cloud-native.

Para VXLAN EVPN, la integración con Kubernetes típicamente se basa en CNIs independientes como Calico o Cilium. Cilium, en particular, aprovecha eBPF para la aplicación de políticas de red de alto rendimiento y la observabilidad, ofreciendo micro-segmentación nativa de Kubernetes sin dependencia directa del fabric subyacente. La inserción de servicios L4-L7 generalmente implica la integración de proveedores separados (por ejemplo, NGINX, HAProxy, firewalls de terceros) y la gestión de su direccionamiento de tráfico a través de PBR en los switches leaf, o confiando en los Kubernetes Ingress/Egress controllers. Este enfoque es altamente flexible pero requiere una orquestación más manual que ACI o NSX.

Costo Total de Propiedad (TCO) y Consideraciones Operacionales

El TCO es un diferenciador crítico. ACI introduce un costo inicial significativo para los controllers APIC (típicamente clústeres de 3 o 5 nodos para redundancia) y switches Nexus serie 9000 con licencias específicas (por ejemplo, Advantage/Premier). Aunque la automatización reduce las tareas operativas, la curva de aprendizaje para el modelo de políticas de ACI puede ser pronunciada. Los contratos de mantenimiento para APIC y los switches Nexus son sustanciales. Las actualizaciones (por ejemplo, ACI 5.x a 6.x) pueden ser complejas, a menudo requiriendo una planificación significativa y potencialmente ventanas de mantenimiento en todo el fabric.

NSX también tiene un costo de licencia sustancial, a menudo por socket de CPU o por VM, lo que puede aumentar rápidamente en entornos grandes. Los costos de hardware para los NSX Edges son separados, aunque pueden ejecutarse en servidores estándar (commodity servers). La complejidad operativa proviene de la gestión del overlay extendido y la posible integración con los underlays físicos existentes. Las actualizaciones para NSX Manager y los nodos Edge pueden ser disruptivas si no se planifican cuidadosamente. NSX Federation añade otra capa de complejidad y coste de gestión. Sin embargo, los beneficios operativos de la seguridad automatizada y el aprovisionamiento de red son altos.

NX-OS VXLAN EVPN a menudo aparece como la opción de CAPEX más baja en términos de licencias, basándose en características estándar de sistemas operativos de red y BGP. Los costos de hardware para los switches Nexus 9000 son comparables a los de ACI, pero sin clústeres APIC obligatorios. El OPEX para EVPN, sin embargo, puede ser mayor debido a la naturaleza distribuida del control plane y la necesidad de herramientas de automatización robustas (Ansible, Puppet, etc.) para mantener la consistencia en muchos dispositivos. La resolución de problemas puede ser más desafiante debido a la falta de un motor de correlación centralizado como APIC o NSX Manager. Las actualizaciones suelen ser por switch, minimizando el impacto en todo el fabric pero aumentando la gestión individual del dispositivo.

**Matriz Comparativa de Fabrics de Data Center (Proyecciones 2026)**
Característica	Cisco ACI 6.x	VMware NSX 4.2	NX-OS VXLAN EVPN (BGP)
Control Plane	Centralizado (APIC), Propietario	Distribuido (NSX Managers + Controllers), Overlay Propietario	Distribuido (BGP EVPN), Basado en Estándares
Micro-segmentación	EPGs y Contracts (L2-L4), Service Graphs	Distributed Firewall (DFW) (L2-L7), Consciente de la Identidad	VLAN/VNI, Firewalls Externos, ACLs, (Cilium para K8s)
Integración con Kubernetes	ACI CNI (modelo EPG)	Antrea / NCP (políticas DFW)	Calico / Cilium (Independiente)
Multi-Site	Multi-Pod, Multi-Site Orchestrator	NSX Federation	DCI con EVPN/MPLS, IP VPN
Curva de Aprendizaje	Alta (Modelo de Políticas)	Moderada-Alta (Overlay, Servicios Distribuidos)	Moderada (Conceptos BGP EVPN, Automatización)
Vendor Lock-in	Alto (Cisco Nexus)	Moderado (Ecosistema VMware)	Bajo (Soporte de hardware Multi-vendor)
Capex Estimado (fabric de 8 leaf)	$350k - $600k (incl. APIC, Nexus 93180YC-FX3)	$280k - $500k (incl. licencias NSX, Edges)	$180k - $300k (incl. Nexus 93180YC-FX3)
Opex Estimado (anual)	$60k - $100k (mantenimiento, admin dedicado)	$50k - $90k (mantenimiento, admin dedicado)	$40k - $80k (mantenimiento, esfuerzos de automatización)

Ciclos de Actualización y Vendor Lock-in

Las rutas de actualización de ACI (por ejemplo, de ACI 5.2 a 6.0 y luego a versiones intermedias de 6.x) tradicionalmente requieren una preparación cuidadosa y pueden implicar reinicios de todo el fabric para versiones principales, impactando las ventanas de mantenimiento. Cisco está mejorando esto, pero la naturaleza fuertemente acoplada de APIC y el sistema operativo de red en los switches Nexus significa menos flexibilidad. El vendor lock-in es, posiblemente, el más alto con ACI, ya que es un ecosistema completo construido alrededor del hardware Cisco Nexus y el software APIC.

Las actualizaciones de NSX implican NSX Manager, NSX Edge y VIBs de host. Aunque generalmente son menos disruptivas que las actualizaciones de fabric de ACI, la aplicación de parches en un entorno NSX Federation a gran escala aún requiere una planificación cuidadosa. NSX está menos ligado a hardware específico que ACI, pero está profundamente integrado en el stack de virtualización de VMware. Los clientes con una gran inversión en vSphere encontrarán que NSX encaja naturalmente; aquellos con hypervisores diversos o activos bare-metal significativos podrían encontrar la integración más desafiante sin componentes específicos de NSX.

VXLAN EVPN ofrece la mayor flexibilidad. Las actualizaciones suelen ser por dispositivo, minimizando el impacto si un solo switch necesita un reinicio. La naturaleza basada en estándares significa que se puede mezclar y combinar hardware de diferentes proveedores (por ejemplo, Cisco Nexus 9000, Arista 7000, Juniper QFX) para diferentes partes del fabric, reduciendo el vendor lock-in. Sin embargo, asegurar la interoperabilidad y conjuntos de características consistentes entre proveedores mixtos añade complejidad de diseño y operativa. La automatización juega un papel crucial en la gestión consistente de estos diversos componentes.

Veredicto

Para entornos Greenfield, centrados en Cisco: Cisco ACI 6.x gana. Si está construyendo un nuevo data center desde cero, utiliza principalmente Cisco Nexus hoy en día y valora un enfoque declarativo y basado en políticas con un single pane of glass para red y seguridad, ACI ofrece capacidades potentes, especialmente con MSO para la consistencia multi-site. La inversión en el ecosistema Cisco es significativa pero ofrece una alta automatización para cargas de trabajo monolíticas y virtualizadas tradicionales.
Para estrategias multi-cloud con fuerte presencia VMware: VMware NSX 4.2 gana. Si su carga de trabajo principal está virtualizada en VMware vSphere y necesita una micro-segmentación ágil y granular y servicios L4-L7 directamente integrados con su hypervisor, NSX proporciona capacidades inigualables. Sus fortalezas se extienden al cloud-native con Antrea/NCP y NSX Advanced Load Balancer, ofreciendo un overlay unificado para la seguridad de VM y contenedores a través de hybrid clouds.
Para entornos híbridos, conscientes del costo o que buscan evitar el Vendor Lock-in: NX-OS VXLAN EVPN con BGP gana. Si necesita máxima flexibilidad, se siente cómodo con un control plane distribuido, ya tiene sólidas capacidades de NetDevOps y/o desea aprovechar múltiples proveedores de hardware de red, VXLAN EVPN es la opción pragmática. Proporciona la base para fabrics escalables y abiertos sin la sobrecarga de un controller propietario, permitiendo una automatización altamente personalizada y la integración con herramientas cloud-native de código abierto como Cilium. Esta es la elección para aquellos que valoran la libertad arquitectónica y pueden invertir en experiencia interna en automatización.