December 2012 | Reading Time: 8 mins
Dynamic Multipoint VPN (DMVPN) has become a powerful WAN architecture choice for scalable and secure enterprise connectivity. While Phase 1 and Phase 3 offer their own use cases, Phase 2 strikes a balance between simplicity and flexibility, especially in deployments where full-mesh communication is desirable but control and predictability are still required. At the heart of this topology lies the Next Hop Resolution Protocol (NHRP), which enables the discovery and dynamic mapping of peers over an NBMA (Non-Broadcast Multi-Access) network.
DMVPN Phase 2 Overview
In Phase 2, spoke-to-spoke tunnels are dynamically formed after initial routing information is exchanged through the hub. The hub advertises routes from other spokes, but then steps aside once communication begins directly between spokes. This reduces unnecessary traffic through the hub and optimizes performance.
However, this also introduces complexity. Routing must be carefully configured to avoid routing loops and ensure the NHRP mappings resolve correctly. Split-horizon filtering and NHRP redirection play key roles in this process.
Configuring the Hub
The hub acts as the NHRP server and routing reflector. Let’s break down a minimal configuration for a Cisco IOS router acting as the DMVPN hub:
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source Ethernet0
tunnel mode gre multipoint
tunnel key 123
Key points to note:
- ip nhrp map multicast dynamic enables the dynamic mapping of multicast traffic, which is essential for routing protocol adjacencies (like EIGRP or OSPF).
- tunnel mode gre multipoint allows multiple endpoints to connect without defining static GRE peers.
- tunnel key helps distinguish tunnels in multi-tenant scenarios.
Configuring Spokes
Each spoke needs to register with the hub and should be ready to form direct tunnels with peers. Here’s a basic spoke configuration:
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
ip nhrp map 10.0.0.1 192.0.2.1
ip nhrp map multicast 192.0.2.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
tunnel source Ethernet0
tunnel mode gre multipoint
tunnel key 123
Routing Considerations
For Phase 2 to work correctly, routing must advertise the real IP addresses of the remote spokes, not the hub’s. This ensures that once NHRP resolves the tunnel destination, traffic bypasses the hub. If EIGRP is used:
router eigrp 100
network 10.0.0.0
no auto-summary
On the hub, remember to disable split horizon on the tunnel interface:
interface Tunnel0
no ip split-horizon eigrp 100
This is essential so that the hub can advertise one spoke’s route to another.
Troubleshooting NHRP
NHRP issues can prevent spokes from resolving tunnel endpoints. Use the following commands to diagnose:
show ip nhrp– Verifies NHRP registration and mapping.debug nhrp– Monitors NHRP packets and responses.show dmvpn– Displays DMVPN tunnel status and peerings.
Check that the hub is responding to NHRP requests and that spoke IPs are reachable.
Common Pitfalls
- Using incorrect tunnel keys across devices
- Forgetting to disable split horizon on the hub
- Omitting the NHS (Next Hop Server) configuration on spokes
- Not advertising the correct IPs into routing
Conclusion
DMVPN Phase 2 with NHRP offers a powerful way to optimize dynamic peer-to-peer connectivity across enterprise WANs. Proper configuration of the hub, spokes, and routing is critical to ensure performance and reliability. While Phase 3 later introduced dynamic routing with route summarization, Phase 2 remains a widely adopted and stable solution, particularly when topology stability and control are desired.
No comments:
Post a Comment