Date: Thu, 10 Jan 2008 12:30:19 -0800 From: Julian Elischer <julian@elischer.org> To: Randall Stewart <rrs@cisco.com> Cc: freebsd-arch@freebsd.org Subject: Re: Routing in the network :-) Message-ID: <4786805B.6010303@elischer.org> In-Reply-To: <478631ED.2030108@cisco.com> References: <478631ED.2030108@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4786805B.6010303>