[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