Routing in the network :-)

[Julian Elischer]

Randall Stewart wrote:
> 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...
> 

well you'd be hosed anyhow because the return packets
would STILL be routed to AT&T because you have an AT&T
address as a source address. Sending the packets out the
other way wouldn't help. SCTP ok, but UDP/TCP you're screwed
for that session.

For load sharing, I always use NAT of course so the
return packets come back to the right place,
and if I truely had two flaky providers I'd actually tunnel
to a common third point using Mpd.


> 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.
> <and>
> 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..

yeah return packets would still not get back

> 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.

I see no harm in this change in general but I think it should
be part of your SCTP capacity..as SCTP is the only
real user of this I think.

You MIGHT be able to use it in an organisation where you control both 
next hops..

> 
> 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 :-)

Cats have the ability to distinguish between blues and greens, but 
lack the ability to pick out shades of red
:-)

> 
> 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..

I think that these patches are of interest.
I'd certainly put them in P4..

> 
> R