Linux Network Interface & Connection Failure Triage

When a Linux server loses connectivity, experiences packet loss, or fails to resolve internal microservice endpoints, guessing wastes critical incident response minutes.

This guide delivers a bottom-up troubleshooting runbook: checking physical link state, examining route tables, inspecting socket states, testing the active DNS resolver, and capturing packet traffic with tcpdump. Commands use eth0 as an example; replace it with the interface name shown by ip -brief link.

---

🗺️ Systematic Triage Pipeline

Follow the OSI model from physical link up to application sockets:

1. Layer 1 & 2 (Link & Carrier): Interface up/down state, MAC addresses, and duplex negotiation.
2. Layer 3 (IP & Routing): Address assignment, gateway reachability, and default route tables.
3. Layer 4 (Transport & Sockets): Listening ports, backlog queues, and half-open TCP states.
4. Layer 7 (Name Resolution): The active resolver, upstream DNS reachability, and packet captures.

---

Step 1: Verify Interface Link & Layer 2 Carrier State

01

Audit Physical Link and Carrier State via iproute2

Link Layer

Verify that the Linux kernel registers a physical carrier signal and that interface flags show UP and LOWER_UP. Setting an interface administratively up cannot restore carrier if a cable, switch port, virtual NIC, or upstream link is unavailable. On NetworkManager-managed hosts, prefer correcting the connection profile rather than repeatedly changing the link with ip.

# List all network interfaces with carrier and operational state:
ip link show

# Check interface link statistics, CRC errors, and dropped packets:
ip -s link show dev eth0

# If an interface is DOWN administratively, bring it online:
sudo ip link set dev eth0 up

---

Step 2: Audit IPv4/IPv6 Addresses and Default Gateway Routing

02

Verify Address Assignment and Kernel Routing Tables

Network Layer

Confirm the interface has a valid IP and that a default route exists to send traffic outside the local subnet:

# Verify assigned IP addresses and subnet masks:
ip -brief addr show

# Inspect the kernel IPv4 routing table:
ip route show

# Test which route and gateway the kernel selects for a target IP:
ip route get 8.8.8.8

---

Step 3: Inspect Socket States and Backlog Queues with ss

03

Inspect Active Listening Sockets and Connection Queues

Transport Layer

Check if local listening services are bound to the right addresses (e.g., 0.0.0.0 vs 127.0.0.1) and examine TCP socket health:

# List all listening TCP ports and associated process names:
sudo ss -tulpn

# Inspect established outbound connections and packet queues:
ss -ta --numeric

# Filter connections in SYN-SENT or TIME-WAIT states:
ss -t state syn-sent

---

Step 4: Check DNS Through the Active Resolver

04

Check DNS Through the Active Resolver

DNS Resolution

Use resolvectl only when systemd-resolved is active. Some Debian/Ubuntu systems use it; many RHEL 9 systems use NetworkManager and /etc/resolv.conf instead. The fallback below checks the configured resolver without assuming a particular service. Replace eth0 with the interface name shown by ip -brief link.

IFACE=eth0
getent ahosts api.github.com

if systemctl is-active --quiet systemd-resolved; then
  resolvectl status
  resolvectl query api.github.com
  # Flush only this resolver's cache if you have evidence it is stale.
  sudo resolvectl flush-caches
elif command -v nmcli >/dev/null 2>&1; then
  nmcli device show "$IFACE" | grep -E 'GENERAL.STATE|IP[46].DNS'
  cat /etc/resolv.conf
else
  cat /etc/resolv.conf
fi

Figure 1: Interface, route, and resolver checks show that the host has no active network link.

---

Step 5: Capture Live Network Frames with tcpdump

05

Analyze Raw Ingress and Egress Packets on the Wire

Packet Capture

When a connection fails, capture only the traffic needed to answer a specific question. Each example stops after 30 seconds or 50 matching packets, whichever comes first. Captures may contain credentials, personal data, or internal host details, so use them only with authorization and store them according to your incident policy.

# Capture up to 50 ICMP packets, with a 30-second time limit:
sudo timeout --signal=INT 30s tcpdump -i eth0 -nn -c 50 icmp

# Capture up to 50 DNS packets, with a 30-second time limit:
sudo timeout --signal=INT 30s tcpdump -i eth0 -nn -c 50 port 53

# Capture initial TCP SYN packets, excluding SYN-ACK responses:
sudo timeout --signal=INT 30s tcpdump -i eth0 -nn -c 50 \
  'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

---

Pro-Tip: Fast Triage Command

Use ip route get 1.1.1.1 to see which route the kernel would select; it does not prove the destination is reachable. Test IP connectivity with an approved target and then test name resolution separately, for example with getent ahosts cloudflare.com. A failed name lookup can result from resolver configuration, DNS transport, routing, firewall rules, or an unavailable upstream server, so use the other checks before calling it a DNS-only fault.