Routing in the network :-)
Qing Li
qingli at speakeasy.net
Sat Jan 12 11:58:48 PST 2008
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 at freebsd.org
> [mailto:owner-freebsd-arch at freebsd.org] On Behalf Of Randall Stewart
> Sent: Saturday, January 12, 2008 8:58 AM
> To: qingli at speakeasy.net
> Cc: qingli at freebsd.org; freebsd-arch at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscribe at freebsd.org"
>
>
More information about the freebsd-arch
mailing list