Network Diagnostics: Ping, Traceroute, and Port Scanning Guide

Network diagnostic tools are the stethoscope of infrastructure operations and security assessment. They allow engineers to measure connectivity, identify packet loss, map network paths, discover open services, and characterize firewall behavior — all without deploying additional software on target systems. Ping, traceroute, and port scanning are the foundational trio that every network engineer and security professional uses daily. Understanding their mechanics, not just their usage, enables you to interpret ambiguous output correctly and use them effectively in both troubleshooting and security assessment contexts.

Ping sends ICMP Echo Request packets to a target host and measures whether ICMP Echo Reply packets are received, how long they take to arrive (round-trip time, RTT), and whether any packets are lost. Despite its simplicity, ping output conveys several important metrics:

Basic Ping Usage

# Linux/macOS - 4 packets (default: continuous)
ping -c 4 8.8.8.8

# Windows
ping 8.8.8.8

# Linux - continuous with timestamp
ping -D 8.8.8.8

Interpreting Ping Output

• TTL (Time To Live) — The TTL field in the reply packet tells you how many hops the packet traveled. Linux typically initializes TTL at 64, Windows at 128, Cisco at 255. Subtracting the received TTL from the OS default gives the approximate hop count. A TTL of 56 in an ICMP reply from a Linux host suggests 8 hops (64 - 56 = 8).
• Round-trip time (RTT) — The time between sending the request and receiving the reply. RTT under 10ms indicates local network; 10–50ms is typical for continental connections; 100–300ms for intercontinental; above 300ms indicates either very long distance or congestion. RTT consistency matters as much as the absolute value — high variance (jitter) indicates queue buildup or packet loss-induced retransmission.
• Packet loss — Any packet loss on a LAN indicates hardware or configuration problems. Small amounts of packet loss (1–2%) on internet paths may be acceptable but warrant investigation on corporate WAN links. Above 5% packet loss typically causes application performance degradation.
• Request timeout / no response — The destination is unreachable, the path is blocked by a firewall, or ICMP is rate-limited or disabled on the target. Host unreachability cannot be reliably concluded from ping failure alone — the host may simply have ICMP disabled.

Traceroute (or tracert on Windows) reveals the series of routers between your source and a destination. It works by exploiting the TTL field: each probe is sent with a progressively increasing TTL value, starting at 1. Each router that decrements TTL to zero sends back an ICMP Time Exceeded message, revealing its IP address and the time taken to reach it.

Traceroute Variants

• Linux traceroute — Sends UDP probes by default on high-numbered ports (33434+). May be blocked by firewalls.
• tracepath — Similar to traceroute but also discovers MTU along the path (useful for fragmentation debugging).
• tracert (Windows) — Sends ICMP Echo Request probes instead of UDP, which has better pass-through rates on some firewalls.
• TCP traceroute — traceroute -T -p 443 sends TCP SYN packets, which are more likely to traverse firewalls to web servers than ICMP or UDP probes.

# Standard traceroute
traceroute google.com

# TCP traceroute to port 443 (bypasses some firewalls)
traceroute -T -p 443 google.com

# Windows
tracert -d google.com

Reading Traceroute Output

Each line shows one hop: the hop number, the router's hostname (if resolvable) and IP address, and three RTT measurements for three probes sent at that TTL. Important patterns to recognize:

• Asterisks (* * *) — The router at this hop did not respond. This is not necessarily a problem — many routers deprioritize or rate-limit TTL-exceeded messages for administrative or security reasons. Asterisks in the middle of a path do not mean the path is broken; if subsequent hops respond, the path continues through the silent router.
• Asymmetric routing — Forward and reverse paths may be different (different ISPs, BGP policies). RTT can appear to increase then decrease as the path shifts between routers.
• ISP handoff points — A sudden RTT increase of 20–50ms often indicates a handoff between ISPs or a trans-oceanic cable segment. Identifying these points helps determine where latency is introduced.
• Persistent high latency at a specific hop — May indicate congestion at that router. Compare RTT at the suspect hop with RTT at subsequent hops — if subsequent hops have lower RTT, the high value at the suspect hop is likely due to ICMP deprioritization rather than actual congestion.

