A university spoke reaches its applications only by hairpinning through a congested hub, and delay stays high even though the spoke link itself is quiet. Which recommendation belongs in the capacity report?
Select an answer to reveal the explanation.
Short Explanation
Think of hairpin traffic like driving across town only to turn around and drive back out. You clear the university delay by changing the topology so the spoke reaches its applications without crossing the congested hub. Another alert, a renamed dashboard, or a duplicate test still leaves that detour in place.
Full Explanation
Spoke traffic that can reach its applications only by traveling to the hub and back is hairpinning, so the quiet spoke link is not the bottleneck. A capacity recommendation has to change topology, configuration, or QoS. The change that removes this delay is a topology change giving the spoke a path that does not backhaul through the congested hub. Raising a second alert that pages the same campus team whenever hub delay returns only repeats a notification operators can already see, and it installs no better path. Renaming the university dashboard so the congested hub is easier to notice changes a label on a screen and leaves forwarding as it is. Deploying another test that records the same hairpin delay, while leaving the forwarding path unchanged, adds a duplicate measurement of the current design rather than a topology, configuration, or QoS action. Exam caveat: more visibility into a structural bottleneck is not itself the capacity action the report was asked to deliver. Operational check: after the spoke is moved, confirm its application flows no longer traverse the hub and that delay falls with the hub out of the path. If the hub is still on the route, the recommendation was not carried out.