From 9f5536807eadbc2e729492cfd87d38007f19236c Mon Sep 17 00:00:00 2001 From: Donald Sharp Date: Fri, 24 Jan 2025 15:04:13 -0500 Subject: [PATCH] bgpd: Optimize evaluate paths for a peer going down Currently when a directly connected peer is going down BGP gets a call back for nexthop tracking in addition the interface down events. On the interface down event BGP goes through and sets up a per peer Q that holds all the bgp path info's associated with that peer and then it goes and processes this in the future. In the meantime zebra is also at work and sends a nexthop removal event to BGP as well. This triggers a complete walk of all path info's associated with the bnc( which happens to be all the path info's already scheduled for removal here shortly). This evaluate paths is not an inexpensive operation in addition the work for handling this is already being done via the peer down queue. Let's optimize the bnc handling of evaluate paths and check to see if the peer is still up to actually do the work here. Signed-off-by: Donald Sharp --- bgpd/bgp_nht.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/bgpd/bgp_nht.c b/bgpd/bgp_nht.c index 164e2300c0..2ef7ec97e3 100644 --- a/bgpd/bgp_nht.c +++ b/bgpd/bgp_nht.c @@ -1278,6 +1278,25 @@ void evaluate_paths(struct bgp_nexthop_cache *bnc) } LIST_FOREACH (path, &(bnc->paths), nh_thread) { + /* + * Currently when a peer goes down, bgp immediately + * sees this via the interface events( if it is directly + * connected). And in this case it takes and puts on + * a special peer queue all path info's associated with + * but these items are not yet processed typically when + * the nexthop is being handled here. Thus we end + * up in a situation where the process Queue for BGP + * is being asked to look at the same path info multiple + * times. Let's just cut to the chase here and if + * the bnc has a peer associated with it and the path info + * being looked at uses that peer and the peer is no + * longer established we know the path_info is being + * handled elsewhere and we do not need to process + * it here at all since the pathinfo is going away + */ + if (peer && path->peer == peer && !peer_established(peer->connection)) + continue; + if (path->type == ZEBRA_ROUTE_BGP && (path->sub_type == BGP_ROUTE_NORMAL || path->sub_type == BGP_ROUTE_STATIC || -- 2.39.5