Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Nov 2001 16:16:41 -0600
From:      Randall Stewart <randall@stewart.chicago.il.us>
To:        Barney Wolff <barney@databus.com>
Cc:        Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG
Subject:   Re: SCTP and multiple default routes
Message-ID:  <3BE31B48.47A88007@stewart.chicago.il.us>
References:  <3BE30097.C02C828D@stewart.chicago.il.us> <3BE303EA.1040506@isi.edu> <20011102162701.A38190@tp.databus.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Barney:

Comments below...

Barney Wolff wrote:
> 
> On Fri, Nov 02, 2001 at 12:36:58PM -0800, Lars Eggert wrote:
> >
> > Disclaimer: I may be biased here, because I think implementing
> > multi-homing at the transport layer (like SCTP tries to) is a bad idea
> > in general. It's a network layer concept, reimplementing it at the
> > transport layer gives you no new capabilities.
> 
> Whether or not multiple default routes is a good idea, SCTP-style
> multihoming makes a tremendous difference for small organizations
> that cannot justify getting a block of addresses big enough to be
> routed by multiple providers.  With SCTP I can have a host with
> an address from a cable-modem provider and another from a dsl provider
> and my peers can treat both as addresses of my one machine, so
> connections will not break if one link goes down.  The big payoff
> for the Internet as a whole is I don't need a separate route to me
> in the global routing tables.
> 
> I would gladly pay for two such links if there were an automatic way
> to switch away from a broken link.  Without asking cable or dsl
> providers to talk bgp to me (which they will surely refuse to do)
> this is not easy.
> 
I could not have put it better myself!! 

1) The current internet is once again getting exponential growth
   in the routing tables due to multi-homing. The big boys are
   forcing ISP's to advertise there network address has a host
   route thus breaking aggregation. This is a BIG problem.

2) Little guys do not have the muster to make their ISP do anything
   except tell you.. here is your default route... and no way will
   I advertise your other IP address... (golden rule of business applies
   here .. he who has the gold makes the rules :>)

3) If I have two default routes.. one for my cable modem and one for
   my DSL provider. I can set both in. Now when a peer that has the
   same arrangment sets up an association with me it tells me its 
   two addresses. I then enter these in and do:
   a) net->rt = rt_alloc(first-addr);
   b) net2->rt = rt_alloc_alt(second-addr,net-rt);

   Now what rt_alloc_alt does is attempt to give me an alternate route
   out a different interface if possible. This might mean we expand
   the node entry for each level of the routing tree to have a list
   of alternate entries behind it.

   It is simple for the little guy and solves his problem and
   if big guys use it the routing tables do not have to grow
   so fast ...

Yes I know there IS one issue.. i.e. we can still have a broken
scenario where I choose my routes opposite of my peer. But with
a little thoughtful work with the SACK generation even that
can be overcome...

a) You have to make sure that SACK's do not go to
   the source address when you have it marked down

<and>

b) When you receive duplicates you must SACK to other
   addresses .

This will cause a minor performance degregation while
the both sides are detecting the failure .. but 
thats better then going OOS.

R



Better yet maybe a error counter 

R
  


> --
> Barney Wolff
> 
> "Nonetheless, ease and peace had left this people still curiously tough.
> They were, if it came to it, difficult to daunt or to kill; and they were,
> perhaps, so unwearyingly fond of good things not least because they could,
> when put to it, do without them, and could survive rough handling by grief,
> foe, or weather in a way that astonished those who did not know them well
> and looked no further than their bellies and their well-fed faces." J.R.R.T.

-- 
Randall R. Stewart
randall@stewart.chicago.il.us 815-342-5222 (cell phone)

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BE31B48.47A88007>