Hi colleagues, I tried to implement NHRP using FRR 7.5 (Ubuntu 20) and facing so much issues, that I'm in doubts that NHRP is production-ready. Is it? My test topology is the following: + NHRP: 10.0.0.254 | +-----------+ | +------------+ | | | | | | HUB +-----+ | Spoke (S1) | | 10.9.8.53 | | | 10.9.8.241 | | | +------+ | +--+--------+ | +------------+ | | NHRP: 10.0.0.1 | + LAN: 10.2.1.241/24 | +---+-+ | | +-----+ | Routed | +---- network | | +-----+ +---+--+ | | +------+-----+ | | | Spoke (S2) | | 10.1.2.242 | | | +------------+ NHRP: 10.0.0.2 LAN: 10.2.2.242/24 At the moment, I'm trying to play without IPSec encryption (so no 'tunnel protection' on the gre interfaces) and configurations of nodes (HUB, S1; S2 is similar to S1) are: HUB (NBMA 10.9.8.53): nhrp nflog-group 1 ! ip route 10.0.0.0/24 Null0 ! interface gre1 description DMVPN Tunnel Interface ip address 10.0.0.254/32 ip nhrp map 10.0.0.1 10.9.8.241 ip nhrp map 10.0.0.2 10.1.2.242 ip nhrp network-id 1 ip nhrp redirect ip nhrp registration no-unique ip nhrp shortcut tunnel source eth1 ! router bgp 65000 bgp router-id 10.0.0.254 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 disable-connected-check neighbor 10.0.0.1 update-source 10.0.0.254 neighbor 10.0.0.2 remote-as 65000 neighbor 10.0.0.2 disable-connected-check neighbor 10.0.0.2 update-source 10.0.0.254 ! address-family ipv4 unicast network 10.0.0.0/24 redistribute nhrp neighbor 10.0.0.1 route-reflector-client neighbor 10.0.0.2 route-reflector-client exit-address-family S1 (NBMA 10.9.8.241): ip route 10.2.1.0/24 Null0 ! interface gre1 description DMVPN Tunnel Interface ip address 10.0.0.1/32 ip nhrp network-id 1 ip nhrp map 10.0.0.254 10.9.8.53 ip nhrp redirect ip nhrp registration no-unique ip nhrp shortcut tunnel source eth0 ! router bgp 65000 bgp router-id 10.0.0.1 no bgp ebgp-requires-policy neighbor 10.0.0.254 remote-as 65000 neighbor 10.0.0.254 disable-connected-check neighbor 10.0.0.254 update-source 10.0.0.1 ! address-family ipv4 unicast network 10.2.1.0/24 exit-address-family S2 is same as S1 except is has nbma address 10.1.2.242 and NHRP address is 10.0.0.2 On all hosts configuration of GRE intfs is same (except IP address): ip tunnel add gre1 mode gre key 42 ttl 64 ip addr add 10.0.0.xxx/32 dev gre1 ip link set gre1 up The issues are: - unlike all examples (incl. official), NHRP neighborhood is not established until I specify explicit mapping on Hub, using 'ip nhrp map ...' - though, if I do 'ip link set gre1 down' and then 'up', FRR loses 'ip nhrp map ...' config and, thus, loses connectivity - if, on spoke, I use instead 'ip nhrp nhs dynamic nbma 10.9.8.53' - it persists between interfaces down/up events, but, in fact, it never finds nhrp hub, keeping forever in the following state: s1# sh ip nhrp Iface Type Protocol NBMA Flags Identity gre1 local 10.0.0.1 - - - nevertheless, while using 'ip nhrp map' everywhere (incl. S2) and see established neighborship and BGP and, thus, LAN prefixes announces, I try to ping S1's LAN from S2: * before ping S2's RT shows the route: root@s2:~# ip route 10.2.1.0/24 nhid 32 via 10.0.0.254 dev gre1 proto bgp metric 20 onlink first two ping go through hub and then, after it signals to build the direct tunnel, connectivity passes away: root@s2:~# ping 10.2.1.241 PING 10.2.1.241 (10.2.1.241) 56(84) bytes of data. 64 bytes from 10.2.1.241: icmp_seq=1 ttl=64 time=2.31 ms 64 bytes from 10.2.1.241: icmp_seq=2 ttl=64 time=1.10 ms From 10.0.0.2 icmp_seq=3 Destination Host Unreachable From 10.0.0.2 icmp_seq=4 Destination Host Unreachable ^C but S2's RT is expanded with new entry (10.2.1.241): root@s2:~# ip route 10.2.1.0/24 nhid 38 via 10.0.0.1 dev gre1 proto bgp metric 20 onlink 10.2.1.241 nhid 29 dev gre1 proto nhrp metric 20 Questions are: 1) whether it's possible to keep as less as possible configuration on the Hub, avoiding direct mapping for every spoke? (here in tests I used BGP, but want to move to OSPF and get rid of any pre-spoke configuration on hubs) 2) disappearing of 'ip nhrp map' during interface up/down - whether it is bug or feature? If latter - what is rationale behind this? 3) 'ip nhrp nhs dynamic' do not establish NHRP neighborhood - what I'm doing wrong? 4) peer unreachability after NHRP redirect - is it case for 'tunnel protection' or another issue? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison