Date: Wed, 23 Jun 2010 11:21:27 -0400 From: Kevin Wilcox <kevin.wilcox@gmail.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: Free BSD Questions list <freebsd-questions@freebsd.org> Subject: Re: FreeBSD router - large scale Message-ID: <AANLkTimKo6QQ9Kk2pby37RaCyh0-uk_n8QZYf9V-ytQc@mail.gmail.com> In-Reply-To: <4BFE99EB.50208@infracaninophile.co.uk> References: <AANLkTinvU5tOZyzzeJmVU1mlXGXMIEEOXWEv5GGArSCl@mail.gmail.com> <4BFE99EB.50208@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 May 2010 12:12, Matthew Seaman <m.seaman@infracaninophile.co.uk> wrot=
e:
> 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. =C2=A0The thing to watch out for is running out of states=
in
> PF. =C2=A0It'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. =C2=A0Also 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.
Matthew -
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
| 10.10.10.254
| 10.10.20.254
| 10.10.30.254
| 10.10.40.254
|
----------------
| switch |
----------------
Attached to the switch are four workstations/laptops:
10.10.10.1/255.255.255.0
10.10.20.1/255.255.255.0
10.10.30.1/255.255.255.0
10.10.40.1/255.255.255.0
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
addresses.
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=
!
kmw
--=20
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimKo6QQ9Kk2pby37RaCyh0-uk_n8QZYf9V-ytQc>