Hi, I just realized the other spoke's IP arrives as BGP route. I think this is not right.
The way it should work is that if there's multiple Hubs they will exchange full Spoke route database with BGP, but Hubs should not announce those to Spokes - I suspect this is a side effect of that. The config I privately use has on Hubs: neighbor DMVPN prefix-list no-hosts out .. ip prefix-list no-hosts seq 5 permit 0.0.0.0/0 le 30 Alternatively, as long as you have only single Hub you could remove the 'redistribute nhrp' from BGP which has the same effect of not announcing spoke host routes. But if you have more than one Hub then you need the redistribute config with the route filters. I think in Cisco FlexVPN this works more transparently because normal spokes do not use BPG at all; instead they get the Hub routes as "IKE routes" announced over IKEv2, and that list does not have the spokes ever. The hub should be announcing the GRE subnet via BGP explicitly, so you'll need also for Hub's BGP config: network 10.10.10.0/24 If you ever add other Hubs they should be in different peer group that get the full routing database including spoke host routes. Rough overview of this is explained in README.nhrpd 'Routing Design' but it's omitting certain parts of this. Need to also add this to the BGP config example. Hope these three Hub specific BGP configs will fix the issue. I will update the README.nhrpd accordingly. And try to add an example. Timo On Tue, 24 Oct 2017 16:45:36 -0400 Lee Cardona <lee.card...@gmail.com> wrote: > Timo, > > After some additional investigation, I was able to discover that the > version of frr I was using (3.0rc1 from Aug 9th) lacked some recent > fixes to the route distribution and other nhrp/bgp fixes and updates. > > I have since rebuilt my set up with the latest frr build of #1913 > Oct. 10th this past weekend. > > Source code from: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-1913/ > > Everything looks stable and debug log comes up clean. > > Now when pinging from tunnel interfaces, spoke to spoke (S2S) tunnel > comes up and switches from phase 1 (via hub) to phase 3 (spoke to > spoke) after ~ 10 pings following hub redirect. > > However, I can not get phase 3 spoke to spoke to initiate if the > pings are from the back-end networks. > > > In summary, > > - it appears phase 1 works fine whether its tunnel to tunnel, > back-end to back-end, tunnel to back-end or back-end to tunnel over > the hub > - it appears phase 3 S2S works only when its tunnel to tunnel > - phase 3 S2S does not work if its back-end to back-end, tunnel to > back-end or back-end to tunnel > > I'm just not sure if it's a configuration issue on my end with nhrp > or bgp or if this is a bug? > > Here is a link to a gist that has more detail explanation and the > configs of the hub and spokes plus debug output. > > https://gist.github.com/leecardona/e9230cc42d3a2ab557087d8a63087450 > > > Super thanks again for all the help! > > --Lee > > > On Tue, Oct 17, 2017 at 1:34 AM, Timo Teras <timo.te...@iki.fi> wrote: > > > Hi, > > > > On Mon, 16 Oct 2017 13:53:47 -0400 > > Lee Cardona <lee.card...@gmail.com> wrote: > > > > > Hi Timo et al, > > > > > > I'm having a problem with shortcuts not installing with > > > ubuntu/strongswan/Frr. > > > > > > Setup is as follows: > > > > > > 1 hub 2 spokes (single machine lab setup with lxc) > > > > > > strongswan loads dmvpn conns ok > > > both spokes register fine > > > Hub has [N] routes back to spokes > > > Spokes have single [N] route back to hub... spoke to hub pings > > > fine and vise-a-versa > > > ibgp works fine - hub bgp sees routes from spokes and spokes see > > > routes from hub and reflected routes sent by hub from other spoke > > > in RIB > > > > Nice. > > > > > But the FIB does not install these routes > > > > > > and a > > > > > > sh ip nhrp shortcuts > > > > > > returns no entries > > > > > > nhrp nflog-group 1 is enabled on hub > > > > > > and iptables NFLOG rule also installed on hub > > > > Could show the iptables rule on hub? > > > > Please also verify from the 'iptables -v -L' command's statistics > > output that the iptables rule is matching packets. > > > > Any logs? Please enable nhrp debugging and post the logs on hub, and > > one spoke. > > > > > Additonally, I've turned on 'nhrp nflog-group 1' along with > > > iptables rule on hub and spokes but not sure if this is needed on > > > spokes. > > > > Spoke will not need this. This is basically enabling kernel to > > notify nhrpd about packets being routed non-optimally. > > > > > Also put 'ip nhrp redirect' in addition to ' ip nhrp shortcut' on > > > spokes but also not sure if 'ip nhrp redirect' is needed on > > > spokes. > > > > Not needed either. "Redirect" concerns hub only. It enables nhrpd to > > send NHRP Traffic Indication messages based on the above mentioned > > kernel notifications. > > > > > I also tried adding 'ip nhrp shortcut' on hub but again not sure > > > if this does anyting on the hub. > > > > This might be needed if you have multiple hubs, and not all spoke > > are connecting to all hubs. In this case this would enable hub to > > initiate shortcuts to spokes that are not directly connected. > > > > > After a long weekend I just can't seem to figure this one out. > > > Help pls! > > > > > > Also have full debug log from frr if that will help > > > > Yes please :) > > > > > router bgp 65000 > > > bgp router-id 10.0.0.1 > > > bgp default show-hostname > > > no bgp default ipv4-unicast > > > neighbor DMVPN peer-group > > > neighbor DMVPN remote-as 65000 > > > neighbor DMVPN disable-connected-check > > > neighbor DMVPN advertisement-interval 1 > > > neighbor 10.0.0.6 peer-group DMVPN > > > neighbor 10.0.0.7 peer-group DMVPN > > > > Btw. FRR should support BGP listen-range feature, so you should be > > good on hub with just: > > > > bgp listen range 10.0.0.0/8 peer-group DMVPN > > > > Instead of listing all spokes. Unfortunately this is not available > > on Quagga (at the time of writing this). > > > > Timo > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ opennhrp-devel mailing list opennhrp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
