--XIiC+We3v3zHqZ6Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 07, 2005 at 05:29:41PM -0500, der Mouse wrote:
> >> through to LACP-based load-balancing like agr(4),
> > Please, does LACP (with agr or not) do also redundancy, or only
> > increase throughput?

Yes, it does, though it depends what kind of redundancy you're looking
for.  You'll certainly get nic/cable/port redundancy in an aggregate
between a switch and a host.  Getting switch redundancy requires
switches that support cross-chassis LACP in a stack, or other means.

> > That is, if two links are aggregated, and one fails, do all the
> > frames go through the other, or is one half of them lost?
>=20
> Everything I've seen indicates that the remaining link(s) pick(s) up
> the load.  Whether this depends on LACP or not I couldn't say.

It does, in the general case. LACP is the negotiation protocol by
which ports join and leave the aggregation group (changing the hash
buckets and redistributing traffic accordingly).

If you can find other (eg, manual) ways of triggering the
reconfiguration, that would work too within its own limitations: LACP
isn't involved for actual traffic flow (in the way that 802.1q vlan
encapsulation is for example).  But these manual ways won't work with
our agr(4) at present, because there are no manual knobs to twiddle.

> One of the most bothersome things about agr(4), to me, is that which
> link a packet goes out seems to depend on nothing but a hash of
> assorted data related to the packet.  This means that if links of
> different speeds are aggregated, the slower one(s) will get overloaded.

"So don't do that". =20

It also means that any one given (say) TCP stream can't use more than
one port's worth of bandwidth.

Neither of these is specific to agr(4).

> I'd expect it to simply pick the interface with the shortest output
> queue....

that would result in many out-of-order packets at the destination, which
will play various kinds of havoc with various upper layer protocols.

--
Dan.
--XIiC+We3v3zHqZ6Z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDl2lSEAVxvV4N66cRAuAwAKD3HjIRfwnGdmLtYRN4StZg5sMBgACg6DX3
t50qN/XJsWOIVHqcwazpU0w=
=+oXe
-----END PGP SIGNATURE-----

--XIiC+We3v3zHqZ6Z--