DMVPN – Theory, explanations, and illustrations! (Lab coming up next post)

So I have not been posting over the weekend, however I haven’t been slacking either. What I am going to post today is going to be a mixture of information from Chris Bryant’s 8 minute DMVPN video, and the few parts I watched from the 8 hours of INE CCNP DMVPN training.

INE really goes over the entire history of it, which I do intend to do as well, but right now I need to finish one study material first (Bryant) before filling the gaps.

So because my next topic was also very briefly covered (VRF) and I am doing a “wr er” and “reload” on all routers to demonstrate that topic, I will see if I can follow this up with a DMVPN configuration lab tomorrow although I have not gotten the formal training, so it will be off the cuff as they say (whoever they are).

All that being said, lets get into the theory of DMVPN

As can be seen in the upper left-hand corner of the Topology, they Physical and Tunnel addresses are listed for this network, also known as the Overlay and Underlay addresses.

• Underlay addresses are the IP’s of the physical interfaces of our tunnel addresses
• Overlay addresses will be the Tunnel’s endpoint IP addresses to Physical IP’s

So that is why I explained it as that right off the bat, so that terminology starts to sink in, the actual network address are the underlay our foundation that the Overlay or tunnel uses to do what it does.

Now, IPSec has one glaring gap in functionality and that is being able to encapsulate multicast packets, which GRE can do, then IPSec re-encapsulates them to encrypt the data and allow for the DMVPN to be not only dynamic but secure.

Speaking of things to start soaking in, there are a couple of key things that I’d like to point out before going deeper into theory, and firstly that DMVPN only needs two protocols technically to run : mGRE and NHRP. Although the tunnels will have no encryption due to IPSec missing from the configuration, which is basically in this day and age ‘required’, it actually isn’t and you need to know that.

So this is what a DMVPN topology model might look like, fully captioned for you:

As shown again in the above Topology, it works based off a Client / Server model, where the Spokes of our Hub-and-Spoke Topology is are the NHRP Client or NHC’s, and the Hub is the NHRP Server or NHC. The Hub also has the Multipoint GRE interface that will be managing tunnel information to its clients.

So you will want to configure the Hub first with both mGRE and NHRP configurations, so when NHRP / Tunnel configs are entered on Spoke routers, the NHC’s will advertise their Overlay / Underlay mapping to the Hub / NHS to put in it’s Database for queries by other DMVPN routers. The Hub should have mGRE running on it’s main outside interface, which will allow the transmission of these Overlay to Underlay mappings.

Speaking of mappings, this is where NHRP comes in, as it creates these overlay to underlay mappings to make the dynamic nature of these VPN’s possible for the NHS to share with it’s NHC’s.

So when the initial configuration is pumped in, this is what it should logically do:

So when R2 wants to build a Dynamic tunnel over to R3, it can query the NHS:

And now that R2 has the Physical IP to R3, it doesn’t need the Hub to reach it for a VPN:

Now, I am skeptical as to how this is going to work, as I will be trying my hand to configure this over a frame switch. However, I will google some commands and we will be taking a deeper dive that just the very top level Fundamentals (and maybe a deep dive down the road), however I need to keep pushing forward with studying new topics cause I tend to get stuck in quicksand topics that I spend forever trying to dig to the bottom of.

VRF and VRF Lite were also very lightly explained so that lends me some time this week to try my hand at a free style DMVPN config tomorrow, and that it is on to the kryptonite of Cisco material for me : IPv6.

I am hoping it isn’t going to be a lot of memorization as it was at the CCNA level, and we can do some labs with it, but we shall see. So I will set my routers R1, R2, and R3 up only for the next lab and we shall see what happens, hope to see you there! 🙂