This was raised by a MetalLB user on 4.13 (which is RHEL 8.6 based). There's a particular configuration where the reloader script takes around 150 seconds to run.

I tested the same configuratoin with what we have in OCP 4.14 (which is RHEL9 based) and it takes around 7 seconds.

I am gonna attach the two files for the two statuses, in order to reproduce it should be enough to apply the first with the frr-reload.py script, and then apply the other, and see how long it takes.

Note: there are a few optimizations that can be done in the rendered configuration (like having one single route-map), and I am adding those to MetalLB, but on 4.13 the reload still takes 50-ish seconds, so I feel the real time hog is in frr itself.

I wasn't able to find a particular issue upstream, I will try to go over the frr-reload-py history to see if there's something evident.