Quelle est la principale différence de Control Plane entre ACI, NSX et VXLAN EVPN ?

ACI utilise un contrôleur APIC centralisé et propriétaire pour programmer les commutateurs Cisco Nexus. NSX emploie un overlay logiciel distribué géré par les NSX Managers et les contrôleurs. VXLAN EVPN avec BGP utilise un protocole de routage BGP distribué et basé sur des standards pour l'échange d'informations de Control Plane directement entre les équipements réseau.

Quelle solution offre la meilleure micro-segmentation pour les machines virtuelles ?

Le Distributed Firewall (DFW) de VMware NSX est généralement considéré comme supérieur pour la micro-segmentation des VM. Il applique les politiques directement dans le kernel de l'hyperviseur, fournissant une sécurité fine, sensible à l'identité, jusqu'aux cartes réseau de VM individuelles, indépendamment de la topologie du réseau physique sous-jacent.

Le Vendor Lock-in est-il une préoccupation avec ces solutions ?

Oui, c'en est une. Cisco ACI a le plus haut niveau de Vendor Lock-in, car il nécessite du matériel Cisco Nexus spécifique et leur contrôleur APIC. VMware NSX vous lie à l'écosystème VMware. VXLAN EVPN avec BGP offre le moins de Vendor Lock-in, car il est basé sur des standards et compatible avec plusieurs fournisseurs de matériel réseau, bien que les outils d'automatisation puissent devenir spécifiques au fournisseur.

Quelle solution est la plus adaptée à un pourcentage élevé de serveurs bare-metal ?

Pour les environnements avec une forte densité de serveurs bare-metal, Cisco ACI et le VXLAN EVPN natif sous NX-OS sont généralement de meilleurs choix. ACI traite les serveurs bare-metal comme des citoyens de première classe au sein de son modèle EPG. VXLAN EVPN étend la couche 2 directement aux cartes réseau des serveurs bare-metal, les traitant comme des endpoints réguliers dans l'overlay. NSX, bien que capable, nécessite généralement plus d'efforts pour intégrer les workloads bare-metal de manière transparente par rapport à son intégration native de VM.

Ces solutions peuvent-elles s'intégrer aux environnements de Cloud Public ?

Oui. Le Multi-Site Orchestrator d'ACI étend la politique sur site et dans le Cloud Public (AWS, Azure, Google Cloud) via des contrôleurs de services cloud. NSX prend en charge les architectures hybrides cloud avec NSX Cloud, étendant le DFW et les politiques de mise en réseau aux VPC du Cloud Public. L'intégration de VXLAN EVPN avec le Cloud Public implique généralement l'utilisation d'VPN IPsec ou de Direct Connect / ExpressRoute avec routage pour former un réseau routé plus large, ou l'utilisation de constructions réseau natives du Cloud Public.

Quelle est la courbe d'apprentissage typique pour chaque solution pour un ingénieur réseau senior ?

ACI a une courbe d'apprentissage élevée en raison de son modèle centré sur les politiques et orienté objet, nécessitant un changement de paradigme par rapport à la configuration CLI traditionnelle. NSX a une courbe modérée à élevée, en particulier pour comprendre les composants distribués et le réseau overlay. VXLAN EVPN avec BGP, bien que basé sur des standards, nécessite toujours une solide compréhension des concepts BGP EVPN, du routage/switching et des chaînes d'outils d'automatisation, ce qui en fait une courbe modérée mais peut-être plus alignée avec l'expertise réseau traditionnelle.

Quelle option est la meilleure pour un centre de données de petite à moyenne taille (moins de 16 commutateurs Leaf) ?

Pour les déploiements plus petits, le TCO pour ACI et NSX peut être disproportionnellement élevé en raison des coûts des contrôleurs/licences. Une fabrique VXLAN EVPN sous NX-OS bien conçue offre souvent une solution plus rentable et opérationnellement plus simple pour les PME disposant de solides capacités d'ingénierie réseau. ACI ou NSX pourraient être justifiés si la micro-segmentation avancée et l'automatisation sont primordiales, même à des échelles plus petites.

Cisco ACI 6.x vs VMware NSX 4.2 vs VXLAN EVPN sous NX-OS : Les fabriques de centre de données en 2026

