Was ist der primäre Unterschied in der Control Plane zwischen ACI, NSX und VXLAN EVPN?

ACI verwendet einen zentralisierten, proprietären APIC-Controller zur Programmierung von Cisco Nexus Switches. NSX verwendet ein verteiltes Software-Overlay, das von NSX Managern und Controllern verwaltet wird. VXLAN EVPN mit BGP nutzt ein verteiltes, standardbasiertes BGP-Routing-Protokoll für den Austausch von Control Plane-Informationen direkt zwischen Netzwerkgeräten.

Welche Lösung bietet die beste Mikrosegmentierung für virtuelle Maschinen?

VMware NSX's Distributed Firewall (DFW) wird allgemein als überlegen für die VM-Mikrosegmentierung angesehen. Sie erzwingt Policies direkt im Hypervisor-Kernel und bietet eine feingranulare, identitätsbasierte Sicherheit bis hin zu einzelnen VM-NICs, unabhängig von der zugrunde liegenden physischen Netzwerktopologie.

Ist Vendor Lock-in ein Problem bei diesen Lösungen?

Ja, das ist es. Cisco ACI hat den höchsten Vendor Lock-in, da es spezifische Cisco Nexus Hardware und ihren APIC-Controller erfordert. VMware NSX bindet Sie an das VMware-Ökosystem. VXLAN EVPN mit BGP bietet den geringsten Vendor Lock-in, da es standardbasiert und mit mehreren Netzwerk-Hardware-Anbietern kompatibel ist, obwohl Automatisierungstools anbieterspezifisch werden könnten.

Welche Lösung ist besser geeignet für einen hohen Anteil an Bare-Metal-Servern?

Für Umgebungen mit einer hohen Dichte an Bare-Metal-Servern sind Cisco ACI und natives NX-OS VXLAN EVPN im Allgemeinen bessere Optionen. ACI behandelt Bare-Metal-Server als First-Class Citizens innerhalb seines EPG-Modells. VXLAN EVPN erweitert Layer 2 direkt auf Bare-Metal-Server-NICs und behandelt sie als reguläre Endpunkte im Overlay. NSX, obwohl fähig, erfordert typischerweise mehr Aufwand, um Bare-Metal-Workloads nahtlos zu integrieren, im Vergleich zu seiner nativen VM-Integration.

Können diese Lösungen mit Public Cloud-Umgebungen integriert werden?

Ja. ACI's Multi-Site Orchestrator erweitert Policies über On-Premises- und Public Cloud-Umgebungen (AWS, Azure, Google Cloud) über Cloud Services Controller. NSX unterstützt Hybrid Cloud-Architekturen mit NSX Cloud, die DFW- und Netzwerkpolicies in Public Cloud VPCs erweitern. Die VXLAN EVPN-Integration mit Public Cloud beinhaltet typischerweise die Nutzung von IPsec VPN oder Direct Connect / ExpressRoute mit Routing, um ein größeres geroutetes Netzwerk zu bilden, oder die Verwendung nativer Public Cloud-Netzwerkkonstrukte.

Wie hoch ist die typische Lernkurve für jede Lösung für einen Senior Network Engineer?

ACI hat eine hohe Lernkurve aufgrund seines Policy-zentrischen und objektorientierten Modells, das einen Wechsel im Denken von der traditionellen CLI-Konfiguration erfordert. NSX hat eine mittlere bis hohe Kurve, insbesondere beim Verständnis der verteilten Komponenten und des Overlay-Netzwerks. VXLAN EVPN mit BGP erfordert, obwohl standardbasiert, immer noch ein fundiertes Verständnis von BGP EVPN-Konzepten, Routing/Switching und Automatisierungs-Toolchains, was es zu einer mittleren Kurve macht, aber möglicherweise besser zu traditionellem Netzwerk-Know-how passt.

Welche Option ist am besten für ein kleines bis mittleres Rechenzentrum (unter 16 Leaf-Switches)?

