The Limitation of Basic Ping Tests
If a customer complains that they cannot connect to your company’s Linux web server, the first thing a junior IT technician will do is run a basic ping command. The ping command fires a tiny data packet at the server and waits to see if it bounces back. If the ping fails, the technician knows the server is completely unreachable.
However, the internet is not a direct wire between the customer and the server. Data must travel through dozens of intermediate routers (often owned by different telecommunications companies) to reach its destination. If a ping test fails, it does not tell you why it failed. Did your Linux server crash? Did the customer’s home router break? Or did a massive fiber-optic cable operated by AT&T get cut in half somewhere in the middle of the country?
To accurately diagnose exactly where the data is dying on the internet highway, you must trace the exact route the data is taking. You could use the classic traceroute command, but it is static and slow. For real-time, dynamic network forensics, modern systems administrators use the mtr (My Traceroute) command.
Step 1: Understanding MTR
The mtr command is essentially a hybrid. It violently smashes the basic ping command and the classic traceroute command together into a single, aggressively refreshing interface.
Because it generates highly specific ICMP network packets that manipulate the core networking stack of the operating system, you usually must run mtr with root administrator privileges.
Step 2: Launching a Basic Diagnostic
To test the connection between your Linux machine and a remote server (e.g., Google’s public DNS server), run the command followed by the IP address or domain name.
sudo mtr 8.8.8.8
Unlike a normal command that prints text and immediately returns you to a blank prompt, mtr completely hijacks your terminal window and replaces it with a dynamic, constantly updating dashboard.
On the left side of the dashboard, you will see a numbered list of “Hops.” These are the physical, intermediate routers your data is passing through. Hop 1 is usually your own office Wi-Fi router. Hop 5 might be a massive Comcast switching center in Chicago. Hop 12 is the final destination at Google.
Step 3: Analyzing the Data Columns
As you watch the dashboard, mtr fires hundreds of packets through the route every single second. The columns on the right instantly calculate the statistics for every single router along the path.
- Loss%: This is the most critical column. If Hop 6 shows a 0% loss, it is perfectly healthy. If Hop 7 suddenly shows a 60% loss, you have found the exact physical location of the internet outage. You can immediately call the telecom company that owns that specific router and demand a fix.
- Snt (Sent): The total number of packets fired at that specific router during this test.
- Last / Avg / Best / Wrst: This is the latency (measured in milliseconds). If the “Avg” (Average) time suddenly jumps from 20ms at Hop 3 to 900ms at Hop 4, you have found a router that isn’t broken, but is catastrophically congested with too much traffic.
Step 4: Using Report Mode for Automation
If you are writing a script to monitor network health overnight, you cannot use the interactive dashboard because nobody is sitting there to watch it. You need mtr to run quietly in the background and dump its final math into a text file.
You can use the -r (report) flag, combined with the -c (count) flag to specify exactly how many packets it should fire before giving up.
sudo mtr -r -c 10 8.8.8.8 > network_report.txt
This command silently fires exactly 10 packets at the destination, calculates the statistics, and saves a beautifully formatted text table directly into network_report.txt. By mastering mtr, you transform guesswork into exact, mathematically proven network forensics.