Tests from a logistics hub stay clean in both directions until the hop at the far firewall, where loss begins. What should the analyst examine?
Select an answer to reveal the explanation.
Short Explanation
A road that is smooth until one checkpoint is telling you to inspect that checkpoint. You look at the far-firewall hop because both directions stay clean until loss begins there. The handheld browser, DNS alone, and a wireless ticket for the hub floor do not fit a path that is healthy up to that hop.
Full Explanation
Both directions stay clean until the hop at the far firewall, and loss begins there, so the path has already shown that everything in front of that hop forwarded the test. The analyst should examine the far-firewall hop where loss begins after a clean path, because that is the spot the metric changes. The browser on the handheld scanner used at the dock would be a client symptom. It would not create loss that starts at a distant firewall hop after a clean path in both directions. A DNS-only fault even though the path reaches that firewall would fail before a healthy hop-by-hop path existed. This trace reaches the firewall, so name lookup is not what broke. A wireless ticket for the hub floor that this path test does not cross sends the team to a radio segment the test never marked as the start of loss. Exam caveat: start where the metric goes bad when earlier hops are clean in both directions, and do not move the ticket to a client or a radio segment the trace did not implicate. Operational check: repeat the test in both directions, confirm loss still begins at the far firewall hop, and compare that hop with the clean hops in front of it.