DMVPN 101
DMVPN
DMVPN – Dynamic Multipoint VPN is a technology that uses IPSec, mGRE and NHRP to provide a dynamic VPN infrastructure.
DMVPN evolved in several phases as follows:
DMVPN phase 1: Hub and Spoke – spokes only communicate via Hub
DMVPN phase 2: Hub and spoke with spoke to spoke tunnels – spokes can create tunnels between themselves, but the hub is used to provide information on how to reach the spokes
DMVPN phase 3: Hub and spoke with spoke to spoke tunnels – spokes can also provide reachability information so the role of the hub is reduced.
GRE and NHRP
mGRE (multipoint GRE) generalizes the GRE concept by allowing multiple, dynamic GRE tunnels initiated from a single device. NHRP (Next Hop Resolution Protocol) is used to resolvee L3 to L2 address mapping in NBMA environments (like DMVPN or Frame Relay) NHRP operates by using servers (NHS) and clients (NHC). A client needs to register with at least one server, and the servers collect client addressing information in order to provide it to other clients when requested. A server can query another server if it’s missing information requested by clients.
Enable mGRE
The NBMA address of the node will be the IP address of the tunnel source. When using EIGRP or RIP, split horizon should be disabled on the hub tunnel interface.
Enable NHRP
Building the NHRP cache – mapping addresses
Static mapping
Static mapping is required on the spokes to intiate the connection to the server. To map multicast traffic to a destination, use:
This is normally configured on the spokes, pointing to the hub and is required for some IGPs to work. (similar to Frame Relay’s broadcast mapping).
Dynamic mapping
An NHRP interface works both as server and client. A server can also have another server configured and it can forward requests to it’s known servers when it doesn’t have the complete mapping. The clients need to have the server destination configured:
Clients and servers can use an authentication key between them to prevent unwanted connections:
A client sends a registration request to the server which includes it’s Tunnel interface address and it’s NBMA interface (physical) address. The server will create an entry in it’s NHRP cache and can use it to reply to other NHRP clients. To send multicast traffic to the spokes, the hub should also have this configured:
The hub can’t intitate connections to the spokes until they register, because it does’t know how to reach them.
Check mapping
To verify the NHRP cache, use:
The cache entries have some flags associated to them, which can be:
authoritative = This entry was learned from the next hop server.
registered = This entry was learned by the server from one of it’s clients.
implicit = learned not from an NHRP request generated from the local router, but from an NHRP packet being forwarded or from an NHRP request being received by the local router
unique = If a client wants to register another entry which is already in the cache with this flag set, it will be rejected. Normally, all routers register their addresses with the “unique” flag. This can be disabled with:
used = This entry is used to switch traffic. See DMVPN Phase 2.
IPSec protection
mGRE and NHRP can create a functional NBMA network, but the security is lacking, especially since this is used over a public/ISP interface. To easy deployment, the IPSec profile protection should be enabled. To do this, use:
The IPSEC-PROFILE is similar to an IPSEC-CRYPRO-MAP, but it lacks peer information and ACL to match interesting traffic. These will be derived from the mGRE configuration and the NHRP cache. See IPSEC article for details.
DMVPN Phases
Phase 1
Phase 1 uses static GRE tunnels on the spokes and a mGRE tunnel on the hub. It’s easy to configure but communication between spokes must go through the hub. RIP, EIGRP or OSPF can be used over DMVPN Phase 1.
Phase 2
Phase 2 uses mGRE tunnels on spokes as well, allowing the creation of tunnels between spokes. EIGRP can be used over DMVPN phase 2, but the hub must not set itself as the next-hop, so the routers can intitiate the NHRP resolution and the creation of the mGRE tunnels. OSFP with broadcast network type can also be used.
To resolve the adjacency, CEF marks the tunnel destination as “glean” – meaning it will request NHRP data when traffic needs to be forwarded over that interface. When CEF is enabled, as long as traffic is sent to a node (which means a specific CEF entry is used), that entry doesn’t timeout. When the timer is less than 120 seconds, the CEF entry is marked as stale. If a new packet is switched over the stale entry, a new NHRP request is sent and the entry is refreshed. If no packet is switchd until the timer expires, the CEF entry times out becomes invalid. When CEF is not used, the entries expire based on the “used” flag associated with the map entries. When there’s no more traffic using that entry, it will timeout.
Phase 3
The additions in phase 3 are that once the network is setup, CEF entries point to the hub address. When traffic reaches the hub, but is destined for another spoke, it sends a NHRP redirect which triggers a new NHRP request from the source spoke to the destination spoke. This request travels via the hub, but the reply is direct and foreces a rewrite of the CEF entry with the new spoke information. This operation is called a NHRP shortcut. To enable Phase 3, you should use the following commands:
Last updated