cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
229
Views
1
Helpful
5
Replies

Spoke to Spoke broadcast communication does not work (for lan hosts)

nefalim_a
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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)


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

View solution in original post

5 Replies 5

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?


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

nefalim_a
Level 1
Level 1

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

 

 

 

 

 

 

 

 

 

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)


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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

 

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


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking for a $25 gift card