CompTIA Network+ Domain 5: Network Troubleshooting

169.254.0.0/16 is the APIPA range a client uses when no DHCP server answers — the classic 'no DHCP' symptom.

• AA 169.254.x.x address is auto-assigned, not the kind of address an admin sets statically.
• CDNS failure breaks name resolution, but the host would still get a normal DHCP IP — not a 169.254 address.
• DDuplex mismatch causes slowness/errors, not an APIPA address. The link would still pass DHCP.

Traceroute lists each router hop and the latency to it, pinpointing where delay is introduced.

• BPing confirms reachability and round-trip time to the destination, but not the per-hop path. It won't show WHERE the slowdown is.
• Cnslookup queries DNS records; it doesn't trace a network path.
• Dipconfig shows local IP settings — nothing about the path to a remote site.

CRC errors and runts are physical-layer symptoms — corrupted frames from a bad cable, connector, or interference.

• BDHCP affects addressing, not frame integrity. It wouldn't generate CRC errors.
• CDNS resolves names; it has no effect on physical frame errors on an interface.
• DA wrong gateway breaks off-subnet routing, but doesn't corrupt frames into CRC errors.

Late collisions plus poor throughput is the signature of a duplex mismatch between the two ends.

• BDNS issues break name lookups, not raw link throughput with collisions.
• CAPIPA means no DHCP and usually no connectivity at all — not a slow-but-working link with collisions.
• DA blocked port stops specific traffic; it doesn't cause physical-layer late collisions.

ipconfig prints the host's IP, mask, and gateway (and with /all, much more).

• BPing tests reachability to another host; it doesn't display local IP configuration.
• Cnetstat lists active connections and listening ports, not the interface's IP settings.
• Dtracert maps the path to a remote host, not local configuration.

STP detects Layer 2 loops and blocks redundant paths, preventing the broadcast storm described.

• BDHCP snooping blocks rogue DHCP servers; it does nothing about switching loops.
• CNAT translates addresses at the network edge — unrelated to Layer 2 loops.
• DQoS prioritizes traffic but can't stop a loop from flooding the segment.

A wrong mask makes the host misjudge which destinations are local vs remote, so it never sends remote traffic to the gateway.

• BA display cable has nothing to do with IP routing decisions.
• CIf you're reaching the server by IP, DNS isn't involved. The symptom is a routing/addressing decision.
• DLocal connectivity works, so the switch is powered. Not the cause.

After establishing a plan and implementing the solution, step six requires verifying full system functionality and, if applicable, implementing preventive measures before the final documentation step is performed.

• ARe-establishing a theory belongs to step two and happens before testing; once the fix works the technician moves forward, not backward, in the documented seven-step process flow.
• BEscalation is only warranted when the technician cannot resolve the issue; here the SFP swap already restored service, so escalating adds no value and skips required closure steps entirely.
• DDocumentation is the seventh and final step, but it comes only after verifying full functionality and applying preventive measures; documenting before verification risks closing a still-broken ticket.

When one side is hard-set to full and the other auto-negotiates, the auto side defaults to half-duplex, producing late collisions, runts, and CRC errors that match the symptoms exactly.

• BEMI typically causes intermittent CRC errors but not the late-collision counter, which is a definitive duplex indicator; the hard-set/auto configuration points clearly to negotiation, not interference.
• CExcessive attenuation degrades or drops the link entirely and would not selectively generate late collisions; the described configuration mismatch is a far more precise fit for these counters.
• DA failing SFP usually produces link flaps or RX power errors rather than late collisions tied to half-duplex operation, and the explicit speed/duplex pinning explains the behavior better.

With transmit light confirmed on both ends yet loss-of-signal everywhere, the fibers are almost certainly cross-connected so each transmitter feeds another transmitter; swapping one LC duplex pair restores link.

• AA distance problem would still allow some receive power to register and usually causes errors rather than a total loss-of-signal on both ends with confirmed transmit light present.
• BA mode mismatch degrades signal and causes high loss, but the symptom of zero receive while transmit is confirmed on both ends points more directly to a strand swap.
• CAn administratively down port would not show optics inserted and reporting loss-of-signal; the ports are clearly active and powered, so a config disable does not explain the readings.

