Troubleshooting - Learning Module

Loading content...

0/228

Network Tools

The Network Engineer's Toolbox

A methodology without tools is just theory. The troubleshooting approaches we've learned become actionable through a range of diagnostic utilities—from simple command-line programs available on every operating system to sophisticated packet analyzers that reveal exactly what's happening on the wire.

The right tool for the right job:

Master carpenters don't just own hammers—they have chisels, planes, saws, and dozens of specialized tools for specific tasks. Similarly, network engineers need a complete toolkit where each tool serves a distinct purpose:

Connectivity testers tell you if you can reach a destination
Path analyzers tell you how packets travel and where they stop
Name resolution tools verify DNS is translating names correctly
Protocol analyzers reveal what data is being exchanged
Performance monitors show how well the network is performing
Configuration utilities let you examine and modify network settings

What You Will Learn

This page covers the essential network diagnostic tools organized by category. You'll learn not just how to use each tool, but when to use it, how to interpret results, and how tools combine to solve complex problems. We focus on cross-platform fundamentals that apply whether you're on Windows, Linux, or macOS.

Tool Categories Overview

Network tools can be organized into categories based on their primary function. Understanding these categories helps you quickly identify which tool to reach for when facing a specific problem.

The Troubleshooting Funnel:

As you progress through troubleshooting, you typically move from broad connectivity tests to focused protocol analysis—a funnel that narrows as you isolate the problem:

Network Diagnostic Tool Categories
Category	Purpose	Key Tools	When to Use
Connectivity Testing	Verify basic reachability	ping, Test-Connection	First step in any network issue
Path Analysis	Trace route to destination	traceroute, tracert, mtr	When ping fails or latency is high
Name Resolution	Debug DNS problems	nslookup, dig, host	When names don't resolve or resolve incorrectly
Port/Service Testing	Check if services are accessible	telnet, netcat, Test-NetConnection	When application connectivity fails
Interface Diagnostics	Examine local network config	ipconfig, ifconfig, ip	To verify local configuration
Connection State	View active connections	netstat, ss, Get-NetTCPConnection	To check what's connected to what
Routing Tables	Examine routing decisions	route, ip route, netstat -r	When packets take wrong paths
ARP/Neighbor Cache	View MAC address resolution	arp, ip neigh	For Layer 2 connectivity issues
Packet Capture	Deep protocol analysis	Wireshark, tcpdump, tshark	For complex protocol-level debugging
Bandwidth/Performance	Measure throughput	iperf3, speedtest-cli	For performance verification

Converting Mermaid diagram...

Cross-Platform Awareness

Most tools exist in some form across Windows, Linux, and macOS, but command syntax varies. We'll note platform-specific variations where relevant. The core concepts transfer across platforms even when commands differ.

Connectivity Testing with Ping

Ping is the most fundamental network diagnostic tool—so fundamental that 'can you ping it?' is often the first question in any troubleshooting session. Ping sends ICMP Echo Request messages and waits for Echo Reply responses. If replies return, basic network connectivity exists.

How Ping Works:

Your system sends an ICMP Echo Request packet to the target IP
The packet traverses the network (routers, switches, etc.)
The target receives the request and sends an ICMP Echo Reply
Your system receives the reply and measures the round-trip time (RTT)

Basic Usage:

Ping Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Basic ping (sends 4 packets by default on Windows)
ping 8.8.8.8
 
# Continuous ping (like Linux default)
ping -t 8.8.8.8
 
# Specific number of pings
ping -n 10 8.8.8.8
 
# Ping with specific packet size
ping -l 1000 8.8.8.8
 
# Set timeout (milliseconds)
ping -w 2000 8.8.8.8
 
# Force IPv4
ping -4 hostname.example.com
 
# Force IPv6
ping -6 hostname.example.com

Interpreting Ping Results:

