Load-balancing

[AT Matik]

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 = 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 sequence 
to get most close to the defined rate. 

Probably exactly to 33% if you define .33 since 0=0 and 1=100% but since ipfw 
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 can 
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 
>>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 

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

I guess with keep-state you can not get any balance and may break balance 
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 
>>match the prob, some other would not. So what do we get? Some packets 
>>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 default 
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 matter 
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 
then.

João









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