A city IT team wants the access-to-distribution link to carry multiple civic VLANs as an 802.1Q trunk, but staff keep seeing unexpected dynamic trunk negotiation after switch replacements. Which approach best removes that surprise while keeping a stable trunk?
Select an answer to reveal the explanation.
Short Explanation
Think of DTP like an auto-handshake that can flip a port into a trunk when you did not mean it to. For civic uplinks you want a hard-set trunk—static 802.1Q—and DTP turned off so a replacement switch cannot renegotiate into something weird.
Full Explanation
On civic access-to-distribution uplinks that must carry multiple municipal VLANs, the durable design is an explicitly configured 802.1Q trunk with Dynamic Trunking Protocol disabled. Static trunk mode on both ends removes dependency on DTP desirable/auto negotiation, so a switch replacement cannot silently re-negotiate a different operational mode. Disabling DTP (for example with switchport nonegotiate after setting trunk encapsulation and mode) further ensures the link will not answer or initiate trunk formation advertisements. That combination keeps the Layer-2 uplink predictable for city services that rely on a stable allowed-VLAN set across the trunk.
Leaving DTP enabled and trusting desirable mode fails the requirement because automatic negotiation is exactly what produced surprise trunks after hardware swaps; it optimizes convenience, not deterministic behavior. Forcing both interfaces into access mode and pushing every civic VLAN through router-on-a-stick abandons the trunk design the city asked to keep and needlessly concentrates inter-VLAN routing on a single stick interface. Enabling MST only on access ports while ignoring trunk encapsulation does not address DTP or trunk stability; MST governs spanning-tree instance mapping, not whether an uplink is a negotiated or static trunk.
Exam caveat: static trunk plus nonegotiate still requires matching native VLAN, consistent allowed lists, and compatible encapsulation (dot1q). Hard-setting trunk mode without aligning those parameters can leave a “stable” trunk that drops or mis-maps traffic. Also remember nonegotiate is meaningful on trunks; simply setting access mode is the hardening pattern for host ports, not for this multi-VLAN uplink.
Operational check: on both ends verify switchport mode trunk, switchport nonegotiate, matching native VLAN, and the intended allowed VLAN list; then bounce or reseat one side after a lab “replacement” and confirm the link returns as trunk without DTP OPERATIONAL state changes or unexpected access-mode fallback.