From owner-freebsd-net Fri Nov 2 14:16:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by hub.freebsd.org (Postfix) with ESMTP id 58C8737B40D for ; Fri, 2 Nov 2001 14:16:45 -0800 (PST) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fA2MGoX23783; Fri, 2 Nov 2001 14:16:50 -0800 (PST) Received: from stewart.chicago.il.us (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AAE31804; Fri, 2 Nov 2001 14:16:41 -0800 (PST) Message-ID: <3BE31B48.47A88007@stewart.chicago.il.us> Date: Fri, 02 Nov 2001 16:16:41 -0600 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff Cc: Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: SCTP and multiple default routes References: <3BE30097.C02C828D@stewart.chicago.il.us> <3BE303EA.1040506@isi.edu> <20011102162701.A38190@tp.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 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