A 169.254.x.x address with a /16 mask and no gateway is APIPA, assigned only when a client cannot reach a DHCP server, and scope exhaustion on a busy guest network fits perfectly.

• BAn expired lease that renews would still show a routable address from the scope, not the 169.254 APIPA range; APIPA only appears when no DHCP offer is received at all.
• CA wrong gateway option would still hand the client a valid scope address with that bad gateway; an empty gateway and a 169.254 address instead signal that no DHCP reply arrived.
• DDNS failures prevent name lookups but the client would still hold a valid leased IP and gateway; an APIPA self-assigned address shows the problem occurs earlier, at address acquisition.

Since the host reaches its gateway but nothing beyond it, the gateway itself cannot forward the traffic, indicating a missing route or default route on the router toward remote destinations.

• ABad DNS would break name resolution but the failure to reach remote hosts even by IP shows a routing or gateway problem, not a name-lookup issue that DNS alone would cause.
• BA wider mask such as /16 would make the host treat remote addresses as local and ARP for them, but the host already reaches its gateway, so the symptom centers on routing past it.
• CA wrong VLAN would typically break local connectivity too, yet this host successfully pings same-subnet peers and its gateway, so layer-two VLAN membership is clearly correct here.

Choppy, robotic audio with widely varying inter-packet delays is the classic signature of jitter, the variation in latency that overruns or empties the voice de-jitter buffer.

• ABandwidth saturation would slow downloads too, but transfers stay fast here; the issue is variable timing of small voice packets rather than a lack of overall throughput capacity.
• BAverage latency is described as low and ping round-trip times are good, so steady delay is not the culprit; the variation in delay, not its average, degrades the voice quality.
• DPacket loss causes dropouts and gaps rather than the varying-delay pattern shown in the capture, and nothing indicates a hardware optic fault; the data points specifically to timing variance.

Both nslookup and dig let you target a specific server, for example dig @ns1 app A, querying the authoritative source directly and bypassing the client resolver and local cache.

• ANetstat displays active sockets and listening ports on the local host but cannot issue a DNS query or return record contents, so it cannot validate what a name server answers.
• CTraceroute maps the layer-three path of hops to a destination but does not reveal which A record a particular authoritative server returns, so it cannot verify the DNS answer.
• DA cable tester checks physical wiring continuity and pinout but has no ability to perform a DNS lookup or interrogate an authoritative server, making it irrelevant to this resolution task.

Step three says to test the theory and, when testing does not confirm it as the swap here did not, the technician must reestablish a new theory of probable cause or escalate to a higher tier.

• AImplementing a solution and verifying functionality are later steps that apply only after a theory is confirmed; the swap disproved this theory, so there is no working solution to roll out yet.
• CDocumentation is the final seventh step and is performed only after a verified fix restores service; closing the ticket now would record an unresolved outage that is still broken.
• DIdentifying the problem and duplicating it belong to the first step, which the technician has already completed; repeating step one ignores the methodology's instruction to revise the theory after a failed test.

Tight zip ties pulled around a sharp corner force the fiber below its minimum bend radius, so light escapes the core as macrobend loss, producing the high attenuation and load-sensitive errors observed.

• ANothing indicates the run is too long, and distance attenuation would be constant rather than concentrated at the tight corner; the sharp bend and overtightened ties point to a different loss mechanism entirely.
• BA mode mismatch causes high loss regardless of how the cable is routed and would not improve with better physical handling; the symptom is tied directly to the overtightened corner, not the optics type.
• DThe technician already cleaned and reseated the connectors without improvement, which rules out end-face contamination; the remaining culprit is the mechanical stress from the tightly bent routing.

Routing unshielded copper alongside an elevator motor and fluorescent ballasts injects electromagnetic interference that corrupts frames, producing CRC and input errors that spike exactly when the motor draws current.

