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:

DMVPN Example Topology with hub, two spokes and loopback interfaces.

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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

540 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Mahmoud,
    You are exactly right. The default network type of a DMVPN tunnel is Point-to-Point.

    One of the rules of a P2P interface is there can be at most 1 OSPF neighbor. With the Hub’s tunnel interface, however, the OSPF process hears Hello messages from numerous different neighbors’ OSPF processes. This causes the Hub’s OSPF process to churn over and over, throwing out the previously formed Exstart relationship to form a new neighborship with the most recently received Hello. When this happens, you will see these messages on the Hub over and over again fo

    ... Continue reading in our forum

  2. Hello Salvatore

    Yes you are correct that for Phase 2 with a broadcast network type, there is direct spoke-to-spoke connectivity. However, this direct connectivity is achieved AFTER the initial communication occurs with the HUB. When a spoke router wants to reach another spoke, it will send an NHRP resolution request to the hub to find the NBMA IP address of the other spoke. This means that initial connectivity must be made with the hub router.

    Additionally, in order to achieve this direct spoke-to-spoke connectivity, you need two things:

    * Spoke routers need

    ... Continue reading in our forum

  3. Ciao Lazaros,

    thanks for your detailed description,

    if i understood it right, it seems to be a matter of priorities:
    before the spoke-to-spoke communication can work I should have hub & spoke reachability which means that, in case I decide to use OSPF, the DR/BDR election it’s a prerequisite for the spoke-to-spoke communication to be established

    Thanks,
    Salvatore.

    • First call of traceroute : RIP, EIGRP, OSPF (BROADCAST, NBMA, POINT-TO-MULTIPOINT). All 5 labs do show the HUB hop.

    • Next calls : Only OSPF (POINT-TO-MULTIPOINT) does show the HUB hop at each call.

    Below is OSPF (POINT-TO-MULTIPOINT) output.

    **SPOKE-2#traceroute 2.2.2.2 source loopback 0**
    Type escape sequence to abort.
    Tracing the route to 2.2.2.2
    VRF info: (vrf in name/id, vrf out name/id)
      1 172.16.123.1 16 msec 8 msec 8 msec
      2 172.16.123.2 20 msec 20 msec *
    **SPOKE-2#traceroute 2.2.2.2 source loopback 0**
    Type escape sequence to abort.
    Tracing the r
    ... Continue reading in our forum

  4. Thank you for the answer Lazaros.

    According to what you say. For all these articles on DMVPN Phase 2 ; a text explaining that the “traceroute” to be considered is not the first one must be added.

9 more replies! Ask a question or join the discussion by visiting our Community Forum