05-02-2023 09:48 PM
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!
Solved! Go to Solution.
05-03-2023
12:25 PM
- last edited on
05-04-2023
02:10 AM
by
Translator
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!
05-03-2023
02:29 PM
- last edited on
05-04-2023
02:20 AM
by
Translator
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.
05-03-2023
12:06 AM
- last edited on
05-04-2023
02:09 AM
by
Translator
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
05-03-2023
12:25 PM
- last edited on
05-04-2023
02:10 AM
by
Translator
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!
05-03-2023 12:25 AM - edited 05-03-2023 12:28 PM
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 ?
05-03-2023 01:02 PM
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...
05-03-2023 01:16 PM
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
05-03-2023
02:29 PM
- last edited on
05-04-2023
02:20 AM
by
Translator
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.
05-03-2023 03:02 PM
That worked perfectly.
All of the routes are showing up properly now. Thank you very much for your assistance!
05-03-2023 03:03 PM
You are so so welcome friend.
Have a nice day
MHM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide