From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 07:54:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FC7816A4B3 for ; Sun, 5 Oct 2003 07:54:38 -0700 (PDT) Received: from storming.org (MG035035.user.veloxzone.com.br [200.165.35.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F47243FE3 for ; Sun, 5 Oct 2003 07:54:36 -0700 (PDT) (envelope-from fred@storming.org) Received: (qmail 57005 invoked by uid 1000); 5 Oct 2003 11:54:31 -0300 Date: Sun, 5 Oct 2003 11:54:31 -0300 From: Fred Souza To: Paul Robinson Message-ID: <20031005145431.GA42245@torment.storming.org> References: <20031004235400.GA20943@ussenterprise.ufp.org> <3F801CA7.60201@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <3F801CA7.60201@iconoplex.co.uk> X-Sender: fred@storming.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fred@storming.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 14:54:38 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Depends on how much money you have, but had you considered getting your= =20 > own address range and BGP peering with your ISPs? I'd consider talking=20 > to them about it. It'll take some time to setup, but it means your=20 > "switching" is done at the router, not at the NAT box, which is the=20 > wrong place to do it anyway. I think I have an inelegant solution to this, but one that could be implemented with even a simple script. If I understood what Leo asked correctly, what's needed is to change the default route on the FreeBSD gateway whenever an event tells it to (in this case, the increase/decrease in performance for the ISPs). The concern here is to keep currently-stablished connections alive, so the process is carried out seamlessly. Unless my tests were wrong, there's a way around it with the very base system tools. The idea is simple: Say the box has two valid IP addresses A.A.A.A and B.B.B.B, and that at a given moment A.A.A.A is being used as the default route. Whenever the event telling the system to switch the routes to B.B.B.B happens, you could parse the current routing table and the current list of open connections, and add a temporary, static route for each of these entries pointing A.A.A.A (the current default gateway) as their gateway (route add X.X.X.X A.A.A.A (or A.A.A.A's remote peer) - where X.X.X.X is the address of one of the open connections). Once you do that for all the current active connections, they'll be guaranteed to stay up when the next step takes place. Now you'd remove the default gateway entry in your routing table and add B.B.B.B (or its remote peer) as the default gateway. From this point on, all connections will use this route as the default, and noone should see the change. The downpoint of this approach is that the system will have to monitor the active connections periodically and remove the static routes after their previously active connections finish; This is because if you don't do so, all connections to a given address will be routed out through the default route at the time the first switch was made and there was a connection to that address. Another concern would be the decrease in perfomance on the FreeBSD gateway if its routing table gets too large (over tens of thousands of static routes). What makes this to work is that static routes have priority over default ones. One could work this up from this point. =20 =20 Fred --=20 "Real programmers argue with the systems analyst as a matter of principle." --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/gDCnZNmEsrl+ROERAqMTAKC0l3UVy1Rt709qkwuRhyDlfLEh3QCgugGT W1zIKhbeI4JlYM1NlRViLyM= =8UqY -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--