Für kleinere Deployments können die TCO für ACI und NSX aufgrund von Controller-/Lizenzkosten unverhältnismäßig hoch sein. Ein gut konzipierter NX-OS VXLAN EVPN Fabric bietet oft eine kostengünstigere und operativ einfachere Lösung für SMB mit starken Netzwerktechnik-Fähigkeiten. ACI oder NSX könnten gerechtfertigt sein, wenn erweiterte Mikrosegmentierung und Automatisierung auch in kleineren Maßstäben von größter Bedeutung sind.

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

Die Auswahl einer Rechenzentrumsnetzwerk-Fabric im Jahr 2026 umfasst mehr als nur das Weiterleiten von Paketen. Es geht um Automatisierung, Multi-Cloud-Strategie, granulare Sicherheit und operativen Aufwand. Wir analysieren die Stärken und Schwächen von Cisco ACI 6.x, VMware NSX 4.2 und traditionellem NX-OS VXLAN EVPN mit BGP als Control Plane. Dies ist keine theoretische Übung; dies sind die Systeme, die Infrastrukturen im Wert von vielen Millionen Dollar zugrunde liegen.

Architektur-Philosophien & Control Planes

Cisco ACI (Application Centric Infrastructure) arbeitet nach einem deklarativen, Policy-gesteuerten Modell unter Verwendung des Application Policy Infrastructure Controller (APIC). APIC ist effektiv das Gehirn, das High-Level-Anwendungspolicies in konkrete Netzwerkkonfigurationen auf Nexus 9000-Series Leaf- und Spine-Switches übersetzt. Dieser zentralisierte Controller verwaltet alles von VXLAN Tunnel Endpoints bis hin zu Security Group Policies (EPGs und Contracts). Die Control Plane ist proprietär und eng mit dem APIC-Cluster gekoppelt. ACI 6.x verfeinert weiterhin den Multi-Site Orchestrator (MSO) für Multi-Fabric- und Hybrid-Cloud-Deployments, indem er die Policy-Verteilung über geografisch verteilte APIC-Domänen zentralisiert.

VMware NSX-T (jetzt nur noch NSX) verfolgt einen Software-Defined Networking (SDN)-Ansatz, der Netzwerk- und Sicherheitsdienste von der zugrunde liegenden Hardware abstrahiert. Seine Control Plane ist über NSX Manager (für zentralisiertes Management) und ein Netzwerk von Controllern verteilt, die Hypervisor vSwitches (z. B. vSphere Distributed Switch oder N-VDS/VDS mit NSX-spezifischen Komponenten) und NSX Edges programmieren. Während NSX in physische Netzwerk-Fabrics integriert werden kann, liegt seine Stärke in der engen Integration mit dem VMware-Ökosystem, wodurch Mikrosegmentierung und L4-L7-Services direkt in die Hypervisor-Ebene erweitert werden. NSX Federation ermöglicht die Policy-Verteilung über mehrere NSX Manager-Instanzen.

NX-OS VXLAN EVPN mit BGP ist ein offener, standardbasierter Ansatz. Es nutzt BGP als Control Plane für die VXLAN EVPN Routenverteilung und erreicht so eine verteilte Netzwerk-Fabric ohne proprietären SDN-Controller. Jeder BGP-Sprecher (typischerweise Cisco Nexus 9000 Series, Arista 7000 Series oder Juniper QFX Series Switches) fungiert als Peer und tauscht MAC- und IP-Reachability-Informationen über den Underlay aus. Dies eliminiert die "Single Point of Failure"-Bedenken, die oft bei zentralisierten Controllern aufkommen, verlagert jedoch die Komplexität auf die Verwaltung von BGP-Konfigurationen über viele Geräte. Automatisierung wird typischerweise über Ansible, Python oder externe Orchestratoren erreicht, nicht über einen integrierten, anbieterspezifischen Controller.

Skalierbarkeit und Multi-Site-Operationen

