Common Issues

After years of network troubleshooting, experienced engineers recognize that the same problems appear repeatedly—different networks, different applications, but fundamentally the same root causes. This is both frustrating and powerful.

Frustrating because you'd think people would stop making the same mistakes. Powerful because once you recognize the pattern, diagnosis becomes fast.

This page catalogs the most common network issues you'll encounter in production environments. For each, we'll cover:

• Symptoms — How the problem manifests
• Root causes — What typically causes this issue
• Diagnostic steps — How to confirm the diagnosis
• Resolution — How to fix it
• Prevention — How to stop it from recurring

Think of this as a field guide—a reference you'll return to throughout your career.

"I can't reach the server" — the most common complaint. Complete connectivity failures have many causes, but systematic diagnosis quickly identifies the layer at fault.

Symptom Categories:

Issue: No Physical Connectivity

Symptoms:

• No network icon or 'Network cable unplugged'
• No link lights on NIC or switch port
• ipconfig shows 'Media disconnected'

Diagnosis:

# Windows
ipconfig /all   # Look for 'Media State: Media disconnected'

# Linux
ip link show    # Look for 'state DOWN' or 'NO-CARRIER'
ethtool eth0    # Check 'Link detected: yes/no'

Common Causes:

• Loose or damaged cable
• Failed NIC
• Wrong cable type (crossover vs straight-through, though auto-MDI/X usually handles this)
• Dead switch port
• Port administratively disabled

Resolution:

1. Try a different cable (most common fix)
2. Try a different switch port
3. Check switch port configuration (show interface on Cisco)
4. Test NIC with known-good cable/port
5. Update/reinstall NIC driver

Issue: APIPA/Link-Local Address

Symptoms:

• IP address in 169.254.x.x range (Windows) or 169.254.x.x (Linux with zeroconf)
• Can't reach anything outside local segment

Diagnosis:

# Check IP configuration
ipconfig /all              # Windows
ip addr show               # Linux

# Try to get new address
ipconfig /release          # Windows
ipconfig /renew

dhclient -r eth0           # Linux
dhclient eth0

# Check for DHCP traffic (on capture)
sudo tcpdump -i eth0 port 67 or port 68

Common Causes:

• DHCP server down or unreachable
• DHCP scope exhausted
• VLAN mismatch (client and DHCP server on different VLANs without relay)
• Firewall blocking DHCP (UDP 67/68)

Resolution:

1. Verify DHCP server is running
2. Check DHCP scope has available addresses
3. Verify VLAN configuration and DHCP relay (ip helper-address)
4. Use static IP as workaround while fixing DHCP

"The network is slow" — possibly the most frustrating complaint because 'slow' is subjective and can have dozens of causes. Systematic analysis is essential.

First: Quantify 'Slow'

Before investigating, establish baselines:

• What is the expected performance?
• What is the actual measured performance?
• How consistently slow is it? (Always, peak times, random)

Performance Issue Categories:

Issue: Network Congestion

Symptoms:

• High latency during busy periods
• Packet loss (retransmissions visible in captures)
• Throughput lower than link capacity

Diagnosis:

# Check interface utilization on network devices
show interface GigabitEthernet0/1   # Cisco
# Look for 'input rate' and 'output rate' near link capacity

# From endpoints, use iperf to test capacity
iperf3 -c server-ip                  # Client
iperf3 -s                            # Server

# mtr to identify where latency increases
mtr -n target.example.com

Common Causes:

• Insufficient bandwidth for traffic volume
• Backup jobs during business hours
• Streaming or large file transfers
• Broadcast storms or loops

Resolution:

1. Identify the traffic causing congestion (NetFlow, sFlow, SNMP)
2. Reschedule bandwidth-intensive tasks to off-peak
3. Implement QoS to prioritize critical traffic
4. Upgrade link capacity if consistently saturated
5. Check for traffic loops (STP issues)

Issue: Duplex Mismatch

Symptoms:

• Slow throughput despite available bandwidth
• Increasing 'late collisions' on switch port
• Performance degrades under load
• Works okay for small transfers, terrible for large ones

Diagnosis:

