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.

Lab Hard, with a Vengeance (VPLS in GNS3!!)

So I'm finally getting back into lab mode, and getting excited out R/S technologies again. After realizing that the requirements for Cisco's CSR1000v (Cloud Services Router) has been dramatically decreased I wanted to get one into virtualbox and throw it in the mix with GNS3. The results thus far have been phenomenal. Hence what this post is about, something I've wanted to get working in a home lab for some time now is VPLS. For those of you not familiar with VPLS, I'm speaking of virtual private lan services. With a 7200 in GNS3 we've been able to create point-to-point pseudowires for some time now. A pseudowire completely hides the MPLS provider network from clients and gives the illusion that both CEs are directly connected by a very long cable. This works because we're encapsulating frames received on the PE and associating them with a virtual circuit that gets label switched between two PE routers. Very cool stuff...

However, what if you had a situation where the client wanted this layer 2 style of WAN... but they had multiple sites. Even worse they wanted a full mesh! Enter VPLS, giving us the ability to almost carve out a small switch inside the MPLS cloud. This is something that GNS3 has been lacking for sometime, because no GNS3 emulated router can host a multipoint pseudowire. Until now! Well... technically it's not GNS3 doing the heavy lifting, it's the CSR1000v. So I made a video about this setup, of course, before trying this in your own lab a couple key notes about the CSR1000v:


- IOS XE 3.10+ is your best bet because of the lowered requirements
- IOS XE 3.10+ requires 2.5GB of RAM, but it can run on a single vCPU (this is vastly improved from the 3.9 release)
- In order to test out the more advance features, after booting up your CSR1000v go into global configuration and enter "license boot level premium", other wise you can't enable MPLS. After setting the boot level to premium and accepting the EULA for eval licensing, wr mem and reload.
- Lastly, unless you want to do all your configs within virtualbox via CSR's virtual console, install CSR with a Serial Console (from the GRUB menu on first boot) and connect via a named pipe. I'm using SOCAT in OS X to redirect the named pipe to /dev/ttys001. Your mileage may vary.