DMVPN Phase 1–3: Designentscheidungen, NHRP, Shortcut Routing

DMVPN (Dynamic Multipoint VPN) ist ein Cisco-Architekturpattern, um viele Standorte über einen Hub-and-Spoke-Tunnelverband zu verbinden, ohne für jeden Spoke einen eigenen statischen Tunnel bauen zu müssen. Kernkomponenten sind GRE over IPsec, mGRE (multipoint GRE) am Hub, NHRP als „Mapping-Datenbank“ (Tunnel-IP ↔ Public-IP) und – je nach Phase – Direktverbindungen (Spoke-to-Spoke) über Shortcut Routing. In der Praxis entscheidet die DMVPN-Phase (1–3) über Betriebsverhalten, Skalierung, Routing-Policy und Troubleshooting-Aufwand. Dieser Artikel erklärt die Phasen, die Designentscheidungen dahinter und wie NHRP/Shortcut Routing wirklich funktionieren.

DMVPN Bausteine: mGRE, NHRP, IPsec

DMVPN kombiniert drei Technologien. mGRE reduziert Tunnel-Statik am Hub. NHRP löst „wer ist hinter welcher Public-IP?“ auf. IPsec liefert Verschlüsselung und Authentifizierung. Ohne sauberes Zusammenspiel sind Instabilitäten vorprogrammiert.

• mGRE (Hub): ein Tunnelinterface für viele Spokes
• GRE (Spoke): Tunnelinterface zum Hub, optional dynamische Peers
• NHRP: dynamische Zuordnung Tunnel-IP ↔ NBMA/Public-IP
• IPsec: Schutz der GRE-Pakete (meist IKEv2 in modernen Designs)

Merker

$\text{DMVPN}=\text{mGRE}+\text{NHRP}+\text{IPsec}$

NHRP kurz erklärt: „ARP für NBMA“

NHRP (Next Hop Resolution Protocol) arbeitet wie ein Mapping-Service: Ein Spoke registriert beim Hub seine Tunnel-IP und seine NBMA-Adresse (Public/WAN-IP). Wenn ein Spoke einen anderen Spoke direkt erreichen soll, fragt er den Hub nach der NBMA-Adresse des Ziel-Spokes. Das ist die Grundlage für Shortcut Routing in Phase 2/3.

• Registration: Spoke → Hub (Ich bin Tunnel-IP X, NBMA-IP Y)
• Resolution: Spoke → Hub (Welche NBMA-IP gehört zu Tunnel-IP Z?)
• Shortcut: Spoke baut direkte GRE/IPsec Verbindung zu Spoke auf

DMVPN Phase 1: Hub-and-Spoke ohne Shortcut Routing

Phase 1 ist das konservativste Modell: Spokes sprechen nur mit dem Hub. Spoke-to-Spoke Verkehr geht immer über den Hub (Hairpin). Das ist betrieblich simpel, aber skaliert bei Ost-West Traffic schlecht und belastet den Hub.

• Spoke-to-Spoke: immer über Hub
• Routing: einfach, oft statisch oder IGP mit Hub als Transit
• Pro: sehr gut kontrollierbar
• Contra: suboptimale Pfade, Hub-Bandbreite/CPU belastet

DMVPN Phase 2: Spoke-to-Spoke Data Plane via NHRP Shortcut

Phase 2 erlaubt direkte Spoke-to-Spoke Verbindungen in der Data Plane. Control Plane (Routing) ist jedoch häufig noch „hub-zentriert“: Spokes lernen Routes so, dass sie den Hub als Next-Hop sehen, aber NHRP kann den Next-Hop in der Data Plane auflösen und eine direkte Verbindung bauen.

• Data Plane: Spoke-to-Spoke direkt möglich
• Control Plane: Next-Hop oft Hub (abhängig vom Routingprotokoll)
• Pro: bessere Pfade, weniger Hub-Last
• Contra: mehr Komplexität, Next-Hop-Design muss verstanden werden

Shortcut Routing Denkmuster

$\text{Route zeigt zum Hub}+\text{NHRP löst Ziel-Spoke auf}\to \text{Direktpfad}$

DMVPN Phase 3: Optimiertes Routing mit Next-Hop Preservation/Redirect

Phase 3 erweitert Phase 2 um ein klareres Routingmodell: Spokes können Prefixes lernen, bei denen der eigentliche Spoke als Next-Hop erhalten bleibt (oder durch NHRP Redirect/Shortcut Mechanismen effizient wird). Damit wird Routing konsistenter und Skalierung/Failover besser steuerbar, insbesondere mit EIGRP/OSPF Patterns.

• Data Plane: Spoke-to-Spoke direkt
• Control Plane: Next-Hop-Optimierung (weniger „Hub als Next-Hop“)
• Pro: besser skalierbar, klareres Routingverhalten
• Contra: höchste Komplexität, NHRP Redirect/Shortcut muss sauber laufen

Designentscheidung: Welche Phase passt zu welchem Use-Case?

Die Phasenwahl ist keine „Version“, sondern ein Architekturentscheid. Sie hängt von Traffic-Mustern, Hub-Ressourcen, Betriebsreife und Fehlertoleranz ab.

• Phase 1: wenig Spoke-to-Spoke, maximale Einfachheit
• Phase 2: moderater Ost-West Traffic, bessere Pfade gewünscht
• Phase 3: viele Spokes, viel Ost-West, hohe Skalierungsanforderungen

Routing über DMVPN: EIGRP/OSPF/BGP und die üblichen Patterns

