Skip site navigation (1)Skip section navigation (2)
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>