• AA duplex mismatch generates late collisions and errors continuously and independently of the elevator; the fact that the errors spike precisely when the motor energizes points to an external interference source instead.
• BThe cable tester confirms the length is acceptable and within spec, which eliminates distance attenuation; the time correlation with the elevator motor indicates electrical noise rather than signal loss over distance.
• CA split pair shows up as a wiring fault and would degrade signal regardless of the elevator, but the tester reports a correct pinout, so the errors tracking motor activity indicate interference, not miswiring.

The plugged-in consumer router runs its own DHCP service and races the legitimate server, handing some clients a 192.168.0.x address and wrong gateway that cannot route to the 10.10.0.0/16 internal resources.

• BAPIPA self-assigned addresses fall in the 169.254.0.0/16 range with no gateway, but these clients received a routable 192.168.0.x lease with a gateway, so an unauthorized server, not exhaustion, is responsible.
• CDNS resolves names to addresses and never assigns a client's IP, mask, or gateway; these users were handed an entirely wrong subnet, which is a DHCP-layer issue rather than a name-resolution one.
• DA duplicate IP affects a single address and triggers conflict warnings, but it would not cause multiple clients to receive a completely different subnet and gateway, which only an unauthorized DHCP server explains.

The old A record's time-to-live has not yet expired in the clients' or the local resolver's cache, so they keep returning the stale address until the entry ages out or an administrator flushes it.

• AIf the clients were pointed at the wrong DNS server, flushing the local cache would not resolve the issue because the bad server would still answer; the temporary fix shows the resolver is correct but caching stale data.
• CA duplicate IP on the new server would cause intermittent reachability to the new host, not a consistent, clean resolution to the old address that a simple cache flush reliably corrects each time.
• DAn incorrect mask breaks routing for whole ranges of destinations rather than selectively resolving one hostname to a stale IP, and flushing a DNS cache would have no effect on a layer-three mask error.

Utilization pinned at 100 percent with a full egress queue and rising output drops is the classic signature of link saturation, and the simultaneous large backups are consuming all available WAN bandwidth.

• AA duplex mismatch produces CRC errors and late collisions, yet those counters read zero here; the symptoms are a full transmit queue and output drops, which indicate congestion rather than a negotiation fault.
• BA failing optic typically logs receive errors or causes the link to flap, but the interface is clean apart from output drops tied to load, pointing to traffic volume instead of a hardware module problem.
• DJitter is variation in delay that mainly harms real-time media timing, not bulk web and backup throughput; the saturated interface with output drops reflects congestion from overusing capacity, not timing variance.

This switch command lists each learned MAC address alongside its VLAN and the specific interface it was learned on, letting the technician map the offending device's MAC straight to the exact port for isolation.

• BThe ARP cache maps IP addresses to MAC addresses for hosts the workstation has recently contacted, but it provides no information about which switch port a given MAC is connected to on the network.
• CThe netstat -r command prints the local host's routing table of network destinations and next hops, which has nothing to do with switch interface-to-MAC associations needed to physically locate the device.
• DPathping measures latency and packet loss at each hop along a route to a destination, but it cannot reveal which switch interface learned a particular MAC address, so it cannot locate the port.

Choosing layer 3 first and then moving up or down based on the result deliberately halves the OSI stack on each test, which is exactly the divide-and-conquer strategy of isolating from the middle outward.

• AThe top-down approach begins testing at layer 7 and works downward, but this technician deliberately started in the middle at layer 3 to bisect the stack, so the top-down label does not fit her method.
• BBottom-up begins at layer 1 cabling and works steadily upward, yet she began at the network layer to split the model in half rather than starting at the physical wiring, so this label is incorrect.
• DEscalation transfers an unresolved issue to a higher tier and is appropriate only after local theories are exhausted, but here she is actively isolating the failing layer rather than handing off ownership of the problem.

Each powered device draws from the switch's finite PoE budget, and once cumulative consumption reaches the power supply's wattage ceiling the switch refuses to energize additional ports, which matches the logged denial exactly.

