LFCA 121 🐧 Real-World Scenario — Basic Network Diagnostics - KandZ

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 show

The 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 show

The 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 eth0

The -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 eth0

The 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 show

The 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.1

The 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.8

If 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.8

The 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.com

The 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.conf

The /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 443

The 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.com

The 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 :443

On 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 443

The 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 up

2. No IP Address

ip addr show
# eth0: no inet address
sudo dhclient eth0

3. Gateway Unreachable

ping -c 3 192.168.1.1
# Request timeout
ip route show

4. DNS Failure

dig example.com
# connection timed out
cat /etc/resolv.conf

5. Port Closed

nc -zv example.com 443
# Connection refused
ss -tulpn | grep :443

6. Firewall Blocking

tcpdump -i eth0 -n port 443
# SYN sent, no SYN-ACK
sudo iptables -L -n | grep 443

7. Route Missing

ip route show
# no default route
sudo ip route add default via 192.168.1.1

8. Interface Errors

ip -s link show eth0
# RX errors: 1234
ethtool eth0

9. TLS Failure

curl -v https://example.com
# SSL certificate problem
openssl s_client -connect example.com:443

10. Packet Capture

tcpdump -i eth0 -n host 8.8.8.8
# Observe request/response

Visual

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 show confirms the link state. ip addr show confirms IP configuration. Both are prerequisites for any higher-layer connectivity.
The gateway must be reachable before external hosts are. ping the 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. dig queries DNS directly. If DNS fails, the problem is in /etc/resolv.conf or the DNS server, not in the network path.
Port connectivity is a separate test. nc -zv tests 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.
tcpdump shows 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!