Date: Fri, 30 Jul 1999 11:51:15 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Joe Gleason" <freebsd.list@bug.tasam.com>, "Tom" <tom@uniserve.com> Cc: "Jeffrey J. Libman" <jeffrl@wantabe.com>, <freebsd-stable@FreeBSD.ORG> Subject: RE: routing over a dual t1 connection (fwd) Message-ID: <001601bedabc$805f0410$021d85d1@youwant.to> In-Reply-To: <006801bedab6$23b107a0$0286860a@tasam.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 1) It can be very easy to get working. > > > > > > Funny, you just said it was tricky to get working :) > > > > Tricky to get working _well_. Easy to get working. :) > > > > Adding an extra 'ip route' command takes 5 seconds. But then > watching your > > traffic balance terribly and performance go down is the hitch. > > I have done this is a production environment, the traffic balanced > perfectly. Then perhaps you'd care to share with us how you told the router whether it should route outbound traffic to avoid inbound traffic or not do so. Universally, the inability to control this is the largest problem that I have. Is there some 'outbound traffic avoids inbound traffic' mode that you can turn on or off? The router seems to make no distinction between shared and unshared media (bandwidth shared between inbound and outbound) and, as far as I can tell, uses an algorithm that is optimized for neither case. In addition, no single TCP connection seems to be able to use the combined bandwidth. They appear to be assigned to a single link and pretty much stay that way. This could be considered to be a feature, I suppose it depends upon your application. And if it did use both links for a single connection, large numbers of packets would be received out of order. This is because each link is considered a separate IP conduit. Techniques that bond the two links into a signle conduit do not have this problem. The decision of which link to assign a connection to seems made based upon long-term load calculations (30 _seconds_ or more), so traffic patterns that vary widely over short periods of time cannot easily be accounted for. I'd love to learn the tricks to fix this, because I'd prefer to use this solution. But I've had mediocre results every time I've tried it. DS 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?001601bedabc$805f0410$021d85d1>