Table of Contents
I came across a question about bandwidth measurement on https://osqa-ask.wireshark.org/. A user was asking how to measure his real bandwidth. According to his post on the site, he tried many methods but was not happy with the different results, since he expected similar outcomes for bandwidth usage. Tools like Cacti, Net Limiter, Resource Monitor and Task Manager were used during the test. Each time there were discrepancies and he was asking for a solution. We will find the answer in this article, using many functionality in Wireshark.
What is Bandwidth?
Bandwidth is the maximum rate of transferring data from one point to another point in a specific amount of time. when you buy a service of 30Mbps (megabits per second) from your ISP (Internet Service Provider), it means you will be able to transfer 30 million bits in a second. Let's assume that you have a file size of 1.8GB (gigabytes) to transfer it to your Dropbox and you would like calculate how much time it will take for transferring the file. Since the file size and bandwidth rate are in different units, you need to calculate your file size in bits. 1 byte is equal 8 bits.
Taking this into account, we can say your file size is 1.8x8 Gb(gigabits). When we divide the total size in bits by bandwidth, we will get the time it takes to transfer the file. After the conversion of the units, the result will be 480 seconds which means that it will be transferred in 8 minutes. I think the concept of bandwidth is clear now.
Let’s discover how to measure bandwidth using wireshark.
Wireshark I/O Graphs Window
Wireshark has multiple ways to measure your bandwidth. I/O Graph is one of the most common and easy way to plot your data in variety ways. I will transfer a file from my virtual machine to my main machine and start capturing during the transfer. After transfer is finished, we will use Wireshark I/O Graph function to plot the data which will give us the idea of how much bandwidth we used.
Steps are below.
1) Stop packet capturing from the interface.
2) Go to Statistics menu and click on I/O Graphs.
3) Now, you will see your bandwidth usage in number of “packets”. You can change this from “Y Axis”. I want to see the bandwidth usage in bits per second so I change the Y Axis value to “Bits” and leave the “interval” as 1 sec. See the details below.
In the figure above, we can clearly see how much bandwidth it consumed during the file transfer. Since the plot is based on the real data (packets), it is most accurate method of measuring bandwidth.
I/O Graph window lets you customize the plots. For example, when you need to see multiple plots in the same window (assume you need to compare two IPs traffic), you should add multiple rows and prepare a display filter to show the only traffics you are interested in. In the figure below, I prepared two display filter and showed two different graphs in the same window which lets us to make a correlation and have a better perspective.
Finding the culprit eating your bandwidth
Bandwidth over utilization is one of the culprit that makes your network performance slow which can be difficult and you may want to know which application or client consumes most of your bandwidth. Collecting flows (NetFlow, Sflow etc.) is one of the method to find who is consuming your bandwidth, but it is not easy setting up all the infrastructure and pretty expensive. Another option can be using Wireshark to find top bandwidth consumers. Wireshark includes many useful windows, some of them explained below.
1. Endpoints Window
In this window, we will be able to see layer 2, 3 and 4 endpoints, which are Ethernet, IP, and TCP or UDP. Let’s sniff our interface and discover who is consuming most of our bandwidth. The steps are below.
1) From Statistics menu, click on Endpoints
2) I select Ipv4 tab and sort the IP addresses (Endpoints) by Tx Bytes(Transmit). There are many criteria like Packets, Bytes, Tx Packets, Tx Bytes, Rx Packets, Rx Bytes and so on. Beside the fixed 5 tabs, you can filter based on the display filters. After sorting by transmitted bytes, the endpoint in the first row is the top bandwidth consumer. See my output below.
3) You should enable name resolution, if the IP addresses in the figure above are not familiar to you. From Edit menu, click on the Preferences as below.
4) Preferences window pops up. Select “Name Resolotion” from left pane then check “use captured DNS packet data for address resolution” and “ use an external name resolver”. Next, click Ok to close the window.
5) Again from Statistics menu, click on In the opening window, do not forget to select “Name Resolution” and sorting based on the parameter you want. In the end, you will see something like below.
As you see in the figure above, the IP address that is using most of the bandwidth is not translated into a domain name. There can be many reason behind that. Remember that we selected “use captured DNS packet data for address resolution” from Edit->Prerences->NameResolution. Since the connection established before we started to capture the packets, We were not be able to capture the dns resolution packets, in other saying we missed to capture some dns packets that is why Wireshark can not translate some IP addresses into domain names.
Let’s prepare a dns “A” record filter for that IP address (184.108.40.206) to confirm that we missed some dns packets. As seen below, there is no match for that “A” record.
Lets go for another IP address (220.127.116.11). After applying the display filter, it shows some results. See my output below.
Another common reason is that DNS records can be cashed after the resolution. Even you start capturing before a connection establishes, you will not see any DNS activity for that domain or IP address since your dns requests are cashed before. The figure below shows that the client should cache the “A” record for www.golinuxcloud.com for 5 minutes.
2. Protocol Hierarchy Window
1) Sometimes we need to know bandwidth consumption by protocols and in this kind of case, “Protocol Hierarchy” window comes in handy. “Protocol Hierarchy” window shows the protocol distribution in the captured file. Let’s analyse our packets by protocols. From Statistics menu, click on Protocol Hierarchy.
In the figure above, we can see all packets are using IPv4 while in transport layer, UDP ( User Data Gram) takes lion's share with 95.9 percent. TCP only makes 4.1 percent whereas HTTP only is 0.1 percent.
Conversations Window (Statistics à Conversations) is yet another useful tool to see the volume of the conversations between endpoints. We can measure bandwidth consumption by conversations in IP, TCP, UDP or Ethernet. See below my output.
In the first row, you can see I am filtering the conversations by IPv4. It does not matter how many TCP conversation in it. IPv4 tab shows total bandwidth usage from source/destination Address A to destination/source Address B. When you need a conversation bandwidth consumption by each connection, you can use TCP tab to see how much bandwidth is consumed by each connection.
Wireshark Statistics menu includes many great windows to help you analyse your network activity. Since everything is based on the packets, we can easily trust it’s judgement about bandwidth usage, endpoint conversations statistics etc.