Warum wird Multi-Site einem einzelnen, gestreckten VXLAN-Fabric vorgezogen?

Weil der BGW im Wesentlichen als 'Filter' für die Datenebene fungiert, lokale VNIs in entfernte VNIs übersetzt und die lokale Kapselung entfernt. Dies verhindert, dass eine Broadcast-Schleife oder ein Spanning Tree-Fehler an einem Standort die CP/DP des zweiten Standorts beeinträchtigt.

Kann ich ältere Switches der 9300-Serie (ohne EX/FX) als Border Gateways verwenden?

Cloud Scale ASICs wie FX2 oder GX sind erforderlich, da sie das für einen BGW benötigte VXLAN-zu-VXLAN 'Double Lookup' unterstützen. Ältere ASICs können die notwendige Kapselung und Entkapselung nicht in einem Durchlauf mit Line-Rate durchführen.

Ist vPC für die Hochverfügbarkeit von Border Gateways erforderlich?

Anycast BGW ist deutlich besser für die Skalierbarkeit. Es ermöglicht mehreren BGWs, eine virtuelle IP zu teilen, wodurch L3 ECMP für den Inter-Site-Verkehr ermöglicht wird und die proprietären Einschränkungen und Fehlerdomänenrisiken eines vPC Peer-Links vermieden werden.

Was sind die spezifischen Anforderungen an das Inter-Site Network (ISN)?

Das ISN muss lediglich IP-Erreichbarkeit bieten und eine MTU von mindestens 1550 Bytes unterstützen. Es muss nicht VXLAN- oder EVPN-aware sein; es routet lediglich die gekapselten Pakete zwischen BGW VTEPs.

Was bewirkt der Befehl 'rewrite-evpn-rt-asn' eigentlich?

Der Befehl 'rewrite-evpn-rt-asn' ermöglicht es einem BGW, EVPN-Routen mit seiner eigenen ASN neu zu initiieren, was für Multi-AS-Designs entscheidend ist, bei denen Route Targets zwischen unabhängigen BGP-Domänen korrekt zugeordnet werden müssen.

Sollte ich Ingress Replication oder Multicast für BUM-Traffic über Sites hinweg verwenden?

Für die meisten Unternehmen ist Ingress Replication (IR) die bevorzugte Methode. Sie vereinfacht die ISN-Konfiguration, indem der BGW BUM-Traffic als Unicast zu entfernten Sites repliziert, wodurch PIM oder ein RP im Core überflüssig werden.

Cisco Nexus 9000 VXLAN EVPN Multi-Site beherrschen: Design Guide 2026

Die Ära der "gestreckten" Layer 2 Domäne mittels OTV oder VPLS ist vorbei. Wer sich immer noch auf "back-to-back vPC" für Multi-Pod-Konnektivität verlässt, sitzt auf einer tickenden Zeitbombe. 2026 ist die einzige vertretbare Architektur zur Verbindung verteilter Hochleistungsrechenzentren das Nexus 9000 VXLAN EVPN Multi-Site-Modell, das Hardware-basierte Border Gateway (BGW)-Funktionen nutzt, um Fehlerdomänen zu lokalisieren und gleichzeitig eine nahtlose Workload-Mobilität zu gewährleisten.

Das Trugbild des gestreckten Fabric

Jahrelang jagten Netzwerkarchitekten dem "Heiligen Gral" eines einzigen, vereinheitlichten Fabric über mehrere physische Standorte hinweg hinterher. Dieser Ansatz vereinfachte zwar theoretisch vMotion und IP-Konsistenz, schuf aber eine fragile "Fate-Sharing"-Umgebung. Ein einzelner BUM (Broadcast, Unknown Unicast, Multicast)-Sturm in Site A konnte und tat es oft, Sites B und C gleichzeitig lahmlegen. Ciscos NX-OS-Implementierung von VXLAN EVPN Multi-Site löst dies durch die Entkopplung der internen Site-Protokolle vom "Inter-Site Network" (ISN).

In einem Standard Multi-Site-Design betreibt jede Site ihre eigene unabhängige BGP EVPN Control Plane. Die Border Gateways (BGWs) fungieren als Endpunkt für interne VXLAN-Tunnel und als Ursprungspunkt für Inter-Site-Tunnel. Im Gegensatz zur traditionellen Streckung schreibt der BGW den "Next-Hop" neu und modifiziert die "Route Targets", wodurch sichergestellt wird, dass das MAC/IP-Lernen isoliert bleibt. Tritt in Site A eine Schleife auf, fangen die Spanning Tree- oder "Storm Control"-Mechanismen innerhalb dieser Site sie ab, bevor sie sich über den "High-Latency"-ISN-Link ausbreitet.

