From owner-freebsd-arch@FreeBSD.ORG Tue Jan 15 02:37:30 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 5139F16A421; Tue, 15 Jan 2008 02:37:30 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 247A813C4D5; Tue, 15 Jan 2008 02:37:30 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.24,284,1196668800"; d="scan'208";a="8107465" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2008 18:37:29 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m0F2bTaH028033; Mon, 14 Jan 2008 18:37:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0F2bPid015263; Tue, 15 Jan 2008 02:37:29 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); Mon, 14 Jan 2008 18:35:17 -0800 Received: from [128.107.155.117] ([128.107.155.117]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jan 2008 18:35:17 -0800 Message-ID: <478C1B4D.4070507@cisco.com> Date: Mon, 14 Jan 2008 21:32:45 -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: Qing Li References: <30834.1199989743@speakeasy.net> <4788F1AE.4030502@cisco.com> <001801c85555$8d3bd970$8d335140@SAINTS> In-Reply-To: <001801c85555$8d3bd970$8d335140@SAINTS> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jan 2008 02:35:17.0165 (UTC) FILETIME=[43B5CDD0:01C8571F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8979; t=1200364649; x=1201228649; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Routing=20in=20the=20network=20=3A-) |Sender:=20; bh=KFOqP+jfVkIyGRVo68IEBw8ePExte+VojwbAqfifrM8=; b=VVx8ekhu0xb5/qz/rUiAWNa4hvA1wMQmhmD9ayN/o/BXC0u9tomm3ypnja De370cJOQFhpf8SVrmv2l3wmJbBBxic17FnUpJyipT9uQVDIHfItw2edCUPg fLYanX0Vmg; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: qingli@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 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: Tue, 15 Jan 2008 02:37:30 -0000 Great.. I will await your email :-D R Qing Li wrote: > Okay, I will pull the branch and start the work on it. > Let me get all of my changes in place and after testing > the features out, I will ping you and you can let me > know if you require additional support, we'll just go > from there. > > -- Qing > > > >>-----Original Message----- >>From: owner-freebsd-arch@freebsd.org >>[mailto:owner-freebsd-arch@freebsd.org] On Behalf Of Randall Stewart >>Sent: Saturday, January 12, 2008 8:58 AM >>To: qingli@speakeasy.net >>Cc: qingli@freebsd.org; freebsd-arch@freebsd.org >>Subject: Re: Routing in the network :-) >> >>Qing Li: >> >>Ok, the branch is created :-) >> >>//depot/user/rrs/alt_route >> >>Please go ahead and pull a copy and add your changes.. unless >>you would like me to ressurect my old patches.. (let me know).. >> >>If you put your patches in ping me to tell me they are in .. >>and then I will ressurect my old alternate route lookup patch >>and the changes to SCTP to use it :-) >> >>Ping me either way >> >> >>R >> >>Qing Li wrote: >> >>> Interesting you are bringing this up ... I actually >> >>sent a similar email to freebsd-net@ >> >>> about 2 years ago and had one response back (it was a >> >>polite no). >> >>> I back ported and integrated the radix_mpath changes >> >>from KAME into FreeBSD 5.4 >> >>> and the changes are working good right now in >> >>production environment. Changes >> >>> were also necessary in quite a few place throughout the >> >>netinet/ files, e.g., >> >>> address initialization functions such as in_ifinit(). >>> >>> I actually discussed what I have done with itojun back >> >>in August of 2007. >> >>> >>>>On Thu Jan 10 6:55 , Randall Stewart sent: >>>> >>>>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. >>>> >>> >>> >>> This is done. >>> >>> >>> >>>>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? >>>> >>> >>> >>> There was a inp_route field in the in_pcb{} structure but >>> that field was later removed by Andre in 5.5. I never quite >>> understood why but I did find that field to be rather useful. >>> >>> union { >>> /* placeholder for routing entry */ >>> struct route inc4_route; >>>#if 1 /* def NEW_STRUCT_ROUTE */ >>> struct route inc6_route; >>>#else >>> struct route_in6 inc6_route; >>>#endif >>> } inc_dependroute; >>> >>> I used this field for caching and it gets flushed when >>> there is a routing table change. Works out good. >>> >>> >>> >>>>Now I admit for TCP these API's would have limited use.. >>>> >>> >>> >>> That depends ... :-) >>> >>> >>> >>>>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 >>>>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. >>>> >>> >>> >>> The rtrequest1() function needed a bit of work but not so huge. >>> >>> >>> >>>>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... >>>> >>> >>> >>> I have been enhancing the code for some time now ... >>> >>> I can do both route delete and even route modification (I added >>> route preferences in addition to ECMP). >>> >>> I have 7 fundamental test cases to perform on the >> >>implementation to ensure >> >>> both correctness and compatibility. >>> >>> >>> >>>>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.. >>>> >>> >>> >>> I would like to get these changes made into 8.0. >>> >>> If there is enough interest out there, I'd be happy to >> >>share my implementation >> >>> and we probabaly can collaborate on this effort if that >> >>works for you. >> >>> -- Qing >>> >>> >>> >>>R >> >> >>-- >>Randall Stewart >>NSSTG - Cisco Systems Inc. >>803-345-0369 803-317-4952 (cell) >>_______________________________________________ >>freebsd-arch@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>To unsubscribe, send any mail to >>"freebsd-arch-unsubscribe@freebsd.org" >> >> > > > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell)