Domain 5 of 5 · Chapter 5 of 5

Troubleshooting Tools

Reachability, path, and name resolution

A user says "the internet is down." The fastest way to turn that into a diagnosis is to run three command-line tools in order: can I reach it (ping), where does the path break (traceroute), and does the name resolve (nslookup or dig). Each answers exactly one question, and running them in that sequence walks the problem from the host outward.

ping: reachability, latency, and loss

ping sends ICMP Echo Request messages[1] (ICMP type 8) and waits for Echo Reply (type 0), reporting whether the destination answered, the round-trip time in milliseconds, and the percentage of replies lost. That makes it the single fastest test of "is this host alive, and how cleanly." A successful ping to a public IP but a failed ping to a name points the finger straight at DNS; a ping that succeeds with high latency or loss points at congestion or a flaky link. The one trap is that ping rides ICMP, and many firewalls drop ICMP while still passing real traffic, so a failed ping is suggestive, not proof, that a host is down.

traceroute / tracert: the path hop by hop

Once ping tells you a destination is unreachable or slow, traceroute (tracert on Windows, traceroute on Linux/macOS) finds the hop responsible. It works by sending packets with a Time To Live (TTL) of 1, then 2, then 3[2]: each router that decrements the TTL to zero returns an ICMP Time Exceeded, so the tool maps one router per TTL value until it reaches the destination. Read the output for the last hop that answers normally; the break or the latency jump lives at the next hop. A single middle hop showing asterisks is usually a router that rate-limits ICMP, not a real failure, so judge the path by whether later hops still respond.

nslookup / dig: name resolution

When a site fails by name but its IP works, the fault is DNS, and nslookup (cross-platform) or dig (Linux/macOS, more detailed output) query a DNS name server directly[3] and show which server answered and what record came back. They separate a resolution problem from a connectivity problem in one command: if the lookup returns the wrong address, times out, or returns NXDOMAIN, the issue is DNS, not the network path. You can also point them at a specific server to test whether one resolver is stale while another is correct.

pingalive? latency? loss?traceroute / tracertwhich hop breaks?nslookup / digdoes DNS resolve?Each tool answers one questionrun them in order, host outwardunreachable / slowname fails
The three-step reachability workflow: ping for liveness, traceroute for the failing hop, nslookup/dig for name resolution.

Local config, connections, and host discovery

When the path out is fine but one host misbehaves, the next tools look at the host itself: its own IP settings, the connections it has open, its ARP cache, and what ports a remote host exposes.

ipconfig / ifconfig / ip: read the local configuration

ipconfig (Windows) and ifconfig or the newer ip command (Linux/macOS) print the interface's IPv4 address, subnet mask, default gateway, and DNS servers. This is the first stop for any "my machine cannot get anywhere" report, because a wrong mask, a missing gateway, or no DNS server explains the symptom instantly. The single most diagnostic value here is an address in the 169.254.0.0/16 range[4]: that is an Automatic Private IP Addressing (APIPA) link-local address, which a host assigns itself only when it asked for a DHCP lease and got no answer, so an APIPA address means the DHCP server is unreachable or the pool is exhausted.

netstat: local ports and connections

netstat lists the host's own active connections and the TCP/UDP ports it is listening on. Use it to confirm a service is actually bound and listening (for example that a web server is up on port 443) and to see which remote hosts a machine is talking to. It answers "what is this host listening on and connected to," a local view that nothing on the network can give you.

arp: the IP-to-MAC cache

arp displays and edits the host's Address Resolution Protocol cache[5], the table that maps IPv4 addresses to the MAC addresses on the local segment. It is the tool for diagnosing a suspected duplicate IP or a stale or poisoned mapping: if two hosts claim one address, or an entry points at the wrong MAC, arp shows it. ARP only operates within the local broadcast domain, so an arp entry for an off-subnet host shows the gateway's MAC, not the remote host's.

nmap and a quick port test: remote discovery

nmap scans a remote target (or a whole subnet) to report which hosts are up and which ports they expose, so it answers "what services does this host offer" from across the network. For a single quick check you do not need a full scan: telnet or nc (netcat) to a host and port simply succeeds or refuses, confirming whether one TCP port is open when ICMP is blocked and ping cannot help. Use the port test to prove a service is reachable even when the firewall drops ping.

