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.279.pdf)
research paper in paragraph "II. RATE-LIMITING IMPLEMENTATIONS"
(3)
https://gist.github.com/tonusoo/1cced39aa6ae53143d12623a05f02331?permalink_comment_id=5820674#gistcomment-5820674
Martin
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/[email protected]/message/4ZW2HS5NHD2H6Q3XLDU6K4DG4UNSJUTB/
