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 port 5001 connected with port 43697

[ ID] Interval Transfer Bandwidth

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

TCP Client Mode

$ iperf -c


Client connecting to, TCP port 5001

TCP window size: 22.9 KByte (default)


[ 3] local port 43697 connected with 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.

MindMajix Youtube Channel

UDP Server Mode
$ iperf -s -u


Server listening on UDP port 5001

Receiving 1470 byte datagrams

UDP buffer size: 160 KByte (default)


[ 3] local port 5001 connected
with 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


Client connecting to, UDP port 5001

Sending 1470 byte datagrams

UDP buffer size: 208 KByte (default)


[ 3] local port 55272 connected
with 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.

Are you looking to get trained on DevOps, we have the right course designed according to your needs. Our expert trainers help you gain the essential knowledge required for the latest industry needs. Join our DevOps Certification Training program from your nearest city.

DevOps Training Chennai, DevOps Training Dallas, DevOps Training BangaloreDevOps Training London, DevOps Training Mumbai, DevOps Training Chicago,  DevOps Training Gurgaon, DevOps Training Pune.

These courses are equipped with Live Instructor-Led Training, Industry Use cases, and hands-on live projects. Additionally, you get access to Free Mock Interviews, Job and Certification Assistance by Certified DevOps Trainers

Explore Devops Sample Resumes! Download & Edit, Get Noticed by Top Employers!Download Now!


Course Schedule
DevOps Training Jul 23 to Aug 07View Details
DevOps Training Jul 27 to Aug 11View Details
DevOps Training Jul 30 to Aug 14View Details
DevOps Training Aug 03 to Aug 18View Details
Last updated: 03 Apr 2023
About Author

Ravindra Savaram is a Technical Lead at His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.

read less
  1. Share:
DevOps Articles