Troubleshooting and Support
Work a method, not a hunch
Troubleshooting questions test disciplined process. The universal loop is: define the problem precisely, gather information, form a hypothesis, test it, act on the result, verify the fix, then document. Skipping verification or documentation is the most common wrong-answer pattern.
Choose a direction and justify it. Bottom-up starts at the physical layer and suits "nothing works at all." Top-down starts at the application and suits a single failing application on an otherwise working host. Divide-and-conquer tests the middle layer first - fastest when the fault is suspected to be narrow.
Know the tools and what each proves. ping proves IP reachability only when ICMP is permitted (a failed ping is not proof a host is down). traceroute/tracert reveals the path and where responses stop. nslookup/dig isolate name resolution. ipconfig/ifconfig show address, mask, gateway, and DNS servers. netstat/ss show listening ports and established sessions. A port test with telnet or netcat separates "host up" from "service listening." Packet capture settles arguments about direction and loss.
High-yield fault signatures. Duplex or speed mismatch on a link; MTU/fragmentation black holes (small pings succeed, large ones fail); asymmetric routing; DNS as the culprit whenever IP works but names do not; ICMP blocked by policy; and candidate changes - always ask "what changed recently?"
Worked example
A user can reach a server at 203.0.113.20 by IP but https://intranet.example.com times out. Reachability is proven, so start at the resolver: check the configured DNS server, then dig intranet.example.com, then the record itself. The fault is name resolution or the record, not the network path.
Rule of thumb
Change one variable at a time and test in both directions. If two fixes are proposed and one of them includes verification, that is your answer.