zebra: Check both IPv4 and IPv6 NH before removing RMAC

[leonshaw]

IPv4 and IPv4-mapped IPv6 address of a VTEP is used as nexthops of EVPN routes. Thus should check for both IPv4 and IPv6 before removing RMAC. Otherwise, withdrawing the last route in one address family breaks the other.

[leonshaw]

BTW, the nexthop IP of EVPN type 5 route is an intermediate value to resolve to L2 neighbor (RMAC + VTEP) in VxLAN domain, thus not necessarily the same as VTEP IP. Linux rtnetlink also has RTA_VIA, so it's possible to use IPv4 nexthop in IPv6 route. Not sure if there's a way to specify L2 nexthop directly.

[leonshaw]

Will add a topotest.

[chiragshah6]

@leonshaw Is there any issue file explaining the situation where RMAC is removed? If there are more data available along with some of the show commands outputs assist to shade light on the problem.

[leonshaw]

@chiragshah6 See the topotest in question for example. R2 advertises EVPN type-5 routes of both IPv4 and IPv6 prefixes under VTEP 192.168.100.41. R1 then use the VTEP address as IPv4 next-hop, and IPv4-mapped IPv6 address as IPv6 next-hop (which eventually resolve to underlay VxLAN encap via ARP/ND table and L2 FDB). These two next-hops share one RMAC.

# ip -4 route
192.168.101.41 via 192.168.100.41 dev bridge-101 proto bgp metric 20 onlink
# ip -6 route
fd00::2 via ::ffff:192.168.100.41 dev bridge-101 proto bgp metric 20 onlink pref medium
# ip neigh
192.168.100.41 dev bridge-101 lladdr ca:45:f5:59:9e:55 extern_learn  NOARP proto zebra
::ffff:192.168.100.41 dev bridge-101 lladdr ca:45:f5:59:9e:55 extern_learn  NOARP proto zebra
# bridge fdb
ca:45:f5:59:9e:55 dev vxlan-101 dst 192.168.100.41 link-netnsid 0 self extern_learn

r1# sh evpn next-hops vni 101
Number of NH Neighbors known for this VNI: 2
IP              RMAC
192.168.100.41  ca:45:f5:59:9e:55
::ffff:c0a8:6429 ca:45:f5:59:9e:55
r1# sh evpn rmac vni 101
Number of Remote RMACs known for this VNI: 1
MAC               Remote VTEP
ca:45:f5:59:9e:55 192.168.100.41

When the IPv6 route is withdrawn, without the changes of this PR, the RMAC will be deleted because the IPv6 next-hop is gone and the RMAC is considered unreferenced.

r1# sh evpn next-hops vni 101
Number of NH Neighbors known for this VNI: 1
IP              RMAC
192.168.100.41  ca:45:f5:59:9e:55
r1# sh evpn rmac vni 101

With this change, zebra will find there's still an IPv4 next-hop, thus the RMAC is preserved.

r1# show evpn next-hops vni 101
Number of NH Neighbors known for this VNI: 1
IP              RMAC
192.168.100.41  82:eb:2d:49:62:fa
r1# show evpn rmac vni 101
Number of Remote RMACs known for this VNI: 1
MAC               Remote VTEP
82:eb:2d:49:62:fa 192.168.100.41

[github-actions[bot]]

This PR is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this PR closed.

[leonshaw]

@chiragshah6 What to do with this PR now?

[ton31337]

Superseded by https://github.com/FRRouting/frr/pull/16341.