DMVPN-Probleme wirken oft „wie VPN kaputt“, sind aber in der Praxis meist eine Mischung aus Underlay-Erreichbarkeit, Tunnel-Interface-Status, NHRP-Registrierung und IPsec-Schutz. Ein solides Troubleshooting folgt deshalb einer festen Reihenfolge: erst Underlay (NBMA), dann Tunnel0 (GRE/mGRE), dann NHRP (Mappings/Registrierung), dann Routing (IGP/BGP), und erst am Ende IPsec-Counters/Policies. Mit dieser Systematik findest du typische Fehler in Minuten statt in Stunden.
Troubleshooting-Reihenfolge: Underlay → Tunnel → NHRP → Routing → IPsec
Wenn du die Reihenfolge einhältst, vermeidest du „im Kreis debuggen“. Viele DMVPN-Fehler liegen vor dem IPsec-Layer, obwohl der Tunnel „irgendwie“ existiert.
- Underlay: Public/NBMA IP erreichbar, Default Route ok
- Tunnel0: Interface up/up, Source/Destination/Mode korrekt
- NHRP: Spoke registriert beim Hub, Maps korrekt, Multicast ok
- Routing: Nachbarn/Routes über Tunnel vorhanden
- IPsec: SAs aktiv, Counters steigen bei Traffic
Schritt 1: Underlay prüfen (NBMA-Erreichbarkeit)
DMVPN braucht eine stabile Underlay-Erreichbarkeit. Wenn Spoke den Hub-NBMA nicht erreicht, gibt es weder NHRP-Registration noch IPsec-SAs. Prüfe Default Route, WAN-Interface und Ping/Traceroute zur Hub-IP.
Router# show ip interface brief
Router# show ip route | include Gateway|0.0.0.0
Router# ping <hub-nbma-ip>
Router# traceroute <hub-nbma-ip>Typische Underlay-Fehler
- Kein Default Gateway oder falsches ISP-Gateway
- Outside-ACL blockiert UDP/500/4500 oder ESP
- NAT/Carrier-NAT stört IPsec/NAT-T
Schritt 2: Tunnel-Status prüfen (mGRE/GRE)
Der Tunnel muss logisch funktionieren: IP-Adresse, Tunnel-Mode, Source und (beim Hub) multipoint-Konfiguration. Auf Spokes ist mGRE ebenfalls üblich, aber der NHS ist entscheidend.
Tunnel Interface prüfen
Router# show ip interface brief | include Tunnel0
Router# show interfaces tunnel0
Router# show running-config interface tunnel0Was du im Tunnel-Config prüfen solltest
- IP-Adresse/Mask passt zum Overlay
tunnel sourceist korrekt (WAN-IP oder Interface)- Hub:
tunnel mode gre multipoint - Spoke: mGRE ist ok, aber NHRP muss korrekt sein
- Keepalive kann helfen, ist aber nicht zwingend
Schritt 3: NHRP prüfen (Kern von DMVPN)
NHRP ist der „Directory Service“: Es mappt Overlay-IP (Tunnel-IP) auf NBMA-IP (WAN-IP). Wenn NHRP nicht stimmt, gibt es keine saubere Spoke-Registrierung und keine Shortcuts.
Wichtigste Show-Befehle
Router# show ip nhrp
Router# show ip nhrp detailWas du auf dem Hub sehen willst
- Für jeden Spoke einen NHRP-Cache-Eintrag
- Overlay-IP des Spokes ↔ NBMA-IP des Spokes
- Registrierungsstatus/Timeouts plausibel
Was du auf dem Spoke sehen willst
- Statische Map zum Hub (Overlay→NBMA) vorhanden
- NHS (Hub) gesetzt und erreichbar
- Multicast-Mapping auf Hub-NBMA korrekt
Typischer Fehler 1: NHRP Network-ID oder Authentication mismatch
Wenn Network-ID oder NHRP-Authentication nicht übereinstimmen, registriert sich der Spoke nicht. Der Tunnel kann trotzdem „up“ aussehen, aber NHRP bleibt leer.
Prüfen der Parameter
Router# show running-config interface tunnel0 | include ip nhrp
Router# show ip nhrp detailKonzeptwerte (müssen matchen)
ip nhrp network-idip nhrp authentication
Typischer Fehler 2: Multicast-Mapping fehlt (Routing-Protokoll kommt nicht hoch)
Viele IGPs benötigen Multicast (Hello/Updates). Wenn der Spoke kein Multicast zum Hub mappt, kann NHRP registriert sein, aber OSPF/EIGRP-Nachbarschaft bleibt down.
Spoke: Multicast-Mapping prüfen
Router# show running-config interface tunnel0 | include map multicast
Router# show ip nhrpTypische Spoke-Zeile
ip nhrp map multicast <hub-nbma-ip>Schritt 4: Routing prüfen (IGP/BGP über Tunnel)
Wenn Tunnel und NHRP stehen, muss Routing folgen: Nachbarschaften über Tunnel0 sind up, und Routen zu Remote-LANs müssen existieren. Ohne Routing wirkt DMVPN wie „Tunnel da, aber nichts geht“.
OSPF prüfen
Router# show ip ospf neighbor
Router# show ip route ospfEIGRP prüfen
Router# show ip eigrp neighbors
Router# show ip route eigrpBGP prüfen
Router# show ip bgp summary
Router# show ip route bgpTypischer Fehler 3: Split Horizon / Next-Hop-Themen (Hub-and-Spoke Routing)
Je nach Routing-Protokoll und DMVPN-Phase können klassische Hub-and-Spoke-Fallen auftreten: Routen werden am Hub nicht korrekt zwischen Spokes verteilt oder Next-Hop-Informationen verhindern Spoke-to-Spoke-Pfade.
- EIGRP: Split Horizon auf Tunnel-Interface relevant (phasenabhängig)
- OSPF: Network-Type/DR/BDR kann relevant sein
- Phase 3: Redirect/Shortcut-Mechanismen müssen passen
Schritt 5: IPsec prüfen (SAs und Counters)
Erst wenn Underlay, Tunnel und NHRP ok sind, lohnt IPsec-Debugging. Prüfe IKE/IPsec-SAs und ob die Counters bei DMVPN-Traffic steigen. Bei DMVPN mit IPsec Profile sind die SAs trotzdem sichtbar.
IKE/IPsec-Status prüfen
Router# show crypto isakmp sa
Router# show crypto ipsec saWas du bei IPsec sehen willst
- ISAKMP/IKE-SA ist up (z. B.
QM_IDLE) - IPsec-Counters (
encaps/decaps) steigen bei Traffic - Keine „decrypt failed“/„no sa“-Spikes
Typischer Fehler 4: IPsec-Parameter passen nicht (Transform/PFS)
Wenn NHRP registriert, aber keine SAs entstehen oder „no sa“ steigt, ist oft ein Mismatch in Transform-Set oder PFS die Ursache. Bei Templates ist das schnell zu übersehen.
Checks
Router# show running-config | include transform-set|ipsec profile|set pfs
Router# show crypto ipsec saTypischer Fehler 5: MTU/MSS – Tunnel steht, aber Anwendungen hängen
DMVPN + IPsec erhöht Overhead. Dadurch kann PMTUD brechen, und große TCP-Sessions hängen. Ein konservativer MSS-Wert am Tunnel ist ein bewährter Praxisfix.
MSS-Clamping am Tunnel
interface tunnel0
ip tcp adjust-mss 1360MTU prüfen
Router# show interfaces tunnel0 | include MTU
Router# ping <remote-host> df-bit size 1400Verifikation: Spoke-to-Spoke Shortcut (je nach Phase)
Wenn du Phase 2/3 nutzt, sollte Spoke-to-Spoke-Traffic optional direkt gehen. Dann siehst du NHRP-Entries für andere Spokes, nicht nur für den Hub.
Router# show ip nhrp
Router# traceroute <remote-lan-host>Debugging gezielt und kurz einsetzen
Wenn Show-Befehle nicht reichen, nutze Debugs sparsam. Bei DMVPN sind NHRP- und Crypto-Debugs die wichtigsten, aber sie können CPU-lastig sein.
Router# terminal monitor
Router# debug nhrp
Router# debug crypto isakmp
Router# debug crypto ipsec
Router# undebug allQuick-Reference: DMVPN Troubleshooting Checkliste (Copy & Paste)
Diese Liste deckt Underlay, Tunnel, NHRP, Routing und IPsec in der richtigen Reihenfolge ab.
show ip interface brief
show ip route | include Gateway|0.0.0.0
ping <hub-nbma-ip>
traceroute <hub-nbma-ip>
show ip interface brief | include Tunnel0
show interfaces tunnel0
show running-config interface tunnel0
show ip nhrp
show ip nhrp detail
show ip ospf neighbor
show ip eigrp neighbors
show ip bgp summary
show crypto isakmp sa
show crypto ipsec sa
show loggingKonfiguration speichern
Router# copy running-config startup-configKonfiguriere 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.