# Check duplex settings on switch
show interface GigabitEthernet0/1
# Look for 'Half-duplex' when 'Full-duplex' expected
# Look for 'late collision' or 'CRC error' counters

# On Linux
ethtool eth0
# Check 'Duplex: Full' or 'Duplex: Half'

# On Windows
Get-NetAdapter | Format-List -Property *

What happens in a duplex mismatch:

• One side set to full-duplex (doesn't check for traffic before sending)
• Other side set to half-duplex (waits for clear channel)
• Full-duplex side transmits while half-duplex side is sending
• Half-duplex side detects collision, retransmits
• Result: severe performance degradation under load

Resolution:

1. Set both ends to same duplex (ideally full-duplex)
2. Configure both ends to auto-negotiate (most reliable on modern gear)
3. If auto-neg fails, manually set both sides identical

Issue: TCP Window Size Limitation

Symptoms:

• Throughput much lower than bandwidth allows
• High-latency links particularly affected
• Single connections slow, multiple parallel connections faster

Explanation:

TCP window size limits how much data can be in-flight before acknowledgment. For high bandwidth-delay product links:

Max Throughput = Window Size / RTT

Example: 64 KB window, 100ms RTT
Max = 65536 bytes / 0.1 seconds = 655 KB/s = 5.2 Mbps

On a 100 Mbps link, you're limited to 5.2 Mbps!

Diagnosis:

• Packet capture: Look at TCP window sizes in handshake and during transfer
• Filter: tcp.analysis.zero_window or tcp.analysis.window_full

Resolution:

1. Enable TCP window scaling (usually default on modern OS)
2. Tune TCP buffer sizes:

   # Linux - increase TCP buffers
   sysctl -w net.core.rmem_max=16777216
   sysctl -w net.core.wmem_max=16777216
   sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
   sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'
   

3. For file transfers, use applications that support parallel streams

"It's always DNS" — a meme in network engineering because it's often true. DNS issues cause symptoms that look like network problems but are actually name resolution failures.

Issue: DNS Server Unreachable

Symptoms:

• Websites don't load by name, but IPs work
• 'Name or service not known' or 'DNS_PROBE_FINISHED_NXDOMAIN'
• Inconsistent failures (some names work, others don't)

Diagnosis:

# Test DNS resolution explicitly
nslookup www.example.com
nslookup www.example.com 8.8.8.8   # Test alternate DNS

# Check configured DNS servers
cat /etc/resolv.conf               # Linux
ipconfig /all                      # Windows

# Ping DNS server
ping 192.168.1.1                   # Your DNS server IP

# Test DNS port
nc -zv 192.168.1.1 53              # TCP
nc -zuv 192.168.1.1 53             # UDP

Common Causes:

• DNS server down or overloaded
• Firewall blocking UDP/TCP 53
• Incorrect DNS server configured
• DHCP providing wrong DNS server

Issue: DNS Returning Wrong Answer

Symptoms:

• Website shows wrong content or certificate error
• Internal names resolve to external IPs or vice versa
• Recent DNS changes not reflected

Diagnosis:

# Query authoritative server directly
dig www.example.com @ns1.example.com

# Check what your resolver returns
dig www.example.com

# Compare results - they should match

# Check TTL to see if cached
dig www.example.com   # Note TTL in answer section

# Flush cache
ipconfig /flushdns                  # Windows
sudo systemd-resolve --flush-caches # Linux (systemd-resolved)
sudo rndc flush                     # BIND server

Common Causes:

• Cached stale record (wait for TTL expiry or flush)
• Split-horizon DNS returning wrong view
• DNS hijacking or poisoning
• HOSTS file override
• Local DNS server with stale zone

Issue: DNS Propagation Delay

Symptoms:

• DNS change made, but old IP still returning
• Different results from different locations
• Complaints that 'it works for some people but not others'

Understanding TTL:

DNS records have a Time-To-Live (TTL) specifying how long resolvers should cache them. Until TTL expires, cached value is returned.

# Check current TTL
dig example.com

;; ANSWER SECTION:
example.com.        3600    IN    A    93.184.216.34
                    ^^^^
                    TTL in seconds (1 hour)

Resolution:

1. Before changing DNS, reduce TTL to 300 (5 min) 24-48 hours in advance
2. Make the change
3. Wait for old TTL to expire
4. Return TTL to normal value

For immediate change needs:

• Old TTL must expire; you can't force remote caches
• Upstream resolvers (ISP, 8.8.8.8) honor TTL
• Some resolvers enforce minimum TTL regardless of record

MTU (Maximum Transmission Unit) issues cause frustrating partial failures: small packets work, large packets fail. This creates symptoms like:

• Web pages partially load
• SSH works, SCP fails
• Ping works, applications fail
• VPN connections mysteriously break

Understanding MTU:

When a packet exceeds the path MTU, it must be fragmented or dropped. Modern hosts use Path MTU Discovery (PMTUD) to avoid fragmentation by discovering the smallest MTU along the path.

Issue: Black Hole Due to PMTUD Failure

Symptoms:

• Connections establish (SYN/ACK works) but data transfer stalls
• Small requests work, large ones timeout
• Works on some networks, not others
• Classic: 'SSH works, HTTPS doesn't'

What's Happening:

1. Host sends large packet with DF (Don't Fragment) bit set
2. Router in path can't forward (MTU exceeded)
3. Router should send ICMP 'Fragmentation Needed' message
4. But a firewall blocks ICMP, so message never arrives
5. Host never learns packet was too big
6. Host keeps retrying with same packet size
7. Connection stalls

Diagnosis:

# Test with large ping and DF bit
ping -M do -s 1472 target.example.com     # Linux
ping -f -l 1472 target.example.com        # Windows

# If this fails but smaller sizes work, MTU issue confirmed
ping -M do -s 1400 target.example.com

# Binary search to find path MTU
ping -M do -s 1450 target.example.com
ping -M do -s 1430 target.example.com
# ... continue until you find the breakpoint

# Packet capture: look for large packets with no response
sudo tcpdump -i eth0 -nn host target.example.com and greater 1400

Routing issues cause traffic to go to the wrong place—or nowhere at all. They range from simple (missing default gateway) to complex (routing loops, asymmetric routing).

Issue: Missing or Wrong Default Gateway

Symptoms:

• Can reach local network but nothing beyond
• 'Network is unreachable' errors
• Traceroute fails at first hop

Diagnosis:

# Check routing table
route -n                    # Linux
ip route show               # Linux
route print                 # Windows
Get-NetRoute               # PowerShell

# Is there a default route (0.0.0.0)?
ip route show | grep default

# Can you reach the gateway?
ping <gateway-ip>

Common Causes:

• DHCP not providing gateway
• Manual configuration error
• Gateway router down or unreachable
• Multiple default routes confusing routing

Issue: Asymmetric Routing

Symptoms:

• Connections fail or are inconsistent
• Stateful firewalls drop return traffic
• tcpdump shows traffic going out but no return
• But return traffic appears on a different interface/path

What's Happening:

• Traffic from A to B takes Path X
• Traffic from B to A takes Path Y
• If a firewall on Path X sees outbound but not return, it may block return traffic as 'unsolicited'

Diagnosis:

# Traceroute from both endpoints
# On Host A
traceroute host-b

# On Host B
traceroute host-a

# If paths are different, you have asymmetric routing

# Check for multiple routes to same destination
ip route show
# Multiple routes with same metric cause unpredictable path selection

Resolution:

1. Ensure stateful firewalls are on symmetric path or use stateless rules
2. Adjust routing metrics to force symmetric path
3. Use policy-based routing to control path selection
4. Place firewalls at network chokepoints where all traffic passes

Issue: Routing Loop

Symptoms:

• Packets never reach destination
• TTL expires (ICMP Time Exceeded)
• Traceroute shows same hops repeating
• 'TTL exceeded in transit' from intermediate routers

Example Traceroute with Loop:

 1  192.168.1.1    1.2 ms
 2  10.0.0.1       5.3 ms
 3  10.0.1.1      10.2 ms
 4  10.0.0.1      15.1 ms  <- Same as hop 2!
 5  10.0.1.1      20.3 ms  <- Same as hop 3!
 6  10.0.0.1      25.2 ms  <- Looping forever

Common Causes:

• Misconfigured static routes pointing at each other
• Routing protocol convergence issue
• Default route pointing back to source
• Route redistribution problems

Resolution:

1. Identify the routers in the loop
2. Check routing tables on each: where are they sending the traffic?
3. Find conflicting or circular routes
4. Fix static routes or wait for protocol convergence
5. Use debug ip routing (carefully!) to watch route changes

Firewalls are the most common cause of 'It works from here but not from there' scenarios. Security controls exist to block traffic, so they're doing their job—but sometimes too well.

Issue: Traffic Blocked by Firewall

Symptoms:

• Connection timeout (no response, firewall drops)
• Connection refused or RST (firewall rejects)
• Works from one source, not another
• Works to one port, not another

Diagnosis:

# Test port connectivity
nc -zv target 443
telnet target 443
Test-NetConnection target -Port 443    # PowerShell

# Differentiate drop vs reject:
# - Timeout = DROP (packet silently discarded)
# - Connection refused = REJECT (explicit denial)

# Capture on firewall or destination
sudo tcpdump -i eth0 host source-ip
# See if packets arrive but aren't responded to

Common Firewall Issues:

Issue: NAT Problems

Symptoms:

• Outbound connections work, inbound fail
• Applications see wrong source IP
• Deep inspection breaks due to payload IP addresses
• 'Hairpin' scenarios fail (accessing external IP from inside)

Diagnosis:

# Check if NAT is expected
# Is your source IP private (10.x, 172.16-31.x, 192.168.x)?
ip addr show

# What IP does external service see?
curl ifconfig.me      # Shows your external IP

# Check NAT table on router (if accessible)
show ip nat translations   # Cisco
conntrack -L               # Linux

Common NAT Issues:

Issue: Security Software False Positives

Symptoms:

• Connection works sometimes, blocked others
• Works until 'suspicious' pattern detected
• IDS/IPS alerts correlate with failures
• Antivirus or endpoint security blocking traffic

Diagnosis:

# Check security software logs
# Windows Defender
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall'

# Check IDS/IPS for relevant alerts
grep 'blocked' /var/log/snort/alert   # Snort

# Temporarily disable (for testing ONLY) to confirm
# Be very careful with this in production

Resolution:

1. Check security software logs for blocks
2. Create exception rules for legitimate traffic
3. Work with security team to tune rules
4. Never permanently disable security; create targeted exceptions

Wireless networks add a layer of complexity—literally. RF interference, channel congestion, and authentication add failure modes not present in wired networks.

Issue: Slow WiFi or High Packet Loss

Symptoms:

• Throughput much lower than WiFi standard allows
• High latency spikes
• Intermittent disconnections
• 'Limited connectivity' messages

Diagnosis:

# Linux - check WiFi signal and link quality
iwconfig wlan0
# Look for: Signal level, Link Quality, Tx-Power

# Check what channel you're on
iwlist wlan0 channel

# Scan for competing networks
sudo iw dev wlan0 scan | grep -E 'SSID|signal|Channel'

# Windows - detailed WiFi report
netsh wlan show interfaces

# Check signal strength (RSSI)
# -30 to -50 dBm = Excellent
# -50 to -60 dBm = Good
# -60 to -70 dBm = Fair
# -70 to -80 dBm = Weak
# Below -80 dBm = Unusable

Issue: Authentication Failures (Enterprise WiFi)

Symptoms:

• 'Unable to connect' or 'Can't connect to this network'
• Prompts for credentials repeatedly
• Works for some users, not others
• Works on phone, not laptop (or vice versa)

Enterprise WiFi Components:

• 802.1X — Authentication framework
• EAP — Extensible Authentication Protocol (EAP-TLS, PEAP, etc.)
• RADIUS — Server that validates credentials
• Supplicant — Client software requesting access

Diagnosis:

1. Check user credentials (expired password, locked account)
2. Verify certificate (expired, untrusted CA)
3. Check RADIUS server logs for authentication attempts
4. Compare working and non-working device EAP settings
5. Check if device certificate is required

Common Causes:

• Password changed, stored credential stale
• Certificate expired (server or client)
• Device not in allowed list
• EAP method misconfiguration
• RADIUS server unreachable from AP