ipconfig / ifconfig / ipnetstatarpnmap / telnet / ncLocal IP configaddr/mask/gw/DNS, APIPAListening ports + connectionsthis host's own viewIP-to-MAC cachelocal segment onlyOpen ports on a remote hostworks when ping is blocked
Host-side tools and the question each answers; an APIPA address from ipconfig means DHCP failed.

Hardware tools: copper, fiber, and the physical plant

No command running on a host can see a broken conductor, a mislabeled cable, or fiber loss in decibels, so Layer 1 faults need physical tools. Pick the hardware tool by the medium (copper or fiber) and by what you need to find (continuity, distance to a fault, or which jack a cable runs to).

Continuity and wiremap: the cable tester

A cable tester verifies a copper run end to end. The basic version checks continuity; a wiremap tester is the one the exam expects, because it proves opens (a broken conductor), shorts (two conductors touching), reversed pairs, transposed pairs, and split pairs by lighting each pin in turn. It is the right tool the moment you suspect a bad termination or a miswired patch, but it only proves the copper is good; it says nothing about VLANs, routing, or any logical fault.

Distance to a fault: TDR and OTDR

When a cable tests bad or intermittent and you need to know where along a long run the fault is, a reflectometer reports the distance to it. A time-domain reflectometer (TDR) sends a pulse down copper and times the reflection from a break or short; an optical time-domain reflectometer (OTDR) does the same for fiber, reporting distance to a break, splice, or high-loss bend. The pairing to memorize is TDR for copper, OTDR for fiber.

Locate a cable: the toner probe

A toner probe is a two-piece tool: a tone generator clipped to one end of a cable injects an audible signal, and an inductive probe waved over a bundle of cables at the far end finds the one carrying the tone. It is the tool for the specific job of locating or labeling an unmarked cable in a crowded patch panel or wiring closet, a job no tester or analyzer does.

Power, light, and the bench tools

A few tools confirm the physical layer can carry signal at all. A light meter (optical power meter) reads the optical power arriving on a fiber in dB, the way you confirm a fiber run is inside its loss budget rather than too long, dirty, or bent. A multimeter measures voltage, resistance, and continuity, useful for verifying power to a device or a coax run. A loopback plug folds a port's transmit pins back into its receive pins so the port talks to itself, proving a NIC or switch port can send and receive; it confirms the port works but never locates a cable break.

Copper or fiber?and what to findCable tester (wiremap)open/short/miswireTDR / toner probedistance / locate cableLight meter / OTDRfiber dB / fault distanceLoopback plugproves a port TX/RX, not a breakcopper, pinoutcopper, distancefibernot for locating
Choose the hardware tool by medium and need; TDR is copper, OTDR is fiber, and a loopback plug only confirms a port works.

Protocol analyzers and wireless tools

Two categories of tool answer questions the simpler commands cannot: protocol analyzers, which decode the actual packets, and wireless tools, which read the radio environment.

Protocol analyzers: see the packets

A protocol analyzer (packet analyzer or packet sniffer) such as Wireshark or the command-line tcpdump captures frames off the wire and decodes them field by field, so it can answer almost any question about what a host sent or received. That makes it the most powerful tool and also the slowest, so it is the last resort: reach for it only when you must see the protocol exchange itself, such as a TLS handshake that fails partway, a DHCP DISCOVER that gets no OFFER, or a flood of TCP retransmissions. To capture traffic that is not destined for the analyzer's own port on a switch, you configure port mirroring (a SPAN port), which copies frames from one or more switch ports to the monitoring port; without it a switch forwards only the analyzer's own traffic. Capturing also normally requires putting the NIC in promiscuous mode so it accepts frames addressed to other hosts.

Wi-Fi analyzer: channels, signal, and interference

A Wi-Fi analyzer scans the wireless bands and reports the access points in range, the channel each uses, and the signal strength a client sees. It is the tool for wireless that is slow or dropping, because it exposes co-channel and adjacent-channel interference (too many APs sharing or overlapping a channel) and weak signal (too far from the AP or an obstruction). The fix it points to is choosing non-overlapping channels or moving or adding an AP. Wi-Fi spans the 2.4 GHz and 5 GHz bands[6] (Wi-Fi 6E and Wi-Fi 7 add 6 GHz), and the 2.4 GHz band has only three non-overlapping channels (1, 6, 11), which is why crowded 2.4 GHz cells interfere so easily.

Spectrum analyzer: non-Wi-Fi RF

When interference is not coming from other access points, a spectrum analyzer shows raw radio energy across a band, revealing non-Wi-Fi sources such as microwave ovens, cordless phones, or Bluetooth devices that a Wi-Fi analyzer (which only sees 802.11) cannot. The distinction the exam draws is that a Wi-Fi analyzer reads the 802.11 network, while a spectrum analyzer reads the RF spectrum itself.

Protocol analyzerWi-Fi analyzerSpectrum analyzerDecoded packetsneeds port mirroring / SPAN802.11 channels + signalco-channel interferenceRaw RF energynon-Wi-Fi sources
A protocol analyzer reads packets, a Wi-Fi analyzer reads 802.11 channels, a spectrum analyzer reads raw RF including non-Wi-Fi interference.

Exam-pattern recognition: symptom to tool

Network+ tool questions almost always give a symptom and ask which tool finds the cause. The winning move is to map the symptom to the layer, then to the one tool that answers it, and to reject distractors that confuse a physical tool with a logical one or one CLI tool with another.

Reachability and path stems

A stem that says a host cannot be reached is testing ping first (is it alive), then traceroute (which hop breaks). When the stem says "identify the router where traffic stops," the answer is traceroute, not ping; when it says "confirm the server is up," the answer is ping. The trap is concluding a host is down from a failed ping alone, when a firewall may simply drop ICMP, the correct follow-up is a TCP port test with telnet or nc.

Name and address stems

A stem where a site loads by IP but not by name is a DNS question, and the tool is nslookup or dig, never ping by name. A stem where a workstation shows a 169.254.x.x address is an APIPA symptom, read with ipconfig, and it means DHCP is unreachable or its pool is exhausted, not that DNS is broken. A stem about a suspected duplicate IP or a wrong MAC mapping points at arp.

Physical-layer stems

A stem to locate or label an unknown cable in a closet is always the toner probe. A stem to find the distance to a cable fault is a reflectometer: TDR for copper, OTDR for fiber, the most common physical-tool distractor pair. A stem to verify a fiber link is within its loss budget is a light meter. A stem to prove a switch port itself works is a loopback plug, and its trap is choosing it to locate a break, which it cannot do.

Wireless and packet stems

A stem about a slow or dropping wireless network points at a Wi-Fi analyzer for channel and signal data; if the interference is from a microwave or cordless phone rather than another AP, it is a spectrum analyzer. A stem that can only be solved by reading the actual packet exchange (a failing handshake, a missing DHCP offer, retransmissions) is the protocol analyzer, and remember it needs port mirroring on a switch to see traffic for other ports. The trap is reaching for the analyzer when a quick ping or traceroute would already answer the question.

What is the symptom?name the layer firstping / tracerouteunreachable / slownslookup / digname fails, IP worksipconfig169.254 = DHCP failWi-Fi analyzerwireless slow/dropToner probelocate a cableTDR / OTDRdistance to faultProtocol analyzerread the packets
Map the symptom to the layer, then to the one tool that answers it; physical-tool and CLI-tool distractors are the usual traps.

Which tool confirms which symptom

ToolTypeConfirms / answersReach for it when
pingSoftware / CLIReachability, latency, packet loss (ICMP echo)You need to know if a host is alive and how cleanly
traceroute / tracertSoftware / CLIEvery router hop and where the path breaks or slowsping fails or is slow and you need the responsible hop
nslookup / digSoftware / CLIDNS resolution: which server answered, what recordA name fails but its IP works
ipconfig / ifconfig / ipSoftware / CLILocal address, mask, gateway, DNS, APIPAYou suspect a wrong or missing local IP config
netstatSoftware / CLILocal listening ports and active connectionsYou need to see what the host is listening on or connected to
nmapSoftware / CLIOpen ports and live hosts on a remote targetYou must map which services a host exposes
Protocol analyzer (Wireshark / tcpdump)Software / CLIDecoded packet contents on the wireOnly a packet-level view answers the question
Cable tester (wiremap)HardwareContinuity, opens, shorts, miswires, split pairsYou suspect a bad termination or broken conductor
TDR / OTDRHardwareDistance to a copper (TDR) or fiber (OTDR) faultAn intermittent fault is somewhere along a long run
Toner probeHardwareWhich jack or port a cable connects toYou must locate or label an unmarked cable
Wi-Fi analyzerHardware / softwareChannels, signal strength, co-channel interferenceWireless is slow or dropping
Light meterHardwareOptical power / loss in dB on a fiber runYou must verify a fiber link is within its loss budget

