DMVPN Part 2

The other night I did the first video on YouTube from INE dealing with DMVPN.  This morning I did the second video.  While the first video was more about the phase 1 setup and theory behind this technology, video 2 was how to build upon that and make it dynamic and encrypted.  These two videos are not going to make anyone an expert on DMVPN but they will help someone, such as myself, who is clueless about it that has never seen nor used the technology.  Well on to the fun stuff.

These two videos are done using EIGRP as the internal routing protocol.  Two reasons in my book for this.  One that is what Cisco used in their configuration and two is that this protocol has some pitfalls and examples that make it great for the show case of the different phases.  First things first.  All traffic goes in and out of one tunnel when looking at the config and routing table.  So each spoke will not get the routing updates for another spoke from the hub because of that great and pain in the butt technology that is split horizon (it is a pain in the butt at 0300 in the morning when you are troubleshooting why something won't work or in the 11th hour of the IE test and you can't get routes to show up).  Turn that off on the hub's tunnel interface.  This allows routes to come into the hub on the tunnel interface and re-leave the interface to go to other spokes.

But wait.  There is an issue still.  So spoke 2 can see routes from spoke 3 but the next hop is still the hub.  This means that the hub is still in the data and the control planes.  Not acceptable.  This will cause the hub to work harder decrypting and routing packets that it shouldn't care one bit about.  Send that crap straight to the other spoke.  Use  no ip next-hop-self eigrp <AS_number> and the hub will not inject itself as the next hop.  This will allow the spokes to talk directly with each other.

Now that the spokes know the other spokes are there, how do they get there?  This is where NHRP comes in.  They query the hub for the NBMA (think public) address of the other spoke and away they go.  There is more to it than that but the gist is that the hub introduces the spokes and then politely bows out.  Think of it as a match maker.  Sets them up and then bids adieu. 

At this point, the spokes are talking, but is it permanent?  Nope.  There is a lifetime of everything.  The lifetime by default is two hours.  This can all be adjusted on the tunnel interface with ip nhrp holdtime.

Another thing to remember when setting up NHRP and DMVPN is multicast and how to make it work.  The command  ip nhrp map multicast <hub_IP/dynamic> will allow multicast to function correctly over the tunnels.  As Brian said in the video, think of this as adding the broadcast word to a frame relay map statement.

Oh, crap.  Something seems to be wrong with NHRP.  What ever will I use to troubleshoot it?  How about the command debug nhrp?  That will turn on basic NHRP debugging and help show issues that might arise.  I find this interesting since the command to use nhrp is ip nhrp and the command for debugging doesn't have the keyword ip.  Oh, well.

Okay.  So what do we have now?  We have dynamic tunnels from spoke to spoke and a static tunnel from each spoke to the hub.  Perfect, right?  Nope.  If this is traveling the wonder that is the Internet, that means that this is subject to monitoring and that ain't cool.  How to fix that is the use of IPSec.  Now according to Brian in the video, the traditional way of doing IPSec (I have never done it on a router or firewall; always used other devices) was through crypto maps but these require each spoke to know about each other.  Kinds makes DMVPN more like MVPN.  Why use a match maker if you have her number already?  To beat this little bugger, you can now use crypto profiles.  Make the profile and attach it to the interface and WAMMO, instant get-the-hell-off-my-lawn scenario to anyone listening in.

 You want to tell if IPSec is working?  Why?  Always trust the configuration.  Isn't that always correct?  Yeah, right.  Use show crypto isakmp sa to see what IKEv1 sessions are active and show crypto ipsec sa to see what IPSec sessions are active and with what parameters.  You can also use show dmvpn detail for specific DMVPN information.  These commands will only show the initial connection to the hub from each spoke until a spoke wants to get his freak on with another spoke.  At that time, the encrypted tunnel (Internet condom?) is made and away they go.

Brian listed a couple of articles to help with learning more about DMVPN.  The first is the design guide off of Cisco's Design Zone.  The other is the DMVPN articles on Cisco Live 365.  Not bad places to learn a little more.

Now I don't feel like an expert with DMVPN, but I can say that I feel better than I did.

Below is the video that I watched and followed along with.