Re: Routing in the network :-)
- From: Julian Elischer <julian@xxxxxxxxxxxx>
- Date: Thu, 10 Jan 2008 12:30:19 -0800
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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- Routing in the network :-)
- From: Randall Stewart
- Routing in the network :-)
- Prev by Date: Re: Routing in the network :-)
- Next by Date: Re: [PATCH] lockmgr and VFS plans
- Previous by thread: Routing in the network :-)
- Next by thread: Re: Routing in the network :-)
- Index(es):
Relevant Pages
|
|