Hardware-Auswahl: Cloud Scale oder nichts

Versuchen Sie nicht, Multi-Site auf Nexus 9300 der ersten Generation zu betreiben. Sie benötigen Cloud Scale ASICs (EX, FX, FX2, FX3 oder die neueren GX/GX2-Serien), um die erforderliche VXLAN-zu-VXLAN-Terminierung und die notwendigen TCAM-Einträge für L3VNI- und L2VNI-Mapping zu unterstützen. Speziell für die Border Gateway-Rolle sind der Nexus 9364C-GX oder der 9336C-FX2 unsere Goldstandards für 100G/400G-Dichte.

Die 9300-GX-Serie ist 2026 besonders kritisch, da wir uns auf 400G-Backbones zubewegen. Sie bieten die notwendigen tiefen Puffer, um Mikro-Bursts zu bewältigen, die beim Übergang von "High-Bandwidth"-internen Spines zu potenziell "Lower-Bandwidth"-ISN-Leitungen auftreten. Vermeiden Sie die 9200er-Serie für BGW-Rollen; die Feature-Parität ist für komplexe EVPN Multi-Site-Implementierungen einfach nicht gegeben.

Architektur des Border Gateway (BGW)

Das Border Gateway ist die kritischste Komponente in diesem Design. Es gibt zwei primäre Bereitstellungsmodelle: Distributed BGW (Spines als BGWs) oder Dedicated BGW (Leafs als BGWs). Bei TechLeague empfehlen wir für große Unternehmensumgebungen fast ausschließlich das Modell des Dedicated BGW (Border Leafs). Während die Verwendung von Spines als BGWs einige "RU" Rack-Platz spart, zwingt es Ihre Spines dazu, eine vollständige BGP-Routing-Tabelle für die Außenwelt zu führen, was den CPU-Druck erhöht und Ihre Managementgrenze verkompliziert.

Hochverfügbarkeit: Anycast BGW vs. vPC BGW

Alteingesessene Ingenieure versuchen immer noch, ihre BGWs in einem vPC-Paar zu betreiben. Das ist ein Fehler. VXLAN EVPN Multi-Site unterstützt das Modell des Anycast BGW (virtuelle IP). In diesem Setup teilen sich mehrere BGWs dieselbe "Anycast"-IP-Adresse für den VXLAN Tunnel Endpoint (VTEP). Die Verwendung von Anycast BGW ermöglicht bis zu 6- oder 8-Wege-ECMP-Pfade über das ISN, was eine wesentlich höhere Ausfallsicherheit und einen höheren Durchsatz bietet als ein Zwei-Knoten-vPC-Cluster.


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

Durch die Verwendung des "Anycast"-Modells entfällt die Notwendigkeit eines vPC Peer-Link zwischen Gateways, der traditionell einen Fehlerpunkt in konvergenzsensitiven Umgebungen darstellte. Fällt ein BGW aus, leitet die BGP-Konvergenz auf dem ISN den Datenverkehr einfach an die anderen "Anycast"-Mitglieder um, ohne dass eine komplexe LACP-Aushandlung erforderlich ist.

Das Inter-Site Network (ISN): Komplizieren Sie es nicht weiter

Das ISN ist oft der am meisten missverstandene Teil des Designs. Es muss kein EVPN sprechen. Tatsächlich sollte es das auch nicht. Das ISN ist lediglich ein Transportmedium, das IP-Erreichbarkeit zwischen BGW VTEPs bereitstellt. Es muss MTU 1550+ (um den 50-Byte VXLAN-Header aufzunehmen) unterstützen und ein IGP wie OSPF oder IS-IS ausführen.

Die BGWs etablieren Multi-Hop MP-BGP EVPN Peering miteinander über das ISN. Wir befürworten nachdrücklich die Verwendung von BGP Peer Groups, um diese Verbindungen zu verwalten, insbesondere wenn über drei Sites hinaus skaliert wird. Hier ist ein typischer BGW-Konfigurationsausschnitt für ISN-Peering:


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

Der Befehl rewrite-evpn-rt-asn ist entscheidend. Er ermöglicht es dem BGW, Route Targets zwischen Sites zu übersetzen, um sicherzustellen, dass Labels korrekt interpretiert werden, wenn der Datenverkehr durch das ISN fließt.

L3 Multicast und BUM Traffic Handling

