On 5/8/06, Daniel Hartmeier <[EMAIL PROTECTED]> wrote:
If somewhat inprecise limits are acceptable, the most simple solution is
to only guarantee
X + Y <= 2*N
by limiting both firewalls to N connections. You guarantee the client N
connections (no matter where they flow through), and count the
difference between N and 2*N as imprecision. That might sound awfully
imprecise at first, but in most cases, is good enough.
Maybe you can explain why you need precisely N, what value N would
typically have, and why 2*N would be unacceptable.
Daniel, the X + Y <= 2*N idea is fine actually. The way I see it, I
can either do that, or keep each client going through one of my
backends only (that way I use a static approach to divide my clients
across the backends using the bridge). Typically, we are looking at
around 20 sessions per client.
On 5/8/06, Karl O. Pinc <[EMAIL PROTECTED]> wrote:
On 05/08/2006 11:21:47 AM, Daniel Hartmeier wrote:
> On Mon, May 08, 2006 at 05:58:08PM +0300, Hisham Mardam Bey wrote:
>
> This currently won't work. pfsync does only synchronize state table
> entries, not rules. Since the firewalls can have different rules, no
> attempt is made to associate a state entry with a particular rule of
> the
> recipient's ruleset. Instead, such state entries are associated with
> the default pass rule.
Couldn't he do this on his bridge, which is doing the load balancing
between the firewalls anyhow, by limiting the number of states on the
bridge?
Karl, I could do this on the bridge itself, but I dont know if that
will create a bottleneck at that stage. That is why I decided to move
this over to the backend servers.
Now this entire debate brings up a couple of more points I was
thinking of. Assuming I decide to do this kind of thing on the bridge,
how much load can the bridge really handle? I have read the various
documents that discuss PF's performance and how it is related to the
network card itself and the CPU/RAM on the system, but was wondering
if someone had really stressed an OpenBSD box running PF and what sort
of numbers they had achieved.
What we are looking at here is a setup that does:
- Session Limitation
- Bandwidth Limitation
- Port / IP based filtering
We expect to have an initial number of users close to 3000. That
number might climb to 6000 or 7000 eventually. If we want to traffic
shape our users, and we want to impose session limits, that means we
have around (initially) 3000 x 20 = 60000 sessions (max) and
eventually 7000 x 20 = 140000 sessions (max). How much of that do you
think a single OpenBSD box running PF can handle? (Thats why I had the
load balancing idea in mind, I can add as much backend boxes as
required while keeping the bridge's task as simple as possible). After
giving it some thought though, the bridge *IS* keeping state of each
and every connection. It has to do that in order to be able to
properly round-robin packets properly to the respective backend
server. So what do you think, should I just move the session
limitation to the bridge itself?
Now my other main concern is ALTQ. I understand that it is not
possible to have any form of ALTQ across multiple PF boxes (ie, shared
information, as I was proposing regarding using pfsync and session
limits). So what would be a good way to limit the total bandwidth of a
single client that is being load balanced across multiple backend
servers?
Thank you for your time everyone (=
hisham.
--
Hisham Mardam Bey
MSc (Computer Science)
http://hisham.cc/
+9613609386
Codito Ergo Sum (I Code Therefore I Am)
