After looking at some Cisco documentation, I decided to make a lab based off of DMVPN and OSPF in first — a single cloud, and next as a dual cloud.

 

DMVPNTopo

This will be our starting topology. The initial show runs are seen below.

R1

interface Loopback0
 ip address 8.8.8.8 255.255.255.0
interface FastEthernet0/0
 ip address 192.168.0.6 255.255.255.0
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

Hub A
interface FastEthernet0/0

 ip address 172.17.0.1 255.255.255.0
interface FastEthernet0/1
 ip address 192.168.0.1 255.255.255.0
router ospf 1
 network 10.0.0.0 0.0.0.255 area 1
 network 192.168.0.0 0.0.0.255 area 0

Hub B
interface FastEthernet0/0
 ip address 172.17.0.5 255.255.255.0
interface FastEthernet0/1
 ip address 192.168.0.2 255.255.255.0
router ospf 1
 network 10.0.0.0 0.0.0.255 area 1
 network 192.168.0.0 0.0.0.255 area 0

Spoke A
interface FastEthernet0/0
 ip address 172.17.0.3 255.255.255.0
router ospf 1
 network 10.0.0.0 0.0.0.255 area 1
 network 192.168.1.0 0.0.0.255 area 1

Spoke B
interface FastEthernet0/0
 ip address 172.17.0.4 255.255.255.0
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.255 area 1
 network 192.168.2.0 0.0.0.255 area 1

Ok here we go, we have our interfaces pointing into the DMVPN cloud with the subnet of 172.17.0.0/24 and the “inside” facing subnets are based off the 192.168.0.0/24 network. We’ve also configured OSPF area 0 and 1.

First before anything, make sure you have basic l3 (use pings) and check CDP to ensure connectivity.

Next, lets go through the DMVPN tunnel steps. This part reminds me alot of when I first learned the steps for a IPsec VPN tunnel. Theres alot of pieces and if one step is missing, it could break the whole process. DMVPN (hence VPN) is very similar.

Let’s look at our hubs. Now this part is a bit misleading. We’ll always configure at least one PRIMARY hub, and a secondary. The thing is, the secondary is actually another spoke and acts like one until the primary fails.

interface Tunnel0
 bandwidth 1000
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication MEETUP
 ip nhrp map multicast dynamic
 ip nhrp network-id 10577
 ip ospf network broadcast
 ip ospf priority 2
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

So here’s our basic config for Hub A. The biggest thing to take away here is note there is no ip nhrp nhs command. This is a primary hub, so we shouldnt have to statically peer this guy with anyone else. The next piece is the OSPF priority. This is one of the reasons why Cisco isnt too crazy on having OSPF work with DMVPN. It will — but if you misconfigure the priority of a spoke and it becomes the DR, it’ll really screw up the whole DMVPN cloud. EIGRP or RIP are alot more forgiving when it comes to this. Remember the priority for all OSPF routers is 1 by default — higher is better. So if we configure 2 on the Hub A, it always guarantees this router will be the DR for our DMVPN cloud. Finally, we have bandwidth 1000, we’ll see later on why this is important.

Next lets look at Hub B

interface Tunnel0
 bandwidth 900
 ip address 10.0.0.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication MEETUP
 ip nhrp map multicast dynamic
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp network-id 10577
 ip nhrp nhs 10.0.0.1
 ip ospf network broadcast
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

Hub B looks similiar to Hub A, but remember its really a Spoke setup ready to take over as a Hub. Note here we see the bandwidth command lower than Hub A so traffic perfers Hub A instead of Hub B. Next, note the map commands. We’re saying here to reach 10.0.0.1 (Hub A), go through NHRP via the IP of 172.17.0.1 (the outside public IP). Notice also the existence of the ip nhrp nhs command. We’re statically mapping our Next Hop Server/Hub IP will means this is pointing to a hub.

 

Finally lets look at Spoke A and B

Spoke A
interface Tunnel0
 bandwidth 1000
 ip address 10.0.0.11 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication MEETUP
 ip nhrp map multicast 172.17.0.1
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.5
 ip nhrp map 10.0.0.2 172.17.0.5
 ip nhrp network-id 10577
 ip nhrp nhs 10.0.0.1
 ip nhrp nhs 10.0.0.2
 ip ospf network broadcast
 ip ospf priority 0
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

Spoke B
interface Tunnel0
 bandwidth 1000
 ip address 10.0.0.12 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication MEETUP
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.5
 ip nhrp map 10.0.0.2 172.17.0.5
 ip nhrp map multicast 172.17.0.1
 ip nhrp network-id 10577
 ip nhrp nhs 10.0.0.1
 ip nhrp nhs 10.0.0.2
 ip ospf network broadcast
 ip ospf priority 0
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

Note here we’re statically mapping how to reach each Hub as well as specifying what the hub IPs are. Also note here we’re saying for our spokes to do a priority of 0 so it’ll never become the DR, they’ll stay at DROTHER.

Now you might be wondering why I have that 8.8.8.8 loopback off of R1. For me, its a way to test failover between the two Hubs. Let’s look at the routing table of any Spoke, lets say Spoke B.

