When soft-reconfiguration inbound is not set, an inbound policy change on BGP neighbors (a route-map, prefix-list or allowas-in change) makes VyOS send a ROUTE-REFRESH request to those peers. Peers that support Enhanced Route Refresh (RFC 7313, for example route servers and many transit providers) answer with a BoRR marker, their routes, and an EoRR marker. bgpd then re-announces its whole table to that peer at each marker, although nothing asked for it: one full-table walk per marker per peer, back to back on bgpd's main thread.

Cause (FRR, 10.5.2 and master): bgp_route_refresh_receive() handles the BoRR and EoRR markers and then falls through to the code for a normal refresh request, which runs a forced bgp_announce_route() to that peer. RFC 7313 gives the markers no re-advertisement role.

Measured on VyOS 1.5.1 (FRR 10.5.2), 4 vCPU VM, 2 transit sessions of 784,840 prefixes and a peer-group of 150 peers with Enhanced Route Refresh, inbound route-map change on the peer-group:

• 151 announce walks; bgpd busy for 315-321 s after the commit returned;
• at 4.77M paths (154 sessions), watchfrr restarted bgpd about 8 minutes after the change with its default timeout; with 600 s bgpd was busy for 701 s, 673 s of it in 286 such walks;
• with graceful restart enabled, routes from the refreshed peers were lost when the stale-path timer expired before the walks ended.

Possible fix. An FRR patch: the BoRR and EoRR branches return after their marker work, and the forced re-announce applies to normal refresh requests only.

Workaround. soft-reconfiguration inbound on the peers whose inbound policy changes (no refresh is sent then; costs memory for the received routes).