At a voter registration office, Root Guard is enabled on a distribution port toward an access switch. The access switch suddenly advertises a superior bridge ID. What is Root Guard’s expected local reaction?
Select an answer to reveal the explanation.
Short Explanation
Root Guard hears a braggy "I should be root" BPDU and puts the port in time-out (root-inconsistent) instead of handing over the crown. Protect the planned root; do not crown the closet switch.
Full Explanation
With Root Guard enabled on a distribution port toward an access switch at a voter registration office, a superior bridge ID advertised by that access switch is rejected as a new root via that link. Root Guard places the port into a root-inconsistent state, blocking forwarding while superior BPDUs persist, so the planned distribution root remains authoritative. When the superior advertisements stop, the port can recover without having crowned the closet switch as campus root.
Immediately electing the access switch as the new campus root on all VLANs is what Root Guard prevents, not what it does. Converting the port into a routed SVI and flooding BPDUs campus-wide is not Root Guard behavior. Disabling spanning tree on the distribution switch until reboot is unrelated; Root Guard is a per-port protective state, not a global STP shutdown.
Exam caveat: root-inconsistent is different from BPDU Guard’s err-disabled. Root Guard is appropriate on designated ports facing downstream bridges; BPDU Guard belongs on edge ports that should never see BPDUs. A persistent superior BPDU leaves the port inconsistent until the offending bridge is fixed or disconnected.
Operational check: enable Root Guard on the distribution port, lower the access-switch priority in a lab window to advertise a superior BID, confirm root-inconsistent rather than a root role change, restore the access switch priority, and verify the voter-office port returns to normal designated forwarding.