DMVPN Phase 1 OSPF Routing

In the first DMVPN lesson I explained the basics, the second one covers a basic DMVPN phase 1 configuration which we will use in this lesson where we configure OSPF.

OSPF is not the best solution when it comes to DMVPN. Because it’s a link-state protocol, each spoke router has to have the complete LSDB of the DMVPN area. Since we use a single subnet on the multipoint GRE interfaces, all spoke routers have to be in the same area.

With a few routers this is no problem but when you have dozens or hundreds of routers, this doesn’t scale very well. Most spoke routers are probably low end devices at branch offices that don’t like all the LSA flooding that OSPF might do within the area. One way to reduce the number of prefixes in the DMVPN network is to use a stub or totally stub area.

OSPF also has a lot of different network types:

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

In this lesson I’ll show you how to configure OSPF on a DMVPN phase 1 network. Here’s the topology we will use:

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

Let’s take a look at the configuration…

Configuration

In the first DMVPN lesson I explained the basics, the second one covers a basic DMVPN phase 1 configuration which we will use in this lesson where we configure OSPF. OSPF is not the best solution when it comes to DMVPN. Because it's a link-state protocol, each spoke router has to have the complete L


Tunnel interfaces

Here is the basic DMVPN phase 1 configuration that we will use:

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
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 destination 192.168.123.1
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 destination 192.168.123.1

Let’s make sure it works:

Hub#show dmvpn | begin 192.168.123.
     1 192.168.123.2      172.16.123.2    UP 00:22:37     D
     1 192.168.123.3      172.16.123.3    UP 00:00:32     D

This is looking good, two registrations. Let’s try a quick ping:

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 = 6/6/8 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 = 5/6/9 ms

Our tunnels are up and running. Let’s play with OSPF!

OSPF

We will try each of the OSPF network types, the default is point-to-point so that’s what we will start with:

Point-to-point

Let’s configure OSPF, I will advertise all networks in the same area for now:

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

As soon as you configure the network commands, the hub router will spam the following message:

Hub#
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel0 from EXCHANGE to DOWN, Neighbor Down: Adjacency forced to reset
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel0 from EXCHANGE to DOWN, Neighbor Down: Adjacency forced to reset

Why do we see this? Take a look at the OSPF default network type:

Hub#show ip ospf interface Tunnel 0 | include Network Type
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1000
Spoke1#show ip ospf interface Tunnel 0 | include Network Type
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 1000

The default is point-to-point and we are using multipoint interfaces. Our hub router expects one neighbor, not two. It will keep establishing and tearing neighbor adjacencies with the default network type.

This is never going to work, not for any of the phases so the OSPF point-to-point network type is something you can forget about with DMVPN. Let’s move on to the next one!

Broadcast

The broadcast OSPF network type works very well since it automatically establishes neighbor adjacencies. Let’s change the network type on all routers:

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

There is no direct communication between spoke routers so we need to make sure that the spoke router can never be elected as DR or BDR. To enforce this we’ll set their priority to 0:

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

Let’s reset OSPF:

Hub#clear ip ospf process 
Reset ALL OSPF processes? [no]: yes

And verify if we have neighbors:

Hub#show ip ospf neighbor 

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

Excellent, we see two neighbors. Using an OSPF network type that automatically establishes neighbor adjacencies works well on a hub that allows dynamic spoke routers. Let’s check 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:02:16, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:02:06, Tunnel0
Spoke1#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/1001] via 172.16.123.1, 00:02:24, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:02:14, Tunnel0
Spoke2#show ip route ospf

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

Each router has learned the networks on the different loopback interfaces. When we use the broadcast network type, the next hop value is preserved. Do we have connectivity? Let’s find out:

Spoke1#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/9 ms
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.1 7 msec 8 msec 6 msec
2 172.16.123.3 8 msec 9 msec *

Since we use DMVPN phase 1, all traffic will go through the hub. Let’s move on to the next network type!

Non-Broadcast

The non-broadcast network type works exactly the same as broadcast with the exception that we have to configure static neighbors. It works but it kinda defeats the purpose of having dynamic spokes if we have to configure static neighbors:

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 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

503 Sign Ups in the last 30 days

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

Tags: , , ,


Forum Replies

  1. Rene,

    When would we choose to use Phase 1, 2, or 3, and why? I understand the differences between the three, but do we gain any benefit from implementing one or the other that is noticeable to end users?

    It seems to me that perhaps allowing spoke routers to talk to each other may decrease latency in the real world, as they would not have to hop through the hub router, but other than that I’m not sure.

    Thanks,

    Patrick

  2. Hi Patrick,

    The different versions are like an evolution of DMVPN. We don’t really use phase 1 anymore unless you have a really good reason why you want to force all traffic through the hub (security perhaps?). Otherwise, it’s more effective to allow spoke-to-spoke traffic.

    Both phase 2 and 3 allow spoke-to-spoke traffic, the advantage of phase 3 is that we use the “shortcuts” so you don’t need specific entries anymore in the routing tables of the spoke routers. I can’t think of any advantages right now that phase 2 has over phase 3 so if you implement this, yo

    ... Continue reading in our forum

  3. Hello Heng

    This is a very good question. Looking at the process in more detail, when using Phase 3.

    Initially, (and that is the key word) all spoke to spoke packets are switched across the hub. In order for a spoke to learn about the true NBMA IP address of another spoke, the NHRP redirect message is used.

    So when a hub receives an IP packet inbound on its interface and switches it out of the same interface, it sends a special NHRP redirect message to the source indicating that this is a suboptimal path. It should look for a better way using NHRP resolution.

    ... Continue reading in our forum

  4. Hello Lagapides
    Thank you so much for your time. I got it now .
    Sovandara

  5. Thanks Laz - I’ve only ever known ethernet in my time as a network engineer so to imagine that something else can exist in it’s place at layer 2 is a strange concept for me! :open_mouth:

    I’ve since heard that home power line network can actually be used to shuttle ethernet frames around too… absolute madness! :wink:

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