Connectivity troubleshooting is the most common network support task and is heavily tested throughout the CompTIA Network+ N10-009 Troubleshooting domain. You must be able to systematically diagnose why a device cannot reach a destination — working through physical connectivity, IP configuration, routing, and application-layer issues using the right tools at each layer.
Practice this topic
Layer 1: Check link lights on the NIC and switch port. Use 'ipconfig' (Windows) or 'ip link' (Linux) to see if the interface is up. If no link: check cable, try different port, replace cable.
Layer 2: Verify the device is on the correct VLAN. Check the switch port configuration. If the device can reach local devices but not the gateway, suspect a VLAN issue.
Layer 3: Check IP configuration — 'ipconfig /all' (Windows) or 'ip addr' (Linux). Verify: IP address is correct for the subnet, subnet mask is correct, default gateway is correct, and the IP was obtained (not APIPA 169.254.x.x). 'ping default-gateway' — if this fails, check local routing table and gateway ARP.
Layer 3 routing: ping the remote destination. If ping fails, use traceroute to find where packets stop. If routing is the issue, check routing tables on the path devices.
Layer 4/7: If ping succeeds but the application fails, the issue is at Layer 4 or above — firewall blocking the application port, service not listening, DNS failure, or application misconfiguration.
Wrong subnet mask: a device with an incorrect subnet mask may think remote hosts are local (ARP flooding) or think local hosts are remote (routing to gateway). Symptoms: can ping the gateway but not other local devices, or cannot ping the gateway.
Wrong default gateway: device cannot reach any remote networks. Can ping local devices but nothing outside the subnet. 'ipconfig' shows incorrect or no gateway. DHCP misconfiguration most common cause.
Duplicate IP address: two devices on the same subnet with the same IP cause intermittent connectivity for both — ARP conflicts cause traffic to alternately reach each device. Windows event log shows 'Address conflict detected.'
Blocked by ACL or firewall: ping may work (ICMP permitted) but specific ports blocked. Use 'telnet host port' or 'Test-NetConnection -ComputerName host -Port port' (PowerShell) to test specific port connectivity. Check firewall and ACL rules.
If ping works, the network connection is fully functional
Ping tests ICMP Layer 3 connectivity only. Application connectivity requires the correct port to be reachable (TCP/UDP), the service to be running, DNS to resolve correctly, and the application to be properly configured. A successful ping eliminates physical and routing issues, not application issues
These questions are representative of what you will see on Network+ exams. The correct answer and explanation are shown immediately below each question.
A user can access websites by IP address but not by hostname. What is the most likely cause?
Explanation: If IP access works but hostname access fails, DNS resolution is the problem. When you access 'google.com,' the browser queries DNS to resolve the name to an IP. If DNS fails, the browser cannot find the IP address for the hostname. Accessing by IP bypasses DNS. Check: DNS server configuration ('ipconfig /all'), DNS server reachability ('nslookup google.com'), flush DNS cache ('ipconfig /flushdns').
Test the specific port: 'telnet host port' (if ping works but application doesn't). On Windows: 'Test-NetConnection -ComputerName host -Port 443'. If the connection hangs or times out, a firewall is likely blocking the port. 'Connection refused' means the target host is reachable but no service is listening on that port. Check ACLs on routers and firewall rules. Use traceroute to identify where the path stops.
Try free Connectivity Troubleshooting practice questions with explanations, topic links and progress tracking.