FreeBSD router - large scale
kevin.wilcox at gmail.com
Wed Jun 23 15:21:28 UTC 2010
On 27 May 2010 12:12, Matthew Seaman <m.seaman at infracaninophile.co.uk> wrote:
> The hardest job I've had an OpenBSD firewall do is actually as a
> mid-level firewall between a DMZ full of web servers and a back-end
> database layer. The thing to watch out for is running out of states in
> PF. It's trivial to change that in the config, and given a machine with
> 1GB or so RAM dedicated to running PF, you can up the number of states
> by a factor of a hundred or more without problem. Also if you know all
> your connections are from directly attached networks and very low
> latency, you can be a lot more aggressive about dropping old states.
thanks for the information! For other reasons I'm limited to about
500k states...since our typical hardware build has at least 4GB of
RAM, I'm not overly concerned about RAM exhaustion when routing. As I
stated in another post the potential for something like a squid cache
does exist, in which case I'll take all the RAM I can get my hands on
(a 16GB+ build is not out of the question at that point).
Preliminary testing has been favorable. My big concerns have mostly
been related to state and packets per second. The first test
environment was as follows:
| one NIC, 4 routable addresses
| FreeBSD 8 Router |
| one NIC with aliases for
| switch |
Attached to the switch are four workstations/laptops:
All connections are gigabit.
The idea is that in a production environment, we'll have multiple /22
networks coming in so I wanted to test having multiple network
aliases. There will be a pool of public addresses for the outside
interface(s), possibly as large as a class C but probably 20 - 30
By using sticky-address on a NAT rule, we can watch each RFC-1918
address get mapped to a different outside address via round-robin
while enforcing that all connections from one inside host are
consistently mapped to the same external address. Generating 10k
active pings on each of the workstations/laptops, we were able to get
an idea of how the machine would respond with 80k active states (two
per connection, one in each direction). Adding in a couple of
BitTorrent and HTTP .iso downloads only supported the conclusions we
were beginning to form.
Currently I'm testing it with multiple BitTorrent downloads and a very
lively World of Warcraft installer. While nowhere near an indication
of what we could expect in production it is showing us RAM usage,
processor usage and state maintenance behaviour that gives us pretty
good indications that we can go ahead and test in a larger
environment. Like I said, we are otherwise limited to approximately
500k states (actually 250k connections) and only about half of that
will be allotted for the population this project is targeting so
testing with 100k states is actually pretty realistic at this point.
We will wait, of course, to attempt a production deployment until
after we have tested with a larger sample of the target population.
Thanks to everyone for their comments and suggestions, both on and off list!
A: Maybe because some people are too annoyed by top-posting.
Q: Why do I not get an answer to my question(s)?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
More information about the freebsd-questions