From owner-freebsd-net@FreeBSD.ORG Fri Aug 1 12:30:56 2003 Return-Path: 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 66AEC37B401 for ; Fri, 1 Aug 2003 12:30:56 -0700 (PDT) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C4DC43FA3 for ; Fri, 1 Aug 2003 12:30:55 -0700 (PDT) (envelope-from Helge.Oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])h71JUr9U078949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2003 21:30:53 +0200 (CEST) (envelope-from Helge.Oldach@atosorigin.com) Received: from dehhx004.hbg.de.int.atosorigin.com (dehhx004.hbg.de.int.atosorigin.com [161.90.164.40]) ESMTP id h71JUrqm031854; Fri, 1 Aug 2003 21:30:53 +0200 (CEST) (envelope-from Helge.Oldach@atosorigin.com) Received: by dehhx004.hbg.de.int.atosorigin.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Aug 2003 21:30:53 +0200 Message-ID: From: "Oldach, Helge" To: "Michael W. Oliver" Date: Fri, 1 Aug 2003 21:30:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-net@freebsd.org Subject: RE: Multipath Routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Aug 2003 19:30:56 -0000 > I am no programmer, so forgive my ignorance in that respect, but why can't a > metric be used to differentiate routes to the same destination network > within the routing table? I happened to be googling and found: > > http://daily.daemonnews.org/view_story.php3?story_id=3878 > > which describes a patch to -STABLE that does exactly what I am talking > about. Routing will always follow the better metric. That's the paradigm. So if you have two routes the one with the better metric will always rule. Frankly, I don't quite see the rationale for such a hack. This can be solved using available mechanisms such as VRRP (or HSRP, if the gateways are decent routers). Furthermore: It doesn't detect when remote hosts are down. This is not the job of the kernel. It's not a routing protocol, it's not an automatic failover system. So what is this good for, that cannot be solved by already available mechanisms? Helge