Every university spoke slows when its traffic hairpins through one hub, and that hub link is the bottleneck shared by all of the spokes. What should the capacity recommendation be?
Select an answer to reveal the explanation.
Short Explanation
You can address the shared bottleneck by raising hub capacity or changing the topology so the spokes are not all forced through the same hub. Capacity or a new path changes the constraint; another alert, a renamed dashboard, or more tests that collect the same delay without a network change only reports or displays the problem. The key is to change how much traffic the hub can carry or where the spokes send it.
Full Explanation
Every spoke slows while its traffic hairpins through the same hub, so the hub link is the shared bottleneck. Raising hub capacity or changing the topology so spokes are not all forced through that hub directly addresses the constraint by adding capacity or providing another path. Adding another alert that fires when any spoke slows through the same hub may detect the slowdown again, but it does not move traffic or increase the link’s capacity. Renaming the campus dashboard may make the bottleneck easier to see, but a clearer label does not change the network path or relieve congestion. Deploying more tests that collect the same spoke delay without a topology, configuration, or QoS change measures the hairpin again while leaving the hub as the only crossing. Exam caveat: identical slowdowns across spokes suggest a shared hub bottleneck, not a need for another alert for each spoke. Practical check: trace sample spokes during a slowdown and confirm they share the hub link; then recommend more hub capacity or a topology that avoids forcing every spoke through it.