Community discussions

MikroTik App
 
toto4ds
just joined
Topic Author
Posts: 6
Joined: Fri Dec 03, 2021 10:39 pm

Bonding 802.3ad with HW-offloaded and hash policy

Sun Aug 21, 2022 10:38 am

Hello,
The documentation says:
With HW-offloaded bonding interfaces, the built-in switch chip will always use Layer2+Layer3+Layer4 for a transmit hash policy, changing the transmit hash policy manually will have no effect
On Linux, I can only select: layer2, layer2+3 or layer3+4.

What value of xmit_hash_policy should be set from the side of the bond in Linux?

Thanks
 
mkx
Forum Guru
Forum Guru
Posts: 8936
Joined: Thu Mar 03, 2016 10:23 pm

Re: Bonding 802.3ad with HW-offloaded and hash policy  [SOLVED]

Sun Aug 21, 2022 12:13 pm

I might be wrong, but AFAIK Tx hash policies don't have to be exactly the same on both sides. Receiver should gladly accept frames through any of bond members (when frames target bond's active MAC address), it's only Tx that matters to distribute traffic accross all active bond members.

When you think of it: in most cases L2 doesn't play a big role when looking from host's side, number of used MAC addresses will be low (in most cases single unless we're talking about VM hypervisor) and most of time there will be single L3 address per L2 address (also true for most VM deployments). Meaning most of time L3+L4 will have same effect as L2+L3+L4. The only exception in most deployments will be where traffic from gateway is in play where L2 address will be the one of gateway device while L3 will be one of many remote addresses (in which case using L2 as part of Tx hash makes even less of a difference). There are other border line exceptions, one is when ethernet frames carry L3 protocol other than IP/IPv6 (most of bonding drivers/devices implement only IP and IPv6 so L3/L4 information can't be used for those frames).
 
User avatar
ekarin
Trainer
Trainer
Posts: 24
Joined: Fri Jun 01, 2018 9:12 pm
Contact:

Re: Bonding 802.3ad with HW-offloaded and hash policy

Sun Nov 13, 2022 6:30 am

Hello,
The documentation says:
With HW-offloaded bonding interfaces, the built-in switch chip will always use Layer2+Layer3+Layer4 for a transmit hash policy, changing the transmit hash policy manually will have no effect
On Linux, I can only select: layer2, layer2+3 or layer3+4.

What value of xmit_hash_policy should be set from the side of the bond in Linux?

Thanks
For MikroTik devices that support bridge hardware offloading e.g. CRS3xx, the document means that any transmit-hash-policy value can be selected and have no effect because the switch chip does not take that value into account. The switch chip has predefined value i.e. layer 2+3+4 for the transmit-hash-policy.

For my testing, MikroTik devices that use CPU to process the bonding take a transmit-hash-policy that is specified manually via WinBox/WebFig. The testing result is that the 802.3ad mode provides traffic into only one bonding member regardless of layer 2, layer 2+3. Note that the layer 3+4 is not fully complatible for the 802.3ad mode by its standard. However MikroTik devices with switch chip supported balance outgoing traffic at all bonding members for the 802.3ad mode. It means that no matter what layer number is set, the switch chip has it own way to do the transmit-hash-policy but the MikroTik document shows the layer 2+3+4.
I still wonder the layer 2+3+4. How the transmit-hash-policy works? I tried to think about sources and destinations (MAC+IP+Port) but it seems that it should work only one bonding members instead of balancing all bonding members. Note that I used the Bandwidth Test tool to see the traffic flowing through the bonding member interfaces. My hardware is CRS326 (ethernet switch) and hap ac2 (router) with RouterOS 7.6rc3. Hopefully it helps.
 
mkx
Forum Guru
Forum Guru
Posts: 8936
Joined: Thu Mar 03, 2016 10:23 pm

Re: Bonding 802.3ad with HW-offloaded and hash policy

Sun Nov 13, 2022 10:26 am

As you observed, none of hashing policies will use more than one bond member for transmitting frames belonging to single L4 connection. The one notable exception is Round Robin. Which can cause its share of problems (similar to processing packets by firewall in multi-threaded manner) and is thus not part of standard 803.2ad Tx hashing policies suite.

Who is online

Users browsing this forum: No registered users and 30 guests