Richard A Steenbergen ras at e-gerbil.net
Wed Mar 29 03:56:51 UTC 2006

On Tue, Mar 28, 2006 at 09:03:43PM -0500, Brad wrote:
> On Tue, Mar 28, 2006 at 07:20:15PM -0500, Richard A Steenbergen wrote:
> > 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?
> He was not asking for ECMP. He clearly asked for a failover mechanism
> for two switches within the SAME Layer *2* domain.

Hrm ok I misread the original post, but I'm still not exactly sure what 
the original poster wanted. 2 redundant paths out via two switches? Sounds 
like an application for VRRP to me.

The operations you're really trying to support are:

a) Routing or bridging directly on an interface,
b) Creating a virtual L2 interface (such as link-agg) and then routing or 
   bridge on it, or
c) Bridging on the physical interfaces, making them members of the same 
   vlan, and then creating a common virtual L3 interface for the vlan.

C) is probably what the original poster is going for, so that they can 
talk to two different switches on two different physical interfaces via a 
common L3 interface.

A properly designed system should be seperating out these layers 
internally, in order to tie all of these features together under a common 
framework. Whether you configure your L3 interface on one physical 
interface, a virtual L2 interface composed of multiple member links, or an 
L2 vlan which may be mapping to one or many physical ports (or having 
multiple L2 vlans map to a single physical interface doing 802.1q), it 
should all be the same. It should be designed this way from the lower 
layers up, not from the higher layers down, with funky bridging hacks and 
funky vlan hacks and funky link-agg hacks.

> What does link aggregation have to do with trunk ports? Link aggregation
> and trunk ports can be configured separately or in a combined fashion but
> in this scenario there is no need or use for trunking. What you have
> described is still not what trunk(4) does.

Ok so, I'm not sure what you think trunking means (in all fairness it IS 
probably one of the most abused terms out there :P), but link aggregation 
and "trunking" as it is used in this context are the exact same thing. 
You're taking two seperate physical L2 channels, binding them together 
under a common virtual L3 interface, applying certain rules like "don't 
create forwarding loops", and using some mechanism to decide what traffic 
to send to what links. Methods like "round robin" and "backup only" just 
happen to be really bad/unusual hashes, but in all other respects it is 
link aggregation.

> PAgP is the negotiation protocol for EtherChannel. So LACP is not bringing
> anything new to the table, except getting away from Cisco propreitary
> standards, which is a really good thing.

I think thats what I said before. :)

> In theory round robin is bad but in reality it is not as bad as is typically
> made out, plus it also depends on the protocols being used over this link.

Reordering tcp packets within a flow has a definite and profound impact on 
the performance of those flows, unless your link speed is so low already 
that it doesn't much matter. If you don't have any mechanism that attempts 
to hash individual TCP flows onto a specific channel/trunk/aggregation 
member, you will most definitely see reordering within a flow.

If you're talking 4xT1's or something this probably isn't a big deal, if 
you're talking NxFE or NxGE speeds and high speed flows it probably is. 
I'm not saying they shouldn't be providing the option if you REALLY want 
per-packet load balancing, but I don't see any sane reason to make that 
the only load balancing mechanism.

> trunk(4) can also provide L2 failover with a primary uplink and one or more
> backup uplinks. trunk(4) can also work in other scenarios like for example
> failover between a wireless uplink and a Ethernet uplink, when the AP is
> within the same L2 domain (bridging AP, as opposed to a router) as the
> Ethernet uplink.

Like I said, that is actually just link aggregation, but with an unusual 
"member aware" hash that isn't often implemented in commercial networking 

> You can think it sucks all you want, but it makes me sleep sounder at night
> knowing I can engineer my system with higher availability in mind with trunk(4)
> in use than is currently possible with a FreeBSD/NetBSD/DragonFly system.

Well, just to be clear, its the implementation that sucks not the concept. 
I still think you're confused about what the "trunking" is actually buying 
you though. The original motivation behind creating etherchannel style 
link aggregation was for L2 switches to be able to talk to each other with 
more capacity than a single link can provide. The inability to create 
operational parallel paths without forwarding loops or a specific 
etherchannel construct is an issue that only exists at L2. You still need 
this L2 construct in order to happily work with all the devices out there 
(though now we just dig deeper into the header to do L3/L4/Payload 
hashing on these L2 trunks), but a properly designed ECMP system would 
solve a lot of issues too.

Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

More information about the freebsd-net mailing list