DMVPN

First off, what is DMVPN (Dynamic multipoint virtual private network)?  Well, it is essentially a point-to-multipoint overlay VPN tunneling technology.  In addition, it is a scalable and dynamic way of building GRE over IPSec site-to-site tunnels.  It is an IP packet encrypted with IPSec, with a GRE tunnel inside of that. Because of GRE, we are able to run dynamic routing protocols (OSPF, EIGRP, BGP, etc).

• Because DMVPN uses IP transport, any internet connectivity will work...be it a T1, DS3, cable, ethernet, etc.

• Unlike some of the underlying layer 2 tunnel protocols, like frame relay or ATM, DMVPN is built on an overlay VPN tunnels.  The spokes build a tunnel to the hub, and the hub will have a multipoint tunnel back to the spokes.

• Now what makes DMVPN truly dynamic is the ability to create on demand tunnels.  If using at least phase 2, if spoke A wants to talk to spoke B, a dynamic tunnel is built between the two.  We'll talk about the differences between the phases later on.  Furthermore, unlike IPSEC, where if you had 10 sites you would need 10 crypto maps...no change is required on the head-in for DMVPN.  Lastly, the configuration the spokes is stupid easy and templates can be made.

• When to scale?  
• IPSEC: It honestly comes down to the number of endpoints.  Should spoke A want to talk to a new site B..then A must be re-configured to be able to talk to site B.  As the number of sites grow, management of the spokes can become a nightmare!  Orinally, static IPSec tunnels did not support multicast.  To overcome this, you would run a GRE tunnel between the sites.  Furthermore, you put the GRE tunnels inside an IPSEC tunnel.  That is basically what DMVPN does..but it is dynamically with the control-plane protocol NHRP (which will be discussed later).
• Layer 3 MPLS: This first off creates routing complexity.  Most of the time, you're going to need a routing protocol (typically BGP) between you and the ISP.  With that, redistribution and various other technologies can over-complicate the design.  Also MPLS might not support IPV6 of IPV4 and/or multicast.  Next, inter-ISP operability may be an issue.  Should you need two sites to talk where any single ISP is unavailable...you might have issues.

• Traffic Routing:
• Multipoint GRE (mGRE):
• Next Hop Resolution Protocol (NHRP): Mapping between the NBMA (public) address and the private address.
• DMVPN Hub/NHRP server
• DMVPN spokes/NHRP clients

• Traffic Encryption:
• IPSec:

(NHRP):

"Partially meshed NBMA networks typically have multiple logical networks behind the NBMA network. In such configurations, packets traversing the NBMA network might have to make several hops over the NBMA network before arriving at the exit router (the router nearest the destination network). With NHRP and when NHRP is combined with IPsec, the NBMA network is basically a collection of point-to-point logical tunnel links over a physical IP network. This is also true of virtual tunnel networks, for example, generic routing encapsulation (GRE) tunnels. In order for a router to scale the connectivity of this collection of point-to-point links, the links are usually grouped into a single- or multilayer hub-and-spoke network. Multipoint interfaces (GRE tunnel interfaces in this case) can be used to reduce the configuration on a hub router in such a network. This resulting network is an NBMA network.

NHRP is an ARP-like protocol that alleviates these NBMA network problems. With NHRP, systems attached to an NBMA network dynamically learn the NBMA address of the other systems that are part of that network, allowing these systems to directly communicate without requiring traffic to use an intermediate hop."

"NHRP is the catalyst which facilitates dynamic tunnel establishment, providing tunnel-to-physical interface address resolution. NHRP clients (spoke routers) issue requests to the next hop server (hub router) to obtain the physical address of another spoke router."
"Routers, access servers, and hosts can use the NHRP to discover the addresses of other routers and hosts connected to an NBMA network."

DMVPN Phases:

Phase 1: Hub-and-spoke; all traffic traverses the hub router to get to each spoke.
Phase 2: Spokes dynamically build tunnels to communicate.  Each spoke needs a route for every possible spoke.
Phase 3: Same as phase two, but we use summarization.


Note: The head-in device does not need to explicitly define destination IPs.  This is because multipoint tunnels are built dynamically from the DMVPN spokes to the hub router; the hub router doesn't need to be preconfigured with spoke addresses.

Head-in configurations:
ip nhrp authentication <key> <--Must match or tunnel won't come up
ip nhrp map multicast dynamic <---Forwards multicast traffic (required for most routing protocols)
ip nhrp network-id <id> <--Must match or tunnel won't come up
ip nhrp redirect <--For DMVPN phase 3: Tells spoke that it can communicate directly with another spoke
tunnel source <IP> or <interface>
tunnel mode gre multipoint
tunnel key <key> <--Must match or tunnel won't come up
tunnel protection ipsec profile <cyrpto profile> shared <--IPsec protection policy to the tunnel interface

*********************************************************************************

Spoke configurations:
ip nhrp authentication <key> <--Must match or tunnel won't come up
ip nhrp map multicast dynamic <---Multicast traffic is only being allowed from spokes to the hub, not from spoke to spoke.
ip nhrp network-id <id> <--Must match or tunnel won't come up
ip nhrp shortcut <--For DMVPN phase 3:  Responsible for rewriting the CEF entry after getting the redirect message from hub.
ip nhrp nhs <IP address>   <--NHS address of head-in device
ip nhrp map <NHS address> <physical address>  <--Mapping of the head-in NHS address to the physical address
tunnel protection ipsec profile <cyrpto profile> shared  <--IPsec protection policy to the tunnel interface

Notes for EIGRP:
Phase 1:

• Summarization/default routing possible!
• Must disable split-horizon UNLESS we use summarization.

Phase 2:

• Summarization/default routing NOT possible!   Next-hop would point towards the hub, and we would not be able to perform the dynamic spoke-to-spoke tunnels.  Route next-hop MUST point to the spoke tunnel interface, NOT the hub's tunnel interface.
• Must disable split-horizon.
• Must configure "no ip next-hop-self eigrp 1" -- Otherwise, the next-hop would be that of the hub, not the tunnel IP address of the individual spokes.

Phase 3:

• Summarization/default routing possible!
• Disable split-horizon!
• Remove "no ip next-hop-self eigrp 1" .. This is NOT needed for phase 3.  
• NHRP overrides RIB (Compare against FIB--CEF table).  You will see that route still points to hub, while FIB points to destination spoke tunnel IP.

Notes for OSPF:
Phase 1:

• Summarization/default routing possible!
• Point-to-multipoint possible.

Phase 2:

• Summarization/default routing NOT possible!   Next-hop would point towards the hub, and we would not be able to perform the dynamic spoke-to-spoke tunnels.  Route next-hop MUST point to the spoke tunnel interface, NOT the hub's tunnel interface.
• CANNOT use point-to-multipoint (next-hop is hub).
• MUST run broadcast/non-broadcast with the HUB as the DR.  

Phase 3:

• Summarization/default routing possible!
• Can run point-to-multipoint, as next hop does not directly relate to the route.  
• NHRP overrides RIB (Compare against FIB--CEF table).  You will see that route still points to hub, while FIB points to destination spoke tunnel IP.

Notes for BGP:

• HUB can be route-reflector.
• Static neighbor statements would be a P.I.T.A.----so on HUB you can configure BGP dynamic neighbors.