Cisco

    Cisco SD-WAN Multi-Region Fabric: Ein resilientes Design für 2026

    TechLeague Editorial··11 Min. Lesezeit

    Das Deployment von Cisco Catalyst SD-WAN jenseits weniger hundert Standorte ohne eine Multi-Region Fabric (MRF)-Architektur ist ein Rezept für den Kollaps der Control Plane. Während eine Single-Region Fabric einfacher erscheint, führt ihr Full-Mesh-Charakter zu einer geometrischen Explosion von BFD-Sessions und OMP-Updates, die kein vSmart oder Edge Router im Enterprise-Massstab aufrechterhalten kann. MRF, früher bekannt als Hierarchical SD-WAN, ist kein optionales Add-on; es ist das zwingende Design-Paradigma für jedes Netzwerk, das 1.000 Standorte überschreitet oder mehrere Kontinente umspannt. Ein erfolgreiches MRF-Deployment hängt jedoch vollständig von einer perfekt architektonisch gestalteten Region 0 und korrekt dimensionierten Transport Gateways ab. Wer dies falsch macht, baut einen verteilten Engpass anstelle einer skalierbaren Fabric.

    Verständnis der Multi-Region Fabric Control Plane

    Ein Standard-Deployment von Catalyst SD-WAN in einer einzelnen Region ist eine flache Control Plane. Jeder Edge Router (cEdge/vEdge) etabliert OMP-Adjacencies mit jedem anderen Edge Router, um TLOCs (Transport Locators) und Service Routes zu lernen, sowie mit jedem vSmart Controller. BFD-Sessions verifizieren die Pfadverfügbarkeit zwischen allen TLOCs. Bei 100 Standorten ist dies handhabbar. Bei 2.000 Standorten, jeder mit zwei Transportwegen, müsste ein einzelner Router Tausende von BFD- und OMP-Sessions aufrechterhalten. Dies beansprucht erhebliche CPU und Speicher, nicht nur auf den Edge Routern, sondern kritisch auch auf den vSmart Controllern, die als zentrale Route Reflectors fungieren. Ein einzelnes vSmart-Paar, selbst auf robuster Hardware, stösst bei etwa 2.500 OMP-Peering-Sessions an praktische Grenzen.

    MRF löst dies durch die Einführung einer hierarchischen Control Plane. Die Fabric wird in eine Core-Region (Region 0) und mehrere Access-Regionen (Regionen 1-N) unterteilt.

    • Access-Regionen: Diese enthalten die eigentlichen Benutzerstandorte — Filialen, Campussen und Rechenzentrums-Anwendungsumgebungen. Router innerhalb einer Access-Region arbeiten in einem Full Mesh untereinander.
    • Region 0: Diese spezielle Region enthält keine Benutzerstandorte. Ihr einziger Zweck ist es, die Access-Regionen miteinander zu verbinden. Sie enthält hochleistungsfähige Border Router, die als Transport Gateways fungieren.

    Die Magie liegt in der Abstraktion der Control Plane. Ein Edge Router in Region 1 (z.B. London) peert nicht mit einem Edge Router in Region 2 (z.B. Tokyo). Stattdessen lernt der Londoner Router einen zusammengefassten Pfad zur Tokioter Region über seinen lokalen Border Router. Die vSmarts erzwingen diese Segmentierung und reduzieren die Anzahl der OMP- und BFD-Sessions, die jedes Gerät aufrechterhalten muss, drastisch. Dies ist nicht nur ein Vorschlag; für globale Netzwerke, die unter Catalyst SD-WAN 20.9 oder neuer laufen, ist es die einzige stabile Architektur.

    Kernarchitektur: Region 0, Border Router und Transport Gateways

    Die Terminologie hier ist präzise. Ein Router, der einen Exit Point für eine Region bereitstellt, ist ein Border Router. Wenn diese Border Router zur Verbindung von Regionen verwendet werden, fungieren sie als Transport Gateways. In einem MRF-Design werden diese Begriffe oft synonym für dasselbe Gerät verwendet.

    Design des Cores: Region 0

    Region 0 ist das Herzstück der Fabric; ihr Design bestimmt die Stabilität, Latenz und den Durchsatz der gesamten Inter-Region-Kommunikation. Es ist eine reine Transitregion. Unter keinen Umständen sollten Service-Side VPNs für Benutzerfilialen oder Rechenzentren direkt in Region 0 terminieren. Ihre einzigen Mitglieder sind die Transport Gateways selbst. Für maximale Stabilität sollten Transport Gateways der Region 0 in mindestens zwei, bevorzugt drei oder mehr, geografisch verteilten, Carrier-Neutral-Einrichtungen mit Hochgeschwindigkeitsanbindung bereitgestellt werden. Für ein globales Netzwerk sind dies beispielsweise Equinix-Standorte in Ashburn, London und Singapur. Der Transport, der diese Core-Standorte verbindet, sollte nicht das öffentliche Internet sein; es muss ein privates, Hochleistungs-Backbone sein (z.B. 100Gbps DWDM, dediziertes Carrier Ethernet oder ein Premium MPLS-Dienst).

    Hardwareauswahl: Keine Kompromisse

    Für die kritische Rolle der Transport Gateways in Region 0 und hochdichten Access-Regionen ist die Hardware-Auswahl von grösster Bedeutung. Versuchen Sie nicht, Entry-Level Branch Router zu verwenden. Die erforderliche IPsec-Krypto-Performance und Session-Skalierbarkeit erfordern High-End-Plattformen. Das Arbeitspferd für diese Rolle ist die Catalyst 8500 Serie, insbesondere der C8500-12X, der bis zu 197 Gbit/s IPsec-Durchsatz bietet. Für virtuelle Deployments in einer Private Cloud oder Colocation ist eine Catalyst 8000V (Cat8kV)-Instanz, die mit ausreichenden CPU-Kernen (z.B. 16+ vCPUs auf einem UCS C220 M7) und SR-IOV für NIC-Performance provisioniert ist, eine valable Alternative. Für Access Region Border Router in kleineren Regionen kann ein Paar Catalyst 8300 ausreichen, aber die Performance muss sorgfältig gegen die aggregierten Durchsatzanforderungen validiert werden.

    Dimensionierung von Transport Gateways und Control Plane Komponenten

    Die Unterdimensionierung von Transport Gateways ist der häufigste und kostspieligste Fehler im MRF-Design. Die Berechnung erfordert eine ehrliche Einschätzung der Inter-Region-Verkehrsflüsse und ein Verständnis des IPsec-Overheads.

    Ein reales Dimensionierungsbeispiel

    Modellieren wir ein Transport Gateway für eine europäische Access-Region (Region 1) mit 600 Branch-Standorten, das mit einer amerikanischen Region (Region 2) kommunizieren muss.

    1. Aggregierter Branch-Durchsatz: Angenommen, jede der 600 Filialen verfügt über eine 100-Mbit/s-DIA-Leitung mit einer durchschnittlichen Spitzenlast von 40 %, also 40 Mbit/s pro Standort. Der theoretische aggregierte Ausgangsdurchsatz beträgt 600 * 40 Mbit/s = 24 Gbit/s.
    2. Schätzung des Inter-Region-Verkehrs: Nicht der gesamte Verkehr wird die Region verlassen. Basierend auf der Anwendungsanalyse, sagen wir 30 % des Verkehrs sind für die AMER-Region bestimmt. Dies bedeutet, dass das Transport Gateway 24 Gbit/s * 0.30 = 7.2 Gbit/s Stateful Traffic verarbeiten muss.
    3. Berechnung des Krypto-Overheads: IPsec (ESP im Tunnelmodus mit AES-256-GCM) fügt Kapselungsoverhead hinzu. Eine konservative Schätzung ist ein 25%iger Performance-Impact auf den Rohdurchsatz. Die erforderliche Kryptoleistung beträgt also 7.2 Gbit/s * 1.25 = 9.0 Gbit/s.
    4. Berücksichtigung von Failover: Sie werden mindestens zwei Transport Gateways für Redundanz bereitstellen (z.B. eines in London, eines in Frankfurt). Jedes Gateway muss so dimensioniert sein, dass es die gesamte 9.0 Gbit/s-Last bewältigen kann, wenn das andere ausfällt. Eine Dimensionierung auf jeweils 4.5 Gbit/s (50/50 Last) würde bei einem Ausfall eine massive Performancedegradation garantieren.
    5. Plattformauswahl: Ein einzelner Catalyst 8300 (C8300-2N2S-4T2X) erreicht unter idealen Bedingungen etwa 10-15 Gbit/s aggregierten IPsec-Durchsatz. 9 Gbit/s bei einem Failover zu stemmen, ist riskant und lässt keinen Raum für Wachstum. Die richtige Wahl hier ist ein Paar Catalyst 8500-12X Switches oder leistungsstarke Cat8kV-Instanzen. Während ein Konkurrent wie ein PA-5440 von Palo Alto Networks ~40 Gbit/s IPsec-Durchsatz bieten könnte, vereinfacht der Verbleib im Catalyst-Ökosystem das Management unter vManage.

    TLOC Design und Path Control

    Die Eleganz von MRF liegt in der Verwendung von TLOCs. Ein Border Router in einer Access-Region erfüllt eine entscheidende Funktion: TLOC Extension. Er erweitert seine eigenen TLOCs auf die Edge Router innerhalb seiner Region. Wenn ein Branch cEdge in Frankfurt Traffic an ein Branch cEdge in Dallas senden muss, sieht es die TLOCs des Dallas cEdge nicht direkt. Es sieht den TLOC seines lokalen Transport Gateways (z.B. in London), das einen Pfad zur AMER-Region hat.

    Der Control Plane Flow ist wie folgt:

    • Der Dallas cEdge advertised seine lokalen TLOCs und service-seitigen Präfixe an seinen lokalen (AMER) Border Router via OMP.
    • Der AMER Border Router advertised diese Präfixe an die Region 0 vSmarts, aber entscheidend ist, dass er sie mit seinem eigenen TLOC als Next Hop advertised.
    • Die Region 0 vSmarts leiten diese Zusammenfassung an den EMEA Border Router weiter.
    • Der EMEA Border Router leitet die Erreichbarkeitsinformationen an den Frankfurt cEdge weiter.

    Das Ergebnis: Der Frankfurt cEdge leitet Inter-Region-Traffic einfach an den TLOC des Londoner Transport Gateways weiter. Die komplexe Interkontinentalpfadfindung wird durch die strukturierte Hierarchie gehandhabt, nicht durch einzelne Branch Router. Dies ermöglicht eine leistungsstarke Policy-Anwendung. Sie können zentralisierte Control Policies in vManage erstellen, die zum Beispiel festlegen, dass der gesamte Traffic von Region 1 nach Region 2 mit einer bestimmten DSCP-Markierung den MPLS-Transport durch Region 0 nutzen muss, während der gesamte andere Traffic den Internet-Transport nutzen kann.

    Häufige Falle: Creating Backdoor Inter-Region Links

    Ein fataler Designfehler ist die Einrichtung von Out-of-Band-Konnektivität zwischen Access-Regionen, die Region 0 umgeht. Zum Beispiel könnte ein Ingenieur zwei Rechenzentren, eines in Access-Region 1 und eines in Access-Region 2, direkt mit einer dedizierten Layer 3-Verbindung für eine bestimmte Anwendung verbinden und dann Routen in OMP redistribuieren. Dies erzeugt einen «Backdoor»-Pfad.

    Dies untergräbt die MRF-Architektur vollständig. Es führt das Risiko von asymmetrischem Routing ein, bei dem der Verkehr von Region 1 nach 2 den Backdoor-Link nimmt, der Rückverkehr von 2 nach 1 jedoch versucht, den offiziellen Region 0-Pfad zu verwenden. Dies richtet Chaos bei Stateful Services wie Firewalls an. Es verletzt die Hierarchie der Control Plane, was die Fehlerbehebung mit den Tools von vManage nahezu unmöglich macht, da der tatsächliche Verkehrspfad nicht dem logisch konfigurierten entspricht. Der gesamte Inter-Region-Verkehr muss die Transport Gateways über Region 0 passieren. Es gibt keine Ausnahmen.

    Wann NOT to Use Multi-Region Fabric

    MRF fügt eine Schicht von Design- und Betriebskomplexität hinzu. Es ist nicht immer die richtige Antwort. Eine gut skalierte einzelne Region ist einem schlecht implementierten Multi-Region-Design vorzuziehen.

    Sie sollten MRF nicht verwenden, wenn:

    • Ihr Netzwerk weniger als 500 Standorte hat. Der Overhead der Control Plane ist auf moderner Hardware handhabbar. Ein Paar vSmarts (virtuell oder physisch) kann die OMP-Last bewältigen, und Edge Router wie der Catalyst 8200 oder 8300 können die BFD-Sessions für ein Netzwerk dieser Grösse verwalten.
    • Ihr Netzwerk geografisch begrenzt ist. Wenn sich alle Ihre Standorte auf einem einzigen Kontinent befinden (z.B. Nordamerika), sind die Latenzvorteile der Regionalisierung minimal. Eine einzelne Region mit Controllern, die in geografisch zentralen Rechenzentren platziert sind (z.B. Chicago und Dallas), ist effizienter.
    • Ihnen das Core-Netzwerk-Backbone für eine zuverlässige Region 0 fehlt. Wenn Sie keinen dedizierten, Hochgeschwindigkeits-, Low-Latency-Transport zwischen Ihren Core-Region 0-Standorten bereitstellen können, wird MRF keine gute Performance liefern. Der Versuch, Region 0 über das öffentliche Internet aufzubauen, führt zu zu viel Unvorhersehbarkeit und vereitelt den Zweck, einen stabilen Core zu schaffen.

    Der Hauptauslöser für MRF ist die Skalierung über die OMP/BFD-Grenzen einer einzelnen Control Plane Domain hinaus, typischerweise jenseits der 1.000-1.500 Standorte, oder die Notwendigkeit, eine strikte Segmentierung und optimiertes Routing über ein globales, multikontinentales Deployment zu erzwingen.

    Die Beherrschung der Multi-Region Fabric ist unerlässlich, um ein resilientes, weltweites Catalyst SD-WAN aufzubauen. Ihre hierarchische Natur ist der einzige Weg, die inhärenten Skalierungsbeschränkungen flacher Netzwerkdesigns zu überwinden. Indem Sie sich auf eine robuste, private Region 0 konzentrieren, Transport Gateways korrekt für Failover dimensionieren und die Integrität der Hierarchie der Control Plane bewahren, können Sie eine Fabric aufbauen, die stabile, Policy-gesteuerte Konnektivität für Tausende von Standorten bietet. Für Expertenratschläge zur Planung, Implementierung und Verwaltung Ihres grossflächigen SD-WAN-Deployments, erkunden Sie Beratungsdienstleistungen unter techleague.io. Um Ihr Fachwissen weiter zu vertiefen, lesen Sie unsere Analysen zur Plattformauswahl von Catalyst 8000 vs. ISR 4000 und die Schnittmenge von SASE mit Fabric-Design in unserem ZTNA vs. VPN Integrationshandbuch.

    Häufige Fragen

    Kann ich das öffentliche Internet für die Transportkonnektivität von Region 0 verwenden?+

    Es ist technisch möglich, Tunnel über das Internet zu betreiben, aber es ist ein grundlegend fehlerhaftes Design. Region 0 ist Ihr Core-Backbone; seine Stabilität bestimmt die Performance der gesamten Fabric. Die Verwendung des unberechenbaren öffentlichen Internets führt zu variabler Latenz und Jitter, was die Zuverlässigkeit untergräbt, die MRF bieten soll. Verwenden Sie immer dedizierten privaten Transport wie DWDM, Carrier Ethernet oder Premium MPLS für Region 0.

    Wie viele Access-Regionen sollte ich erstellen?+

    Beginnen Sie mit kontinentalen Grenzen: AMER, EMEA und APJC sind häufige Ausgangspunkte. Eine gute Faustregel ist, die Regionsgrössen zwischen 500-1000 Standorten zu halten, um gut innerhalb der Control Plane-Grenzen der Border Router zu bleiben. Vermeiden Sie die Erstellung Dutzender kleiner, granularer Regionen, da dies die Managementkomplexität erhöht, ohne signifikante Skalierungsvorteile zu bieten.

    Benötige ich separate vSmart Controller Cluster für jede Region?+

    Nein, dies ist ein häufiges Missverständnis. Ein einziger, zentralisierter Cluster von vSmart Controllern verwaltet die gesamte Multi-Region Fabric. Sie weisen Router und ihre Standorte während der Konfiguration bestimmten Regionsnummern zu, und der einzelne vSmart Cluster erzwingt die hierarchischen Control Plane-Grenzen basierend auf diesen Zuweisungen.

    Welche Catalyst SD-WAN Softwareversion wird für MRF benötigt?+

    Das Feature, ursprünglich Hierarchical SD-WAN genannt, ist seit Viptela OS 18.x verfügbar. In der modernen Cisco Catalyst SD-WAN Software (z.B. Version 20.9 und neuer) ist es ein stabiles und ausgereiftes Feature. Für jedes Produktions-MRF-Deployment ist es entscheidend, eine langlebige, stabile von Cisco empfohlene Release zu verwenden, wie z.B. die kommende 20.13 oder ein zukünftiges Äquivalent.

    Kann ein einzelner Branch-Standort zu mehr als einer Access-Region gehören?+

    Nein, ein Edge Router (cEdge/vEdge) ist über seine Systemkonfiguration explizit einer einzelnen Access-Region zugewiesen. Alle seine OMP-Sessions zum Lernen von TLOCs und Routen werden innerhalb der Grenzen dieser einzelnen Region aufgebaut, entweder zu anderen Edges oder zu den designierten Border Routern der Region.

    Wie funktionieren Routing Policies und QoS mit MRF?+

    Policies und QoS werden hierarchisch angewendet. Sie können spezifische Data Policies, Control Policies oder Application-Aware Routing Policies anwenden, die nur den Traffic innerhalb einer Access-Region betreffen. Separat können Sie Policies an den Transport Gateways anwenden, um den Traffic durch Region 0 zu steuern. Dies ermöglicht eine granulare Kontrolle innerhalb einer Region und eine übergeordnete Kontrolle über den Inter-Region Backbone Traffic.

    Ist Multi-Region Fabric dasselbe wie Cisco SD-WAN Cloud OnRamp?+

    Nein, sie lösen unterschiedliche Probleme, sind aber komplementär. Cloud OnRamp für SaaS/IaaS ist ein Feature, das den Pfad von einem Branch-Standort zu einem spezifischen Cloud-Applikations- oder IaaS-Anbieter optimiert. MRF ist eine grundlegende Architektur zur Skalierung des gesamten WAN selbst über viele Standorte und geografische Gebiete hinweg. Sie würden Cloud OnRamp typischerweise *innerhalb* einer Access-Region Ihres MRF-Deployments verwenden.