ACI 6.x Fabrics skalieren auf Hunderte von Leaf-Switches und Zehntausende von Endpunkten. Multi-Pod erweitert einen einzelnen APIC-Cluster über mehrere physische Standorte innerhalb eines Großstadtgebiets, während Multi-Site Orchestrator (MSO) mehrere APIC-Domänen föderiert, was eine konsistente Policy-Bereitstellung und Workload-Mobilität über geografisch verteilte Rechenzentren ermöglicht. Zum Beispiel kann ein 8-Leaf ACI Fabric mit Nexus 93180YC-FX3 auf bis zu 128 Leaves mit Nexus 9332C-FX2/9364C-FX2 als Spines skaliert werden. Eine einzelne MSO-Bereitstellung kann bis zu 16 ACI Fabrics verwalten.

NSX 4.2-Deployments skalieren auf Hunderte von NSX Edges und unterstützen Zehntausende von VMs/Workloads pro NSX Manager-Instanz. NSX Federation bietet eine Multi-Site-Lösung, die es ermöglicht, Policies einmal zu definieren und konsistent über bis zu 3 Global Manager, die jeweils mehrere Local Manager verwalten, durchzusetzen. Dies unterstützt Active-Active- oder Active-Standby-Rechenzentrumsarchitekturen. Bei Integration mit Tanzu Kubernetes Grid skaliert NSX auf Hunderttausende von Container-Pods, wobei das NSX Container Plugin (NCP) oder Antrea Netzwerkdienste bereitstellen.

Die Skalierbarkeit von VXLAN EVPN hängt weitgehend von den zugrunde liegenden Hardware-Fähigkeiten und dem BGP-Design ab. Moderne Switches wie der Nexus 93180YC-FX3 oder Arista 7050SX3-48YC12 können Hunderttausende von MAC/Route-Einträgen verarbeiten. Eine typische VXLAN EVPN Fabric kann mit entsprechender Spine-Kapazität auf Hunderte von Leaf-Switches skaliert werden. Multi-Site wird durch DCI (Data Center Interconnect) unter Verwendung von EVPN über MPLS oder IP erreicht, oder durch eigenständige Fabrics mit IP/VPN-Routing für L3-Konnektivität. Der verteilte Charakter ermöglicht ein 'Scale-Out'-Modell, ohne auf die harten Grenzen eines zentralen Controllers zu stoßen.

Mikrosegmentierung und Sicherheit

Die Mikrosegmentierung von ACI ist intrinsisch in seinem Policy-Modell verankert. Endpoint Groups (EPGs) sind logische Gruppierungen von Endpunkten (VMs, Bare-Metal, Container), die ähnliche Netzwerk- und Sicherheitspolicies benötigen. Contracts definieren die zulässige Kommunikation zwischen EPGs, die auf Layer 2 bis Layer 4 operieren. Dieses Modell implementiert effektiv eine Zero Trust-Philosophie, mit einer standardmäßigen Deny-Haltung für den Datenverkehr zwischen EPGs, es sei denn, dies ist explizit durch einen Contract erlaubt. ACI integriert auch L4-L7 Service Appliances (Firewalls wie FortiGate 1800F oder Palo Alto PA-5440) über Service Graphs, die die Konfigurationsbereitstellung und Policy-Steuerung automatisieren.

NSX bietet robuste verteilte Firewall (DFW)-Funktionen, die direkt im Hypervisor-Kernel durchgesetzt werden. Dies ermöglicht eine extrem granulare Mikrosegmentierung bis hin zu einzelnen VM-NICs, basierend auf verschiedenen Attributen wie VM-Namen, OS, Security Tags oder Active Directory-Gruppen. NSX DFW-Regeln können auf L2-L7-Traffic angewendet werden und unterstützen die anwendungsbezogene Sicherheit. NSX Gateway Firewalls (auf NSX Edges) bieten Perimeter-Sicherheit (Nord-Süd-Datenverkehr), während die DFW den Ost-West-Traffic verarbeitet. NSX unterstützt auch fortschrittliche Sicherheitsdienste wie IDS/IPS, Sandbox und Netzwerkinspektion über Service Insertion für Partner.

