proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-07-13 22:16:43 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

bgpd: Optimize evaluate paths for a peer going down

Browse Source 
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 <sharpd@nvidia.com>
This commit is contained in:
Donald Sharp 2025-01-24 15:04:13 -05:00
parent 2982edcaa3
commit 9f5536807e
1 changed files with 19 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
bgpd/bgp_nht.c
View File

@ -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 ||