Author Profile - Chris Greer is a Network Analyst for Packet Pioneer. Chris has many years of experience in analyzing and troubleshooting networks. He regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. When he isn’t hunting down problems at the packet level, he can be found teaching various analysis workshops at Interop and other industry trade shows. Chris also delivers training and develops technical content for several analysis vendors.
Chris can be contacted at chris (at) packetpioneer (dot) com.
How much bandwidth is an application using? At a remote office, how many users can simultaneously use that app before the WAN fills up?
Have you ever asked those questions before? I’m sure at one point or another we all have. Especially when in the network planning stage, it’s important to know how much bandwidth is taken up by an application or service. Recently I was at a site where one of the WAN links to a remote office was constantly being slammed up to 100% utilization. After putting an analyzer in and getting a sample of the traffic, we found that the high utilization was due to a security guard who was pulling several video camera feeds across the WAN so he could monitor the main building remotely.
There wasn’t necessarily a problem with this traffic, it’s just that the IT department was told that the video feeds used far less bandwidth than they really did. How could this traffic been measured ahead of time using Wireshark?
- The first thing we need to do is get a good example of the application traffic, preferably only one user or feed at a time. This can be done in a lab or test environment, or on the production network.
- Next, use Wireshark conversations to verify that we have the right traffic. Go to Statistics | Conversation List | IPv4. This will display the IP conversations that are in the trace. Find the application conversation you are interested in, look for the addresses of the client and server. Then right-click the conversation and set a filter for this flow.
- Now that you have isolated the application traffic for one user and filtered on that traffic, use the I/O graphs to measure the throughput. Go to Statistics | I/O.
This brings up the I/O graphs for the trace. This will graph out the utilization of the conversation over the course of the trace file. This is great because Wireshark lets us see the peaks and valleys of the utilization over time. By default, the I/O graphs will come up displaying a 1 second per tick X axis and the Y axis set to packets per
second.
In the graph below, we changed the Y axis to display bits/tick. This will show us the bitrate that is used by this application. This is an example of one VoIP call going across the wire.
We can see from the graph that this VoIP call is using 180Kbps. If we are planning to deploy at a remote office, we should take this number into account when deciding what bandwidth is necessary for the number of users at that office. Not to mention the email and other application usage as well.
Depending on the amount of traffic we captured, it may help to change the X axis to .01 seconds per tick. Remember that this will display the number of bits per 0.01. So in order to figure out the application utilization per second, we will need to multiply the bits/tick by 100.
Using the I/O graphs to measure application utilization is critical during the network planning phase. It can also help when troubleshooting delays in backups and file transfers on the network. After capturing the application, use the seconds and bits per tick to
determine the maximum bandwidth used by the app.
Recent Comments