Routing in the network :-)

[Randall Stewart]

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

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

R
-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)