Decision tree

Physical or logical fault?name the layer firstLogical: which symptom?Layer 3 and abovePhysical: which symptom?Layer 1, the mediumlogicalphysicalnslookup / digname fails, IP worksipconfig / ifconfig / ip169.254 APIPA = DHCP failping then tracerouteunreachable / slowProtocol analyzerlast resort, read packetsnamelocal IPreachabilitystill unsolvedToner probelocate a cableTDR / OTDRdistance: copper / fiberLight meterfiber dB loss budgetWi-Fi analyzerchannels / signallocatedistancefiber losswireless
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Name the layer before you pick a tool

Decide first whether a symptom is physical (Layer 1) or logical (Layer 3 and above), because that one split eliminates most wrong-tool answers. A dead cable, a port that will not light, or a powered device that will not boot is physical and needs a hardware tool like a cable tester, TDR, or toner probe. Reachability, addressing, name resolution, and routing are logical and need a command-line tool like ping, traceroute, nslookup, or ipconfig.

ping tests reachability, traceroute tests the path

ping sends ICMP echo requests and reports whether a host answers plus the round-trip latency and loss, so it answers "is it alive and how cleanly." traceroute (tracert on Windows) reports every router hop to the destination and where the path breaks or slows, so it answers "which hop is responsible." Confirm the destination is alive with ping first, then switch to traceroute once you know it is unreachable or slow.

Trap Reaching for traceroute to test whether a host is simply up; that wastes time mapping hops when one ping already answers the liveness question.

11 questions test this
A failed ping is not proof a host is down

Many firewalls drop ICMP while still passing real application traffic, so a host that will not answer ping can still be serving on its TCP ports. When ping fails, confirm with a TCP port test, telnet or nc (netcat) to the service port, before declaring the host unreachable. A successful port test with a failed ping means ICMP is filtered, not that the service is down.

Trap Concluding a server is down from a failed ping alone, when the firewall is only dropping ICMP and the service port is still open.

A silent traceroute hop is usually rate-limiting, not a failure

traceroute works by raising the IP TTL one step at a time so each router returns an ICMP Time Exceeded, but routers commonly rate-limit or deprioritize that ICMP. A single middle hop showing asterisks while later hops still answer is that router quietly throttling, not a break. Read the path by the last hop that answers normally and the first that does not, not by one silent hop in the middle.

Trap Treating an asterisk on one middle hop as the point of failure, when later hops still respond and the gap is just ICMP rate-limiting.

10 questions test this
Use nslookup or dig when a name fails but the IP works

When a site loads by IP address but not by name, the fault is name resolution, and nslookup (cross-platform) or dig (more detailed, on Linux and macOS) query a DNS server directly to prove it. They show which server answered and what record came back, separating a DNS problem from a connectivity problem in one command. You can also aim them at a specific resolver to test whether one server is stale while another is correct.

Trap Pinging the hostname to diagnose a name failure; ping by name blends DNS and connectivity, so it confirms something is wrong but never that DNS specifically is the cause.

11 questions test this
ipconfig reads the local IP config; 169.254 means DHCP failed

ipconfig (Windows) and ifconfig or ip (Linux and macOS) print the interface's address, subnet mask, default gateway, and DNS servers, the first stop for a "my machine cannot get anywhere" report. An address in the 169.254.0.0/16 range is an APIPA (Automatic Private IP Addressing) link-local address, which a host assigns itself only after asking for a DHCP lease and getting no reply. So an APIPA address means the DHCP server is unreachable or its pool is exhausted, not that DNS or routing is broken.

Trap Reading a 169.254.x.x address as a DNS or gateway problem; it is the specific signature of a failed DHCP lease.

netstat shows a host's own ports and connections

netstat lists the local host's active TCP and UDP connections and the ports it is listening on, a view only the host itself can give. Use it to confirm a service is actually bound and listening (for example a web server on port 443) and to see which remote hosts a machine is talking to. It is the local counterpart to nmap, which scans ports from across the network.

