Useful Iperf Commands for Network Troubleshooting

A network can be a weird place, with ever-changing asymmetric paths moving bits from one place to another. Sometimes this leads to very different throughput performance between servers that appear to be otherwise identical. After running a few common utilities like traceroute — or perhaps curl on an HTTP service — you are still unable to replicate the problem.

Enter iperf, the network testing tool. Iperf is designed to measure the throughput between two points and runs as a client/server pair. It supports both UDP and TCP and can either test bidirectionally or unidirectionally from each endpoint in a single command. The power of iperf is how efficiently it is able to saturate a network connection. For TCP, it reports the overall throughput. For UDP, you can adjust the datagram size and the report includes throughput, packet loss, and jitter.

Want to enhance your skills to become master in  DevOps Methodology, enroll in our DevOps Training

Installation is easy, as the package exists in most major Linux distributions and is supported for cross-platform compiling, and Windows binaries are available from third parties. To run iperf, you do need to have your firewall configured to allow connections between the two endpoints, with the default server port for TCP and UDP being 5001. You also need to have iperf running on both sides of the connection to test. Iperf can either run in Server or Client mode, one on each end of the connection, as in the following examples.

TCP Server Mode

$ iperf -s

———————————————————–

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

———————————————————–

[ 4] local 192.168.1.101 port 5001 connected with 192.168.1.100 port 43697

[ ID] Interval Transfer Bandwidth

[ 4] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec

TCP Client Mode

$ iperf -c 192.168.1.101

———————————————————–

Client connecting to 192.168.1.101, TCP port 5001

TCP window size: 22.9 KByte (default)

———————————————————–

[ 3] local 192.168.1.100 port 43697 connected with 192.168.1.101 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 114 MBytes 95.0 Mbits/sec

Performing an initial TCP test with iperf requires starting the server, then firing the client at it. In the above example, a Raspberry Pi is running as the server, with another system sending traffic to it. The end result is the complete throughput as measured from the client to the server.

Frequently asked Devops Interview Questions

You can optionally measure both directions, one at a time with the -r flag, or run both directions at the same time with the -d flag passed to the client. Which method to use depends on your expected workload, but in general you should get statistically similar results from the independent tests when each system is running on similar hardware.

$ iperf -s -u

———————————————————–

Server listening on UDP port 5001

Receiving 1470 byte datagrams

UDP buffer size: 160 KByte (default)

———————————————————–

[ 3] local 192.168.1.101 port 5001 connected
with 192.168.1.100 port 55272 Jitter Lost/Total
[ ID] Interval sec Transfer Bandwidth
[ 3] 0.0-10.0 114 MB 95.7 Mbps 0.158 ms 0/81482
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
UDP Client Mode

$ iperf -u -c 192.168.1.101

———————————————————–

Client connecting to 192.168.1.101, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 208 KByte (default)

———————————————————–

[ 3] local 192.168.1.100 port 55272 connected
with 192.168.1.101 port 5001
[ ID] Interval sec Transfer Bandwidth
[ 3] 0.0-10.0 114 MB 95.8 Mbps
[ 3] Sent 81483 datagrams
[ 3] Server Report: 114 MB 95.7 Mbps  0.158 ms 0/81482
[ 3] 0.0-10.0 sec
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

Since UDP is stateless, it has no idea how far it can push the network like TCP does. So iperf has some sane defaults for sending UDP traffic, and by default targets 1Mbps of throughput. The previous examples are worked around this, by specifying our target bandwidth of 100M using the -b flag.

Related Article - Network Troubleshooting

You may also notice that the UDP view on the client side also presents a Server Report. This is required since there are no guarantees with UDP — the client could happily send packets all day long to a server that was dropping them on the floor. Be mindful of this when comparing UDP results, as the client and server must agree to it.