Was ist die reale Latenzgrenze für ein ACI Multi-Pod IPN?

Cisco unterstützt offiziell bis zu 50ms RTT für das IPN. Bei Designs, die Layer 2 Bridge Domains strecken, sollte jedoch eine praktische Grenze von 10ms durchgesetzt werden. Eine Latenz über diesem Wert erhöht das Risiko von Anwendungsproblemen für den Datenverkehr innerhalb der gestreckten Broadcast-Domäne drastisch.

Sitzt der Nexus Dashboard Orchestrator (NDO) im Datenpfad?

Nein. NDO ist eine reine Out-of-Band Orchestrierungs- und Policy-Management-Plattform. Es konfiguriert die APIC-Cluster in jeder Site, aber der gesamte Datenverkehr fließt direkt zwischen den Spine Switches der jeweiligen Sites über das Inter-Site Network (ISN). Ein NDO-Ausfall hat keine Auswirkungen auf den bestehenden Datenverkehr.

Kann ich Multi-Pod und Multi-Site gleichzeitig betreiben?

Ja, dies ist eine unterstützte, wenn auch komplexe Topologie. Eine Multi-Pod Fabric kann so konfiguriert werden, dass sie als einzelne 'Site' innerhalb einer größeren ACI Multi-Site Architektur fungiert. Dies wird typischerweise verwendet, um das Management von zwei nahegelegenen Pods zu konsolidieren, bevor sie als eine einzige logische Entität mit einem entfernten DR-Standort verbunden werden.

Wie unterscheiden sich die Lizenzen zwischen Multi-Pod und Multi-Site?

Multi-Pod erfordert nur die Standard-ACI Premier oder Advantage Lizenzen für die Leaf Switches; es gibt keine zusätzliche Lizenz für Multi-Pod selbst. Multi-Site erfordert ACI-Lizenzen für die Leafs jeder Site PLUS Nexus Dashboard Lizenzen und eine spezifische NDO-Anwendungslizenz (z.B. N-D-ADV-S-GF), die gestaffelt ist basierend auf der Anzahl der verwalteten Sites und/oder Leaf Switches.

Was passiert mit dem Inter-Site-Verkehr, wenn NDO ausfällt?

Der bestehende Datenverkehr ist davon völlig unberührt. Die BGP EVPN Sessions zwischen den Sites bleiben aktiv und die über das Overlay gelernten Endpunkte werden beibehalten. Die einzige Auswirkung eines NDO-Ausfalls ist die Unfähigkeit, administrative Änderungen an Inter-Site-Policies vorzunehmen, bis der NDO-Cluster wiederhergestellt ist.

Ist PIM-Bidir eine zwingende Anforderung für das Multi-Pod IPN?

Es ist das von Cisco validierte und empfohlene Design für die effiziente Handhabung von BUM-Verkehr. Technisch können Sie es auch mit anderen Multicast-Modi wie PIM Sparse-Mode zum Laufen bringen, aber dies verkompliziert das Design mit Rendezvous Point Platzierung und potenziellen Traffic Trombones. Für jede Greenfield-Implementierung sollte PIM-Bidir als feste Anforderung betrachtet werden.

Kann ich Dark Fiber für das Multi-Pod IPN verwenden?

Absolut. Dark Fiber ist ein idealer Transport für ein IPN, insbesondere für Metro-Gebiets-Verbindungen. Sie würden an jedem Ende der Faser ein Paar Router oder Layer 3 Switches (wie Catalyst 9500s) platzieren, um als IPN-Geräte zu dienen, und dann das erforderliche OSPF/PIM/BGP Peering über diese Verbindung aufbauen.

Cisco ACI Multi-Pod vs. Multi-Site: Architekturentscheidungen 2026

