Troubleshooting Network Connectivity at the Help Desk

Objective. Learners will use command-line tools and the OSI model as a diagnostic framework to isolate and resolve simulated network connectivity issues reported by end users.

When an end user calls the help desk and says "I can't get to the internet" or "I can't reach the file server," your job is to find the root cause quickly and fix it systematically. Two tools help you do that every time: the OSI model as a diagnostic framework, and a set of built-in Windows command-line utilities.

Using the OSI Model as a Troubleshooting Framework

The OSI model has seven layers. At the help desk, you almost always work from the bottom up — physical first, then logical. This approach prevents you from chasing a software problem when a cable is simply unplugged.

Layer 1 – Physical: Is the cable seated? Is the NIC link light on? Is Wi-Fi enabled?
Layer 2 – Data Link: Is the correct network adapter active? Is there a valid MAC address?
Layer 3 – Network: Does the machine have a valid IP address, subnet mask, and default gateway?
Layer 4 – Transport: Are the right ports open? Is a firewall blocking traffic?
Layer 7 – Application: Is DNS resolving hostnames? Is the correct service running?

Working bottom-up keeps you from wasting time. If Layer 1 is broken, nothing above it matters.

The Five Core Command-Line Tools

ipconfig

Run `ipconfig /all` to see the full IP configuration of every adapter. Look for:

A valid IP address (not 169.254.x.x — that is an APIPA address, which means DHCP failed)
A subnet mask that matches the network
A default gateway address
DNS server addresses

If you see an APIPA address, the machine could not reach a DHCP server. You can try `ipconfig /release` followed by `ipconfig /renew` to request a new lease.

ping

`ping` sends ICMP echo requests and measures round-trip time. Use it in a logical sequence:

1. `ping 127.0.0.1` — tests the local TCP/IP stack

2. `ping <your own IP>` — confirms the NIC is bound correctly

3. `ping <default gateway>` — tests Layer 3 connectivity to the router

4. `ping 8.8.8.8` (or another public IP) — tests internet reachability without DNS

5. `ping google.com` — tests DNS resolution

If step 4 works but step 5 fails, the fault is DNS, not routing.

tracert

`tracert <destination>` shows every hop between your machine and the destination. Each line is a router. If traffic stops at a particular hop, that is where the problem lives — either a failed router or a firewall blocking ICMP. This tool is most useful after you confirm basic IP settings are correct.

nslookup

`nslookup <hostname>` queries the configured DNS server directly. If it returns the correct IP, DNS is working. If it returns a timeout or "server can't find" error, the DNS server address is wrong, the DNS server is down, or the hostname record does not exist. You can also specify an alternate server: `nslookup google.com 8.8.8.8` to test against a known-good public resolver.

netstat

`netstat -an` lists all active TCP and UDP connections and listening ports. Use it to confirm that a service is listening on the expected port, or to spot unexpected connections that might indicate a security issue. For help desk work, the most common use is confirming whether a required application port is open or blocked.

The Six-Step Troubleshooting Model

CompTIA formalizes network troubleshooting in six steps. Memorize these — they appear on both A+ and Network+ exams, and you will use them in every incident report.

1. Identify the problem — gather information, question the user, duplicate if possible

2. Establish a theory of probable cause — consider obvious causes first (bottom-up or top-down)

3. Test the theory — run commands; if the theory is confirmed, move to step 4; if not, form a new theory

4. Establish a plan of action — determine the fix and any side effects

5. Implement the fix — make the change; verify full functionality

6. Document findings, actions, and outcomes — write the incident report

Documentation is not optional. It protects you legally, helps the next technician, and satisfies organizational change-management policies.

Three Common Seeded Faults

|---|---|---|---|

Safety and Professional Conduct

While electrical hazards are limited when working at a desktop PC, follow standard precautions: use an anti-static wrist strap when opening cases, and never work inside a powered server without verifying the power state. More relevant at the help desk is data safety — never share another user's account credentials to test connectivity, and do not leave a command prompt open on someone else's machine. Always obtain proper authorization before changing firewall rules or network settings on a production system; unauthorized changes can violate organizational policy and, in some environments, federal law.

Key terms10

OSI ModelA seven-layer conceptual framework that describes how data moves through a network; used as a structured reference for isolating connectivity problems layer by layer.

APIPA (Automatic Private IP Addressing)A Windows feature that assigns an address in the 169.254.0.0/16 range when a DHCP server cannot be reached, indicating a DHCP failure.

Default GatewayThe router IP address that a host sends traffic to when the destination is outside the local subnet; a missing or incorrect gateway prevents off-network communication.

DNS (Domain Name System)The service that translates human-readable hostnames such as google.com into IP addresses; misconfigured DNS allows IP connectivity but breaks name-based access.

ICMP (Internet Control Message Protocol)The protocol used by ping and tracert to send echo requests and receive replies; some firewalls block ICMP, which can make a working path appear broken.

Six-Step Troubleshooting ModelThe CompTIA-defined process: identify the problem, establish a theory, test the theory, establish a plan of action, implement the fix, and document findings.

tracertA Windows command that displays each router hop between a source and destination, helping identify where traffic stops on a network path.

netstatA Windows command that displays active network connections and listening ports, used to verify whether a service is running and accessible on the expected port.

ipconfigA Windows command that displays IP address, subnet mask, default gateway, and DNS settings for all network adapters on a machine.

nslookupA Windows command-line tool that queries DNS servers directly to test name resolution and identify DNS configuration errors.

In class: Instructor reviews OSI-layer troubleshooting logic (physical first, then logical) and demonstrates ipconfig, ping, tracert, nslookup, and netstat on a lab machine with a seeded connectivity fault; learners follow along and record output. · Each learner receives a lab machine with one of three seeded faults (bad IP configuration, DNS misconfiguration, blocked port): they run the command sequence, interpret output, correct the fault, and confirm connectivity restoration. · Learners write a one-page incident report for their assigned fault using the six-step troubleshooting model, then present the report to a partner who asks two clarifying questions.
Materials: Lab PCs on a switched network with instructor-controlled faults, command-line tools (built into Windows), OSI reference card, CompTIA Network+ Study Guide (Mike Meyers or equivalent), incident report template
Check: Instructor evaluates both the live fix (connectivity restored without hints) and the incident report (six steps present, commands correctly interpreted, resolution accurate). Both components must score 80% or higher.

Practice check8

Answer each question, then check it. Nothing is recorded; this is your own practice.