Date: Thu, 10 Jan 2008 09:55:41 -0500 From: Randall Stewart <rrs@cisco.com> To: freebsd-arch@freebsd.org Subject: Routing in the network :-) Message-ID: <478631ED.2030108@cisco.com>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?478631ED.2030108>