Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Jan 2008 11:58:50 -0800
From:      "Qing Li" <qingli@speakeasy.net>
To:        "'Randall Stewart'" <rrs@cisco.com>
Cc:        qingli@freebsd.org, freebsd-arch@freebsd.org
Subject:   RE: Routing in the network :-)
Message-ID:  <001801c85555$8d3bd970$8d335140@SAINTS>
In-Reply-To: <4788F1AE.4030502@cisco.com>
References:  <30834.1199989743@speakeasy.net> <4788F1AE.4030502@cisco.com>

next in thread | previous in thread | raw e-mail | index | archive | help

	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 <or> 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"
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001801c85555$8d3bd970$8d335140>