<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi colleagues,</p>
<p>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?</p>
<p>My test topology is the following:</p>
<pre> +
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
</pre>
<p>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:</p>
<p>HUB (NBMA 10.9.8.53):</p>
<pre>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
</pre>
<p>S1 (NBMA 10.9.8.241):</p>
<pre>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
</pre>
<p>S2 is same as S1 except is has nbma address 10.1.2.242 and NHRP
address is 10.0.0.2<br>
</p>
<p>On all hosts configuration of GRE intfs is same (except IP
address):<br>
</p>
<pre><span class="go">ip tunnel add gre1 mode gre key 42 ttl 64</span>
<span class="go">ip addr add 10.0.0.xxx/32 dev gre1</span>
<span class="go">ip link set gre1 up</span></pre>
<p>The issues are:</p>
<p>- unlike all examples (incl. official), NHRP neighborhood is not
established until I specify explicit mapping on Hub, using 'ip
nhrp map ...'<br>
- though, if I do 'ip link set gre1 down' and then 'up', FRR loses
'ip nhrp map ...' config and, thus, loses connectivity<br>
- 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:<br>
</p>
<pre>s1# sh ip nhrp
Iface Type Protocol NBMA Flags Identity
gre1 local 10.0.0.1 - -
</pre>
<p>- 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:<br>
* before ping S2's RT shows the route:</p>
<pre>root@s2:~# ip route
10.2.1.0/24 nhid 32 via 10.0.0.254 dev gre1 proto bgp metric 20 onlink
</pre>
<p>first two ping go through hub and then, after it signals to build
the direct tunnel, connectivity passes away:</p>
<pre>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
</pre>
<p>but S2's RT is expanded with new entry (10.2.1.241):</p>
<pre>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
</pre>
<p>Questions are:</p>
<p>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)<br>
2) disappearing of 'ip nhrp map' during interface up/down -
whether it is bug or feature? If latter - what is rationale behind
this?<br>
3) 'ip nhrp nhs dynamic' do not establish NHRP neighborhood - what
I'm doing wrong?<br>
4) peer unreachability after NHRP redirect - is it case for
'tunnel protection' or another issue?<br>
</p>
<p>Thank you.<br>
</p>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>