From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 26 13:33:36 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18FB1106566B for ; Thu, 26 Jun 2008 13:33:36 +0000 (UTC) (envelope-from luiz@aonet.com.br) Received: from aonet.com.br (mail.aonet.com.br [200.148.248.194]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE548FC0A for ; Thu, 26 Jun 2008 13:33:35 +0000 (UTC) (envelope-from luiz@aonet.com.br) Received: (qmail 4551 invoked by uid 0); 26 Jun 2008 13:06:53 -0000 Received: from 201.95.119.91 (luiz@aonet.com.br@201.95.119.91) by mail.aonet.com.br (envelope-from , uid 89) with qmail-scanner-2.01 (uvscan: v5.1.00/v5210. Clear:RC:0(201.95.119.91):. Processed in 0.534575 secs); 26 Jun 2008 13:06:53 -0000 Received: from unknown (HELO note4c47) (luiz@aonet.com.br@201.95.119.91) by aonet.com.br with RC4-MD5 encrypted SMTP; 26 Jun 2008 13:06:53 -0000 Message-ID: <001901c8d78d$8180c680$5e00a8c0@note4c47> From: "Luiz Otavio O Souza" To: "Julian Elischer" , References: <1214430974.26401.0.camel@devstation> <4862DCB5.6080005@elischer.org> Date: Thu, 26 Jun 2008 10:06:52 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: Re: 3 connections as one] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2008 13:33:36 -0000 ----- Original Message ----- Subject: Re: [Fwd: Re: 3 connections as one] : Martes Wigglesworth wrote: : > -------- Forwarded Message -------- : > From: Martes Wigglesworth : > Reply-To: martes@mgwigglesworth.com : > To: Andres Chavez : > Subject: Re: 3 connections as one : > Date: Tue, 24 Jun 2008 16:34:04 -0400 : > : > I have been researching this issue for almost a month now, and what I : > have found is that you can bind the ports together for outbound traffic, : > and the same can be done for inbound traffic, the problem comes when you : > try to get the inbound packets, or sessions to dispurse across the : > load-balanced ports. I.E.: Who is on the other side of the multiple : > DSL/Cable links to filter the traffic across the associated pipes so as : > to "balance the load," so to speak? : > : > It can be done, however, without an upstream, or maybe a vps that is : > being used as an external gateway, you will not be able to get the : > different session traffic to load balance across the multiple links, : > when downloading. : > : > At least that seems to be the situation, without some nifty DNS tricks. : > I have not seen how the "appliances" get around this, however, it took : > me this long for either list that I was on, to even admitt that the : > theory was not stupid, and to engage me in productive inquiry. : : : the usual way is to NAT traffic out though each interface : so that the internet is not aware that sessions from apparently : different places are actually the same.. : : : you can do the same with multiple NAT instances and some way to divide : up the load between interfaces.. I had write a patch, a long time before (probably in 4.x days - before libnat get the kernel bits) wich you can set two (fixed by patch at that time) alias address on natd. Another option has been added to natd, a number wich can be set from 0 to 100 to determine the use of the second alias address. This is intended to be used as "%", so 50 should be read as 50/50% balanced link. So when a connection has to be established for the first time, the patch use the value of balance option to determine what alias address should be used for this new connection. The natd will use the default alias address or the optional alias address based on the "balance" set. So natd is generating new connections in two diferent IPs (for two diferent connections) based on a "%" value, wich allow the use of unequal bandwidth links. At that time the patch work like a charm and is very usefull (as set 0/100 disable the use of one link and 100/0 disable the use of the other link without change any other configuration). Ipfw should be configured to deliver each IP/network to the proper gateway. Due to the number of changes in recent libalias/natd the patch need to be rewrite and the only thing i am not happy (and IMHO should be revised is the number of connections that should be from 1 to any and not limited to two). This should be a simple task for a natd/libalias developer (not enough time for me). -luiz