VXLAN EVPN bietet nativ Netzwerksegmentierung durch VNIs (VXLAN Network Identifiers), die effektiv als separate virtuelle Netzwerke fungieren. Mikrosegmentierungsfunktionen werden typischerweise durch externe Firewalls für Nord-Süd- und Ost-West-Traffic oder durch Policy-Based Routing (PBR) erreicht, um den Traffic zu Sicherheits-Appliances umzuleiten. Während Switches wie der Nexus 9000 ACLs und rudimentäre Policy-Durchsetzung unterstützen, fehlen ihnen die feinkörnigen, identitätsbasierten Funktionen von ACI's Contracts oder NSX's DFW. Fortgeschrittenere Mikrosegmentierung in EVPN basiert oft auf Host-basierten Firewalls (z.B. Linux iptables, Windows Firewall) oder komplementären SDN-Overlays wie Cilium für Kubernetes-Umgebungen.


! 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

Integration mit Cloud-Native (Kubernetes) & L4-L7-Services

ACI bietet das ACI CNI Plugin für Kubernetes, das sein Policy-Modell in Container-Umgebungen erweitert. Dies ermöglicht es, Kubernetes Pods als ACI EPGs zu behandeln und Fabric-Policies direkt anzuwenden. Für L4-L7-Services können ACI's Service Graphs die Konfigurationsbereitstellung und Konfiguration von physischen oder virtuellen Appliances automatisieren und den Datenverkehr über eine FortiGate 1800F oder einen Load Balancer wie einen F5 Big-IP basierend auf EPG Contracts leiten. Dies bietet eine zentralisierte Orchestrierung von Netzwerk- und Sicherheitsdiensten.

NSX verfügt über eine starke Kubernetes-Integration, insbesondere mit Antrea (Open-Source-CNI) und seinem eigenen Container Plugin (NCP). Antrea bietet Netzwerk- und Sicherheitspolicies für Kubernetes-Pods, wobei die NSX DFW für Mikrosegmentierung genutzt und die Netzwerk-Visibilität erweitert wird. NSX Advanced Load Balancer (ehemals Avi Networks) integriert sich vollständig für L4-L7 Load Balancing- und WAF-Services mit automatisierter Bereitstellung und Skalierung. NSX unterstützt auch die Service Insertion für verschiedene Sicherheits-Appliances, wodurch es eine umfassende Plattform für Cloud-Native-Workloads ist.

Für VXLAN EVPN basiert die Kubernetes-Integration typischerweise auf unabhängigen CNIs wie Calico oder Cilium. Insbesondere Cilium nutzt eBPF für eine hochleistungsfähige Durchsetzung von Netzwerkpolicies und Observability, was Kubernetes-native Mikrosegmentierung ohne direkte Abhängigkeit vom Underlay Fabric bietet. Die Bereitstellung von L4-L7-Services beinhaltet normalerweise die Integration separater Anbieter (z.B. NGINX, HAProxy, Anbieter-Firewalls) und die Verwaltung ihrer Traffic-Steuerung über PBR auf Leaf-Switches oder die Nutzung von Kubernetes Ingress/Egress Controllern. Dieser Ansatz ist sehr flexibel, erfordert jedoch mehr manuelle Orchestrierung als ACI oder NSX.

Total Cost of Ownership (TCO) & Operative Überlegungen

Die TCO ist ein entscheidendes Unterscheidungsmerkmal. ACI verursacht erhebliche Vorabkosten für APIC-Controller (typischerweise 3 oder 5 Knoten-Cluster zur Redundanz) und Nexus 9000-Series Switches mit spezifischen Lizenzen (z. B. Advantage/Premier). Während die Automatisierung operative Aufgaben reduziert, kann die Einarbeitung in das Policy-Modell von ACI steil sein. Wartungsverträge für APIC und Nexus-Switches sind beträchtlich. Upgrades (z. B. ACI 5.x auf 6.x) können komplex sein und erfordern oft eine erhebliche Planung und möglicherweise Wartungsfenster über die gesamte Fabric hinweg.

