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 <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
