From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 14:28:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0389316A4A7 for ; Fri, 23 Jun 2006 14:28:09 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E5043D72 for ; Fri, 23 Jun 2006 14:28:04 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 4231 invoked by uid 1001); 23 Jun 2006 14:28:03 -0000 Date: Fri, 23 Jun 2006 16:27:40 +0159 From: 'Claudio Jeker' To: freebsd-net@freebsd.org Message-ID: <20060623142803.GG12611@diehard.n-r-g.com> Mail-Followup-To: 'Claudio Jeker' , freebsd-net@freebsd.org References: <20060623135144.GD12611@diehard.n-r-g.com> <53binj$o6s2np@iinet-mail.icp-qv1-irony5.iinet.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53binj$o6s2np@iinet-mail.icp-qv1-irony5.iinet.net.au> User-Agent: Mutt/1.5.11 Subject: Re: Multiple routes to the same destination 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: Fri, 23 Jun 2006 14:28:09 -0000 On Sat, Jun 24, 2006 at 12:04:25AM +1000, Christopher Martin wrote: > > > I doubt that. Doing a per packet round robin over different pathes will > > kill your tcp performance because of out of order packets. > > Noted. That's a very good reason. Maybe if there was a may to round robin on > a session basis to mitigate this. Not really going to be an easy fix, > however, so your point is very valid. > Most implementation do a per source/dst IP address hashing which should result in a similar distribution. > > > > > > It would seem that you are assuming that I want to load balance two > > internet > > > connections which are NATed, in which case round robin might have issues > > > with lost TCP sessions and weird reactions from servers as the apparent > > > source address changes from packet to packet, but in a routed internal > > > network the source address will not be changed by the router, thus > > negating > > > that issue. > > > > > > It did seem at some stage someone was going to include it in OpenBSD: > > > http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded > > > > > > > That's just part of the it. The rest was added in the last couple of days > > because multipath routing and accepting more than one route per > > destination is a scary thing. Additionally dead nexthop detection is not > > available. > > I would have thought OSPF would have provided your dead hop issues, however > it does not resolve your point above, so we still seem out of luck. > OpenOSPFD will learn to cope with multipath routes in the next few weeks but it will only work on OpenBSD. > > > To quote: > > > "...OSPF also supports multipath equal cost routing". > > > > > > > Yes it does but often you try to avoid that. > > Because of your point above? Besides that, can you provide a couple of > examples of why we would try and avoid it? > Multipath setups are harder to debug as packets may flow differently. Often it is easier to use a layer 2 trunk to aggregate links. It depends on your network layout, etc. > > > It's more of a case where we would like to use BSD as a router/packet > > > filtering firewall for sites with multiple WAN links between each site, > > of > > > equal size, and not have one site idle until the other fails over. Round > > > robin is better than what we have: nothing. > > > > OpenBSD is on the way to support this but it is still a long journey till > > all issues are resolved. Btw. OpenBSD uses a hash-threshold mechanism to > > select paths based on source/destination IP address pairs (round robin > > will never be supported). > > Again, another good point. And it also answers the other query as to the > level of work involved in making it work. > I hope that we can get more routing stuff done in the next few weeks but the way routing is implemented in BSD makes it harder then necessary. I bet andre@ will start to port features to FreeBSD as soon as the stabilised in OpenBSD. -- :wq Claudio