NSX hat ebenfalls erhebliche Lizenzkosten, oft pro CPU-Sockel oder pro VM, die in großen Umgebungen schnell ansteigen können. Die Hardwarekosten für NSX Edges sind separat, obwohl sie auf Commodity-Servern laufen können. Die operative Komplexität ergibt sich aus der Verwaltung des gestreckten Overlays und der potenziellen Integration in bestehende physische Underlays. Upgrades für NSX Manager und Edge-Knoten können störend sein, wenn sie nicht sorgfältig geplant werden. NSX Federation fügt eine weitere Ebene der Management-Komplexität und Kosten hinzu. Die operativen Vorteile der automatisierten Sicherheit und Netzwerkbereitstellung sind jedoch hoch.

NX-OS VXLAN EVPN erscheint oft als die kostengünstigste Option in Bezug auf Lizenzierung, da es auf standardmäßigen Netzwerk-OS-Funktionen und BGP basiert. Die Hardwarekosten für Nexus 9000-Switches sind mit denen von ACI vergleichbar, jedoch ohne obligatorische APIC-Cluster. Die OPEX für EVPN kann jedoch aufgrund der verteilten Art der Control Plane und der Notwendigkeit robuster Automatisierungstools (Ansible, Puppet usw.) zur Aufrechterhaltung der Konsistenz über viele Geräte hinweg höher sein. Die Fehlerbehebung kann aufgrund des Fehlens eines zentralisierten Korrelations-Tools wie APIC oder NSX Manager schwieriger sein. Upgrades erfolgen typischerweise pro Switch, was den Fabric-weiten Impact minimiert, aber das Management einzelner Geräte erhöht.

**Vergleichsmatrix für Rechenzentrums-Fabrics (2026-Prognosen)**
Merkmal	Cisco ACI 6.x	VMware NSX 4.2	NX-OS VXLAN EVPN (BGP)
Control Plane	Zentralisiert (APIC), Proprietär	Verteilt (NSX Manager + Controller), Proprietäres Overlay	Verteilt (BGP EVPN), Standardbasiert
Mikrosegmentierung	EPGs & Contracts (L2-L4), Service Graphs	Distributed Firewall (DFW) (L2-L7), Identitäts-aware	VLAN/VNI, Externe Firewalls, ACLs, (Cilium für K8s)
Kubernetes-Integration	ACI CNI (EPG-Modell)	Antrea / NCP (DFW-Policies)	Calico / Cilium (Unabhängig)
Multi-Site	Multi-Pod, Multi-Site Orchestrator	NSX Federation	DCI mit EVPN/MPLS, IP VPN
Lernkurve	Hoch (Policy-Modell)	Mittel-Hoch (Overlay, Verteilte Dienste)	Mittel (BGP EVPN-Konzepte, Automatisierung)
Vendor Lock-in	Hoch (Cisco Nexus)	Mittel (VMware-Ökosystem)	Niedrig (Multi-Vendor-Hardware-Unterstützung)
Geschätzte Capex (8-Leaf-Fabric)	$350k - $600k (inkl. APIC, Nexus 93180YC-FX3)	$280k - $500k (inkl. NSX-Lizenzen, Edges)	$180k - $300k (inkl. Nexus 93180YC-FX3)
Geschätzte Opex (pro Jahr)	$60k - $100k (Wartung, dedizierter Admin)	$50k - $90k (Wartung, dedizierter Admin)	$40k - $80k (Wartung, Automatisierungsaufwand)

Upgrade-Zyklen und Vendor Lock-in

