Hi.
Why not just set MRAI to something very small, like 1 or 2 seconds, on systems that support it, and call it a day?
Yes, that would definitely help too. It's also suggested by the authors in paragraph 6.1("Partial Mitigations"). To put some numbers behind it, I replaced the router "rM" running BIRD in a virtual machine with a physical router (1) running Junos which has a similar (2) rate-limiting functionality to MRAI called "out-delay". When the "out-delay" was not configured, that is, it was 0 seconds, then the average UPDATE/sec rate in BGP vortex was around 5900 (3). From the FRR router "rZ" point of view the situation looked similar to what I described in my previous e-mail: input queues of bgpd were filled up and "rZ" frequently sent TCP packets with a zero receive window to its BGP neighbors. Once the "out-delay" was set to 1 second in "rM" Juniper router, then the UPDATE messages rate in BGP vortex dropped to 1700 messages per second and as much as I tested, the route propagation delay from "rX" to "rZ" ranged between 1.2 - 1.8 seconds. (1) Juniper MX960; RE-S-1800X4-16G-S routing engine; 4-core Intel Xeon 5500 family CPU C5518 at 1.73 GHz; Junos version 23.4R2.13; two shard threads(junos-bgpshard0, junos-bgpshard1) and two update-IO threads(bgp-updio-0, bgp-updio-1) able to run on different cores (2) Difference between MRAI timer(https://datatracker.ietf.org/doc/html/rfc4271#section-9.2.1.1) and Juniper's "out-delay" is very well explained, for example, in "On Update Rate-Limiting in BGP"(https://web-backend.simula.no/sites/default/files/publications/Simula.simula...) research paper in paragraph "II. RATE-LIMITING IMPLEMENTATIONS" (3) https://gist.github.com/tonusoo/1cced39aa6ae53143d12623a05f02331?permalink_c... Martin