A hotel chain's tests to the reservation system start black-holing traffic at the moment a summary route appears on the path. What does the collected data point to?
Select an answer to reveal the explanation.
Short Explanation
Think of a road that closes the moment a new detour sign goes up. You treat the summary route as the cause, because the black hole begins when that routing change appears. A slow browser, a DNS-only story, and a wireless ticket ignore the timing the path data gave you.
Full Explanation
The black hole begins at the moment the summary route appears, so the collected data points at that routing change. A new summary can attract traffic for destinations the advertising router is not prepared to forward, and a drop that starts with the route is that kind of finding. A slow browser waterfall would matter if the reservation page were slow while the path still forwarded, and the symptom here is black-holed traffic. A DNS-only failure would be a name that does not resolve, not a path that starts dropping when a route appears. A wireless problem at the front desk would be local radio loss, and it would not turn on at the same moment as a summary route on the path. The browser, the name lookup, and the radio do not share the timestamp the route change does. Exam caveat: tie the conclusion to the change that lines up with the failure, which here is the summary route rather than the application. Operational check: align the path-test history with the appearance of the summary and confirm the black hole starts at that change.