Date: Thu, 29 Jul 1999 21:30:14 -0700 (PDT) From: Tom <tom@uniserve.com> To: David Schwartz <davids@webmaster.com> Cc: Joe Gleason <freebsd.list@bug.tasam.com>, "Jeffrey J. Libman" <jeffrl@wantabe.com>, freebsd-stable@FreeBSD.ORG Subject: RE: routing over a dual t1 connection (fwd) Message-ID: <Pine.BSF.4.02A.9907292121450.17897-100000@shell.uniserve.ca> In-Reply-To: <000001beda3e$da10bc70$021d85d1@youwant.to>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Jul 1999, David Schwartz wrote: > > I suggest getting a Cisco 2500 or 2600 series router. They can > > do the load > > balancing quite easily and 2 T1's can be attached to either. I > > know this is > > a non-freebsd solution, but I have always found that a hardware > > router with > > no drives and few moving parts is quite reliable. I know this is > > not where > > I should be peddling my wares, but I have a 2500 and a 2600 for sale. ;-) > > > > Joe Gleason > > Tasam > > There are several problems I have had with that type of setup: > > 1) The router has a problem separating inbound traffic from outbound > traffic. It can start to move outbound traffic away from an interface just > because its inbound traffic level is high. Or, for shared media, it can > continue to route large amounts of outbound traffic to an interface, causing > the inbound traffic to collide to hell. No. Balancing on Cisco products is done via the routing table. If multiple routes exist to a destination, traffic is balanced. Each route has a "use" counter, and the route with the lowest "use" value is one used for the traffic. There are some other options too. > 2) While you can control the way your outbound traffic splits, you can't > control the inbound traffic. If the other end isn't configured just right, > your inbound traffic will be badly split and there isn't a thing you can do > about it. Sure, inbound traffic is up to the other end. It isn't too difficult to configure, in fact, it is really easy. > 3) Recovery from a single link failure is often very bad. This isn't quite > so bad for serial links because the router can usually discover a link > failure pretty rapidly. But if it can't, if something fails at a higher > level, it's very difficult to get good failover. You can try to implement > failover at a higher level with IP routing protocols, but if this is a link > to an ISP, they are unlikely to be willing to do this. Most links to ISP are going to be serial links, or maybe cross-over ethernet, where carrier loss is going to pretty accurate. ISPs use of routing protocols between customers is very common now. > 4) The only splits possible are even or none. You can't allow a little > traffic, or just overflow traffic to take one link. This problem is worst > for shared media (like Ethernet), where inbound traffic and outbound traffic > can collide badly, even if both directions are well split. Not all ethernet is shared, only half-duplex. The solution for that problem is obvious. Cisco has quite slow to adopt full-duplex ethernet interfaces. There is really very little available on models less than the 4500. > 5) The load is measured over too long a period of time and commitments are > made to route connections over one link or another which the router can't > quickly change. Dramatically varying traffic patterns are very badly split. Not really. > Don't draw the wrong conclusion. I'm not saying you should never do this. > Sometimes it is the best solution. But it can have some really serious > drawbacks. The biggest advantages of this setup are: > > 1) It can be very easy to get working. Funny, you just said it was tricky to get working :) > 2) It doesn't cause too many out-of-order packets to be received. > > 3) It's fairly inexpensive, especially if you already have a Cisco router > with a spare fast serial port. > > 4) Cisco routers are very solid and can have many months of uptime without > a problem. > > DS > Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9907292121450.17897-100000>