What do you do when you can't load a website, but your internet seems fine? This is the problem network troubleshooting solves: it gives you a step-by-step method and specialised tools to find out exactly why a connection is failing, even when everything looks okay on the surface. For the FC0-U71 exam, you need to know the names of these tools, what each one does, and a basic order of operations for diagnosing network problems — a skill that separates a panicked user from a calm, professional troubleshooter.
Jump to a section
A simple way to picture Network Troubleshooting and Tools
Your front door at home. The doorbell rings, but no one is there. A delivery tracker says your package was 'delivered to the back porch'. You don't have a back porch. The tracking website shows the driver's location as 'somewhere on your street', but you can see the street from your window and there is no van. Your neighbour's package arrived fine yesterday. Your internet service is working, your phone is charged, and your doorbell camera is online.
This is exactly like network troubleshooting. The 'package' is a piece of data (a request to load a website, send an email, or download a file) that is supposed to be delivered to a specific 'address' (your device's IP address) on a network. The 'delivery driver' is a network protocol (like TCP/IP) that follows a set of rules to route the data. When the data doesn't arrive, you need tools to trace its journey, check each 'turn' (router hop), and see exactly where it got lost.
In IT, the tools are digital: 'ping' is like shouting 'are you there?' to a device on the network; 'tracert' (or traceroute) is like checking the GPS log of every turn the delivery driver took; 'ipconfig' is like checking your own front door number to make sure it's written correctly; and 'nslookup' is like asking the phone book (DNS server) if the address you have for the website is actually correct. Just like the delivery company needs to know if the driver never left the depot, or got stuck at a junction, or delivered to the wrong house, network troubleshooting tools help you pinpoint exactly where data stops travelling.
Network troubleshooting is the systematic process of identifying, diagnosing, and resolving problems within a computer network. For the CompTIA Tech+ exam, you are expected to know a set of basic software tools that are built into virtually every operating system (Windows, macOS, Linux) and a simple methodology for using them. The goal is to figure out why one device cannot communicate with another device over a network.
First, you need to understand the core components of a network connection. A 'device' (your laptop, phone, server) has a 'network interface' (like a Wi-Fi card or Ethernet port) that is assigned a unique 'IP address' (Internet Protocol address — think of it as a mailing address for your device on a network). Devices also have a 'subnet mask' which defines which part of the address is the 'neighbourhood' and which part is the specific 'house'. To talk to devices outside your immediate local network, you need a 'default gateway' — the address of your router, which is the door to the wider internet. Finally, 'DNS' (Domain Name System) is like a phone book: it translates the human-friendly website name (like 'google.com') into the numerical IP address that computers use.
When something stops working, an IT professional follows a troubleshooting methodology. The CompTIA Tech+ focuses on a simple one: identify the problem, establish a theory of probable cause, test the theory, establish a plan of action, implement the solution, verify full system functionality, and document findings. The tools are what you use in the 'test the theory' and 'identify the problem' steps.
Here are the essential tools you must know for the exam:
'ping': This is the most fundamental tool. It sends a small packet of data (a 'echo request') to a target IP address or hostname. If the target responds, it sends back an 'echo reply'. A successful ping confirms that the network path between your device and the target is working at a basic level (Layer 3 of the OSI model, for those who go further). A failed ping tells you there is a problem somewhere along the route. You can ping a local address (like your own computer — '127.0.0.1' or 'localhost'), the default gateway, or a remote server like '8.8.8.8' (Google's DNS server). This is called a 'ping sweep' when you check multiple addresses.
'tracert' (on Windows) or 'traceroute' (on macOS/Linux): This tool shows you every 'hop' a packet takes from your computer to a destination. Each hop is a router that forwards the data along the path. Tracert sends three packets to each hop and reports the time it took. If you see a 'Request timed out' or a long delay at a specific hop, you have found the bottleneck or break.
'ipconfig' (on Windows) or 'ifconfig' (on macOS/Linux) / 'ip addr': This tool displays the network configuration of your own device. Running 'ipconfig /all' (Windows) or 'ifconfig -a' (macOS/Linux) will show you your current IP address, subnet mask, default gateway, DNS server addresses, and the physical (MAC) address of your network interface. It is the first tool you use when you are unsure about your own configuration.
'nslookup' or 'dig': These tools query the DNS system. They ask a DNS server: 'What is the IP address for this hostname?' If the reply is wrong, or if the server times out, you know the issue is with DNS resolution, not the network connection itself. For example, if you can ping '8.8.8.8' but cannot load 'google.com', DNS is likely the culprit. Nslookup is the simpler version; 'dig' provides more detail but is less common on Windows.
'netstat': This shows active network connections on your device. It lists all the open ports, the remote addresses your computer is connected to, and the state of each connection (e.g., 'ESTABLISHED', 'LISTENING', 'TIME_WAIT'). This helps you see if a service is running and listening for connections, or if there is a suspicious connection (potential security issue).
How do these tools work together? Imagine your friend cannot get to a website. You, the troubleshooter, would first run 'ipconfig' on their computer to check their own IP address and default gateway. Then you 'ping' the default gateway. If that fails, the problem is local (cable, Wi-Fi, router issue). If it succeeds, you 'ping' a known remote address like 8.8.8.8. If that fails, the problem is beyond the router (ISP issue). If it succeeds, you 'nslookup' the website name. If that fails, DNS is broken. If it returns the correct IP, you run 'tracert' to that IP to see the path. Each tool isolates one part of the connection chain, allowing you to systematically eliminate possible causes.
Identify the Problem
Gather information from the user: what exactly is broken? Is it one website, all websites, email, or file sharing? Ask when it started, if anything changed, and if other users are affected. This scope tells you whether the issue is local to one device or network-wide.
Test Local Connectivity (Loopback and Gateway)
Run 'ping 127.0.0.1' to confirm the computer's own network adapter is working. Then ping the default gateway (e.g., 'ping 192.168.1.1'). If the gateway ping fails, the problem is between the computer and the router — check cables, Wi-Fi, or the router itself. If it succeeds, the local network is intact.
Test Remote Connectivity (Ping a Known External IP)
Ping a reliable external IP address like '8.8.8.8' (Google DNS). If this fails but the gateway ping succeeded, the problem is beyond your router — likely with your internet service provider (ISP). If it succeeds, your internet connection itself is working.
Test Name Resolution (nslookup)
Use nslookup to query the DNS server for the website the user cannot reach (e.g., 'nslookup google.com'). If you get a valid IP address, DNS is working. If you get 'Non-existent domain' or 'server failed', the DNS system is the culprit. If nslookup fails but the external IP ping succeeded, the issue is DNS specifically.
Trace the Route (tracert)
If connectivity to a remote IP succeeds but the service still does not work, or if you want to see the path, run 'tracert [target IP]'. This shows each hop and the latency to each hop. A drop at a specific hop indicates where the problem lies — for example, hop 3 timing out while all following hops also time out tells you hop 3 has a problem.
Verify and Document
After implementing a fix (e.g., replacing a cable, resetting the router, flushing DNS), repeat the tests to confirm the problem is resolved. Then document the issue, the steps taken, and the solution. This documentation helps with future troubleshooting and is often required in professional IT environments.
Consider this scenario: you are a junior IT support technician at a small accounting firm with 50 employees. It is 9:30 AM on a Monday, and the receptionist calls you, panicking. She says: 'The main company website won't load on my computer, and I need to send an invoice link to a client. My email is also not working.' You walk over to her desk. Here is what you actually do, step by step, with the tools.
First, you look at the bottom-right corner of her screen (the system tray). You see the network icon shows a yellow triangle — it is connected, but with limited access. This tells you there is an issue, but you need more detail. You open the Command Prompt (type 'cmd' in the Start menu search). Your first command is 'ipconfig'. The output shows her IP address is '192.168.1.45', the subnet mask is '255.255.255.0', and the default gateway is '192.168.1.1'. The DNS server is '192.168.1.1' (the router is acting as DNS). This all looks normal.
Next, you 'ping the loopback address' by typing 'ping 127.0.0.1'. This tests her own network adapter. You see four replies — her adapter is working fine.
Then you ping the default gateway: 'ping 192.168.1.1'. This tests if her computer can talk to the local router. You get four 'Request timed out' messages. That means her computer cannot communicate with the router at all. This isolates the problem: it is definitely a local connection issue, not an internet or server issue.
Now you examine the physical connection. She is using a wired Ethernet cable (not Wi-Fi). You check the cable at the back of her PC — it is plugged in, but when you wiggle it, the port LED flickers off. You unplug the cable and plug it back in firmly. You run 'ping 192.168.1.1' again. This time, you get four replies. The problem is solved: a loose Ethernet cable.
But something else happens many times. Another user has the same symptom (website and email down), but 'ipconfig' shows their IP address starting with '169.254.x.x'. This is an 'APIPA' (Automatic Private IP Addressing) address — the computer tried to get an address from a DHCP server but failed, so it gave itself a random one. This means the DHCP server (often the router) is not responding or there is a break in the network path to it. You would then check the router or the switch in the server room.
In a more complex case, you might use 'tracert' to a remote server. If you see a '!' or asterisk at hop 3, and then nothing after that, you know the problem is at that specific router, which could belong to an internet service provider. You would then contact the ISP, giving them the exact hop where the trace stopped.
The key point: in a real job, you do not just run one command. You follow a logical order. First, check your own configuration (ipconfig). Then test local connectivity (ping gateway). Then test remote connectivity (ping 8.8.8.8). Then test name resolution (nslookup). Finally, trace the route (tracert) if needed. This methodology is faster and more professional than randomly clicking settings.
The FC0-U71 exam will test your ability to recall and apply the names and functions of network troubleshooting tools. It does NOT ask you to write commands from memory for every obscure switch (e.g., -t for continuous ping), but you must know what each tool is used for conceptually. Expect about 3-5 questions directly on this topic within the Network and Infrastructure domain (Objective 6.3).
Here are the exact topics and question patterns you will see:
'ping': Questions will give you a scenario (e.g., 'A user can access a file on a local file server but cannot load a website. Which tool should the technician use first to test connectivity to the remote server?') The trap is that beginners choose 'ipconfig' (which reveals local config, not connectivity) or 'nslookup' (which tests DNS, not basic connectivity). The correct answer is 'ping' because it tests the most basic level of reachability (Layer 3).
'tracert' / 'traceroute': You will be asked: 'Which command-line tool shows the path a packet takes across a network?' Or: 'A technician receives a report that a remote server is unreachable. Which tool would show the hops between the local computer and the server?' The trap answer is 'ping' — while ping tells you if it is reachable, it does not show each individual hop. The exam specifically asks about viewing the path.
'ipconfig': The exam loves to ask about the 'ipconfig /all' command (full configuration) versus plain 'ipconfig' (basic info). A typical question: 'A technician needs to see the MAC address and DNS server of a Windows client. Which command should they use?' The correct answer is 'ipconfig /all'. Remember that 'ipconfig' is Windows-specific; 'ifconfig' is for macOS/Linux.
'nslookup' / 'dig': This tool is tested in the context of DNS failures. A classic exam question: 'A user cannot get to a website by name but can access it by entering the IP address directly. Which tool should the technician use to diagnose the problem?' The correct answer is 'nslookup' (or 'dig'), because the issue is name resolution, not connectivity. The trap is choosing 'ping' again — but ping uses DNS automatically, so it would fail if DNS is broken, but it would not tell you why it failed.
- 'netstat': This tool is less frequently tested but can appear. You might see: 'Which tool shows active network connections and listening ports on a computer?' The answer is 'netstat'. The trap is confusing it with 'ipconfig', which shows static configuration, not dynamic connections. - Troubleshooting methodology: The exam may ask you to put steps in the correct order. The standard CompTIA troubleshooting methodology is: 1) Identify the problem, 2) Establish a theory of probable cause (question the obvious), 3) Test the theory to determine cause, 4) Establish a plan of action and implement the solution, 5) Verify full system functionality and implement preventative measures, 6) Document findings, actions, and outcomes. Common trap: they list 'Implement the solution' before 'Test the theory'. Know the order. - Key definitions to memorise for the exam: - 'Ping': Tests basic network connectivity between two devices. - 'Tracert': Traces the route packets take to a destination. - 'Ipconfig': Displays current TCP/IP network configuration values. - 'Nslookup': Queries DNS servers for hostname-to-IP resolution. - 'Netstat': Shows active network connections and listening ports. - 'Loopback address': 127.0.0.1 (tests the local network adapter). - 'APIPA': 169.254.x.x address indicates DHCP failure. - Traps to watch for: The exam might describe a scenario where a user cannot access the internet, but internal network resources work fine. Beginners often jump to 'ipconfig' to see if the IP is correct, but the real first step is to ping the default gateway. Another trap: mixing up the function of 'tracert' and 'netstat'. Tracert is path; netstat is connection status.
The ping command tests basic network connectivity by sending an echo request and waiting for a reply from a target IP address or hostname.
The tracert (Windows) or traceroute (macOS/Linux) command shows every router hop between your computer and a destination, helping you identify where data stops.
The ipconfig command (Windows) displays your current IP address, subnet mask, and default gateway; use ipconfig /all to see DNS servers and MAC addresses.
The nslookup command queries the DNS system to translate a hostname into an IP address, which helps isolate name resolution problems from network connectivity issues.
A full troubleshooting methodology starts by identifying the problem, then testing systematically: loopback address, then local gateway, then remote IP, then DNS resolution.
An APIPA address starting with 169.254.x.x tells you the computer failed to get an IP address from a DHCP server, indicating a failure in dynamic address assignment.
These come up on the exam all the time. Here's how to tell them apart.
Ping
Tests basic reachability of a remote device
Shows only success or failure (reply or timeout)
Uses ICMP echo request/reply packets
Tracert
Shows the complete path of hops to a destination
Lists each router along the way with response times
Also uses ICMP but records the route (TTL manipulation)
Ipconfig
Displays static network configuration (IP, DNS, Gateway)
Shows current state of network interfaces on the device
Useful for checking your own computer's settings
Netstat
Displays active network connections and listening ports
Shows dynamic states (established, listening, time_wait)
Useful for seeing what services are running and who is connected
Nslookup
Specifically queries DNS servers for hostname to IP resolution
Can test different DNS servers directly (e.g., nslookup google.com 8.8.8.8)
Does not test the network path itself
Ping
Tests network connectivity, not DNS resolution
Resolves hostnames automatically using the system's DNS settings
Does not directly reveal DNS server responses or failures
Loopback Address (127.0.0.1)
Tests only the local computer's TCP/IP stack and NIC
Does not involve any network cable, router, or internet
Always succeeds if the network stack is installed correctly (software loopback)
Default Gateway (e.g., 192.168.1.1)
Tests connectivity to the local router
Involves the network cable or Wi-Fi and the router itself
Fails if the physical connection or router is broken
Mistake
Ping only tells you if a website is up or down.
Correct
Ping confirms if a remote device is reachable at the network layer, but many servers block ping for security reasons, so a failed ping does not necessarily mean the server is down. It only means it did not respond to the ping request (ICMP echo).
Beginners assume ping is a universal 'is it running?' test, but firewalls often disable ping responses to prevent reconnaissance attacks.
Mistake
ipconfig /flushdns fixes all connection problems.
Correct
Flushing DNS only clears the local DNS cache. It fixes problems where a device has a stale or incorrect DNS entry. It will not fix a physical cabling issue, a router misconfiguration, or an ISP outage.
Online forums often recommend flushing DNS as a first troubleshooting step for any network issue, leading beginners to overuse it.
Mistake
If you can ping an IP address, the network is fully working.
Correct
A successful ping only verifies Layer 3 (IP) connectivity. It does not guarantee that higher-layer services (like web servers, email, or database connections) are operational. You could have a perfectly working ping but still not be able to open a website because the web server service is stopped.
Beginners mistake one layer of the OSI model for the entire system. They see a working ping as a 'green light' for everything.
Mistake
The loopback address (127.0.0.1) checks if you have internet access.
Correct
Pinging 127.0.0.1 only tests your own network interface card (NIC) and the TCP/IP stack on your local machine. It does not involve any network cable, router, or internet connection at all.
The address is often misunderstood as a 'loop through the network' address, but it is purely internal and never leaves the computer.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Ping only tells you whether a device is reachable or not. Tracert shows you the entire route the data takes, listing every router hop along the way, so you can see exactly where a slowdown or failure occurs.
It means the device you are pinging did not send back a reply within a certain time. This could be because the device is offline, a firewall is blocking ping (ICMP) traffic, or there is a network break somewhere along the path.
Ipconfig shows basic info (IP, subnet mask, default gateway). Ipconfig /all shows much more: DNS servers, MAC address, DHCP lease info, and whether DHCP is enabled. You use /all when you need to check name resolution details or the physical address of your network card.
That is an Automatic Private IP Addressing (APIPA) address. Your computer tried to get an IP from a DHCP server but got no response, so it assigned itself this address. It means there is a problem with the DHCP server (often your router) or a physical connection issue.
The loopback address is 127.0.0.1. Pinging it tests whether your own computer's network software (TCP/IP stack) is installed and working correctly. It does not test any network cable or internet connection.
Ping an IP address directly, like 8.8.8.8. If that works, your network connection is fine. Then try to ping the website name (e.g., google.com). If that fails, the problem is DNS (name resolution). Nslookup will confirm this by showing whether the DNS server can translate the name.
You've finished Network Troubleshooting and Tools. Continue through the FC0-U71 study guide to build a complete picture of the exam.
Done with this chapter?