DMVPN Fundamentals - Part 2 with CCIE Guest Blogger Jon Major
Well, Jon Major CCIE #47884 is back and bringing us another great blog. Thanks Jon, psyched you are willing to share on the Cisco Learning Network. Take it away. -Brett

Welcome back! In my last post, DMVPN Fundamentals - Part 1, we took a look at the basics of getting a DMVPN network up and running, with special focus on operations you might see in the lab. Today I’m going to pick up where we left off –  tunnels up, spokes registered to the hub – and expand on DMVPN a bit more. Just as a refresher, here is out existing topology:

Device

Source IP (real address)

Tunnel IP

R9

172.16.16.1

10.123.123.1

R10

172.16.0.14

10.123.123.10

R11

172.16.0.22

10.123.123.20

R12

172.16.0.26

10.123.123.30

 

 

Also of note, tunnel sources are running inside a VRF called “Provider-Services” and are participating in OSPF 99, peering with the provider.

 

In the interest of transparency, here are our starting tunnel configurations from R9 (hub) and R10 (spoke). Tunnel configurations from R11 & R12 are nearly identical to R10.

 

 

R9

 

interface Tunnel0

  ip address 10.123.123.1 255.255.255.0

  no ip redirects

  ip nhrp map multicast dynamic

  ip nhrp network-id 123

  tunnel source Loopback1

  tunnel mode gre multipoint

  tunnel vrf Provider-Services

end

 

R10

 

interface Tunnel0

  ip address 10.123.123.10 255.255.255.0

  no ip redirects

  ip nhrp map 10.123.123.1 172.16.16.1

  ip nhrp map multicast 172.16.16.1

  ip nhrp network-id 123

  ip nhrp nhs 10.123.123.1

  tunnel source GigabitEthernet0/1

  tunnel mode gre multipoint

  tunnel vrf Provider-Services

end

 

 

DMVPN Phase 2 – EIGRP behavior

 

DMVPN Phase 2 is best described (in my humble opinion) as a dynamic VPN that leverages the RIB to decide when/where to build tunnels. So when we’re implementing routing protocols and summarization, we have to take that into account. Spokes will only try to build tunnels to other spokes if the spokes show as next hop in the RIB. Let’s do a really quick EIGRP configuration, and I’ll demonstrate that. EIGRP in DMVPN is pretty much straight forward, with the exception of making two very important changes on the hub. To make my point, I’m going to skip those changes. I’ll also be using EIGRP named mode, since that seems to be the trend these days (and because it’s better). In addition, we’ll create loopbacks on each router (Loopback 1337), and advertise said loopbacks into EIGRP.

 

 

R9

 

router eigrp DMVPN
  !
  address-family ipv4 unicast autonomous-system 1337
   !
   af-interface Tunnel0
     no split-horizon
   exit-af-interface
   !
   topology base
   exit-af-topology
   network 10.0.0.0
  exit-address-family
!
!
interface Loopback1337
  ip address 10.0.0.9 255.255.255.255

 

 

R10

 

router eigrp DMVPN

  !

  address-family ipv4 unicast autonomous-system 1337

   !

   topology base

   exit-af-topology

   network 10.0.0.0

  exit-address-family

!

interface Loopback1337

  ip address 10.0.0.10 255.255.255.255

 

 

Fairly simple configuration, right? Notice no split-horizon configured on the hub. This command is absolutely essential for EIGRP to operate properly within DMVPN, since the hub is supposed to advertise routes learned from one spoke back out to the same interface so other spokes may receive them. In legacy EIGRP we’d achieve this under the interface config with no ip split-horizon eigrp xxxx where xxxx is your EIGRP ASN. As promised, I intentionally skipped one important bit of config on the hub. So let’s look at our routing tables and see if we can spot any potential issues.

 

On R9, everything will look just fine. We have routes to the lo1337 interfaces on our spokes, and they’re reachable.

 

 

R9#show ip route eigrp | b ^Gateway

Gateway of last resort is not set

 

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D        10.0.0.10/32 [90/76800640] via 10.123.123.10, 00:07:23, Tunnel0

D        10.0.0.11/32 [90/76800640] via 10.123.123.11, 00:07:14, Tunnel0