Die Wahl zwischen Cisco ACI Multi-Pod und Multi-Site ist eine entscheidende architektonische Weichenstellung mit weitreichenden Konsequenzen. Allzu oft wird diese Entscheidung als einfache Frage von Latenz oder Skalierung betrachtet. Tatsächlich hängt die korrekte Wahl für 2026 von einer nüchternen Bewertung von Ausfallbereichen, betrieblicher Komplexität und den Gesamtbetriebskosten ab. Multi-Pod bietet eine verlockende Einfachheit auf Kosten einer monolithischen Ausfalldomäne, während Multi-Site eine echte Fehlertrennung ermöglicht, aber ein höheres Maß an technischem Können und ein deutlich größeres Budget erfordert. Eine falsche Wahl führt nicht nur zu technischer Schuld, sondern zu karriereentscheidenden Ausfällen.

Kernarchitektur: Pods und Sites

Bevor die Multi-Fabric-Erweiterungen verglichen werden, ist ein präzises Verständnis der Basiskomponenten unerlässlich. Das gesamte ACI-Portfolio basiert auf einer Spine-Leaf Clos-Topologie, aber die Art und Weise, wie diese Topologien verwaltet und miteinander verbunden sind, bestimmt die Architektur.

Die einzelne ACI Fabric: Eine Baseline Ausfalldomäne

Eine Standard-ACI Fabric besteht aus einem Cluster von mindestens drei Application Policy Infrastructure Controllern (APICs), einer Reihe von Spine Switches (z.B. Nexus 9508 mit Gen3 -FX3 Line Cards) und einer Reihe von Leaf Switches (z.B. Nexus 93180YC-FX3). Dieses gesamte Konstrukt bildet eine einzige administrative und Control Plane Domäne. Ein grundlegendes ACI-Prinzip besagt, dass alle Endpunkte innerhalb der Fabric aus Policy- und Erreichbarkeitssicht nur einen Hop voneinander entfernt sind, was durch das VXLAN Overlay ermöglicht wird. Entscheidend ist, dass diese einzelne Fabric eine einzige Ausfalldomäne darstellt. Ein katastrophaler Bug in der APIC-Software (ab ACI Version 6.0+) oder ein Control Plane Ausfall des Council of Oracle Protocol (COOP) kann und wird die gesamte Fabric beeinträchtigen.

ACI Multi-Pod: Die gestreckte einzelne Fabric

ACI Multi-Pod kann als eine Standard-ACI Fabric verstanden werden, die über mehrere physische Standorte oder „Pods“ „gestreckt“ wird. Jeder Pod ist seine eigene Spine-Leaf-Topologie. Alle Pods werden jedoch von einem *einzigen* APIC Cluster verwaltet, der sich in einem der Pods befindet. Die Pods sind über ein IP-basiertes Inter-Pod Network (IPN) miteinander verbunden. Aus Managementsicht ist es eine Fabric. Alle Konfigurationsobjekte – Tenants, EPGs, Bridge Domains (BDs) – werden über alle Pods hinweg synchronisiert. Dies bedeutet, dass Sie eine Single Pane of Glass für das Management haben, aber es bedeutet auch eine einzige, geografisch verteilte Ausfalldomäne. Ein Fehler im APIC Cluster kann die gesamte Multi-Pod Infrastruktur instabil machen.

ACI Multi-Site: Eine Föderation unabhängiger Fabrics

ACI Multi-Site stellt ein fundamental anderes Paradigma dar. Jede „Site“ ist eine vollständige, unabhängige ACI Fabric mit einem eigenen dedizierten APIC Cluster. Diese Sites sind vollständig autonom; ein Fehler in Site1 hat keine operativen Auswirkungen auf Site2. Die Sites sind über ein Standard IP/MPLS- oder VXLAN EVPN-Netzwerk miteinander verbunden. Die Besonderheit liegt im Nexus Dashboard Orchestrator (NDO), früher Multi-Site Orchestrator (MSO). Auf einem separaten Nexus Dashboard Cluster ausgeführt, fungiert NDO (Version 4.2+) als Föderations- und Policy Orchestrierungs-Engine. Ein Administrator definiert Templates und Policies in NDO, die dann die entsprechenden Konfigurationen an den lokalen APIC Cluster jeder Site pushen. Es verwaltet die Fabrics nicht in Echtzeit; es ist eine Orchestrierungsschicht, keine Control Plane Komponente.

