A city clerk must decide which switch should be the primary root for the civic-core Rapid PVST+ instance. What concept guides that choice?
Select an answer to reveal the explanation.
Short Explanation
STP root isn’t a popularity contest—it’s a priority contest. Dial the civic core’s bridge priority to win, park a secondary nearby, and stop letting some closet switch accidentally run the tree.
Full Explanation
Civic-core Rapid PVST+ root placement is guided by bridge priority (with MAC address as the tie-breaker in the bridge ID). Operators lower priority on the intended city-core switch so it wins root election for the relevant VLAN instances, and typically set a secondary with a priority better than closets but worse than primary. That deterministic election keeps spanning-tree topology predictable for municipal Layer 2 domains instead of leaving root to chance.
Highest MAC address always winning ignores priority: lower priority values are preferred, and MAC breaks ties only when priorities are equal. Root election is not determined only by enabling PortFast globally—PortFast is an edge feature for host ports, not a root-election control. The first switch to boot remaining root until a manual reload elsewhere is not how STP works; superior BPDUs cause reconvergence when a better bridge ID appears, independent of boot order mythology.
Exam caveat: Rapid PVST+ elects a root per VLAN instance. Tuning one VLAN’s priority does not automatically place root for every VLAN; verify each instance that matters to the civic design.
Operational check: set primary and secondary bridge priorities on core switches per VLAN plan, clear or wait for reconvergence as needed, verify root identity with spanning-tree status commands, and document priorities so closet switches cannot accidentally outrank the core.