802.3ad?

[Richard A Steenbergen]

On Tue, Mar 28, 2006 at 11:45:58PM -0500, Brad wrote:
> 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.

Ok listen screwball. Ignore the advanced theory, it's clearly not getting 
through. I'm not going to waste my time trying to debate this with you any 
more, but please take my word for it that I know how this works a little 
bit better than you, mmmkay?

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

I'm not the one who named a "link aggregation" mechanism trunk(4). Like I 
said, trunking is one of the most abused terms out there. Many people use 
it to mean vlan TAGGING (for example, Cisco), but a lot of people (like 
say those wonderful loveable guys at OpenBSD who decided to name a link 
aggregation mechanism trunk(4)!) (mis)use it to mean any number of other 
things including link aggregation. If you're going to talk about trunk(4), 
then use the verb "trunking", you shouldn't whine when people assume you 
are using trunking to mean a link aggregation channel.

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

Of course all links are active (as in, they're up, they're linked, they 
can receive traffic on any channel), but link aggregation implies nothing 
about how you balance your outgoing traffic onto those channels. If you 
have a load balancing algorithm that happens to put all of the data onto 
one channel as long as it is up and while leaving another channel unused, 
that is "failover". That is precisely what is happening under trunk(4) 
"failover" mode, you're just confused about it. Round robin is another 
valid load balancing mechanism, its just a particularly BAD one for tcp 
traffic.

The trunk(4) mechanism is NOTHING more than link aggregation, just with 
some particularly odd/bad load balancing mechanisms. In fact it even 
explicitly states that you can RECEIVE traffic across all of the channel 
members, this is because only the transmitting side has any control over 
how it will distribute the frames onto the individual channel members. One 
side could do "failover" mode, another side could do round robin mode, or 
if it was properly supported it could do one of the more common mechanisms 
like L2/L3/L4 hashing.

And for the record, the reason that this particular mode of "failover" is 
bad is that it relies on link detection as its only method for fault 
detection. If you've ever dealt with complex network setups, you know how 
easy it is for a L1/L2 device in the middle of a link-agg to malfunction 
and keep generating link incorrectly, or even for some idiot tech to come 
along and plug a fiber into the wrong port, so the channel member thinks 
it still has link but is sending packets into the void. This is why 
mechanisms like PagP/LACP exist, and if you can't use them, you should at 
least use L3 routing protocols or suffer the consequences later.

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

Most of your post is a mix of things that are completely incorrect, or 
snipits of things are are completely correct (lets call them "duh" 
factoids) that have no context or reason for being dropped. Clearly you're 
confused, but I've got better things to do with my time that try and 
convince you of it. Best of luck to you.

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