BUM-Traffic über Sites hinweg zu handhaben, ohne das WAN zu überlasten, unterscheidet einen Junior-Administrator von einem Senior Engineer. Sie haben zwei Möglichkeiten: "Ingress Replication" (IR) oder "Local-Bias Multicast". Für Designs im Jahr 2026 ist Ingress Replication mit Multi-Site-Optimierungen der Standard, es sei denn, Sie haben sehr spezifische "High-Bandwidth Multicast"-Anforderungen. IR erstellt einzelne Unicast-Kopien von BUM-Paketen für jede entfernte Site, aber der BGW ist intelligent genug, um nur eine Kopie an die entfernte Site zu senden, die der entfernte BGW dann lokal an seine Leafs repliziert. Diese "Head-end Replication" reduziert die Bandbreitenbelastung auf Ihrem ISN erheblich.

Wenn Sie Multicast im Core verwenden müssen, stellen Sie sicher, dass Ihr ISN PIM-BSR oder PIM-RP unterstützt. Die Komplexität der Verwaltung eines RP über mehrere administrative Domänen überwiegt jedoch in der Regel die Effizienzgewinne für 90 % der Unternehmen.

Sicherheit und Richtlinien: Micro-segmentation mit Group-Based Policy (GBP)

Standard VXLAN EVPN überträgt nur die VNI und L2/L3-Informationen. Wenn Sie die Sicherheitslage über mehrere Sites hinweg aufrechterhalten möchten, müssen Sie VXLAN-GPO (Group-Based Policy) implementieren. Dies ermöglicht es Ihnen, SGTs (Scalable Group Tags) im VXLAN-Header zu transportieren. Wenn ein Benutzer in Site A (SGT 10) mit einem Server in Site B kommuniziert, bewahrt der BGW dieses Tag. Dadurch können Ihre Firewalls oder Nexus Leafs in Site B Richtlinien auf der Grundlage des SGT durchsetzen, anstatt einer IP-Adresse, die sich möglicherweise geändert hat.

Wie wir in unserem Leitfaden zu Nexus ACI vs. Standalone EVPN detailliert dargelegt haben, ist die manuelle Orchestrierung von SGTs in NX-OS der primäre "痛み"-Punkt, der Kunden oft in Richtung ACI treibt. Wenn Sie jedoch ein "CLI-first"-Unternehmen sind, bietet Ihnen die Beibehaltung von NX-OS Multi-Site eine bessere Transparenz der Control Plane und vermeidet die "Black Box"-Natur von APIC.

Verifizierung und operativer Alltag

Die Fehlerbehebung bei Multi-Site erfordert eine Beherrschung der show nve multisite Befehle. Sie überprüfen nicht nur die Adjazenz; Sie überprüfen, ob der BGW tatsächlich die korrekte Site-ID annonciert. Ein häufiger Fehlerpunkt sind nicht übereinstimmende Site-IDs innerhalb desselben Fabric, was dazu führt, dass der BGW das Inter-Site VIP beendet, um Loops zu verhindern.


# BGW-Status prüfen
show nve multisite border-gateway
# Erreichbarkeit der Remote Site prüfen
show bgp l2vpn evpn summary
# VNI-Mapping über Sites hinweg verifizieren
show nve vni

Erwarten Sie, dass die ISN-Latenz eine Rolle bei der BGP-Konvergenz spielt. Passen Sie Ihre keepalive- und holdtime-Timer an, gehen Sie aber nicht unter eine Sekunde, es sei denn, Sie verfügen über eine dedizierte Dark-Fiber-Verbindung. Bei einem Standard-10ms-20ms-WAN-Transit ist ein 3-Sekunden-Keepalive der "Sweet Spot", um "Flapping" bei geringfügigen Jitter-Ereignissen zu verhindern.

Fazit

Cisco Nexus 9000 VXLAN EVPN Multi-Site ist der einzige Weg, moderne Rechenzentren zu skalieren, ohne die Risiken einer riesigen, flachen Layer-2-Domäne zu erben. Durch die Verwendung von Anycast BGWs und Cloud Scale ASICs bauen Sie eine widerstandsfähige, "Multi-Homed"-Umgebung auf, die den Hochgeschwindigkeitsanforderungen von 2026 gerecht wird. Wenn Ihr aktuelles Design auf gestreckten vPCs oder komplexen OTV-Overlays basiert, ist es an der Zeit für eine Neuausrichtung. Um eine Expertenprüfung Ihres Fabric-Designs zu erhalten oder ein Tier-3-Engineering-Team für Ihre Implementierung hinzuzuziehen, besuchen Sie unsere techleague.io Preisübersicht, um zu erfahren, wie wir Ihre Infrastrukturmodernisierung beschleunigen können.