In the image above we are setting up DMVPN phase 2. R1-3 are spokes and R5 is the hub. Current reachability should not matter all that much because it’s one broadcast domain between the four routers. IP addresses are assigned below:
R5/Hub:
Physical IP – Gig0/0 – 96.76.43.137/29
VPN/Tunnel IP – Tu0 – 155.1.0.5
Loopback – L5 – 5.5.5.5/32
R1/Spoke:
Physical IP – Gig0/0 – 96.76.43.140/29
VPN/Tunnel IP – Tu0 – 155.1.0.1
Loopback – L1 – 1.1.1.1/32
R2/Spoke:
Physical IP – Gig0/0 – 96.76.43.138/29
VPN/Tunnel IP – Tu0 – 155.1.0.2
Loopback – L2 – 2.2.2.2/32
R3/Spoke:
Physical IP – Gig0/0 – 96.76.43.137/29
VPN/Tunnel IP – Tu0 – 155.1.0.3
Loopback – L3 – 3.3.3.3/32
The config on the hub/R5 is below:
The config on any spoke is below, minor IP changes:
On each router we’re running EIGRP AS 1 that is advertising each loopback and participating/creating adjacency on the physical interface. The main difference between the hub vs. spoke configuration are the NHS, map and map multicast commands. All of them specifying the hub/server/hub IPs.
Now on the hub we’ll see the below screen after entering ‘show dmvpn’:
The attribute D on the right means they were setup dynamically. Now looking at routes sourced from EIGRP, we receive the following from a spoke:
R1 is receiving the loopback of R5, as well as a couple routes from a router running EIGRP on the other side (outside of DMVPN) of R5. A router advertising it’s own loopback of 4.4.4.4/32.
Unfortunately we are not receiving routes from the other DMVPN spokes. This is due to EIGRP being a (hybrid) distance vector protocol that uses Split Horizon as loop avoidance. To fix this the hub will need to turn split horizon off.
After this there is a DUAL resync and the routes start to come through.
Spoke to Spoke communication:
As of right now if a spoke wants to speak to another spoke, it will first have to traverse the hub. This is due to EIGRP changing the next hop value to its tunnel 0 interface. This can be changed with the command below on R5 tun0:
Now the routes on R1 show the VPN address of each spoke as the next hop. If a traceroute is completed from R1’s loopback to R2’s loopback, the first hop shows it goes to the hub, second to the spoke. If this is performed again however it can be seen that now there’s spoke to spoke communication. In addition on R1 we’ll see with ‘show dmvpn’ that there’s a dynamic tunnel created between the two.
OSPF:
All of this can be completed with other routing protocols. EIGRP has been removed from each router and now this will be completed with OSPF.
For the spokes on each tunnel and loopback interface we’re going to enable ‘ip ospf 1 area 0’, and on the tunnel interface we will change the network type via ‘ip ospf network broadcast’.
The two commands above will be added on the hub as well, but the hub also needs the command ‘ip ospf priority 255’ under the tunnel interface. The reason for this is because we cannot have any non-hub device as the Designated Router. If a spoke becomes the DR then updates will not work because each spoke does not statically have a connection between the two devices. The hub is needed for the DMVPN spoke to spoke connectivity. Routing updates in this situation will eventually fail.
An additional command to make sure a spoke does not become the DR is by changing their priority to 0 so they take themselves out of the election process.
An ‘ip ospf priority 0’ shows that all of the spoke neighbors are now DROTHERs, so they’ll never even be a BDR.
Now on R1 when looking at ‘show ip route ospf’ we’ll see the routes for the neighbors come in. On the routes to other DMVPN spokes, we’ll see that the next hop is not modified like it was originally in EIGRP.
To reach 3.3.3.3, the next hop value is the VPN address of R3 instead of R5, the hub. This is why OSPF Broadcast network type is used. The DR process does not modify next hop. The limitation to using OSPF in DMVPN however has to do with needing to specify DR and not being able to summarize. In this scenario all routers are in area 0.
mickx009.org 