On Thursday, 01/22/2009 at 05:05 EST, "Harder, Pieter" <[email protected]> wrote: > You just lost me. LACP is on the trunk side of the VSWITCH. I am talking
> bonding on the port side of it. What exactly did you think of doing that was > solved by LACP? Talk about a confusing conversation! For those who left their scorecard at home today, LACP (Link Aggregation Control Protocol) support in the VSWITCH is directed only at the physical switch. The guest-facing side of the VSWITCH does not support LACP. (Let's avoid terms like "port side" and "trunk side". When a guest is using a virtual trunk, which side is the "trunk side"?) LACP is the thing that lets the host and switch coordinate traffic. The only use of LACP that I've seen/heard about so far is for better error toleration and recovery, better physical OSA management (dynamically delete from group so you can put on microcode fixes, then re-add), and to satisfy Management demand to "Stop wasting OSAs! Why aren't both LEDs flickering?!? I'm not paying for LEDs that don't flicker!" (FYI, IEEE 802.3ad spec lists 9 benefits of which increased bandwidth is only one.) While you can have multiple vNICs on an aggregating VSWITCH, there's nothing that will spray/deal queued frames across the vNICs since they each have a unique MAC address. But even if it did, you're doomed if the buffer fill rate is higher than the consumption rate. All you've done is delay slightly the point at which all guest buffers are full. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