Ping Result Interpretation Guide
Result	Meaning	Likely Causes
Reply received, low RTT (< 50ms)	Healthy - Connectivity works, latency acceptable	Normal operation
Reply received, high RTT (> 200ms)	Slow - Connectivity works but delayed	Congestion, satellite link, long distance
Reply received, variable RTT	Jitter - Inconsistent performance	Network congestion, buffer issues
Request timed out	No reply - Packet lost or host unreachable	Host down, firewall blocks ICMP, routing issue
Destination host unreachable	Routing problem - Router can't forward	No route to host, network unreachable
Destination net unreachable	Network down - Entire subnet inaccessible	Interface down, missing route
TTL expired in transit	Routing loop - Packets cycling	Misconfigured routing, loop detected
Packet needs to be fragmented	MTU issue - Packet too large	Path MTU discovery problem

Ping Can Lie

Many hosts and firewalls block ICMP. A failed ping doesn't always mean the host is unreachable—it might just block ping. Conversely, a successful ping doesn't guarantee the application is working. Always combine ping with application-layer tests.

Advanced Ping Techniques:

1. Progressive Ping Testing: Start from your local machine and ping progressively further:

ping localhost          # Test local TCP/IP stack
ping 192.168.1.1       # Test default gateway
ping 10.0.0.1          # Test core router
ping 8.8.8.8           # Test Internet reachability
ping target.example.com # Test final destination

Where ping first fails indicates the location of the problem.

2. Packet Size Testing: Large pings help detect MTU problems:

# Windows - test with 1472 bytes (1500 - 20 IP - 8 ICMP = 1472)
ping -f -l 1472 target.example.com

# Linux - same test
ping -M do -s 1472 target.example.com

If this fails but smaller packets succeed, there's an MTU issue in the path.

3. Ping Statistics: After multiple pings, examine statistics:

Minimum RTT: Best-case latency (network capacity)
Maximum RTT: Worst-case latency (congestion events)
Average RTT: Typical latency
Packet loss %: Reliability (> 1% is concerning, > 5% is problematic)

Name Resolution Tools

DNS problems are among the most common network issues. When 'the website doesn't work' but IP addresses work fine, DNS is usually the culprit. Several tools help diagnose DNS issues.

nslookup - Basic DNS Queries:

Available on Windows, Linux, and macOS, nslookup performs DNS lookups and allows you to query specific DNS servers.

nslookup Examples
Basic Usage
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Simple lookup
nslookup www.example.com
 
# Query specific DNS server
nslookup www.example.com 8.8.8.8
 
# Lookup specific record type
nslookup -type=MX example.com
nslookup -type=AAAA example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
 
# Reverse lookup (IP to name)
nslookup 8.8.8.8
 
# Interactive mode
nslookup
> server 8.8.8.8
> set type=ANY
> example.com
> exit

dig - Domain Information Groper (Linux/macOS):

dig is more powerful and provides more detailed output than nslookup. It's the preferred tool for serious DNS debugging.

dig Examples
dig Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Basic query
dig www.example.com
 
# Short answer only
dig +short www.example.com
 
# Query specific server
dig @8.8.8.8 www.example.com
 
# Query specific record types
dig example.com MX
dig example.com AAAA
dig example.com TXT
dig example.com NS
dig example.com SOA
 
# Trace delegation from root servers
dig +trace www.example.com
 
# Reverse lookup
dig -x 8.8.8.8
 
# Show all records
dig example.com ANY
 
# Check DNSSEC
dig +dnssec example.com
 
# Display query time and server used
dig www.example.com +stats

Interpreting DNS Results:

