From owner-freebsd-questions@FreeBSD.ORG Wed Jan 14 10:50:12 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2A0616A4CF for ; Wed, 14 Jan 2004 10:50:11 -0800 (PST) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FA843D5E for ; Wed, 14 Jan 2004 10:50:10 -0800 (PST) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 5FA18121; Wed, 14 Jan 2004 12:50:09 -0600 (CST) Date: Wed, 14 Jan 2004 12:50:09 -0600 From: Tillman Hodgson To: FreeBSD-Questions Message-ID: <20040114185008.GX415@seekingfire.com> References: <20040114134255.GA59317@kumprang.or.id> <009201c3daad$31d89220$1100a8c0@dtg17> <20040114163043.GL415@seekingfire.com> <200401141827.30569.ajacoutot@lphp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401141827.30569.ajacoutot@lphp.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.5.1i Subject: Re: Loading balancing with more than one ISP. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 18:50:12 -0000 On Wed, Jan 14, 2004 at 06:27:30PM +0100, Antoine Jacoutot wrote: > On Wednesday 14 January 2004 17:30, Tillman Hodgson wrote: > > I'm a heavy Zebra (migrating to Quagga) user. Using dynamic routing is > > very handy, but it won't solve the problem of balancing load across two > > connections. > > Thanks for the feedback :) > > > So you can't round-robin between two default gateways. You /can/, > > however, send traffic for different destinations out of different links. > > For example, I send my nightly CVSup traffic and other automated > > downloads out of a regular ADSL link in order to prevent swamping my > > main link. > > What I'm hoping to do is find a way to route all paquets coming: > - from DMZ to internet, using NET connexion1 > - from LAN to internet, using NET connection2 > > To be more understandable, something like this: > route add from DMZ defaut em0 > route add from LAN defaut em1 > --> I know it is not a real command line, it's just to make things clearer. That's basically source-based routing, as opposed to the normal destination based routing. Normal routing says "Based on the fact that you want to go to network X, I'll send you to gateway Y". Source-based routing says "Based on IP address that you're coming from, I'll send to you to gateway Y". On FreeBSD, source-based routing is done with the IPFW 'fwd' command (or the IPFilter 'pass out quick on to ' syntax) rather that using the `route` command. I'm doing that myself (with IPFilter) and it works well. It's confusing to set up initially because you have to take into account the interaction between normal routing and firewall-based source routing. If you're also NAT'ing and using dynamic IPs understanding how it all can be made to work is an enlightening experience ;-) > > If your upstream providers support dynamic routing protocols, then you > > can get that destination information automatically. But that's not the > > same as load balancing, it's best-path selection. > > And if it doesn't ? Then you have to figure out and enter the best paths yourself as static routes. Pain in the butt and likely to drift from reality over time. For example, if my CVSup server of choice were to change it's IP address (which I have no control over and am not likely to be notified about), then my static route won't apply and my CVSup traffic, which I've so carefully ensured won't affect my main link, will start going over my main link. -T -- The tao that can be told is not the eternal Tao. The name that can be named is not the eternal Name. - Tao Te Ching