Choisir une fabrique de réseau de centre de données en 2026 implique bien plus que le simple acheminement de paquets. Il s'agit d'automatisation, de stratégie multi-cloud, de sécurité granulaire et de l'overhead opérationnel. Nous allons décortiquer les forces et les faiblesses de Cisco ACI 6.x, VMware NSX 4.2, et du VXLAN EVPN traditionnel sous NX-OS avec BGP comme Control Plane. Ce n'est pas un exercice théorique ; ce sont les systèmes qui sous-tendent des infrastructures de plusieurs millions de dollars.

Philosophie Architecturale et Control Planes

Cisco ACI (Application Centric Infrastructure) fonctionne sur un modèle déclaratif et axé sur les politiques, utilisant l'Application Policy Infrastructure Controller (APIC). L'APIC est effectivement le cerveau, traduisant les politiques d'application de haut niveau en configurations réseau concrètes sur les commutateurs Leaf et Spine de la série Nexus 9000. Ce contrôleur centralisé gère tout, des VXLAN tunnel endpoints aux Security Group Policies (EPGs et contrats). Le Control Plane est propriétaire, étroitement lié au cluster APIC. ACI 6.x continue d'affiner Multi-Site Orchestrator (MSO) pour les déploiements multi-fabriques et hybrid cloud, centralisant la distribution des politiques à travers des domaines APIC géographiquement dispersés.

VMware NSX-T (maintenant simplement NSX) adopte une approche SDN (Software-Defined Networking), en abstraant les services réseau et de sécurité du matériel sous-jacent. Son Control Plane est distribué entre les NSX Managers (pour la gestion centralisée) et un réseau de contrôleurs qui programment les vSwitches d'hyperviseur (par exemple, vSphere Distributed Switch, ou N-VDS/VDS avec des composants spécifiques à NSX) et les NSX Edges. Bien que NSX puisse s'intégrer aux fabriques de réseau physiques, sa force réside dans son intégration étroite avec l'écosystème VMware, étendant la micro-segmentation et les services L4-L7 directement au niveau de l'hyperviseur. NSX Federation permet la distribution de politiques sur plusieurs instances NSX Manager.

VXLAN EVPN sous NX-OS avec BGP est une approche ouverte et basée sur des standards. Il utilise BGP comme Control Plane pour la distribution de routes VXLAN EVPN, réalisant une fabrique de réseau distribuée sans contrôleur SDN propriétaire. Chaque BGP speaker (généralement des commutateurs Cisco Nexus série 9000, Arista série 7000 ou Juniper série QFX) agit comme un peer, échangeant des informations de joignabilité MAC et IP sur l'underlay. Cela élimine la problématique du 'single point of failure' souvent soulevée avec les contrôleurs centralisés, bien que cela déplace la complexité vers la gestion des configurations BGP sur de nombreux appareils. L'automatisation est généralement réalisée via Ansible, Python ou des orchestrateurs externes, et non un contrôleur intégré et spécifique au fournisseur.

Scalabilité et Opérations Multi-Site

Les fabriques ACI 6.x peuvent supporter des centaines de commutateurs Leaf et des dizaines de milliers d'endpoints. Multi-Pod étend un cluster APIC unique sur plusieurs sites physiques au sein d'une zone métropolitaine, tandis que Multi-Site Orchestrator (MSO) fédère plusieurs domaines APIC, permettant un déploiement de politiques cohérent et une mobilité des workloads à travers des centres de données géographiquement divers. Par exemple, une fabrique ACI à 8 Leaf utilisant des Nexus 93180YC-FX3 peut monter jusqu'à 128 Leaf avec des Nexus 9332C-FX2/9364C-FX2 comme Spine. Un seul déploiement MSO peut gérer jusqu'à 16 fabriques ACI.

Les déploiements NSX 4.2 peuvent supporter des centaines de NSX Edges et des dizaines de milliers de VM/workloads par instance NSX Manager. NSX Federation fournit une solution multi-site, permettant de définir les politiques une seule fois et de les appliquer de manière cohérente sur jusqu'à 3 Global Managers, chacun gérant plusieurs Local Managers. Cela prend en charge les architectures de centre de données active-active ou active-standby. Lorsqu'il est intégré à Tanzu Kubernetes Grid, NSX prend en charge des centaines de milliers de pods de conteneurs, avec le NSX Container Plugin (NCP) ou Antrea fournissant des services réseau.

