LFCA 121 🐧 Real-World Scenario — Basic Network Diagnostics
A network problem is a mystery with layers. The user reports that “the internet is down.” The application logs show connection timeouts. The monitoring system fires an alert about packet loss. Each of these symptoms is real, but none of them tells you where the problem actually lives. Is it the cable? The interface? The route? DNS? The firewall? The remote service? Without a systematic approach, you end up restarting things at random, hoping the symptom disappears.
This chapter walks through basic network diagnostics as a structured investigation. You will learn the layered model that guides the diagnostic sequence, the specific commands that test each layer, and how to interpret their output to narrow the problem to a specific point in the path between your machine and the service it is trying to reach. The scenario is a typical production incident: a server that cannot reach an external API, with the cause unknown.
By the end, you will have a repeatable diagnostic procedure that starts at the physical layer and moves upward, testing one assumption at a time until the failure point is isolated.
Key point: Network diagnostics works from the bottom up. Confirm the link is up, then the IP is configured, then the gateway is reachable, then DNS resolves, then the route exists, then the port is open, and finally the application responds. Skipping layers wastes time on the wrong hypothesis.
Why basic network diagnostics matters
The layered model. Network communication is built in layers. The physical layer carries electrical signals. The data link layer frames those signals into packets. The network layer addresses and routes those packets. The transport layer establishes connections between ports. The application layer sends actual data. A failure at any layer produces symptoms that look similar from the user’s perspective—the connection does not work—but requires different diagnostic tools . The layered model tells you where to look first: always at the bottom, because a problem at a lower layer makes all higher layers fail regardless of their own health.
The blame problem. When an application cannot reach a service, the instinct is to blame the application. When a website is slow, the instinct is to blame the website. Both instincts are often wrong. The cause may be a saturated interface, a misconfigured route, a DNS server that has stopped responding, or a firewall rule that silently drops packets. Without diagnostics, you cannot distinguish between these causes. You cannot fix what you have not identified.
The escalation problem. When a network problem is escalated to a network team or a cloud provider, the first question is always the same: “What have you already tried?” A structured investigation—even one that has not yet found the answer—demonstrates that you have ruled out the obvious causes. It provides the negative results that narrow the search space for the next person. An escalation that says “the network is down” is useless. An escalation that says “the interface is up, the gateway responds, DNS resolves, but TCP connections to port 443 time out” is actionable.
The intermittent problem. Some network problems are not constant. A link that drops under load. A DNS server that responds slowly. A route that fails over incorrectly. These are the hardest to diagnose because the symptom is absent when you look for it. The diagnostic approach for intermittent problems is different: you set up continuous monitoring that logs state at the moment of failure, then analyze the logs after the fact.
a. Layer one and two: link and interface
The first question is whether the network interface is up and has an IP address. This is the physical and data link layer. If the interface is down, nothing above it can work.
ip link showThe ip link show command lists all network interfaces and their states. The output shows UP or DOWN for each interface, along with the MAC address and other link-layer details. An interface that is DOWN will not carry traffic regardless of its configuration .
ip addr showThe ip addr show command adds IP address information to the interface state. An interface can be UP but have no IP address, which means it cannot participate in IP networking. The output shows the assigned addresses, their subnets, and their scope .
ip -s link show eth0The -s flag adds statistics: packets received, packets transmitted, errors, and drops. A steadily increasing error or drop count indicates a physical layer problem—a bad cable, a failing NIC, or a switch port that is dropping frames .
ethtool eth0The ethtool command shows link speed, duplex mode, and whether the link is detected. It also shows whether the interface supports and has negotiated the expected speed. A 1 Gbps interface that has negotiated 100 Mbps indicates a cable or switch port problem .
If the interface is down, the fix depends on the cause. A cable that has been unplugged, a switch port that has been disabled, or an interface that has been administratively shut down all produce the same symptom. The ip link set eth0 up command brings an interface up administratively, but if the physical link is not present, the interface remains DOWN despite the command.
b. Layer three: IP, gateway, and routing
With the interface up and an IP address assigned, the next layer is IP connectivity. The first test is whether the machine can reach its default gateway.
ip route showThe ip route show command lists the routing table. The default via line identifies the gateway. If there is no default route, the machine can only reach hosts on its local subnet .
ping -c 3 192.168.1.1The ping command sends ICMP echo requests to the gateway. If the gateway responds, the local link and the gateway’s reachability are confirmed. If it does not, the problem is at the link layer or the gateway itself .
ping -c 3 8.8.8.8If the gateway responds but an external IP does not, the problem is beyond the local network—possibly a routing issue at the gateway, an ISP problem, or a firewall blocking ICMP. Using an IP address rather than a hostname removes DNS from the equation at this stage .
traceroute 8.8.8.8The traceroute command shows the path packets take to reach a destination. It identifies where the path breaks or slows down. The output lists each hop, with the response time for three probes. A hop that shows * * * indicates that the router at that hop is not responding to the probe, which may be normal (some routers block ICMP) or may indicate a problem .
The mtr command combines ping and traceroute. It runs continuously, showing the packet loss and latency for each hop. A hop with 100% loss that is followed by responsive hops is likely a router that blocks ICMP, not a failure. A hop with partial loss that propagates to subsequent hops indicates a problem at that hop.
c. Layers four through seven: DNS, ports, and services
DNS is the first thing to test at the application layer. A hostname that does not resolve produces the same symptom as a server that is down, but the fix is entirely different.
dig example.comThe dig command queries DNS directly. It shows the resolved IP address, the TTL, and the server that provided the answer. If the resolution fails, the problem is in /etc/resolv.conf or the DNS server configuration. If it succeeds, the hostname is resolving correctly .
cat /etc/resolv.confThe /etc/resolv.conf file lists the DNS servers the system queries. A missing or incorrect nameserver entry causes all hostname resolution to fail. On systemd-based distributions, this file may be managed by systemd-resolved and should not be edited directly .
Once DNS resolves, the next test is whether the port is open and the service is responding.
nc -zv example.com 443The nc (netcat) command with -z tests whether a TCP port is open. The -v flag produces verbose output. If the connection succeeds, the port is open and the service is listening. If it fails, the service may not be running, or a firewall may be blocking the port .
curl -v https://example.comThe curl -v command performs an HTTP request and shows the full exchange: DNS resolution, TCP connection, TLS handshake, HTTP request, and HTTP response. It identifies the exact point at which the transaction fails. A failure after “Connected to” but before “TLS handshake” indicates a TLS problem. A failure after “TLS handshake” but before the HTTP response indicates an application-level issue .
ss -tulpn | grep :443On the server side, the ss command shows listening ports and the processes that own them. If the service should be listening on port 443 but is not, the service has not started or is bound to a different port .
tcpdump -i eth0 -n port 443The tcpdump command captures packets on the interface. It is the most direct way to see whether packets are leaving the machine and whether responses are coming back. A connection attempt with outbound SYN packets but no SYN-ACK responses indicates that the packets are being dropped—by a firewall, a routing issue, or a server that is not listening .
Complete Example Session
# ============================================
# PART 1: INTERFACE STATE
# ============================================
ip link show
# Check: is the interface UP?# ============================================
# PART 2: IP ADDRESS
# ============================================
ip addr show
# Check: does the interface have an IP?# ============================================
# PART 3: INTERFACE STATISTICS
# ============================================
ip -s link show eth0
# Check: are errors or drops increasing?# ============================================
# PART 4: ROUTING TABLE
# ============================================
ip route show
# Check: is there a default route?# ============================================
# PART 5: GATEWAY REACHABILITY
# ============================================
ping -c 3 $(ip route | grep default | awk '{print $3}')
# Check: does the gateway respond?# ============================================
# PART 6: EXTERNAL IP REACHABILITY
# ============================================
ping -c 3 8.8.8.8
# Check: can we reach an external IP?# ============================================
# PART 7: PATH TRACING
# ============================================
traceroute 8.8.8.8
# Check: where does the path break?# ============================================
# PART 8: DNS RESOLUTION
# ============================================
dig example.com
cat /etc/resolv.conf
# Check: does the hostname resolve?# ============================================
# PART 9: PORT CONNECTIVITY
# ============================================
nc -zv example.com 443
curl -v https://example.com
# Check: is the port open and the service responding?# ============================================
# PART 10: PACKET CAPTURE
# ============================================
tcpdump -i eth0 -n port 443 -c 20
# Check: are packets leaving and responses arriving?The ten parts covered interface state, IP address, interface statistics, routing table, gateway reachability, external IP reachability, path tracing, DNS resolution, port connectivity, and packet capture.
Quick Reference
Diagnostic Layers
| Layer | Test | Command |
|---|---|---|
| Link | Interface up? | ip link show |
| Network | IP assigned? | ip addr show |
| Link errors | Errors/drops? | ip -s link show |
| Routing | Default route? | ip route show |
| Gateway | Reachable? | ping gateway |
| External | Reachable? | ping 8.8.8.8 |
| Path | Where breaks? | traceroute |
| DNS | Resolves? | dig |
| Port | Open? | nc -zv |
| Service | Responds? | curl -v |
| Packets | Leaving/arriving? | tcpdump |
Common Commands
| Command | Purpose |
|---|---|
ip link show | Interface state |
ip addr show | IP addresses |
ip route show | Routing table |
ip -s link show | Interface statistics |
ethtool eth0 | Link speed and duplex |
ping | ICMP reachability |
traceroute | Path to destination |
mtr | Continuous path monitoring |
dig | DNS resolution |
nc -zv | Port connectivity |
curl -v | Full HTTP exchange |
ss -tulpn | Listening ports |
tcpdump | Packet capture |
Interpreting Results
| Symptom | Likely Layer |
|---|---|
| Interface DOWN | Physical or link |
| No IP address | Configuration |
| Gateway unreachable | Link or local network |
| External IP unreachable | Routing or gateway |
| Hostname fails, IP works | DNS |
| Port closed | Service or firewall |
| SYN sent, no SYN-ACK | Firewall or server |
| TLS handshake fails | Certificate or TLS config |
Best Practices
✅ Do This:
# Start at the bottom of the stack
ip link show && ip addr show # ✅
# Test by IP before testing by hostname
ping 8.8.8.8 && dig example.com # ✅
# Use traceroute to find the break
traceroute 8.8.8.8 # ✅
# Test the specific port
nc -zv example.com 443 # ✅
# Use curl -v for HTTP diagnostics
curl -v https://example.com # ✅
# Check packet flow with tcpdump
tcpdump -i eth0 -n port 443 # ✅
# Document findings for escalation
# (interface up, gateway responds, DNS fails) # ✅❌ Don’t Do This:
# Don't restart the network stack first
systemctl restart networking # ❌
# Don't test by hostname before testing by IP
ping example.com # ⚠️ (DNS may fail)
# Don't assume the application is at fault
# (check the network layer first) # ❌
# Don't ignore interface statistics
# (errors indicate physical problems) # ❌
# Don't use ping alone to diagnose
# (ICMP may be blocked while TCP works) # ⚠️
# Don't skip the firewall check
ss -tulpn && iptables -L -n # ✅Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Testing hostname before IP | DNS failure masquerades as network failure | Test IP first |
| Ignoring interface statistics | Errors indicate physical issues | Check ip -s link |
| Assuming ping works | ICMP may be blocked | Test TCP ports directly |
| Missing default route | No gateway configured | Check ip route |
| Wrong DNS server | /etc/resolv.conf misconfigured | Verify nameservers |
| Firewall blocking silently | Packets dropped, no response | Check firewall rules |
| Testing wrong port | Service on different port | Verify with ss -tulpn |
Real-World Examples
1. Interface Down
ip link show
# eth0: <BROADCAST,MULTICAST> state DOWN
sudo ip link set eth0 up2. No IP Address
ip addr show
# eth0: no inet address
sudo dhclient eth03. Gateway Unreachable
ping -c 3 192.168.1.1
# Request timeout
ip route show4. DNS Failure
dig example.com
# connection timed out
cat /etc/resolv.conf5. Port Closed
nc -zv example.com 443
# Connection refused
ss -tulpn | grep :4436. Firewall Blocking
tcpdump -i eth0 -n port 443
# SYN sent, no SYN-ACK
sudo iptables -L -n | grep 4437. Route Missing
ip route show
# no default route
sudo ip route add default via 192.168.1.18. Interface Errors
ip -s link show eth0
# RX errors: 1234
ethtool eth09. TLS Failure
curl -v https://example.com
# SSL certificate problem
openssl s_client -connect example.com:44310. Packet Capture
tcpdump -i eth0 -n host 8.8.8.8
# Observe request/responseVisual
The Diagnostic Funnel
┌─────────────────────────────────────────────────────────────┐
│ NETWORK DIAGNOSTIC FUNNEL │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LAYER 1-2: LINK AND INTERFACE │ │
│ │ ip link show, ip addr show, ip -s link show │ │
│ │ → Is the interface UP with an IP? │ │
│ └─────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LAYER 3: IP AND ROUTING │ │
│ │ ip route show, ping gateway, ping 8.8.8.8 │ │
│ │ → Can we reach the gateway and external IPs? │ │
│ └─────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LAYER 3.5: PATH │ │
│ │ traceroute, mtr │ │
│ │ → Where does the path break? │ │
│ └─────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LAYER 7: DNS │ │
│ │ dig, cat /etc/resolv.conf │ │
│ │ → Does the hostname resolve? │ │
│ └─────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LAYER 4: PORTS │ │
│ │ nc -zv, ss -tulpn │ │
│ │ → Is the port open? │ │
│ └─────────────────────┬───────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LAYER 7: APPLICATION │ │
│ │ curl -v, tcpdump │ │
│ │ → Does the service respond? │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Layer-by-Layer Decision Tree
┌─────────────────────────────────────────────────────────────┐
│ CONNECTION FAILS — WHERE IS THE PROBLEM? │
│ │
│ ip link show → interface DOWN? │
│ ├── YES ──▶ Physical layer problem │
│ │ Check cable, switch port, NIC │
│ └── NO │
│ │ │
│ ▼ │
│ ip addr show → no IP? │
│ ├── YES ──▶ Configuration problem │
│ │ Check DHCP, static config │
│ └── NO │
│ │ │
│ ▼ │
│ ping gateway → no response? │
│ ├── YES ──▶ Link or gateway problem │
│ └── NO │
│ │ │
│ ▼ │
│ ping 8.8.8.8 → no response? │
│ ├── YES ──▶ Routing or upstream problem │
│ └── NO │
│ │ │
│ ▼ │
│ dig hostname → fails? │
│ ├── YES ──▶ DNS problem │
│ │ Check /etc/resolv.conf │
│ └── NO │
│ │ │
│ ▼ │
│ nc -zv host port → fails? │
│ ├── YES ──▶ Service or firewall problem │
│ └── NO ──▶ Service responds, check application │
│ │
└─────────────────────────────────────────────────────────────┘Packet Flow Analysis
┌─────────────────────────────────────────────────────────────┐
│ TCP CONNECTION IN Tcpdump │
│ │
│ Successful connection: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 10:00:01 client → server SYN │ │
│ │ 10:00:02 server → client SYN-ACK │ │
│ │ 10:00:02 client → server ACK │ │
│ │ 10:00:02 client → server TLS ClientHello │ │
│ │ ... │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Firewall blocking: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 10:00:01 client → server SYN │ │
│ │ 10:00:03 client → server SYN (retransmit) │ │
│ │ 10:00:07 client → server SYN (retransmit) │ │
│ │ (no SYN-ACK from server) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Service not listening: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 10:00:01 client → server SYN │ │
│ │ 10:00:01 server → client RST │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Diagnostic Commands by Layer
┌─────────────────────────────────────────────────────────────┐
│ LAYER 2 │
│ ip link show, ip -s link show, ethtool │
│ │
│ LAYER 3 │
│ ip addr show, ip route show, ping, traceroute, mtr │
│ │
│ LAYER 4 │
│ ss -tulpn, nc -zv, tcpdump │
│ │
│ LAYER 7 │
│ dig, curl -v, openssl s_client │
│ │
└─────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| First check | ip link show |
| Second check | ip addr show |
| Third check | ip route show |
| Gateway test | ping gateway |
| External test | ping 8.8.8.8 |
| Path test | traceroute, mtr |
| DNS test | dig, cat /etc/resolv.conf |
| Port test | nc -zv, ss -tulpn |
| Service test | curl -v |
| Packet capture | tcpdump |
| Principle | Bottom up, one layer at a time |
Key takeaways:
- Network diagnostics works from the bottom up. Start at the link layer and move upward. A problem at a lower layer makes all higher layers fail regardless of their own health. Testing the application first wastes time on the wrong hypothesis.
- The interface must be up and have an IP.
ip link showconfirms the link state.ip addr showconfirms IP configuration. Both are prerequisites for any higher-layer connectivity. - The gateway must be reachable before external hosts are.
pingthe default gateway first. If the gateway does not respond, the problem is local. If it does, the problem is beyond it. - Test by IP before testing by hostname. A DNS failure and a network failure produce similar symptoms. Using an IP address removes DNS from the equation and isolates the layer.
- DNS is a separate layer.
digqueries DNS directly. If DNS fails, the problem is in/etc/resolv.confor the DNS server, not in the network path. - Port connectivity is a separate test.
nc -zvtests whether a specific TCP port is open. A service that is not listening and a firewall that is blocking both produce connection failures, but the diagnostic path differs. tcpdumpshows what is actually on the wire. It is the most direct way to see whether packets are leaving and whether responses are arriving. A SYN with no SYN-ACK indicates that packets are being dropped or the server is not responding.- Document findings at each layer. An escalation that reports which layers passed and which failed is actionable. An escalation that reports only the symptom is not.
Remember: Network diagnostics is not guessing. It is a systematic process of elimination. Start at the bottom, confirm each layer, and move upward. Each test either confirms that a layer is healthy—so the problem is above it—or identifies the layer where the failure occurs. The commands are simple. The discipline is in the order. Check the interface before the IP, the IP before the gateway, the gateway before the external host, the external host before DNS, and DNS before the port. When the failure is found, the fix is usually obvious. The hard part is finding it, and the method is what makes finding it possible.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!