Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Apr 2006 17:49:42 +0200
From:      Max Laier <max@love2party.net>
To:        freebsd-pf@freebsd.org
Cc:        Kostas Zorbadelos <kzorba@otenet.gr>
Subject:   Re: Address pools and load balancing issues
Message-ID:  <200604021749.48171.max@love2party.net>
In-Reply-To: <20060402082519.GA25134@enigma.otenet.gr>
References:  <20060402082519.GA25134@enigma.otenet.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2949266.5xS15lAr7f
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 02 April 2006 10:25, Kostas Zorbadelos wrote:
> Hello to everyone.
> I am a newcomer to the list. I am evaluating the pf packet filter for
> a few months now and I like very much what I see. I have a few
> questions regarding address pools and load balancing. In the relevant
> documentation [1] it is explicitly mentioned that methods other than
> round-robin (bitmask, random, source-hash) work only if the address
> pool is expressed as a CIDR network block. Also, if the address pool
> is expressed as a table, then the only method allowed is round-robin.
> In my setup this is a problem, since I have a pool of WWW servers and
> I need the source-hash load balancing method where a specific client
> connects to the same  web server (that has its http session for
> instance). My pool of servers is not in a continuous network block, so
> it cannot be expressed in a CIDR notation. Is there a way to overcome
> this limitation? (sticky-address is not an option since it works only
> as long as there are states for a client's connections)
> Will these restrictions go away in a next version of pf? Ideally, I
> would like to express all my pools as tables and have all the
> different algorithms for load balancing available.

The problem is what does bitmask or source-hash mean for a table?  What do =
you=20
apply the bitmask to?  What do you hash to?  The other problem is the=20
internal organization of tables that is optimized for lookups and doesn't=20
work as a list or array which is required for hashing.  A sollution would b=
e=20
to have real address lists, but I doubt that will happen any time soon.

As for a workaround sollution for you.  sticky-address works also without=20
states, provided you set a reasonable value for "set timeout source-track" =
as=20
described in pf.conf(5).  Another option is to just make your webserver int=
o=20
a continuous netbock via rdr/binat rules.  You should be able to map them=20
into a private netbock and can then apply source-hash load-balanceing to=20
that.  Of course there is overhead associated with that as well.  It really=
=20
depends on your usecase which is the most workable sollution.

> Thanks in advance and congratulations to all the people involved in pf
> for the great work.

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart2949266.5xS15lAr7f
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQBEL/KcXyyEoT62BG0RAqE0AJ46GceB/Q15cjwDMnbqGWHWnQUcSgCfeWpt
JdN/sXhBm2zu66X5GgmtncE=
=9TzD
-----END PGP SIGNATURE-----

--nextPart2949266.5xS15lAr7f--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604021749.48171.max>