Effective network troubleshooting follows a systematic approach rather than random guessing. The OSI model provides a useful framework: start at the physical layer (Layer 1) and work your way up, or start at the application layer (Layer 7) and work down. Most experienced IT professionals use a combination, starting with the most likely cause based on the symptoms. The general troubleshooting workflow is: (1) identify the problem clearly, (2) establish what has changed recently, (3) test connectivity at different layers, (4) isolate the failure point, (5) implement a fix, and (6) verify the fix resolves the issue. Before running any commands, gather information: What exactly is not working? When did it stop working? Does it affect one user or many? Is it one website/service or all internet access? Has anything changed recently (new software, hardware, configuration)? The answers to these questions often point directly to the cause and save significant troubleshooting time.

The ping command is the most fundamental network troubleshooting tool. It sends ICMP Echo Request packets to a target and measures the response time. This tells you whether a destination is reachable and how long the round trip takes. Basic usage: • ping 8.8.8.8 — Tests connectivity to Google's DNS server • ping google.com — Tests connectivity and DNS resolution • ping 192.168.1.1 — Tests connectivity to your default gateway (router) Interpreting results: • "Reply from..." with low latency (under 50ms for local, under 100ms for internet): Connection is working normally • "Request timed out": The destination is unreachable or blocking ICMP. This could indicate a network issue, firewall blocking, or the target being offline • "Destination host unreachable": Your local router cannot find a path to the destination • High latency (over 200ms) or variable latency: Indicates network congestion, a failing connection, or routing issues A useful troubleshooting sequence with ping: 1. ping 127.0.0.1 (localhost) — Tests your TCP/IP stack 2. ping your-ip-address — Tests your network adapter 3. ping default-gateway — Tests your connection to the router 4. ping 8.8.8.8 — Tests internet connectivity 5. ping google.com — Tests DNS resolution If step 3 fails but steps 1-2 succeed, the problem is between your computer and the router (cable, Wi-Fi, switch). If step 4 fails but step 3 succeeds, the problem is with your internet connection or ISP. If step 5 fails but step 4 succeeds, the problem is DNS.

Traceroute (tracert on Windows) shows every router hop between your computer and the destination. This is invaluable for identifying where in the network path a problem occurs. Usage: • Windows: tracert google.com • Linux/Mac: traceroute google.com Each line in the output represents one router hop, showing the hop number, round-trip times (three measurements), and the router's IP address or hostname. A typical internet connection might show 10-20 hops. Interpreting results: • Consistent low latency across all hops: Normal, healthy connection • Sudden latency increase at a specific hop: That hop or the link to it may be congested or having issues • Asterisks (* * *) at a hop: That router is not responding to traceroute probes (often due to firewall rules) — this is not necessarily a problem if subsequent hops respond normally • Asterisks at the final hop: The destination may be blocking ICMP or may be unreachable • Latency that increases and then decreases: The high-latency hop may simply be deprioritizing ICMP responses while forwarding your actual traffic normally For IT professionals, traceroute helps determine whether a connectivity problem is within your network, at your ISP, or somewhere on the internet. If the problem appears at hop 3 and that is your ISP's first router, you have evidence to present when calling their support line.

DNS (Domain Name System) translates domain names to IP addresses. When DNS fails, you can reach IP addresses directly but not domain names — a common symptom is "This site can't be reached" errors in the browser while ping 8.8.8.8 works fine. nslookup (available on all platforms): • nslookup google.com — Queries your default DNS server for google.com's IP address • nslookup google.com 8.8.8.8 — Queries Google's DNS server specifically • nslookup -type=MX example.com — Looks up mail server records • nslookup -type=NS example.com — Looks up nameserver records dig (Linux/Mac, more detailed output): • dig google.com — Full DNS query with detailed response • dig google.com +short — Just the IP address(es) • dig @8.8.8.8 google.com — Query a specific DNS server • dig example.com MX — Look up mail server records Common DNS issues and solutions: • "Server failed" or "SERVFAIL": Your DNS server is having problems. Try switching to a public DNS like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) • "Non-existent domain" or "NXDOMAIN": The domain does not exist or is misspelled • Slow DNS resolution: Your DNS server may be overloaded. Switching to a faster public DNS often helps • DNS returning wrong IP: Could indicate DNS cache poisoning, an outdated DNS record, or a DNS hijacking issue. Flush your DNS cache with "ipconfig /flushdns" on Windows or "sudo dscacheutil -flushcache" on Mac

These commands display and manage your computer's network configuration — essential for verifying that your network settings are correct. Windows (ipconfig): • ipconfig — Shows IP address, subnet mask, and default gateway for all adapters • ipconfig /all — Detailed information including MAC address, DHCP server, DNS servers, and lease times • ipconfig /release — Releases your current DHCP lease • ipconfig /renew — Requests a new IP address from the DHCP server • ipconfig /flushdns — Clears the local DNS cache Linux (ip command, modern replacement for ifconfig): • ip addr show — Shows all network interfaces and their IP addresses • ip route show — Shows the routing table including default gateway • ip link show — Shows interface status (up/down) and MAC addresses What to look for: • IP address starting with 169.254.x.x (APIPA): Your computer failed to get an address from DHCP. Check the DHCP server, network cable, and switch port • Correct subnet mask: A wrong subnet mask can cause intermittent connectivity issues where some devices are reachable and others are not • Default gateway present and correct: Without a default gateway, you can reach local devices but not the internet • DNS servers configured: Without DNS servers, you can reach IP addresses but not domain names

Netstat (and its modern Linux replacement, ss) shows active network connections, listening ports, and network statistics. This is essential for troubleshooting application connectivity issues and identifying unauthorized connections. Windows (netstat): • netstat -an — Shows all connections and listening ports with numeric addresses • netstat -b — Shows which program is using each connection (requires admin) • netstat -s — Shows protocol statistics (useful for identifying packet errors) • netstat -r — Shows the routing table Linux (ss, preferred over netstat): • ss -tuln — Shows all TCP and UDP listening ports • ss -tp — Shows TCP connections with process names • ss -s — Shows socket statistics summary Practical uses: • Verify a service is listening: If your web server is not responding, check if it is actually listening on port 80/443 with "netstat -an | find ":80"" (Windows) or "ss -tln | grep :80" (Linux) • Identify port conflicts: If an application fails to start because a port is in use, netstat/ss shows which process is using that port • Detect suspicious connections: Unusual outbound connections to unknown IP addresses could indicate malware • Monitor connection states: A large number of TIME_WAIT or CLOSE_WAIT connections can indicate application issues For IT helpdesk professionals, these commands are invaluable when users report that a specific application cannot connect to its server. Verifying that the server is listening on the expected port and that no firewall is blocking the connection are the first steps in troubleshooting application connectivity.