Zyxel XS1930-10 - LACP to linux bond aggragate in only one direction.

michael2494

Hi

I try to enable a lacp link between the XS1930-10 and a linux lacp bond.
The lacp aggregate bandwitch only on upload.


I configure like that:

Linux lacp 3+4 port ens17 et ens16
XS1930 port 7 and 8 with enable lacp and algo src-dest-ip ( vlan 10 and 20 tagged)
All ports are synchronise.

In one side i have a server with vlan 10 and 20 over lacp bond0 and one iperf client link to each vlan ip

In other side of the switch one proxmox server with 2 VM on the vlan of openvswitch bridge

If i start two download, the first from ip192.168.0.1 and second from 192.168.1.1 to 192.168.0.2 and 192.168.1.2, the lacp use only one link and share 1gb bandwitch,
The downloads is not balanced.

Concurrents Iperf3:

iperf3 -c 192.168.0.2 -P 16 --time 60 -R Results : 411 Mbits/s

iperf3 -c 192.168.1.2 -P 16 --time 60 -R Results: 477Mbits/s

- interface ens17: RX: 981MB TX: 2.55Mb
- Interface ens16: RX: 3,38Kb TX: 3,70Mb


If i start two upload, the first from ip192.168.0.1 and second from 192.168.1.1 to 192.168.0.2 and 192.168.1.2, the lacp use two links and share 2gb bandwitch
The upload is balanced

iperf3 -c 192.168.0.2 -P 16 --time 60 Results: 933 Mbits/sec

iperf3 -c 192.168.1.2 -P 16 --time 60 Results: 943 Mbits/s

- interface ens17: RX: 41,80MB TX: 981,58Mb
- Interface ens16: RX: 3,38Kb TX: 981.87Mb


I tried all hash algorhytme on switch and linux, and i had the same results.
I tried witch an Asus router TUF-AX6000, and i got the reverse results, download was balanced the the upload used only one link.

Lacp config on linux seems to be good:


Ethernet Channel Bonding Driver: v6.2.0-37-generic

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

Slave Interface: ens16f4
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: b4:2e:99:89:79:2e
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: 22:43:b1:22:01:3d
port key: 9
port priority: 255
port number: 1
port state: 61
details partner lacp pdu:
system priority: 65535
system mac address: f4:4d:5c:67:16:f2
oper key: 1
port priority: 1
port number: 7
port state: 63

Slave Interface: ens17
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: b4:2e:99:89:79:2f
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: 22:43:b1:22:01:3d
port key: 9
port priority: 255
port number: 2
port state: 61
details partner lacp pdu:
system priority: 65535
system mac address: f4:4d:5c:67:16:f2
oper key: 1
port priority: 1
port number: 8
port state: 63

And on the switch:

If someone could help me

Best regards

Zyxel_Kay

Hi @michael2494

Yes, if the criteria is src-dst-ip/src-ip/dst-ip, the switch is indeed capable of reading the IP information inside the packet. However, it's important to note that different chipsets may employ various elements such as IP, VLAN, MAC, or port for the hashing process.

In terms of hash algorithm behavior, it's common to notice variations in link aggregation criteria, and this is often tied to the chipset design. Feel free to select the algorithm that aligns best with your specific setup.

Zyxel_Kay

Hi @michael2494

It seems that there might be some missing information in your post, especially regarding the test results. To better assist you, could you please share them again?

PeterUK

Its the hash type I think if you change 192.168.0.1 to 192.168.0.4 it might balance the load

I don't see why no one does a least loaded hash type? Best I have seem is Src/Dest IP and TCP/UDP Port fields

Zyxel_Kay

Hi @michael2494

To gain a deeper understanding of your concern, we replicated a similar setup in our office (without VLAN configuration) and obtained distinct results. In our scenario, neither the download nor the upload utilized the two links for transmission.

We would like to suggest a slight modification to your setup for further testing. Could you please replace the Proxmox server with two physical PCs and observe if the results remain the same?

Here's the topology of our setup:

Results:

• upload
  • iperf3 192.168.1.100 -t 600 , Results: 951Mbits/sec
  • iperf3 192.168.1.222 -t 600 , Results: 949Mbits/sec
• download
  • iperf3 192.168.1.100 -t 600 -R , Results: 942Mbits/sec
  • iperf3 192.168.1.200 -t 600 -R , Results: 942Mbits/sec

Switch 2:

• LACP: Port 9-10, Criteria: src-dst-mac

Linux Server:

• Bonding Mode: IEEE 802.3ad Dynamic link aggregation
  Transmit Hash Policy: layer3+4 (1)
  MII Status: up
  MII Polling Interval (ms): 1
  Up Delay (ms): 0
  Down Delay (ms): 0
  Peer Notification Delay (ms): 0
• 802.3ad info
  LACP active: on
  LACP rate: slow
  Min links: 0
  Aggregator selection policy (ad_select): stable
  System priority: 65535
  System MAC address: fe:b4:55:xx:xx:xx
  Active Aggregator Info:
  Aggregator ID: 1
  Number of ports: 2
  Actor Key: 9
  Partner Key: 1
  Partner Mac Address: 5b:8b:f3:xx:xx:xx

michael2494

Hi,

Without Vlan, it's seem to work.

I found a way to do it working with vlan

If a set the trunk option enable on the ports where proxmox and iperfs client are connected.
( i see it on a post for another zyxel switch model).

Maybe some lacp related traffics cant be echanged, without truck mode, if vlan is enabled for port.

Another strange behavor is, the packets received from switch are balanced if i choose mac algorithm, but not with src-dest-ip while, the src_ip and dest_ip are all differents.
I have not this issue with packets that are send to the switch by the linux machine as the hash are calculated by the sender.

Does the switch is able to read the ip inside vlan ?

Best Regards

Zyxel_Kay

Hi @michael2494

Yes, if the criteria is src-dst-ip/src-ip/dst-ip, the switch is indeed capable of reading the IP information inside the packet. However, it's important to note that different chipsets may employ various elements such as IP, VLAN, MAC, or port for the hashing process.

In terms of hash algorithm behavior, it's common to notice variations in link aggregation criteria, and this is often tied to the chipset design. Feel free to select the algorithm that aligns best with your specific setup.