Limitations on Bulk Addition of Static Routes in FRR?
Greetings- I'm attempting to use FRR 7.5.1 running on Debian 11.1 in a lab environment to simulate an upstream BGP peer to other network devices. I wrote a quick shell script to generate all of the /24s in IPv4 address space and have tried loading these into FRR two different ways: a) Writing all static route config directives to a separate config file, then loading that config live using "vtysh -f /tmp/nets" b) Appending the static route config directives to my existing /etc/frr/frr.conf file and restarting the frr service Both options fail to load routes after the first few thousand or so ( 1.0.0.0/24 through 1.4.238.0/24, none further). The logs don't indicate any problems or cause for the failure to load additional routes. The system has plenty of resources so I don't expect this to be a memory problem. Thoughts on what I could be doing wrong and suggestions on how to accomplish this? Thanks! --Tim
I am a bit surprised that this is having issues. I'll give it a try with several thousand static routes. In the meantime I would recommend running sharpd and installing the routes using that. The cli would be: `sharp install routes 10.0.0.0 nexthop <valid nexthop> 850000` This will create 850k /32 routes starting at 10.0.0.0, in bgp just do a `redistribute sharp` that should work fine. On Fri, Nov 12, 2021 at 2:14 PM Tim Nelson <tim.e.nelson@gmail.com> wrote:
Greetings-
I'm attempting to use FRR 7.5.1 running on Debian 11.1 in a lab environment to simulate an upstream BGP peer to other network devices. I wrote a quick shell script to generate all of the /24s in IPv4 address space and have tried loading these into FRR two different ways:
a) Writing all static route config directives to a separate config file, then loading that config live using "vtysh -f /tmp/nets" b) Appending the static route config directives to my existing /etc/frr/frr.conf file and restarting the frr service
Both options fail to load routes after the first few thousand or so ( 1.0.0.0/24 through 1.4.238.0/24, none further).
The logs don't indicate any problems or cause for the failure to load additional routes. The system has plenty of resources so I don't expect this to be a memory problem.
Thoughts on what I could be doing wrong and suggestions on how to accomplish this? Thanks!
--Tim _______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
participants (2)
-
Donald Sharp -
Tim Nelson