DNS Troubleshooting Scenarios
Symptom	Likely Cause	Verification
No response at all	DNS server unreachable	ping DNS server IP; try alternate DNS
NXDOMAIN (name doesn't exist)	Typo, domain expired, or record deleted	Check spelling; verify domain registration
Wrong IP returned	DNS cache poisoning or stale cache	Check authoritative server; flush local cache
Resolution works but slow	DNS server overloaded or far away	Measure query time; try closer DNS server
Works from server, not client	Client DNS configuration wrong	Check /etc/resolv.conf or network settings
MX records missing	Email DNS not configured	Check with authoritative DNS server
dig +trace fails partway	DNS delegation broken	Check NS records at parent zone

Windows DNS Utilities:

# Flush DNS cache
ipconfig /flushdns

# Display DNS cache
ipconfig /displaydns

# Register DNS (force re-registration)
ipconfig /registerdns

# Resolve-DnsName (PowerShell)
Resolve-DnsName www.example.com
Resolve-DnsName -Name example.com -Type MX
Resolve-DnsName -Name example.com -Server 8.8.8.8

Checking Local DNS Configuration:

# Linux - check resolver configuration
cat /etc/resolv.conf

# Check systemd-resolved status (modern Linux)
resolvectl status

# macOS - check DNS servers
scutil --dns

# Windows - check DNS servers
ipconfig /all | findstr DNS

The +trace Technique

dig +trace is invaluable for complex DNS issues. It shows the entire resolution path from root servers to authoritative servers, revealing exactly where delegation breaks or incorrect records appear. Use it when standard lookups don't reveal the problem.

Interface and Configuration Tools

Before testing connectivity to remote hosts, verify your local network configuration is correct. These tools show IP addresses, subnet masks, gateways, and interface status.

ipconfig (Windows):

Network Configuration Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Basic configuration
ipconfig
 
# Detailed configuration (includes DNS, DHCP info)
ipconfig /all
 
# Release DHCP lease
ipconfig /release
 
# Renew DHCP lease
ipconfig /renew
 
# Flush DNS cache
ipconfig /flushdns
 
# Show specific adapter
ipconfig /all | findstr "Ethernet"
 
# PowerShell equivalents
Get-NetIPConfiguration
Get-NetIPAddress
Get-NetAdapter
Get-DnsClientServerAddress

What to Look For in Configuration Output:

Configuration Checklist

•IP Address — Is it valid for this network? Is it APIPA (169.254.x.x) indicating DHCP failure?
•Subnet Mask — Does it match the network design? Mismatched masks cause reachability issues.
•Default Gateway — Is one configured? Is it the correct router? Can you ping it?
•DNS Servers — Are they configured? Are they reachable? Are they correct for this network?
•Interface Status — Is the interface up? Is there a valid link?
•MAC Address — Useful for switch port identification and ARP troubleshooting.
•MTU — Typically 1500 for Ethernet. Non-standard MTU can cause fragmentation issues.
•DHCP Enabled — If yes, when does the lease expire? When was it obtained?

Viewing Connection State with netstat/ss:

These tools show active network connections, listening ports, and network statistics.

Connection State Commands

# All connections with addresses
netstat -an
 
# Show process ID for each connection
netstat -ano
 
# Show process names (admin)
netstat -anb
 
# TCP connections only
netstat -ant
 
# UDP connections only
netstat -anu
 
# Statistics
netstat -s
 
# Routing table
netstat -r
 
# PowerShell alternatives
Get-NetTCPConnection
Get-NetTCPConnection -State Listen
Get-NetUDPEndpoint

ss vs netstat

On modern Linux systems, ss (socket statistics) has replaced netstat. It's faster and provides more detailed information. However, netstat is still commonly used and available on most systems.

Port and Service Testing

When you can ping a server but the application doesn't work, the problem is often at the transport layer. Port and service testing tools verify that specific TCP/UDP ports are reachable and services are responding.

telnet - Classic TCP Port Testing:

Though telnet is primarily a remote terminal protocol, it's commonly used simply to test if a TCP port is open:

Port Testing Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
# Test if port 80 is open
telnet example.com 80
 
# If connection successful, you'll see:
# Connected to example.com.
# Escape character is '^]'.
 
# If connection fails, you'll see:
# Trying 93.184.216.34...
# telnet: Unable to connect to remote host: Connection refused
 
# On Windows, telnet may need to be enabled:
# Control Panel > Programs > Turn Windows features on/off > telnet Client

Port Test Result Interpretation
Result	Meaning	Common Causes
Connected / Succeeded	Port open, service accepting connections	Normal operation
Connection refused	Port closed (nothing listening) OR firewall actively rejecting	Service not running, wrong port
Connection timed out	Packets not reaching destination OR silently dropped	Firewall dropping traffic, routing issue
No route to host	Cannot reach the IP address at all	Network unreachable, routing problem
Host unreachable	ICMP response: host not accessible	Host down or ARP failure

curl and wget - Application Layer Testing:

For HTTP/HTTPS services, curl and wget test not just port accessibility but actual protocol functionality:

HTTP Testing
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Basic HTTP request
curl http://example.com
 
# Show headers
curl -I http://example.com
curl -v http://example.com
 
# Show only HTTP status code
curl -o /dev/null -s -w "%{http_code}\n" http://example.com
 
# Test HTTPS with certificate info
curl -vI https://example.com
 
# Ignore certificate errors (testing only!)
curl -k https://self-signed.example.com
 
# Specify request timeout
curl --connect-timeout 5 http://example.com
 
# Test specific host header (virtual hosting)
curl -H "Host: example.com" http://192.168.1.100
 
# Follow redirects
curl -L http://example.com

Layer by Layer Testing

When testing a web server, work up the layers: (1) ping IP - basic reachability, (2) telnet/nc port 80/443 - TCP connectivity, (3) curl HTTP - application layer. If curl fails but telnet succeeds, the issue is application-level (service configuration, web server error).

Routing and ARP Tools

When connectivity problems aren't explained by simple reachability tests, examining routing tables and ARP caches can reveal the underlying issue.

Viewing the Routing Table:

The routing table determines where packets are sent. Incorrect routes cause packets to go to the wrong place (or nowhere).

Routing Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Display routing table
route print
 
# Show only IPv4 routes
route print -4
 
# Show only IPv6 routes
route print -6
 
# Add a route (admin required)
route add 10.10.0.0 mask 255.255.0.0 192.168.1.1
 
# Delete a route
route delete 10.10.0.0
 
# Make route persistent across reboots
route add -p 10.10.0.0 mask 255.255.0.0 192.168.1.1
 
# PowerShell alternatives
Get-NetRoute
Get-NetRoute -DestinationPrefix "0.0.0.0/0"  # Default gateway

Reading the Routing Table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    100    0        0 eth0
10.0.0.0        10.0.0.1        255.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

Destination 0.0.0.0 = Default route (used when no specific route matches)
Gateway = Next hop router (0.0.0.0 means directly connected)
Flags: U = Up, G = Gateway (not directly connected), H = Host route
Iface = Which interface to use

Common routing problems:

No default gateway → Can't reach external networks
Wrong gateway → Packets sent to wrong router
Missing specific route → Network unreachable for that destination
Conflicting routes → Unpredictable behavior based on metric

ARP Cache - Layer 2 Resolution:

ARP (Address Resolution Protocol) maps IP addresses to MAC addresses. ARP problems prevent local network communication even when IP configuration is correct.

ARP Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Display ARP cache
arp -a
 
# Delete entire ARP cache
arp -d
 
# Delete specific entry
arp -d 192.168.1.5
 
# Add static entry (rarely needed)
arp -s 192.168.1.5 00-11-22-33-44-55
 
# PowerShell alternatives
Get-NetNeighbor
Get-NetNeighbor -IPAddress 192.168.1.1

ARP State Flags
State	Meaning
REACHABLE	Entry recently confirmed valid through traffic
STALE	Entry hasn't been verified recently (may still work)
DELAY	Waiting a moment before sending ARP verification
PROBE	Currently sending ARP request to verify
FAILED	ARP resolution failed - host didn't respond
PERMANENT	Statically configured, won't expire

ARP Issues Cause Bizarre Problems

Stale or incorrect ARP entries can cause intermittent connectivity that's hard to diagnose. If you have strange local network issues (can't reach a local host, or traffic going to wrong device), clear the ARP cache and let it rebuild.

