Chapter 1

Common network issues

Last updated November 20264 sectionsabout 9 min read

Key takeaways

Diagnose in order from the quickest, most local check to the most involved: hardware, ipconfig, ping and tracert, a DNS check, the ISP, malware, then the system logs.
A large share of reported faults are a loose or unplugged cable, which is why the hardware is checked before any software or configuration theory.
When a ping to an external IP address succeeds but the same destination fails by name, the fault is isolated to DNS, and nslookup confirms it.
A fault passes through four stages before it can be fixed: reporting, detection, classification and location.
Isolate the problem by ruling out what works rather than replacing parts speculatively, and close a fault only once testing shows the original symptom is gone and nothing new has broken.

A network fault is only ever solved as fast as it is correctly identified, and identifying it well means following a deliberate procedure, not guessing. This chapter covers the standard order of checks a technician works through, the distinct stages a fault passes through from first report to confirmed fix, and the discipline of isolating a problem before attempting to solve it.

Procedures for network problem diagnosis

The procedure below is worked roughly in order from quickest and most local to most involved and most external, so that cheap checks rule out simple causes before time is spent on anything more elaborate.

Check the hardware: cables, power, link lights, before assuming a software or configuration fault, since a large share of reported faults are a loose or unplugged cable
Use ipconfig (or ifconfig) to confirm the device's own IP configuration is correct: the right address, subnet mask and default gateway for its network
Use ping and tracert (traceroute) to confirm connectivity and trace where along the path a connection is failing
Perform a DNS check (nslookup) to rule out a name-resolution problem masquerading as a connectivity problem, since 'the website will not load' and 'the network is down' look identical to a user but are very different faults
Contact the ISP where the fault appears to be outside the organisation's own network, once everything internal has been ruled out
Check for virus and malware infection, which can degrade or disrupt network behaviour in ways that mimic a hardware or configuration fault
Review system logs for errors or warnings that point directly to the cause, often the fastest route to an answer once the broad category of fault is already narrowed down

Distinguishing a connectivity fault from a DNS fault
A user reports 'the internet is not working' after trying to open a website in a browser.
Step 1, hardware: the network cable is seated and the link light on the NIC is on, so a purely physical fault is ruled out.
Step 2, ipconfig: the device shows a valid IP address, subnet mask and default gateway on the correct subnet, ruling out a local addressing fault.
Step 3, ping the default gateway by its IP address: four replies, low and consistent round-trip time, confirming the device can reach the local network and its router.
Step 4, ping a known external IP address directly (not a name, an address): four replies, confirming the device can reach the internet at the IP level, so the fault is not a general connectivity failure.
Step 5, ping the same external destination by its domain name instead of its IP address: this fails, or returns 'could not find host'. Since the IP-address ping succeeded but the name-based ping failed, the fault is isolated specifically to DNS, not to connectivity, and nslookup is run next to confirm which DNS server is failing to resolve the name.
This is exactly why the diagnostic order matters: jumping straight to 'restart the router' would have wasted time on a working router, while the systematic order isolated the fault to one specific layer, name resolution, within five short steps.

Isolating the fault: hardware through DNS

Each of the first four checks passes, ruling out hardware, local addressing, local connectivity and general internet connectivity in turn. Only the fifth check, pinging by name instead of by IP address, fails, isolating the fault to DNS specifically, exactly the systematic narrowing the worked example describes and the reason jumping straight to 'restart the router' would have wasted time on a working router.

Fault determination and identification

A fault passes through four distinct stages before it can be fixed, and treating them as one undifferentiated step is what makes troubleshooting feel chaotic rather than systematic.

Fault reporting

Recording the fault, when it started, its symptoms and who is affected, the starting point for any investigation and the record a technician returns to if the first theory turns out wrong.

Fault detection

Identifying that a fault exists at all, sometimes before a user even reports it, through monitoring (the maintenance schedule in Network Operating Systems) that catches a problem developing before it becomes a full outage.

Fault classification

Categorising the fault by type (hardware, software, configuration, external) and severity, to prioritise it correctly against other work and route it to the right person or team.

Fault location

Narrowing down exactly where in the network the fault originates, the specific device, link or configuration setting responsible, which is what the diagnostic procedure above is actually for.

Isolating the problem

Isolating the problem means systematically ruling out parts of the network that are working correctly, narrowing the search until the actual faulty component or link is identified, rather than guessing or replacing parts speculatively. The worked example above is isolation in practice: each step either confirmed a layer was working (hardware, addressing, gateway reachability, general internet reachability) or found the one layer that was not (DNS), narrowing the search at every step rather than jumping to a conclusion.

Fault solving and testing

Fault solving applies the fix appropriate to the diagnosed cause: replacing a cable, correcting a configuration, restarting a service, or escalating where the fix is beyond the current level of access or expertise, such as a fault genuinely inside the ISP's own network. Testing then confirms the fix actually resolved the original symptom, and that it did not introduce a new problem elsewhere, before the fault is considered closed; a fault reopened days later because the fix was never actually verified erodes confidence in the whole troubleshooting process faster than almost anything else.

Self-check

(a) List the seven-step diagnostic procedure in order, from quickest to most involved. (7 marks)

(b) State the four stages a fault passes through, from first report to being located. (4 marks)

(c) A user can ping an external IP address directly but cannot reach any website by name. Identify the fault and the tool that would confirm it. (3 marks)

(d) Explain what isolating a problem means and why it is preferred over replacing parts speculatively. (3 marks)

(e) Distinguish fault solving from testing, and explain why closing a fault without testing is risky. (3 marks)

Show worked answer

(a) Check the hardware (cables, power, link lights); use ipconfig/ifconfig to confirm IP configuration; use ping and tracert to confirm connectivity and trace the failure; perform a DNS check; contact the ISP if the fault is external; check for virus or malware infection; review system logs.

(b) Fault reporting, fault detection, fault classification, fault location.

(c) The fault is DNS (name resolution), since IP-level connectivity works but name-based lookup fails. nslookup would confirm it by directly querying DNS and showing whether the lookup succeeds or fails.

(d) Isolating a problem means systematically ruling out working parts of the network to narrow the search until the actual faulty component is identified. It is preferred over speculative replacement because it finds the real cause efficiently and avoids wasting time, money and effort on parts that were never faulty.

(e) Fault solving applies the fix appropriate to the diagnosed cause; testing confirms the fix actually resolved the original symptom and did not introduce a new problem. Closing a fault without testing is risky because the symptom may return, or a different problem may have been introduced unnoticed, and both erode confidence in the troubleshooting process once discovered.

Exam tip

The diagnostic procedure above (hardware, ipconfig, ping/tracert, DNS, ISP, malware, logs) is a reliable general order to work through in a scenario question; start with the simplest, most local checks before escalating outward, and use the worked example's technique, pinging by IP address versus pinging by name, to isolate a DNS fault from a genuine connectivity fault specifically.