From owner-freebsd-current Tue May 21 9:31: 0 2002 Delivered-To: freebsd-current@freebsd.org Received: from agamemnon.cnchost.com (agamemnon.cnchost.com [207.155.252.31]) by hub.freebsd.org (Postfix) with ESMTP id C2E5C37B405 for ; Tue, 21 May 2002 09:30:55 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by agamemnon.cnchost.com id MAA18371; Tue, 21 May 2002 12:30:46 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200205211630.MAA18371@agamemnon.cnchost.com> To: Terry Lambert Cc: "Vladimir B. Grebenschikov" , Oleg Chebotarev , freebsd-current@FreeBSD.ORG Subject: Re: multi default routes in freebsd !? In-reply-to: Your message of "Tue, 21 May 2002 02:13:36 PDT." <3CEA0FC0.E71EC770@mindspring.com> Date: Tue, 21 May 2002 09:30:45 -0700 From: Bakul Shah Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > BGP is a better idea (of course). > > You might also consider using BGP. > > And have I mentioned BGP? 8-) 8-). Whether to use BGP/OSPF is orthogonal to multipath use. Both OSPF and BGP allow you to install multiple next hops. Adding multipath support requires, at a minimum, changing struct rtentry to store multiple `gateways' (which are really next hops). You also need to fix up code to do the right thing when adding a new route or deleting an existing route (for example, a route is not considered dead until paths all next hops are dead). For forwarding a packet you can always use the first next hop to start with but very likely you'd want to change the forwarding code and use some policy to pick a next hop. Typically you'd want to use the same next hop for a given source so as to not mess up TCP RTT calculations. Seems to me that the needs of client, server and router machines are different enough that the networking stack code needs to be much more flexible. One can always put in the most elaborate solution and just not use fancier features for client machines but then every one pays the cost of complexity. Not sure what is the right thing to do here. Anyone care to pontificate? The same situation exists w.r.t. a number of other features. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message