Protocol Analyzers Introduction

When simpler tools don't reveal the problem, protocol analyzers (packet sniffers/capture tools) show exactly what's happening on the wire. They capture network traffic and decode protocol details, revealing what's actually being transmitted.

Wireshark - The Industry Standard GUI Analyzer:

Wireshark is the most widely used protocol analyzer, offering deep protocol decoding and powerful filtering.

Wireshark Capabilities

•Live Capture — Capture packets as they traverse the interface in real-time
•Protocol Decoding — Decode hundreds of protocols (TCP, HTTP, DNS, TLS, and more)
•Display Filters — Filter captured traffic by any field (IP, port, protocol, content)
•Follow Streams — Reconstruct TCP conversations or HTTP sessions
•Statistics — Protocol hierarchies, conversation lists, I/O graphs
•Export — Export packets in various formats, extract files from captures

tcpdump/tshark - Command-Line Capture:

For servers without GUI or remote troubleshooting, command-line tools are essential.

Packet Capture Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# Basic capture on interface
sudo tcpdump -i eth0
 
# Capture with more detail
sudo tcpdump -i eth0 -nn -v
 
# Filter by host
sudo tcpdump -i eth0 host 192.168.1.100
 
# Filter by port
sudo tcpdump -i eth0 port 80
sudo tcpdump -i eth0 port 443 or port 80
 
