Network Troubleshooting

Network issues are inevitable. Whether it's a misconfigured security group, a DNS failure, or a TLS certificate mismatch, having a systematic approach and knowing your tools will get you to the root cause faster.

Troubleshooting Methodology

Work up the network stack from the bottom:

1. L1 — Physical / Instance: Is the instance running? Is the network interface up?
2. L2 — Link: Is the subnet routing correctly? Is the ENI attached?
3. L3 — IP: Can you ping the gateway? Can you reach other IPs in the same VPC?
4. L4 — Transport: Is the right port open? Is the service listening?
5. L5-7 — Application: Is DNS resolving? Are TLS certs valid? Does the HTTP request succeed?

ping — ICMP Reachability

ping google.com              # test internet connectivity
ping 8.8.8.8                 # test by IP (bypasses DNS)
ping -c 4 10.0.1.10          # send exactly 4 packets
ping6 ipv6.google.com        # ping over IPv6

No response to ping doesn't always mean the host is down — firewalls often block ICMP. If HTTP works but ping doesn't, the host is up.

traceroute / tracert — Path Discovery

traceroute google.com        # Linux/macOS (uses UDP by default)
traceroute -T google.com     # use TCP (better through firewalls)
traceroute -I google.com     # use ICMP
tracert google.com           # Windows

# Example output showing hop-by-hop with RTTs:
# 1  10.0.0.1 (router)       0.5ms
# 2  72.x.x.x (ISP hop)      5.2ms
# 3  * * *                   (hop blocking ICMP — not necessarily a problem)
# 4  142.x.x.x (Google)      12.1ms

* * * means that hop is not responding to probes — often firewalls. If all hops after a certain point show * * *, that's likely where the path is blocked.

dig / nslookup — DNS Diagnostics

# Basic lookup
dig api.example.com
nslookup api.example.com

# Specific record types
dig api.example.com A
dig example.com MX
dig example.com TXT

# Short output
dig api.example.com +short

# Query a specific server
dig @8.8.8.8 api.example.com
dig @169.254.169.253 api.example.com    # query AWS VPC DNS

# Trace the resolution chain
dig api.example.com +trace

# Reverse lookup
dig -x 93.184.216.34

On AWS EC2, the VPC DNS server is at the VPC CIDR + 2 address (e.g., 10.0.0.2 for a 10.0.0.0/16 VPC, or the link-local address 169.254.169.253).

curl — HTTP/HTTPS Testing

# Basic GET
curl https://api.example.com/health

# Verbose output (shows TLS handshake, headers)
curl -v https://api.example.com

# Show only headers
curl -I https://api.example.com

# Follow redirects
curl -L http://example.com

# POST with JSON body
curl -X POST https://api.example.com/users   -H "Content-Type: application/json"   -d '{"name": "Alice"}'

# Show timing breakdown
curl -w "
DNS: %{time_namelookup}s
Connect: %{time_connect}s
TLS: %{time_appconnect}s
Total: %{time_total}s
"   -o /dev/null -s https://api.example.com

# Test with specific DNS server (bypass system DNS)
curl --resolve api.example.com:443:93.184.216.34 https://api.example.com

# Skip TLS certificate verification (use for testing only)
curl -k https://api.example.com

netstat / ss — Connections and Listening Ports

# Show all listening TCP ports
ss -tlnp
netstat -tlnp

# Show all established connections
ss -tnp state established
netstat -tnp

# Show all UDP sockets
ss -ulnp

# Check if a service is listening on port 3000
ss -tlnp | grep 3000

# On AWS EC2 — verify the app is listening:
ss -tlnp | grep LISTEN

tcpdump — Packet Capture

# Capture all traffic on eth0
tcpdump -i eth0

# Capture HTTP traffic
tcpdump -i eth0 port 80

# Capture traffic to/from a specific host
tcpdump -i eth0 host 10.0.1.10

# Save to file for analysis in Wireshark
tcpdump -i eth0 -w capture.pcap

# Read captured file
tcpdump -r capture.pcap

Common AWS Networking Issues

You've completed the Networking Basics course. These fundamentals apply directly when preparing for the AWS Certified Solutions Architect, AWS Cloud Practitioner, or any cloud networking certification.