DMVPN Phase 3 OSPF Routing

In this lesson we’ll take a look how to configure OSPF on a DMVPN phase 3 network. Here’s the topology we will use:

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

There is one hub router and two spoke routers.

Configuration

In this lesson we'll take a look how to configure OSPF on a DMVPN phase 3 network. Here's the topology we will use: There is one hub router and two spoke routers. Configuration Tunnel Interfaces Let's start with a basic DMVPN phase 3 configuration: Hub(config)#interface Tunnel0 Hub(config-if)#ip add


Tunnel Interfaces

Let’s start with a basic DMVPN phase 3 configuration:

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)#ip nhrp redirect
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
Spoke1(config-if)#ip nhrp shortcut
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
Spoke2(config-if)#ip nhrp shortcut

Let’s make sure the tunnels are working:

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:00:04     D
     1 192.168.123.3      172.16.123.3    UP 00:00:03     D

We see two NHRP registrations. Let’s do a quick ping from the hub:

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 = 7/8/10 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 = 7/7/8 ms

The tunnels are up and running, time to mess around with OSPF.

OSPF

Point-to-point

The first OSPF network type, point-to-point we can forget about. I’ve showed this in the OSPF configuration for phase 1 and 2 before. We can’t use this since we use GRE multipoint interfaces.

Broadcast

The broadcast network type will work. Let’s enable it on all tunnel interfaces:

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

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

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

Now we can configure some network commands. I’ll turn the loopback interface of the hub into area 0 and the DMVPN network will use area 1:

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 172.16.123.0 0.0.0.255 area 1
Spoke1(config-router)#network 2.2.2.2 0.0.0.0 area 1
Spoke2(config)#router ospf 1
Spoke2(config-router)#network 172.16.123.0 0.0.0.255 area 1
Spoke2(config-router)#network 3.3.3.3 0.0.0.0 area 1

Let’s see what we find in 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:38, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:00:01, 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:23, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:00:13, 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:02:07, Tunnel0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/1001] via 172.16.123.2, 00:02:07, Tunnel0

Each spoke router still has the routes for the other spoke router. Because we use a single area for DMVPN network there’s no way to get around this. Let’s see if spoke1 can reach spoke2 directly:

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 9 msec 6 msec *

No problem at all! The spoke routers will install the NBMA addresses in their NHRP cache:

Spoke1#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:14:26     S
     1 192.168.123.3      172.16.123.3    UP 00:03:38   DT1
Spoke2#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:15:04     S
     1 192.168.123.2      172.16.123.2    UP 00:04:08   DT1

Nothing will change in the routing tables since we already had specific entries and the next hop addresses are correct:

Spoke1#show ip route ospf | include 3.3.3.3
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:11:26, Tunnel0
Spoke2#show ip route ospf | include 2.2.2.2
O        2.2.2.2 [110/1001] via 172.16.123.2, 00:11:39, Tunnel0

Let’s try the next network type.

Non-broadcast

This will be exactly the same as the previous example with the exception that we have to configure static neighbors. Let’s change the tunnel interfaces:

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

Let’s add static neighbors on the hub:

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

Everything else will remain the same. Spoke routers are still able to reach each other directly:

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 9 msec 6 msec *

The information in the NHRP cache will also remain the same:

Spoke1#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:14:26     S
     1 192.168.123.3      172.16.123.3    UP 00:03:38   DT1
Spoke2#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:15:04     S
     1 192.168.123.2      172.16.123.2    UP 00:04:08   DT1

Same thing for the routing tables:

Spoke1#show ip route ospf | include 3.3.3.3
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:11:26, Tunnel0
Spoke2#show ip route ospf | include 2.2.2.2
O        2.2.2.2 [110/1001] via 172.16.123.2, 00:11:39, Tunnel0

Let’s move on to the next network type…

Point-to-multipoint

Time for something different. In DMVPN phase 2, we couldn’t really use this OSPF network type since it changes the next hop. Will it work better for DMVPN phase 3? Let’s find out!

First I will remove the static neighbors:

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

Let’s change the network type on the tunnel interfaces:

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

Let’s make sure we have neighbors:

Hub#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:01:50    172.16.123.2    Tunnel0
3.3.3.3           0   FULL/  -        00:01:58    172.16.123.3    Tunnel0

We do and the advantage of point-to-multipoint is that you don’t have to worry about a DR/BDR election. 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:01:37, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:01:37, Tunnel0
      172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
O        172.16.123.2/32 [110/1000] via 172.16.123.2, 00:01:37, Tunnel0
O        172.16.123.3/32 [110/1000] via 172.16.123.3, 00:01:37, 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:01:41, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2001] via 172.16.123.1, 00:01:41, Tunnel0
      172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
O        172.16.123.1/32 [110/1000] via 172.16.123.1, 00:01:41, Tunnel0
O   %    172.16.123.3/32 [110/2000] via 172.16.123.1, 00:01:41, 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:01:47, Tunnel0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2001] via 172.16.123.1, 00:01:47, Tunnel0
      172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
O        172.16.123.1/32 [110/1000] via 172.16.123.1, 00:01:47, Tunnel0
O   %    172.16.123.2/32 [110/2000] via 172.16.123.1, 00:01:47, Tunnel0

Above you can see that the spoke routers learned each others loopback interfaces. Take a close look at the next hop, that’s the IP address of the hub. You can also see a strange % symbol which I’ll explain in a minute. First let’s try a traceroute from spoke1 to 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.1 9 msec 7 msec 7 msec
  2 172.16.123.3 9 msec 8 msec *

The first time I do this, we can see that our traffic goes through the hub. When I try it a second time, something else happens:

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 5 msec 5 msec *

This time, traffic from spoke1 goes directly to spoke2. How is this possible? Take another look at the routing table:

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

528 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,

    what would be the reason for nbma 192.168.123.2 to inside ip 172.16.123.2 be showing twice under “show dmvpn” command? It has shown several times in your examples.

    Thanks.

  2. Hi Harvinder,

    Take a look below:

    Spoke2#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 NH
    ... Continue reading in our forum

  3. Rene I set this up, Spoke still use Hub as next-hop, Spoke 2 is fine but Spoke 1 still shows 172.6.132.1 as next hop in cef
    see output below

    Spoke 2
    Spoke2#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 32 msec 28 msec 24 msec
      2 172.16.123.2 76 msec 32 msec *
    ... Continue reading in our forum

  4. How should the behavior when it is deployed with the ISIS? It would be nice to post a lesson of ISIS in phases 1, 2 and 3.

  5. Hi Ricardo,

    The difference between OSPF P2MP and broadcast/non-broadcast is that with P2MP, the next hop will always be the hub and with broadcast/non-broadcast it will be the remote spoke. I have an example for this:

    ... Continue reading in our forum

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