Two access switches on the same ward are both eligible to become the spanning tree root bridge. A technician wants the more powerful aggregation-facing switch, not either access switch, to remain root. What is the most direct way to ensure this?
Select an answer to reveal the explanation.
Short Explanation
Root bridge elections come down to one number: priority. Lower always wins, so setting the aggregation switch's priority below the access switches' values is the direct, deliberate way to guarantee it stays root instead of leaving the outcome to whichever switch happens to have the lowest MAC address.
Full Explanation
Spanning tree elects the bridge with the numerically lowest bridge priority (with MAC address only as a tiebreaker) as the root, so deliberately lowering the aggregation switch's priority value below that of both access switches directly and predictably makes it the root bridge. Disabling spanning tree on the access switches removes their ability to become root, but it also removes their loop protection entirely, turning a targeted priority problem into a network-wide risk if any redundant path exists among access switches. Physically disconnecting an uplink is not a configuration solution at all — it is a workaround that breaks redundancy and does not scale or survive re-cabling, and it does not actually configure root preference anywhere. Increasing port cost on the aggregation switch's uplinks affects which path is preferred once a root is already elected; it has no bearing on which switch wins the root election itself, so it does not address the stated goal. Caveat: after changing priority, both access switches should have their own priorities left at default or set higher, and a small hierarchy of priorities across the campus is far more predictable than relying on default MAC-based tiebreaks. Operational check: verify the root bridge ID shown on all three switches now points to the aggregation switch's bridge ID.