bgpd: Allow type 5 routes to be handled better when link is flapping

In some stress testing, we are seeing type-5 evpn routes being
left in a rejected state in zebra.

Sequence of events as I am seeing it:

a) Interface comes up that type5 routes nexthop depends on
b) zebra processes creates the connected and lets bgp know via nht
c) bgp installs the route to zebra
d) zebra processes and sends install to kernel
e) before route is installed, the interface the nexthop points at flaps
f) the route install is rejected, notify zebra
g) the interface comes up
h) zebra gets the notification about the route install rejection
i) zebra processes the down/up and turns it into a single up event
j) BGP never reinstalls the type 5 route

This up event does not translate into a nexthop tracking event
when the events happen quickly enough and/or zebra is extremelyh
busy and bgp would never see that the nexthops changed even very quickly.

This is the same thing that was going on with
https://github.com/FRRouting/frr/pull/7724
in PBR.

To fix this let's notice the interface up/down events for v4
in bgp now as well.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

diff --git a/bgpd/bgp_nht.c b/bgpd/bgp_nht.c
index d3ebc0e6a26771ee27b8f9bfdc33d7e8c9231fbc..f5b355673133a7abb4afa08340f79f7383f90da0 100644 (file)
--- a/bgpd/bgp_nht.c
+++ b/bgpd/bgp_nht.c
@@ -589,6 +589,10 @@ static void bgp_nht_ifp_handle(struct interface *ifp, bool up)
        if (!bgp)
                return;
 
+       bgp_nht_ifp_table_handle(bgp, &bgp->nexthop_cache_table[AFI_IP], ifp,
+                                up);
+       bgp_nht_ifp_table_handle(bgp, &bgp->import_check_table[AFI_IP], ifp,
+                                up);
        bgp_nht_ifp_table_handle(bgp, &bgp->nexthop_cache_table[AFI_IP6], ifp,
                                 up);
        bgp_nht_ifp_table_handle(bgp, &bgp->import_check_table[AFI_IP6], ifp,