Hi, as the tables are stored in RAM anyway during thee processing it’s moreless matter of how fast are your DIMMs / CPU. I’m usually work with several tables with cca 30 K records - no impact on the performance so far.
S pozdravem / Kind regards Martin Sukaný UNIX Engineer, Developer, DevOps specialist xmpp: [email protected] phone: +420 776 275 713 email: [email protected] l: https://www.linkedin.com/in/martins6 > 12. 8. 2020 v 14:22, Stuart Harland <[email protected]>: > > This is one of those “How long is a piece of string” examples. > > You don’t give a lot in the way of specifications so as to come up with a > reasonble guess. But the guesses are meaningless anyway, as the packet > filtering subsystems are pretty efficient and very rapid. > > In reality with sufficient CPU clock speed and memory for the state tables, > you should be able to simultaneously block thousands and thousands, if not > more. > > Not particularly scientific, but there we are. > > Stuart > >> On 12 Aug 2020, at 13:11, Alan McKay <[email protected]> wrote: >> >> Hey folks, >> >> This is one that is difficult to test in a test environment. >> >> I've got OpenBSD 6.5 on a relatively new pair of servers each with 8G RAM. >> >> With some scripting I'm looking at feeding block IPs to the firewalls >> to block bad-guys in near real time, but in theory if we got attacked >> by a bot net or something like that, it could result in a few thousand >> IPs being blocked. Possibly even 10s of thousands. >> >> Are there any real-world data out there on how big of a block list we >> can handle without impacting performance? >> >> We're doing the standard /etc/blacklist to load a table and then have >> a block on the table right at the top of the ruleset. >> >> thanks, >> -Alan >> >> -- >> "You should sit in nature for 20 minutes a day. >> Unless you are busy, then you should sit for an hour" >> - Zen Proverb >> >
