Skip to content

Commit 9f55368

Browse files
committed
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 <sharpd@nvidia.com>
1 parent 2982edc commit 9f55368

File tree

1 file changed

+19
-0
lines changed

1 file changed

+19
-0
lines changed

bgpd/bgp_nht.c

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1278,6 +1278,25 @@ void evaluate_paths(struct bgp_nexthop_cache *bnc)
12781278
}
12791279

12801280
LIST_FOREACH (path, &(bnc->paths), nh_thread) {
1281+
/*
1282+
* Currently when a peer goes down, bgp immediately
1283+
* sees this via the interface events( if it is directly
1284+
* connected). And in this case it takes and puts on
1285+
* a special peer queue all path info's associated with
1286+
* but these items are not yet processed typically when
1287+
* the nexthop is being handled here. Thus we end
1288+
* up in a situation where the process Queue for BGP
1289+
* is being asked to look at the same path info multiple
1290+
* times. Let's just cut to the chase here and if
1291+
* the bnc has a peer associated with it and the path info
1292+
* being looked at uses that peer and the peer is no
1293+
* longer established we know the path_info is being
1294+
* handled elsewhere and we do not need to process
1295+
* it here at all since the pathinfo is going away
1296+
*/
1297+
if (peer && path->peer == peer && !peer_established(peer->connection))
1298+
continue;
1299+
12811300
if (path->type == ZEBRA_ROUTE_BGP &&
12821301
(path->sub_type == BGP_ROUTE_NORMAL ||
12831302
path->sub_type == BGP_ROUTE_STATIC ||

0 commit comments

Comments
 (0)