[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2905.1391759849@death.nxdomain>
Date: Thu, 06 Feb 2014 23:57:29 -0800
From: Jay Vosburgh <fubar@...ibm.com>
To: Thomas Glanzmann <thomas@...nzmann.de>
cc: Linux Network Development <netdev@...r.kernel.org>
Subject: Re: Cascading Bond devices
Thomas Glanzmann <thomas@...nzmann.de> wrote:
>I wonder if it is possible to cascade bond devices. I have currently a
>box with four network cards. Two are going to switch a and two are going
>to switchb. And what I would like to do is the following:
>
>switch-01 port 1 - eth0 \
>switch-01 port 2 - eth1 - bond0 (802.3ad Layer 2 hash) \
>switch-02 port 1 - eth2 - bond1 (802.3ad Layer 2 hash) - bond2 (active-passive)
>switch-02 port 2 - eth3 /
For this specific case, it is unnecessary to nest the bonds, as
one feature of 802.3ad is that it will group the ports correctly into
multiple aggregators, and fail over from one to the other under certain
circumstances selected by the ad_select parameter. It is not possible
to select different hash algorithms on a per-aggregator basis, though.
>If it is possible, how would I configure such a scenario? bond0 and
>bond1 is easy and in fact I already have them. But I don't get howto to
>use adifferent hashing algorithm for bond2.
Generally speaking, nesting of bonds does not function
correctly. It is possible to configure, but various parts do not
function as expected from the nesting (when last I checked, transmit
generally functioned, but receive generally did not).
>I also wanted to use tlb/alb in the past but experienced broadcast
>storms when using IPv6 on such devices. Also I was not able to set an
>IPv6 address because of duplicated address detection told me that it was
>already online on the subnet which it was not. This was with kernel 3.12
>and 3.13.
With a nesting, or just in general? I have not tested alb/tlb
modes much with IPv6, but the remote peer load balancing scheme for alb
mode in particular is only implemented for IPv4. I do recall that both
of them should balance outgoing traffic for IPv6.
As far as storms go, normally for tlb/alb, one slave is the
"active" slave, and for both alb and tlb should be the only slave that
receives broadcasts or multicasts. For tlb mode, the active slave is
the only slave that receives anything at all, the others are
transmit-only. For alb mode, the other slaves receive unicast traffic
from network peers according to the balance algorithm issuing special
ARP frames to those peers to direct their traffic (this is the IPv4-only
part).
I have not tested tlb/alb with very recent kernels, so it's
possible that something has been broken in some of the substantial
changes over the last few months.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
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