Die Interconnect: IPN vs. ISN Detail

Das Netzwerk, das Ihre Pods oder Sites verbindet, ist kein triviales Implementierungsdetail; es ist eine Kernkomponente der Architektur mit spezifischen, starren Anforderungen.

Multi-Pod IPN Design Anforderungen

Das IPN ist ein Layer 3 Netzwerk, das die Spine Switches jedes Pods verbindet. Die Spines bauen OSPF Adjacencies zu den IPN Devices und BGP EVPN Sessions zu Spines in anderen Pods auf. Wichtige Anforderungen sind:

Hohe MTU: Das IPN muss eine MTU von mindestens 9150 Bytes unterstützen, um den VXLAN-gekapselten Datenverkehr (50 Bytes Overhead) ohne Fragmentierung zu ermöglichen. Nicht verhandelbar. Der Einsatz von Geräten wie dem Catalyst 9500-48UXM für das IPN erfordert eine sorgfältige End-to-End MTU Validierung.
Multicast: PIM-Bidir ist das erforderliche Routing-Protokoll, um Broadcast, Unknown Unicast und Multicast (BUM) Traffic effizient zu handhaben, der zwischen Pods geflutet werden muss. Obwohl andere PIM-Modi funktionieren können, ist Bidir das Standarddesign.
DHCP Relay: Der APIC verwendet DHCP, um TEP-Adressen an Nodes zuzuweisen, einschließlich Spines in entfernten Pods. Das IPN muss mit DHCP Relay Agents konfiguriert werden, die auf das im APIC definierte TEP Pool Subnetz zeigen.
Latenz: Die offiziell unterstützte Round-Trip Time (RTT) beträgt 50ms. Jedes Design, das L2 Bridge Domains über ein IPN mit einer Latenz von mehr als 10ms streckt, birgt jedoch große Risiken. Hohe Latenz verstärkt die Auswirkungen von Broadcast Storms und kann zu einer erheblichen Leistungsverschlechterung für Anwendungen wie vMotion führen. Für L3-only geroutete Konnektivität zwischen Pods sind 50ms realistischer.

Multi-Site Inter-Site Network (ISN)

Das ISN für Multi-Site ist in seinen ACI-spezifischen Anforderungen einfacher, setzt aber ein anspruchsvolleres zugrunde liegendes Netzwerk voraus. Das ISN ist typischerweise ein vom Carrier bereitgestelltes MPLS L3VPN oder, zunehmend, ein selbstverwaltetes Dark Fiber Netzwerk, das VXLAN BGP EVPN betreibt. Die Data Plane Verbindung erfolgt von Spine zu Spine, wobei BGP EVPN Sessions genutzt werden, um Endpunkt-Erreichbarkeitsinformationen zwischen Sites auszutauschen. NDO orchestriert den Aufbau dieser BGP Sessions, aber der zugrunde liegende Netzwerktransport ist unabhängig von ACI. Dies ist ein entscheidender Unterschied: Multi-Site schreibt nicht vor, *wie* Ihre Sites verbunden sind, sondern nur, dass sie gerouteten Traffic mit entsprechender MTU austauschen *können*.

Ausfalldomänen und Blast Radius

Dies ist die wichtigste Überlegung. Eine größere Ausfalldomäne vereinfacht das Management, erhöht aber das Risiko. Multi-Pod und Multi-Site liegen an entgegengesetzten Enden dieses Spektrums.

Bei Multi-Pod ist ein ACI-Bug, ein fehlerhafter Konfigurations-Push oder ein APIC Control-Plane-Ausfall ein globales Ereignis. Eine über die APIC GUI oder API vorgenommene Änderung wird gleichzeitig an alle Pods propagiert. Stellen Sie sich ein Szenario vor, in dem ein Bug in COOP zu einem Fabric-weiten Endpunkt-Lernproblem führt. In einem Multi-Pod-Design würde dieses Problem sofort alle Ihre Rechenzentren umfassen. Ihr Disaster Recovery Site wäre vom gleichen Fehler betroffen wie Ihr primärer Standort, was ihn unbrauchbar macht. Dies ist ein inakzeptables Risiko für die meisten Enterprise-Grade Deployments, die auf echte Business Continuity abzielen.

