Meraki SD-WAN planen: Hubs dimensionieren, Routing wählen, neue Standorte sauber anbinden

Früher oder später stellt sich in jedem Meraki SD-WAN dieselbe Frage: Was ist zu tun, wenn ein neuer Standort dazukommt? Die Antwort ist kurz, wenn das Design steht, und lang, wenn Hub-Größe, Routing und Hardware nie als Design entschieden wurden. Dieser Beitrag folgt der Meraki-Dokumentation, trennt sie von unseren Empfehlungen und endet mit einer Checkliste.

Die Architektur, wie Meraki sie beschreibt

Auto VPN baut Tunnel zwischen MX-Appliances über einen cloudbasierten Prozess auf; ein Registrierungsdienst in der Cloud orchestriert die Verbindungen. Ein Hub ist der zentrale Punkt, zu dem Standorte ihre Tunnel aufbauen. Ein Spoke verbindet sich ausschließlich mit den ihm zugewiesenen Hubs, Verkehr zwischen Standorten läuft über den Hub.

Diese Hub-and-Spoke-Topologie empfiehlt Meraki für die meisten SD-WAN-Installationen. Im Mesh verbindet sich dagegen jede Appliance im Mesh-Modus direkt mit allen anderen Appliances im Mesh-Modus. Die empfohlene Referenzarchitektur hat sechs Bausteine:

• ein MX im Rechenzentrum als One-Armed-Konzentrator mit nur einer Ethernet-Verbindung ins vorgelagerte Netz
• Warm Spare beziehungsweise Hochverfügbarkeit im Rechenzentrum
• OSPF-Ankündigung der VPN-Subnetze ins Rechenzentrumsnetz
• Redundanz über ein zweites Rechenzentrum (DC-DC-Failover)
• Split Tunnel an den Standorten
• zwei WAN-Uplinks an allen Standorten

Über jeden Tunnel senden die Appliances jede Sekunde eine UDP-Probe von etwa 100 Byte und leiten daraus Paketverlust, Latenz und Jitter für die Pfadwahl ab.

Hubs nach Tunneln dimensionieren, nicht nach Standorten

Die Hub-Wahl beginnt im MX Sizing Guide. Er nennt je Modell zwei Tunnelzahlen: Das Maximum stammt aus Labortests ohne Nutzverkehr in den Tunneln, das empfohlene Maximum aus Tests mit Nutzverkehr. Basis der Leistungswerte ist MX 26.1.

Dasselbe Dokument führt die Zahl der VPN-Tunnel als Faktor mit hoher Auswirkung auf die Leistung, ebenso HTTPS-Inspektion auf dem Gerät. Und es empfiehlt, das Sizing mit einem Proof of Concept zu validieren, weil jede Umgebung anders ist.

Entscheidend ist die Zählweise. Ein Standort mit zwei Uplinks baut Auto-VPN-Tunnel über beide Internetschnittstellen gleichzeitig auf. Im DC-DC-Failover-Design baut er Tunnel zu allen für ihn konfigurierten Hubs auf und schickt Verkehr zu mehrfach angekündigten Subnetzen an den erreichbaren Hub mit der höchsten Priorität.

Routing: statische Routen, BGP und was MX 26.2 ändert

Im Grundmodell verteilt das Dashboard die Routen selbst: Jedes Subnetz und jede statische Route mit aktiviertem VPN-Modus geht an die anderen MX der Organisation. Die Reihenfolge der Hubs am Spoke wirkt als Metrik; Routen über den obersten Hub haben die Metrik 0, jede weitere Position erhöht sie um eins. Mit Peer Tracking markiert ein MX alle Routen eines Tunnels als unerreichbar, sobald die Gegenstelle ausfällt.

Laut Meraki kann dieser Standardansatz zu großen Routingtabellen führen, die Geräte in Netzen mit vielen Subnetzen destabilisieren können. Dafür beschreibt Meraki vier Techniken:

• Keine Hub-to-Hub-Tunnel: gilt organisationsweit; der Meraki-Support aktiviert es auf Anfrage.
• Keine Spoke-to-Spoke-Routen: Routen zu Subnetzen hinter anderen Spokes werden nicht mehr verteilt; ebenfalls organisationsweit über den Support.
• Tracking hub-originierter Routen: Spokes tracken jede Route mit einem Hub als Next Hop, auch ohne redundanten Pfad; ebenfalls über den Support.
• Routenzusammenfassung: standardmäßig aktiv. Zusammengefasste Routen tragen keine Metrik und werden nicht getrackt.

Mit MX 26.2 verschiebt sich die Grenze zwischen Auto VPN und dynamischem Routing. Laut Features Directory lässt sich BGP unabhängig von Auto VPN aktivieren. MP-BGP tauscht IPv4- und IPv6-Routen zwischen Auto-VPN-Peers über eine einzige iBGP-Session aus. Für eBGP-Routen, die über mehrere IPsec-VPN-Tunnel gelernt werden, verteilt ECMP neue Flows auf gleichwertige Pfade.

Segmentierung und SSE: VRF, SGT und Secure Access

Segmentierung hieß im Meraki SD-WAN lange: VLANs, Firewall-Regeln, Gruppenrichtlinien. VRF, also mehrere virtuelle Routingtabellen auf einem Gerät, führt das Features Directory bei 26.1 als neue Funktion mit dem Vermerk „Early Access“, bei 26.2 als Erweiterung ohne diesen Vermerk. Bei den Security Group Tags brachte 26.1 Zuweisung und Durchsetzung über Gruppenrichtlinien; 26.2 ergänzt IP-to-SGT-Mapping und SGACL.

