[FROG] NHRP multiple issues

Volodymyr Litovka doka.ua at gmx.com
Fri Jan 29 08:24:38 UTC 2021


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/82b85ee4/attachment.htm>


More information about the frog mailing list