English:Network Troubleshooting
Network Troubleshooting
Introduction
Network troubleshooting is the structured process of finding, explaining, correcting, and documenting faults in a computer network. In vocational work, a good technician does more than make a connection work again: you collect evidence, protect users and systems, test one change at a time, and leave a clear record for the next person.
This aiMOOC is designed for apprentices, trainees, and vocational students in IT support, network administration, electronics, and related technical fields. You will practise a repeatable method for wired and wireless networks, learn the purpose and limits of common diagnostic commands, interpret typical symptoms, and decide when to repair, monitor, or escalate a fault.
A switch with multiple connected Ethernet cables is a useful reminder that one user-visible fault can involve many components: the end device, cable, switch port, VLAN, router, DNS service, firewall, wireless access point, or remote application.
Learning Goals
After completing the course, you should be able to explain a professional troubleshooting workflow, distinguish physical from logical faults, inspect an IP configuration, test reachability and name resolution, interpret basic traceroute and packet-capture evidence, recognise performance symptoms, document your work, and escalate with useful technical evidence.
You should also be able to choose a diagnostic tool because of the question it can answer. A tool is not a diagnosis by itself. A failed ping, for example, can mean loss of reachability, filtering of ICMP traffic, a local configuration problem, or a remote device that does not answer echo requests.
A Professional Troubleshooting Workflow
A reliable workflow reduces guessing. Start by defining the symptom and scope. Ask what changed, when the problem began, who or what is affected, whether the problem is constant or intermittent, and what should happen when the system is healthy. Record the time, device, interface, network, user report, and error message.
Then form a testable hypothesis. Begin with low-risk observations before making changes. Compare a failing device with a working device on the same network when possible. Change only one relevant factor at a time. Retest the original service after every corrective action. If the repair creates a new risk, violates policy, or requires permissions you do not have, stop and escalate.
A practical cycle is: identify the problem, establish a theory, test the theory, plan and implement a safe fix, verify full functionality, and document the result. In real workplaces, you may loop through the theory and testing stages several times.
Scope Before Detail
The scope tells you where to look. If one laptop is affected but nearby devices work, suspect the laptop, its cable, its wireless association, or its local configuration. If an entire room is affected, consider a switch, access point, VLAN, power source, or uplink. If several sites are affected, consider shared routing, WAN, DNS, authentication, firewall, or provider services.
Do not assume that a visible application error identifies the faulty layer. A browser that says a page cannot be reached might be reporting a DNS failure, a routing failure, a blocked port, a certificate or proxy problem, or a remote service outage.
Use a Layered Strategy
You can troubleshoot bottom-up, top-down, or by dividing the problem space. A bottom-up check starts with power, link, cabling, radio connectivity, and interface state before moving to IP configuration and applications. A top-down check starts with the failed service and works toward lower layers. A divide-and-conquer approach tests a middle point such as the default gateway and then narrows the search depending on the result.
A topology diagram helps you identify dependencies and likely failure domains. In a workplace, use an up-to-date network diagram, port map, VLAN list, addressing plan, and change record whenever they are available.
Physical and Link Checks
Begin with facts you can observe safely. Confirm power, link indicators, correct port, cable seating, obvious damage, wireless radio state, and whether the interface is enabled. Compare the suspected cable or port with a known-good one only when workplace procedures permit it. Do not move production cables, disable ports, or reboot shared equipment without authorization.
An Ethernet plug can look connected while still having a wiring, termination, strain, or contact problem. A cable tester can detect common continuity and wire-map faults, but a simple tester does not prove that a cable meets every performance requirement of its category.
Check the switch side as well. A link light shows that a physical link has negotiated, but it does not prove that the correct VLAN, IP configuration, gateway, DNS service, or application is working.
Wireless Checks
For Wi-Fi, confirm that the client is associated with the intended network, not merely that the Wi-Fi icon is visible. Check signal quality, distance, obstacles, roaming behaviour, channel congestion, authentication, and whether other clients have the same symptom. A strong radio signal does not guarantee Internet access because DHCP, VLAN, routing, DNS, firewall, or upstream services may still fail.
When testing wireless performance, keep the test method consistent. Compare the same client in two locations, or compare two clients in the same location. Document the access point, time, signal information, and measured result so that later tests are meaningful.
Inspect the Client Configuration
A host needs a usable interface configuration before most network services can work. Important values include the IP address, prefix length or subnet mask, default gateway, and DNS resolver. On managed networks, DHCP often supplies these automatically.
On Windows, ipconfig shows basic IPv4 and IPv6 information, while ipconfig /all shows more detail. On Linux, ip address shows interface addressing and ip route shows routing information. The exact commands available depend on the operating system and installed tools.
When you compare a failing host with a working host, ask whether they are on the same expected subnet, use the same gateway and DNS environment, and have the same VLAN or wireless network. Do not copy another host's address manually; that can create an address conflict.
An IPv4 address in the 169.254.0.0/16 link-local range can appear when a host does not obtain a normal IPv4 configuration from DHCP. Treat it as a clue, not a complete diagnosis: verify the interface, DHCP path, VLAN, and server availability.
Build a Connectivity Test Ladder
Use a sequence of tests that answers progressively broader questions. A typical ladder is:
- Loopback: Can the local TCP/IP stack respond?
- Local network interface: Is the host using the expected local address?
- Default gateway: Can the host reach its local router?
- Remote IP address: Is there routed reachability beyond the local network?
- DNS name: Can the host resolve and reach a named destination?
- Application service: Can the required protocol and port complete the task?
The order is a diagnostic aid, not an absolute rule. Security controls can block one test while the real application still works.
Ping: Reachability and Delay Clues
ping sends ICMP echo requests and reports replies when they return. It is useful for testing IP-level reachability and observing round-trip time. A successful result shows that an IP path and a return path for the permitted ICMP traffic existed during the test.
A failed ping does not prove that the destination is down. Firewalls and hosts can block or rate-limit ICMP echo. Use ping as one item of evidence and compare it with the service you actually need.
A useful diagnostic comparison is to test a known remote IP address and then a hostname. If the IP test works but the hostname test fails, investigate name resolution. If neither works, investigate addressing, gateway, routing, filtering, or upstream connectivity before blaming DNS.
Traceroute: Path and Hop Clues
Windows uses tracert; many Unix-like systems use traceroute or a related tool such as tracepath. These tools use increasing TTL or hop-limit values so that intermediate routers can reveal parts of the path toward a destination.
A missing hop is not automatically a broken hop. Some routers do not answer traceroute probes or treat them differently from normal application traffic. Look for patterns: where responses stop, where delay changes, whether the destination eventually answers, and whether repeated tests behave consistently.
Test DNS Separately
The Domain Name System maps names to records such as IPv4 and IPv6 addresses. A network can have working IP connectivity while name resolution is broken. On Windows, nslookup can query DNS information. On Linux and other systems, tools such as dig, host, or resolvectl may be available.
Test the name that matters to the user. Then compare the result with a known working resolver or with a working client on the same managed network, if policy allows. Check for timeouts, unexpected addresses, wrong search domains, stale cache entries, or a resolver that cannot be reached.
The packet-capture image above shows how a DNS request can be broken into Ethernet, IP, UDP, and DNS fields. Packet analysis is useful when simple command results are not enough.
Ports, Services, and Firewalls
An application can fail even when ping works. Web, mail, file, voice, and database services depend on specific protocols, ports, certificates, proxies, authentication systems, and server processes. Test the service itself.
On Windows, Test-NetConnection can test TCP connectivity to a chosen port. On many systems, curl can test HTTP or HTTPS behaviour. Tools such as netstat or ss can show local listening sockets and connections. Use only tools that are permitted in your workplace and interpret their output in context.
A blocked port may be caused by a local firewall, network firewall, security group, access-control list, proxy policy, or a service that is not listening. Do not weaken security controls just to make a test pass. Gather evidence and follow the change process.
Packet Capture with Wireshark
Wireshark is a packet analyser that can display protocol conversations in detail. It can help you verify whether DNS queries receive answers, whether TCP handshakes complete, whether resets occur, and whether repeated transmissions suggest loss or delay.
Useful display filters for beginner labs include icmp, dns, and tcp.port == 443. Capture only on networks and devices where you have explicit authorization. Packet captures may contain credentials, identifiers, business data, or personal information, so handle them according to policy.
Performance Troubleshooting
A connection can be available but still unusable. Separate availability from performance. Measure latency, packet loss, throughput, and stability over time. Compare results with a baseline or service requirement rather than assuming that one speed-test number is sufficient.
High latency can result from distance, congestion, queueing, overloaded equipment, wireless contention, or an inefficient path. Packet loss can cause retries and poor voice, video, or interactive performance. Low throughput can result from congestion, radio conditions, rate limits, server constraints, duplex or negotiation problems, or a slow end system.
For intermittent faults, timestamps are essential. Record when the issue occurs, how long it lasts, which users and services are affected, and what monitoring data shows at the same time.
Documentation and Escalation
A professional ticket should allow another technician to understand what happened without repeating every test. Record the original symptom in the user's words, affected devices and locations, start time, scope, relevant configuration, tests performed, results, changes made, verification, and final status.
Escalate when the fault is outside your access level, crosses a provider or security boundary, requires a risky production change, involves suspected compromise, or remains unresolved after reasonable testing. Good escalation includes evidence, not just the phrase "network problem."
Example Fault Record
| Field | Example |
|---|---|
| Symptom | Training workstation cannot open internal web portal |
| Scope | One workstation affected; neighbouring workstation works |
| Physical check | Link active; known-good patch lead gives same result |
| Configuration | Unexpected link-local IPv4 address; no default gateway |
| Test result | Gateway unreachable; other workstation reaches gateway |
| Working theory | Client is not receiving expected DHCP configuration |
| Next action | Check switch VLAN and DHCP path, then retest according to authorization |
| Verification | Portal loads after valid address, gateway, and DNS settings are restored |
The example shows how one piece of evidence changes the next test. It does not assume that every link-local address has the same cause.
Troubleshooting Decision Guide
| Observation | Useful next question | Possible next test |
|---|---|---|
| No link on wired interface | Is the physical path intact and enabled? | Inspect cable, port, power, interface state, and known-good alternatives |
| Valid local address but gateway unreachable | Is the local subnet or VLAN path working? | Compare port, VLAN, ARP or neighbour information, and another client |
| Gateway reachable but remote IP unreachable | Is routing or upstream access failing? | Test another remote IP and examine route or traceroute evidence |
| Remote IP reachable but hostname fails | Is name resolution failing? | Query DNS directly and compare resolver settings |
| Hostname resolves but application fails | Is the required service or port available? | Test the application protocol and relevant TCP or UDP path |
| Service works but is slow | Is the problem latency, loss, throughput, or server response? | Measure over time and compare with a baseline |
Interactive Tasks
Quiz: Test Your Knowledge
What should you establish before making major changes to a network? (The symptom and scope of the problem) (!The brand of every switch) (!The colour of every patch cable) (!The operating system wallpaper)
What does a successful ping most directly show? (The tested IP path returned ICMP echo replies) (!The DNS server is definitely healthy) (!Every application port is open) (!The network has no packet loss anywhere)
Which clue most strongly suggests a DNS problem? (A remote IP works but the hostname fails) (!The Ethernet cable is unplugged) (!The switch has no power) (!The local interface is disabled)
What is the main purpose of traceroute or tracert? (To reveal parts of the path toward a destination) (!To repair a damaged cable) (!To assign a permanent IP address) (!To encrypt all network traffic)
Why should you change one relevant factor at a time? (To preserve cause and effect during testing) (!To make the ticket longer) (!To bypass change control) (!To avoid documenting results)
What can a cable tester help detect? (Common continuity and wire-map faults) (!Incorrect DNS records on the Internet) (!A blocked web application account) (!A remote server certificate error)
What does a link light fail to prove? (That the required network service is working) (!That a physical link has negotiated) (!That the interface has electrical activity) (!That the port can detect a connection)
Which tool is commonly used to inspect DNS answers? (nslookup) (!format) (!shutdown) (!taskkill)
Why must packet captures be handled carefully? (They can contain sensitive network data) (!They always erase switch settings) (!They permanently change IP addresses) (!They automatically disable firewalls)
What makes an escalation useful to the next technician? (Clear evidence of scope tests results and changes) (!Only the words network problem) (!A guess without test results) (!A request to repeat every test)
Memory Game
| Ping | Tests IP reachability using echo requests and replies |
| Traceroute | Reveals intermediate path information toward a destination |
| Resolver | Answers or forwards DNS name queries |
| Gateway | Forwards traffic from the local network toward other networks |
| DHCP | Supplies automatic network configuration to clients |
| Latency | Time delay measured across a network path |
| Wireshark | Analyses captured network packets |
| Baseline | Reference measurement used for later comparison |
Drag and Drop
| Match the correct terms. | Topic |
|---|---|
| Physical inspection | No wired link light |
| DNS query | IP address works but hostname fails |
| Traceroute | Need to inspect the path toward a remote site |
| Port test | Host responds but web service does not |
| Performance baseline | Users report that the service is unusually slow |
...
Crossword Puzzle
| Gateway | Which device forwards traffic from a local network toward other networks? |
| Latency | What term describes delay across a network path? |
| Traceroute | Which tool reveals intermediate hops toward a destination? |
| Resolver | What DNS component answers or forwards name queries? |
| Ethernet | Which common wired LAN technology uses frames and network links? |
| Firewall | Which security control may allow or block network traffic according to rules? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- Network Fault Vocabulary: Create a one-page illustrated glossary of twelve troubleshooting terms and explain each term in your own words for a new apprentice.
- Cable Inspection: With instructor permission, photograph or draw a correct Ethernet connection and annotate the connector, cable, switch port, and link indicator.
- Support Interview: Interview a classmate acting as a user and write five questions that reveal symptom, scope, timing, and recent changes without suggesting the answer.
- Troubleshooting Flowchart: Draw a simple flowchart that starts with one device unable to reach a website and shows safe checks before any configuration change.
Standard
- Command Comparison: Run permitted network commands on a training computer, capture the outputs of configuration, ping, DNS, and route tests, and explain what question each command answers.
- Known-Good Comparison: Compare a working and a deliberately misconfigured training client, identify three differences, and produce a short diagnostic report without copying settings blindly.
- Wireless Survey: In an approved training area, record Wi-Fi signal and performance at several locations, create a labelled map or chart, and explain which observations are evidence and which are hypotheses.
- Troubleshooting Video: Produce a three-minute instructional video that demonstrates a safe test ladder from local configuration to application service and includes one example of a misleading result.
Advanced
- Packet Analysis Project: In an authorised lab, capture DNS and web traffic, identify the request and response sequence, and create annotated screenshots that explain how the packets support your diagnosis.
- Intermittent Fault Experiment: Design a repeatable lab experiment for an intermittent connectivity problem, collect timestamped evidence over multiple trials, and decide what additional monitoring would reduce uncertainty.
- Network Technician Interview: Interview a network or support professional about a difficult incident, then compare their troubleshooting method with the workflow in this course while removing confidential details.
- Escalation Simulation: Analyse a multi-layer fault scenario, decide which tests you can perform at your role level, produce an escalation package for the next support tier, and defend why your evidence is sufficient.
Learning Assessment
- Fault Isolation Case: Given a workstation with a valid local address, reachable gateway, working remote IP test, and failing hostname test, explain the most likely fault domain and design two tests that could confirm or reject your theory.
- Evidence Evaluation: Compare a failed ping with a successful HTTPS connection to the same host and explain why the two results are not contradictory.
- Layered Diagnosis: For a training room in which every wired client loses access at the same time, rank three plausible failure domains, state the evidence needed for each, and justify the order of your tests.
- Performance Analysis: Interpret a set of latency, loss, and throughput measurements taken at different times and decide whether the evidence points more strongly to congestion, a local client fault, or a remote service issue.
- Change Risk Review: Evaluate a proposed fix that disables a firewall rule to restore access, identify the risks, and propose a safer diagnostic or change-control approach.
- Technical Escalation: Write an escalation note from a provided fault log that separates confirmed facts, working hypotheses, completed tests, unresolved questions, and the exact support needed from the next team.
Evidence of Learning
Knowledge: You can explain the roles of Ethernet, Wi-Fi, IP addressing, the default gateway, DHCP, DNS, ICMP, routing, ports, firewalls, and packet analysis in a troubleshooting context.
Skills: You can define scope, inspect physical and logical state, choose appropriate diagnostic commands, compare working and failing systems, interpret results cautiously, verify repairs, and follow authorization boundaries.
Products: Your evidence may include a fault ticket, annotated network diagram, command-output log, measurement table, packet-capture analysis, troubleshooting flowchart, short instructional video, or escalation report.
Transfer: You can apply the same evidence-based workflow to unfamiliar networks, different operating systems, wired or wireless access, and new application services without relying on one memorised command sequence.
Professional practice: You distinguish observation from hypothesis, protect sensitive information, make controlled changes, communicate clearly with users and colleagues, and know when to escalate.
OERs on the Topic
For broad background reading, this course embeds the English Wikipedia article on computer networks.
Reliable Reference Resources
For command syntax and current platform details, consult the official documentation for the system you are using. Useful references include Microsoft Learn: ping, Microsoft Learn: ipconfig, Microsoft Learn: tracert, Microsoft Learn: nslookup, and Cisco: Extended Ping and Extended Traceroute.
For protocol analysis, use the official Wireshark documentation and practise only in authorised environments. For DNS background, compare the course explanation with reliable technical documentation such as Cloudflare Learning Center: What is DNS?.
Linked Learning Areas
This topic connects hardware, operating systems, TCP/IP, services, security, documentation, and customer support. A competent troubleshooter moves between these areas while keeping evidence and risk in view.
