Date: Thu, 22 Jul 1999 14:25:23 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: Mike Hoskins <mike@ns1.seidata.com>, freebsd-net@freebsd.org Subject: Re: etherchannel support Message-ID: <9907221425.ZM18435@beatrice.rutgers.edu> In-Reply-To: Mike Hoskins <mike@ns1.seidata.com> "Re: etherchannel support" (Jul 22, 2:10pm) References: <Pine.BSF.4.05.9907221413520.25178-100000@ns1.seidata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 22, 2:10pm, Mike Hoskins (possibly) wrote: > Hello, > > I was curious about etherchannel/NIC aggregation in FreeBSD... > browsing the archives turned up a thread that seemed to end up asking > 'what does Cisco do?'. > > What's the status of this now? Someone (luigi?) had asked about > methodology for choosing output interface, how to load balance, etc. > How would we go about actually 'bonding' multiple interfaces into one > logical trunk (single MAC, downed NIC detection, etc.)? Adaptec does > this with their Dura* product line, but I think the software is NT > only. > > http://www.adaptec.com/technology/whitepapers/portaggregationio1.html There are a couple of different options available for doing something like this. The first is multiple path support for routing; a beta is at ftp://ftp.flirble.org/pub/unix/hacks/FreeBSD/mpath. It does not include any means of balancing other than equal volume, and necessitates routing to multiple gateways as opposed to an interface route. I've been considering some improvements, namely looking at characteristics like collisions, output errors, and queue drops on the next 2 interfaces in the queue and deciding whether to use the first or second either randomly or deterministically (i.e., whichever looks the best gets the packet). The second is the true bonding you're discussing above. This is available for Linux in the Beowulf project; see http://beowulf.gsfc.nasa.gov/software/bonding.html. I'm primarily looking at the former, for various reasons including that we might have one interface going to a hub with an outside connection and the other interfaces going to isolated hubs; we'd want to be able to use the outside-interface'd hub (probably connected with a bridge to reduce collisions) to also relay data. I'm not really planning on doing much work on either in the near future, however, since we'd mainly be interested in it for connecting together multiple SMP machines for heavy data-crunching work, and we don't have the budget yet for the SMP machines et al. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9907221425.ZM18435>