After a fire-station access switch replacement, an uplink unexpectedly becomes a trunk via DTP even though the design called for a static access handoff to a phone closet device. What is the best corrective action?
Select an answer to reveal the explanation.
Short Explanation
DTP will "helpfully" trunk if you leave it in charge. After a swap, spell out access or trunk in the config and shut DTP off—no more surprise tunnels into the phone closet.
Full Explanation
After a fire-station access switch replacement, lingering DTP can negotiate a trunk even when the design called for a static access handoff to a phone closet device. The corrective action is to hard-set the required mode—access or trunk—explicitly and disable DTP on the interface. Setting the mode explicitly restores (switchport mode access already stops DTP negotiation; on a trunk, also add switchport nonegotiate) the intended Layer-2 handoff and stops replacement gear from “helpfully” forming an unexpected trunk into the phone closet.
Enabling MST on the replacement switch and ignoring switchport mode does not stop DTP; MST is spanning-tree instance mapping, not trunk negotiation control. Lowering the STP priority on the fire-station switch so DTP stops negotiating confuses STP root elections with DTP—priority does not disable dynamic trunking. Configuring PAT on the interface to prevent dynamic trunk formation is a Layer-3 translation feature with no role in DTP.
Exam caveat: decide whether the handoff should be access or trunk from the design, then lock that mode; do not leave dynamic desirable/auto. For true phone/endpoint closets expecting access, also set the access VLAN and typically PortFast/BPDU Guard. For trunks, still align native VLAN and allowed lists after disabling DTP.
Operational check: on the replaced fire-station uplink/handoff, configure the designed switchport mode, disable DTP, verify operational mode matches admin mode after reload, and confirm the phone closet device no longer sees an unexpected trunk.