MTR (Matt's Traceroute / My Traceroute) combines ping and traceroute into a continuously updated display, sending hundreds of probes to each hop and computing packet loss and RTT statistics per hop. This makes it far superior to a one-shot traceroute for diagnosing intermittent problems:

# Run MTR for 100 packets and show report
mtr --report --report-cycles 100 google.com

# TCP mode to port 443
mtr -T -P 443 --report-cycles 100 google.com

The output shows packet loss percentage and average/best/worst/standard deviation RTT per hop. Packet loss at a specific hop that does not propagate to subsequent hops indicates that hop is deprioritizing ICMP — not actual packet loss. True packet loss appears at a hop and continues through all subsequent hops.

Port scanning probes a system's TCP or UDP ports to determine which services are listening. This is fundamental to both network administration (verifying firewall rules, discovering unauthorized services) and security assessment (attack surface enumeration). Understanding scan types helps you choose the right technique for the situation:

• TCP Connect Scan — Completes the full TCP three-way handshake (SYN, SYN-ACK, ACK). Reliably detects open ports but is fully logged by the target. The default when running without root/Administrator privileges.
• TCP SYN Scan (half-open scan) — Sends SYN, receives SYN-ACK (open) or RST (closed), then sends RST without completing the handshake. Faster than connect scan and generates fewer log entries on some systems. Requires raw socket privileges (root/Administrator).
• UDP Scan — Sends UDP probe packets and waits for ICMP Port Unreachable responses (closed) or no response (open or filtered). Much slower than TCP scanning; UDP services are often overlooked in assessments.
• NULL, FIN, Xmas scans — Send packets with unusual TCP flag combinations. On RFC-compliant systems, closed ports respond with RST; open ports send no response. Can bypass some simple firewalls and packet filters but unreliable on Windows targets.

Nmap is the de facto standard port scanner for security professionals. Its feature set extends well beyond basic port scanning to include service version detection, OS fingerprinting, and scriptable network analysis:

# SYN scan top 1000 ports (requires root)
nmap -sS 192.168.1.1

# Connect scan specific ports (no root needed)
nmap -sT -p 22,80,443,8080,8443 192.168.1.1

# Service version and OS detection
nmap -sV -O 192.168.1.1

# Run default scripts with version detection
nmap -sC -sV 192.168.1.1

# Scan all 65535 ports
nmap -p- 192.168.1.1

# Scan a network range
nmap -sn 192.168.1.0/24   # Ping sweep (host discovery only)
nmap -sV 192.168.1.0/24   # Service scan entire subnet

# Timing template (-T0 slowest, -T5 fastest/noisiest)
nmap -T4 -sV 192.168.1.1

# UDP scan common ports
nmap -sU --top-ports 100 192.168.1.1

Reading Nmap Output

• open — A service is listening and accepting connections on this port.
• closed — The port is reachable (host is up, firewall is not blocking) but no service is listening. Returns RST.
• filtered — No response received. A firewall is likely dropping probes without sending RST or ICMP Unreachable. The port state cannot be determined.
• open|filtered — Common in UDP scanning when no response is received — could be open (service ignoring probe) or filtered by firewall.

Service version strings from -sV are especially valuable: they reveal specific software and version numbers that can be cross-referenced against CVE databases for known vulnerabilities.

Traceroute is not just for performance troubleshooting. In security contexts it reveals network topology: which ISPs handle your traffic, where BGP peering occurs, and whether traffic routes through unexpected jurisdictions. BGP hijacking incidents can be detected by sudden changes in traceroute output showing your traffic routing through unrecognized ASNs. WHOIS lookups on intermediate router IPs (using tools like whois or ip-api.com) reveal the organizations operating each hop.

During security incidents, network diagnostic tools provide rapid situational awareness. Ping sweeps identify which hosts are online. Port scans reveal unexpected open services that may be backdoors or malware C2 listeners. Traceroute identifies whether traffic is being redirected to unexpected destinations. MTR during an ongoing attack reveals where traffic is being dropped and helps distinguish between network congestion and deliberate blocking.

Port scanning and network probing are legal against systems you own or have explicit written authorization to test. Scanning systems without authorization — even passively — may violate the Computer Fraud and Abuse Act (US), the Computer Misuse Act (UK), and equivalent legislation in other jurisdictions. Bug bounty programs typically specify explicitly which IP ranges are in scope. Always obtain proper authorization before scanning any systems you do not personally own. Document your authorization before beginning any assessment.

Ping, traceroute, and Nmap form the essential toolkit for understanding what is happening on a network at the packet level. Ping provides rapid reachability and latency measurement. Traceroute exposes the path and pinpoints where problems occur. MTR combines both with statistical rigor for intermittent issues. Nmap maps the attack surface of a system or network and identifies service versions for vulnerability correlation. Used together and interpreted carefully — especially when dealing with firewalled paths where asterisks and filtered states introduce ambiguity — these tools provide the ground truth about network behavior that no dashboard or alert system can substitute for.