In the IT world of troubleshooting, problems happen, and more often than not, the finger-pointing starts. “It is slow database performance.” “It is the network.” “Maybe it’s malware on the users’ machine.” “Probably a PEBKAC.” Unfortunately, this is usually the result of not understanding how to effectively troubleshoot parts of the environment that aren’t the most familiar. Hopefully, this blog will provide one more tool for your tool belt.
Iperf3 is a network bandwidth and quality tool that can test point to point connectivity between computers. You can download it here.
Iperf3 is based on a few older versions of iperf that accomplish the same goal; however, this version is the only version that has continued development. It is principally developed by ESnet and Lawrence Berkeley National Laboratory.* The following are some of its features.
- Iperf3 is a command-line tool with only two files, iperf3.exe and cygwin1.dll. It is a portable tool, and therefore does not need to be installed, which makes it convenient to use.
- Launching the tool from a Command Prompt or PowerShell window does not require elevated administrator access.
- The tool is a standard command-line tool that accepts parameters and will take the -help parameter to show all available parameters that it will take.
- This tool is meant to be used in a client/server-based setup. That is, the tool must be running on at least two devices at the same time. The two devices are for you to decide.
Let us run through a couple of use cases.
Validate Upload Speed Through Network with iperf3
Are you trying to troubleshoot upload speed during a migration from an on-premise Exchange server to Office 365, and things seem slow? Is it the network? Is it throttling on the Exchange server or on Microsoft’s side? Let’s rule out the internet connection bandwidth first. In this scenario, the client would be the Exchange server, and the computer is acting as the server would be some other computer not in the same network. You could set up your second device and set up a firewall rule to allow traffic to the computer for testing if you wanted to. If you don’t have that available, there are publicly available servers that are listening. This page has a listing of available public servers that can be used as a target for the server: https://iperf.fr/iperf-servers.php.
To start, from the Exchange server, first download iperf, and then run it against one of the public servers: iperf3.exe -c iperf.he.net.
This will assume a lot of default parameters, including using a TCP (instead of UDP) connection and using the default port (5201) instead of any port that could be specified. In our example, we are showing an average 11.5 Mbit per second upload speed average. I know that my ISP is a 100Mbit/10Mbit connection, so that matches up. If I were to have significantly less than a 10Mbit upload shown here, I would know I to take a look at my network for troubleshooting internet connection speed from that machine. I would then perform the same test from another server, and if it was persisting in being slower than expected, I would troubleshoot the network on a broader level. If only the Exchange server was being slow, I would look specifically at the Exchange server for troubleshooting. Perhaps duplex is set to 100Mb instead of auto-negotiating to 1Gb. Perhaps the server is using the incorrect route and using the wrong ISP to go out. If nothing here shows as an issue, I would suggest starting to look at the other possibly throttling that may be happening on either side of the connection.
Troubleshooting Slow Wireless issues with iperf3
In this scenario, a user with a laptop on your wireless network is complaining that local applications are lagging and slow to respond. If you have client/server applications where a significant amount of data is traversing the network through wireless, one of the first steps to troubleshoot would be to see what the functional speed from the user’s computer is to the server and visa versa. To do this, you would have iperf on both the user’s computer and the server it is talking to.
From the application server (ex. AppServer1), start listening: iperf3.exe -s.
From the user’s machine: iperf3.exe -c AppServer1.
Note: If you get an error connecting the client to the server, you may need to open TCP port 5201 on the computer functioning as the server.
This will return the results of network bandwidth from the user’s machine to the AppServer1 computer.
We can also run the test in the reverse direction from the client by adding the -R parameter. This will instead run in reverse mode, uploading data from the AppServer1 computer to the client machine.
Using the normal method and the -R reverse parameter will allow for testing both egress and ingress traffic to the laptop over the wireless connection.
We average 152-164 Mbits per second over the wireless connection. For comparison, we should also run this test from a workstation connected to a wired connection to use as a baseline.
If the results are less than you would expect them to be, perhaps try again when the user’s computer is closer to a wireless access point or move to a location where a brick wall isn’t between the laptop and the access point. If speeds improve, that would indicate perhaps additional access point(s) would need to be mapped out in the building for ideal wireless connectivity for users. It also might be worth it to wire a network drop to this user to get gigabit speeds via a wired connection.
Have any questions on how to troubleshoot speed issues with iperf3? Please contact us at any time!
*Sikich is not affiliated nor sponsored by any entities referenced in this blog. Sikich does not warrant and is not liable for usage of any third-party tools.
