2.4Network troubleshooting (ping, ipconfig, traceroute)
The essentials in 30 seconds
- ipconfig shows the local configuration (address, mask, gateway, DNS): if it is abnormal (169.254), fix it here before going further.
- ping tests whether a target answers, from the gateway to an external address then to a name: each test confirms one link.
- tracert follows the path hop by hop and reveals where the journey breaks; a failed ping is only a clue, because ICMP may be filtered.
Running mini-case — Sofiane runs the diagnostic sequence
Sofiane, a level 1 support technician in a distribution SME in Algiers, receives a “no more Internet” from accounting. He applies the nearest-to-farthest method: ipconfig shows a healthy config (192.168.1.23, gateway 192.168.1.1); ping 192.168.1.1 answers (the local network is reachable); but ping 8.8.8.8 comes back “request timed out”. He deduces that the failure is upstream of the gateway (box, line or ISP). He runs tracert to locate the hop that is blocking, then escalates the information to level 2 with his readings attached. He notes the reflex: always write down the results at each step.
Standalone case for this section: it returns in the lesson, the diagram, the script and the 48h challenge of section 2.4.
1. ipconfig — my local configuration
ipconfig displays the machine's IP address, mask, gateway and DNS servers. If this configuration is missing or abnormal (169.254), the problem is here: no point going further before fixing it. It is the first link Sofiane checks.
2. ping — does it answer?
ping tests whether a target answers. You first ping the gateway (is the local network reachable?), then an external address (is the Internet reachable?), then a name (does the DNS work?). Each test confirms one link in the chain.
3. tracert — the path, hop by hop
tracert (traceroute) shows the route taken to reach a destination, step by step. It reveals where the journey breaks: at your end, at the provider, or beyond. By proceeding in order (ipconfig → gateway → external IP → name → tracert), you always know how far connectivity works — and therefore where the failure lies.
🔎 Concrete example — 🔎 Concrete example — A diagnostic sequence
On a “no more Internet”, Sofiane runs the sequence:
> ipconfig - 192.168.1.23 (config OK)
> ping 192.168.1.1 - reply (gateway OK)
> ping 8.8.8.8 - request timed out <- it jams here
Reading : config + local network healthy, Internet unreachable
Diagnosis : failure upstream of the gateway (box/line/ISP)Reading: the configuration and the local network are healthy, but the Internet is unreachable.
Lesson: the problem is upstream of the gateway; tracert will specify at which hop it blocks.
Section vocabulary
- ipconfig
- Displays the local IP configuration: address, mask, gateway and DNS servers.
Simple example: Sofiane reads 192.168.1.23 as a first troubleshooting reflex.
What it is not: a command that tests whether a target answers.
Reflex: see my config → ipconfig.
- ping
- Tests whether a target answers on the network.
Simple example: Sofiane pings the gateway then an external address.
What it is not: the command that follows the path hop by hop.
Reflex: does it answer? → ping.
- tracert / traceroute
- Shows the hop-by-hop path to a destination and where it stops.
Simple example: Sofiane runs tracert to locate the hop that is blocking.
What it is not: the command that displays the local configuration.
Reflex: where it breaks → tracert.
- Gateway ping
- Test that confirms the local network is reachable before aiming further.
Simple example: The gateway 192.168.1.1 answers: the LAN is healthy.
What it is not: a test on a remote server outside the local network.
Reflex: local network OK? → ping the gateway.
- Nearest-to-farthest method
- Diagnosing from the local workstation towards the remote network, step by step.
Simple example: Sofiane follows the order ipconfig, gateway, external IP, name, tracert.
What it is not: testing servers at random without order.
Reflex: from the nearest to the farthest, always.
In practice — In practice — Locating the failure from the local to the remote
- ipconfig: confirm a healthy configuration (address, mask, gateway, DNS), like Sofiane.
- Ping the gateway (local network), then an external IP (Internet), then a name (DNS).
- Deduce where the failure is located: config, LAN, Internet or DNS.
- If a remote service stays unreachable, run tracert to see where the path breaks.
Step-by-step script — Sofiane's diagnostic sequence (5 min)
1) ipconfig: check address, mask, gateway and DNS. 2) ping the gateway (e.g. 192.168.1.1): is the local network reachable? 3) ping an external IP (e.g. 8.8.8.8): is the Internet reachable? 4) ping a name (e.g. example.com): does the DNS work? 5) If a remote service stays unreachable, tracert to locate the hop that is blocking. Note each result.
A failed ping remains a clue, not a verdict: ICMP may be filtered, notably on large servers.
Copy-paste template — my troubleshooting sequence
1) ipconfig 192.168.1.23 -> healthy config?
2) ping 192.168.1.1 -> gateway (LAN) answers?
3) ping 8.8.8.8 -> external IP (Internet) answers?
4) ping example.com -> name (DNS) resolves?
5) tracert -> where does the path break?
Conclude: config | LAN | Internet | DNS | pathAbnormal local config
ipconfig shows 169.254: Sofiane fixes the addressing before even testing further.
Mute gateway
ping to the gateway with no reply: the problem is in the local network (cable/switch).
Name KO, IP OK
The external IP answers but not the name: Sofiane switches to the DNS lead.
Broken path
tracert stops at a specific hop: Sofiane locates the break at the ISP or beyond.
✓ Best practices
- Always diagnose from the nearest to the farthest.
- A failed ping ≠ dead machine (ICMP may be filtered).
- Run tracert only if a remote service stays unreachable.
✗ Common pitfalls
- Concluding “server down” on a filtered ping.
- Skipping
ipconfigand testing at random. - Forgetting to test the name after the address (DNS).
Key takeaways
- Order: ipconfig → ping gateway → ping Internet → ping a name → tracert.
- Local config missing (169.254) → fix it here first.
- Ping by name KO but by IP OK → DNS.
- tracert reveals where the path breaks.
48h challenge — apply it tomorrow
Like Sofiane, run the complete sequence on your workstation: ipconfig, then ping the gateway, then ping an external IP, then ping a name. Note the four results and conclude in one sentence: at which link does connectivity stop in your case? Finish with a tracert to an external destination.
- I know the order of the commands: ipconfig, ping, tracert.
- I can interpret a ping by name and by IP.
- I locate a failure from the local workstation all the way to the remote network.
Frequently asked questions
In what order should I run the commands?
ipconfig, then ping gateway, then ping external IP, then ping a name, then tracert if needed — from the nearest to the farthest.
A ping fails — is the machine necessarily down?
No: many servers and firewalls ignore ping (ICMP). A failed ping is a clue, not a verdict; cross-check with other tests.
In what order should a network failure be diagnosed from the nearest to the farthest?