]> git.puffer.fish Git - matthieu/frr.git/commit
zebra: evpn: not coerce VTEP IP to IPv4 in nh_list
authorEugene Crosser <crosser@average.org>
Tue, 2 Jul 2024 17:02:53 +0000 (19:02 +0200)
committerEugene Crosser <crosser@average.org>
Mon, 8 Jul 2024 08:32:03 +0000 (10:32 +0200)
commitf883c7119e76e264fb8045bf1884e436eb66527a
tree431ad58ee98bb0ea54778573379de4acd0268d52
parent66a84c7c107d7b70befdae77f923b72f3d5956b2
zebra: evpn: not coerce VTEP IP to IPv4 in nh_list

In L3 BGP-EVPN, if there are both IPv4 and IPv6 routes in the VPN, zebra
maintains two instances of `struct zebra_neigh` object: one with IPv4
address of the nexthop, and another with IPv6 address that is an IPv4
mapped to IPv6, but only one intance of `struct zebra_mac` object, that
contains a list of nexthop addresses that use this mac.

The code in `zebra_vxlan` module uses the fact that the list is empty as
the indication that the `zebra_mac` object is unused, and needs to be
dropped. However, preexisting code used nexthop address converted to
IPv4 notation for the element of this list. As a result, when two
`zebra_neigh` objects, one IPv4 and one IPv6-mapped-IPv4 were linked to
the `zebra_mac` object, only one element was added to the list.
Consequently, when one of the two `zebra_neigh` objects was dropped, the
only element in the list was removed, making it empty, and `zebra_mac`
object was dropped, and neigbrour cache elements uninstalled from the
kernel.

As a result, after the last route in _one_ family was removed from a
remote vtep, all remaining routes in the _other_ family became
unreachable, because RMAC of the vtep was removed.

This commit makes `zebra_mac` use uncoerced IP address of the `zebra_neigh`
object for the entries in the `nh_list`. This way, `zebra_mac` object no
longer loses track of `zebra_neigh` objects that need it.

Bug-URL: https://github.com/FRRouting/frr/issues/16340
Signed-off-by: Eugene Crosser <crosser@average.org>
zebra/zebra_vxlan.c