Good day, everyone!

From my last blog entry, I discussed virtual network interface speeds versus reality.  This blog can be read here.

A great question was posed: “How do you test networking speeds?”

This is a great question as – by itself – it is simple enough to answer.  However, depending on what one desires out of “network testing” the answer can be as complex as anyone would like to make it!

Ergo this is why I have decided to answer this question via our community blogs using a long standing, free utility called IPERF (well, IPERF2).  It is a powerful utility I have used over many, many years.  Links to IPERF will be provided along with documentation on its use later, but a few perks of it are:

– Can be used to test bandwidth

– Helps in determining bottlenecks

– Assists with black box testing or the  “what happens if” scenarios

– Runs on either Linux-based systems or Windows-based systems

– And more…

In its most basic use, IPERF has to be installed at two separate end points.  One point acts a server/receiver and the other instance acts as a client/transmitter.  This is done so network testing can be done on a simple subnet to a complex, routed network from end-to-end using TCP or UDP generated traffic.

Here is a quick, visual example:

The visual shows an IPERF client transmitting data over IPv4 to an IPERF receiver.  With networking,  wireless, routers, switches, or even firewalls can be traversed as IPERF, by default, uses port 5001 on the client and server side to transmit data.

How does this apply to XenServer and Virtual Machines?

The key to network testing is to remember that any device that is connected to your network infrastructure via TCP/IP  – Virtual or Physical – is a target, an end point, and basically… a networked device.

With regards to virtual machines, XenServer obviously supports Windows and Linux operating systems.  IPERF can be used to test virtual-to-virtual networking as well as virtual-to-physical networking.  If we stack virtual machines in a box to our left and stack physical machines in a box to our right – despite a common subnet or routed network – we can quickly see the permutations of how Virtual and Physical network testing can be achieved with IPERF:

Cut to the chase: How can I start using IPERF?

Excellent question.

This blog will focus on using plain-old IPERF2 within a Windows 7 VM (client) and a CentOS 5.10 VM (receiver).

BUT, just as an FYI, the latest version of IPERF, or IPERF3 can be found at or, more specifically,  Feel free to explore this version.

The reason for using IPERF2 is quite simple: portability and compatibility on two of the most popular operating systems that I know are virtualized.  In addition, the same steps to installing IPERF2 on these hosts can be carried out on physical systems running similar operating systems, as well.


Just as a heads up to all my readers, the remainder of this blog regarding IPERF2 will require use of the MS/DOS command line as well as the Linux shell (of choice).  I will carefully explain all commands as so if you are a “strictly GUI” person, you should fit right in.

When utilizing IPERF2 keep in mind that this is a traffic generator.  While one can control the quantity and duration of traffic, it is still network traffic!  So, consider testing during non-peak hours or after hours!

IPERF2 for Windows

The Windows port of IPERF 2.0.5 requires Windows XP (or greater) and can be downloaded from:

Within the .zip file you will find two directories.  One is labeled DEBUG and the other is labeled RELEASE.  Export the Iperf.exe program to a directory you will remember, such as C:\iperf\

Now, accessing the command line (cmd.exe), navigate to C:\iperf\ and execute: iperf

You should see the following output:

The Iperf.exe binary works and we are now ready to move on to our CentOS VM to test IPERF2!

IPERF2 for Linux

If you have additional repos already configured for CentOS, you can simply execute (as root):

yum install iperf

If that fails, you will need to download the Fedora/RedHat EPEL-Release RPM file for your version of CentOS.  To do this (as root), execute:


rpm -Uvh epel-release-5-4.noarch.rpm

*** Note that the above EPEL-Release RPM file is just an example (a working one) ***

Once epel-release-5-4.noarch.rpm is installed, execute:

yum install iperf

And once complete, as root execute iperf and you should see the following output:

Notice that it is the same output as what is being displayed from Windows.  IPERF2 is expecting a -s (server) or -c (client) command along with options… which we shall get into now!

