Dynamic Multipoint VPN was designed to make large hub-and-spoke VPN deployments less dependent on a separate static tunnel configuration for every branch. It combines multipoint GRE, Next Hop Resolution Protocol, dynamic routing, and IPsec so spokes can register their public reachability with a hub and, in appropriate designs, build direct spoke-to-spoke forwarding paths. The result can scale better than a full mesh of manually defined point-to-point tunnels, but it also creates several protocol layers that must all work.<\/p>\n
The current 300-410 ENARSI<\/a> v1.1 blueprint includes configuring and verifying single-hub DMVPN with GRE\/mGRE, NHRP, IPsec, dynamic neighbors, and spoke-to-spoke behavior. Troubleshooting is easiest when each layer is checked separately instead of treating \u201cthe DMVPN tunnel\u201d as one feature.<\/p>\n Multipoint GRE lets one tunnel interface represent multiple dynamic GRE peers. The hub does not need a separate logical interface for every spoke. NHRP provides the mapping between a spoke\u2019s tunnel address and its underlay or NBMA address. A routing protocol then exchanges reachability over the overlay, while IPsec protects the GRE traffic across the untrusted transport.<\/p>\n These functions depend on one another but fail differently. A spoke can have IP connectivity to the hub\u2019s public address while NHRP registration fails. NHRP can register correctly while the routing protocol never forms a neighbor. Routes can be present while IPsec negotiation prevents user traffic. The architecture should therefore be documented as a stack of control relationships rather than one green\/red tunnel status.<\/p>\n The general VPN protocol model<\/a> helps place DMVPN correctly: GRE provides tunneling and multiprotocol flexibility, NHRP supplies dynamic mapping, and IPsec provides confidentiality and integrity.<\/p>\n Every DMVPN session ultimately depends on the transport network between public or NBMA addresses. Verify routing to the hub, NAT behavior, firewall rules, MTU, and basic IP reachability before investigating NHRP. If a spoke cannot reach the hub\u2019s transport address, overlay commands cannot compensate for the missing underlay.<\/p>\n When NAT is present, confirm that the design and IPsec mode support the translation path. Internet transports can also change source addresses or time out state during failover. Capture the actual outer addresses seen at the hub rather than relying only on the configured WAN interface. A branch with dual Internet circuits may register from a different address after a provider failover.<\/p>\n Document which transport path each spoke is expected to use. That makes it easier to distinguish a correct failover from an accidental path change. Underlay monitoring should be independent of DMVPN so operations can tell whether an outage begins in the carrier path or in the overlay itself.<\/p>\n A spoke registers its tunnel-to-NBMA mapping with the hub using NHRP. The hub becomes a mapping authority that other participants can consult. If registration is missing, check the configured NHS address, tunnel network ID, authentication where used, source interface, and the mapping or multicast statements required by the design.<\/p>\n NHRP tables should show current mappings with expected tunnel and public addresses. An old or incomplete entry can indicate transport changes, stale state, or a spoke that has not refreshed registration. Clear state carefully during troubleshooting because forcing a re-registration can temporarily disrupt routing neighbors that depend on the tunnel.<\/p>\n For spoke-to-spoke traffic, NHRP supplies the information needed to build a more direct forwarding path. Treat this as a separate validation step after hub registration. A healthy spoke-to-hub relationship does not prove that shortcut resolution between spokes is working.<\/p>\n Engineers often describe DMVPN designs as phases because the forwarding and routing behavior evolved over time. Phase 1 keeps spoke traffic through the hub. Phase 2 can create direct spoke-to-spoke tunnels but has routing next-hop requirements that affect summarization. Phase 3 uses NHRP redirect and shortcut behavior so the hub can remain the routing next hop while spokes install optimized forwarding toward one another.<\/p>\n Current troubleshooting should focus on the actual configured behavior rather than the label alone. Verify whether the hub sends redirects, whether spokes install shortcuts, and whether route summarization is used. If an inherited diagram says \u201cPhase 3\u201d but the required NHRP commands are absent, the label is not evidence.<\/p>\n Phase 3 is attractive because the hub can advertise summarized or default routing while NHRP helps traffic find a direct spoke path after the first packets. That reduces the route-detail pressure on the hub-and-spoke routing design, but it makes NHRP state even more important to forwarding diagnosis.<\/p>\n EIGRP, OSPF, and BGP can all be used over DMVPN, but each has topology and next-hop considerations. The hub may need to preserve a spoke\u2019s next hop so other spokes can resolve it directly, and split-horizon behavior may need to be considered depending on the protocol and design phase. Do not copy a routing template between protocols without understanding those differences.<\/p>\n Check routing neighbors after NHRP registration. If a neighbor is absent, inspect tunnel addresses, multicast handling, network statements, authentication, and protocol timers. If the neighbor is healthy but routes are missing, inspect filtering, summarization, next-hop attributes, and redistribution. A working tunnel interface only proves the interface is logically up, not that the overlay routing system is correct.<\/p>\n Keep the number of routes proportional to the design. Branch prefixes can often be summarized toward the core. A DMVPN network that advertises every small user subnet individually may work, but it creates unnecessary routing and troubleshooting state at the hub.<\/p>\n DMVPN commonly protects GRE with IPsec, so IKE and IPsec security associations become another required layer. Verify peer negotiation, authentication, proposals, transform sets or profiles, lifetimes, and counters. A failure here can leave NHRP or routing behavior partially visible while data traffic is dropped or remains unprotected.<\/p>\nBuild the mental model from mGRE, NHRP, routing, and IPsec<\/h3>\n
Use NHRP registration as the first overlay checkpoint<\/h3>\n
Understand Phase 1, Phase 2, and Phase 3 behavior when inheriting existing designs<\/h3>\n
Run the routing protocol with DMVPN-specific next-hop expectations<\/h3>\n
Troubleshoot IPsec independently from GRE and NHRP<\/h3>\n