[FROG] NHRP multiple issues

Fri Jan 29 17:00:32 UTC 2021

> that I'm in doubts that NHRP is production-ready. Is it?

No, that is why its status is listed as "Alpha". We would love for someone to take up the work needed to bring it up to scratch though!
________________________________
From: frog <frog-bounces at lists.frrouting.org> on behalf of Volodymyr Litovka <doka.ua at gmx.com>
Sent: Friday, January 29, 2021 3:24 AM
To: frog at lists.frrouting.org <frog at lists.frrouting.org>
Subject: [FROG] NHRP multiple issues

External email: Use caution opening links or attachments

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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20210129/eae97816/attachment.htm>