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

next in thread | previous in thread | raw e-mail | index | archive | help
The catch here is you can send out your other link, but your partner
cannot send back to your other address via that link since the ISP
won't route it that way.  To make your partner know to switch over
means major mods to TCP, equivalent to replacing it with SCTP.
Barney

On Fri, Nov 02, 2001 at 04:16:41PM -0600, Randall Stewart wrote:
> 
> 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

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?20011102175533.B38677>