This chapter covers troubleshooting network connectivity issues, a critical skill for the CompTIA A+ 220-1101 exam. Network connectivity problems are among the most common IT support tickets, and the exam tests your ability to systematically identify and resolve them using command-line tools and logical analysis. Approximately 10-15% of the Hardware Troubleshooting domain (Objective 5.4) focuses on network connectivity issues, so mastering these techniques is essential for passing the exam.
Jump to a section
Imagine a postal system where every building has a unique street address (IP address) and within each building, every apartment has a specific door number (port number). When you send a letter, you write the destination address, your return address, and the apartment number. The postal service (routers) reads the street address to forward the letter between post offices (routing). Once it reaches the correct city, the local post office (switch) delivers it to the building. The building's mailroom (operating system) checks the apartment number and slides the letter under the correct door. If the apartment number is wrong (closed port), the mailroom discards the letter or sends back a 'return to sender' notice (ICMP port unreachable). If the building address is wrong, the postal service returns the letter with 'no such address' (ICMP host unreachable). If the street exists but the building number is out of range, the letter is returned (ICMP network unreachable). The postal service also uses a tracking number (sequence number) to reassemble letters that were split into multiple envelopes (packet fragmentation). This analogy mirrors how TCP/IP uses IP addresses for host identification and port numbers for application identification, with ICMP providing error reporting. The postal service's routing tables and forwarding decisions are analogous to routers using routing protocols like OSPF or BGP to determine the best path.
What is Network Connectivity Troubleshooting?
Network connectivity troubleshooting is the process of identifying and resolving issues that prevent a device from communicating with other devices over a network. The OSI model layers 1 (Physical), 2 (Data Link), 3 (Network), and 4 (Transport) are the primary focus. The CompTIA A+ 220-1101 exam expects you to use a structured methodology, often referred to as the 'CompTIA Troubleshooting Methodology,' which includes: 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. For network issues, this translates to checking physical connections, verifying IP configuration, testing reachability, and inspecting higher-layer services.
Common Network Connectivity Issues and Their Symptoms
No connectivity: The device cannot communicate with any other device. Possible causes: unplugged cable, disabled network adapter, incorrect IP configuration, or switch port issues.
Limited connectivity: The device can communicate locally but not to the internet or remote networks. Often due to incorrect default gateway, DNS issues, or proxy misconfiguration.
Intermittent connectivity: Connection drops periodically. Causes include faulty cables, electromagnetic interference, duplex mismatch, or overloaded network.
Slow connectivity: High latency or low throughput. Causes: bandwidth saturation, interference, faulty hardware, or misconfigured QoS.
IP address conflict: Two devices have the same IP address. Symptoms include intermittent connectivity and error messages like 'IP address conflict with another system on the network.'
The Troubleshooting Process: Step by Step
Step 1: Identify the Problem – Gather information from the user and observe symptoms. Ask: 'What exactly is not working? When did it start? Has it worked before? Are other devices affected?' Check for error messages, LED status on NIC and switch, and recent changes.
Step 2: Establish a Theory of Probable Cause – Based on symptoms, list possible causes. For no connectivity, start with physical layer: is the cable plugged in? Are link lights on? Then move up: is the IP address valid? Is the default gateway reachable? Common causes include: faulty cable, disabled adapter, incorrect IP configuration (DHCP failure, static misconfiguration), DNS resolution failure, firewall blocking, or switch port security.
Step 3: Test the Theory – Use command-line tools to verify. Begin with ipconfig (Windows) or ifconfig/ip addr (Linux/macOS) to check IP configuration. Then ping the default gateway. If successful, ping a remote IP (e.g., 8.8.8.8). If that fails, it's a routing or internet issue. If ping to IP works but not to hostname, it's a DNS issue. Use tracert (Windows) or traceroute (Linux/macOS) to identify where packets stop. Use nslookup or dig to test DNS resolution. Check firewall with telnet or Test-NetConnection (PowerShell).
Step 4: Establish a Plan of Action – Based on the test results, decide on the fix. For example, if DHCP fails, assign a static IP or restart the DHCP client service. If DNS fails, check DNS server settings or flush DNS cache (ipconfig /flushdns). If physical layer fails, replace cable or reseat adapter.
Step 5: Implement the Solution – Perform the fix. For software changes, ensure you have administrative privileges. For hardware changes, power down if necessary.
Step 6: Verify Full System Functionality – Confirm the original issue is resolved and that no new issues were introduced. For example, after fixing DNS, verify that browsing works and other network services are unaffected.
Step 7: Document Findings – Record the symptoms, cause, and solution for future reference. This helps in recognizing recurring issues.
Key Command-Line Tools and Their Usage
`ipconfig` (Windows): Displays IP configuration. Use ipconfig /all for detailed info including MAC address, DNS servers, DHCP server, lease obtained/expires. Commands: ipconfig /release and ipconfig /renew to force DHCP renewal.
`ifconfig` (Linux/macOS): Similar to ipconfig. Use ifconfig -a to show all interfaces. Modern Linux uses ip addr and ip link.
`ping`: Tests reachability by sending ICMP Echo Request. Default packet size 32 bytes (Windows) or 56 bytes (Linux). Use -t for continuous ping (Windows) or -c for count (Linux). Useful for testing latency and packet loss.
`tracert` (Windows) / `traceroute` (Linux/macOS): Shows the path packets take to a destination. Uses ICMP TTL expiration to hop routers. Each hop is listed with IP and response time. tracert -d skips DNS resolution for faster results.
`nslookup`: Queries DNS servers. Use nslookup hostname to resolve IP. Use nslookup IP for reverse lookup. Type server <IP> to change DNS server. set type=MX to query mail records.
`dig` (Linux/macOS): More advanced DNS tool. dig @8.8.8.8 example.com queries Google's DNS. dig -x 8.8.8.8 does reverse lookup.
`netstat`: Displays active connections, listening ports, routing table. netstat -an shows all connections with numeric IPs and ports. netstat -r shows routing table. netstat -b (Windows) shows which program owns the connection.
`arp`: Displays and modifies the ARP cache. arp -a shows IP-to-MAC mappings. arp -d clears the cache. Useful for duplicate IP detection.
`route`: Displays and modifies the routing table. route print (Windows) or route -n (Linux). route add can add static routes.
`telnet`: Tests connectivity to a specific port (e.g., telnet mail.example.com 25). If the port is open, you get a blank screen or banner; if closed, connection fails. Many Windows versions require enabling Telnet Client.
`Test-NetConnection` (PowerShell): Modern tool that combines ping, trace, and port test. Test-NetConnection -ComputerName 8.8.8.8 -Port 443 tests HTTPS connectivity.
Common Configuration Issues and Fixes
DHCP Failure: If a device gets an APIPA address (169.254.x.x), it means DHCP failed. Check if the DHCP server is running, if the switch port is in the correct VLAN, or if there's a rogue DHCP server. Fix: ipconfig /release and ipconfig /renew. If still fails, assign a static IP temporarily.
Incorrect Default Gateway: If you can ping local devices but not the internet, check the default gateway. Use route print to see the default route. The gateway must be in the same subnet as the device's IP. Fix: correct the gateway in network settings.
DNS Resolution Failure: If you can ping by IP but not by hostname, DNS is the issue. Check DNS server settings in ipconfig /all. Try nslookup with a known DNS server like 8.8.8.8. Flush DNS cache with ipconfig /flushdns. Check the hosts file (C:\Windows\System32\drivers\etc\hosts on Windows) for incorrect entries.
Duplicate IP Address: Symptoms include intermittent connectivity and 'IP address conflict' messages. Use arp -a to see if two MAC addresses have the same IP. Fix: release and renew DHCP, or assign a unique static IP.
Firewall Blocking: Windows Firewall or third-party firewalls can block ping (ICMP), file sharing (SMB ports 445), or remote desktop (3389). Temporarily disable the firewall to test. Use netsh advfirewall to manage rules.
Switch Port Issues: The switch port may be disabled, in a different VLAN, or have port security enabled (MAC address filtering). Check the switch configuration. If the port is administratively down, it needs to be enabled. If port security is enabled, the MAC address must be added to the allowed list.
Cable and Hardware Issues: Check for physical damage. Use a cable tester to verify continuity. Ensure the cable category matches the network speed (Cat5e for gigabit). Faulty NICs can be tested by connecting another device to the same cable.
Advanced Troubleshooting Scenarios
Duplex Mismatch: Occurs when one side is set to full-duplex and the other to half-duplex. Symptoms include high error rates, slow performance, and intermittent connectivity. Use ethtool (Linux) or NIC driver settings to check. Most modern devices autonegotiate, but misconfiguration can override this.
MTU Issues: Path MTU discovery may fail if ICMP is blocked. Symptoms: large packets get lost, small packets work. Use ping -f -l 1472 (Windows) to test maximum packet size. Reduce MTU on the interface if needed.
VLAN Mismatch: If the device is in the wrong VLAN, it may not reach resources. Check the switch port VLAN assignment. Use ipconfig to see the default gateway; if the gateway's IP is in a different subnet, VLAN mismatch is likely.
Verification Commands
After making changes, verify with:
- ipconfig /all to confirm IP, subnet mask, default gateway, and DNS.
- ping 127.0.0.1 to test the local stack.
- ping <default gateway> to test local connectivity.
- ping <remote IP> to test internet connectivity.
- nslookup <hostname> to test DNS.
- tracert <remote IP> to see the path and identify where packets are dropped.
Documenting the Process
Always document: the problem description, steps taken, results of tests, the root cause, and the solution. This helps in creating a knowledge base for future issues and is part of the CompTIA troubleshooting methodology.
Identify the Problem
Gather information from the user: what exactly isn't working? Is it a specific website, all internet, or just local resources? When did it start? Were there any recent changes (new software, hardware, configuration)? Check for error messages on the screen, such as 'No internet access' or 'IP address conflict'. Observe the physical layer: are the link lights on the NIC and switch port solid or blinking? A solid green light indicates a good connection, while an amber or off light suggests a problem. Also, check if other devices on the same network are affected to isolate whether it's a single device issue or a network-wide problem.
Establish a Theory of Probable Cause
Based on the symptoms, list possible causes. For no connectivity, start with the physical layer: unplugged cable, faulty NIC, disabled switch port. Then consider IP configuration: DHCP failure, incorrect static IP, wrong subnet mask, missing default gateway. Next, consider higher layers: DNS resolution failure, firewall blocking, proxy settings, or application-specific issues. For intermittent connectivity, consider duplex mismatch, electromagnetic interference, or faulty hardware. Prioritize the most likely causes based on the symptoms. For example, if the user says 'the internet stopped working after I installed a new antivirus', the firewall in the antivirus is a probable cause.
Test the Theory Using Command-Line Tools
Use `ipconfig` to check if the device has a valid IP address. If it shows an APIPA address (169.254.x.x), DHCP failed. If it shows a valid IP, ping the default gateway. If that fails, the issue is local (cable, switch, or IP configuration). If ping to gateway succeeds, ping a remote IP like 8.8.8.8. If that fails, the issue is beyond the local network (routing, ISP). If ping to IP works but not to a hostname, use `nslookup` to test DNS. `tracert` can pinpoint where packets are dropped. Use `netstat -an` to see if the device is even trying to connect to the remote resource. For port-specific issues, use `telnet <IP> <port>` or `Test-NetConnection -Port`. Each tool provides specific clues to narrow down the cause.
Establish a Plan of Action
Based on the test results, decide on the specific fix. If DHCP failed, the plan might be to restart the DHCP client service, check the DHCP server, or assign a static IP. If DNS failed, the plan could be to flush the DNS cache, change DNS server to 8.8.8.8, or check the hosts file. If the default gateway is unreachable, the plan might involve checking the cable, switch port, or gateway device. If a firewall is blocking, the plan is to create an exception or temporarily disable it. Ensure the plan is specific and actionable. For example, 'Release and renew the IP address using ipconfig /release and ipconfig /renew' is a clear plan.
Implement the Solution
Execute the plan. For software changes, ensure you have administrative privileges. For hardware changes, power down if necessary. For example, to replace a cable, disconnect both ends, connect the new cable, and verify link lights. To release and renew DHCP, open Command Prompt as Administrator and run `ipconfig /release` followed by `ipconfig /renew`. To flush DNS, run `ipconfig /flushdns`. To disable a firewall temporarily, go to Windows Firewall settings and turn it off for testing. Document the exact steps taken in case you need to roll back. After implementation, proceed to verification.
Verify Full System Functionality
Confirm that the original issue is resolved. Use the same tests that initially failed. For example, if you couldn't ping the internet, try pinging 8.8.8.8 again. If DNS was the issue, try `nslookup google.com`. Also, verify that other network services still work, such as file sharing, printing, or accessing internal resources. Check that no new issues were introduced. For instance, after assigning a static IP, ensure there is no IP conflict. If the fix involved changing DNS servers, confirm that other users are not affected. Run a comprehensive test: browse a website, send an email, access a network share. Once everything works, inform the user and document the resolution.
Document Findings and Outcomes
Record the problem, symptoms, cause, and solution in a knowledge base or ticket system. Include the exact commands used and their output, the configuration changes made, and any lessons learned. This documentation helps in future troubleshooting and can be used to identify recurring issues. For example, if multiple users experience DHCP failures, it might indicate a server issue. Documentation also satisfies the CompTIA troubleshooting methodology requirement. Write in clear, concise language so that other technicians can understand and use the information. Include the date, time, and who performed the work.
Enterprise Scenario 1: Office Connectivity Outage
A mid-sized company experiences a complete loss of internet connectivity in one department. The helpdesk receives multiple tickets. The technician starts by checking if the issue is isolated to that department or company-wide. Using ping to the corporate DNS server fails. Checking the switch shows that the uplink port to the main router has an amber light, indicating a possible cable fault. The technician uses a cable tester and finds a broken wire in the patch cable. Replacing the cable restores connectivity. In a production environment, having spare cables and a cable tester is essential. The technician documents the issue and the switch port is monitored for future errors.
Enterprise Scenario 2: DNS Resolution Failure After Server Migration
After migrating DNS servers to new IP addresses, users report that they cannot access external websites by name, but internal resources work. The technician uses nslookup on a user's machine and sees that it is still querying the old DNS server IP. The DHCP server's scope options were not updated. The technician updates the DHCP scope with the new DNS server IPs and forces a renewal on clients using ipconfig /renew. After the update, DNS resolution works. This scenario highlights the importance of updating DHCP options when servers change. The technician also flushes the DNS cache on the client to clear any stale entries.
Enterprise Scenario 3: Intermittent Connectivity Due to Duplex Mismatch
A branch office reports intermittent slow performance and occasional disconnections. The network team discovers that a new switch was installed and autonegotiation was disabled on one port. The switch port was set to 100 Mbps full-duplex, but the connected server's NIC was forced to 100 Mbps half-duplex. This mismatch caused collisions and retransmissions. Using ethtool on the Linux server, the technician sees the duplex mismatch. The fix is to set both sides to autonegotiate or to the same forced setting. After setting both to full-duplex, the issue is resolved. This scenario underscores the importance of consistent duplex settings and the dangers of disabling autonegotiation.
The CompTIA A+ 220-1101 exam (Objective 5.4) tests your ability to troubleshoot network connectivity issues using a systematic approach. You must know the CompTIA Troubleshooting Methodology steps and be able to apply them to network problems. The exam focuses on common issues such as no connectivity, limited connectivity, intermittent connectivity, and slow connectivity. You will be expected to use command-line tools like ipconfig, ping, tracert, nslookup, netstat, and arp.
Common Wrong Answers and Why Candidates Choose Them
'Replace the network card' when the issue is a DHCP failure. Candidates often jump to hardware replacement without checking software configuration. The correct approach is to first verify IP configuration with ipconfig.
'Use ping to test DNS' – Ping tests reachability, not DNS. Many candidates confuse ping with nslookup. The exam tests that you know nslookup is for DNS.
'Reset the modem' for a single device issue. If only one device is affected, the problem is likely with that device, not the modem. Candidates often assume the ISP is at fault.
'Check the firewall' when the issue is a cable unplugged. Candidates sometimes skip the physical layer and go straight to software. The exam emphasizes starting with the physical layer.
Specific Numbers, Values, and Terms That Appear on the Exam
APIPA address: 169.254.0.0/16 with mask 255.255.0.0. The exam expects you to recognize that a 169.254.x.x address indicates DHCP failure.
Default subnet masks: 255.0.0.0 (Class A), 255.255.0.0 (Class B), 255.255.255.0 (Class C).
Loopback address: 127.0.0.1. Ping 127.0.0.1 tests the TCP/IP stack.
Common ports: 80 (HTTP), 443 (HTTPS), 25 (SMTP), 110 (POP3), 143 (IMAP), 3389 (RDP), 445 (SMB).
ping -t for continuous ping (Windows), ping -c for count (Linux).
tracert -d skips DNS resolution.
ipconfig /flushdns clears the DNS cache.
arp -a displays the ARP cache.
Edge Cases and Exceptions the Exam Loves to Test
IPv6 connectivity: The exam may test that IPv6 link-local addresses (fe80::/10) are used for local communication. If a device has only a link-local address, it cannot reach the internet.
Proxy settings: If a client has a proxy configured but the proxy server is unreachable, the browser may fail to load pages even though ping works. The exam expects you to check proxy settings in the browser or Internet Options.
VPN connectivity: When troubleshooting a VPN, the exam may ask about split tunneling vs. full tunneling. If the VPN is configured for full tunneling, all traffic goes through the VPN, which may affect internet access if the VPN fails.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If the symptom is 'no internet access on one computer but others work', the cause is likely local to that computer (IP config, firewall, cable). Eliminate answers that involve the router or ISP.
If ping to IP works but ping to hostname fails, the issue is DNS. Eliminate answers about IP configuration or routing.
If ping to the default gateway fails, the issue is local (cable, switch, NIC). Eliminate answers about DNS or remote servers.
If ipconfig shows an APIPA address, the issue is DHCP. Eliminate answers about DNS or gateway.
By understanding the underlying mechanism of each step, you can systematically eliminate incorrect options and choose the correct troubleshooting step.
Always start troubleshooting at the physical layer: check cables, link lights, and power.
Use ipconfig to verify IP configuration; an APIPA address (169.254.x.x) indicates DHCP failure.
Ping the loopback address (127.0.0.1) to test the TCP/IP stack, then the default gateway, then a remote IP.
Use nslookup to test DNS resolution; if ping by IP works but not by hostname, DNS is the issue.
Use tracert to identify where packets are dropped along the path to a destination.
Flush the DNS cache with ipconfig /flushdns if you suspect stale DNS entries.
Check for IP address conflicts using arp -a; a duplicate IP causes intermittent issues.
Document every step of the troubleshooting process for future reference and compliance.
When testing connectivity, use specific ports with telnet or Test-NetConnection to verify firewall rules.
Remember the CompTIA Troubleshooting Methodology: identify, establish theory, test, plan, implement, verify, document.
These come up on the exam all the time. Here's how to tell them apart.
Static IP Configuration
IP address is manually assigned and never changes unless manually updated.
No dependency on a DHCP server; works even if the server is down.
Risk of IP address conflicts if not managed carefully.
Requires manual configuration on each device, which is time-consuming in large networks.
Commonly used for servers, printers, and network devices that need a fixed address.
DHCP (Dynamic Host Configuration Protocol)
IP address is automatically assigned from a pool of addresses by a DHCP server.
Leases are temporary and can be renewed; addresses can change over time.
DHCP server manages address allocation, reducing the risk of conflicts.
Centralized management; changes can be made on the server and propagated to clients via lease renewal.
Commonly used for client devices like desktops, laptops, and mobile devices.
Mistake
Ping to 127.0.0.1 tests network connectivity to other devices.
Correct
Ping to 127.0.0.1 (loopback) only tests the local TCP/IP stack. It does not test the network adapter, cable, or any external connectivity. A successful loopback ping only confirms that the TCP/IP protocol is installed and working on the local machine.
Mistake
APIPA addresses (169.254.x.x) are always a sign of a hardware failure.
Correct
APIPA indicates that DHCP failed to assign an IP address. This can be due to a DHCP server problem, network connectivity issues preventing the DHCP request from reaching the server, or a misconfigured firewall blocking DHCP traffic (UDP ports 67 and 68). It is not necessarily a hardware failure.
Mistake
If you can ping a website by IP, DNS is working correctly.
Correct
Ping by IP only tests IP layer connectivity. DNS is a separate service that resolves hostnames to IP addresses. If you can ping by IP but not by hostname, DNS is failing. You must use nslookup or dig to test DNS resolution.
Mistake
ipconfig /release always fixes IP configuration issues.
Correct
ipconfig /release releases the current DHCP lease, but it does not fix underlying issues like a non-functional DHCP server, incorrect VLAN, or physical disconnection. It must be followed by ipconfig /renew to request a new lease. If the DHCP server is unreachable, the device will still get an APIPA address.
Mistake
A blinking link light on the NIC indicates a problem.
Correct
A blinking link light is normal and indicates network activity. A solid link light indicates a good connection but no activity. An off or amber light typically indicates a problem. Blinking is not a sign of trouble; it shows data is being transmitted.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An APIPA address indicates that DHCP failed. First, run `ipconfig /release` then `ipconfig /renew` to attempt a new lease. If that fails, check the DHCP server is running and reachable. Ensure the network cable is connected and the switch port is active. You can also assign a static IP temporarily to restore connectivity. If the issue persists, check for a rogue DHCP server or firewall blocking DHCP traffic (UDP 67/68).
This indicates a DNS resolution failure. Ping works at the IP layer, but the system cannot resolve the hostname to an IP address. Use `nslookup hostname` to test DNS. Check the DNS server settings in `ipconfig /all`. Try flushing the DNS cache with `ipconfig /flushdns`. Also check the hosts file for incorrect entries. If necessary, change the DNS server to a public one like 8.8.8.8 temporarily.
Use `telnet <IP> <port>` on Windows (if Telnet Client is enabled) or `Test-NetConnection -ComputerName <IP> -Port <port>` in PowerShell. On Linux, use `nc -zv <IP> <port>`. If the port is open, you'll see a blank screen or a banner; if closed, you'll get a connection refused error. This is useful for testing firewall rules or application availability.
Ping tests reachability and measures round-trip time to a single destination. Tracert (traceroute) shows the path packets take to the destination, listing each router hop with response times. Tracert uses ICMP packets with increasing TTL values to elicit time-exceeded messages from each router. Use tracert when you need to identify where packets are being dropped or delayed.
Use `arp -a` to view the ARP cache. If you see two different MAC addresses for the same IP, there is a conflict. You can also use `ping -a <IP>` to see the hostname of the conflicting device. On Windows, you may receive a 'IP address conflict' error message. To resolve, release and renew DHCP, or assign a unique static IP.
A link light off indicates no physical connection. Check that the cable is securely plugged into both the computer and the switch/wall jack. Try a different cable. If the cable is fine, check the switch port: is it enabled? Try plugging into a different port. If the NIC's link light is still off, the NIC may be faulty. Test with another device to isolate the issue.
Open Command Prompt as Administrator and run `netsh int ip reset` followed by `netsh winsock reset`. Then restart the computer. This resets the TCP/IP configuration to default and can fix issues caused by corrupted settings. After resetting, you may need to reconfigure static IPs or renew DHCP.
You've just covered Troubleshoot: Network Connectivity — now see how well it sticks with free 220-1101 practice questions. Full explanations included, no account needed.
Done with this chapter?