If you would like to read the other articles in this series please go to:
If you would like to be notified when Brien Posey releases Working with Network Monitor (Part 5) please sign up to the WindowsNetworking.com Real Time Article update newsletter.
So far in this article series, I have shown you some basic techniques for capturing data using Network Monitor. In this article, I want to continue the discussion by showing you how to analyze the data that you have captured.
For the purposes of keeping things simple, let’s perform a packet capture against a simple ping operation. To do so, log on to the server that you will be running Network Monitor on, and open a Command Prompt window. When the command prompt window opens, type the PING command followed by a space and the fully qualified domain name or the IP address of a computer on your network, but do not press Enter yet. Now, open the Network Monitor and select the Start command from the Capture menu. Immediately switch over to the Command Prompt window and press Enter to execute the PING command. The command should return four results, as shown in Figure A. As soon as the command finishes executing, switch back to the Network Monitor screen and select the Stop command from the Capture menu. In doing so, you will have captured the packets associated with the PING command, but will likely have captured some unrelated traffic as well.
Figure A: The PING command should return four results
After you stop the capture process, click the Display Captured Data icon (
) to view the data that you have captured. The actual amount of data that will be displayed as a part of the capture depends on how busy your network is and on how long the PING command takes to complete. On a lab network, you may only capture a few dozen frames, while you will almost certainly capture many more frames if you are capturing data from a production network. For example, when I tried this procedure while writing this article, I captured nearly six hundred frames over the course of about five seconds.
The point is that if you were using the Network Monitor to troubleshoot a network problem in the real world, you would almost certainly capture some irrelevant data. Knowing how to sift through this excess data is an essential skill because otherwise locating the data that you are actually interested in could be like looking for a needle in the proverbial haystack.
If you look at Figure B, you will notice that there were quite a few packets captured. Our job is to filter the packets that are unrelated to the activity that we were trying to capture so that analyzing the captured packets will be easier.
Figure B: Network Monitor will often capture traffic that is unrelated to the activity that you are trying to analyze
To do so, click the Filter icon found on the tool bar. When you do, you will see a rather intimidating looking dialog box, as shown in Figure C. What this dialog box is telling you is that right now Network Monitor is showing you all of the captured data, regardless of protocol or IP address.
Figure C: The Display Filter dialog box can appear a bit intimidating
However, we performed a PING from one machine to another, and we know the IP addresses that were involved in the PING. Therefore, we can filter on those addresses. To do so, select the ANY <-> ANY line and click the Edit Expression button. You will now see a screen similar to the one that’s shown in Figure D.
Figure D: The Expression dialog box allows you to select the addresses involved in the conversation
This screen allows you to select the addresses of the two machines involved in the conversation. Normally, you would simply select the source and destination addresses, verify that the direction column was set to <-> and click OK. In this particular case things are a bit more complex.
You will notice in the figure that there are multiple IP addresses associated with the machine FUBAR. That’s because this machine is a Web server and is hosting multiple sites, each with their own address. In a situation like this, you would select the machine’s primary address unless you had a specific reason for using one of the other addresses.
The other thing that makes this screen a bit difficult is that the address of the destination machine is not displayed. You can fix this by clicking the Edit Addresses button. Doing so will display a list of all of the addresses from the previous list. Click the Add button and you will be given the chance to add an address to the list. Notice in Figure E that you must choose the type of address (IP or MAC) that you are adding. Click OK followed by Close, and the address will be added to the address filter.
Figure E: You can manually add an address to the list
Now select the IP addresses involved in the conversation that you are interested in and click OK twice. The list of captured frames is now filtered to display only traffic from the selected machines, as shown in Figure F.
Figure F: We have filtered the list of captured data to display only the frames that we are interested in
Since our capture only involved the PING command you shouldn’t have any trouble locating the data that you are looking for. In the real world though, there is a chance that the data that you are trying to capture may not even exist within the capture. There are two primary conditions that can cause this to happen.
The first reason why your capture file may not contain the data that you are interested in is because most companies have made the move from hubs to switches. On a network in which hubs are used, every computer on the hub receives the exact same traffic. When a computer needs to communicate with another computer, it places a packet on the wire, and that packet travels to every computer that’s attached to the hub. Each computer looks at the destination address found in the packet header to check to see if the packet is intended for that computer. If the destination address matches the computer’s MAC address then the computer opens the packet and processes its contents. Otherwise the packet is ignored.
Things work differently if a switch is involved. When a computer sends a packet, the switch actually looks at the packet header to determine the packet’s intended recipient. The switch then forwards the packet to the switch port that the recipient is attached to. Computers other than the sender and the recipient are completely oblivious to the conversation.
The reason why switches have begun replacing hubs is because switches are far more efficient (and more secure) than hubs. If a hub is in use and two computers attempt to transmit data at the same time, a collision occurs, destroying both packets in the process. The two computers each wait a random amount of time before retransmitting the data. The more computers that are attached to a network, the more collisions occur. Of course more collisions mean slower network performance. Therefore, dropping prices and the need for greater performance has driven many companies to make the move to switches.
Switches are particularly problematic when it comes to capturing data with Network Monitor. Because of the way that switches work, you will only be able to capture data sent to or from the computer that Network Monitor is running on.
Another condition that may lead to the desired packets not being captured is the use of virtual machines. If a single server is hosting multiple virtual machines, then the traffic flowing between those virtual machines will most likely not be captured because traffic between virtual machines hosted by a single server typically does not flow across the wire. It is possible to configure virtual machines so that traffic between them is placed on the network, but doing so is beyond the scope of this article.
Conclusion
In this article, I have explained the need for filtering captured data, and why you may not capture all of the data that you expect. In Part 4, I will continue the discussion by showing you how to analyze the filtered data.
If you would like to read the other articles in this series please go to:
If you would like to be notified when Brien Posey releases Working with Network Monitor (Part 5) please sign up to the WindowsNetworking.com Real Time Article update newsletter.