DMVPN lebt oder stirbt mit Routing. EIGRP ist historisch sehr verbreitet, OSPF funktioniert, braucht aber saubere Network-Type-Entscheidungen. BGP über DMVPN ist oft die stabilste Wahl bei großen Netzen, weil Policy und Skalierung besser kontrollierbar sind.

• EIGRP: einfach, aber Design (split-horizon, next-hop) beachten
• OSPF: Network Type (point-to-multipoint) sauber setzen
• BGP: skaliert gut, klare Policy, oft bevorzugt in Enterprise-WANs

Konfigurationsmuster: Hub (mGRE + NHRP) (Phase 2/3 Grundgerüst)

Dieses Pattern zeigt die typische Hub-Basis: mGRE Tunnel, NHRP Network-ID, NHS-Rolle (Server), und GRE over IPsec (über Tunnel Protection oder Crypto Profile). Werte und Auth-Keys sind Beispiele.

Hub Tunnel (Pattern)

interface Tunnel0
 description DMVPN HUB
 ip address 10.255.0.1 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 ip nhrp network-id 100
 ip nhrp authentication DMVPNKEY
 ip nhrp map multicast dynamic

Konfigurationsmuster: Spoke (NHRP Registration + NHS)

Der Spoke kennt den Hub als NHS (Next Hop Server) und mappt den Hub statisch (Tunnel-IP ↔ NBMA-IP). Multicast wird zum Hub gemappt (für Routingprotokolle). Danach registriert sich der Spoke automatisch.

Spoke Tunnel (Pattern)

interface Tunnel0
 description DMVPN SPOKE1
 ip address 10.255.0.11 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 ip nhrp network-id 100
 ip nhrp authentication DMVPNKEY
 ip nhrp nhs 10.255.0.1
 ip nhrp map 10.255.0.1 203.0.113.1
 ip nhrp map multicast 203.0.113.1

IPsec Integration: GRE over IPsec sauber schützen

In modernen Deployments wird GRE over IPsec häufig über ein IPsec-Profil auf dem Tunnel geschützt. Das ist betrieblich sauberer als große Crypto Maps, weil der Tunnel das Objekt ist. Die IKEv2 Details hängen von deinem Standard ab.

Tunnel Protection (Pattern)

crypto ipsec profile DMVPN-IPSEC
 set transform-set TS-ESP-AESGCM
 set pfs group14
interface Tunnel0

tunnel protection ipsec profile DMVPN-IPSEC

NHRP Shortcut Routing: Was wirklich passiert

Wenn Spoke A Traffic zu einem Prefix hinter Spoke B sendet, kann der Hub A per NHRP die NBMA-Adresse von B liefern. A baut dann dynamisch einen direkten GRE/IPsec-Peer zu B auf. Der Tunnel bleibt logisch „Tunnel0“, aber die Peer-Beziehung wird dynamisch ergänzt.

• Spoke A sendet initial via Hub
• Hub liefert NHRP Mapping (B Tunnel-IP → B NBMA-IP)
• Spoke A baut direkte Verbindung zu Spoke B
• Traffic läuft direkt, Hub wird entlastet

Typische Pitfalls: Warum DMVPN „instabil“ wirkt

Die häufigsten Probleme sind kein „DMVPN Bug“, sondern Design- und Betriebsfehler: falsche MTU/MSS, NHRP Mappings, NAT auf Spoke-WANs, oder Routing-Parameter, die nicht zu Phase/Network-Type passen.

• NAT am Spoke: NBMA-IP ändert sich, Registrations brechen
• MTU/PMTUD: IPsec Overhead → Blackholes ohne MSS Clamping
• Routing: falscher OSPF Network Type oder EIGRP Split-Horizon
• NHRP Auth/Network-ID mismatch → keine Registrierung

Verifikation: NHRP, Tunnel-Status und Shortcut-Peers prüfen

DMVPN debuggt man am schnellsten über NHRP-Tabellen und Tunnel-Status. Du willst sehen: Registrations da, Peers da, dynamische Spoke-to-Spoke Mappings vorhanden, IPsec SAs aktiv.

NHRP und DMVPN Status

show dmvpn
show ip nhrp
show ip nhrp detail

IPsec/IKE Status

show crypto ikev2 sa
show crypto ipsec sa

Routing über Tunnel

show ip route | include 10.255.0.
show ip cef <remote-spoke-lan-host> detail

Operational Best Practices: Stabilität im Betrieb

DMVPN wird betriebssicher, wenn du Standards setzt: konsistente Network-IDs/Keys, saubere MTU/MSS, klare Routing-Templates, und Monitoring von NHRP Registrations und Tunnel-States. Ohne diese Standards wird DMVPN schnell „magisch“.

• MSS Clamping auf Tunnelinterfaces (typisch 1360–1400)
• IP SLA/Tracking für WAN-Health, um Flaps zu reduzieren
• NHRP Monitoring: Registrations, Expiry, Flaps
• Change-Disziplin: Phase/IGP-Parameter nicht „nebenbei“ ändern

MSS Clamping (Pattern)

interface Tunnel0
 ip tcp adjust-mss 1360

Quick-Runbook: DMVPN Incident Isolation

Diese Checkliste trennt schnell NHRP-, IPsec- und Routing-Probleme und eignet sich für produktive Störungen.

show dmvpn
show ip nhrp
show interface Tunnel0
show crypto ikev2 sa
show crypto ipsec sa
show ip route
show interfaces | include drops|error

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.