DMVPN routing Issues

[Tony Basile]

Greetings,

This is a PoC and I'm a bit new to this. That being said, I tried kicking this one around a bit just to see if i could figure it out. It seems I need a second (third, or fourth?) set of eyes please.

My goal is to set up a dual hub dmvpn scenario utilizing two service providers. The underlay network consists of a very basic eigrp setup, but the overlay is ospf area 0 using an internal vrf. The switch allowing connectivity between the hubs and spokes is just a flat, layer 2 switch.

Each dmvpn spoke is set up exactly the same, naturally. My configuration seems to be working up to the hub nhs address, however none of the spokes can reach beyond the hubs to the HQ_NET networks of 10.1.3.0/30, 10.1.3.4/30, or 10.2.3.0/24 even though the tunneled traffic is populated in the hub vrf RIB.

Any feedback is greatly appreciated!

[paul driver]

Hello
Your underlay network is segregated from the DMVPN overlay, as a test remove the DMVPN tunnels and OSPF from the vrf, Also you need to disable eigrp split horizon check on the NHS tunnels if you running eigrp over them,  if OSPF on broadcast network then set the hub ospf priorities and the spoke to be DRothers

HUBS (eigrp)
int tun x
no ip split-horizon eigrp 100
no ip next-hop-self eigrp 100

HUBS (OSPF)
int tun x
Ip ospf pririoty 100


SpokesOSPF)
int tun x
Ip ospf pririoty 0

[Tony Basile · Accepted solution]

Hi Paul,

Thanks for your prompt reply!

Per your recommendation, I removed the VRF from all interfaces and tunnels. I noticed that the HQ_NET router's RIB had the overlay tunnel network in it's database, however the spokes did not... I placed the VRF back into play, and noticed the same results in the RIB.

The thought behind the VRF was just to acheive segregation from the theoretical internet global routing table, and I had at one point thought of disabling EIGRPs split horizon at first. I had also removed EIGRP completely and used only static routes, but the issue still persisted.

To allow connectivity, I used static default routes with an IP SLA for failover to the secondary hub.

The following configurations were made to all spokes:

ip sla 1
icmp-echo 192.200.3.5 source-interface gi0/0
frequency 10
timeout 5000
!
ip sla schedule 1 start-time now life forever
!
track 11 ip sla 1 reachability
!
! Route to primary HUB1 with SLA to track reachability
ip route vrf INTERNAL 0.0.0.0 0.0.0.0 Tu100 10.1.1.100 track 11
!
! Floating static route to secondary HUB2 as a failover
ip route vrf INTERNAL 0.0.0.0 0.0.0.0 Tu101 10.1.2.100 5

Thanks again for your assist. Sometimes, you just need a second pair of eyes!

[MHM Cisco World]

I dont understand 
in Hub there is Eigrp and OSPF, 
for what eigrp you use here ? are you using it for routing protocol between HQ and R5&6 ?

[Tony Basile]

The reasoning for EIGRP was simply just an underlay transport. I could have used static routes if I'd wanted, but for the sake of making things quick, EIGRP was used...

[MHM Cisco World]

sorry, I read your post again and you already mention that the EIGRP using for underlay. 
NOW 
with respect to your solution I will run lab and check why overlay OSPF and underlay EIGRP is not work.
update you after hours 

[MHM Cisco World · Accepted solution]

I found the reason, 
you config OSPF with single area, that correct except the the network types of DMVPN need to change to be 

ip ospf network broadcast 

also you must sure that any spoke never select as DR or BDR. so adjust the tunnel interface priority to be higher and change priority of spoke to be 0. 

[Tony Basile]

That worked perfectly.

All of the routes are showing up properly now. Thank you very much for your assistance!

[MHM Cisco World]

You are so so welcome friend.

Have a nice day

MHM