Support for NHRP mapping IPv6 addresses would allow DMVP to work with IPv6. Current you can create an IPv6 DMVPN but NHRP doesn't support IPv6
Description
Description
Details
Details
- Difficulty level
- Unknown (require assessment)
- Version
- -
- Why the issue appeared?
- Will be filled on close
- Is it a breaking change?
- Unspecified (possibly destroys the router)
- Issue type
- Feature (new functionality)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In progress | FEATURE REQUEST | v.huti | T2326 Migrate NHRP(DMVPN) to FRR | ||
| On hold | FEATURE REQUEST | v.huti | T3040 NHRP IPv6 Support |
Event Timeline
Comment Actions
@c-po with this merge on FRR https://github.com/FRRouting/frr/pull/8153#event-4589485067 is migration possible? Possibly related to https://phabricator.vyos.net/T2326
Comment Actions
Hi @francis the latest FRR version lacks support for Cisco authentication https://github.com/FRRouting/frr/blob/master/nhrpd/nhrp_peer.c#L1212
Comment Actions
I have tested FRR NHRP with IPv6 as an overlay and I found some issues.
1. FRR as a spoke
My Lab
Cisco HUB--- FRR Spoke
Cisco HUB
interface Tunnel100 ipv6 address 2001:DB8::1/64 ipv6 tcp adjust-mss 1360 ipv6 nhrp map multicast dynamic ipv6 nhrp network-id 1 ipv6 nhrp holdtime 60 ipv6 nhrp redirect tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 42
FRR Spoke
VyOS CLI
set interfaces tunnel tun100 address '2001:DB8::20/128' set interfaces tunnel tun100 encapsulation 'gre' set interfaces tunnel tun100 ipv6 address no-default-link-local set interfaces tunnel tun100 ipv6 adjust-mss '1360' set interfaces tunnel tun100 mtu '1400' set interfaces tunnel tun100 parameters ip key '42' set interfaces tunnel tun100 source-interface 'eth0' set protocols static route6 2001:db8::/64 next-hop 2001:db8::1 distance '200'
FRR CLI
interface tun100 ipv6 address 2001:db8::20/128 ipv6 nhrp holdtime 60 ipv6 nhrp network-id 1 ipv6 nhrp nhs dynamic nbma 192.168.100.100 ipv6 nhrp registration no-unique ipv6 nhrp shortcut no link-detect tunnel source eth0
At first everything looks ok.
FRR register and add new ipv6 routes
N>* 2001:db8::1/128 [10/0] is directly connected, tun100, weight 1, 00:06:40
But there is a problem with neighbor's table
After some time the record of 2001:db8::1 changes status from REACHABLE to STALE then to DELAY, PROBE, and finally to FAILED.
ip -6 neigh 2001:db8::1 dev tun100 lladdr 192.168.100.100 REACHABLE proto nhrp
ip -6 neigh 2001:db8::1 dev tun100 FAILED proto nhrp
I checked Spoke to Spoke conversation. It works. but with the same issue.
It looks like a bug in FRR, the neighbor's status never changes to PROBE in IPv4. It takes Reachable - STALE - DELAY - and then again REACHABLE. And it looks like FRR NHRP controls it.
I tried to change nhrp holdtime and it did not help.
2. My second Lab was FRR as a HUB and two spokes (FRR and Cisco)
Cisco Spoke ---- FRR HUB----------FRR Spoke
All routers in one network.
Cisco Spoke config
interface Tunnel100 no ip address no ip redirects ip mtu 1400 ipv6 address 2001:DB8::15/64 ipv6 nhrp map 2001:DB8::1/128 192.168.100.100 ipv6 nhrp map multicast 192.168.100.100 ipv6 nhrp network-id 1 ipv6 nhrp nhs 2001:DB8::1 ipv6 nhrp shortcut tunnel source GigabitEthernet0/0 tunnel mode gre multipoint tunnel key 42
FRR Spoke config is the same as in the example №1
FRR HUB config
VyOS CLI config
set interfaces tunnel tun100 address '2001:DB8::1/128' set interfaces tunnel tun100 disable-link-detect set interfaces tunnel tun100 encapsulation 'gre' set interfaces tunnel tun100 ipv6 adjust-mss '1360' set interfaces tunnel tun100 mtu '1400' set interfaces tunnel tun100 parameters ip key '42' set interfaces tunnel tun100 source-interface 'eth0'
FRR CLI
interface tun100 ipv6 address 2001:db8::1/128 ipv6 nhrp holdtime 60 ipv6 nhrp network-id 1 ipv6 nhrp redirect ipv6 nhrp registration no-unique no link-detect tunnel source eth0
vyos# show ipv6 nhrp Iface Type Protocol NBMA Claimed NBMA Flags Identity tun100 dynamic fe80::ea7:caff:fec4:0 192.168.100.115 192.168.100.115 T tun100 dynamic 2001:db8::20 192.168.100.120 192.168.100.120 T tun100 local 2001:db8::1 192.168.100.100 192.168.100.100 -
I found 2 issues. The first issue is the same as in the example №1
The second issue
FRR HUB registers CISCO only by its link-local address.
vyos# show ipv6 nhrp Iface Type Protocol NBMA Claimed NBMA Flags Identity tun100 dynamic fe80::ea7:caff:fec4:0 192.168.100.115 192.168.100.115 T
Link local address must exist on cisco side
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-16-12/sec-conn-dmvpn-xe-16-12-book/ip6-dmvpn-xe.pdf
I also found a bug in FRR NHRP with dual stack as an overlay. I will describe it later.
Comment Actions
I have checked in with @sharpd, he mentioned that it might not be supported to use v4 nexthop for v6 route.
From local testing:
vova | ip r default via 192.168.0.1 dev wlp4s0 proto dhcp metric 600 192.168.0.0/24 dev wlp4s0 proto kernel scope link src 192.168.0.102 metric 600 vova | sudo ip route add 1::2/64 via 192.168.0.102 dev wlp4s0 Error: inet6 address is expected rather than "192.168.0.102". vova | ip nexthop id 13 dev wlp4s0 scope link proto zebra id 16 via 192.168.0.1 dev wlp4s0 scope link proto zebra vova | sudo ip route add 1::2/64 nhid 16 Error: IPv6 routes can not use an IPv4 nexthop.
I will look at how Kernel handles this and if there is a way around it before fixing the NHRP.