• BA class mismatch could cap per-port wattage, but the camera powers cleanly on a bench injector and the switch explicitly logs total budget exhaustion, so the shortfall is aggregate supply rather than a per-port standard difference.
• CAn over-length run can reduce delivered voltage, yet the device powers up on a local injector and the switch reports a budget ceiling rather than a voltage-drop fault, pointing to total power and not cable distance.
• DA duplicate IP would only affect network reachability after the device already has power, but it cannot stop PoE delivery itself, and the observed symptom is a power denial logged against the supply budget.

Using conductors from two different twisted pairs preserves end-to-end continuity so the wiremap passes, but it destroys the differential pairing, generating the near-end crosstalk that cripples gigabit signaling while leaving slower speeds usable.

• AAn open would break continuity on a pin and fail the basic wiremap outright, but this cable passed continuity and even carries 10/100 traffic, so a broken conductor cannot explain a crosstalk-only failure at gigabit.
• BA short usually registers on the wiremap and can disable the link entirely, yet continuity passed and slower speeds work cleanly, so a dead short does not match the near-end crosstalk symptom seen only at gigabit.
• CExcessive length causes attenuation that degrades all speeds and would likely impair 10/100 as well, but slower modes run fine and the tester reports a crosstalk fault rather than a distance-related signal loss.

Placing the port in VLAN 80 drops the PC into a broadcast domain with no relay to VLAN 20's DHCP server, so it falls back to an APIPA address and cannot reach the resources that live in VLAN 20.

• AScope exhaustion would affect many clients drawing from that pool, but only this relocated port is failing and it now sits in a different VLAN with no reachable DHCP, so pool exhaustion is not the explanation.
• CA duplicate address produces a conflict warning on a real assigned lease, not an APIPA self-assignment, and it would not appear precisely after the port was moved into a different VLAN, so it does not fit.
• DA failed NIC driver would usually stop the link from negotiating full speed at all, yet the port comes up cleanly, and the meaningful change is the VLAN reassignment cutting the host off from its DHCP server.

DHCP discovery is a broadcast that routers do not forward by default, so without an ip helper-address relaying it to the server in another subnet, new-VLAN clients never receive a lease and default to APIPA addressing.

• AA corrupt database would disrupt leasing for every VLAN, including the existing ones that are still working fine, so a failure isolated entirely to the brand-new subnet must originate somewhere other than the server's database.
• BAPIPA is automatic self-assignment that occurs when no DHCP reply is received, not a manual configuration, and seeing it across every new-VLAN client at once indicates they cannot reach the server rather than deliberate static settings.
• DA pruned or missing VLAN on the trunk would break all connectivity for that VLAN, but these clients can still communicate locally within their subnet and only cross-subnet DHCP is failing, which is a relay problem.

The 2.4 GHz band provides only three non-overlapping channels of 1, 6, and 11, so access points on 1, 4, and 8 overlap and interfere, producing the retries and reduced throughput even while signal strength stays strong.

• BThe users already report a strong signal, so weak coverage is not the problem, and raising transmit power would actually worsen the overlap between the competing access points crowded onto adjacent channels in the band.
• CMTU mismatches cause fragmentation at layer 3 and are unrelated to a radio band or channel plan, while the spectrum analysis specifically shows overlapping channels as the source of the contention and retries.
• DReusing an SSID across access points is normal practice that enables seamless roaming and does not by itself overlap channels, whereas the analyzer clearly reveals adjacent-channel conflict on 1, 4, and 8 as the culprit.

Issuing set type=MX in nslookup instructs the resolver to return the domain's mail-exchanger records, directly exposing the mail server hostnames and their priorities so the technician can verify the mail routing.

• AA plain nslookup query returns the host address record by default and does not display mail-routing entries, so it cannot directly confirm or refute the mail-exchanger configuration the technician needs to inspect.
• BTraceroute maps the layer-3 hop path toward a destination and measures latency, but it cannot query or display DNS resource records of any type, so it reveals nothing about the domain's mail-exchanger entry.
• CPing confirms ICMP reachability to a resolved address but never returns the contents of DNS records, so it cannot show whether the domain's mail-exchanger records are correctly published or misconfigured.