From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: "Oleg V. Ukhno" <olegu@yandex-team.ru>
Cc: "John Fastabend" <john.r.fastabend@intel.com>,
"Jay Vosburgh" <fubar@us.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Sébastien Barré" <sebastien.barre@uclouvain.be>,
"Christophe Paasch" <christoph.paasch@uclouvain.be>
Subject: Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
Date: Tue, 18 Jan 2011 17:24:53 +0100 [thread overview]
Message-ID: <4D35BED5.7040301@gmail.com> (raw)
In-Reply-To: <4D35B1B0.2090905@yandex-team.ru>
Le 18/01/2011 16:28, Oleg V. Ukhno a écrit :
> On 01/18/2011 05:54 PM, Nicolas de Pesloüan wrote:
>> I remember a topology (described by Jay, for as far as I remember),
>> where two hosts were connected through two distinct VLANs. In such
>> topology:
>> - it is possible to detect path failure using arp monitoring instead of
>> miimon.
>> - changing the destination MAC address of egress packets are not
>> necessary, because egress path selection force ingress path selection
>> due to the VLAN.
>
> In case with two VLANs - yes, this shouldn't be necessary(but needs to
> be tested, I am not sure), but within one - it is essential for correct
> rx load striping.
Changing the destination MAC address is definitely not required if you segregate each path in a
distinct VLAN.
+-------------------+ +-------------------+
+-------|switch 1 - vlan 100|-----|switch 2 - vlan 100|-------+
| +-------------------+ +-------------------+ |
+------+ | | +------+
|host A| | | |host B|
+------+ | | +------+
| +-------------------+ +-------------------+ |
+-------|switch 3 - vlan 200|-----|switch 4 - vlan 200|-------+
+-------------------+ +-------------------+
Even in the present of ISL between some switches, packet sent through host A interface connected to
vlan 100 will only enter host B using the interface connected to vlan 100. So every slaves of the
bonding interface can use the same MAC address.
Of course, changing the destination address would be required in order to achieve ingress load
balancing on a *single* LAN. But, as Jay noted at the beginning of this thread, this would violate
802.3ad.
>> I think the only point is whether we need a new xmit_hash_policy for
>> mode=802.3ad or whether mode=balance-rr could be enough.
> May by, but it seems to me fair enough not to restrict this feature only
> to non-LACP aggregate links; dynamic aggregation may be useful(it helps
> to avoid switch misconfiguration(misconfigured slaves on switch side)
> sometimes without loss of service).
You are right, but such LAN setup need to be carefully designed and built. I'm not sure that an
automatic channel aggregation system is the right way to do it. Hence the reason why I suggest to
use balance-rr with VLANs.
>> Oleg, would you mind trying the above "two VLAN" topology" with
>> mode=balance-rr and report any results ? For high-availability purpose,
>> it's obviously necessary to setup those VLAN on distinct switches.
> I'll do it, but it will take some time to setup test environment,
> several days may be.
Thanks. For testing purpose, it is enough to setup those VLAN on a single switch if it is easier for
you to do.
> You mean following topology:
See above.
> (i'm sure it will work as desired if each host is connected to each
> switch with only one slave link, if there are more slaves in each switch
> - unsure)?
If you want to use more than 2 slaves per host, then you need more than 2 VLAN. You also need to
have the exact same number of slaves on all hosts, as egress path selection cause ingress path
selection at the other side.
+-------------------+ +-------------------+
+-------|switch 1 - vlan 100|-----|switch 2 - vlan 100|-------+
| +-------------------+ +-------------------+ |
+------+ | | +------+
|host A| | | |host B|
+------+ | | +------+
| | +-------------------+ +-------------------+ | |
| +-------|switch 3 - vlan 200|-----|switch 4 - vlan 200|-------+ |
| +-------------------+ +-------------------+ |
| | | |
| | | |
| +-------------------+ +-------------------+ |
+---------|switch 5 - vlan 300|-----|switch 6 - vlan 300|---------+
+-------------------+ +-------------------+
Of course, you can add others host to vlan 100, 200 and 300, with the exact same configuration at
host A or host B.
Nicolas.
next prev parent reply other threads:[~2011-01-18 16:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 19:07 [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing Oleg V. Ukhno
2011-01-14 20:10 ` John Fastabend
2011-01-14 23:12 ` Oleg V. Ukhno
2011-01-14 20:13 ` Jay Vosburgh
2011-01-14 22:51 ` Oleg V. Ukhno
2011-01-15 0:05 ` Jay Vosburgh
2011-01-15 12:11 ` Oleg V. Ukhno
2011-01-18 3:16 ` John Fastabend
2011-01-18 12:40 ` Oleg V. Ukhno
2011-01-18 14:54 ` Nicolas de Pesloüan
2011-01-18 15:28 ` Oleg V. Ukhno
2011-01-18 16:24 ` Nicolas de Pesloüan [this message]
2011-01-18 16:57 ` Oleg V. Ukhno
2011-01-18 20:24 ` Jay Vosburgh
2011-01-18 21:20 ` Nicolas de Pesloüan
2011-01-19 1:45 ` Jay Vosburgh
2011-01-18 22:22 ` Oleg V. Ukhno
2011-01-19 16:13 ` Oleg V. Ukhno
2011-01-19 20:12 ` Nicolas de Pesloüan
2011-01-21 13:55 ` Oleg V. Ukhno
2011-01-22 12:48 ` Nicolas de Pesloüan
2011-01-24 19:32 ` Oleg V. Ukhno
2011-01-29 2:28 ` Jay Vosburgh
2011-02-01 16:25 ` Oleg V. Ukhno
2011-02-02 17:30 ` Jay Vosburgh
2011-02-02 9:54 ` Nicolas de Pesloüan
2011-02-02 17:57 ` Jay Vosburgh
2011-02-03 14:54 ` Oleg V. Ukhno
2011-01-18 17:56 ` Kirill Smelkov
2011-01-18 16:41 ` John Fastabend
2011-01-18 17:21 ` Oleg V. Ukhno
2011-01-14 20:41 ` Nicolas de Pesloüan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D35BED5.7040301@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=christoph.paasch@uclouvain.be \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=olegu@yandex-team.ru \
--cc=sebastien.barre@uclouvain.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).