D        10.0.0.12/32 [90/76800640] via 10.123.123.12, 00:07:08, Tunnel0

!

R9#ping 10.0.0.10 source lo1337 rep 2 time 1

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.10, timeout is 1 seconds:

Packet sent with a source address of 10.0.0.9

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 2/3/4 ms

R9#ping 10.0.0.11 source lo1337 rep 2 time 1

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.11, timeout is 1 seconds:

Packet sent with a source address of 10.0.0.9

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 3/4/5 ms

R9#ping 10.0.0.12 source lo1337 rep 2 time 1

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.12, timeout is 1 seconds:

Packet sent with a source address of 10.0.0.9

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 4/4/4 ms

 

 

So far so good right? Let’s take a look at R10 and try the same.

 

 

R10#show ip route eigrp | b ^Gateway

Gateway of last resort is not set

 

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D        10.0.0.9/32 [90/76800640] via 10.123.123.1, 00:08:55, Tunnel0

D        10.0.0.11/32 [90/102400640] via 10.123.123.1, 00:08:46, Tunnel0

D        10.0.0.12/32 [90/102400640] via 10.123.123.1, 00:08:41, Tunnel0

R10#ping 10.0.0.9 source lo1337 rep 2 time 1

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.9, timeout is 1 seconds:

Packet sent with a source address of 10.0.0.10

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 4/4/5 ms

R10#ping 10.0.0.11 source lo1337 rep 2 time 1

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.11, timeout is 1 seconds:

Packet sent with a source address of 10.0.0.10

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 7/8/10 ms

R10#ping 10.0.0.12 source lo1337 rep 2 time 1

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.12, timeout is 1 seconds:

Packet sent with a source address of 10.0.0.10

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 5/5/6 ms

 

 

Nothing suspicious yet, right? Take a closer look at R10’s routing table, and notice how the loopbacks of R11 and R12 are only reachable via 10.123.123.1 (R9). We can confirm our suspicions with show dmvpn, and notice we have no dynamic tunnels built to said spokes. Also, running a traceroute for further confirmation.

 

 

R10#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        T1 - Route Installed, T2 - Nexthop-override

        C - CTS Capable

        # 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 172.16.16.1        10.123.123.1    UP 00:22:04    S

 

R10#trac

R10#traceroute 10.0.0.11

Type escape sequence to abort.

Tracing the route to 10.0.0.11

VRF info: (vrf in name/id, vrf out name/id)

  1 10.123.123.1 7 msec 5 msec 5 msec

  2 10.123.123.11 6 msec *  5 msec

 

 

Definitely not ideal; it looks like all traffic is routing through the hub. This is exactly the problem with Phase 2 DMVPN – there’s no built-in mechanism to tell spokes to attempt to build dynamic tunnels. We need the RIB to have accurate next hop information. To correct this, we’ll go back onto R9 and under af-interface tunnel 0, add no next-hop-self. EIGRP will then do a graceful restart, and we’ll be in business.

 

 

R9

 

router eigrp DMVPN

!

address-family ipv4 unicast autonomous-system 1337

  !

  af-interface Tunnel0

   no next-hop-self

   no split-horizon

  exit-af-interface

 

 

Now, going back to R10 we can check our routing table, re-run pings, and then validate that everything is working as expected with traceroute and show dmvpn.

 

 

R10#show ip route eigrp | b ^Gateway

Gateway of last resort is not set

 

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

D        10.0.0.9/32 [90/76800640] via 10.123.123.1, 00:01:31, Tunnel0

D        10.0.0.11/32 [90/102400640] via 10.123.123.11, 00:01:30, Tunnel0

D        10.0.0.12/32 [90/102400640] via 10.123.123.12, 00:01:30, Tunnel0

R10#ping 10.0.0.11 so lo1337 re 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 10.0.0.11, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.10

!!!

Success rate is 100 percent (3/3), round-trip min/avg/max = 3/3/3 ms

R10#ping 10.0.0.12 so lo1337 re 3

Type escape sequence to abort.

Sending 3, 100-byte ICMP Echos to 10.0.0.12, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.10

!!!

Success rate is 100 percent (3/3), round-trip min/avg/max = 6/11/17 ms

R10#traceroute 10.0.0.11

Type escape sequence to abort.

