DMVPN Phase 2 OSPF Routing

In my first lesson about DMVPN we covered the basics, the second lesson explained how to configure DMVPN phase 1 and DMVPN phase 2. I also showed you an example where we use OSPF on DMVPN phase 1.

As I explained before, OSPF is not the best solution for DMVPN. It’s a link state protocol so all spoke routers have to be in the same area. When something changes on one spoke router then it will trigger SPF on the other spoke routers.

When we use DMVPN phase 2, spoke-to-spoke traffic will be direct and doesn’t go through the hub.

In this lesson I will show you what happens when you configure the following OSPF network types on DMVPN phase two:

• point-to-point
• broadcast
• non-broadcast
• point-to-multipoint
• point-to-multipoint non-broadcast

Here’s the topology that we will use:

Configuration

Tunnel Interfaces

Here is the hub router:

Hub(config)#interface Tunnel0
Hub(config-if)#ip address 172.16.123.1 255.255.255.0
Hub(config-if)#ip nhrp authentication DMVPN
Hub(config-if)#ip nhrp map multicast dynamic
Hub(config-if)#ip nhrp network-id 1
Hub(config-if)#tunnel source GigabitEthernet0/1
Hub(config-if)#tunnel mode gre multipoint
Hub(config-if)#end

And the spoke routers:

Spoke1(config)#interface Tunnel0
Spoke1(config-if)#ip address 172.16.123.2 255.255.255.0
Spoke1(config-if)#ip nhrp authentication DMVPN
Spoke1(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke1(config-if)#ip nhrp map multicast 192.168.123.1
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp nhs 172.16.123.1
Spoke1(config-if)#tunnel source GigabitEthernet0/1
Spoke1(config-if)#tunnel mode gre multipoint

Spoke2(config)#interface Tunnel0
Spoke2(config-if)#ip address 172.16.123.3 255.255.255.0
Spoke2(config-if)#ip nhrp authentication DMVPN
Spoke2(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke2(config-if)#ip nhrp map multicast 192.168.123.1
Spoke2(config-if)#ip nhrp network-id 1
Spoke2(config-if)#ip nhrp nhs 172.16.123.1
Spoke2(config-if)#tunnel source GigabitEthernet0/1
Spoke2(config-if)#tunnel mode gre multipoint

Let’s see if the hub sees two NHRP spokes:

Hub#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:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.2      172.16.123.2    UP 00:09:48     D
     1 192.168.123.3      172.16.123.3    UP 00:09:56     D

And try a quick ping to test connectivity:

Hub#ping 172.16.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/7/11 ms

Hub#ping 172.16.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/7/10 ms

The tunnel interfaces are up and running. Let’s continue with OSPF.

OSPF

Point-to-point

We can skip the first network type (point-to-point) since it doesn’t work. I showed you in the DMVPN phase 1 OSPF routing lesson what happens when you try this. The hub expects one neighbor on its tunnel interface while in reality we have two neighbors.

Broadcast

This is the best OSPF network type to use for DMVPN phase 2 and I’ll show you why. First let’s configure it:

Hub, Spoke1 & Spoke2
(config)#interface Tunnel 0
(config-if)#ip ospf network broadcast 

You need to make sure that the spoke routers will never be elected as DR or BDR:

Spoke1 & Spoke2
(config)#interface Tunnel 0
(config-if)#ip ospf priority 0

Now let’s configure some network commands. We’ll go for “best practices” and use a different area number for the DMVPN network:

Hub(config)#router ospf 1
Hub(config-router)#network 1.1.1.1 0.0.0.0 area 0
Hub(config-router)#network 172.16.123.0 0.0.0.255 area 1

Spoke1(config)#router ospf 1
Spoke1(config-router)#network 2.2.2.2 0.0.0.0 area 1
Spoke1(config-router)#network 172.16.123.0 0.0.0.255 area 1

Spoke2(config)#router ospf 1
Spoke2(config-router)#network 3.3.3.3 0.0.0.0 area 1
Spoke2(config-router)#network 172.16.123.0 0.0.0.255 area 1

Let’s see if the hub has two neighbors:

Hub#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/DROTHER    00:00:38    172.16.123.2    Tunnel0
3.3.3.3           0   FULL/DROTHER    00:00:37    172.16.123.3    Tunnel0

It does and the spoke routers have been elected as DROTHER, that’s good…we don’t want to see DR or BDR here. Let’s take a look at the routing tables:

Hub#show ip route ospf

      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/1001] via 172.16.123.2, 00:00:24, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:00:24, Tunnel0

Spoke1#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/1001] via 172.16.123.1, 00:00:28, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:00:28, Tunnel0

Spoke2#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/1001] via 172.16.123.1, 00:00:31, Tunnel0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/1001] via 172.16.123.2, 00:00:21, Tunnel0

Above you can see that all routers have learned the networks on each others loopback interfaces. Take a close look at the next hop IP addresses for the 2.2.2.2/32 and 3.3.3.3/32 entries. This is looking good, these are the IP addresses of the spoke routers. You can also see that 1.1.1.1/32 shows up as an inter-area route. This is good, it means we can summarize networks “behind” the hub towards the spoke routers if we want to.

Let’s see if spoke1 can reach spoke2:

Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.123.3 7 msec 6 msec *

Great this is working. We have spoke-to-spoke connectivity which worked “out of the box”. OSPF neighbor adjacencies were automatically established and the next hop addresses were correct for spoke-to-spoke communication.

Non-broadcast

The non-broadcast OSPF network type behaves the same as broadcast with the exception that we have to configure static neighbors:

Hub, Spoke1 & Spoke2
(config)#interface Tunnel 0
(config-if)#ip ospf network non-broadcast 

On the hub we will configure our neighbors:

Hub(config)#router ospf 1
Hub(config-router)#neighbor 172.16.123.2 
Hub(config-router)#neighbor 172.16.123.3 

We can see our neighbors on the hub:

Hub#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/DROTHER    00:00:38    172.16.123.2    Tunnel0
3.3.3.3           0   FULL/DROTHER    00:00:37    172.16.123.3    Tunnel0

Let’s try another traceroute:

Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.123.3 7 msec 6 msec *

The end result will be the same as with “broadcast”. The only difference is the static neighbor command.

Point-to-multipoint

This network type is a poor choice, let me show you why. First we’ll get rid of the static neighbors from the previous example and we’ll set the network type: