109.3 Basic Network Troubleshooting

Weight: 4

Goal: Troubleshoot network problems on a Linux host, using the standard set of diagnostic tools.

This objective is all about commands. Memorize what each tool does and how to read its output.

1. A Methodical Approach

When something doesn’t work on the network, work bottom up through the stack:

  1. Is the link up? (Cable plugged in, Wi-Fi associated.) → ip link
  2. Does the interface have an IP address? → ip addr
  3. Is there a default route? → ip route
  4. Can I reach the gateway? → ping <gateway>
  5. Can I reach a public host by IP? → ping 8.8.8.8
  6. Can I reach a host by name? → ping example.com
  7. Is the service running on the right port? → ss, nc

If step 5 works but step 6 doesn’t, it’s a DNS problem, not a network problem. Knowing this distinction is exam-worthy.

2. Showing Interfaces and Addresses

ip — the modern one

ip link                              # interfaces, MAC addresses, up/down state
ip link show eth0
ip link set eth0 up                  # bring an interface up
ip link set eth0 down                # bring it down

ip addr                              # interfaces with their IP addresses
ip addr show eth0
ip -4 addr                           # IPv4 only
ip -6 addr                           # IPv6 only

ifconfig — the legacy one

ifconfig                             # all up interfaces
ifconfig -a                          # all interfaces, including down
ifconfig eth0                        # one interface
ifconfig eth0 up
ifconfig eth0 down

ifconfig comes from the net-tools package. It is deprecated but still on the exam.

What to look for in the output

3. The Routing Table

A host has a routing table that decides where to send each outgoing packet.

Show routes

ip route                             # modern
route -n                             # legacy (-n disables DNS lookups)
netstat -rn                          # legacy alternative

Typical output of ip route:

default via 192.168.1.1 dev eth0 proto dhcp
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

Read it as:

No default route = no internet

If ip route does not contain a default line, you cannot reach anything outside the local subnet, no matter what else is configured.

Adding and removing routes (runtime)

ip route add default via 192.168.1.1
ip route add 10.0.0.0/8 via 192.168.1.254
ip route del default

4. Reachability: ping

ping host                            # send ICMP echo requests indefinitely
ping -c 4 host                       # send only 4 packets
ping -i 0.5 host                     # interval between packets (seconds)
ping -W 2 host                       # timeout per reply (seconds)
ping -s 1400 host                    # payload size (test fragmentation/MTU)
ping6 host                           # IPv6 version (or use `ping -6`)

Reading ping output

PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=15.2 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=14.9 ms
...
4 packets transmitted, 4 packets received, 0.0% packet loss

Common diagnoses

Many internet hosts block ICMP for security, so a failed ping is not always a failure of connectivity.

5. Tracing the Path: traceroute, tracepath, mtr

These tools show which routers a packet passes through to reach a destination — by sending packets with increasing TTL values and waiting for the “Time Exceeded” ICMP reply from each hop.

traceroute example.com
traceroute -n example.com           # don't resolve hop names (faster)
traceroute -I example.com           # use ICMP instead of UDP
traceroute -T -p 80 example.com     # use TCP to port 80 (firewalls love TCP/80)

tracepath example.com               # similar, no root needed, also shows MTU
mtr example.com                     # combined traceroute + continuous ping

Each line is one hop. * * * means no response from that router — it could be filtering ICMP, doesn’t matter as long as a later hop replies.

6. DNS Lookups: host, dig, getent

When ping <hostname> fails but ping <ip> works, suspect DNS.

host — short and friendly

host example.com
# example.com has address 93.184.216.34

host 93.184.216.34                   # reverse lookup
# 34.216.184.93.in-addr.arpa domain name pointer ...

host -t MX example.com               # query a specific record type
host -t NS example.com
host -t TXT example.com

host example.com 8.8.8.8             # query a specific DNS server

dig — detailed

dig example.com                      # full A-record query with timing
dig example.com MX                   # specific type
dig @8.8.8.8 example.com             # query a specific server
dig -x 93.184.216.34                 # reverse lookup
dig +short example.com               # just the answer values
dig +trace example.com               # follow the delegation chain from root

dig output includes sections: QUESTION, ANSWER, AUTHORITY, ADDITIONAL. The ANSWER is what you asked for.

getent hosts NAME — what the system actually resolves

getent hosts example.com
getent ahosts example.com

This is important because host and dig go straight to DNS, while getent goes through /etc/nsswitch.conf — so it also checks /etc/hosts and any other configured source. If ping and getent agree but dig disagrees, the answer is coming from /etc/hosts, not DNS.

nslookup (legacy, still on the exam)

nslookup example.com
nslookup example.com 8.8.8.8

Older but still common. host and dig are preferred today.

7. Listening Ports and Active Connections: ss and netstat

These show what’s running and connected on the local machine — invaluable when “the service isn’t responding.”

ss — modern, fast

ss                                   # all established connections
ss -t                                # TCP only
ss -u                                # UDP only
ss -l                                # listening sockets only
ss -n                                # numeric ports (no DNS lookup)
ss -p                                # show the process owning each socket

ss -tuln                             # the classic one: TCP+UDP, listening, numeric
ss -tunap                            # TCP+UDP, all states, numeric, with processes

-tuln is the typical “what is this machine listening on?” command.

netstat — legacy, similar usage

netstat -tuln                        # same idea
netstat -rn                          # routing table (same as `ip route`)
netstat -i                           # per-interface statistics
netstat -p                           # with process info (needs root for others)

netstat is part of net-tools and is deprecated. The exam still expects you to know it.

Reading the output

Proto Recv-Q Send-Q Local Address     Foreign Address    State
tcp        0      0 0.0.0.0:22        0.0.0.0:*          LISTEN
tcp        0      0 192.168.1.10:22   192.168.1.20:51820 ESTABLISHED

8. Testing Ports and Sending Data: nc (netcat)

nc (or netcat) is a Swiss-army knife. For troubleshooting, the main use is “is this TCP/UDP port open?”

nc -zv host 22                       # test TCP port 22 (z = scan, v = verbose)
nc -zv host 80 443                   # multiple ports
nc -zvu host 53                      # test a UDP port

# Send something into a port
echo "GET / HTTP/1.0" | nc example.com 80

# Listen on a port (handy for ad-hoc testing)
nc -l 12345

nc -zv host port is the standard one-liner to check whether a port is reachable from your machine.

9. Per-User and Diagnostic Files

/var/log/syslog (Debian) or /var/log/messages (RHEL) and the systemd journal contain useful entries when:

journalctl -u NetworkManager
dmesg | grep -i eth0

10. Putting It All Together: A Troubleshooting Cheat Sheet

Symptom Command to try What it tells you
Nothing works ip link Is the interface up at all?
Interface up but no traffic ip addr Do you have an IP?
Have IP, can’t reach outside ip route Is there a default route?
Have route, can’t ping gateway ping <gateway> Layer 2 / cable / Wi-Fi issue.
Can ping gateway, not internet ping 8.8.8.8 Is upstream routing working?
Can ping IPs, not names host example.com, cat /etc/resolv.conf DNS problem.
Service unreachable from another machine ss -tuln, nc -zv host port, firewall Is the daemon actually listening? On the right address? Is a firewall blocking?
Slow connection traceroute, mtr Where in the path is the loss/latency?

11. Quick Reference for the Exam

Commands to know cold:

Concepts:

12. Likely Exam Questions (Self-Check)

  1. What command shows the routing table on a modern Linux system? ip route (or ip r). Legacy alternatives: route -n, netstat -rn.

  2. ping example.com fails but ping 93.184.216.34 works. What is the most likely cause? A DNS problem — name resolution is failing. Check /etc/resolv.conf, /etc/nsswitch.conf, and try host example.com or dig example.com.

  3. Which command shows the path packets take to a remote host? traceroute (or tracepath, or mtr for a continuous variant).

  4. You want to list all TCP and UDP ports currently being listened on, with numeric port numbers. What command do you use? ss -tuln (or netstat -tuln).

  5. What does the address 0.0.0.0:22 in ss output mean? The service is listening for TCP connections on port 22, on every interface.

  6. Which command tests whether TCP port 443 is open on host example.com? nc -zv example.com 443.

  7. What is the difference between dig and getent hosts? dig queries DNS directly. getent hosts uses the system resolver, which respects /etc/nsswitch.conf and therefore consults /etc/hosts first.

  8. What is the modern replacement for ifconfig? The ip command from the iproute2 package — ip link, ip addr, ip route.

  9. How do you bring eth0 up at runtime using ip? ip link set eth0 up.

  10. How do you add an IP address to eth0 at runtime? ip addr add 192.168.1.10/24 dev eth0.

  11. What protocol does ping use? ICMP (Echo Request / Echo Reply).

  12. What does the -n flag do on netstat, route, or ss? Disables name (DNS) and service-name lookups — output is numeric only. Faster and avoids confusing failures from a broken DNS.

  13. How do you query the MX records for example.com using host and using dig? host -t MX example.com and dig example.com MX.

  14. You can ping the gateway but not the public internet. What do you check next? Whether the gateway itself has connectivity (likely not your problem), but on your side, confirm ip route shows a default route via that gateway and traceroute 8.8.8.8 to see where packets stop.

  15. What’s the difference between traceroute and mtr? traceroute traces the path once. mtr runs continuously, combining traceroute with ongoing ping statistics for each hop.