Packet loss of a digital transmission occurs when the data packets transmitted across a network fail to reach their destination. When this happens, the amount of data that is delivered to the destination is a fraction of what was originally sent. This has a negative impact on applications and digital services and it’s crucial to be proactive. Testing packet loss helps you identify issues early, and take appropriate measures to resolve them.
Effects of packet loss
Packet loss can have several negative implications on network performance and end-user experience. When packet loss happens, it will cause:
- A reduction in throughput and page loading time due to the required retransmissions in the case of TCP connections.
- Disruption of UDP communications in the case of real-time voice, video calls, etc.
For this reason, packet loss should be detected and remediated as soon as possible. There are several tools and troubleshooting techniques available. Each one of them has a specific function, goal, and requirements.
Tools for testing packet loss
Packet loss can be detected in different ways, and each method here listed has a specific context. It’s important to understand when it makes sense to use one or more approaches. In this section, we’ll introduce the following tools and techniques:
- Ping
- Iperf
- MTR
- Speed test
- Interface statistics
- Network monitoring tools
Ping
Ping is the go to tool for testing packet loss and round-trip time against a remote host. This command that can be executed from any computer’s console, since almost any operating system supports it. When you execute ping, by default it sends one packet every second to the destination host that you passed as argument. If the destination host is up and running, reachable, and allowed to respond, it will reply with an echo_reply packet to each echo_request by the sender. If the network between the two hosts has packet loss, some of these echo_request/echo_reply packets will be lost. The percentage of packet lost will be factored into the packet loss calculation.
The following output from a ping test against netbeez.net with 10 packets (option -c as count). All packets but one are received back, so the packet loss is 10%.
% ping -c 10 netbeez.net
PING netbeez.net (141.193.213.10): 56 data bytes
64 bytes from 141.193.213.10: icmp_seq=0 ttl=59 time=8.135 ms
64 bytes from 141.193.213.10: icmp_seq=1 ttl=59 time=15.771 ms
64 bytes from 141.193.213.10: icmp_seq=2 ttl=59 time=16.383 ms
64 bytes from 141.193.213.10: icmp_seq=3 ttl=59 time=17.835 ms
64 bytes from 141.193.213.10: icmp_seq=4 ttl=59 time=9.219 ms
64 bytes from 141.193.213.10: icmp_seq=5 ttl=59 time=15.211 ms
64 bytes from 141.193.213.10: icmp_seq=6 ttl=59 time=8.148 ms
64 bytes from 141.193.213.10: icmp_seq=7 ttl=59 time=16.280 ms
Request timeout for icmp_seq 8
64 bytes from 141.193.213.10: icmp_seq=9 ttl=59 time=8.001 ms
--- netbeez.net ping statistics ---
10 packets transmitted, 9 packets received, 10.0% packet loss
round-trip min/avg/max/stddev = 8.001/12.905/17.835/3.817 msIperf
Iperf is a client-server bandwidth testing tool that generates TCP or UDP traffic from one host to another. To use iperf, you need to run the iperf client on the sender host (iperf -c <server_address>), and the iperf server on the receiving host (iperf -s). When running in UDP mode (-u flag), iperf returns the amount of packets transmitted, and the packet loss. In the following example you can see a 10 Mbits/sec transfer with 0% packet loss.
Iperf can be used to identify packet loss from one network to another.
------------------------------------------------------------
Client connecting to 10.0.20.5, UDP port 5001
Sending 1470 byte datagrams, IPG target: 1121.52 us (kalman adjust)
UDP buffer size: 0.16 MByte (default)
------------------------------------------------------------
[ 3] local 10.0.10.5 port 60603 connected with 10.0.20.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 1.22 MBytes 10.2 Mbits/sec
[ 3] 1.0- 2.0 sec 1.28 MBytes 10.8 Mbits/sec
[ 3] 2.0- 3.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 3.0- 4.0 sec 1.24 MBytes 10.4 Mbits/sec
[ 3] 4.0- 5.0 sec 1.26 MBytes 10.5 Mbits/sec
[ 3] 5.0- 6.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 6.0- 7.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 7.0- 8.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 8.0- 9.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 0.0-10.0 sec 12.5 MBytes 10.5 Mbits/sec
[ 3] Sent 8917 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 12.5 MBytes 10.5 Mbits/sec 0.009 ms 0/ 8917 (0%)MTR
MTR stands for Matt’s Traceroute. This utility merges the functionalities of traceroute and ping. Like traceroute, it discovers all the routers between the source and destination, those at least that reply to requests. Like ping, it runs ping tests against all the discovered routers, and reports latency and packet loss.
MTR can be used to pinpoint issues at various points along the path(s) to the destination. In the following screenshot you can see that hops 3, 4, and 5 are having more than 25% of packet loss. That could indicate performance issues along the Internet path.
Speed test
NDT is a speed test utility that runs download and upload speed tests with a server on the Internet. Along with latency, download and upload speed, NDT also reports the TCP retransmissions. TCP retransmissions are an indication of packet loss. The NDT servers are hosted by an consortium for open measurements called the M-LAB (Measurement Lab). Some servers are also hosted by third parties around the world. You can also host your own server if interested.
Interface statistics
If you manage a node that you discovered is dropping packets, check the interfaces counters on the interfaces where the traffic flows. The command or method to see interfaces’ counters errors changes based on the vendor and platform. The good news is that you may be able to find the root cause of packet loss.
The following example illustrates the show command on a Cisco switch returns the number of frames with alignment, FCS (checksum), transmit, receive, and undersize errors.
#show interfaces counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Fa0/1 0 0 0 0 0
Fa0/2 0 0 0 0 0
Fa0/3 0 0 0 0 0
Fa0/4 0 0 0 0 0
Fa0/5 0 0 0 0 0
Fa0/6 0 0 0 0 0
Fa0/7 0 0 0 0 0
Fa0/8 0 0 0 0 0
Fa0/9 0 0 0 10112735 0
Fa0/10 0 0 0 0 0
Fa0/11 0 0 0 0 0
...Network monitoring tools
A network monitoring tool allows you to monitor all these metrics automatically, and get alerts when packet loss is detected. For active measurements like ping, traceroute, and NDT, NetBeez is an option available. To monitor interface errors, an SNMP management tool like SolarWinds or Nagios would work.
The following screenshot shows a ping test run by a NetBeez endpoint. The test reports packet loss and other statistics.
Causes and possible solutions for packet loss
There are several possible causes of packet loss. When troubleshooting, it’s important to consider all of them. The troubleshooting process will help eliminate those that don’t apply to a specific case. Here are some of the most common causes and corresponding solutions for packet loss.
| CAUSE | POSSIBLE SOLUTION |
|---|---|
| Hardware failures Faulty network equipment or bad cabling such as dirty/faulty connectors or fiber optics. | Hardware upgrade or recabling. |
| Network congestion When the traffic originated is higher than what the network can forward. Buffers will start filling up, and packets will get dropped. | Bandwidth or hardware upgrade. |
| Interferences In wireless communications, interferences and obstacles induce packet loss. | Remove interference sources, change channels, or consider extenders/repeaters. |
| Configuration issues For example speed-duplex mismatches between two neighbors, incorrect QoS parameters, etc. | Reconfiguration or QoS changes. |
Conclusion
By regularly testing packet loss using these methods, you can gain insights into the health of your network, identify issues early, and take appropriate measures to resolve them. Addressing packet loss promptly will significantly improve end-user experience and prevent disruptions in critical activities. Request a demo of NetBeez if you don’t monitor this important metric.