La scalabilité de VXLAN EVPN dépend largement des capacités matérielles sous-jacentes et de la conception BGP. Les commutateurs modernes tels que le Nexus 93180YC-FX3 ou l'Arista 7050SX3-48YC12 peuvent gérer des centaines de milliers d'entrées MAC/route. Une fabrique VXLAN EVPN typique peut supporter des centaines de commutateurs Leaf avec une capacité Spine appropriée. Le multi-site est réalisé via DCI (Data Center Interconnect) en utilisant EVPN étendu sur MPLS ou IP, ou via des fabriques autonomes avec routage IP/VPN pour la connectivité L3. La nature distribuée permet un modèle 'scale-out' sans atteindre les limites strictes d'un contrôleur central.

Micro-segmentation et Sécurité

La micro-segmentation d'ACI est intrinsèque à son modèle de politique. Les Endpoint Groups (EPGs) sont des regroupements logiques d'endpoints (VMs, bare-metal, conteneurs) qui nécessitent des politiques réseau et de sécurité similaires. Les Contracts définissent la communication permise entre les EPGs, fonctionnant de la couche 2 à la couche 4. Ce modèle mett en œuvre efficacement une philosophie Zero Trust, avec une posture par défaut de refus pour le trafic entre les EPGs, sauf autorisation explicite par un Contract. ACI s'intègre également aux services d'appliances L4-L7 (firewalls comme FortiGate 1800F ou Palo Alto PA-5440) via des Service Graphs, automatisant l'insertion et l'aiguillonnement des politiques.

NSX offre des capacités Distributed Firewall (DFW) robustes, appliquées directement dans le kernel de l'hyperviseur. Cela permet une micro-segmentation extrêmement granulaire, jusqu'aux cartes réseau de VM individuelles, basée sur divers attributs tels que le nom de la VM, l'OS, les Security Tags, ou les groupes Active Directory. Les règles DFW de NSX peuvent s'appliquer au trafic L2-L7, prenant en charge la sécurité au niveau de l'application. Les NSX Gateway Firewalls (sur les NSX Edges) fournissent une sécurité périmétrique (trafic North-South), tandis que le DFW gère le trafic East-West. NSX prend également en charge des services de sécurité avancés comme IDS/IPS, sandbox et Network Introspection via l'insertion de services pour les partenaires.

VXLAN EVPN fournit nativement la segmentation réseau via les VNIs (VXLAN Network Identifiers), agissant effectivement comme des réseaux virtuels distincts. Les capacités de micro-segmentation sont généralement obtenues via des firewalls externes pour le trafic North-South et East-West, ou via le Policy-Based Routing (PBR) pour rediriger le trafic vers des appliances de sécurité. Bien que des commutateurs comme le Nexus 9000 prennent en charge les ACLs et une application rudimentaire des politiques, ils n'ont pas les capacités fines et sensibles à l'identité des Contracts d'ACI ou du DFW de NSX. Une micro-segmentation plus avancée dans EVPN repose souvent sur des firewalls basés sur l'hôte (par exemple, iptables Linux, Windows Firewall) ou des overlays SDN complémentaires comme Cilium pour les environnements 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

Intégration avec le Cloud-Native (Kubernetes) et les Services L4-L7

ACI propose le Plugin ACI CNI pour Kubernetes, étendant son modèle de politique aux environnements de conteneurs. Cela permet de traiter les Kubernetes Pods comme des EPGs ACI, en appliquant directement les politiques de la fabrique. Pour les services L4-L7, les Service Graphs d'ACI peuvent automatiser l'insertion et la configuration d'appliances physiques ou virtuelles, dirigeant le trafic via un FortiGate 1800F ou un Load Balancer comme un F5 Big-IP, basé sur les Contracts EPG. Cela fournit une orchestration centralisée des services réseau et de sécurité.

NSX dispose d'une forte intégration Kubernetes, notamment avec Antrea (CNI open source) et son propre Container Plugin (NCP). Antrea fournit des politiques réseau et de sécurité pour les Kubernetes Pods, utilisant le DFW de NSX pour la micro-segmentation et étendant la visibilité réseau. NSX Advanced Load Balancer (anciennement Avi Networks) s'intègre pleinement pour les services de Load Balancing L4-L7 et de WAF, avec un déploiement et une mise à l'échelle automatisés. NSX prend également en charge l'insertion de services pour diverses appliances de sécurité, ce qui en fait une plateforme complète pour les workloads cloud-native.

