Saturday, February 22, 2020

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:
Hub(config)#router ospf 1
Hub(config-router)#neighbor 172.16.123.2 
Hub(config-router)#neighbor 172.16.123.3 
(config)#interface Tunnel 0
(config-if)#ip ospf priority 0
Also make sure that the spoke routers never become DR or BDR. Let’s see if this works:
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 6 msec 6 msec
  2 172.16.123.3 8 msec 8 msec *
Everything is still working!

Point-to-multipoint

This network type also works very well. We will have automatic neighbor adjacencies and there is no DR/BDR election so we don’t have to worry about the priority of our spoke routers. Let’s change the network type (and make sure the neighbor command is gone):
Hub, Spoke1 & Spoke 2(config)#interface Tunnel 0
Hub(config-if)#ip ospf network point-to-multipoint
The hub will have two neighbors:
Hub#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -        00:01:43    172.16.123.3    Tunnel0
2.2.2.2           0   FULL/  -        00:01:43    172.16.123.2    Tunnel0
Above you can see we don’t have a DR/BDR election anymore. 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:08, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:00:58, 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:08, Tunnel0
O        172.16.123.3/32 [110/1000] via 172.16.123.3, 00:00:58, 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:01:23, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2001] via 172.16.123.1, 00:01:13, 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:23, Tunnel0
O        172.16.123.3/32 [110/2000] via 172.16.123.1, 00:01:13, 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:01:29, Tunnel0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2001] via 172.16.123.1, 00:01:29, 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:29, Tunnel0
O        172.16.123.2/32 [110/2000] via 172.16.123.1, 00:01:29, Tunnel0
Each router has a full routing table. Take a close look at the different next hop values, they all point to the hub router. This is no problem for DMVPN phase 1  since everything will go through the hub anyway but in phase 2, this will cause issues (we will see this later).
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 6 msec 8 msec
  2 172.16.123.3 11 msec 7 msec *
Traffic is flowing through the hub, no issues here.

Point-to-multipoint non-broadcast

We can also use the point-to-multipoint non-broadcast network type. It’s the exact same thing but we have to configure static neighbors:
Hub, Spoke1 & Spoke 2(config)#interface Tunnel 0
Hub(config-if)#ip ospf network point-to-multipoint non-broadcast
Hub(config)#router ospf 1
Hub(config-router)#neighbor 172.16.123.2 
Hub(config-router)#neighbor 172.16.123.3 
Just like non-broadcast, it defeats the purpose of having dynamic neighbors if we have to configure OSPF neighbors manually but it works. The hub has two neighbors:
Hub#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -        00:01:43    172.16.123.3    Tunnel0
2.2.2.2           0   FULL/  -        00:01:43    172.16.123.2    Tunnel0
And we still have connectivity:
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 6 msec 8 msec
  2 172.16.123.3 11 msec 7 msec *
Excellent, it’s working.
You have now seen all the different OSPF network types on DMVPN phase 1. As you have seen, there’s quite some stuff in the routing tables. All traffic goes through the hub so our spoke routers don’t really need to know everything. Unfortunately, it’s impossible to summarize within the area. We can reduce the number of routes however by changing the DMVPN area into a stub or totally stub area…

Stub Area

Let’s convert the DMVPN area into a stub area, we’ll use area 1 for this:
Hub(config)#router ospf 1
Hub(config-router)#network 172.16.123.0 0.0.0.255 area 1
Hub(config-router)#area 1 stub no-summary 
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
Spoke1(config-router)#area 1 stub
Spoke2(config)#router ospf 1
Spoke1(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
Spoke2(config-router)#area 1 stub
Now 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:04:42, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/1001] via 172.16.123.3, 00:04:09, 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:05:49, Tunnel0
O        172.16.123.3/32 [110/1000] via 172.16.123.3, 00:05:49, Tunnel0
Spoke1#show ip route ospf

O*IA  0.0.0.0/0 [110/1001] via 172.16.123.1, 00:10:35, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2001] via 172.16.123.1, 00:09:57, 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:10:35, Tunnel0
O        172.16.123.3/32 [110/2000] via 172.16.123.1, 00:10:35, Tunnel0
Spoke2#show ip route ospf

O*IA  0.0.0.0/0 [110/1001] via 172.16.123.1, 00:10:32, Tunnel0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2001] via 172.16.123.1, 00:10:32, 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:10:32, Tunnel0
O        172.16.123.2/32 [110/2000] via 172.16.123.1, 00:10:32, Tunnel0
The two spoke routers still know all prefixes within the DMVPN area but they don’t see the 1.1.1.1/32 route from the hub anymore.
hostname Hub
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
 ip address 172.16.123.1 255.255.255.0
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip ospf network broadcast
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 !
interface GigabitEthernet0/1
 ip address 192.168.123.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 172.16.123.0 0.0.0.255 area 0
!         
end
hostname Spoke1
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
 ip address 172.16.123.2 255.255.255.0
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.123.1 192.168.123.1
 ip nhrp map multicast 192.168.123.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.123.1
 ip ospf network broadcast
 ip ospf priority 0
 tunnel source GigabitEthernet0/1
 tunnel destination 192.168.123.1
!
interface GigabitEthernet0/1
 ip address 192.168.123.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 172.16.123.0 0.0.0.255 area 0
!
end
hostname Spoke2
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
 ip address 172.16.123.3 255.255.255.0
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.123.1 192.168.123.1
 ip nhrp map multicast 192.168.123.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.123.1
 ip ospf network broadcast
 ip ospf priority 0
 tunnel source GigabitEthernet0/1
 tunnel destination 192.168.123.1
!
interface GigabitEthernet0/1
 ip address 192.168.123.3 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 172.16.123.0 0.0.0.255 area 0
!
end

Conclusion

You have now seen all the different OSPF network types running on DMVPN phase 1. It works but it’s not ideal, RIP, EIGRP and BGP will work better than OSPF on DMVPN.
All spokes in the DMVPN network have to be in the same area and when something changes, all routers have to run SPF…also we can’t do any summarization within the area.
I hope you enjoyed this lesson, if you have any questions feel free to leave a comment!

No comments:

Post a Comment