Für überlappende Adressräume gibt es seit 26.1 VPN-Übersetzungen: Eine 1:1-Subnetzübersetzung lässt Standorte mit überlappenden Subnetzen am VPN teilnehmen. Dazu kommen NAT-Ausnahmen für einzelne oder alle VLANs.

Für Internet und SaaS bringt 26.1 die Integration von Cisco Secure Access ins Dashboard. Wer Secure Connect nutzt, steht vor einer Migration: Cisco bietet den Umstieg an, um sein SASE-Portfolio auf eine SSE-Plattform zu konsolidieren. Der Migrationsleitfaden nennt die Bedingungen:

• Eine Organisation kann derzeit nicht gleichzeitig mit Secure Connect und Secure Access verbunden sein; eine Unterbrechung ist unvermeidlich.
• Das Umziehen der Auto-VPN- und IPsec-Verbindungen erfordert Downtime.
• Secure Connect entfernt der Support erst, wenn alle zugehörigen Konfigurationen gelöscht sind, darunter RAVPN-Head-End-Regionen, private Anwendungen und Richtlinien. Ein schneller Rückweg ist damit versperrt; Cisco nennt die Einschränkung vorübergehend.

Hardwaregeneration: Was bei MX 18.1 stehen bleibt

Die neuen Funktionen haben eine Hardwaregrenze. MX64, MX64W, MX65, MX65W, MX84, MX100 und vMX100 laufen laut Meraki höchstens mit MX 18.1 und erhalten keine Firmware ab 18.2, also nichts aus 26.1 und 26.2. Die Support-Enden:

Die letzten beiden Zeilen stammen aus EOL15861 vom 27. August 2026: Cisco ersetzt MX67C und MX68CW durch Cisco 8000 Series Secure Router mit MX OS, erkennbar an der Endung -MX. Laut Ciscos FAQ behält ein solcher Router ein Geräteleben lang das bestellte Betriebssystem; eine Umstellung von MX OS auf IOS XE ist nicht möglich. Bestehende Co-Term- oder Subscription-Lizenzen lassen sich nicht übertragen. Was das für die Planung heißt, behandelt der Beitrag zu den Meraki-Lizenzmodellen.

Dieselbe Hardwarefamilie gibt es auch mit IOS XE: Die Secure Router C8455-G2, C8355-G2 und C8235-G2 lassen sich ab IOS XE 26.1.1 im Dashboard verwalten. Entscheidend ist eine Regel aus der Onboarding-Anleitung: Eine Organisation kann Auto VPN nur für einen Gerätetyp aktivieren, entweder für IOS-XE-basierte Secure Router oder für MX und Secure Router mit MX OS. Meraki empfiehlt für IOS-XE-Geräte eine eigene Organisation. Auto VPN auf diesen Routern nutzt standardmäßig einen hybriden Schlüsselaustausch aus P-521 und dem Post-Quantum-Verfahren ML-KEM-768; Hub-to-Hub-Routing und ECMP stehen dort laut Meraki derzeit nicht zur Verfügung. Die grundsätzliche Wahl zwischen beiden Welten behandelt der Beitrag Meraki oder Catalyst.

Einen neuen Standort hinzufügen: die Checkliste

Steht das Design, ist ein neuer Standort Routine. In dieser Reihenfolge nehmen wir ihn auf:

1. 01

   Tunnelbudget prüfen

   Uplinks des Standorts mal Hubs mal Hub-Uplinks ergibt die neuen Tunnel. Die Summe je Hub gegen das empfohlene Maximum halten.

2. 02

   Hardware wählen

   Kein Modell, das bei MX 18.1 endet. Bei MX67C und MX68CW das Verkaufsende am 27. November 2026 beachten; die Nachfolger brauchen neue Lizenzen.

3. 03

   Adressraum vergeben

   Ein eindeutiges Subnetz, das in die Zusammenfassung des Standortbereichs passt. VPN-Übersetzung bleibt die Ausnahme.

4. 04

   Netz anlegen und Geräte einlösen

   Aus dem Template des Standorttyps. Wie Templates und Claiming zusammenspielen, beschreibt der Beitrag zum Meraki-Rollout über viele Standorte.

5. 05

   Auto VPN als Spoke einrichten

   Hubs in der festgelegten Reihenfolge eintragen, lokale Subnetze in den VPN-Modus nehmen, Split oder Full Tunnel wie im Standard.

6. 06

   Richtlinien und Segmentierung übernehmen

   Beide Uplinks aktiv, Leistungsklassen für Sprache und kritische Anwendungen, VLANs, VRF, SGT und Secure Access wie an allen Standorten.

7. 07

   Firmware angleichen

   Derselbe MX-Zug wie an den Hubs. Wer Funktionen aus 26.2 nutzt, braucht 26.2 auf allen beteiligten Geräten.

8. 08

   Mit echtem Anwendungsverkehr abnehmen

   Ein grüner Tunnel ist Diagnose, keine Abnahme. Abgenommen ist der Standort, wenn aus seinem Clientnetz die realen Dienste im Rechenzentrum und in der Cloud erreichbar sind, auch mit gezogenem Uplink.

Wie wir Meraki-SD-WAN-Designs planen, Hubs dimensionieren und Standorte in Wellen anbinden, beschreibt unser SD-WAN-Angebot im Anschluss an diesen Beitrag; alle Meraki-Leistungen finden Sie unter Cisco Meraki. Steht bei Ihnen noch ein MX84 oder MX100 im Hub oder ist der nächste Standort geplant, können Sie das Design mit uns durchgehen.