# Filter by protocol
sudo tcpdump -i eth0 icmp
sudo tcpdump -i eth0 tcp
sudo tcpdump -i eth0 udp
 
# Save to file for Wireshark analysis
sudo tcpdump -i eth0 -w capture.pcap
 
# Read from file
tcpdump -r capture.pcap
 
# Capture only first 100 packets
sudo tcpdump -i eth0 -c 100
 
# Show packet contents in ASCII
sudo tcpdump -i eth0 -A
 
# Show packet contents in hex and ASCII
sudo tcpdump -i eth0 -XX

Common Capture Filter Expressions:

Filter	Meaning
`host 192.168.1.1`	Traffic to/from this IP
`src host 192.168.1.1`	Traffic FROM this IP only
`dst host 192.168.1.1`	Traffic TO this IP only
`port 80`	Traffic on port 80 (either direction)
`tcp port 443`	TCP traffic on port 443
`net 192.168.1.0/24`	Traffic to/from this subnet
`icmp`	ICMP traffic only
`not port 22`	Exclude SSH traffic
`host A and host B`	Traffic between two hosts

We'll explore Wireshark and packet capture in much more detail in a dedicated section.

Capture Rights

Packet capture typically requires root/administrator privileges. On Linux, you can also add your user to the 'wireshark' group. Be aware of legal and policy implications—capturing network traffic may be regulated in your organization.

Summary: Your Diagnostic Toolkit

We've surveyed the essential tools in the network engineer's toolkit. Let's consolidate when to use each category:

Network Tool Quick Reference
Problem Type	First Tool	If Needed
'Can't reach anything'	ping gateway, ping localhost	ipconfig/ip addr to check config
'Website doesn't work'	nslookup domain	dig +trace, check DNS servers
'Slow connection'	ping with timing	traceroute, mtr for path analysis
'Application won't connect'	telnet/nc to port	curl for HTTP, check firewall
'Intermittent issues'	mtr (continuous trace)	Wireshark for packet analysis
'Routing problems'	route/ip route	Check default gateway, specific routes
'Local network issues'	arp -a / ip neigh	Check switch, cables, VLANs
'Don't know what's wrong'	Wireshark packet capture	Analyze at protocol level

Key Takeaways

•Tools are organized by OSI layer — Ping for Layer 3, telnet for Layer 4, curl for Layer 7
•Start simple, escalate complexity — Use ping before Wireshark; basic tools often reveal the issue
•Cross-platform awareness — Know the equivalent commands on Windows, Linux, and macOS
•Combine tools systematically — Progressive testing from local to remote isolates problems
•Protocol analyzers are the ultimate tool — When other tools fail, packets don't lie
•Practice makes proficiency — Regularly use these tools, even when not troubleshooting

What's Next:

Now that we've surveyed the toolkit, we'll dive deep into two of the most fundamental tools: ping and traceroute. The next page covers their operation in detail, advanced techniques, and how to interpret results like an expert.

Page Complete

You now have a comprehensive overview of network diagnostic tools organized by function. Each tool serves a specific purpose in the troubleshooting process. Next, we'll deep-dive into ping and traceroute—mastering these fundamental tools that form the backbone of network diagnosis.