Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Apr 2006 22:16:56 -0300
From:      AT Matik <>
Subject:   Re: Load-balancing
Message-ID:  <>
In-Reply-To: <>
References:  <20060411092932.42148fd8@giboia> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wednesday 12 April 2006 21:07, Patrick Tracanelli wrote:
> Tt is certainly the deal, according to the code as I mentioned in the
> later message. This is why a "rate" option would do this job better than
> prob which make use of random().
> Anyway according to my tests this random() approach gets very close to a
> percentage. From more elaborated to simple tests such as:
> # ipfw add 1 prob 0.33 deny icmp from me to any out icmptypes 8
> # ping
> [.. and there ping(1) goes...]
> --- ping statistics ---
> 28 packets transmitted, 18 packets received, 35% packet loss
> round-trip min/avg/max/stddev =3D 0.229/0.280/0.359/0.036 ms

I am not sure what you try to prove here.

random means that the packets are randomly processed and not in any sequenc=
to get most close to the defined rate.=20

Probably exactly to 33% if you define .33 since 0=3D0 and 1=3D100% but sinc=
e ipfw=20
does not split packets when only 5 are send you get something close to 33%=
what is then 1 or 2 packets (based on 5) and that this one or two packets c=
be ANY of the 5.
but repeat your ping with -c 99 and you probably see always 33 packages

> So I believe the lack of a "fwd keep-state"-like behavior is more
> significant than the rate-with-precision stuff, when the matter is
> balancing...


in your first msg you said:

>>keep-state in this case would make all other packets from the given=20
>>source IP to the given destination IP always get forwarded...

>>Because as I see (I may be wrong) the above example may break sessions,

in this case  the keep-state rules will probably be broken since "prob" is=
processed before keep-state=20

I believe you could use keep-state in case of policy-routing but not togeth=
with prob but policy-routing is not load-balancing, what makes out of both =
"one-or-the-other" option

I guess with keep-state you can not get any balance and may break balance=20
since you can not know how much traffic the source Ip might demand, overall=
keep-state do catch only tcp and perhaps udp
you said also:

>>right? Thinking on an https session, for example. Some packets would=20
>>match the prob, some other would not. So what do we get? Some packets=20
>>going out via link #1 and some other via link #2. The other end will not=
>>know about the incoming packets from the other link.

since we are talking load-balancing we suppose we have a route to our IP(s)=
from both links
the dst-ip do not know which route the packet went from but from it's defau=
gateway and does not check it either, the dst-ip cares if it comes from the=
original IP and eventual if it has the correct sequence so it does not matt=
if it comes which route since it comes in on the right interface from which=
it goes back to the GW and this is where the further route decision is made=


A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik

Want to link to this message? Use this URL: <>