Network Connectivity Issues

Network Connectivity Issues

Network connectivity problems on Ubuntu servers follow a logical diagnostic path from the bottom up: physical/link layer first, then IP routing, then firewall rules, then DNS, then the application. Jumping straight to application logs when connectivity fails wastes time — if the network cable is unplugged or the default route is missing, no amount of application debugging will help. This systematic approach resolves most connectivity issues in under 10 minutes.

Network troubleshooting layers

OSI layers for network troubleshooting:

  Layer 1 (Physical): Cable plugged in? NIC active?
  Check: ip link show (is the interface UP?)

  Layer 2 (Data Link): ARP working? Switch port active?
  Check: arp -n, ip neigh show

  Layer 3 (Network): IP address? Default route? Routing table?
  Check: ip addr, ip route, ping gateway

  Layer 4 (Transport): TCP/UDP port open? Firewall blocking?
  Check: netstat, ss, ufw status, telnet/nc

  Layer 7 (Application): Service listening? Responding correctly?
  Check: curl, application logs, systemctl status

Testing basic connectivity

# Layer 1-2: is the interface up?
ip link show

ip link show output

2: eth0:  mtu 1500 state UP
#                               ^UP = interface up, LOWER_UP = cable connected
3: eth1:  mtu 1500 state DOWN
#                                            DOWN = interface down (check cable/config)

# Layer 3: IP address and routing:
ip addr show eth0      # Does it have an IP?
ip route show          # Is there a default route?

ip route show output

default via 10.0.0.1 dev eth0     ← Default route present
10.0.0.0/24 dev eth0 scope link   ← Local network route
# If NO default route shown: add it:
sudo ip route add default via 10.0.0.1 dev eth0

# Ping tests (systematic):
ping -c 3 10.0.0.1        # Gateway (same LAN)
ping -c 3 8.8.8.8         # Internet by IP (tests routing, bypasses DNS)
ping -c 3 google.com      # By hostname (tests DNS)

# Traceroute — find where packets are dropped:
traceroute 8.8.8.8
mtr 8.8.8.8    # Continuous traceroute with statistics

Firewall and routing diagnosis

# Check UFW firewall status:
sudo ufw status verbose

# Test if a port is reachable from outside:
nc -zv 10.0.0.10 80    # Test TCP connection to port 80
nc -zvw 3 10.0.0.10 443    # With 3-second timeout

# Check which ports are listening locally:
sudo ss -tlnp    # TCP listening ports and which process owns them

ss -tlnp output

State    Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN   0       128     0.0.0.0:80         0.0.0.0:*          users:(("nginx",pid=1234))
LISTEN   0       128     127.0.0.1:3306     0.0.0.0:*          users:(("mysqld",pid=5678))
# nginx listening on 0.0.0.0:80 (all interfaces, port 80) — OK
# MySQL listening on 127.0.0.1:3306 (localhost only) — expected

# Check raw iptables rules (UFW uses iptables underneath):
sudo iptables -L -n -v | head -50

# Allow a port if blocked:
sudo ufw allow 443/tcp
sudo ufw allow from 10.0.0.0/24 to any port 22

DNS and service-level issues

# DNS resolution test:
nslookup google.com           # Basic DNS query
dig google.com +short         # Quick IP lookup
dig @8.8.8.8 google.com       # Query specific DNS server (bypass local resolver)
cat /etc/resolv.conf          # Check configured DNS servers

# Connection to a specific service:
curl -v http://10.0.0.10/     # Test HTTP with full headers
curl -v https://example.com   # Test HTTPS (shows TLS handshake)
curl -v --max-time 5 http://10.0.0.10:8080/health  # With timeout

# Check if service is actually listening and responding:
sudo systemctl status nginx mysql app-service

Conclusion

Work top-down when connectivity is broken: confirm the interface is UP, confirm an IP is assigned, confirm a default route exists, confirm the gateway is reachable, confirm DNS resolves, then test the specific service port. Skipping any layer wastes time debugging the wrong thing. The mtr command (a continuous traceroute) is particularly valuable for diagnosing intermittent connectivity issues because it shows packet loss per hop over multiple samples, making it easy to identify where in the network path packets are being dropped.