From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 13 01:17:05 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10FCD16A409 for ; Thu, 13 Apr 2006 01:17:05 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3E043D46 for ; Thu, 13 Apr 2006 01:17:00 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k3D1GxMO060219; Wed, 12 Apr 2006 22:16:59 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Wed, 12 Apr 2006 22:16:56 -0300 User-Agent: KMail/1.9.1 References: <20060411092932.42148fd8@giboia> <200604121942.25737.asstec@matik.com.br> <443D9624.4010407@freebsdbrasil.com.br> In-Reply-To: <443D9624.4010407@freebsdbrasil.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200604122216.57305.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Load-balancing X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2006 01:17:05 -0000 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