Multi-Site hingegen bietet eine robuste Fehlerisolierung. Jede Site ist eine eigenständige ACI Fabric. Der Nexus Dashboard Orchestrator ist eine Out-of-Band Orchestrierungsplattform. Wenn der NDO Cluster ausfällt, können keine Inter-Site Policy *Änderungen* mehr vorgenommen werden, aber die vorhandene Data Plane und die Control Planes jeder Site funktionieren weiterhin perfekt. Der Datenverkehr zwischen den Sites ist davon unberührt. Ein Fehler in der ACI-Version, die in Site1 läuft, wird nicht auf Site2 übertragen. Dies ermöglicht gestaffelte, kontrollierte Upgrades (z.B. Upgrade von Site2 auf ACI 6.1, Validierung, dann Upgrade von Site1 Wochen später), ein kritisches operatives Sicherheitsnetz, das Multi-Pod nicht bietet.

Dimensionierungsbeispiel: Inter-Site Bandbreite und NDO Ressourcen

Modellieren wir ein typisches Zwei-Sites-Szenario: zwei Rechenzentren 80 km voneinander entfernt, die aktive/aktive Anwendungskluster und Datenbankreplikation unterstützen müssen.

Sites: 2
Gesamt-Leafs: 300 (150 pro Site)
Tenants: 50
EPGs: 3.000
Spitzen-Inter-Site-Replikationsverkehr: 150 Gbit/s

Multi-Pod Dimensionierungsansatz

Für Multi-Pod ist das IPN das Hauptanliegen. Sie benötigen IPN-Geräte, die 150 Gbit/s Line-Rate, Large-Packet Traffic weiterleiten können. Ein Paar Juniper SRX5800s oder Cisco Catalyst 9606R Chassis mit ausreichender 100G Portdichte wäre erforderlich. Das größere Problem ist der L2 BUM-Verkehr. Wenn Sie 500 VLANs (als BDs) zwischen Pods strecken und jedes im Durchschnitt nur 10 Mbit/s BUM-Verkehr erzeugt, sind das 5 Gbit/s konstanter Multicast-Verkehr, der IPN-Bandbreite und CPU auf den IPN-Routern verbraucht. Diese Berechnung wird häufig übersehen. (Anzahl gestreckter BDs) * (Durchschnittlicher BUM-Verkehr pro BD) = Konstanter IPN-Load. Dieser Load ist immer vorhanden und muss in Ihre Bandbreitenplanung einbezogen werden.

Multi-Site Dimensionierungsansatz

Für Multi-Site provisionieren Sie einen 200Gbps (150 Gbps + 33% Headroom) L3VPN/EVPN Wave Dienst von einem Carrier. Der Fokus verschiebt sich auf die Dimensionierung des Nexus Dashboard Clusters. Basierend auf dem Cisco NDO 4.2 Sizing Guide erfordert die Verwaltung von 2 Sites, 3000 EPGs und 50 Tenants einen 3-Node NDO Cluster, wobei jeder Node eine virtuelle Maschine mit ca. 16 vCPUs, 64 GB RAM und 1 TB Festplattenspeicher ist. Dies ist ein nicht trivialer Virtualisierungs-Footprint. Die Kosten liegen nicht in der Datenpfad-Bandbreitenberechnung (welche einfache Carrier-Circuit-Kosten sind), sondern in den Compute- und Software-Lizenzkosten für NDO und den redundanten APIC-Cluster in der zweiten Site.

Häufiger Fallstrick: L2 über DCI strecken

