From owner-freebsd-arch@FreeBSD.ORG Thu Jan 10 15:26:22 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597E616A418 for ; Thu, 10 Jan 2008 15:26:22 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA5213C442 for ; Thu, 10 Jan 2008 15:26:22 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.24,267,1196668800"; d="scan'208";a="11135899" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Jan 2008 06:58:17 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0AEwHN0032725 for ; Thu, 10 Jan 2008 06:58:17 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0AEwHSb010312 for ; Thu, 10 Jan 2008 14:58:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 06:58:10 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 06:58:10 -0800 Message-ID: <478631ED.2030108@cisco.com> Date: Thu, 10 Jan 2008 09:55:41 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2008 14:58:10.0251 (UTC) FILETIME=[374639B0:01C85399] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4995; t=1199977097; x=1200841097; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Routing=20in=20the=20network=20=3A-) |Sender:=20; bh=vBtBrJv4Tw15hDOspCfmS+tbHPTS8G4JghD64XE4kO8=; b=WXTe1iCf1yWxZi+2GHVZ67cB9SNy0t8cJ5JDAvPeNHpx/YIHD2/F5aUhFX eUWSTkAtWqgxDIKZJdYbiiQTWWng9eeCGjiF/7T0284LnXtgkux5ZmKPWIx4 G2u+VPqwdCxw40JYlgzs+5kOObY6yb/CFHvXgZPK9Uf/hAUcPj0kI=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Routing in the network :-) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 15:26:22 -0000 Hi all: A number of years ago, Itojun and I had played off and on with some modifications to both the routing table and to a "new" interfaces that could be used by transports to gain routing information. I am contemplating digging back in my archives and building a p4 branch that would have the changes for folks to look at.. But before I go to all that trouble I want to have a discussion about this here ;-) This will be a longish email so if you get bored easily or just don't care about routing/networks and all that fun, you have been warned :-) The basic concept: So say I am at home and have purchased two DSL's. One from AT&T (don't you love the new ma-bell) and the other from SpeakEasy (Note I had this until I moved out to the country now I am lucky to have one DSL.. but many can do this if they want)... So my home looked like: IP-A IP-S | | | | | | ,__|__________|___ | | | | | lakerest.net | | | |_________________| Now life is good, I have some degree of fault tolerance right? So AT&T (IP-A) gives me the default route to IP-A1 and Speak Easy gives me the default route to IP-S1. Life is not so good... how do I plumb these in the routing table? I can say route add default IP-A1 or route add default IP-S1 But I cannot have both. And worse if I had a connection up to FreeBSD.net and AT&T's network went down.. and I happened to have put the first command in.. my network connection would stop... What would be nice if I had a way to add BOTH routes into the kernel.. and when Layer 4 realized there was some major problems going on it could "use" the alternate route (i.e. via IP-S1) and life would once again be good.. Ok, yes, the observant person out there will say.. wait IP-S1 will NEVER allow your packets through since they probably do ingress filtering.. yes I am aware of this.. but this would *NOT* hold true for some device in the network talking to some other device in the network.. *OR* for speakeasy.. at least not circa 2004.. since speakeasy did *NOT* do ingress filtering and my way back former employer (AT&T) *DID* do ingress filtering.. So the idea is rather simple: 1) Allow multiple routes on any level of the kernel patricia trees. 2) Add an additional interface to the routing code so that a transport protocol could query the routing table for additional support... i.e. excuse me, the route that I had no longer seems to be working, do you have an alternate gateway? Now I admit for TCP these API's would have limited use.. but for SCTP these are golden.. since both sides know about all addresses and thus you get a form of true network diversity out of this little software change. Now yes, this does not help you if both your DSL's go out to the same pole outside your house, and a truck hits the pole... but it *DOES* help you if your network provider dies somewhere back in the CO *OR* if your cat decides it really likes the red cable running across your carpet to AT&T's DSL and it thinks chewing on it would be fun :-) So what was required way back in 4.x when Itojun and I did this work.. (note that Itojun called his changes RADIX_MPATH which did NOT include my alternate routing lookup code). a) For radix.c there were just a few simple changes that removed the restriction that prevents duplicate routes at any level of the tree. b) For route.c a new method is added.. this is a bit of code not huge but some. c) One thing I added but took back out, was some changes to the "route delete" api... can't remember exactly where.. but basically the delete does not look at the destination ... i.e. with the changes Itojun and I had cooked up if you said: route add default IP-1 route add default IP-2 route add default IP-3 and then when.. opps.. I don't want IP-2, you could NOT say route delete default IP-2.. well you could but it did no good.. it removed the first one (IP-1). I had a fix for this but Itojun thought it was too radical since it changed an interface to one of the routing routines... so we just settled for the fact that if you did that you got to have the pleasure of using: route delete default 3 times.. and then starting again... So is it worth my time resurrecting these patches for 8.0? Objections (being in a routing company I know there will be a lot of them.. gee the routing system is supposed to do that.. etc etc). Comments would be welcome before I dust off the patches.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell)