Get Unlimited Access to our 785 Cisco Lessons Now Get $1 Trial
You are here: Home » Cisco » CCIE Routing & Switching

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







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

Give Membership a try - it's just $1 ►

1830 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. Hi Rene,

    If we configure the stub area and the spoke receive the default route, the default route will not take any effect as we still have a static default route at the SPOKE router which pointing to the internet gateway. We still not able to reach to the IA route from the spoke router in this case right?

    Davis

  2. Hi Davis,

    Good question and yes, this is an issue. In my example I could use default routes since the routers are directly connected. In a real network however you are probably using a default route towards the ISP.

    In that case you shouldn’t use a default route but a summary route instead.

    Rene

  3. In the “Non Broadcast” configuration section ; I’m a little bit confused about the neighbor command.

    With my GNS3 IOS :

    * The neighbor command expects that the interface be configured as point-to-multipoint. And, finally ; it does not turn the interface to NBMA.

    * The command ip ospf network non-broadcast does perfectly the job.

    What exactly is the difference between the two commands ?

  4. Hello Maodo

    In order to configure the network as an NBMA, it is necessary to enter the ip ospf network non-broadcast command. If that is done, then in order to get the OSPF functioning correctly, the neighbor command must be issued. This is because when you configure the interface as an NBMA, neighbor relationships will not form automatically.

    Now in @ReneMolenaar’s lesson, the command ip ospf network non-broadcast was not actually included in the lesson. It was assumed. It might be worth clarifying that in the lesson. I will let @ReneMolenaar know…

    I hope this has been helpful!

    Laz

  5. For last ospf example, it seems the configuration below is missing ?
    network 1.1.1.1 0.0.0.0 area 0

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