Tracing the route to 10.0.0.11

VRF info: (vrf in name/id, vrf out name/id)

  1 10.123.123.11 3 msec *  3 msec

R10#traceroute 10.0.0.12

Type escape sequence to abort.

Tracing the route to 10.0.0.12

VRF info: (vrf in name/id, vrf out name/id)

  1 10.123.123.12 4 msec *  3 msec

R10#show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        T1 - Route Installed, T2 - Nexthop-override

        C - CTS Capable

        # 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:3,

 

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

----- --------------- --------------- ----- -------- -----

    1 172.16.16.1        10.123.123.1    UP 00:27:14    S

    1 172.16.0.22       10.123.123.11    UP 00:05:04    D

    1 172.16.0.26       10.123.123.12    UP 00:00:17    D

 

 

DMVPN Phase 2 – OSPF Behavior

 

OSPF in phase 2 is also fairly straight forward. Generally speaking, the ideal scenario is to use network type ‘broadcast’ and force all spokes to be DROTHERS by setting their priority to 0. We do this because a) network type broadcast will leave next-hop intact, thereby allowing dynamic tunnels based on what’s in the RIB, and b) we need the hub and only the hub to be the DR.

 

R9

 

interface Tunnel0

ip ospf network broadcast

!

router ospf 1337

network 10.0.0.0 0.255.255.255 area 0

 

 

R10

 

interface Tunnel0

ip ospf network broadcast

ip ospf priority 0

!

router ospf 1337

network 10.0.0.0 0.255.255.255 area 0

 

[Rinse and repeat on R11 & R12]

 

 

We have to actually specify network type broadcast, because the default on a tunnel interface is point-to-point. Other than that, as you can see, the configuration is pretty straight. One caveat I failed to mention in EIGRP that can really burn you in OSPF is multicast. If your lab explicitly (or implicitly) forbids you to use multicast in your DMVPN network, then people from the v4 lab will be in very familiar territory. Meaning, you can have a fully functional unicast-only DMVPN network (no ‘ip nhrp map multicast’ present). In that case, you’ll need network type ‘non-broadcast,’ and you’ll have to static configure OSPF neighbors. That being said, the logic of forcing the hub to be DR and spokes to be DROTHER remains the same. Let’s validate our OSPF/DMVPN configurations to confirm everything is working. I’ll use R10 as my example, but in reality you’d want to run this on all DMVPN routers.

 

 

R10#show dmvpn | b ^Type

Type:Spoke, NHRP Peers:1,

 

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

----- --------------- --------------- ----- -------- -----

    1 172.16.16.1        10.123.123.1    UP 13:53:03    S

!

R10#show ip route ospf | b ^Gateway

Gateway of last resort is not set

 

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

O        10.0.0.9/32 [110/1001] via 10.123.123.1, 00:11:33, Tunnel0

O        10.0.0.11/32 [110/1001] via 10.123.123.11, 00:11:33, Tunnel0

O        10.0.0.12/32 [110/1001] via 10.123.123.12, 00:11:33, Tunnel0

!

R10#ping 10.0.0.11 source lo1337 rep 2

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.11, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.10

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 3/5/8 ms

R10#ping 10.0.0.12 source lo1337 rep 2

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.0.0.12, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.10

!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 7/7/7 ms

!

R10#show dmvpn | b ^Type

Type:Spoke, NHRP Peers:3,

 

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb

----- --------------- --------------- ----- -------- -----

    1 172.16.16.1        10.123.123.1    UP 13:54:00    S

    1 172.16.0.22       10.123.123.11    UP 00:00:20    D

    1 172.16.0.26       10.123.123.12    UP 00:00:17    D

!

R10#traceroute 10.0.0.11

Type escape sequence to abort.

Tracing the route to 10.0.0.11

VRF info: (vrf in name/id, vrf out name/id)

  1 10.123.123.11 3 msec *  4 msec

 

 

There you go! Confirmation of the dynamic tunnels form, traceroutes look good, everything checks out. That’s where I leave you today. My original intention was to talk more about phase 3 today, but let’s be honest… this post is getting a bit long. So in DMVPN Fundamentals, Part 3, I’ll dig into phase 3, crypto, and maybe some miscellaneous items.