Network Troubleshooting

Week of 2026-11-10 · Download .docx

Objectives

Apply systematic network troubleshooting methodology
Use Windows network commands to diagnose issues
Identify common causes of APIPA, DNS failure, and DHCP scope exhaustion

Key terms

ping 127.0.0.1: Tests local TCP/IP stack without any network traffic leaving the machine.
tracert: Windows command mapping hop-by-hop routing path to a destination using TTL.
netstat: Displays active TCP/UDP connections, listening ports, and network statistics.
ipconfig /release: Returns current DHCP lease to the server.
ipconfig /renew: Requests a new DHCP lease from the server.
ipconfig /flushdns: Clears local DNS resolver cache to force fresh DNS lookups.
nslookup: Queries a DNS server to verify hostname-to-IP resolution.
APIPA: 169.254.x.x self-assigned address when DHCP server is unreachable.
Duplicate IP: Two devices sharing the same IP address, causing intermittent failures for both.
DHCP scope exhaustion: All addresses in the DHCP pool are leased; new devices receive APIPA.
Cable tester: Physical layer tool verifying cable continuity, pinout, shorts, and opens.
DNS failure: Name resolution fails; device can reach IPs but not hostnames.

The concept

SYSTEMATIC TROUBLESHOOTING METHODOLOGY

Network problems should be diagnosed from the inside out, starting at the most local point and moving outward. Step 1: ping 127.0.0.1 — if this fails, the local TCP/IP stack is not initialized. Step 2: ping the default gateway (router's LAN IP) — failure here means the local network or physical layer is the problem. Step 3: ping an external IP (8.8.8.8) — success proves internet routing works. Step 4: ping an external hostname (google.com) — if Step 3 works but Step 4 fails, the problem is DNS.

COMMON SYMPTOMS AND CAUSES

APIPE address (169.254.x.x): DHCP server unreachable — check cable, DHCP service, and scope. DNS failure: can ping 8.8.8.8 but not google.com — run nslookup to verify DNS server response; run ipconfig /flushdns to clear stale cache. Duplicate IP: both devices experience intermittent errors and Windows shows a duplicate IP notification. DHCP scope exhaustion: the pool is full; new devices get no lease — check lease duration and consider increasing scope or shortening lease time.

TROUBLESHOOTING TOOLS

ipconfig /all shows the full IP configuration including MAC address, DHCP server, and DNS servers — essential for confirming what the client received. tracert maps the route packets take, revealing which hop drops or delays packets. netstat -an shows all listening ports and established connections — useful for identifying unauthorized services or confirming a service is listening. A cable tester verifies the physical layer when everything else seems correct — a broken wire or miswired connector can cause intermittent failures that are invisible in software.

Worked examples

Example 1: A user reports intermittent internet connectivity. Both this user's PC and their neighbor's workstation show connection errors at the same times. Diagnosis: classic duplicate IP conflict. Run 'arp -a' on both machines — if they share the same IP in the ARP table, confirm conflict. Resolution: identify which device has a static IP set incorrectly and change it to a different address or configure it for DHCP.

Example 2: Fifteen new laptops are deployed to a conference room but none get IP addresses. All show 169.254.x.x addresses. Diagnosis: DHCP scope exhaustion. Log into the DHCP server and check the scope statistics. If all leases are active, either expand the scope range, reduce lease duration to free up expired addresses, or add a second scope.

Common mistakes

Skipping the loopback ping (127.0.0.1) and going straight to pinging the gateway — missing a diagnostic step.
Assuming DNS failure means internet is down — if 8.8.8.8 is reachable, the internet works; only name resolution is broken.
Using nslookup without specifying a DNS server — the default server may itself be the problem.
Confusing DHCP scope exhaustion (pool full) with DHCP service crash (no responses at all).
Forgetting that a cable tester only verifies the cable — it cannot tell you anything about Layer 3 or higher issues.

Self-check

Try each question before reading the answer. Answers at the bottom of this page.

1. ping 127.0.0.1 tests:

Local TCP/IP stack only
The default gateway
The DNS server
The ISP's server

2. A user can ping 8.8.8.8 but not google.com. The cause is:

DNS failure
Default gateway offline
NIC driver corrupted
Firewall blocking HTTPS

3. 'ipconfig /flushdns' clears:

Local DNS resolver cache
DHCP lease
ARP cache
Routing table

4. The first step in systematic troubleshooting is:

ping 127.0.0.1
ping default gateway
ping 8.8.8.8
ping google.com

5. A cable tester verifies:

Continuity, correct pinout, shorts, and opens
Network bandwidth throughput
Duplicate IP addresses
Rogue wireless access points

Self-check answers

1. A — 127.0.0.1 is loopback — it tests the local stack without any external network traffic.
2. A — Successful IP ping proves connectivity; failing hostname ping points to DNS failure.
3. A — flushdns clears the cached DNS entries to force fresh lookups.
4. A — Start at the local TCP/IP stack and work outward to isolate the failure layer.
5. A — Cable testers work at Layer 1, verifying the physical wire integrity of a cable.

Canvas is the official record. This companion enhances the PGCC curriculum; it does not replace it. Last name and class year only. Students with a 504 plan or IEP: your accommodations apply.

↑ Back to top