Die gefährlichste Funktion, die sowohl Multi-Pod als auch Multi-Site bieten, ist die Möglichkeit, eine Layer 2 Bridge Domain über geografisch getrennte Standorte zu strecken. Obwohl technisch möglich, ist dies fast immer ein architektonischer Fehler. Das Strecken von L2 schafft eine einzige Broadcast Domäne, was bedeutet, dass ein Broadcast Storm an einem Standort die DCI/IPN-Links überfluten und den anderen Standort (Fate-Sharing) beeinträchtigen wird. Es erschwert die Fehlerbehebung und dient oft als Krücke, um die Modernisierung von Legacy-Anwendungen mit hartkodierten IP-Adressen zu vermeiden. Während Multi-Site eleganter ist, wie es den L2-Verkehr mit VXLAN tunnelt, bleibt das grundlegende Problem bestehen. Die Best Practice im Jahr 2026 besteht darin, L2-Domänen lokal auf eine einzige Site zu beschränken und für den gesamten Verkehr L3-only geroutete Konnektivität zwischen den Sites zu verwenden. Nicht strecken.

Wann ACI Multi-Site NICHT eingesetzt werden sollte

Trotz ihrer technischen Überlegenheit bei der Fehlerisolierung ist Multi-Site keine Universallösung. Es gibt spezifische Szenarien, in denen Multi-Pod die pragmatischere Wahl ist.

Erstens sind es die Kosten. Eine Multi-Site-Bereitstellung erfordert einen vollständigen APIC-Cluster (mindestens 3 Nodes) für *jede Site*, plus einen Nexus Dashboard Cluster (physisch oder virtuell) sowie NDO-Softwarelizenzen (z.B. N-D-ADV-S-GF). Dies kann die Controller- und Softwarekosten im Vergleich zu einem Multi-Pod-Design, das einen einzigen APIC-Cluster verwendet, leicht verdoppeln. Wenn Ihre beiden „Sites“ lediglich zwei Etagen im selben Gebäude sind, sind die Kosten für Multi-Site nicht zu rechtfertigen.

Zweitens Skalierung und Latenz. Für eine kleine Implementierung (z.B. <80 Leaf Switches insgesamt) an zwei Metro-Standorten mit Dark Fiber und <5ms RTT bietet Multi-Pod eine einheitliche Management Plane, die einfacher zu betreiben ist als NDO. Das Risiko einer einzelnen Ausfalldomäne kann ein kalkuliertes, akzeptables Trade-off für operative Einfachheit sein, wenn die physische Nähe und geringe Latenz das Potenzial für netzwerkbedingte Probleme begrenzen.

Betrachten Sie schließlich die Fähigkeiten Ihres Teams. Multi-Pod ist eine direkte Erweiterung des Wissens über Single-Fabric ACI. Multi-Site, mit NDO, Schema Templates und der Notwendigkeit, ein zugrunde liegendes BGP EVPN Inter-Site Netzwerk zu verwalten, stellt einen erheblichen Schritt in der Komplexität dar. Wenn Ihr Team für diesen operativen Sprung nicht bereit ist, kann die Implementierung von Multi-Site mehr Risiken durch Fehlkonfigurationen einführen, als sie durch Fehlerisolierung löst.

Letztendlich beruht die Entscheidung auf einer klaren Risikobewertung. Multi-Pod priorisiert vereinfachte Operationen innerhalb einer einzigen, gestreckten Ausfalldomäne, wodurch es sich für Metro-Gebiets-Implementierungen eignet, bei denen Kosten und Einfachheit von größter Bedeutung sind und das Risiko als akzeptabel angesehen wird. Multi-Site priorisiert Fehlerisolierung und Skalierbarkeit über alles andere, wodurch es die erforderliche Wahl für große, geografisch verteilte Netzwerke ist, bei denen Business Continuity nicht verhandelbar ist. Wählen Sie die Architektur, die Ihrer operativen Realität und Ihrem Budget entspricht, nicht nur die, die technisch möglich ist.

Bei TechLeague können unsere zertifizierten Experten Ihnen helfen, die TCO und die operativen Auswirkungen beider Architekturen für Ihre spezifische Umgebung zu modellieren. Kontaktieren Sie uns, um ein Gespräch zu beginnen. Lesen Sie unsere verwandten Beiträge zu VXLAN EVPN Design und dem Nexus Dashboard-Ökosystem, um mehr zu erfahren.