Tips on how to check for packet loss on Linux, macOS, and Windows
Tips on how to check for packet loss on Linux, macOS, and Windows
Performance-oriented network communications, gaming, real-time video chats, and user experience all suffer from packet loss. Network administrators must understand how to use tools like ping, traceroute, MTR, and pathping to test packet loss in their networks.
The tools that network managers can use to test for and detect packet loss and pinpoint its location along the communication line are covered in this article. Network experts can fix problems and enhance end-user performance with packet loss tests.
What leads to packet loss?
Routers, switches, hardware firewalls, and load balancers are examples of network devices that occasionally receive more traffic than they can manage. Devices may lose data packets they are unable to process quickly as a result of this network congestion. The following problems may also force devices to lose packets:
- Equipment malfunction.
- Harm to the media.
- Interference from Wi-Fi.
- Flaws in software.
- Protocols that are not supported.
While some applications use the TCP/IP transport layer protocols to control dependability, others use packet loss detection or partial transmissions. Two protocols have different approaches to handling packet loss and function at the transport layer:
TCP – This retransmits missed packets, verifies packet delivery, and numbers packets to reduce loss. Characterized as connection-oriented, stateful, or dependable.
UDP – This does not ensure packet delivery and does not track or number packets to reduce loss. Characterized as connectionless, stateless, or untrustworthy.
Almost anywhere in the network channel between the system and the distant target, packet loss can happen.
Tools for measuring network performance
Usually found below the transport layer, network testing tools allow administrators to use Internet Control Message Protocol (ICMP) to verify functionality and performance closer to the hardware. Among these tools are the following:
- Ping
- Traceroute/tracert.
- Pathping.
- MTR.
In the sections that follow, each program is examined in greater detail along with instructions for using it on Linux, macOS, and Windows.
1. Instructions for using ping
Ping requests a response from the destination system by sending request messages. It confirms connectivity if it gets the response, which indicates that the remote host can send and receive. Sending a lot of ping packets and keeping an eye out for unsuccessful answers will test the dependability of the network.
Windows machines send out four ping requests by default. With the /n command-line option, you can indicate how many messages to display, like in this example:
ping /n 100 <destination>
Each request message’s status and performance details are displayed in the output.
Unless you restrict the test, Linux, macOS, and other Unix-related operating systems deliver constant pings. The amount of test messages can be specified with the -c option, as shown in this command prompt:
ping -c 100 <destination>
High latency responses are those that take longer than 100 milliseconds (ms). Keep an eye out for persistently excessive latency. Additionally, be mindful of network jitter, which is a phenomenon in which latency fluctuates quickly instead of staying constant at either a high or low level.
Ping floods and Smurf assaults are two examples of network attacks that may use ICMP packets. Because of this, some administrators set up firewalls and routers to ignore ICMP requests, which significantly diminishes the utility of ping.
2. How traceroute and tracert are used
ICMP messages are also used by the traceroute/tracert to test network performance and connectivity. By showing reaction times for every hop, it assists you in identifying potential network problems.
C:\WINDOWS\system32>tracert www.google.com
Tracing route to www.google.com [74.125.130.106]
over a maximum of 30 hops:
1 1 ms <1 ms 1 ms 192.168.0.1
2 8 ms 7 ms 7 ms 164.253.128.1
3 7 ms 7 ms 6 ms 212.164.32.225
4 7 ms 7 ms 7 ms gw3.conn.com [202.164.32.35]
5 17 ms 8 ms 8 ms nsg-static-181.124.71.182.airtel.in [182.71.124.181]
6 20 ms 15 ms 15 ms 116.119.55.4
7 17 ms 18 ms 18 ms 72.14.222.116
8 21 ms 20 ms 20 ms 142.251.249.5
9 21 ms 20 ms 27 ms 216.239.50.22
10 50 ms 50 ms 52 ms 142.250.224.157
11 82 ms 83 ms 83 ms 74.125.251.157
12 101 ms 92 ms 90 ms 108.170.225.101
13 81 ms 81 ms 81 ms 216.239.35.159
The ability of traceroute to display the complete network path is one of its most noteworthy characteristics; this could be helpful for traffic shaping or troubleshooting.
Once more, an issue is indicated by continuous responses longer than 100 ms. Determining whether you have control over the node that is causing lost packets is one of the challenges in diagnosing these problems. You might not be able to troubleshoot further if the remote device is not within your network environment. ISPs and cloud service providers frequently experience this.
3. How to utilize MTR
MTR integrates traceroute’s information about each hop with ping’s connectivity testing. The mtr command sends several tests, combines the results, and uses a live interface to present significantly more extensive performance statistics than traceroute, which transmits and measures one connection request per hop.
Your Linux distribution may not have MTR installed, but you can add it using one of the commands below:
dnf install mtr
apt install mtr
Since a Mac most likely lacks MTR as well, use the Homebrew package manager to install it with the following command:
brew install mtr
Because MTR is interactive, the output results are updated on a regular basis. Administrators can monitor a connection’s performance with these upgrades. The following are some of the controls that MTR utilizes to manage the output.
| Shortcut | Purpose |
| p | Pause |
| SPACE | Resume |
| r | Reset |
| d | Toggle display |
4. How to apply pathping
Windows tests packet loss using a tool called pathping, which is comparable to MTR. Additionally, the pathping tool logs each hop’s performance, which aids administrators in figuring out where packets are being dropped along the network path.
When pathping, be patient. For destinations on the other side of several routers, the test is somewhat lengthy because it takes roughly 25 seconds per hop to collect information. But its findings are all-encompassing.
Be aware that the results of pathping may appear a little strange. A perfect score is zero out of one hundred, meaning that no packets were lost.
C:\WINDOWS\system32>pathping www.google.com
Tracing route to www.google.com [74.125.130.105]
over a maximum of 30 hops:
0 PC1 [192.168.0.38]
1 192.168.0.1
2 164.253.128.1
3 212.164.32.225
4 gw3.conn.com [202.164.32.35]
5 nsg-static-181.124.71.182.airtel.in [182.71.124.181]
6 116.119.55.4
7 72.14.222.116
8 142.251.248.255
9 192.178.83.220
10 142.250.224.151
11 172.253.74.53
12 216.239.51.20
13 216.239.35.165
14 * * *
Computing statistics for 325 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 PC1 [192.168.0.38]
0/ 100 = 0% |
1 1ms 0/ 100 = 0% 0/ 100 = 0% 192.168.0.1
0/ 100 = 0% |
2 6ms 0/ 100 = 0% 0/ 100 = 0% 164.253.128.1
0/ 100 = 0% |
3 8ms 0/ 100 = 0% 0/ 100 = 0% 212.164.32.225
0/ 100 = 0% |
4 8ms 0/ 100 = 0% 0/ 100 = 0% gw3.conn.com [202.164.32.35]
0/ 100 = 0% |
5 8ms 0/ 100 = 0% 0/ 100 = 0% nsg-static-181.124.71.182.airtel.in [182.71.124.181]
0/ 100 = 0% |
6 15ms 0/ 100 = 0% 0/ 100 = 0% 116.119.55.4
0/ 100 = 0% |
7 20ms 0/ 100 = 0% 0/ 100 = 0% 72.14.222.116
0/ 100 = 0% |
8 20ms 0/ 100 = 0% 0/ 100 = 0% 142.251.248.255
0/ 100 = 0% |
9 22ms 0/ 100 = 0% 0/ 100 = 0% 192.178.83.220
0/ 100 = 0% |
10 51ms 0/ 100 = 0% 0/ 100 = 0% 142.250.224.151
0/ 100 = 0% |
11 — 100/ 100 =100% 100/ 100 =100% 172.253.74.53
0/ 100 = 0% |
12 84ms 0/ 100 = 0% 0/ 100 = 0% 216.239.51.20
1/ 100 = 1% |
13 82ms 1/ 100 = 1% 0/ 100 = 0% 216.239.35.165
Trace complete.