6 questions test this
arp shows the IP-to-MAC cache for the local segment

arp displays and edits the host's Address Resolution Protocol cache, the table mapping IPv4 addresses to MAC addresses on the local broadcast domain. It is the tool for a suspected duplicate IP or a stale or poisoned mapping: if two hosts claim one address, or an entry points at the wrong MAC, arp shows it. ARP only works within the local segment, so an entry for an off-subnet host shows the default gateway's MAC, not the remote host's.

Trap Expecting an arp entry to show a remote off-subnet host's MAC; ARP is local-only, so it returns the gateway's MAC for anything off the segment.

6 questions test this
nmap maps which ports a remote host exposes

nmap scans a remote target or a whole subnet to report which hosts are up and which ports they expose, answering "what services does this host offer" from across the network. For a single quick check you do not need a full scan: a telnet or nc connection to one host and port simply succeeds or refuses. Reach for nmap when you must discover the service footprint, and for the one-port test when you just need to confirm a single port is reachable.

A protocol analyzer is the last resort, not the first

A protocol analyzer (packet sniffer) such as Wireshark or the command-line tcpdump captures frames and decodes them field by field, so it can answer almost any question about what a host sent or received. That power costs time and expertise, so it belongs at the end of the workflow, after cheaper tools have narrowed the problem. Reach for it only when you must read the protocol exchange itself, such as a TLS handshake that fails partway, a DHCP request that gets no offer, or a retransmission storm.

Trap Capturing packets to answer a question ping or traceroute already settles; the analyzer is for protocol-level mysteries, not basic reachability.

2 questions test this
Capturing on a switch needs port mirroring

A switch forwards unicast frames only to the destination port, so a protocol analyzer plugged into one port sees only its own traffic plus broadcasts. To capture another port's traffic you configure port mirroring (a SPAN port), which copies frames from one or more ports to the monitoring port. Capturing also normally requires the analyzer's NIC in promiscuous mode so it accepts frames addressed to other hosts.

Trap Expecting a packet capture on a switched network to see every host's traffic by default; without a mirror or SPAN port the switch never forwards it to the analyzer.

8 questions test this
A wiremap cable tester proves continuity and pinout

A wiremap cable tester lights each conductor in turn to prove opens (a broken conductor), shorts (two conductors touching), reversed pairs, transposed pairs, and split pairs on a copper run. It is the right tool the instant you suspect a bad termination or a miswired patch. It only proves the copper is good, though, and says nothing about VLANs, routing, or any logical fault, so once continuity passes, move up to the command-line tools.

2 questions test this
TDR locates copper faults; OTDR locates fiber faults

When a cable tests bad or intermittent and you need to know where along a long run the fault is, a reflectometer reports the distance to it. A time-domain reflectometer (TDR) pulses copper and times the reflection from a break or short; an optical time-domain reflectometer (OTDR) does the same for fiber, reporting distance to a break, splice, or high-loss bend. The pairing to memorize is TDR for copper, OTDR for fiber.

Trap Using a copper TDR on a fiber run (or an OTDR on copper); the medium decides the instrument, TDR for copper and OTDR for fiber.

11 questions test this
A toner probe locates an unlabeled cable

A toner probe is a two-piece tool: a tone generator clipped to one end injects an audible signal, and an inductive probe waved over a bundle at the far end finds the cable carrying that tone. It is the tool for the specific job of locating or labeling an unmarked cable in a crowded patch panel or wiring closet. No tester or analyzer does this job; only the toner probe traces one physical cable through a bundle.

A light meter verifies fiber is within its dB loss budget

Fiber health is measured as optical loss in decibels, and a light meter (optical power meter) reads the power arriving at the far end of a run. A reading outside the link's loss budget means the run is too long for the optic, a connector is dirty, or the fiber is bent past its minimum radius. Use the light meter to confirm a fiber link carries enough signal; use an OTDR when you also need the distance to the fault.

2 questions test this
A loopback plug proves a port works but never locates a break

A loopback plug folds a port's transmit pins back into its receive pins so the port talks to itself, proving a NIC or switch port can send and receive. It confirms the port hardware is functional, which is useful to rule the port in or out. It never locates a cable fault or measures distance, so reaching for it to find where a cable is broken is the classic loopback distractor.

