6.8 Idenitfy cause of application connectivity issues
Bottom up approach
Work through the OSI layers to isolate where the failure is.
- Physical (L1): Is the NIC connected? Check cable, switch port, wireless signal/range.
- Data Link (L2): MAC learning working? Check with
arp(client) /show mac address-table(switch). Watch for VLAN or STP misconfig. - Network (L3): IP reachability. Check IP/subnet/gateway config (
ipconfig/ifconfig), test withping. Watch for ACLs or routing issues. - Transport (L4): Can the client reach the right TCP/UDP port? Test with
curl/telnet. Watch for firewalls, wrong listening port, proxies, PAT/load balancer issues. - DNS: Name resolution working? Test with
nslookup. Watch for bad resolver config, wrong hostname, missing records. - Performance/QoS: Even with connectivity confirmed, congestion/latency can cause issues — test with
iperf, mitigate with QoS prioritization. - Application (L7): Use
tcpdumpto compare sent vs. received traffic; slow responses often point to backend (e.g., overloaded DB) rather than network.
TLDR
troubleshoot layer by layer — check physical connectivity, then L2 MAC learning, then L3 IP reachability with ping, then L4 port connectivity with curl or telnet, then DNS resolution, and finally application-layer behavior with tools like tcpdump. Most 'network' issues actually turn out to be DNS, firewall rules, or the application itself