Network Troubleshooting Methodology: OSI Layer Approach

Introduction

Systematic network troubleshooting is the skill that separates experienced engineers from junior ones. Without a methodology, troubleshooting becomes random and time-consuming — checking things in no particular order, missing the actual cause. This guide teaches you the OSI model-based troubleshooting framework and specific techniques for common real-world network problems.

The OSI Troubleshooting Framework

Always start at Layer 1 and work up. Don't jump to Layer 7 if Layer 1 hasn't been verified:

TEXT

Layer 7 - Application: Can the application communicate?
Layer 6 - Presentation: Encoding/encryption issues?
Layer 5 - Session: Are sessions being established?
Layer 4 - Transport: Are TCP/UDP connections working?
Layer 3 - Network: Is IP routing correct?
Layer 2 - Data Link: Are MAC addresses resolving?
Layer 1 - Physical: Is the cable/link actually working?

Layer 1: Physical

BASH

# Linux: check link status
ip link show eth0
# Look for: UP (good) vs DOWN (bad)
# ethtool shows more detail:
ethtool eth0 | grep -E "Speed|Duplex|Link"
# Speed: 1000Mb/s (should match switch config)
# Duplex: Full (half-duplex causes many issues)
# Link detected: yes (no = physical problem)

# Cisco switch: check interface
show interface GigabitEthernet1/0/1
# Look for: line protocol is up (down = physical problem)
# Input errors, CRC errors = bad cable
# show interface status → shows speed/duplex/vlan

# Common physical issues:
# - Wrong cable type (straight vs crossover - auto-MDI usually handles this)
# - Duplex mismatch (auto vs forced)
# - Bad SFP/transceiver
# - Flapping link (check: show interface | inc CRC|error|flap)

Layer 2: Data Link

BASH

# Check ARP table (MAC address resolution)
ip neigh show          # Linux
arp -a                 # Windows/Linux

# If missing neighbor entry:
ping 192.168.1.1 -c 3  # Trigger ARP
ip neigh show 192.168.1.1

# Cisco: check MAC address table
show mac address-table | include Gi1/0/1

# Verify VLAN configuration
show vlan brief          # What VLANs exist
show interface Gi1/0/1 trunk   # Is trunk configured correctly?
show interface Gi1/0/1 switchport  # What VLAN is access port in?

# Spanning Tree issues (Layer 2 loops cause broadcast storms)
show spanning-tree vlan 10
# Look for: Root bridge, port states (FWD, BLK, LRN)

Layer 3: Network

BASH

# Basic connectivity test
ping 192.168.1.1       # Default gateway
ping 8.8.8.8           # Internet (bypasses DNS)
ping google.com        # DNS + internet

# Trace the path
traceroute 8.8.8.8          # Linux (UDP by default)
tracert 8.8.8.8             # Windows (ICMP)
traceroute -I 8.8.8.8       # Linux with ICMP (like Windows)

# Check routing table
ip route show          # Linux
route print            # Windows
show ip route          # Cisco

# Check if route exists for destination
ip route get 8.8.8.8   # Linux: shows which route/interface will be used

# MTU issues (large packets failing but small ones working)
# Test with different sizes
ping -s 1472 -M do 192.168.1.1    # Test 1500 byte frame
ping -s 1000 -M do 192.168.1.1    # Test smaller frame
# If large fails but small works: MTU mismatch

Layer 4: Transport (TCP/UDP)

BASH

# Test if port is open
nc -zv 192.168.1.50 80       # Netcat: connect to port 80
nc -zv -u 192.168.1.50 53    # UDP port 53
telnet 192.168.1.50 80        # Old way

# Show listening ports
ss -tlnp             # Linux (ss replaces netstat)
netstat -an          # Windows

# Show established connections
ss -t state established
# Check connection states: ESTABLISHED, TIME_WAIT, FIN_WAIT

# Capture packets to see what's happening
tcpdump -i eth0 host 192.168.1.50 and port 80 -w capture.pcap
tcpdump -i eth0 -n "tcp[tcpflags] & (tcp-syn|tcp-rst) != 0"  # SYN/RST only

# Read capture file
tcpdump -r capture.pcap
# Or open in Wireshark: wireshark capture.pcap

Layer 7: Application

BASH

# HTTP troubleshooting
curl -v http://web.company.com/         # Verbose HTTP request
curl -v -k https://web.company.com/    # HTTPS (ignore cert)
curl -I http://web.company.com/        # Headers only
curl -o /dev/null -s -w "%{http_code} %{time_connect} %{time_total}
" http://web.company.com/

# DNS troubleshooting
nslookup web.company.com               # Basic lookup
dig web.company.com                    # Detailed lookup
dig web.company.com @8.8.8.8           # Query specific DNS server
dig web.company.com +short             # Just the answer
dig -x 192.168.1.50                    # Reverse lookup
dig web.company.com SOA                # Check zone authority

# SSL/TLS issues
openssl s_client -connect web.company.com:443 -showcerts
# Check: certificate chain, expiry dates
echo | openssl s_client -connect web.company.com:443 2>/dev/null |   openssl x509 -noout -dates

Systematic Approach: Real Scenario

TEXT

Problem: "Users can't reach the web application"

Step 1: Define the problem precisely
- Who is affected? All users or some?
- What exactly fails? (Error message)
- When did it start? What changed?

Step 2: Layer 1 - Physical
- Check server NIC link (ip link show)
- Check switch port status

Step 3: Layer 2 - Data Link
- Server has valid MAC? (ip link show)
- Switch ARP table has server MAC?

Step 4: Layer 3 - Network
- Server has correct IP/mask/gateway? (ip addr show)
- Can server ping gateway? (ping 192.168.1.1)
- Can gateway ping server?
- Can client ping server by IP?

Step 5: Layer 4 - Transport
- Is nginx/Apache listening? (ss -tlnp | grep :80)
- Does client successfully TCP connect? (nc -zv server 80)
- Is a firewall blocking? (iptables -L, check security groups)

Step 6: Layer 7 - Application
- Does curl return correct response from server?
- Are there application errors in logs?
- Is DNS resolving correctly?

Useful Tools Summary

BASH

# Physical/Link
ethtool eth0              # Link speed, duplex, driver info
mii-tool eth0             # Media-independent interface status

# Layer 2
arp -n                    # ARP cache
ip neigh                  # Neighbor (ARP/NDP) table

# Layer 3
ip route                  # Routing table
ip route get X.X.X.X      # Which route used for destination
traceroute                # Path to destination

# Layer 4
ss -tlnp                  # Listening TCP sockets
ss -ulnp                  # Listening UDP sockets
tcpdump                   # Packet capture

# Application
curl -v                   # HTTP debugging
dig / nslookup            # DNS
openssl s_client          # TLS debugging

Network troubleshooting mastery comes from one habit: always follow the OSI model from Layer 1 up, never skip layers, and gather evidence at each layer before moving to the next. The methodology turns "random guessing" into systematic diagnosis.