What Is DMVPN Phase 2 in Networking?
Also known as: DMVPN Phase 2, DMVPN Phase 2 Cisco, ENARSI DMVPN, spoke to spoke VPN, NHRP
On This Page
Quick Definition
DMVPN Phase 2 lets branch office routers (spokes) talk directly to each other, instead of always going through the main office router (hub). It works by building temporary, direct tunnels between spokes when they need to exchange data. This makes the network faster and more efficient, especially when branch offices need to share files or video calls without extra delay.
Must Know for Exams
DMVPN Phase 2 is a high-priority topic in the Cisco CCNP Enterprise concentration exam, specifically ENARSI (Implementing Cisco Enterprise Advanced Routing and Services). It appears frequently because it integrates multiple advanced routing and security concepts into one practical technology. The exam objectives explicitly list DMVPN under the “Layer 3 Technologies” section, with a focus on understanding its phases, components, and configuration.
In the ENARSI exam, candidates are expected to know the differences between DMVPN Phase 1, Phase 2, and Phase 3. They must understand how NHRP works, how the routing protocol interacts with NHRP to enable direct spoke-to-spoke tunnels, and how to troubleshoot common issues. Specific exam topics include: mGRE tunnel configuration, IPsec profile creation and application, NHRP configuration (including authentication and hold-time), and routing protocol tuning (especially next-hop-self behavior and route summarization).
The exam may also test the candidate’s ability to design a DMVPN Phase 2 network for a given scenario. For instance, a question might ask which phase of DMVPN to use if branch offices need to communicate directly with each other but the hub router has limited CPU resources. The correct answer is Phase 2 because it offloads data traffic from the hub. Another common exam question type involves troubleshooting: a candidate might be shown a configuration where spokes cannot establish direct tunnels, and they need to identify that the hub has “next-hop-self” enabled under the routing protocol, which prevents Phase 2 operation.
DMVPN Phase 2 also appears in the context of NAT and IPsec coexistence. Exam questions often ask how NAT traversal (NAT-T) affects DMVPN when spokes use private IP addresses behind a PAT device. Candidates must know that DMVPN Phase 2 requires that the hub be reachable from spokes, and that IPsec NAT-T must be enabled if NAT is present between spokes and the hub.
Passing the ENARSI exam requires not just memorization but also the ability to apply concepts to real-world designs. Because DMVPN Phase 2 combines routing, security, and tunnelling, it is a favourite topic for scenario-based questions. The exam question bank often includes exhibits with partial configurations and topology diagrams, and candidates must select the correct command or step to fix a problem or to complete a design.
Simple Meaning
Imagine a company with a main headquarters and several branch offices spread across different cities. In a traditional network, if one branch in New York wants to send data to another branch in London, the data first travels to the headquarters in Chicago, then to London. This is like sending a letter from one neighbor to another by first mailing it to a central post office, which then forwards it. DMVPN Phase 2 changes this by allowing the New York branch to send data directly to the London branch, just like neighbors handing a note directly through a window instead of using the mail system.
In more technical but still plain terms, DMVPN stands for Dynamic Multipoint VPN. Phase 2 is a specific version of this technology that enables direct spoke-to-spoke communication. The key idea is that the hub router acts like a directory or a switchboard operator. When a spoke (branch) wants to talk to another spoke, it first asks the hub for the other spoke’s current IP address. Once it gets that information, the two spokes build a direct encryption tunnel between themselves. This direct tunnel is created on demand and removed when no longer needed, saving resources.
The analogy of a conference call with a receptionist works well here. In Phase 1, every participant calls the receptionist, and the receptionist patches them together, but all audio still goes through the receptionist’s phone. In Phase 2, the receptionist gives each caller the contact details of the other person, and then the two callers hang up and call each other directly. This reduces the load on the receptionist and makes conversations clearer and faster.
DMVPN Phase 2 uses several technologies together: multipoint GRE (mGRE) tunnels for encapsulation, IPsec for encryption, Next Hop Resolution Protocol (NHRP) as the directory service, and a dynamic routing protocol like EIGRP or OSPF to share routing information. The combination allows the network to automatically discover other spoke routers and build secure direct connections without any manual configuration for each pair of spokes. This is especially valuable for large enterprises with hundreds or thousands of branch offices that need to communicate frequently.
Full Technical Definition
DMVPN Phase 2 is a Cisco-proprietary VPN architecture that builds upon Phase 1 by enabling dynamic, direct spoke-to-spoke tunnels. It is built on three core protocols: Multipoint GRE (mGRE) for tunnel encapsulation, IPsec for data confidentiality and integrity, and NHRP (Next Hop Resolution Protocol) as a distributed database that maps tunnel IP addresses to physical (public) IP addresses. A dynamic routing protocol such as EIGRP, OSPF, or BGP is used to propagate routes across the entire DMVPN network.
In Phase 2, the critical difference from Phase 1 is that the routing protocol is configured to advertise the remote spoke’s LAN subnets with a next-hop that points to the spoke’s tunnel IP address, rather than the hub’s. This is achieved by disabling the “next-hop-self” setting on the hub for routes learned from spokes. When a spoke receives a routing update from the hub that includes a network behind another spoke, the next-hop IP is the remote spoke’s tunnel IP. The spoke then performs an NHRP resolution request to the hub, asking for the real (public) IP address associated with that tunnel IP. The hub responds with the public IP of the destination spoke, and the initiating spoke immediately builds a direct IPsec tunnel to that destination spoke.
This direct tunnel is established only when there is traffic to send. The IPsec security associations (SAs) are created dynamically between the two spokes. The mGRE interface on each spoke allows a single tunnel interface to support multiple logical tunnels to different destinations. NHRP maintains a cache of mappings; if a spoke does not have a mapping for a destination tunnel IP, it must resolve it via the hub. The hub acts as an NHRP server and holds the authoritative database of all spoke mappings.
One key technical detail for exams is that DMVPN Phase 2 uses a “on-demand” tunnel establishment model. The spoke-to-spoke IPsec tunnel is created only when traffic matching a route with a spoke next-hop is triggered. The tunnel is torn down after a period of inactivity (configurable via IPsec idle timeout). This conserves resources on the spoke routers, which may have limited CPU and memory.
From a configuration perspective, the hub uses a single mGRE tunnel interface with no tunnel destination configured, relying on NHRP to discover spoke addresses. Each spoke uses the hub’s tunnel IP as its destination, but the mGRE interface allows incoming connections from multiple spokes. The IPsec profile is applied to the tunnel interface or to a crypto map. The routing protocol on the hub must not use next-hop-self for spoke routes; instead, it should propagate the spoke’s original next-hop.
DMVPN Phase 2 is commonly deployed in enterprise WANs where branch offices frequently exchange data with each other, such as in retail chains, financial institutions, and multinational corporations. It reduces latency and bandwidth consumption on the hub router, as traffic does not need to hairpin through it. However, it requires that all spoke routers have unique, routable public IP addresses (or that NAT traversal is properly configured with IPsec). It also demands careful routing design to prevent routing loops or suboptimal path selection.
Real-Life Example
Think of a large office building with a central security desk on the ground floor and many departments on different floors. In the old system (DMVPN Phase 1), if an employee in the accounting department on floor 5 needed to give a document to someone in marketing on floor 10, they would first walk down to the security desk, give the document to the guard, and then the guard would walk it up to marketing. This is slow and makes the security desk a bottleneck.
Now, imagine DMVPN Phase 2. The security desk still knows where every department is located. When the accounting employee wants to send a document to marketing, they call the security desk and ask, “Where is the marketing department?” The guard replies, “Marketing is on floor 10, room 1002.” Now, the accounting employee takes the elevator directly to floor 10 and hands the document to marketing. They don’t need the guard to carry it. The guard only helps with the initial lookup.
In this analogy, the security desk is the hub router. The employees are spoke routers. The building directory (NHRP) tells the spokes where other spokes are located. The direct elevator ride is the temporary IPsec tunnel between spokes. The document is the data being transferred. The security desk is still there for initial introductions but is no longer involved in every single document delivery. This makes deliveries faster and reduces the workload on the security desk.
If a new department (a new spoke) joins the building, the security desk adds it to the directory. Other departments can then find it instantly without needing to know its physical location beforehand. In the same way, DMVPN Phase 2 allows new branch offices to join the network and immediately be reachable by other branches, as long as the hub has their registration information. The system scales gracefully because the hub only handles control traffic (lookups) and routing updates, not the actual data traffic between spokes.
Why This Term Matters
DMVPN Phase 2 matters in real IT work because it solves a fundamental problem in wide-area networking: how to connect many branch offices efficiently without overloading the central hub router. In traditional hub-and-spoke VPN designs, all traffic between branches must pass through the hub, which doubles the bandwidth needed on the hub link and adds latency. For example, if a company has 500 branch offices and each branch regularly sends large files to other branches, the hub router can become a serious bottleneck, leading to slow performance and costly network upgrades.
By enabling spoke-to-spoke tunnels, DMVPN Phase 2 reduces the burden on the hub router and the hub site’s internet connection. The hub only handles control communications like NHRP queries and routing updates, which are small and infrequent compared to bulk data transfers. This means a company can support more branches without buying more expensive hardware for the central site. It also improves user experience because direct communication between branches has lower latency, which is critical for real-time applications like voice over IP (VoIP), video conferencing, and collaborative tools.
From a security perspective, all spoke-to-spoke tunnels are encrypted using IPsec, so data remains secure even though it is not passing through the central hub. This matters for compliance with regulations like GDPR, HIPAA, or PCI DSS, where data in transit must be protected. The dynamic nature of the tunnels means that the network adapts automatically; if a branch office’s public IP address changes due to a DHCP renewal or a new internet provider, the NHRP registration updates the hub, and other spokes can still reach it without manual reconfiguration.
For network administrators, DMVPN Phase 2 simplifies the configuration of large VPN deployments. Instead of manually configuring a full mesh of static tunnels between every pair of branches (which would require n*(n-1)/2 tunnels), they simply configure each spoke with a single tunnel interface pointing to the hub. The network builds the direct tunnels on demand. This reduces human error and makes it easier to add or remove branch offices. Troubleshooting is also more straightforward because the hub maintains an NHRP database that shows which spokes are registered and what their current IP addresses are.
How It Appears in Exam Questions
In the ENARSI exam, DMVPN Phase 2 appears in several distinct question formats. The most common is the multiple-choice scenario question. For example, a question might describe a company with a hub router in New York and 50 spoke routers in various cities. The spokes need to communicate directly for voice traffic. The question then asks: “Which DMVPN phase should be configured to minimize latency and hub CPU utilization while allowing direct spoke-to-spoke communication?” The correct answer would be DMVPN Phase 2. Distractors could include Phase 1 (hub-and-spoke only) or Phase 3 (which adds route summarization and more complex NHRP).
Another common question type is the configuration-based multiple-choice question. A topology diagram might show two spokes, and a partial configuration for the hub is provided. The candidate must identify which additional configuration is needed to enable Phase 2 behaviour. The correct answer might be to remove the “next-hop-self” command under the routing process on the hub, or to ensure that the IPsec profile is applied to the mGRE tunnel interface. Wrong answers could involve adding a static route or disabling NHRP.
Troubleshooting questions are also very common. A candidate might be given the output from “show dmvpn” or “show ip nhrp” on a spoke router, and the output shows that the NHRP mapping for a remote spoke is incomplete or that the tunnel is in an “up/down” state. The question asks: “What is the most likely cause?” Answers could include that the hub does not have the NHRP registration for the remote spoke, that IPsec is not correctly configured, or that the routing protocol is not advertising the spoke’s LAN subnet.
Architecture and design questions are also frequent. For instance, a question might ask: “A network engineer is designing a DMVPN network with 200 spokes. The business requirement is that all spokes must be able to communicate directly. The hub router uses a dual-core processor and has limited memory. Which DMVPN phase and routing protocol configuration will best meet these requirements?” The candidate must select Phase 2 and a configuration that disables next-hop-self on the hub.
Finally, there are simulation-based questions (in the actual exam lab) where the candidate must configure a DMVPN Phase 2 network from scratch or modify an existing configuration to add a new spoke or to enable direct tunnels. These simulations test hands-on skills, including mGRE configuration, NHRP settings, IPsec policy creation, and routing protocol manipulation.
Study enarsi
Test your understanding with exam-style practice questions.
Example Scenario
Consider a multinational retail chain called GlobalMart. GlobalMart has a central data center (the hub) and 200 retail stores (the spokes) across three continents. Each store has a point-of-sale system that needs to communicate with the inventory database at the data center, but stores also need to transfer daily sales reports directly to each other for regional consolidation. In this scenario, DMVPN Phase 2 is the ideal solution.
The situation: A store in Paris needs to send its sales data to a store in Berlin every evening. In a Phase 1 design, the Paris store would encrypt the data and send it to the data center in New York, where the hub router would decrypt it, then re-encrypt it and send it to Berlin. This doubles the bandwidth used on the data center link and adds 100 milliseconds of latency due to the extra hop.
With DMVPN Phase 2, the configuration is set up so that when the Paris router sees a route to the Berlin store’s LAN, the next-hop IP is Berlin’s tunnel IP. The Paris router sends an NHRP resolution request to the hub, which responds with Berlin’s public IP address. Paris now builds a direct IPsec tunnel to Berlin. The sales data travels directly from Paris to Berlin—a much shorter path with lower latency.
This scenario demonstrates why Phase 2 is chosen: it reduces load on the hub, improves data transfer speed, and makes the network more resilient. If the data center link fails, the Paris and Berlin stores can still communicate directly, as long as they have internet connectivity. The hub remains critical for initial lookups and routing updates, but it no longer dictates the performance of every inter-spoke conversation.
Common Mistakes
Thinking that DMVPN Phase 2 requires a full mesh of static tunnels between all spokes.
Phase 2 uses dynamic, on-demand spoke-to-spoke tunnels built via NHRP. There is no need to manually configure tunnels between each pair of spokes, which would be impractical for large networks.
Understand that only the hub requires a static mGRE configuration. Spokes are configured to point to the hub, and direct tunnels are created automatically when needed.
Enabling next-hop-self under the routing protocol on the hub router.
In Phase 2, the hub must advertise routes from one spoke to another with the original next-hop set to the remote spoke’s tunnel IP. If next-hop-self is used, the next-hop becomes the hub’s tunnel IP, preventing the spoke from initiating a direct tunnel.
Ensure that the routing protocol on the hub does not change the next-hop for routes learned from spokes. Use the “no next-hop-self” command under the routing process, or in EIGRP, use “no ip next-hop-self eigrp” on the tunnel interface.
Assuming that DMVPN Phase 2 works without a dynamic routing protocol like EIGRP or OSPF.
While NHRP provides the mapping between tunnel IP and public IP, the routing protocol is essential for distributing the LAN subnets of each spoke across the network. Without routing updates, a spoke will not have a route to another spoke’s LAN, so no traffic is triggered to build the direct tunnel.
Always configure a dynamic routing protocol (EIGRP, OSPF, or BGP) over the mGRE tunnel interface. The hub must redistribute and propagate spoke routes so that all spokes learn about each other’s networks.
Configuring the spoke’s tunnel interface with a destination address pointing directly to another spoke instead of the hub.
In DMVPN, spokes should only point to the hub as their tunnel destination. The spoke does not know the public IP of other spokes until it receives NHRP resolution from the hub. Setting a static destination to another spoke defeats the dynamic discovery purpose and may cause routing issues.
On each spoke router, configure the tunnel destination to be the public IP address of the hub only. The mGRE interface on the spoke can accept multiple connections but will initiate a tunnel to other spokes only after NHRP resolution.
Forgetting to configure IPsec on the mGRE tunnel interface or using a crypto map incorrectly.
Without IPsec, the data sent over the direct spoke-to-spoke tunnels is not encrypted, exposing sensitive corporate traffic to interception. In Cisco DMVPN, IPsec is required for secure communication, and the configuration must be applied to the tunnel interface or through a tunnel protection profile.
Use the “tunnel protection ipsec profile [profile-name]” command under the tunnel interface on both the hub and spokes. Ensure the IPsec profile includes the correct encryption and authentication transforms, and that the pre-shared key or certificate-based authentication is properly configured.
Exam Trap — Don't Get Fooled
In a DMVPN Phase 2 exam question, the scenario describes a network where spoke routers are able to ping each other’s tunnel IP addresses, but cannot reach the LAN subnets behind the remote spoke. The candidate is asked why. Remember that a successful ping to a remote spoke’s tunnel IP only proves that the mGRE and IPsec tunnel is functioning between those two spoke routers.
It does not confirm that the remote spoke’s LAN subnet is known. Always check the routing table on the local spoke to see if the remote LAN subnet is present and what its next-hop is. If the next-hop is the hub’s tunnel IP (10.
0.0.1) instead of the remote spoke’s tunnel IP (10.0.0.2), then Phase 2 is not working correctly. The fix is to disable next-hop-self on the hub. Also verify that the routing protocol is configured to exchange LAN subnets—for example, using network statements or redistribution.
Commonly Confused With
DMVPN Phase 1 does not allow spoke-to-spoke direct tunnels. All traffic between spokes must go through the hub router. Phase 1 is simpler but less efficient because the hub becomes a bottleneck. Phase 2 is specifically designed to allow spokes to communicate directly, reducing hub load and improving performance.
In Phase 1, a branch in Paris sends data to a branch in Berlin, but it must travel through the hub in New York. In Phase 2, Paris sends directly to Berlin after asking the hub for Berlin’s address.
Phase 3 adds “NHRP redirect” and “routing summarization” capabilities. In Phase 3, the hub can advertise a summary route for all spoke LANs, and when traffic matches that summary, the hub sends an NHRP redirect to tell the spoke to build a direct tunnel to the destination. Phase 3 reduces the number of routes in the routing table, which is beneficial for very large networks with thousands of spokes.
With Phase 2, every spoke must have a route to every other spoke’s LAN. With Phase 3, the hub advertises a single summary route, and only when a spoke sends traffic to a specific remote LAN does the hub redirect it to build a direct tunnel.
A traditional site-to-site IPsec VPN requires a static configuration for each pair of sites. If you add a new site, you must update the configuration on every existing site that needs to communicate with it. DMVPN Phase 2 automates this process with NHRP, so adding a new spoke only requires configuration on the new spoke and the hub. The other spokes learn about it automatically via the routing protocol and NHRP.
With traditional IPsec, connecting 10 branch offices in a full mesh would require 45 manually configured tunnels. With DMVPN Phase 2, you configure each branch to point to the hub, and the network builds tunnels dynamically when needed.
Step-by-Step Breakdown
Spoke Registration with the Hub
When a spoke router comes online, it sends an NHRP registration request to the hub. The registration includes the spoke’s tunnel IP address and its physical (public) IP address. The hub stores this mapping in its NHRP database. This step is essential because it allows the hub to act as a directory for all spokes.
Routing Protocol Exchange
The hub and spokes run a dynamic routing protocol (such as EIGRP or OSPF) over the mGRE tunnel. The hub collects routes to each spoke’s internal LAN subnet. It then advertises these routes to all other spokes, but crucially, in Phase 2, the hub does not change the next-hop attribute. The next-hop for a remote spoke’s LAN is set to the tunnel IP of that remote spoke.
Traffic Trigger and Route Lookup
When a spoke has data to send to a LAN subnet behind another spoke, it consults its routing table. It sees the destination network with a next-hop pointing to the remote spoke’s tunnel IP. The spoke then knows it must reach that tunnel IP to deliver the data.
NHRP Resolution Request
The local spoke does not yet have a mapping for the remote spoke’s tunnel IP to a public IP. It sends an NHRP resolution request to the hub, asking: “What is the public IP address of the spoke with tunnel IP X?” The hub replies with the public IP address of the destination spoke, including any necessary NAT information.
Dynamic IPsec Tunnel Establishment
Using the public IP address received from the hub, the local spoke initiates an IPsec session directly to the destination spoke. This involves IKE phase 1 (establishing a secure management channel) and IKE phase 2 (negotiating IPsec security associations for data encryption). Once the IPsec tunnel is established, the two spokes can exchange encrypted data directly.
Data Transfer and Tunnel Teardown
The two spokes now communicate directly using the encrypted tunnel. The hub is no longer involved in forwarding data. After a period of inactivity (configurable), the IPsec tunnel is torn down to conserve resources. If new traffic arises later, the NHRP mapping is typically cached, so the resolution step may not be needed again unless the mapping expires or the spoke’s IP address changes.
Practical Mini-Lesson
To understand DMVPN Phase 2 in a practical sense, you must grasp how it integrates NHRP, mGRE, IPsec, and a dynamic routing protocol. Let’s walk through a real deployment. Imagine you are a network engineer at a mid-sized company with headquarters in London and 30 branch offices across Europe. You need a WAN solution that is secure, scalable, and efficient.
First, you choose DMVPN Phase 2 because you know that branch offices frequently exchange large files and voice traffic with each other, and you want to avoid overloading the London hub. You begin by configuring the hub router. You create a tunnel interface with an IP address from a private range, say 10.0.0.1/24. You set the tunnel mode to mGRE (multipoint GRE) so that multiple spokes can connect to the same interface. You apply an IPsec profile under the tunnel interface using the command “tunnel protection ipsec profile DMVPN-PROFILE”. You then configure the NHRP settings: the hub acts as an NHRP server with authentication (a shared password) and a hold-time of 600 seconds.
Next, you configure the routing protocol, EIGRP, on the tunnel interface. You carefully do not enable next-hop-self under EIGRP; instead, you ensure that routes learned from one spoke are passed to other spokes with the original next-hop. In EIGRP, this is achieved by not using the “no ip next-hop-self eigrp” command (which actually disables the default behaviour; in earlier IOS versions, you need to manually configure “no ip next-hop-self eigrp” on the tunnel interface to prevent the hub from setting itself as the next-hop).
Each spoke router is configured similarly: a tunnel interface with an IP from the same subnet (e.g., 10.0.0.2), but the tunnel destination is set to the public IP of the hub. The spoke also registers with the hub via NHRP and uses EIGRP to advertise its local LAN subnet. The spoke’s tunnel interface uses the same IPsec profile.
Now, the magic happens. When a branch in Paris (10.0.0.2) needs to send data to a branch in Berlin (10.0.0.3), the Paris router looks up the destination LAN in its routing table. It sees a route via next-hop 10.0.0.3. Because it has no NHRP mapping for 10.0.0.3, it sends a resolution request to the hub. The hub replies: “10.0.0.3 is at public IP 203.0.113.5.” Paris then initiates an IPsec tunnel directly to 203.0.113.5. Once established, data flows directly, bypassing London.
What can go wrong? The most common issue is the next-hop-self problem. If the hub changes the next-hop, Paris will see the route with next-hop 10.0.0.1 (the hub), so it will try to send the traffic through the hub or to itself, never building a direct tunnel. Another issue is NAT: if the Berlin spoke is behind a NAT router, the public IP that Paris sees may not be reachable unless NAT-T is enabled and the hub knows the translated address. Also, if the routing protocol does not advertise the LAN subnets (e.g., because of passive interfaces or wrong network statements), the Paris router will have no route at all.
For exam success, practice the configuration on a lab simulator. Focus on the relationship between NHRP and routing. Remember that Phase 2 is about the next-hop being the remote spoke, not the hub. Once you master that, you can troubleshoot and design Phase 2 networks confidently.
Memory Tip
Phase 2: The spoke-to-spoke shortcut. Remember that the hub is the phone book, not the messenger. The routing next-hop must point to the remote spoke, not the hub.
Covered in These Exams
Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
Frequently Asked Questions
What is the difference between DMVPN Phase 1 and Phase 2?
Phase 1 only allows spoke-to-hub communication; all spoke-to-spoke traffic must go through the hub. Phase 2 allows spokes to build direct tunnels between each other, reducing latency and hub load. Phase 2 requires the hub to not change the next-hop in routing updates.
Can DMVPN Phase 2 work without a routing protocol?
No, a dynamic routing protocol like EIGRP, OSPF, or BGP is essential. It distributes the LAN subnets of each spoke so that other spokes know how to reach them. Without routes, no traffic is sent to trigger the direct tunnel.
Do all spokes need a public IP address for DMVPN Phase 2?
Not necessarily, but they must be reachable from other spokes. If a spoke is behind NAT, you must configure IPsec NAT-Traversal (NAT-T) and ensure the hub knows the translated public IP. Otherwise, direct tunnels may fail.
How does NHRP work in DMVPN Phase 2?
NHRP acts as a directory service. Each spoke registers its tunnel IP and public IP with the hub. When a spoke needs to reach another spoke, it queries the hub for the destination’s public IP. The hub responds with the mapping, allowing the direct tunnel to be built.
What is the role of the hub in DMVPN Phase 2?
The hub handles control plane tasks: it maintains the NHRP database, answers resolution requests, and routes routing updates. It does not forward data between spokes once direct tunnels are established. This offloads data traffic from the hub.
Can I mix DMVPN Phase 1 and Phase 2 spokes in the same network?
Yes, it is possible but not recommended for simplicity. Phase 1 spokes cannot build direct tunnels; they will always send traffic through the hub. Phase 2 spokes will be able to talk directly to other Phase 2 spokes, but traffic between a Phase 2 spoke and a Phase 1 spoke will still go through the hub.
What command disables next-hop-self on the hub for DMVPN Phase 2?
For EIGRP, use “no ip next-hop-self eigrp 100” under the tunnel interface. For OSPF, you do not need to disable next-hop-self because OSPF does not change the next-hop by default on point-to-multipoint networks. For BGP, use “no next-hop-self” under the address-family.
How does DMVPN Phase 2 handle IPsec encryption for spoke-to-spoke tunnels?
Each spoke-to-spoke tunnel negotiates its own IPsec security associations dynamically. The IPsec profile configured on the mGRE tunnel interface provides the encryption and authentication settings. The IKE and IPsec parameters are agreed upon during the tunnel establishment.
Summary
DMVPN Phase 2 is a powerful Cisco technology that enables direct, secure, and dynamic communication between branch office routers, bypassing the central hub for data traffic. It combines NHRP as a directory service, mGRE for flexible tunnel encapsulation, IPsec for encryption, and a dynamic routing protocol to propagate routes. The key differentiator from Phase 1 is that the routing protocol on the hub does not overwrite the next-hop, allowing spokes to learn the tunnel IP of other spokes and build direct IPsec tunnels on demand. This reduces latency, conserves hub resources, and scales well for large enterprise networks with many branch offices.
For your ENARSI exam, remember the critical configuration details: the hub must not use next-hop-self, each spoke must register with the hub via NHRP, and the mGRE tunnel interface must be paired with an IPsec profile. Common mistakes include misconfigured next-hop, omitted routing protocol, and incorrect tunnel destination settings. Use the memory hook that the hub is the phone book, not the messenger. Mastering DMVPN Phase 2 will not only help you pass the exam but also prepare you for real-world WAN design and troubleshooting tasks.