DMVPN and OSPF backup tunnel routing

[marc-berger]

I am in the beginning phase where a customer wants to change their routing protocol from EIGRP to OSPF on their network. I noticed that they have a DMVPN setup with about 25 sites each with a single tunnel interface going back to their respective wan block (HUB) and the other to their DR site (backup HUB).

They control the backup connection to their DR by using/manipulating the EIGRP AD so that connection is not preferred. ie. so EGRIP doesn't ECMP across all tunnel connections (to their wan and DR site). I have not been able to find a way to alter the ospf metrics to accomplish this same behavior. Is there a way to do this with OSPF?

[Joseph W. Doherty]

Are we talking about two DMVPN setups, one for primary and one for backup, or backup being in the same DMVPN setup?

Is the DMVPN network, one network, or p2p from hub to each site?

[marc-berger]

Sorry, i failed to mention this. The primary and backup are part of the same dmvpn setup and uses EIGRP currently. The tunnel 251 interface neighbors up on eigrp with the wan block (primary path) and the DR wan (backup) on eigrp using one network 10.10.251.0/24. They currently control the backup path manipulating the eigrp AD going to the DR wan using a higher AD (92) so the traffic goes out the primary path using the default AD (90).  Hope that makes a little more sense. When they migrate to OSPF can I manipulate the OSPF metrics on the backup path?

[paul driver]

Hello

---

@marc-berger wrote:
 When they migrate to OSPF can I manipulate the OSPF metrics on the backup path?

---

You dont need to, specifying the secondary hub with a high NHS priority will make the primary be preferred

ip nhrp nhs <hub1> cluster 1
ip nhrp nhs <hub2>priority 255 cluster 1

[Kanan Huseynli]

Hi,

Distance also supported in OSPF, but since it is link state better to work with cost on DR site. Increase cost on DR site for LAN interface, so it will advertise routes with higher cost.

Also, OSPF does not very well fit to hub&spoke design. You need carefully consider ospf network type and area design.

[MHM Cisco World]

First you must sure that hubs elect as DR/BDR,

Then by change cost you can force traffic through tunnel to primary hub. 

[marc-berger]

Yes, i am aware that using a DR and BDR will require some design considerations ie keeping the hub (s) as the DR and BDR while ensuring the spokes never take on the role of a DR or BDR.  However, given i have one Tunnel interface neighboring up on 10.10.251.0/24 (one network) with with my  wan block (primary site) using eigrp currently and also to the DR site (backup site) also on eigrp when they migrate over to ospf can i adjust the cost per neighbor? I believe it would have to be on a point to multipoint non broadcast (not network type broadcast where it elects a DR/BDR) to adjust the ospf metric  per neighbor .

[paul driver · Accepted solution]

Hello
You mention EIGRP DMVPN but also mention OSPF?  It seems there are two questions here

• protocol migration from eigrp to ospf within a dmvpn environment

For protocol migration, you could enable ospf process and change its default administrative distance to be less preferred to eigrp internal/external routes, then create new DMVPN hub/spokes running ospf. this will allow you to check the routing tables of ospf but it will not change the existing production routing of the network

router ospf 1
distance 171

As/when you are ready to migrate over to ospf to test then decrease the ospf administrative distance to be lower then eigrp

router ospf 1
distance 89
 

• path manipulation within dmvpn

This can be accomplished within DMVPN  OSPF using the cluster/priority features on the spokes.

DMVPN primary hub
interface Tunnelx
ip ospf network broadcast
ip ospf x area 0
ip ospf priority 100

DMVPN secondary hub
interface Tunnelx
ip ospf network broadcast
ip ospf x area 0
ip ospf priority 90




DMVPN spoke:
Int tun x
ip nhrp map <hub1> <hub 1 nbma>
ip nhrp map multicast <hub 1 nbma>
ip nhrp map <hub2> <hub 2 nbma>
ip nhrp map multicast <hub 2 nbma>
ip nhrp nhs <hub1> cluster 1
ip nhrp nhs <hub2>priority 255 cluster 1
ip nhrp nhs cluster 1 max-connections 1
ip ospf network broadcast
ip ospf x area 0
ip ospf priority 0   ( note the primary hub above will have the highest priority value to the secondary hub and all spokes)

[marc-berger]

Thank you. You answered my question on how to prioritize the traffic to the primary hub. I wasn't sure if it was feasible to do with ospf broadcast or not so that is greatly appreciated. I was thinking i may have to change the network type to ospf point to multipoint non broadcast to statically change the cost per neighbor. THanks for the tip regarding migration also!