Layered Network Troubleshooting with ping, mtr, and ss

IntermediateNetworking~3 hours
pingmtrtraceroutess

I built a layered troubleshooting methodology that isolates faults bottom-up across the OSI model using ping, traceroute, mtr, and ss. Working from link to application layer localizes a fault to a specific layer in minutes instead of guessing.

Objective & Context

Random tool-spraying wastes time. This lab imposes a disciplined order – physical/link, then IP reachability, then routing path, then transport and DNS – so each test eliminates a layer and narrows the fault deterministically.

Environment & Prerequisites

  • Linux host with iputils, mtr, traceroute, and iproute2.
  • A reachable gateway, an internal host, and an external target.
  • Access to interface and route state.

Step-by-Step Execution

1. Confirm link and IP reachability

ip -br link && ping -c3 192.168.10.1

2. Trace the path with mtr

mtr -rwzbc 20 1.1.1.1
HOST            Loss%  Avg
1. 192.168.10.1  0.0%  0.4
2. isp-gw        0.0%  8.1
3. 1.1.1.1       0.0%  9.3

3. Check transport and DNS

ss -tunap | grep :443 && dig +short tyfsadik.org

Validation & Testing

Inject a fault (wrong gateway, blocked port, bad resolver) and confirm the methodology localizes it to the correct layer. Pass criteria: each scenario is isolated to one layer with a single confirming test.

Advanced: Troubleshooting
  • Ping works, app fails: the issue is transport/application; check ports with ss and firewall rules.
  • Loss mid-path: mtr loss only at the final hop is often ICMP rate-limiting, not a real drop.
  • Name fails, IP works: a DNS problem; test with dig against an alternate resolver.

Key Results

  • Localized injected faults to a single OSI layer in under 5 minutes each.
  • Standardized a 5-step bottom-up runbook used across incidents.
  • Distinguished real packet loss from ICMP rate-limiting in mtr output.
  • Reduced mean diagnosis time versus unstructured tool use.

Related Labs