ACI-Upgrade-Pfade (z. B. von ACI 5.2 auf 6.0 und dann auf 6.x Zwischen-Releases) erfordern traditionell eine sorgfältige Inszenierung und können für größere Versionen Fabric-weite Neustarts beinhalten, was Wartungsfenster beeinflusst. Cisco verbessert dies, aber die enge Kopplung von APIC und dem Netzwerk-OS auf Nexus-Switches bedeutet weniger Flexibilität. Der Vendor Lock-in ist bei ACI wohl am höchsten, da es sich um ein komplettes Ökosystem handelt, das um Cisco Nexus Hardware und APIC Software aufgebaut ist.

NSX-Upgrades umfassen NSX Manager, NSX Edge und Host-VIBs. Obwohl sie im Allgemeinen weniger störend sind als ACI Fabric-Upgrades, erfordert das Patchen in einer großskaligen NSX Federation-Umgebung immer noch eine sorgfältige Planung. NSX ist weniger an spezifische Hardware gebunden als ACI, aber es ist tief in den VMware-Virtualisierungsstack integriert. Kunden, die stark in vSphere investiert haben, werden NSX als natürliche Ergänzung empfinden; solche mit verschiedenen Hypervisoren oder erheblichen Bare-Metal-Assets könnten die Integration ohne NSX-spezifische Komponenten als anspruchsvoller empfinden.

VXLAN EVPN bietet die größte Flexibilität. Upgrades erfolgen typischerweise pro Gerät, wodurch der Blast Radius minimiert wird, falls ein einzelner Switch neu gestartet werden muss. Der standardbasierte Charakter bedeutet, dass Sie Hardware verschiedener Hersteller (z. B. Cisco Nexus 9000, Arista 7000, Juniper QFX) für verschiedene Teile Ihrer Fabric mischen können, um den Vendor Lock-in zu reduzieren. Die Sicherstellung der Interoperabilität und konsistenter Funktionssätze über verschiedene Anbieter hinweg erhöht jedoch die Design- und Betriebskomplexität. Automatisierung spielt eine entscheidende Rolle bei der konsistenten Verwaltung dieser unterschiedlichen Komponenten.

Fazit

Für Greenfield, Cisco-zentrierte Umgebungen: Cisco ACI 6.x gewinnt. Wenn Sie ein neues Rechenzentrum von Grund auf neu aufbauen, heute primär Cisco Nexus betreiben und einen deklarativen, Policy-gesteuerten Ansatz mit einem Single Pane of Glass für Netzwerk und Sicherheit schätzen, bietet ACI leistungsstarke Funktionen, insbesondere mit MSO für Multi-Site-Konsistenz. Die Investition in das Cisco-Ökosystem ist erheblich, liefert aber eine hohe Automatisierung für traditionelle monolithische und virtualisierte Workloads.
Für VMware-intensive, Multi-Cloud-Strategien: VMware NSX 4.2 gewinnt. Wenn Ihre primäre Workload auf VMware vSphere virtualisiert ist und Sie agile, granulare Mikrosegmentierung sowie L4-L7-Services direkt in Ihren Hypervisor integriert benötigen, bietet NSX unübertroffene Möglichkeiten. Seine Stärken erstrecken sich auf Cloud-Native mit Antrea/NCP und NSX Advanced Load Balancer, die ein einheitliches Overlay für VM- und Containersicherheit über Hybrid Clouds hinweg bieten.
Für Hybrid-Umgebungen, kostenbewusste oder Vendor-Lock-in-Vermeidung: NX-OS VXLAN EVPN mit BGP gewinnt. Wenn Sie maximale Flexibilität benötigen, mit einer verteilten Control Plane vertraut sind, bereits über starke NetDevOps-Fähigkeiten verfügen und/oder mehrere Netzwerk-Hardware-Anbieter nutzen möchten, ist VXLAN EVPN die pragmatische Wahl. Es bietet die Grundlage für skalierbare, offene Fabrics ohne den Overhead eines proprietären Controllers und ermöglicht eine hochgradig angepasste Automatisierung und Integration mit Open-Source-Cloud-Native-Tools wie Cilium. Dies ist die Wahl für diejenigen, die architektonische Freiheit schätzen und in internes Automatisierungs-Know-how investieren können.