Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Apr 2006 22:16:56 -0300
From:      AT Matik <asstec@matik.com.br>
To:        freebsd-ipfw@freebsd.org
Subject:   Re: Load-balancing
Message-ID:  <200604122216.57305.asstec@matik.com.br>
In-Reply-To: <443D9624.4010407@freebsdbrasil.com.br>
References:  <20060411092932.42148fd8@giboia> <200604121942.25737.asstec@matik.com.br> <443D9624.4010407@freebsdbrasil.com.br>

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 10.69.69.1
> [.. and there ping(1) goes...]
> --- 10.69.69.1 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=
e=20
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%=
=20
what is then 1 or 2 packets (based on 5) and that this one or two packets c=
an=20
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=
=20
processed before keep-state=20

I believe you could use keep-state in case of policy-routing but not togeth=
er=20
with prob but policy-routing is not load-balancing, what makes out of both =
an=20
"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=
=20
keep-state do catch only tcp and perhaps udp
=20
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=
=20
>>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)=
=20
from both links
the dst-ip do not know which route the packet went from but from it's defau=
lt=20
gateway and does not check it either, the dst-ip cares if it comes from the=
=20
original IP and eventual if it has the correct sequence so it does not matt=
er=20
if it comes which route since it comes in on the right interface from which=
=20
it goes back to the GW and this is where the further route decision is made=
=20
then.

Jo=E3o









A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?200604122216.57305.asstec>