Date: Tue, 28 Mar 2006 19:20:15 -0500 From: Richard A Steenbergen <ras@e-gerbil.net> To: Brad <brad@comstyle.com> Cc: freebsd-net@freebsd.org Subject: Re: 802.3ad? Message-ID: <20060329002015.GI45591@overlord.e-gerbil.net> In-Reply-To: <20060328215911.GA20602@blar.home.comstyle.com> References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 28, 2006 at 04:59:11PM -0500, Brad wrote: > On Tue, Mar 28, 2006 at 08:56:24PM +0000, Baldur Gislason wrote: > > Following an unrelated discussion about "interface grouping" in OpenBSD, > > I'd like to know if there are any known or planned implementations of LACP (802.3ad) > > interface teaming in FreeBSD? > > FreeBSD currently has etherchannel support, but to my knowledge that will only > > work for a link to a single switch and not provide the possibility of having layer > > 2 resiliance with paths to 2 switches in the same network. > > Any thoughts on this? > > 802.3ad is the standards track replacement for EtherChannel, thus it is not what you > are looking for. What you are asking for is L2 failover. OpenBSD's trunk(4) is such > an implementation. I don't see anything in FreeBSD that would have the same > functionality. Ah nothing says fun like watching systems people try to figure out networking. As I read it, he's looking for what ye olde networking people call "equal cost multi-path" (ECMP) layer 3 load balancing, which is of course very different from layer 2 load balancing. :) 802.3ad/etherchannel and L2 failover are actually the same thing, just with the load balancing algorithm turned off. Simple classic etherchannel is really nothing more than configuring both sides to know that these are trunk ports, and turning off forwarding among trunk members (i.e. you don't want a frame which came in one member to go out another member, unless you like forwarding loops). Everything else is pretty much automagic, you don't even need to have matching hashing algorithms on each end, just do whatever you need to do to shove the packets down the member ports as you see fit. 802.3ad is the standardization of Cisco's (tm) etherchannel, but the only thing it really brings to the table is the negotiation protocol. Cisco used a proprietary protocol called PagP, 802.3ad defines a standard version of the same thing called LACP. Essentially all this does is signal trunk membership information over the individual links, to prevent stupid misconfigurations that blackhole X percent of your traffic. For example say that you have 2 devices talking to each other with 4 trunk members, and someone disconnects a port from one and plugs it into a third device which has no knowledge of the trunks. The device that is still connected to that forth port has no way to know it is blindly blackholing 1/4th of the traffic going through this channel, without a signaling protocol. The operation of the L2 channel itself is really no different w/LACP or PagP or nothing, it just adds another mechanism besides "hey we don't have link any more" to shut individual members off if they're up to no good (or if for some reason you really don't want them utilized unless another link goes offline). As I read the man page, trunk(4) is just a classic protocolless implementation of simple etherchannel style trunking. The round robin option is a Bad Idea (tm) though, unless you like reordering your packets and pissing off tcp royally. I believe FreeBSD has a netgraph implementation of this, though I've personally never used it. At the present time I don't believe fbsd makes any effort to even consider the possibility of supporting the installation of multiple nexthops for a route, let alone how to do it correctly. Andre Oppermann is probably the person to pester about that, I know he's been doing a lot of work recently trying to bring fbsd's routing code into the 21st century. If you're bored and looking for something to work on outside of the routing code, I think both fbsd and obsd's L2 channeling implementations suck badly. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060329002015.GI45591>