Trap Choosing a loopback plug to locate a cable break; it only tests that a port can transmit and receive, not where the wire is faulted.

4 questions test this
A Wi-Fi analyzer reads 802.11 channels and signal

A Wi-Fi analyzer scans the wireless bands and reports the access points in range, the channel each uses, and the signal strength a client sees, so it is the tool for wireless that is slow or dropping. It exposes co-channel and adjacent-channel interference (too many APs sharing or overlapping a channel) and weak signal, pointing to a fix of non-overlapping channels or moving the AP. The 2.4 GHz band has only three non-overlapping channels (1, 6, 11), which is why crowded 2.4 GHz cells interfere so easily.

A spectrum analyzer finds non-Wi-Fi RF interference

A Wi-Fi analyzer only sees 802.11 traffic, so when the interference comes from a microwave oven, cordless phone, or Bluetooth device rather than another access point, it shows nothing. A spectrum analyzer reads raw radio energy across a band and reveals those non-Wi-Fi sources. The distinction the exam draws is that a Wi-Fi analyzer reads the 802.11 network while a spectrum analyzer reads the RF spectrum itself.

Trap Using a Wi-Fi analyzer to chase interference from a microwave or cordless phone; it only sees 802.11, so non-Wi-Fi RF needs a spectrum analyzer.

1 question tests this
Run reachability tools in order: ping, then traceroute, then nslookup/dig

The fast triage for a "the internet is down" report is to run three command-line tools in sequence, each answering one question. ping asks whether the destination is alive and how cleanly; traceroute asks which hop breaks once ping says it is unreachable or slow; nslookup or dig asks whether the name resolves when a site works by IP but not by name. Running them host-outward narrows the fault quickly without jumping to a packet capture.

1 question tests this
tcpdump -w writes raw packets to a pcap file for Wireshark

The tcpdump -w flag saves captured packets in raw pcap binary form to a file instead of printing them, and the file opens directly in Wireshark or reads back with tcpdump -r. Combine it with -i to pick the interface and a trailing BPF expression to limit what is captured, for example tcpdump -i eth0 -w capture.pcap port 80 to save only HTTP traffic.

Trap Using -r or a display option to save a capture, when -w is the flag that writes the pcap file.

4 questions test this
Capture filters limit what is recorded; display filters limit what is shown

A Wireshark capture filter uses BPF syntax and decides which packets get written at capture time, so it is the way to shrink the file on a busy network, written like host 10.1.1.50 or port 53. A display filter uses Wireshark's own syntax and only changes what is shown from an already-saved capture, written like ip.src == 192.168.1.100, ip.addr == 10.1.1.50 and tcp.port == 443, or dns.flags.response == 1. The two syntaxes are different and serve different stages.

Trap Expecting a display filter to reduce the capture file size, when only a capture filter limits what is recorded and a display filter just hides already-captured packets.

6 questions test this
Follow TCP Stream isolates a conversation; Protocol Hierarchy summarizes the capture

Follow TCP Stream pulls every packet of a single TCP conversation together by applying a stream-index filter and reconstructs the application-layer exchange between the two endpoints. Statistics, Protocol Hierarchy instead gives a tree of every protocol seen with packet counts and percentages, which is the fast way to spot an unexpected or unauthorized protocol across a large capture.

Trap Reaching for Follow TCP Stream to survey which protocols appeared, when Protocol Hierarchy is the capture-wide breakdown and Follow Stream drills into one conversation.

3 questions test this
On a TDR an open reflects positive, a short reflects negative

A time-domain reflectometer sends a pulse and reads reflections from impedance changes, with the delay giving the distance to the fault. An open circuit, a break or disconnection, is high impedance and returns an in-phase positive upward spike. A short between conductors is low impedance and returns an inverted negative reflection. A localized impedance change without a full open or short, such as a kink, crush, or crimp, shows as a sharp anomaly at that distance even when a basic wiremap still passes.

Trap Reading a positive TDR spike as a short, when the in-phase upward reflection is an open and the inverted reflection is the short.

7 questions test this
pathping computes per-hop loss to find which router drops packets

