Zyxel XS1930-10 - LACP to linux bond aggragate in only one direction.
![michael2494](https://us.v-cdn.net/6029482/uploads/avatarstock/n5VP8WBH3IZR4.png)
![First Comment](https://us.v-cdn.net/6029482/uploads/badges/MBNFIRD87YVH.png)
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
Accepted Solution
-
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.
Kay
Don't miss this great chance to upgrade your Nebula org. for free! https://bit.ly/4g2pS9L
0
All Replies
-
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?
Kay
Don't miss this great chance to upgrade your Nebula org. for free! https://bit.ly/4g2pS9L
0 -
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
0 -
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
Kay
Don't miss this great chance to upgrade your Nebula org. for free! https://bit.ly/4g2pS9L
0 - upload
-
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 Regards0 -
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.
Kay
Don't miss this great chance to upgrade your Nebula org. for free! https://bit.ly/4g2pS9L
0
Categories
- All Categories
- 414 Beta Program
- 2.2K Nebula
- 130 Nebula Ideas
- 88 Nebula Status and Incidents
- 5.4K Security
- 166 USG FLEX H Series
- 255 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 999 Wireless
- 36 Wireless Ideas
- 6.2K Consumer Product
- 233 Service & License
- 370 News and Release
- 77 Security Advisories
- 24 Education Center
- 5 [Campaign] Zyxel Network Detective
- 2.9K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 80 About Community
- 69 Security Highlight