Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Nov 2001 14:01:28 -0800
From:      Lars Eggert <larse@ISI.EDU>
To:        Barney Wolff <barney@databus.com>
Cc:        Randall Stewart <randall@stewart.chicago.il.us>, freebsd-net@FreeBSD.ORG, xbone@ISI.EDU
Subject:   Re: SCTP and multiple default routes
Message-ID:  <3BE317B8.3040108@isi.edu>
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 Wolff wrote:

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


The big drawback is that it requires a completely new protocol...

It also requires both peers to speak SCTP, and applications in question

must be changed to run over SCTP as well. In other words, it doesn't

work yet, and it will be some time before it does, and then only for modified apps.

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


You can get the exact same behavior toady, with existing Internet 
protocols: Create an IP tunnel to the peer over one interface pair, 
switch the tunnel over to the other pair in case of failure. This is 
transparent to the application (it uses the virtual addresses of the 
tunnel), uses existing protocols (TCP/UDP over IP in IP), works now.

Only new piece is reconfiguring your tunnel, which is trivial (one or 
two system commands, and can be easily automated.)

But we should probbaly move this discussion over to tsvwg... :-)

Lars
-- 
Lars Eggert <larse@isi.edu>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California


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?3BE317B8.3040108>