-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Iperf3 does not work if the server is load-balanced #823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This isn't a part of iperf3's design. If this test scenario is really necessary, you might be better served by some other bandwidth measurement tool(s). |
I'd like to mention that iperf2 only opens one connection and therefore works in the described situation. |
iperf2 was a great tip! |
Had the same use case, iperf2 did not work for me. |
Cool that you use it 😃 But be aware that iperfX and ctraffic target different test-cases:
Ctraffic test more how load-balanced traffic is affected by various disturbancies, for instance a reconfiguration or rolling upgrade. |
Context
Version of iperf3:
commit a681713
Hardware:
Kvm vm
Operating system (and distribution, if any):
Linux 4.19.3
Other relevant information (for example, non-default compilers,
libraries, cross-compiling, etc.):
Built on Ubuntu 18.04
Bug Report
It should be possible to setup a number of
iperf3
servers behind a load-balancer and use the client with-P
option to measure bandwith to multiple servers.This is not an uncommon measurement case and support it would enhance the usability of
iperf3
IMHO. My intention was to measure bandwith towards a "service" in Kubernetes which will load-balance traffic to a number of "pods".When
iperf3
is used towards a load-balanced server the client most often hangs forever.From
tcpdump
traces it looks like theiperf3
client actually setup 2 tcp connections, I guess some control/data channel(?). These will be load-balanced to different servers and I think that causes the problem. It works occationally, probably when the 2 tcp connects happen to hit the same server.Simplest lb may be ecmp or multipath routing. I tested this with xcluster
Otherwise any LB solution may be used to see the problem.
If possible, re-use the TCP connection rather than setup a new one.
This will not be sufficient for UDP tests where a
-u
option on the server side whould be the only clean solution I think. You may not want that, so I suggest that UDP is left as-is, TCP is the most important test case.The text was updated successfully, but these errors were encountered: