This chapter covers the systematic process of troubleshooting network connectivity issues, a core skill tested heavily on the CompTIA Network+ N10-009 exam. Approximately 15-20% of exam questions involve troubleshooting, with connectivity issues being the most common scenario. Mastering the troubleshooting methodology and common connectivity problems is essential for passing the exam and for real-world network administration. We will cover the CompTIA 7-step troubleshooting methodology, common causes of connectivity failures, and how to isolate problems using command-line tools and logical reasoning.
Jump to a section
Troubleshooting network connectivity is like being a plumbing detective in a large building. The building has pipes (cables), valves (switches/routers), and fixtures (end devices). When a sink (workstation) doesn't get water (data), you don't immediately replace the sink. You start at the sink and work backward: check if the faucet handle (network adapter) is turned on, then if the local pipe (patch cable) is kinked or disconnected, then if the shutoff valve under the sink (wall jack) is open, then trace to the main branch (switch port) and check if that valve is open (port enabled, VLAN correct). If water flows to the branch but not the sink, the problem is between them. If the branch itself is dry, you check the riser (uplink to router) and then the main supply (router interface, firewall rules). Each step isolates the problem to a specific segment. A good detective doesn't guess; they follow a logical sequence—checking the most likely and easiest-to-fix problems first (like a loose cable) before calling in heavy equipment (replacing a router). The methodical approach prevents wasted effort and ensures you find the root cause, not just a symptom.
What is Network Connectivity Troubleshooting?
Network connectivity troubleshooting is the systematic process of identifying, isolating, and resolving problems that prevent devices from communicating over a network. The N10-009 exam emphasizes a structured approach, specifically the CompTIA 7-step troubleshooting methodology. This methodology ensures that you address root causes rather than symptoms and that you document changes for future reference.
The 7 steps are: 1. Identify the problem 2. Establish a theory of probable cause 3. Test the theory to determine the cause 4. Establish a plan of action to resolve the problem and identify potential effects 5. Implement the solution or escalate as necessary 6. Verify full system functionality and, if applicable, implement preventative measures 7. Document findings, actions, and outcomes
While following these steps, you must also consider common connectivity issues such as physical layer failures (bad cables, power loss), data link layer issues (VLAN mismatch, duplex mismatch), network layer problems (incorrect IP configuration, routing issues), and transport layer problems (firewall blocking ports, ACLs).
The OSI Model and Troubleshooting
The OSI model is a foundational framework for troubleshooting. Each layer has specific potential issues: - Layer 1 (Physical): Cable faults, power issues, faulty transceivers, signal attenuation. - Layer 2 (Data Link): MAC address issues, VLAN misconfiguration, STP problems, duplex mismatch. - Layer 3 (Network): Incorrect IP address/subnet mask, default gateway misconfiguration, routing loops, ACLs. - Layer 4 (Transport): Firewall blocking ports, TCP window scaling issues, UDP packet loss. - Layers 5-7 (Session, Presentation, Application): Application-specific errors, authentication failures, protocol mismatches.
Common Connectivity Scenarios
#### Scenario 1: No Connectivity at All
A user reports that they cannot access any network resources. The first step is to verify physical connectivity. Check if the link lights on the NIC and switch port are on. If not, suspect a bad cable, unplugged cable, or disabled port. Use ipconfig (Windows) or ifconfig (Linux) to see if the interface has an IP address. If it shows an APIPA address (169.254.x.x), DHCP is failing. If it shows a valid IP, ping the default gateway. If the gateway responds, the problem is beyond the local subnet.
#### Scenario 2: Intermittent Connectivity
Intermittent issues are harder to diagnose. Common causes include duplex mismatch (one side set to full duplex, the other to auto-negotiation), faulty cabling (near-end crosstalk), or broadcast storms. Use continuous pings (ping -t on Windows) to observe packet loss patterns. Check interface counters for errors (CRC errors, runts, giants) using show interfaces on Cisco devices.
#### Scenario 3: Can Access Some Resources but Not Others
This often indicates a routing or firewall issue. If you can ping the destination IP but not access a specific service (e.g., HTTP), the firewall may be blocking the port. Use telnet or Test-NetConnection to test specific ports. If you cannot ping the destination at all, use tracert (Windows) or traceroute (Linux) to see where the path stops. This reveals the last responding hop, indicating where the problem lies.
Troubleshooting Tools and Commands
#### Ping
Tests basic IP connectivity. Sends ICMP Echo Request and waits for Echo Reply. Use ping -n <count> <target> to control the number of packets. A successful ping confirms Layer 3 connectivity but does not guarantee that higher-layer services are working.
#### Tracert/Traceroute
Traces the path packets take to a destination. On Windows: tracert <target>. On Linux: traceroute <target>. It sends packets with increasing TTL values; each router decrements the TTL and, when it reaches zero, sends an ICMP Time Exceeded message back. This reveals the hop-by-hop path and where delays or failures occur.
#### Ipconfig/Ifconfig
Displays IP configuration. On Windows: ipconfig /all shows MAC address, IP, subnet mask, default gateway, DNS servers, DHCP server, lease times. On Linux: ifconfig shows similar info but is deprecated; use ip addr instead.
#### Nslookup/Dig
Tests DNS resolution. nslookup <hostname> returns the IP address. dig <hostname> provides more detailed DNS information. If DNS fails, you cannot reach resources by name but can by IP.
#### Netstat
Shows active connections and listening ports. netstat -an lists all connections with their state (ESTABLISHED, LISTENING, TIME_WAIT). Useful for seeing if a service is listening on the expected port.
#### Pathping (Windows)
Combines ping and traceroute. It first traces the path, then sends pings to each hop to measure packet loss and latency per hop. Command: pathping <target>.
#### Telnet/Test-NetConnection
Tests connectivity to a specific port. telnet <host> <port> (if telnet client is installed) or PowerShell: Test-NetConnection <host> -Port <port>. If the port is open, you get a blank screen or connection established. If closed, you get a timeout or connection refused.
The CompTIA Troubleshooting Methodology in Detail
#### Step 1: Identify the Problem Gather information from the user: what exactly isn't working? When did it start? Has it ever worked? Are others affected? Check for recent changes (new software, hardware, configuration changes). Duplicate the problem if possible. Determine the scope: is it one user, one department, or the entire network?
#### Step 2: Establish a Theory of Probable Cause Based on the symptoms, list possible causes. Start with the most likely and easiest to test. For example, if one user cannot connect, the likely cause is something specific to that user (cable, NIC, switch port). If the entire office is down, the cause is more global (ISP outage, core switch failure, DHCP server down).
#### Step 3: Test the Theory to Determine the Cause Use the tools above to test each theory. For example, if you suspect a bad cable, replace it with a known good one. If you suspect a VLAN mismatch, check the switch port configuration. If the theory is confirmed, move to step 4. If not, return to step 2.
#### Step 4: Establish a Plan of Action Decide how to fix the problem. Consider potential side effects: will changing a switch port configuration affect other users? Will rebooting a router cause downtime? Document the plan.
#### Step 5: Implement the Solution or Escalate Make the change. If you don't have the authority or skills to fix it, escalate to the appropriate team (e.g., server team for DNS issues, ISP for WAN problems).
#### Step 6: Verify Full System Functionality Test that the original problem is resolved. Also check that nothing else is broken. For example, after fixing a VLAN mismatch, verify that the user can access all needed resources, not just the one that was failing.
#### Step 7: Document Findings, Actions, and Outcomes Write down what the problem was, what steps were taken, and the final resolution. This helps in future troubleshooting and for compliance.
Common Pitfalls and Exam Traps
Skipping steps: The exam expects you to follow the methodology in order. Do not jump to step 5 without testing the theory.
Confusing symptoms with causes: For example, a user cannot access the internet. The symptom is no internet. The cause might be a misconfigured DNS server. Do not immediately assume the ISP is down.
Overlooking Layer 1: The most common cause of connectivity issues is physical layer problems. Always check cables, power, and link lights first.
Mixing up tools: Know which tool tests which layer. Ping tests Layer 3. Tracert tests Layer 3 path. Nslookup tests Layer 7 (DNS). Telnet tests Layer 4 (port availability).
Advanced Troubleshooting Scenarios
#### Duplex Mismatch When one side of a link is set to full duplex and the other to half duplex, it causes collisions and CRC errors on the half-duplex side, leading to poor performance and intermittent connectivity. Symptoms: high error counters, slow throughput, but link is up. To fix, set both sides to auto-negotiation (recommended) or manually set both to the same duplex.
#### VLAN Mismatch
If a switch port is configured for VLAN 10 but the connected device expects VLAN 20 (or no tagging), the device cannot communicate with devices in other VLANs. Symptoms: can ping devices in the same VLAN but not in other VLANs. Use show vlan and show interfaces trunk to verify.
#### MTU Issues
If a router or firewall drops packets because they exceed the MTU, you may see connectivity failures for large packets but success with small ones. Symptoms: web pages load partially, SSH connects but then freezes. Test with ping -f -l <size> (Windows) to find the maximum MTU. Common MTU values: 1500 (Ethernet), 1492 (PPPoE), 1400 (VPN).
#### DNS Resolution Failures
If DNS is misconfigured, users can access resources by IP but not by name. Check DNS server settings on the client and server. Use nslookup to test resolution. Common issues: wrong DNS server IP, stale cache, missing forward/reverse lookup zones.
Conclusion
Troubleshooting network connectivity is a critical skill for any network professional. The CompTIA Network+ N10-009 exam tests both your knowledge of the methodology and your ability to apply it to specific scenarios. By understanding the OSI model layers, mastering common tools, and practicing the 7-step process, you will be prepared to answer exam questions and solve real-world problems efficiently.
Identify the Problem
Gather information from the user: what exactly is not working? When did it start? Has it ever worked? Are other users affected? Check for recent changes (new software, hardware, configuration changes). Try to reproduce the problem. Determine the scope: is it one device, one subnet, or the entire network? Use tools like ipconfig to see if the device has an IP address. If it has an APIPA address (169.254.x.x), DHCP is likely the issue. If it has no IP, the interface may be disabled or the cable unplugged.
Establish a Theory of Probable Cause
Based on the symptoms, list possible causes. Start with the most likely and easiest to test. For a single user with no connectivity, probable causes include: unplugged cable, bad cable, disabled NIC, wrong IP configuration, switch port disabled, or VLAN mismatch. For multiple users, consider: switch failure, router failure, DHCP server failure, or ISP outage. Use the OSI model to guide your theory: start at Layer 1 and work up.
Test the Theory to Determine the Cause
Use tools to test each theory. For physical issues: check link lights, replace cable. For IP issues: ping loopback (127.0.0.1) to test NIC, ping local IP to test interface, ping default gateway to test Layer 3. If ping fails, use tracert to see where it stops. For DNS issues: nslookup a known host. For port issues: telnet to the specific port. If the theory is confirmed, move to next step. If not, return to step 2.
Establish a Plan of Action
Decide how to fix the problem. Consider potential side effects: will changing a switch port configuration affect other users? Will rebooting a router cause downtime? Document the plan. For example, if the cause is a bad cable, the plan is to replace it. If the cause is a VLAN mismatch, the plan is to change the switch port VLAN to match the device. If the cause is a firewall blocking a port, the plan is to add an allow rule.
Implement the Solution or Escalate
Make the change. If you have the authority and skills, implement the solution. If not, escalate to the appropriate team (e.g., server team for DNS issues, ISP for WAN problems). For example, replace the cable, change the VLAN, or update the firewall rule. If the solution requires downtime, schedule it during a maintenance window. After implementation, proceed to verification.
Verify Full System Functionality
Test that the original problem is resolved. For example, if the user could not access the internet, verify they can now browse. Also test other functionality to ensure nothing else is broken. For instance, after changing a VLAN, verify the user can access resources in other VLANs. If the fix involved a firewall change, test that legitimate traffic is not blocked. If verification fails, return to step 2.
Document Findings, Actions, and Outcomes
Write down what the problem was, what steps were taken, and the final resolution. Include the date, time, and any configuration changes made. This documentation helps in future troubleshooting and for compliance or audit purposes. It also contributes to a knowledge base that can be used by other team members. Good documentation is a hallmark of a professional network engineer.
Enterprise Scenario 1: Office Relocation with New ISP
A company moves to a new office and contracts a new ISP. After the move, users report that they cannot access the internet. The network team follows the 7-step methodology:
1. Identify: All users in the office cannot reach the internet, but internal resources (file servers) are accessible. The problem started after the move.
2. Theory: The new ISP connection is not configured correctly, or the router's WAN interface has wrong settings.
3. Test: Ping the ISP's gateway IP from the router. If it fails, check the WAN interface configuration: IP address, subnet mask, default gateway. Also check if the ISP's modem is providing an IP via DHCP or if static IP is required. Use show ip interface brief on the router. If the interface is up but no IP, DHCP may be failing. If the interface has an IP but cannot ping the gateway, check the cable or SFP module.
4. Plan: If the ISP uses DHCP, release and renew the IP. If static, verify the IP, subnet, gateway, and DNS provided by the ISP.
5. Implement: Correct the configuration. For example, change from static to DHCP or update the IP settings.
6. Verify: Ping the ISP gateway, then test internet access from a user's workstation. Also check that internal resources remain accessible.
7. Document: Record the ISP configuration details, any changes made, and the resolution.
Enterprise Scenario 2: VLAN Mismatch After Switch Replacement
A network switch is replaced in a wiring closet. After replacement, users in one department cannot access the file server in another VLAN.
1. Identify: Users in VLAN 10 cannot reach the file server in VLAN 20. Inter-VLAN routing is done by a router-on-a-stick. The problem started after the switch replacement.
2. Theory: The new switch may have the wrong VLAN configuration on the trunk port to the router, or the access ports for VLAN 10 may be misconfigured.
3. Test: On the switch, check show vlan to see which VLANs exist and which ports are assigned. Check show interfaces trunk to see if the trunk to the router is allowing VLAN 20. Use show running-config on the router to verify subinterface configuration: interface GigabitEthernet0/0.10 for VLAN 10 and interface GigabitEthernet0/0.20 for VLAN 20. Ping from a user to the router's VLAN 10 gateway IP. If that works, ping the VLAN 20 gateway IP. If that fails, the trunk may not be allowing VLAN 20.
4. Plan: Configure the trunk port to allow VLAN 20: switchport trunk allowed vlan add 20. Also verify that the access ports for VLAN 10 are correctly assigned.
5. Implement: Apply the configuration on the switch.
6. Verify: From a user in VLAN 10, ping the file server in VLAN 20. Also test other VLANs to ensure no disruption.
7. Document: Note the trunk configuration and VLAN assignments.
Enterprise Scenario 3: DHCP Scope Exhaustion
A company expands its workforce, and new employees cannot obtain an IP address via DHCP. Existing users are working fine.
1. Identify: New users get APIPA addresses (169.254.x.x). The DHCP server is a Windows Server. The problem started after onboarding 50 new employees.
2. Theory: The DHCP scope may be exhausted (all IP addresses leased). Or the DHCP server may have a lease duration too long, preventing address reuse.
3. Test: On the DHCP server, check the scope statistics: how many addresses are available? Use netsh dhcp server scope <scope> show clients to see active leases. If the scope is full, you've found the cause.
4. Plan: Options: increase the scope size (if subnet allows), reduce lease duration (e.g., from 8 days to 1 day), or add a new scope on a different subnet with a DHCP relay.
5. Implement: Change the lease duration or expand the scope. For example, change lease duration to 1 day: netsh dhcp server scope <scope> set option 51 value 86400 (seconds).
6. Verify: Have a new user release/renew their IP (ipconfig /release then ipconfig /renew) and check they get a valid IP.
7. Document: Update DHCP server documentation with new lease duration or scope range.
Performance and Scale Considerations
In large enterprises, troubleshooting must be efficient. Use centralized logging (syslog) to capture errors. Implement network monitoring (SNMP) to alert on interface errors, high utilization, or device down. For DHCP, use redundant servers (split scope or DHCP failover). For VLANs, document all VLANs and their purposes. Always test changes in a lab or during maintenance windows. Remember that the most common cause of connectivity issues is human error: misconfiguration, unplugged cables, or power failures.
What the N10-009 Exam Tests
The CompTIA Network+ N10-009 exam objective 5.3 focuses on "Given a scenario, troubleshoot common network connectivity issues." This includes applying the 7-step troubleshooting methodology and using appropriate tools. The exam expects you to:
Identify the problem based on symptoms
Determine the most likely cause (theory)
Select the correct tool to test the theory
Interpret tool output (e.g., ping results, traceroute hops, ipconfig output)
Understand the OSI layer where the problem occurs
Common Wrong Answers and Why Candidates Choose Them
"Replace the network card" — This is a common distractor when the real issue is a bad cable. Candidates often jump to hardware replacement without checking Layer 1 first. Always check the cable and link lights before replacing the NIC.
"Reboot the router" — When a user cannot access the internet, candidates may reboot the router. However, if the issue is a DNS misconfiguration, rebooting won't help. The exam expects you to diagnose the specific cause.
"The ISP is down" — When multiple users cannot access the internet, this is a possibility, but it's not the first thing to test. Always check internal connectivity first (can you ping the router's WAN interface? Can you ping the ISP gateway?). The exam will give clues that point to internal vs. external issues.
"Change the IP address" — If a user has an APIPA address, the cause is DHCP failure, not a wrong IP. Candidates may think to assign a static IP, but the correct approach is to troubleshoot DHCP.
"Update the driver" — Driver issues are rare compared to configuration or physical problems. The exam rarely tests driver troubleshooting; focus on network configuration.
Specific Numbers, Values, and Terms That Appear on the Exam
APIPA address: 169.254.0.0/16 (specifically 169.254.x.x)
Loopback address: 127.0.0.1
Default subnet masks: /24 (255.255.255.0), /16 (255.255.0.0), /8 (255.0.0.0)
Common MTU: 1500 bytes
Common DHCP lease duration: 8 days (default on many systems)
Ping -t: continuous ping (Windows)
Tracert -h: maximum hops (Windows)
Pathping: Windows tool that combines ping and traceroute
Nslookup: DNS lookup tool
Telnet: tests port connectivity (Layer 4)
Duplex mismatch symptoms: slow performance, CRC errors, collisions
VLAN mismatch symptoms: can communicate within same VLAN but not across VLANs
Edge Cases and Exceptions the Exam Loves
Intermittent connectivity: Often caused by duplex mismatch or faulty cabling. The exam may describe a scenario where pings succeed sometimes but fail other times. Look for clues like "error counters increasing" or "link flapping."
One-way audio (VoIP): This is a Layer 3 or 4 issue where traffic flows in one direction but not the other. Common causes: firewall blocking return traffic, asymmetric routing, or NAT issues.
MTU issues: Large packets are dropped but small packets work. Symptoms: web pages load partially, email attachments fail. Test with ping -f -l <size> to find the maximum MTU.
DNS cache poisoning: Users are redirected to wrong sites. The exam may describe a scenario where a user types a correct URL but goes to a different site. This is a security issue, not a connectivity issue.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When you see a troubleshooting question, first determine the OSI layer. For example:
If the user cannot ping the default gateway, the problem is at Layer 3 or below. Eliminate answers that suggest DNS or application issues.
If the user can ping by IP but not by name, the problem is DNS (Layer 7). Eliminate answers about cables or switches.
If the user can ping local devices but not remote, the problem is likely routing or the default gateway. Eliminate answers about the local switch.
If the user gets an APIPA address, the problem is DHCP. Eliminate answers about static IP configuration.
Always look for keywords in the question: "link lights are on" means Layer 1 is likely fine. "Can ping the gateway but not the internet" suggests the ISP or DNS. "Other users are working" isolates the problem to a single device or port.
By understanding the underlying mechanism and following the 7-step methodology, you can systematically eliminate incorrect answers and choose the correct one.
Always follow the CompTIA 7-step troubleshooting methodology in order.
Start troubleshooting at Layer 1 (physical) and work up the OSI model.
APIPA address (169.254.x.x) indicates DHCP failure or unreachable DHCP server.
Ping tests Layer 3 connectivity; traceroute shows the path; telnet tests port access.
Duplex mismatch causes high error rates but link stays up; symptoms are slow performance.
VLAN mismatch prevents communication across VLANs but allows same-VLAN communication.
Default MTU is 1500 bytes; test with ping -f -l to find maximum MTU.
Document every troubleshooting step and resolution for future reference.
These come up on the exam all the time. Here's how to tell them apart.
Ping
Tests end-to-end connectivity at Layer 3 using ICMP Echo.
Provides only success/failure and round-trip time.
Does not show the path taken.
Useful for quick connectivity check.
Can be used with -t for continuous testing.
Tracert
Traces the path packets take to a destination.
Shows each hop (router) along the path.
Reveals where packet loss or delay occurs.
Useful for identifying routing issues or firewall blocks.
On Windows, uses ICMP; on Linux, can use UDP or TCP.
Mistake
Ping success means the network is fully functional.
Correct
Ping only verifies ICMP echo at Layer 3. Higher-layer services (HTTP, DNS, etc.) may still be blocked by firewalls or misconfigured. Always test the specific service that is failing.
Mistake
A blinking link light indicates a problem.
Correct
A blinking link light usually indicates traffic activity, which is normal. A solid link light indicates a link is established but no activity. No light means no link. However, excessive blinking could indicate a broadcast storm.
Mistake
Duplex mismatch causes a link to go down.
Correct
Duplex mismatch does not bring the link down; the link remains up. However, it causes high error rates (CRC, collisions) and poor performance. The link lights stay on.
Mistake
Tracert shows the exact path every time.
Correct
Tracert shows the path at the moment of the trace. Because of load balancing and dynamic routing, subsequent packets may take different paths. Also, some routers may not respond to ICMP, showing asterisks.
Mistake
APIPA addresses are always a sign of DHCP server failure.
Correct
APIPA can also occur if the DHCP server is unreachable due to a network issue (e.g., VLAN mismatch, firewall blocking DHCP broadcast). The DHCP server may be working fine, but the client cannot reach it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The first step is to identify the problem. Gather information from the user, determine the scope (single user or multiple), check for recent changes, and try to reproduce the issue. Use tools like ipconfig to see if the device has an IP address. For example, if a user cannot access the internet, ask when it started and if other users are affected. This step sets the direction for the entire troubleshooting process.
If a client gets an APIPA address (169.254.x.x), it means DHCP failed. First, check the client's network cable and link light. Then, on the client, run `ipconfig /release` and `ipconfig /renew` to force a new DHCP request. If it fails, check the DHCP server: is it running? Are there available leases? Use `netsh dhcp server scope <scope> show clients` on Windows Server. Also check for VLAN mismatch or switch port issues that might block DHCP broadcasts. If the DHCP server is on a different subnet, ensure a DHCP relay agent (IP helper) is configured on the router.
A successful ping to the default gateway confirms that the local device has IP connectivity to the router on the same subnet. It means the following are working: the NIC, the cable, the switch port, the IP configuration (address, subnet mask), and the router's interface. However, it does not guarantee internet access or DNS resolution. The next step would be to ping a remote IP (like 8.8.8.8) to test routing beyond the gateway.
Duplex mismatch occurs when one side of a link is set to full duplex and the other to half duplex (or auto-negotiation fails). The best fix is to set both sides to auto-negotiation. If that's not possible, manually set both to the same speed and duplex (e.g., 1000/full). On Cisco switches, use `speed 1000` and `duplex full` on the interface. After change, verify with `show interfaces` and check for CRC errors and collisions. A clean interface with no errors indicates the mismatch is resolved.
A hub operates at Layer 1 and repeats all signals out all ports, causing collisions and security issues. A switch operates at Layer 2 and forwards frames based on MAC addresses, providing dedicated bandwidth per port. In troubleshooting, if you see excessive collisions or a device seeing traffic not intended for it, suspect a hub. Switches reduce collisions and improve performance. However, switches can still have issues like VLAN misconfiguration or STP problems.
Use telnet or Test-NetConnection (PowerShell). For example, to test if port 80 is open on a web server, run `telnet <server IP> 80`. If the screen goes blank or you get a connection message, the port is open. If you get a timeout or 'connection refused', the port is closed or blocked. On Windows, you may need to enable the Telnet client feature. Alternatively, use `Test-NetConnection <server IP> -Port 80` in PowerShell.
An asterisk in traceroute output indicates that no response was received from that hop within the timeout period. This can happen for several reasons: the router is configured to not respond to ICMP (common for security), the router is down, or there is packet loss. It does not necessarily mean the path is broken; the packet may still be forwarded. If subsequent hops respond, the asterisk is likely due to the router not sending an ICMP Time Exceeded message.
You've just covered Troubleshoot: Network Connectivity — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?