--netperf-data-port option/functionality?

[jsommerville-untangle]

Similar to the --netperf-control-port parameter, it would be nice if we could specify --netperf-data-port during runtime also. This would change the data-port that the netperf tests are being passed through to, IE:

root@99be1c32d2fa:/home# netperf -H 10.11.12.195 -p 12865 -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.11.12.195 () port 0 AF_INET : demo
netperf: send_omni: connect_data_socket failed: Connection refused

root@99be1c32d2fa:/home# netperf -H 10.11.12.195 -p 12865 -t TCP_STREAM -- -P 12866
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 12866 AF_INET to 10.11.12.195 () port 12866 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

131072  16384  16384    10.05     281.20

Only some netperf tests support this, but I don't think the tests that don't support it fail when -P is passed in on them. I'll see if I can put something together, but could be useful for those who are testing netperf between firewalls and don't want to open 30000-40000 (or whatever netserver chooses for the data port during specific tests)

[tohojo]

John Sommerville notifications@github.com writes:

Similar to the --netperf-control-port parameter, it would be nice if we could specify --netperf-data-port during runtime also. This would change the data-port that the netperf tests are being passed through to, IE:

root@99be1c32d2fa:/home# netperf -H 10.11.12.195 -p 12865 -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.11.12.195 () port 0 AF_INET : demo
netperf: send_omni: connect_data_socket failed: Connection refused

root@99be1c32d2fa:/home# netperf -H 10.11.12.195 -p 12865 -t TCP_STREAM -- -P 12866
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 12866 AF_INET to 10.11.12.195 () port 12866 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

131072  16384  16384    10.05     281.20

Only some netperf tests support this, but I don't think the tests that don't support it fail when -P is passed in on them. I'll see if I can put something together, but could be useful for those who are testing netperf between firewalls and don't want to open 30000-40000 (or whatever netserver chooses for the data port during specific tests)

You're right that netperf does have an option to pick a particular port, but the problem is that this option can only be supplied to the client. There is no way to tell netserver to stay within a particular range. And so if we were to support this in Flent, it would require that (a) Flent keeps track of how many ports it needs for each test, and (b) if used, it will prevent multiple Flent tests to run against the same server at the same time.

Also, the failure mode is really ugly (netperf can request a port, but if that is not available, it will just silently use a different one).

So it's kind of a deliberate omission that this is not supported in Flent, unfortunately :(

A workaround is to use iptables to conditionally open the data port range when you see a control port connection. I use something like:

-A INPUT -p tcp --dport 12865 -m conntrack --ctstate NEW -j SET --add-set netperf src -A INPUT -p tcp --dport 12865 -m conntrack --ctstate NEW -j ACCEPT -A INPUT -m set --match-set netperf src -p udp --dport 32768:61000 -j ACCEPT -A INPUT -m set --match-set netperf src -p tcp --dport 32768:61000 -j ACCEPT

[jsommerville-untangle]

@tohojo Yeah I agree that netperf could use some modifications server side to make something like this work properly (ie: feeding a list of data ports server side to use when opening the data connection netserver --data-port=12866,12867,12868) but unfortunately it looks as though the netperf repository is not actively maintained (https://github.com/hewlettpackard/netperf)

I originally discovered this problem while trying to attach to a docker container running netserver, from another remote container running flent. I wanted to avoid opening all host ports to the docker container, so monitoring docker logs to determine the iptables port forwards for the host seems like it would be the only answer. I'm looking to automate running these test suites, so parsing docker logs to expose ports doesn't seem valid.

Currently my work around is to run the netperf container with host networking (network_mode: "host" for the server), I think this is the only way that won't require a hacky intervention (parsing docker logs on the host to figure out what port netserver is listening on...).

Thanks for the reply!

[Avidanborisov]

Although a bit buried in the documentation (I found it out by going through the sources), netperf does have a way to specify local/remote data port bindings with -- -P local_port,remote_port, e.g.

netperf -H IP -p 10000 -t TCP_STREAM -- -P 10001,10002

will connect to a netserver listening on command port 10000, will bind the local netperf data port to 10001, and the remote netserver data port to 10002.