Pour VXLAN EVPN, l'intégration Kubernetes repose généralement sur des CNIs indépendants comme Calico ou Cilium. Cilium, en particulier, utilise eBPF pour une application de politique réseau et une observabilité haute performance, offrant une micro-segmentation native Kubernetes sans dépendance directe à la fabrique underlay. L'insertion de services L4-L7 implique généralement l'intégration de fournisseurs distincts (par exemple, NGINX, HAProxy, firewalls de fournisseurs) et la gestion de leur aiguillage de trafic via PBR sur les commutateurs Leaf, ou en s'appuyant sur les contrôleurs Ingress/Egress de Kubernetes. Cette approche est très flexible mais nécessite une orchestration plus manuelle qu'ACI ou NSX.

Coût Total de Possession (TCO) et Considérations Opérationnelles

Le TCO est un facteur de différenciation critique. ACI introduit un coût initial significatif pour les contrôleurs APIC (généralement des clusters de 3 ou 5 nœuds pour la redondance) et les commutateurs de la série Nexus 9000 avec des licences spécifiques (par exemple, Advantage/Premier). Bien que l'automatisation réduise les tâches opérationnelles, la courbe d'apprentissage du modèle de politique d'ACI peut être abrupte. Les contrats de maintenance pour APIC et les commutateurs Nexus sont importants. Les mises à niveau (par exemple, ACI 5.x vers 6.x) peuvent être complexes, nécessitant souvent une planification significative et potentiellement des fenêtres de maintenance sur l'ensemble de la fabrique.

NSX a également un coût de licence substantiel, souvent par socket de CPU ou par VM, ce qui peut s'accumuler rapidement dans les grands environnements. Les coûts matériels pour les NSX Edges sont distincts, bien qu'ils puissent fonctionner sur des serveurs standards. La complexité opérationnelle provient de la gestion de l'overlay étendu et potentiellement de l'intégration avec les underlays physiques existants. Les mises à niveau pour NSX Manager et les nœuds Edge peuvent être perturbatrices si elles ne sont pas planifiées avec soin. NSX Federation ajoute une autre couche de complexité de gestion et de coût. Cependant, les avantages opérationnels de la sécurité et de l'approvisionnement réseau automatisés sont élevés.

VXLAN EVPN sous NX-OS apparaît souvent comme l'option CAPEX la plus basse en termes de licence, s'appuyant sur les fonctionnalités standard du système d'exploitation réseau et BGP. Les coûts matériels pour les commutateurs Nexus 9000 sont comparables à ceux d'ACI, mais sans les clusters APIC obligatoires. L'OPEX pour EVPN, cependant, peut être plus élevé en raison de la nature distribuée du Control Plane et du besoin d'outils d'automatisation robustes (Ansible, Puppet, etc.) pour maintenir la cohérence sur de nombreux appareils. Le dépannage peut être plus difficile en raison de l'absence d'un moteur de corrélation centralisé comme APIC ou NSX Manager. Les mises à niveau sont généralement par commutateur, minimisant l'impact à l'échelle de la fabrique mais augmentant la gestion des appareils individuels.

