The difference between a junior technician and a senior network engineer is not just technical knowledge—it is the methodology they use to solve problems. Randomly changing firewall rules, rebooting switches, or blindly blaming the ISP ("guess-and-change") causes outages. A professional engineer follows a strict, repeatable Troubleshooting Workflow: Measure, Compare, Isolate, Correlate, Verify, Document.
1. Define the Problem
Never start troubleshooting a vague complaint like "The internet is slow." You must force the user to define exactly what is broken. A well-defined problem statement looks like: "Users on VLAN 10 experience 15–25% packet loss when accessing the internal CRM server between 10:00 and 11:00 AM."
2. Determine the Scope
Scope isolation instantly eliminates 90% of the network from suspicion. Ask:
- Is it one user, or everyone on the floor? (If one user, check their PC/cable. If the floor, check the access switch).
- Is it one VLAN, or all VLANs? (If one VLAN, check routing/DHCP. If all, check the core).
- Is it one application, or all internet traffic?
3. Check the Physical Layer
Before checking complex BGP routes, verify the link is physically UP. Check the cables, SFP transceivers, and interface statistics. Are there Duplex Mismatches, CRC errors, or heavy wireless interference?
4. Check IP Configuration
Does the client have a valid IP address, subnet mask, default gateway, and DNS server? A machine with a 169.254.x.x address simply cannot reach a DHCP server.
5. The Connectivity Ladder
Always test connectivity methodically from the inside out:
- Ping Localhost (127.0.0.1): Proves the local TCP/IP stack works.
- Ping Local IP: Proves the network adapter works.
- Ping Default Gateway: Proves local LAN switching and cabling work.
- Ping Remote IP (e.g., 8.8.8.8): Proves routing and internet access work.
- Ping DNS Name (e.g., example.com): Proves DNS resolution works.
- Test Application Port: Proves the firewall allows the traffic (e.g.,
Test-NetConnection example.com -Port 443).
6. Check Routing
If you can ping the gateway but not the remote IP, check the routing table. Does the router have a path to the destination? Use a traceroute to see where the traffic dies. (Remember: ICMP non-responses in the middle of a trace do not automatically mean a failure).
7. Check DNS
If a user can reach 8.8.8.8 but cannot open a website, the network is perfect, but DNS is broken. Do not troubleshoot routing for a DNS failure.
8. Check the Firewall / ACLs
Are security policies blocking the traffic? Review firewall logs for Deny events. Check NAT translations. Never immediately disable security controls as a troubleshooting method. Analyze the logs instead.
9. Check the Application / Service
If the network passes all tests, the problem is likely the server. Is the web service actually listening on Port 443? Is the backend database crashed? Do not blame the network without evidence.
10. Check Performance & Monitor
If connectivity exists but the complaint is "slow", correlate metrics using your Network Monitoring platform. Check for Latency, Packet Loss, Jitter, and bandwidth saturation.
11. Apply Fix, Verify, and Document
Make one change at a time. If it doesn't fix the problem, revert it. Once fixed, verify from the user's perspective, and document the root cause and preventive actions to ensure it never happens again.