01-14-2025 01:09 PM
Hello Everyone
In the Diagram i have create a Hub and spoke DMVPN design
Green circles are just the local hosts with DHCP addresses obtained.
Red circles are the DHCP servers that assign ip addresses to the local hosts.
Blue circles are the DMVPN configured devices.( iosv-4 is the HUB device and all other devices in blue circles are the spokes).
On the problem now:
The DMVPN Design works fine so the hub and spoke connectivity works fine.
I have simple 1 hub over tunnel 100 configured and all other devices are spokes in the BLUE circles.
HUB#
interface tunnel 100
ip address 100.1.1.1 255.255.255.0
tunnel source gig0/0
tunnel mode gre multipoint
ip nhrp network-id 100
ip nhrp map multicast dynamic
ip nhrp redirect
Spokes (they all have the same configuration and only ip addresses changing for 2.3.4.5.6 spokes)#
interface tunnel 100
ip address 100.1.1.2 255.255.255.0
tunnel source gig0/0
tunnel mode gre multipoint
ip nhrp network-id 200
ip nhrp shortcut
ip nhrp nhs 100.1.1.1 nbma 172.16.1.2 multicast
The problem is that host to host connectivity works only between (hub and spoke) but not spoke to spoke.(the hosts obtain their ip
addresses via DHCP).
Why communication for local lan hosts between spoke to spoke is not working?
Does it have to do with the design or i am missing any configuration?
Any idea or help will be much appreciated.
Thanks in advance
Solved! Go to Solution.
01-14-2025 03:01 PM
Hello
On you hub as you are using eigrp in dmvpn phase 3 they would really be no need to disable split horizon if you were summarizating towards the spokes but in this instance is looks like your not so suggest you disable both split-horizon & next-hop-self on the hub
As for all lan subnets facing interfaces, passive those in eigrp unless that is you want them to form eigrp adjacency's
Hub
int tun 100
no ip next-hop-self eigrp 500
no ip split-horizon eigrp 500
Hub/Spokes
router eigrp 500
passive-interface xxx (lan facing interface)
01-14-2025 02:10 PM
Hello
At first glances your topology doesn't look correct unless im mistaken you have a single rtr and a spoke that in essence share the same lan or is that just the way you have circled them together ?( in green) - meaning iosv12-13 & 14-15 & 20-21 & 22-23 are in separate lans?
Your transit network looks like iosv0-3 rtr correct?
Do you have full reachability on that transit underlay and If so what routing processes are you running on it and for the DMVPN overlay?
Maybe share in some attached files the run cfg for the hub and spokes?
01-14-2025 02:37 PM
Hello Paul
Your transit network looks like iosv0-3 rtr correct?(yes)
Do you have full reachability on that transit underlay and If so what routing processes are you running on it and for the DMVPN overlay?(yes that is an MPLS BGP VPN Design with Ospf underlay and vrf towards the Hub and spoke devices and it works fine).
iosv12-13 & 14-15 & 20-21 & 22-23 are in separate lans?(yes all of them in separate vlan).
The vlans for iosv12 and iosv13 are behind the HUB and they can reach every other vlan in the topology and all the other vlans can reach these 2 vlans.
But spoke to spoke vlans does not work for some reason.
The Dmvpn is configured with an Eigrp process and i have used redistrubute connected on all of the Devices in Red circle (the DHCP server devices that connect to their corresponding hub and spokes).
on the hub and spoke devices it is
router eigrp 500
network 100.1.1.1 0.0.0.0 (the Dmvpn tunnel interface)
network 51.1.1.1 0.0.0.0 (the interface towards the DHCP server device in red )
on the DHCP servers in the (red circles) it is
router eigrp 500
network 51.1.1.2 0.0.0.0 (the interface that is directly connected to the Hub or corresponding spokes)
redistribute connected (and this is applied to all the devices in RED circle also to redistribute the local lan networks to the DMVPN hub and spoke devices in the network)
(they are learning only the HUBs redistributed networks and not from each other).So they can reach only the hub lan networks.
And spoke lan to spoke lan is not working.
Only spoke lan to Hub lan is working.
Basically the spokes are not learning the redistributed networks from the other spokes lan networks and as such they cannot reach each other.They can reach only the HUB and i was wandering maybe it has to do with the design and not the configuration.
But this is a DMVPN Phase 3 normally it shouldn't be achieved spoke to spoke lan connectivity automatically ?
Maybe it does not work from a design perspective ?
Thanks for your support and your time Paul
01-14-2025 03:01 PM
Hello
On you hub as you are using eigrp in dmvpn phase 3 they would really be no need to disable split horizon if you were summarizating towards the spokes but in this instance is looks like your not so suggest you disable both split-horizon & next-hop-self on the hub
As for all lan subnets facing interfaces, passive those in eigrp unless that is you want them to form eigrp adjacency's
Hub
int tun 100
no ip next-hop-self eigrp 500
no ip split-horizon eigrp 500
Hub/Spokes
router eigrp 500
passive-interface xxx (lan facing interface)
01-14-2025 03:21 PM
Hello Paul
Magically it worked
I want to thank you so much.
Spent more than 4 hours to find out why.....connection was not working.
Thanks in advance again
01-15-2025 12:29 AM
Hello
Thank you for sharing and for the marking your post a being solved.
@nefalim_a wrote:
Spent more than 4 hours to find out why.....connection was not working
FYI - Eigrp implements a loop prevent mechanism call Split horizon.
Basically this is a feature that negates reverse routing of a network prefix, meaning to not to advertised a learned prefix out of the same interface it was learned on, so in a dmvpn hub/spoke design like the one you have thats why the spokes subnets were not being learning for each other due to split horizon rule on the hub rtrs tunnel interface.
Going a bit further eigrp also incorporates poison reserve which is an additional safe feature to split-horizon that in certain circumstances will set an very high metric value in the eigrp update to mark(poison) a prefix as unreachable as such the receiving rtr will immediately withdraw that prefix so not to potentially cause any route feedback/loop occurring
Next hop self – by default when the update is sent to the spoke, the next hop field in that packet is empty as such the receiving rtr will “assume” the next hop is the Hub rtr tunnel ip, as/when you disable next hop-self that next hop field in the packet is populated with the originating rtr of the prefix, in this case the other spokes tunnel ip
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