Date: Mon, 14 Jan 2008 21:32:45 -0500 From: Randall Stewart <rrs@cisco.com> To: Qing Li <qingli@speakeasy.net> Cc: qingli@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Routing in the network :-) Message-ID: <478C1B4D.4070507@cisco.com> In-Reply-To: <001801c85555$8d3bd970$8d335140@SAINTS> References: <30834.1199989743@speakeasy.net> <4788F1AE.4030502@cisco.com> <001801c85555$8d3bd970$8d335140@SAINTS>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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"
>>
>>
>
>
>
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478C1B4D.4070507>