**Matrice de comparaison des fabriques de centre de données (projections 2026)**
Caractéristique	Cisco ACI 6.x	VMware NSX 4.2	NX-OS VXLAN EVPN (BGP)
Control Plane	Centralisé (APIC), Propriétaire	Distribué (NSX Managers + Controllers), Overlay Propriétaire	Distribué (BGP EVPN), Basé sur des Standards
Micro-segmentation	EPGs & Contracts (L2-L4), Service Graphs	Distributed Firewall (DFW) (L2-L7), Sensible à l'Identité	VLAN/VNI, Firewalls Externes, ACLs, (Cilium pour K8s)
Intégration Kubernetes	ACI CNI (modèle EPG)	Antrea / NCP (politiques DFW)	Calico / Cilium (Indépendant)
Multi-Site	Multi-Pod, Multi-Site Orchestrator	NSX Federation	DCI avec EVPN/MPLS, IP VPN
Courbe d'apprentissage	Élevée (Modèle de politique)	Modérée-Élevée (Overlay, Services distribués)	Modérée (concepts BGP EVPN, Automatisation)
Vendor Lock-in	Élevé (Cisco Nexus)	Modéré (écosystème VMware)	Faible (support matériel multi-fournisseurs)
CAPEX estimé (fabrique à 8 Leaf)	350k $ - 600k $ (incl. APIC, Nexus 93180YC-FX3)	280k $ - 500k $ (incl. licences NSX, Edges)	180k $ - 300k $ (incl. Nexus 93180YC-FX3)
OPEX estimé (par an)	60k $ - 100k $ (maintenance, administrateur dédié)	50k $ - 90k $ (maintenance, administrateur dédié)	40k $ - 80k $ (maintenance, efforts d'automatisation)

Cycles de Mise à Jour et Vendor Lock-in

Les chemins de mise à niveau ACI (par exemple, d'ACI 5.2 à 6.0, puis aux versions intermédiaires 6.x) nécessitent traditionnellement une mise en scène minutieuse et peuvent impliquer des rechargements de la fabrique pour les versions majeures, impactant les fenêtres de maintenance. Cisco améliore cela, mais la nature étroitement couplée de l'APIC et du système d'exploitation réseau sur les commutateurs Nexus signifie moins de flexibilité. Le Vendor Lock-in est sans doute le plus élevé avec ACI, car il s'agit d'un écosystème complet construit autour du matériel Cisco Nexus et du logiciel APIC.

Les mises à niveau NSX impliquent NSX Manager, NSX Edge et les VIBs hôtes. Bien que généralement moins perturbatrices que les mises à niveau de fabrique ACI, les correctifs dans un environnement NSX Federation à grande échelle nécessitent toujours une planification minutieuse. NSX est moins lié à un matériel spécifique qu'ACI, mais il est profondément intégré à la pile de virtualisation VMware. Les clients fortement investis dans vSphere trouveront NSX un choix naturel ; ceux avec des hyperviseurs divers ou des actifs bare-metal significatifs pourraient trouver l'intégration plus difficile sans les composants spécifiques à NSX.

VXLAN EVPN offre la plus grande flexibilité. Les mises à niveau se font généralement par appareil, minimisant le rayon d'impact si un seul commutateur nécessite un rechargement. La nature basée sur les standards signifie que vous pouvez mélanger et assortir le matériel de différents fournisseurs (par exemple, Cisco Nexus 9000, Arista 7000, Juniper QFX) pour différentes parties de votre fabrique, réduisant ainsi le Vendor Lock-in. Cependant, assurer l'interopérabilité et la cohérence des fonctionnalités entre des fournisseurs mixtes ajoute de la complexité de conception et opérationnelle. L'automatisation joue un rôle crucial dans la gestion cohérente de ces divers composants.

Verdict

Pour les environnements Greenfield centrés sur Cisco : Cisco ACI 6.x l'emporte. Si vous construisez un nouveau centre de données à partir de zéro, utilisez principalement Cisco Nexus aujourd'hui, et valorisez une approche déclarative, axée sur les politiques, avec un point d'entrée unique pour le réseau et la sécurité, ACI offre des capacités puissantes, en particulier avec MSO pour la cohérence multi-site. L'investissement dans l'écosystème Cisco est significatif mais offre une automatisation élevée pour les workloads monolithiques et virtualisés traditionnels.
Pour les stratégies multi-cloud fortement axées sur VMware : VMware NSX 4.2 l'emporte. Si votre workload principal est virtualisé sur VMware vSphere, et que vous avez besoin d'une micro-segmentation agile et granulaire ainsi que de services L4-L7 directement intégrés à votre hyperviseur, NSX offre des capacités inégalées. Ses forces s'étendent au cloud-native avec Antrea/NCP et NSX Advanced Load Balancer, offrant un overlay unifié pour la sécurité des VM et des conteneurs à travers les hybrid clouds.
Pour les environnements hybrides, soucieux des coûts, ou souhaitant éviter le Vendor Lock-in : NX-OS VXLAN EVPN avec BGP l'emporte. Si vous avez besoin d'une flexibilité maximale, êtes à l'aise avec un Control Plane distribué, disposez déjà de solides capacités NetDevOps, et/ou souhaitez utiliser plusieurs fournisseurs de matériel réseau, VXLAN EVPN est le choix pragmatique. Il fournit la base pour des fabriques scalables et ouvertes sans le surcoût d'un contrôleur propriétaire, permettant une automatisation et une intégration hautement personnalisées avec des outils cloud-native open source comme Cilium. C'est le choix pour ceux qui valorisent la liberté architecturale et peuvent investir dans une expertise interne en automatisation.