Enterprise

DMVPN – Part 1, it’s not that bad.

So I wanted to do a couple posts on DMVPN, one of the new topics to CCIE v5.  I’ll run through a basic setup in this post, with a video at the end. In the next few posts I’ll show some of the more advanced things we can do with DMVPN.

First off, for most DMVPN configurations… it’s not that bad. In a single hub environment, you’re either the hub or you’re a spoke. Hub routers are responsible for keeping track of NHRP (next hop resolution protocol) registrations from spokes, and for informing spokes of that information when they need to build dynamic tunnels between one another. So take the topology below:

The first picture is just for reference, it doesn’t matter how many provider routers are between these devices (or if there are any at all). So in a DMVPN deployment spoke routers are statically configured with the public and tunnel IP of the hub. Here’s the good news, if you’re goal is “Let’s just get it working!” then the hub configuration is really really simple. Check it out:

Hub(config)# interface tunnel 0
Hub(config-if)# tunnel source 150.100.1.2
Hub(config-if)# tunnel mode gre multipoint
Hub(config-if)# ip nhrp map multicast dynamic
Hub(config-if)# ip nhrp network-id 100
Hub(config-if)# ip address 172.16.10.1 255.255.255.0

That’s it, obviously if you’ve ever seen a production headend router you can do more… but as for “what’s the bare minimum to make it work” that’s it! Also note that the nhrp network-id is locally significant and complete arbitrary, however it is required (think OSPF process id). Now the spoke configuration is a little more involved, because remember spokes have to be statically mapped to the headend/hub router.

SPK1(config)# interface tunnel 0
SPK1(config-if)# tunnel source 150.100.10.2
SPK1(config-if)# tunnel mode gre multipoint
SPK1(config-if)# ip nhrp map multicast 150.100.1.2
SPK1(config-if)# ip nhrp map 172.16.10.1 150.100.1.2
SPK1(config-if)# ip nhrp nhs 172.16.10.1
SPK1(config-if)# ip nhrp network-id 100
SPK1(config-if)# ip address 172.16.10.10 255.255.255.0

So what’s going on here?  On the hub router we’re saying “Any broadcasts/multicasts going out this interface – the next hops are going to be learned dynamically”. Then on the spoke(s) we’re saying “Any broadcasts/multicasts need to go to 150.100.1.2 so we can learn about the next hop. Also, any traffic going 172.16.10.1, that needs to be forwarded to 150.100.1.2”. Ok, so that about covers our NHRP map statements, so the last thing we should talk about on the spoke configuration is “ip nhrp nhs”. NHS=Next-hop server, this line of code is instructing the spoke to register with the IP address that follows (the hub’s tunnel IP). Without specifying who your NHS is, the spoke wouldn’t know that it has to tell the hub about it’s NBMA(the tunnel source) and tunnel IPs.

Alright! So that’s configuring DMVPN! We can look on the Hub after all spokes are configured and issue a ‘show dmvpn’ to see all nhrp registered devices like so:

HUB#show dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incomplete
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer
        NHS Status: E –> Expecting Replies, R –> Responding, W –> Waiting
        UpDn Time –> Up or Down Time for a Tunnel
===============================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:3,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1 150.100.10.2       172.16.10.10    UP 00:01:24     D
     1 150.200.20.2       172.16.10.20    UP 00:00:46     D
     1 150.200.30.2       172.16.10.30    UP 00:00:23     D

Very good, so by the attribute code “D” we can see that the hub has learned all these peers dynamically (as expected). What does this output look like on Spoke1?

SPK1#sh dmvpn
Legend: Attrb –> S – Static, D – Dynamic, I – Incomplete
        N – NATed, L – Local, X – No Socket
        # Ent –> Number of NHRP entries with same NBMA peer
        NHS Status: E –> Expecting Replies, R –> Responding, W –> Waiting
        UpDn Time –> Up or Down Time for a Tunnel
===============================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1 150.100.1.2         172.16.10.1    UP 00:03:04     S 

As expected, we currently only have (1) peer, the hub. Check out that attribute code “S” too, since we mapped him out statically. Lastly, what happens if we ping spoke2’s tunnel ip from spoke1, how does that impact the show dmvpn output?


Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 —– ————— ————— —– ——– —–
     1 150.100.1.2         172.16.10.1    UP 00:04:46       S
     1 150.200.20.2       172.16.10.20    UP 00:00:02     D

True to it’s name, DMVPN builds a dynamic tunnel between spoke1 and spoke2. Pop quiz hot shots, where did it get the NBMA address from? You guessed it, or at least I hope you did, the Hub! Alright, this is getting to be a lot of typing lol, I’ll demonstrate the above configuration as well as getting EIGRP and OSPF running over DMVPN in a video.

Leave a Reply