How to test packet loss on Windows, macOS and Linux

What causes packet loss?

Network devices, such as routers, switches, hardware firewalls and load balancers, sometimes receive more traffic than they can handle. This network congestion can cause the devices to drop data packets they can't deal with in a timely fashion. Devices might also be forced to drop packets because of the following issues:

• Equipment failure.
• Media damage.
• Wi-Fi interference.
• Software bugs.
• Unsupported protocols.

Some applications detect packet loss or incomplete transmissions, while others rely on the TCP/IP transport layer protocols to manage reliability. Two protocols operate at the transport layer and handle packet loss differently:

1. TCP. Numbers packets to mitigate loss and confirms packet delivery and retransmits lost packets. Described as reliable, stateful or connection-oriented.
2. User Datagram Protocol. Doesn't number or track packets to mitigate loss and doesn't guarantee packet delivery. Described as unreliable, stateless or connectionless.

Packet loss occurs almost anywhere along the network path between the system and the remote destination.

Network performance testing tools

Network testing utilities typically reside below the transport layer, enabling admins to test performance and functionality closer to the hardware using Internet Control Message Protocol (ICMP). These tools include the following:

• Ping.
• Traceroute/tracert.
• MTR.
• Pathping.

The following sections examine each tool in more detail and explain how to use each on Windows, macOS and Linux systems.

1. How to use use ping

Ping sends request messages to the destination system asking for a reply. If it receives the reply, it knows the remote host can receive and send, confirming connectivity. Test network reliability by sending large numbers of ping packets to watch for failed responses.

By default, Windows computers send four ping requests. You can specify the number of messages using the /n command-line option, like this:

ping /n 100 <destination>

The output shows the status and performance information for each request message.

Linux, macOS and other Unix-related OSes send continuous pings unless you limit the test. Use the -c option to specify the number of test messages, as seen in this command prompt:

ping -c 100 <destination>

Responses that take more than 100 milliseconds (ms) are considered high latency. Watch carefully for consistently high latency. Also, be aware of network jitter -- variations where latency changes rapidly rather than remaining consistently high or low.

ICMP packets might be involved in network attacks, such as ping floods and Smurf attacks. As a result, some administrators configure routers and firewalls to not respond to ICMP queries, greatly reducing ping's usefulness.

2. How to use traceroute and tracert

The traceroute utility also relies on ICMP messages to test connectivity and network performance. It displays response times for each hop, helping you determine where network issues might lie.

One of traceroute's most notable features is its ability to show the entire network path, which might be useful for troubleshooting or traffic shaping.

Again, consistent responses above 100 ms indicate a problem. One challenge when diagnosing these issues is whether you control the node causing lost packets. If the remote device is outside your network environment, you might not be able to troubleshoot any further. This is a common occurrence with ISPs and cloud service providers.

Because traceroute relies on ICMP packets, some routers and firewalls might block traceroute communications.

Note that the Windows version of traceroute uses the tracert command, while Unix-based terminals use traceroute.

3. How to use MTR

MTR combines ping's connectivity testing with traceroute's information about each hop. Whereas traceroute sends and measures one connection request per hop, the mtr command sends multiple tests, aggregates the results and displays far more comprehensive performance information using a live interface.

Although MTR might not be installed on your Linux distribution, you can add it by using one of the following commands:

dnf install mtr
apt install mtr

A Mac probably doesn't have MTR either, so install it using the Homebrew package manager with the following command:

brew install mtr

The tool is also distributed via this GitHub page.

MTR is interactive, which means the output results update regularly. These updates enable admins to keep an eye on a connection's performance. MTR uses multiple controls to manage the output, including the following.

4. How to use pathping

Windows relies on a tool similar to MTR called pathping to test packet loss. The pathping utility also records performance information about each hop, helping admins determine where packets are being dropped along the network path.

Be patient with pathping. It requires about 25 seconds per hop to gather information, which results in a relatively long test for destinations on the far side of multiple routers. However, its results are comprehensive.

Note that pathping's output might seem a bit odd. A score of 0/100 is considered perfect; in other words, zero out of 100 packets were lost.

Effective test methods

The best way to use these tools varies by situation and opinion. I tend to use the following two network testing approaches:

1. Connectivity testing. Check the connection as far outward as possible to the destination, and then troubleshoot inward along each possible hop.
2. Packet loss testing. Check the nearest connections first, and work your way outward to the final remote destination.

Testing as far out as possible means sending test packets to the final remote destination and then sending them to the next most remote hop. Continue this until you eventually reach your own default gateway. Test to the destination, and then work your way inward. This approach is efficient for connectivity testing. If the ping test reaches the remote destination, there's no reason to test connectivity to any other hops -- the connection works.

Performance testing in a business network environment operates from different assumptions. Network engineers control the first few hops of the connection, so they can influence or correct network issues that cause packet loss. Therefore, it's beneficial to begin performance testing with routers under your control. Trace packet loss from inside your network, and work outward. Begin with your default gateway.

Use the ipconfig /all command to display your default gateway address on your Windows system. On a Mac, enter netstat -rn | grep -i default. Use ip route | grep -i default on a Linux box.

Address packet loss quickly

Testing network performance and identifying packet loss are critical skills for network professionals. But they don't require learning specialized tools or purchasing expensive network monitoring software. Basic tools often available for your OS of choice usually suffice. More complex tools, such as the iPerf utility available for Linux, might be useful, but start with ping, traceroute, MTR and pathping.

Packet loss is a serious concern for users who rely on fast and reliable connections for real-time apps and services. Test for packet loss, and troubleshoot any issues quickly and efficiently. Add these utilities and practices to your toolkit for improved results.

Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides, and contributes extensively to TechTarget Editorial, The New Stack and CompTIA Blogs.