Troubleshooting network related issues can be challenging at times. One great tool for on-the-spot testing of network bandwidth is Iperf. It’s a simple, yet powerful tool that can provide visibility on network performance metrics such as bandwidth, latency (delay), jitter, and packet loss. If you are not comfortable with the command prompt, the program is available in a GUI version called Jperf too.
Iperf measures network performance in terms of bandwidth, but its worth noting that the unit of measurement for file size and transfer rate are different. Files are typically stated in bytes, while transfer speeds are expressed in bits, so remember that!
When testing bandwidth performance with Iperf, what we’re actually testing is maximum TCP bandwidth at the transport layer (L4). Lots of applications use TCP as the transport protocol, include HTTP, SMTP, FTP, etc. Unlike UDP (another commonly used L4 protocol) TCP is a reliable, connection-oriented protocol with built-in mechanisms for connection established, acknowledgement, and termination. This connection management is why TCP is used (and not UDP) to test bandwidth. If UDP was being used, any lost packet(s) would go missing from the traffic flow and not be resent. Simply put, TCP has a means to detect and retransmit any lost segments. If your network is configured for QoS or CoS, you must make sure that the IPs or ports for these tests are configured for the highest priority QoS. Otherwise, your results will not be accurate.
The following examples use a combination of Microsoft Windows 7 (64-bit) and XP (32-bit). Also, the default TCP window size is used but keep in mind you can adjust window size and effect bandwidth results. To use the program, open the command prompt and navigate to the directory where Iperf.exe is located (Start>Run and type cmd, then press enter). Once in the command prompt you can change directories via the cd command. As you can see I am using Iperf version 1.7.0.
Before we get started I want to quickly discuss Iperf’s architecture. It uses a client/server model, where traffic is initiated from the client and traverses the network (LAN and/or WAN) to the server. So when testing bandwidth in both directions we’ll need to run the test twice, once in each direction. Also, by default the server will listen for the client on TCP port 5001 but like most options this can be changed. Note the ability to change TCP ports in Iperf opens avenues to use it for testing open TCP ports. Thus if a firewall or filtering device is blocking port(s) on a segment of your network you can use Iperf to verify this.
To get started we’ll setup the server side first, entering iperf -s -i 1. The -s command designates this workstation as the “server” and the -i 1 command sets the console output interval to one second.
A key point to remember when testing bandwidth with Iperf is that Iperf consumes all bandwidth available between client/server via TCP, regardless of LAN, WAN, or VPN connection. Thus if traversing a WAN link you can quickly saturate the link, potentially effecting user/application experience! Plan your testing accordingly!
Another example is a test performed over a internet VPN connection. As you might imagine, the bandwidth performance is slower which is due to factors such as encryption and Internet speed.
Lastly, the examples above use the basic options but keep in mind you can change or add numerous options to your testing. Below is the output of the help command to show you the various things you can change.
If your company does not have the time or resources to resolve its network issues, contact SD-WAN-Experts to have one of our engineers do the work for you.
You might also find these troubleshooting tips of interest;