Lesson Contents
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 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:
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.
Hi Harvinder,
Take a look below:
... Continue reading in our forumRene 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
... Continue reading in our forumsee output below
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.
Hi @stlourenco,
That is a short answer…you can’t IS-IS is not supported in DMVPN.
IS-IS doesn’t use IP for routing and NHRP only supports IP for address resolution.