Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
From: Nicolas de Pesloüan <hidden>
Date: 2011-01-18 16:24:57
Le 18/01/2011 16:28, Oleg V. Ukhno a écrit :
On 01/18/2011 05:54 PM, Nicolas de Pesloüan wrote:quoted
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.
quoted
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.
quoted
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.