802.3ad?

[Brad]

On Tue, Mar 28, 2006 at 10:56:46PM -0500, Richard A Steenbergen wrote:
> > 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.

Yes, 2 redundant paths represented by a virtual L2 interface is what he is
asking for. VRRP is for providing L3 redundancy for the next hop. A completely
different scenario.

> 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.
 
And bridging would imply both interfaces active which obviously won't work,
otherwise you're relying on STP to disable the other interfaces, and you
don't want this for all your servers/firewalls. This is not what trunk(4)
does. There is no bridging involved.

> 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.

I'm not sure what exactly it is that you're describing above. It almost sounds
as if you want a flat config with no config information split up by interfaces
be it physical, virtual L2 or virtual L3. I can't say as I've seen *any*
OS that can do that *exactly* as you describe.

With your comment about the layers stuff it sounds like you don't know how the
implementation actually works.

> > 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.

trunking = 801.Q/ISL and nothing else.

No they're not the same. I can't help it if you confuse the terminology and
do not use the terminology correctly. and this is a virtual L2 interface. The
OS provides the TCP/IP stack, not the network card.

> > 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 
> devices.

link aggregation implies that all links are active. this is FAILOVER. there is
no hash involved.

> > 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.

There is no trunking. You are confusing your terminology and on top of that
do not even know how the implementation even works. ECMP does not solve the
issue at hand, so stop trying to solve the issue with something that will not
do the job at all.