Date: Sat, 31 Dec 2005 21:42:29 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Loren M. Lang" <lorenl@alzatex.com>, "Danial Thom" <danial_thom@yahoo.com> Cc: Yance Kowara <yance_kowara@yahoo.com>, freebsd-questions@freebsd.org Subject: RE: FreeBSD router two DSL connections Message-ID: <LOBBIFDAGNMAMLGJJCKNAECOFDAA.tedm@toybox.placo.com> In-Reply-To: <20060101023104.GA31327@alzatex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: Loren M. Lang [mailto:lorenl@alzatex.com] >Sent: Saturday, December 31, 2005 6:31 PM >To: Danial Thom >Cc: Loren M. Lang; Ted Mittelstaedt; Yance Kowara; >freebsd-questions@freebsd.org >Subject: Re: FreeBSD router two DSL connections > > >On Wed, Dec 21, 2005 at 09:55:37AM -0800, Danial Thom wrote: >> >> >> --- "Loren M. Lang" <lorenl@alzatex.com> wrote: >> >> > On Sun, Dec 11, 2005 at 11:28:17PM -0800, Ted >> > Mittelstaedt wrote: >> > > >> > > If both DSL lines go to the same ISP it is >> > easy, run >> > > PPP on them and setup multilink PPP. The ISP >> > has to >> > > do so also. >> > > >> > > If they are going to different ISP's then you >> > cannot >> > > do it with any operating system or device >> > save BGP - the idea is >> > > completely -stupid- to put it simply. If you >> > think different, >> > > then explain why and I'll shoot every >> > networking scenario >> > > you present so full of holes you will think >> > it's swiss cheese. >> > > And if you think your going to run BGP I'll >> > shoot that full >> > > of holes also. >> > >> > I strongly disagree. There are many reasons >> > for this. Two of which are >> > increased throughoutput and redundancy. The >> > primary problem is that you >> > need to make sure outgoing data for a >> > connection is using the same line >> > as the incoming connection. If the majority to >> > all connections are >> > outgoing and both lines use NAT and have unique >> > IP addresses, it's >> > simpler to setup. If you have incoming >> > connections as well, either only >> > one of the two lines will be used or you'll >> > need BGP or some kind of >> > static route setup by the two ISPs. For an >> > internet cafe, most >> > connections will probably be outgoing so it >> > won't be a problem. >> >> Thats not right at all, although in *some* cases >> it may be desirable. All upstream ISPs are >> connected to everyone on the internet, so it >> doesn't matter which you send your packets to >> (the entire point of a "connectionless" network. >> They both can forward your traffic to wherever >> its going. For efficiencies sake, you may argue >> that sending to the ISP that sent you the traffic >> will be a "better path", but if one of your pipes >> is saturated and the other running at 20% then >> its likely more efficient to keep your pipes >> filled and send to "either" isp. You can achieve >> this with per-packet load-balancing with ciscos, >> or bit-balancing with a product like ETs for >> FreeBSD. Unless your 2 isps are connected >> substantially differently (say if one is in >> Europe and one in the US), you'll do better >> keeping your pipes balanced, as YOU are the >> bottleneck, not the upstream, assuming you have >> quality upstream providers. > >You are correct in the case of a normal router, but >this is not a normal router, this is an NAT router >with two different incoming pipes with two unique ip >addresses. As far as each ISP is concerned, they are >providing bandwidth to a single computer that is not >the same as the other ISP. There is no information >that connects the two together. With NAT, the >network behind is hidden and normal routing can't >take place. Only outgoing connections can take place, >and the from address is modified to be the same as the >IP address on the pipeline it is leaving from. On a NORMAL nat device this is correct, what Danial was recommending is a modified NAT that basically "favors" one of the 2 outside addresses that it has, as the source address for all connections, and sends traffic sourced with this address out both pipes, depending on what pipe might be available at the time. He was arguing more on a theoretical level, I personally don't know of any NAT devices that can do that, but perhaps there are some. Certainly, something like that could be written if it doesen't exist. >Internet routers won't know that the other ip address >is the same computer it doesen't matter if they know or not. >and even if they did know, the >NAT software on the router might discard the packets >because the data is arriving on the wrong interface. Yes, that is one of the things the NAT would have to keep track of. It could certainly be done. I maintain that the upstream ISP's would not allow something like this to work, due to antispoof filters. Danial maintained that upstream ISP's don't run antispoof filters, and thus it would work. >Incoming connections work only if the router is setup >to do port forwarding. The problem here with sharing >the bandwidth is that each pipeline has it's own >address and there is no way to specifiy an address of a >computer behind the router because each ISP has only >allocated one address to their customer and there are >no entries in the routing tables for computers behind >them. None of that is applicable to the scenario that Danial described. >Bandwidth sharing is possible with an NAT router, >but not connection sharing. > If your going to restrict each connection to the max bandwidth of the fastest pipe, you are really not bandwidth sharing. The general public is going to expect that anything labeled "a bandwidth sharer" that is designed to work with multiple ISP's would view the speeds of the links as additive for any connection. In short, if you have 2 1MB pipes, you should be able to download the FreeBSD ISO at 2MB, not 1MB. Well, marketing people can argue semantics all they want on this issue, but in this case the general public is right. If you mention load balancing or bandwidth sharing to a network engineer they are going to assume the same thing - that any given session would be able to potentially run at the aggregated speed of all circuts "shared" by the bandwidth sharer. What you have with a device that runs as a NAT router but limts any session to the fastest speed of the fastest pipe, is a "redundant circuit management device" But, bandwidth sharer sounds more sexy so that's why the makers of such devices use the terminology incorrectly. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNAECOFDAA.tedm>