Pathping first traces the route, then sends repeated probes to every hop over a sustained period and reports per-hop and per-link latency and packet-loss percentages. That makes it the right tool for intermittent slowness where connectivity is never fully lost: it pinpoints which specific router or link along the path is dropping the most packets, which a single traceroute or ping cannot do.

Trap Using a one-shot traceroute to find an intermittent packet-dropping hop, when pathping is what accumulates per-hop loss statistics over time.

4 questions test this
Read a traceroute by where replies stop, repeat, or jump in time

Traceroute output is diagnostic by pattern. Hops that reply normally then turn into all-timeouts mark the failure at or just beyond the last responding hop. The same two addresses alternating across many hops until the max hop count is a routing loop, where packets bounce until the TTL expires. A sudden large latency jump between two hops, with later hops staying near that level, locates the added delay on the link between those two hops.

Trap Blaming the hop that times out, when the fault is at or just past the last hop that actually replied.

13 questions test this
netstat -ano maps listening ports to owning process IDs and shows socket states

On Windows, netstat -ano lists all connections and listening ports (-a) numerically (-n) with the owning process ID (-o), so it ties a port like 443 to the exact process serving it. The connection state column is itself diagnostic: many SYN_SENT entries to one host mean the remote end is not answering, and many CLOSE_WAIT entries mean the local application received the client's FIN but never closed its sockets, an application-level socket leak.

Trap Reading CLOSE_WAIT pileups as the remote side hanging, when CLOSE_WAIT means the local application failed to close its half of the connection.

5 questions test this
A centralized syslog server correlates timestamped events across devices

A centralized syslog server aggregates timestamped log messages from every network device into one place, which is what lets you correlate the timing of events, an interface flapping, a device rebooting, a spanning tree reconverging, across multiple switches and routers at once. It is the right approach for intermittent, multi-device problems where you need to line up when things happened. Syslog severity runs 0 Emergency to 7 Debug, with level 4 meaning Warning.

Trap Logging into each device one at a time to chase an intermittent multi-device fault, when centralized syslog lines the events up on a single timeline.

7 questions test this
An RJ45 loopback plug wires pin 1 to 3 and pin 2 to 6

An RJ45 Ethernet loopback plug connects the transmit pair, pins 1 and 2, to the receive pair, pins 3 and 6, so data the port sends loops straight back into its own receive circuit to confirm the port transmits and receives. It proves a port works but, having no run of cable, it can never locate a break or a distance fault.

Trap Expecting a loopback plug to find where a cable is broken, when it only validates the local port and cannot locate a fault along a run.

2 questions test this
A visual fault locator pinpoints a fiber bend or break by escaping red light

A visual fault locator injects bright visible red light, typically around 650 nm, into a fiber, and at a sharp bend, crack, or break the light escapes through the jacket and is visible to the eye, so the technician can walk the run and pin down the exact fault location. It is the quick visual tool for locating a physical fiber fault, distinct from an OTDR's distance trace or a light meter's loss measurement.

Trap Reaching for a light meter to locate a fiber bend, when a light meter only measures end-to-end loss and the VFL shows the physical fault point.

2 questions test this
Read nslookup output to separate a wrong server from a dead resolver

nslookup's first lines name the DNS server it queried, so when only one workstation cannot resolve internal names and that server is an external public resolver, the host is simply pointed at the wrong DNS server. A reply of DNS request timed out means the configured server did not answer, and the next isolating step is to ping that server's IP to test reachability. A Non-authoritative answer is normal: the response came from a caching resolver rather than the zone's authoritative server.

Trap Treating a Non-authoritative answer as an error, when it just means the answer came from a cache and is the expected result of recursive resolution.

5 questions test this

References

  1. RFC 792 — Internet Control Message Protocol (ICMP Echo/Echo Reply, types 8 and 0) Whitepaper
  2. RFC 1393 — Traceroute Using an IP Option (TTL-based hop-by-hop mechanism) Whitepaper
  3. RFC 1035 — Domain Names: Implementation and Specification Whitepaper
  4. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses (APIPA 169.254.0.0/16) Whitepaper
  5. RFC 826 — An Ethernet Address Resolution Protocol (ARP IP-to-MAC mapping) Whitepaper
  6. Wi-Fi CERTIFIED 6 (Wi-Fi 6 on 2.4/5 GHz; Wi-Fi 6E adds 6 GHz) Whitepaper