Command Line Options

On either Windows or Linux, a complete list of options for IPERF2 can be listed by executing:

iperf –help

A few good resources of examples to use IPERF2 options for the server or client can be referenced at:

For now, we will focus on the options needed for our server and client:

-f, –format    [kmKM]   format to report: Kbits, Mbits, KBytes, MBytes

-m, –print_mss          print TCP maximum segment size (MTU – TCP/IP header)

-i, –interval  #        seconds between periodic bandwidth reports

-s, –server             run in server mode

-c, –client    <host>   run in client mode, connecting to <host>

-t, –time      #        time in seconds to transmit for (default 10 secs)

Lastly, there is a TCP/IP Window setting.  This goes beyond the scope of this document as it relates to the TCP frame/windowing of data.  I highly recommend reading either of the two following links – especially for Linux – as there has always been some debate as what is “best to be used”:

Running your first IPERF2 test!

So, we have IPERF2 installed on Windows 7 and on CentOS 5.10.  Before you test, ensure any AV does not block iperf.exe from running as well as port 5001 being opened across your network.  Again, another port can be specified, but the default port IPERF2 uses for both client and server is 5001.

Let’s setup the server/receiver side on our CentOS 5.10 box.

Following the commands above, we want to execute the following to run IPERF2 as a server/receiver from our Windows 7 client machine:

iperf -s -f M -m -i 10

The output should show:
Server listening on TCP port 5001
TCP window size: 0.08 MByte (default)

The TCP window size has been previously commented on and the server is now ready to accept connections (press Control+C or Control+Z to exit).

Let us now focus on the client side to start sending data from our Windows 7 VM to our CentOS VM.

From Windows 7, the command line to start transmitting data for 30 seconds to our CentOS host (x.x.x.48) is:

iperf -c x.x.x.48 -t 30 -f M

Pressing enter, the traffic flow begins and the output from the client side looks like this:

From the server side, the output looks something like this:

And there we have it – a first successful test from a Windows 7 VM (located on one XenServer) to a CentOS 5.10 VM (located on XenServer).

So, what are the results?

From either the client side or server side, results are shown by time and average.  The key item to look for from either side is:

0.0-30.0 sec  55828 MBytes  1861 MBytes/sec

Why?  This shows the average over the course of 0.0 to 30.0 seconds in terms of total megabytes transmitted as well as average megabytes of data sent per second.

Also, since we passed -f M as an option, the output is calculated in megabytes accordingly.

In this particular case, we simply illustrated that from one VM to another VM, we transferred data at 1861 megabytes per second.

*** Note that this test was performed in a local lab with lower-end hardware than what you probably have! ***

Challenge for you…

Reverse the roles!

From Windows 7 start IPERF2 as the server and from CentOS 5.10 run IPERF2 as the client!

What else can I get out of IPERF2 for testing a XenServer deployment?

Great question!

Real world scenarios include testing VLANs, BONDs, and more.

By leveraging the IPERF2 client side option of -t, one can extend the testing (by seconds) as so VLAN end-to-end communication is verified between hosts.  An example would be:

iperf -c x.x.x.48 -t 3600 -f M

The following command will generate traffic for an hour as so VLAN troubleshooting can be done.  This also applies to BONDs as so one can take down an interface to ensure traffic still flows correctly.

Where WAN speed (internal to external transmission measurements) are concerned, one can point a client to an external IPERF2 server that has been established: measuring the speeds with which traffic (TCP, UDP) is sent, acknowledged, and measured.  This information can be passed to IT administrators where degradation of WAN speeds is suspsect.

Lastly, the client can perform bi-directional testing.  By passing in the -d option, the client will also receive data back from the server.

To wrap things up, well, I recommend IPERF2 for Windows or Linux is handy — especially if you can have a dedicated VM or machine across the same (or different) network for testing!

And this if from my virtual desktop to you!