SpokeB#sh ip route

   172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/0
     8.0.0.0/32 is subnetted, 1 subnets
O IA    8.8.8.8 [110/111] via 10.0.0.2, 00:00:14, Tunnel0
                [110/111] via 10.0.0.1, 00:02:36, Tunnel0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Tunnel0
O IA 192.168.0.0/24 [110/110] via 10.0.0.2, 00:00:14, Tunnel0
                    [110/110] via 10.0.0.1, 00:02:36, Tunnel0
     192.168.1.0/32 is subnetted, 1 subnets
O       192.168.1.1 [110/101] via 10.0.0.11, 00:02:38, Tunnel0
C    192.168.2.0/24 is directly connected, Loopback0

 

Right now we’re learning the 8.8.8.0 network over both Hub1 and Hub2.

To make things interesting, lets do a loopback from SpokeB

int l0
ip addr 9.9.9.9 255.255.255.255
router ospf 1
net 9.9.9.0 0.0.0.255 area 1

Now lets verify from R1 that we see and can ping 9.9.9.9 — perfect!

     9.0.0.0/32 is subnetted, 1 subnets
O       9.9.9.9 [110/101] via 10.0.0.12, 00:01:16, Tunnel0
ping 9.9.9.9

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/64/104 ms

OK now lets do a traceroute from SpokeB to get to 8.8.8.8 and see what route it takes. Note that since OSPF costs being equal at this point (going into area 0) it’ll prefer both routes.

SpokeB#traceroute 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 10.0.0.2 76 msec
    10.0.0.1 72 msec
    10.0.0.2 56 msec
  2 192.168.0.6 72 msec *  44 msec

Now the failover test!!

Let’s shut off the f0/0 interface off Hub A (the one that owns 172.17.0.1). We’ll see in the logs a bunch of Tunnel0 to DOWN logs appearing. Let’s make sure its full dead from OSPF point of view before proceeding.

*Mar  1 07:18:46.346: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.0.1 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired

sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.2       1   FULL/DR         00:00:37    10.0.0.2        Tunnel0

Good so from SpokeB’s point of view, 10.0.0.1 is dead and 10.0.0.2 only exists. When we do a trace from SpokeB…

 traceroute 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 10.0.0.2 88 msec 72 msec 44 msec
  2 192.168.0.6 72 msec *  68 msec

We only see .2, no more .1 Hub-B is now the “active” Hub. Now lets bring back Hub A, will it “takeover” and become primary again?

*Mar  1 07:21:12.674: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
HubA(config-if)#
*Mar  1 07:21:13.194: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 07:21:14.194: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar  1 07:21:53.042: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel0 from LOADING to FULL, Loading Done

tunnel comes back up and OSPF comes back online…

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.2       1   FULL/DR         00:00:38    192.168.0.2     FastEthernet0/1
192.168.0.6       1   FULL/DROTHER    00:00:31    192.168.0.6     FastEthernet0/1
192.168.0.2       1   INIT/DROTHER    00:00:39    10.0.0.2        Tunnel0
192.168.1.1       0   FULL/DROTHER    00:00:39    10.0.0.11       Tunnel0
192.168.2.1       0   INIT/DROTHER    00:00:30    10.0.0.12       Tunnel0

Lets give it some more time, state is still in INIT so give it some time….

*Mar  1 07:24:22.906: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.1 on Tunnel0 from LOADING to FULL, Loading Done

I may have to change timers, the tunnel0 interface took a good few minutes to change to FULL.

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.2       1   FULL/DR         00:00:30    192.168.0.2     FastEthernet0/1
192.168.0.6       1   FULL/DROTHER    00:00:33    192.168.0.6     FastEthernet0/1
192.168.0.2       1   INIT/DROTHER    00:00:34    10.0.0.2        Tunnel0
192.168.1.1       0   FULL/DROTHER    00:00:32    10.0.0.11       Tunnel0
192.168.2.1       0   FULL/DROTHER    00:00:33    10.0.0.12       Tunnel0

Now if we traceroute from SpokeB…

traceroute 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 10.0.0.2 116 msec
    10.0.0.1 72 msec
    10.0.0.2 44 msec
  2 192.168.0.6 80 msec *  60 msec

We’re back to our equal load balancing setup. Now if any of these IPs looked familiar to you, is because I borrowed them from Cisco’s documentation —

http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/41940-dmvpn.html#dualhubsingle

Click here for the next blog post, talking about a Dual Hub Dual Cloud scenario!

William Zambrano

William Zambrano

NYC networkers is run by William Zambrano, a passionate network engineer who has been in the IT industry for eight years who posts up blog articles, YouTube videos, and holds meetup.com events in the NYC area. He lives in Queens, New York and has consulted in various different companies in the NY area. Previously William worked as a Cisco Certified Systems Instructor (CCSI) but now currently works for Arista Networks serving as a Systems Engineer. William can be reached by email at willzambrano@gmail.com

More Posts - Website

Follow Me:
Twitter