[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E427499.8060108@cyconix.com>
Date: Wed, 10 Aug 2011 13:07:53 +0100
From: Tom Brown <sa212+glibc@...onix.com>
To: netdev <netdev@...r.kernel.org>
Subject: Use of 802.3ad bonding for increasing link throughput
[couldn't thread with '802.3ad bonding brain damaged', as I've just
signed up]
So, under what circumstances would a user actually use 802.3ad mode to
"increase" link throughput, rather than just for redundancy? Are there
any circumstances in which a single file, for example, could be
transferred at multiple-NIC speed? The 3 hashing options are:
- layer 2: presumably this always puts traffic on the same NIC, even in
a LAG with multiple NICs? Should layer 2 ever be used?
- layer2+3: can't be used for a single file, since it still hashes to
the same NIC, and can't be used for load-balancing, since different IP
endpoints go unintelligently to different NICs
- layer3+4: seems to have exactly the same issue as layer2+3, as well as
being non-compliant
I guess my problem is in understanding whether the 802.3/802.1AX spec
has any use at all beyond redundancy. Given the requirement to maintain
frame order at the distributor, I can't immediately see how having a
bonded group of, say, 3 NICs is any better than having 3 separate NICs.
Have I missed something obvious?
And, having said that, the redundancy features seem limited. For hot
standby, when the main link fails, you have to wait for both ends to
timeout, and re-negotiate via LACP, and hopefully pick up the same
lower-priority NIC, and then rely on a higher layer to request
retransmission of the missing frame. Do any of you have any experience
of using 802.1AX for anything useful and non-trivial?
So, to get multiple-NIC speed, are we stuck with balance-rr? But
presumably this only works if the other end of the link is also running
the bonding driver?
Thanks -
Tom
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists