County clerk switches are intended to share one MST region, but VLAN-to-instance mapping looks inconsistent after a partial config push. Which requirement is essential for switches to remain in the same MST region?
Select an answer to reveal the explanation.
Short Explanation
MST regions are picky clubs: same name tag, same revision, same VLAN-to-instance seating chart. Miss one and switches stop acting like they share the region.
Full Explanation
Switches remain in the same MST region only when three parameters match: region name, revision number, and the VLAN-to-instance mapping. After a partial config push at the county clerk offices, any drift in those values can place switches outside the intended region even if trunks still come up. Consistent region membership is essential so VLAN groups share the designed MST instances rather than interacting via the Common and Internal Spanning Tree in unexpected ways.
Identical OSPF process IDs on every access VLAN SVI are a Layer-3 concern and do not define MST region membership. The same native VLAN alone, with no need to match instance maps, is insufficient—native VLAN equality does not replace the MST configuration digest. Enabling BPDU Guard globally as a substitute for region parameters confuses edge protection with region formation; BPDU Guard does not make mismatched MST maps belong to one region.
Exam caveat: the MST configuration digest incorporates the map; matching name and revision while drifting VLAN-to-instance assignments still breaks region consistency. Inter-region boundaries behave differently than intra-region instance topologies—partial clerk-office cutovers are a common source of production MST surprises.
Operational check: export spanning-tree mst configuration from a known-good clerk switch, compare name/revision/map on every peer, remediate drift from the partial push, and confirm all intended switches show the same region before validating VLAN forwarding.