Monday, September 20, 2010

Iperf - tool for every NetEngineer's Toolbox

Ever wondered, “man, how do I see exactly how much traffic I really can push over this link?” or “I wish I could create some multicast traffic so I can see the bandwidth and make sure everything is working before the vendor gets here.” Well, in steps the simplest program ever, Iperf.

Download the file applicable to your OS. You will need two installs, a source and a destination (Iperf will refer to these as server and client).

Pick one to be your server. Open a command window and browse to the Iperf file. Type: iperf -s

Done, you have an Iperf server running.

Go to machine 2, browse to where you placed the iperf file. To run a simple bandwidth test, just type: iperf -c x.x.x.x where x.x.x.x is the server’s IP address.

View the output, if it is a 100Mb link, you will probably see around 80-85 Mb/s speed and near a 100MB transfered. (If you are running fast, I have seen as quick as 98Mb/s, but that tends to be local to the same switch or nearby)

Now you can start playing with the extra switches. A common one might be:

iperf -c x.x.x.x -r -t 300 -i 2

here, we see -r will run both a regular test from the client to the server, but then reverse it and send traffic from the server to the client. Next we have -t 300 which tells iperf to run for 300 seconds, or 5 minutes. -i 2 informs the program to give you an output ever 2 second interval so you can see what is happening and see any spikes or slowdowns during the test rather than just a averaged output at the end.


Want to test udp traffic, you will need to add a -u on the end of the server command as well as the client command. That lets both sides of the link know to use UDP traffic rather than TCP.


If you are testing a production link, perhaps you don't want to use up the entire link and slow down everyones traffic. use the -b 10m command to set bandwidth to 10Mb/s.


-B x.x.x.x on both ends of the link will bind them to a multicast address, allowing you to look at your router and see the multicast joins and traffic flowing. Don't forget the -T for setting time to live numbers.

This data as pretty specific, and you can show your complainers/customers how well the network handles a solid gig of traffic, when their sluggish program using 50k of bandwidth is not a "slow network issue".

Pair this data with some colorful graphs showing how little they actually use your network and most people accept that the network isn't the problem.

Of course with your excellent customer service skills you have worded this all super politely and let them "arrive at their own conclusion" that there must be something else wrong than the network. Unless of course your gig interface is only able to push 2Mb/s of traffic, then you need to suck it up and figure out why your network is slow!

No comments: