reset ip bgp peer-group <name> is sent to FRR as clear ip bgp peer-group <name> (src/op_mode/bgp.py, reset()). The literal ip makes FRR treat it as an IPv4-only clear, and for that case bgp_clear() does not use its batched path: every member is cleared one after another, each with a full walk of the routing table, on bgpd's main thread. reset bgp peer-group <name> (without ip) reaches FRR as clear bgp peer-group <name> and clears the whole group in one batched walk.
Measured on VyOS 1.5.1 (FRR 10.5.2), about 1M IPv4 paths, bgpd time for the clear (show event cpu, bgp_event):
| members | reset ip bgp peer-group | reset bgp peer-group |
|---|---|---|
| 20 | 1.0-3.6 s | 7-21 ms |
| 80 | 9.2-12.6 s | 7-21 ms |
| 80, 2.25M paths | 26.7 s | 17 ms |
While the unbatched clear runs, bgpd answers nothing: a commit issued one second after the reset with 80 members was blocked 29-34 s. The same holds for the other hard clears that carry ip without an address family (reset ip bgp all, external, <as>), by code.
Cause in FRR (10.5.2 and 10.6.1): clear_ip_bgp_all sets afi = AFI_IP when the ip token is present (bgp_vty.c, 10.5.2 lines 11582-11583), so bgp_clear()'s afi_safi_unspec check (line 1154) is false and the peer-group branch clears each peer inline instead of in one batch.
Possible fix.
- VyOS: for hard clears with no address family given, send clear bgp ... instead of clear ip bgp ... (op-mode reset()).
- or FRR: use the batched path for every hard clear (a hard clear resets every AFI/SAFI anyway).