Reachability, path, and host inventory fail in different ways. Ping answers “does this address reply?” Traceroute (Windows: tracert) answers “which hop on the path stops or delays the packet?” Nmap answers “which hosts and services exist on the network I am authorized to test?” CompTIA Network+ N10-009 Domain 5.0 (Network Troubleshooting, 24% of the exam) tests that you pick the right tool for the symptom.
What N10-009 actually lists
Objective 5.5 says: given a scenario, use the appropriate tool or protocol to solve networking issues.
Under software tools, the official list includes:
- Command line: ping, traceroute/tracert, nslookup, tcpdump, dig, netstat, ip/ifconfig/ipconfig, arp
- Nmap (listed on its own line, not nested under “command line”)
- Protocol analyzer
- Link Layer Discovery Protocol (LLDP) / Cisco Discovery Protocol (CDP)
- Speed tester
Those three title tools sit next to a larger kit. Do not treat ping as a path map. Do not treat traceroute as a port inventory. Do not treat Nmap as a connectivity check.
Objective 5.4 names the performance symptoms these tools often isolate: congestion/contention, bottlenecking, bandwidth (throughput capacity), latency, packet loss, and jitter.
Objective 5.1 is the order of work, not a slogan:
- Identify the problem (gather information, question users, identify symptoms, determine if anything has changed, duplicate the problem if possible, approach multiple problems individually).
- Establish a theory of probable cause (question the obvious; consider multiple approaches, including top-to-bottom or bottom-to-top Open Systems Interconnection (OSI) model and divide and conquer).
- Test the theory to determine the cause.
- Establish a plan of action and identify potential effects.
- Implement the solution or escalate.
- Verify full system functionality and add preventive measures if they apply.
- Document findings, actions, outcomes, and lessons learned.
Use ping, traceroute/tracert, and Nmap inside step 3. Do not skip step 1.
Study the full Domain 5 map inside the Network+ hub.
Ping: test whether an address replies
Ping is a command-line reachability test. You give it a destination Internet Protocol (IP) address or name. The host sends probe packets and reports whether replies return, and how long they take.
Official N10-009 names ping. It does not name the protocol family, message types, default count, or flags.
What you can claim on the exam from the tool name and 5.4/5.5 pairing:
- A successful ping supports the theory that Layer 3 reachability exists to that address from this host, at the moment you ran the test.
- A failed ping does not, by itself, prove the remote host is down. Filters, policy, and a wrong local address all produce silence.
- Latency and packet loss in ping output map to the 5.4 terms latency and packet loss. They do not, by themselves, name the hop that caused them.
Divide and conquer with ping before you blame a route:
- Ping a local interface address first. Confirm the stack on this box is alive.
- Ping the default gateway. Confirm the first hop answers.
- Ping the destination. Confirm end-to-end reply.
If local and gateway succeed and the destination fails, move to traceroute/tracert. If even the local interface fails, stop. Fix addressing with ip/ifconfig/ipconfig (also named in 5.5) before you chase the WAN.
Traceroute / tracert: find the hop that breaks the path
traceroute and tracert are the same exam bullet. The dual name is the official hint that Windows and other platforms use different command names for the same job: list hops toward a destination.
Official N10-009 names both commands. It does not describe hop discovery, probe type, or timeout marks.
What you can claim:
- The tool maps a path as a series of hops.
- Use it when ping to the destination fails, or when 5.4 symptoms (latency, packet loss, bottlenecking) appear only toward some destinations.
- A hop that stops answering is a theory, not a conviction. The next step is still 5.1: test that theory, or escalate.
Read traceroute output against 5.3 service faults as well as 5.4 performance faults. A path that dies at the first hop after your gateway can be a default-route or gateway problem (5.3 lists incorrect default gateway, routing table, and default routes). A path that crawls at one hop and then recovers can be bottlenecking or congestion on that segment (5.4). The tool shows where to look. It does not name the cable, VLAN, or ACL.
Do not confuse traceroute with Nmap. Traceroute follows one destination. Nmap inventories many addresses and services.
Nmap: authorized discovery of hosts and services
Nmap is the Network Mapper. Official 5.5 lists it as its own software tool. Third-party study chatter often treats it as a “port scanner only.” The official line is broader than that label and thinner than any flag chart: Nmap is a tool you select when the scenario needs host or service discovery.
Authorized use only. Scan address space you own or have written permission to test. Unauthorized scanning is not a Network+ lab.
What you can claim:
- Use Nmap when the problem is “what is live?” or “what is listening?” rather than “does this one address reply?”
- A host that answers ping can still hide services. A host that ignores ping can still be live. Those two facts are why 5.5 lists both ping and Nmap.
- Discovery results feed 5.1 documentation. Write down what you found, what you changed, and what you verified.
Pick the tool from the symptom
Match the 5.4/5.5 language to the ticket.
User says “it is down.”
Identify the problem. Duplicate it. Ping the local stack, then the gateway, then the destination. If ping dies after the gateway, run traceroute/tracert. If the name fails and the address works, switch to nslookup or dig (also in 5.5). That is DNS, not a dead path.
User says “it is slow.”
5.4 terms apply: latency, packet loss, jitter, bottlenecking, congestion/contention, bandwidth / throughput capacity. Ping can show loss and delay to one target. Traceroute/tracert can show which hop inflates delay. A speed tester (named in 5.5) measures throughput. None of those three replace a protocol analyzer when you need frames.
User says “I do not know what is on this subnet.”
That is inventory, not reachability. Use Nmap on authorized space. Pair it with arp on the local segment and with LLDP/CDP when you need neighbor identity from a switch or router.
User says “the printer has an address but will not print.”
Ping tests the address. Nmap tests whether the expected service is present. Neither replaces 5.2 cable and interface checks if the link light is dark.
Where these tools stop
Ping does not list hops.
Traceroute/tracert does not list listening services.
Nmap does not prove a cable is good.
When the path looks clean and the host looks live, drop to the rest of 5.5:
- ip / ifconfig / ipconfig for local addressing.
- arp for IP-to-hardware mappings on the local link.
- netstat for sockets on this host.
- tcpdump or a protocol analyzer for the packet itself.
- Device commands named in 5.5 (show interface, show route, show arp, show vlan, show mac-address-table, show config, show power) when the box you manage is a switch or router, not a PC.
Hardware tools in the same objective (toner, cable tester, taps, Wi-Fi analyzer, visual fault locator) own Layer 1. Do not spend an hour on Nmap if the patch cord is the fault.
Exam discipline
Memorize the official names: ping, traceroute/tracert, Nmap.
Memorize the 5.1 order.
Memorize the 5.4 symptom words so you can match a scenario to a tool.
Do not memorize flags this document does not give you. Do not invent ICMP type numbers. Do not treat a filtered hop as a dead router unless you have tested that theory.
If you are mapping Domain 5 for N10-009, start at the CompTIA Network+ study hub.
Leave a Reply