Lab Objective:
The objective of this lab is to learn how to identify packet loss, misconfiguration and redirections.
Lab Purpose:
Understand how to detect and troubleshoot issues related to packet loss, misconfiguration and redirections.
Lab Tool:
Wireshark Network Analyzer on PC, Ethernet Switch/Router (cable/WiFi)
Lab Topology:
Please use the following topology to complete this lab exercise (Pc equipped with Wireshark connected via wireless to a Network Router that has access to the internet).
Lab Walkthrough:
Task 1
Packet loss can degrade performance when the receiver must request retransmissions and wait for them before passing data to the application.
For example, when packet loss occurs on a TCP connection that does not support Selective ACKs, numerous packets may be retransmitted as the receiver cannot acknowledge receipt of data after the lost packet.
Ensure you capture some minutes of traffic with Wireshark while you are navigating in the web browser, then stop the capture and save the file.
In order to analyze if the communication contains packet retransmission, apply the Display Filter “tcp.analysis.retransmission” as displayed in the figure below:
We can see a lot of TCP retransmission packets, indicating that the performance of the communication is getting low.
In a UDP-based application, instead, the retransmission timeout value is dictated by the application itself. An application that is slow to request retransmission will affect the overall performance of the application.
Imagine for example, a retransmission process occurring on a DHCP client. If the very first DHCP Discover goes unanswered, the DHCP client has to retransmit the Discover packet. In case the client waits for a couple of seconds before retransmitting the Discover packet, a delay in recovering from possible packet loss during the boot-up process may occur. Since the DHCP server or relay agent must be on the same network segment, a couple of seconds seems to be an excessive amount of time.
If you are capturing traffic in the infrastructure and you see the original packet and the retransmission, you are upstream from (at a point before) the point of packet loss. “Upstream” means you are closer to the sender of the data. To find out where packet loss is occurring, move along the path until you no longer see the original packet and retransmissions to find out exactly where the packets are being dropped.
Packet loss typically occurs at interconnecting devices such as switches and routers. This is a relatively simple process for TCP communications since Wireshark clearly indicates which packets are retransmissions (in the Info field in the Packet List pane and in the Packet Details pane too), as displayed in the figure below:
To locate if there is packet loss in a capture, trace file, and open the IO Graph as displayed in the figure below:
Fill in the Display Filter fields for the graph with the following filters:
“tcp.analysis.duplicate_ack”
“tcp.analysis.lost_segment”
“tcp.analysis.retransmission”
Assign a different color for each graph, as displayed in the figure below (in the ‘color’ column):
As it is possible to observe in this case, there is no clear effect of packets lost during this quite short TCP session. But in general, TCP doesn’t do well with a large amount of packets lost in a single congestion window, so it is important to keep an eye on this important parameter.
Task 2
Open the web browser and watch a video from a webstream, and in the meantime, download a large file from the Web. Start capturing with Wireshark for some minutes, and then stop the capture and save the file.
Open the IO Graph in order to display the Packets/Tick for a tick of 100ms. In this case, the result is displayed in the figure below:
It indicates the so-called “Heartbeat” effect on the IO graph. In fact, various misconfigurations can affect network performance. For example, video multicast traffic that is prioritized below file transfer, voice, and email traffic may be held in queues along a path, and this traffic that is held in a queue (while higher priority traffic flows ahead of it) can be affected by these issues.
Task 3
Another common example of a performance issue is caused by Traffic Redirections. The most common redirections seen on a network are based on default paths that may not be optimal or available. This could be a default gateway that does not offer the best route to the target network (responding with an ICMP redirection packet).
Another common redirection is seen in web browsing sessions when a browsing client connects to a website, only to be redirected to other sites to build the pages.
To verify that kind of effect, open your web browser, having started a capture session with Wireshark, and fill in the Web Browser address location with the address “www.nytimes.org” and hit “Return”. After some seconds, the web browser has been redirected to the page “www.nytimes.com”. Now, stop the capture and save the file.
Fill in the Display Filter toolbar with the filter “ frame contains “nytimes” “ as in the figure below: it is easy to identify the first HTTP packet requesting the desired web page (frame #672).
Having disabled the Display filter and selecting the frame immediately after the HTTP get request (frame #672), and with right click enabling the “Follow TCP stream”, as shown in the figure below:
This will result to an info stream where the server () indicates to the client that it must connect to “nytimes.com”. This prompts the client to generate a DNS query for the new site before generating a TCP handshake.
Notes:
Repeat the previous steps, capturing some traffic with Wireshark, and identify possible packet loss in the capture, trying to find the root cause. Generate the related IO graphs in order to confirm if the network is correctly configured or not, and if there are redirection problems.
