Troubleshooting Network and Connectivity Issues. When a server can't talk to another device or the internet, everything stops – users can't access their files, websites go offline, and business grinds to a halt. For the Server+ exam, you need to know how to systematically identify what's broken, from a loose cable all the way up to a misconfigured DNS record. This chapter gives you a repeatable method so you never have to guess.
Jump to a section
A simple way to picture Troubleshooting Network and Connectivity Issues
Ever tried to send a package to a friend's new house, but the courier kept returning it marked 'address unknown'? That's exactly what happens when a server can't find another computer on the network.
Let's say you move into a new flat and tell your friends your new address. Your friend writes it down wrong (DNS misconfiguration) so when they try to mail you a birthday gift the courier reads the wrong street number and delivers it to someone else. That's like typing a website domain name and getting an IP address that belongs to a different server.
Now imagine the courier arrives at your building but the main door is locked and the entry phone is broken (firewall blocking the port). The driver can't get in, so the package goes back. That's a classic 'connection refused' or 'timeout' error.
Or maybe your flat number was written correctly, but the postman drops the box in a puddle (packet loss caused by a faulty Ethernet cable). The gift arrives damaged, same way a corrupted file arrives after lots of retransmissions.
Troubleshooting network issues is like being a postal detective: you check whether the address is right (DNS), whether the building exists (gateway), whether the door is open (firewall), and whether the mail route is clear (cable and switch). Each failed step tells you exactly where to look next.
Troubleshooting network and connectivity issues is the process of finding out why one computer cannot communicate with another over a network. Think of a network as a system of roads, street signs, and delivery trucks. The computers are houses, the switches are local roundabouts, the routers are highway exits, and the DNS server is the address book. When something goes wrong, data packets (the delivery trucks) can't reach their destination.
First, let's talk about the basic components you need to understand. An IP address is like a house number – it uniquely identifies a device on a network. A subnet mask tells the device which part of the IP address refers to its local neighbourhood and which part refers to other towns. The default gateway is the router that connects your local network to other networks, including the internet. A DNS server translates human-friendly names like 'google.com' into IP addresses that computers understand.
When you try to visit a website, your computer sends a DNS query to its configured DNS server. If the DNS server doesn't have the answer, it asks other DNS servers until it finds it. Once your computer knows the IP address of the webserver, it sends a packet to that IP. The packet needs to pass through your switch (which directs traffic within the local network) and then through your router (which forwards it to the internet). Along the way, firewalls and access control lists (ACLs) might allow or block the packet based on its source, destination, and port number.
There are many things that can go wrong at each step. Let's list the common categories of network issues:
Physical connectivity problems: a cable is unplugged, damaged, or loose; a switch or router has lost power; a network interface card (NIC) has failed. These are the easiest to spot because link lights on the hardware often go out.
IP configuration problems: the device has the wrong IP address, subnet mask, or default gateway. This can happen if DHCP (Dynamic Host Configuration Protocol, which automatically assigns IP addresses) fails or if someone sets a static IP incorrectly.
DNS resolution failures: the DNS server is unreachable, is returning the wrong IP, or the domain name doesn't exist.
Routing problems: the router doesn't have a route to the destination network, or the route is misconfigured.
Firewall or ACL blocking: security rules are preventing traffic on the required port (e.g., port 80 for web, port 443 for HTTPS).
Intermittent issues: packet loss due to bad cables, high network congestion, or faulty hardware.
Now, the correct way to troubleshoot is to follow a logical order. The CompTIA troubleshooting methodology is: identify the problem, establish a theory of probable cause, test the theory, plan an action, implement it, verify full functionality, and document everything. In networking, we start with the physical layer and move up.
Practical tools you'll use: - ping – sends ICMP echo requests to test basic reachability. - tracert (Windows) or traceroute (Linux) – shows the path packets take to a destination. - nslookup or dig – queries DNS servers to resolve names. - ipconfig (Windows) or ifconfig (Linux) – shows your IP configuration. - netstat – shows active connections and listening ports. - telnet or Test-NetConnection – test if a specific port is open.
For example, if a user cannot reach a web server at 192.168.1.100, you first ping 192.168.1.100 from their computer. If that fails, you check the physical connection and IP configuration. If pinging the default gateway works but pinging the server doesn't, the problem is between the gateway and the server. If ping to the server works but the web page doesn't load, the issue is at the application layer – maybe the web service isn't running or a firewall is blocking port 80.
Every IT professional memorises this sequence. It replaces random guesswork and ensures you fix the root cause, not just the symptom.
1. Identify the Scope
Ask questions: Is this affecting one user or many? Can they reach any other resources? This tells you whether the problem is local (workstation, cable, switch port) or global (router, DNS, ISP).
2. Verify Physical Connectivity
Check the cable is securely plugged in at both ends. Look at link lights on the NIC and switch port. If lights are off or orange, the physical layer is suspect. Try a known-good cable or a different port.
3. Check IP Configuration
Run ipconfig /all (Windows) or ifconfig (Linux). Confirm the device has an IP address, subnet mask, and default gateway. Look for errors like APIPA addresses (169.254.x.x) which indicate DHCP failure.
4. Test Local Network Connectivity
Ping the default gateway IP. If it fails, the problem is within your local network (bad cable, wrong gateway, or switch issue). If it succeeds, your layer 2 and basic layer 3 are working.
5. Test External Connectivity and DNS
Ping a public IP like 8.8.8.8. If that fails but the gateway ping worked, the issue is beyond your router (ISP or routing). If ping to IP works but name doesn't, use nslookup to test DNS. A failure means the DNS server is unreachable or misconfigured.
6. Verify the Specific Service
Use telnet or Test-NetConnection to check the specific port (e.g., telnet serverIP 443). If the port is blocked, check firewall rules and ACLs. If the connection opens but the service doesn't respond, the application itself may be down.
Imagine you're the only IT support person at a small company with 50 employees. One morning, the head of sales calls you: 'I can't access our CRM system. It's been down for ten minutes.' The CRM is a web application hosted on an internal server at IP 10.0.0.15. You need to resolve this fast.
You start by asking the user a few questions: 'Can you access any other websites? Can you ping the server IP directly? Is anyone else having the same issue?' From the answers, you learn that other users can reach the CRM fine, so the problem is isolated to this one workstation. That already narrows the scope.
You walk over to the salesperson's desk. First, check the physical connection – the Ethernet cable is plugged in securely, and the link light on the network card is green. Good. Next, open a command prompt and run ipconfig /all. You see the IP address is 192.168.1.45, which is wrong. It should be in the 10.0.0.x range. The subnet mask is correct, but the default gateway is 192.168.1.1, which is the wrong router. The workstation is on the wrong VLAN.
This is a classic DHCP issue – the user's computer was assigned an IP from the wrong DHCP server. You check if the computer has a static IP set. It does not. The DHCP server for the 192.168.1.x network is a separate router that shouldn't be handing out addresses to this office. You release and renew the IP address using ipconfig /release followed by ipconfig /renew. This time the computer gets 10.0.0.72, correct gateway 10.0.0.1. Now you try pinging 10.0.0.15 – success. Then you open the web browser and the CRM loads perfectly.
But why did this happen in the first place? You investigate and find that a new wireless access point was installed yesterday, and its built-in DHCP server was enabled accidentally. It was handing out addresses from the wrong scope. You disable DHCP on the access point and document the change.
In a more complex scenario, you might have to analyse firewall logs, run traceroutes to see where packets are dropped, or use nslookup to check DNS records. The key is always to follow the same systematic approach: identify the scope, verify physical layer, check IP configuration, test local connectivity, test gateway, test DNS, then test the specific service. This method works for any network troubleshooting task, whether it's a single user or an entire data centre outage.
The SK0-005 exam tests your ability to identify and resolve network connectivity issues using the CompTIA troubleshooting methodology. Expect questions that describe a symptom and ask you to choose the most likely cause or the next best step. The exam loves to test your knowledge of specific networking commands and their output.
Key concepts that appear frequently:
The difference between a switch (operates at Layer 2, uses MAC addresses) and a router (operates at Layer 3, uses IP addresses).
How DNS resolution works: the order of lookups (local cache, hosts file, DNS server).
Common ports: 80 (HTTP), 443 (HTTPS), 22 (SSH), 3389 (RDP), 53 (DNS), 67/68 (DHCP).
The output of ipconfig /all: you should be able to identify a missing default gateway or a wrong subnet mask.
The output of ping: you need to recognise 'Destination Host Unreachable' (no route to the network) vs 'Request Timed Out' (no response from the host).
Using tracert to find where packets stop.
The use of nslookup to test DNS: especially the difference between an authoritative answer and a non-authoritative answer.
Trap patterns to watch for:
Questions that give you a scenario where ping to the IP works but ping to the domain name fails – they want you to say 'DNS resolution problem'.
Questions that say the user can access the internet but not internal resources – that points to a routing issue or VLAN misconfiguration.
Questions where a cable is suspected but the link light is on – they want you to think about duplex mismatch or speed mismatch.
Questions that involve 'intermittent connectivity' – the answer is often a faulty cable, a misconfigured switch port, or a failing NIC.
You should memorise the OSI model's bottom three layers: Physical (cables, connectors), Data Link (switches, MAC addresses), Network (routers, IP addresses). Also know that troubleshooting should start at Layer 1 (physical) and work upwards.
Another exam favourite: comparing static IP configuration vs DHCP. If a device has a static IP but is on a network that uses DHCP, it may still work if the IP falls within the correct subnet – but it might conflict with another device if that IP is already assigned.
Finally, be prepared for questions that ask you to interpret the output of netstat -an – you need to distinguish between LISTENING, ESTABLISHED, TIME_WAIT, and CLOSE_WAIT states. These indicate whether a service is running, a connection is active, or a connection is being closed.
Always start troubleshooting at the physical layer: check cables, connectors, and link lights before worrying about software settings.
The ping command tests basic Layer 3 connectivity; a successful ping to the default gateway means your local IP configuration is likely correct.
DNS resolution failures are isolated by comparing access via IP address versus domain name.
Use nslookup or dig to verify the DNS server is responding and returning the correct IP address for a given hostname.
An intermittent connectivity problem is often caused by damaged cables, faulty switch ports, or duplex mismatches.
The CompTIA troubleshooting methodology is: identify the problem – establish theory – test theory – plan action – implement – verify – document.
A firewall or ACL can block traffic to a specific port while allowing other traffic, so always test the exact service (e.g., telnet to port 443) rather than just a ping.
These come up on the exam all the time. Here's how to tell them apart.
Ping
Tests basic reachability at Layer 3 using ICMP echo requests.
Only shows whether the destination responds, not the path.
Fails if ICMP is blocked by any firewall along the route.
Tracert
Shows every hop (router) the packet traverses to the destination.
Identifies where packet loss or latency increases.
Can still work even if the final destination blocks ping, as long as intermediate hops respond.
DHCP
Automatically assigns IP address, subnet mask, gateway, and DNS.
IP address can change over time, causing potential conflicts.
Easier to manage in large networks, but requires a DHCP server.
Static IP
IP address is manually configured and never changes.
No risk of IP change, but manual configuration errors are common.
Used for servers and devices that must have a fixed address.
DNS
Resolves domain names by querying remote DNS servers.
Centralised and can be updated globally.
Requires network connectivity to the DNS server.
Hosts File
Maps hostnames to IP addresses using a local text file on the device.
Only affects that one device; no central management.
Takes priority over DNS, so can override correct resolution.
Router
Operates at Layer 3 (Network layer) using IP addresses.
Connects different networks and routes packets between them.
Often includes firewall and NAT capabilities.
Switch
Operates at Layer 2 (Data Link layer) using MAC addresses.
Connects devices within the same local network.
Forwards frames based on MAC address tables.
Mistake
If ping fails, the remote server is down.
Correct
Ping can be blocked by firewalls. A failed ping doesn't always mean the server is offline; it could just mean ICMP traffic is filtered.
Many beginners assume the only reason for a ping failure is that the target is not running. In reality, administrators often block ping for security, so a server may be fully operational yet unreachable by ping.
Mistake
Changing the DNS server address will solve all web access problems.
Correct
DNS only affects name resolution. If you can reach a site by IP but not by name, changing DNS helps. But if you can't reach the IP at all, the problem is elsewhere (routing, firewall, server down).
Users often hear 'DNS' as the cause of any internet issue and think changing it is a magic bullet. They don't realise that many connectivity problems have nothing to do with DNS.
Mistake
A faulty Ethernet cable always causes total loss of connectivity.
Correct
A faulty cable can cause intermittent packet loss, high error rates, or speed drops without completely cutting the link. You may still have a link light.
People assume that if lights are on, the cable is fine. But a loose or damaged wire can still pass some traffic while corrupting data, leading to retransmissions and slow performance.
Mistake
You can fix a 'Duplicate IP Address' error by just renewing the DHCP lease.
Correct
Renewing the lease only gives you a new IP if another is available. If two devices have the same static IP, you must change one of them manually. A DHCP renewal won't overwrite a static assignment.
Beginners think 'renew' is a cure-all for IP conflicts. They don't understand that static IPs are permanent and not managed by DHCP.
Mistake
If you can access the internet, your local network is definitely working fine.
Correct
Internet access means your default gateway and ISP connection are working. But internal resources like file servers or printers could still be unreachable due to routing, VLAN separation, or local firewall rules.
People conflate 'internet works' with 'everything works'. Internal networking often uses separate subnets and security rules that can fail independently.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The server's firewall likely blocks ICMP (ping) traffic but allows HTTP/HTTPS (ports 80 and 443). The website is still reachable through those ports.
It means the local router has no route to the destination network. This usually indicates a missing or incorrect default gateway or a routing table problem.
Use the command 'telnet <IP address> 3389' on Windows or 'nc -zv <IP> 3389' on Linux. If the connection succeeds, the port is open. If it times out or is refused, the port is closed or blocked.
A switch works at Layer 2 and forwards traffic based on MAC addresses within the same network. A router works at Layer 3 and forwards traffic between different networks using IP addresses.
That's an Automatic Private IP Addressing (APIPA) address. It means your computer tried to get an IP from a DHCP server but didn't get a response, so it assigned itself a random address in the 169.254.x.x range. This usually means the DHCP server is down or unreachable.
Yes. A damaged cable can cause high numbers of errors and retransmissions, which slows down data transfer. The link light only shows electrical continuity, not quality of the signal.
The hosts file is a local text file that maps hostnames to IP addresses. It takes priority over DNS queries. If a hostname is incorrectly listed there, it can override the correct DNS resolution.
You've finished Troubleshooting Network and Connectivity Issues. Continue through the SK0-005 study guide to build a complete picture of the exam.
Done with this chapter?