On event days at a stadium, path tests show a healthy forward path and loss only where the return path takes a different route. Where should the analyst place the fault?
Select an answer to reveal the explanation.
Short Explanation
A road can be clear heading downtown and jammed only on the way home. You place the fault on the return path, because that is the only direction the stadium tests show as lossy. The phone browser, a DNS-only story, or the event wireless network does not match a one-way path fault.
Full Explanation
The path tests show a healthy forward path and loss only where the return path takes a different route, so the fault follows the return path rather than the whole round trip. Asymmetric routes are a normal reason one direction is clean while the other is lossy, and the measurement already separates the two directions. The browser that renders the ticket page can make a screen look slow, but a browser fault is not directional in the way this test is: it would not leave the forward path healthy while only the return path loses packets. DNS only is a poor fit because the test has already produced both a forward path and a return path, which means the name was resolved far enough for the hops to be measured, and a name fault would not single out the return direction. The stadium wireless network is a tempting ticket on event days, yet the evidence is loss on the return route of the path test, not a wireless symptom, so opening that ticket skips the path the data already named. On the exam, when the two directions disagree, keep the fault on the direction that is lossy. In production, compare forward and return hops on the same event-day test and work the lossy return route before you chase the browser, the name, or the wireless network.