From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 17:34:09 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27CD61065692 for ; Wed, 21 Jan 2009 17:34:09 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id CD6BA8FC0C for ; Wed, 21 Jan 2009 17:34:08 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1586542ywe.13 for ; Wed, 21 Jan 2009 09:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=EPiLHmv9IzioBsLFz6+RTshjiwcM4dQJdADbkR5pPc8=; b=X2qBJ9s2X6bdCuEw8ALhpPqpFUFnpH337d1kreKHOk+pcAsZAfaeWLBgspyfcbkGQb 2pQNmnWrnAI0LIYZJ/0QgtJM0mcWQC0r7d7DTWA2zEHmVfjL9Rm2fp71HSa5usdBOPW9 zK988I6BApio/sjUcU0in43laIPrkI/GDTZCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=ERtPo3rRyugSFSyApP3Gp9hzBUSOeg2tuO5fKRN5z9MIhz78uW8GVIjEEdSvZaraoE OqMEZoJwaI9X3EZg98QQO9oxw1fmNQh7U9tBbC2FlrYWi9jelOv8QYs84ffYOSBVPj5n QuJ+KYPlF2EFVr1HA/5gowdLhrOEt40cfgmSI= Received: by 10.100.46.15 with SMTP id t15mr425426ant.26.1232559248209; Wed, 21 Jan 2009 09:34:08 -0800 (PST) Received: from adnote989 ([201.63.10.146]) by mx.google.com with ESMTPS id d35sm9919358and.18.2009.01.21.09.34.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 09:34:07 -0800 (PST) Message-ID: From: "Luiz Otavio O Souza" To: "Eduardo Meyer" References: <4970DB6C.4030200@elischer.org> <8461C1DA26D349A7B4AA821D8461A923@adnote989> Date: Wed, 21 Jan 2009 15:34:03 -0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Wed, 21 Jan 2009 17:42:08 +0000 Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Multiple Routing Tables (FIB) + IPFW problem as (I?) expected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 17:34:09 -0000 >>>> obviously you did some other commands here.. >>>> something generated 2 million packets.. >>> >>> Julian, its a production enviroment, firewall was up for a few >>> minutes. Thats the reason. >>> >>>> I was thinking of adding a 'reroute' ipfw keyword.. kind of like >>>> 'fwd {original dest} ip from any to any' >>>> because 'fwd' does cause the routing decision to be redone. >>>> >>>> The fib of the process that opens the socket controls where packets >>>> from >>>> the >>>> local machine are sent. >>> >>> divert does cause this too, not "not fib X" seems to work fine... >>> >>> I wish you could make the "setfib" action be kept in state with >>> keep-state only for the static rules, but I guess it will be done for >>> all dynamic rules too, since keep-state makes dynamic rules repeat the >>> static one, right? >>> >>> would something like >>> >>> ipfw add prob 0.5 setfib 1 all from X to any out keep-state >>> >>> be used to balance (per session) between FIB tables? >> >> divert ? i think you want to say natd... >> >> Again... you are using setfib after the route table decisions... >> >> To use natd with setfib you need to setup two instances of natd, one for >> each uplink interface: >> >> ipfw add divert 8668 all from any to any via ${outnic1} >> ipfw add divert 8669 all from any to any via ${outnic2} >> >> And on internal nic: >> >> ipfw add setfib 1 tcp from ${inet} to any 80 IN VIA ${iif} >> >> So the http traffic will be routed thru fib 1 and should appear on >> correct >> uplink interface, and natd can do his the dirty work. >> >> I don't known about prob... you will need to send the connection setup >> packets (for tcp) and subsequent packets through the same link. i don't >> know >> if you can achive this with prob + keep-state. >> >> Luiz >> > > Yes, you are right. Now its way easier to do policy routing and > advanced PBR. However Im still trying to balance outgoing traffic > throught multiple FIBs, per session. But > > add prob 0.5 setfib 1 tcp from ${inet} to any 80 in via ${iif} setup > keep-state > > is not working as I expected... > > Some sessions just fail. I guess I need some special behavior on the > "keep-state" action. > Have you tried the check-state rule ? just an educated guess... no real clue about that... sorry. You will need to dig by yourself on this... take a closer look at dynamics rules created by your rule and try to determine the better way to achive what you want. Luiz