Dynamic Trunking Protocol, or DTP, is a Cisco proprietary protocol. It negotiates trunking between Cisco switches automatically. Instead of manually deciding whether a link should be access or trunk, two Cisco switches can figure it out between themselves.
For CCNA and CCNP students, DTP shows up constantly. It’s part of every serious VLAN configuration discussion, and it’s also one of the more common sources of real-world misconfiguration. This article covers how DTP actually works, its five switchport modes, a corrected worked example, and how to troubleshoot it when things go wrong.
How DTP Works
DTP operates point-to-point, between two directly connected switches. It only works between Cisco devices. Non-Cisco switches don’t understand DTP frames at all, so negotiation with them will always fail.
DTP only successfully negotiates a trunk if the port on the other end is also running a DTP mode that supports trunking. If it isn’t, you end up with a mismatch, and the link either stays in access mode or behaves unpredictably.
Default DTP behavior depends on the switch model and IOS version. On modern Catalyst switches like the 2960 and 3560, the default mode is dynamic auto. Older models, like the 2950 and 3550, default to dynamic desirable instead. Don’t assume. Always check with show dtp interface if you’re not sure what a given port is actually running.
DTP Switchport Modes
Cisco switches support five relevant configurations for trunk negotiation.
Access Mode
Forces the port into access mode. No trunking, no VLAN tagging, no DTP negotiation at all.
Use case: connecting end devices, like PCs, printers, or servers.
Switch(config)#interface fa0/1
Switch(config-if)#switchport mode accessDynamic Auto
A passive mode. The port won’t initiate trunk negotiation on its own. It just listens. If it hears a DTP message from the other side asking to form a trunk, it goes along with it. If both sides of a link are set to dynamic auto, neither one ever initiates, and the link stays in access mode permanently.
Sw1(config)#interface fa0/1
Sw1(config-if)#switchport mode dynamic autoDynamic Desirable
An active mode. The port actively sends DTP messages, trying to convert the link into a trunk. If the other side is set to trunk, dynamic desirable, or dynamic auto, a trunk forms. This is the more aggressive of the two dynamic modes.
Sw1(config)#interface fa0/1
Sw1(config-if)#switchport mode dynamic desirableTrunk Mode
Forces the port into permanent trunk mode. It becomes a trunk regardless of what the other side is doing.
Here’s a detail that trips a lot of people up: trunk mode does not disable DTP by itself. The port still sends and responds to DTP frames unless you separately configure nonegotiate. This matters for security, covered below.
Sw1(config)#interface fa0/1
Sw1(config-if)#switchport mode trunkNonegotiate
Stops the port from generating DTP frames entirely. Use it alongside switchport mode trunk or switchport mode access, since the neighboring interface then has to be configured manually. No negotiation happens either way.
Sw1(config)#interface fa0/1
Sw1(config-if)#switchport mode trunk
Sw1(config-if)#switchport nonegotiateThis combination is exactly how you connect a Cisco switch to a non-Cisco device that needs a trunk link. The non-Cisco side won’t understand DTP frames anyway, so there’s no point sending them.
A Worked Example
Picture three switches: Switch0, Switch1, and Switch2.
Switch0’s Fa0/1 port connects to Switch1’s Fa0/1 port. Both ends are configured as switchport mode trunk. Since neither side has nonegotiate applied, they’re still exchanging DTP frames in the background, even though the trunk link was already going to form either way, because both sides are unconditionally in trunk mode. The link comes up as a trunk.
Switch1’s Fa0/2 port connects to Switch2’s Fa0/2 port. Both ends are set to dynamic auto. Neither side ever initiates negotiation. The link comes up in access mode instead, not trunk, even though both administrators may have expected a trunk to form automatically. This is one of the most common DTP surprises in real networks: two dynamic auto ports facing each other will never trunk on their own.
DTP Modes Comparison
| Mode | Sends DTP Frames | Responds to DTP Frames | Forms Trunk With | Default on Modern Catalyst |
|---|---|---|---|---|
| Access | No | No | None | No |
| Dynamic Auto | No (only responds) | Yes | Trunk, Dynamic Desirable | Yes (2960, 3560) |
| Dynamic Desirable | Yes | Yes | Trunk, Dynamic Desirable, Dynamic Auto | No |
| Trunk | Yes | Yes | Any mode, unless nonegotiate is set on either side | No |
| Nonegotiate | No | No | Only with a manually configured trunk on the other side | No |
A Bit of History: Encapsulation Negotiation
Older Cisco switches supported two trunking encapsulations: ISL (Cisco proprietary) and 802.1Q (open standard). Back then, DTP didn’t just negotiate access versus trunk. It also negotiated which encapsulation to use, if both were available.
Modern switches don’t support ISL anymore. Every trunk today uses 802.1Q. So this part of DTP’s original job has quietly disappeared. But you may still see show interfaces switchport output referencing “Administrative Trunking Encapsulation,” a leftover from that era. It’ll just say negotiate or dot1q, since there’s nothing else left to choose between.
Security Risk: VLAN Hopping
DTP left running on the wrong port is a real security problem, not just a theoretical one. It’s worth understanding the mechanism, not just the warning. There are two common ways VLAN hopping happens.
Switch spoofing. An attacker’s device sends DTP frames, pretending to be a switch. If the port it’s connected to is running dynamic auto or dynamic desirable, it may agree to form a trunk. Once that happens, the attacker’s device sits on a trunk link, with access to every VLAN allowed on it, not just the one VLAN a normal access port would expose.
Double tagging. This one works even without DTP involved. The attacker crafts a frame with two VLAN tags stacked on top of each other. The first switch strips off the outer tag, matching its own native VLAN, and forwards the frame. The second tag, now exposed, gets treated as if it were the original tag, letting the frame reach a VLAN the attacker shouldn’t have access to. This attack specifically depends on the native VLAN being shared between the attacker and the trunk, which is one more reason changing the default native VLAN away from VLAN 1 matters.
Disabling DTP stops switch spoofing cold. It doesn’t stop double tagging on its own, which is why native VLAN hardening matters as a separate, additional step. The fix for switch spoofing specifically is straightforward: disable DTP on every port connecting to end-user devices, servers, or anything you don’t fully control.
Switch(config)#interface range fa0/1 - 24
Switch(config-if-range)#switchport mode access
Switch(config-if-range)#switchport nonegotiateSetting a port to access mode already disables DTP frame generation on its own. Adding nonegotiate on top is a small extra layer of certainty, and it’s cheap insurance against a misconfiguration down the line.
Troubleshooting DTP Issues
Trunk won’t form. Usually a DTP mode mismatch, like both sides sitting in dynamic auto. Check both ends with show dtp interface, and confirm at least one side is actively negotiating.
Link connects to a non-Cisco device and won’t trunk. Non-Cisco devices don’t speak DTP. Configure the Cisco side with switchport mode trunk and switchport nonegotiate, and configure the far side to trunk manually.
Trunk forms, but some VLANs aren’t passing traffic. This usually isn’t a DTP problem at all. Check the allowed VLAN list on both ends with show interfaces trunk, and confirm they actually match.
Unexpected trunk appears on a port that should be access-only. This is the VLAN hopping scenario above. Check show dtp interface on the port, and lock it down with access mode plus nonegotiate.
For any of these, show interfaces trunk and show dtp interface are your two most useful commands. The first tells you the actual current state. The second tells you the negotiated mode and what’s actually being sent and received. If a trunk still isn’t behaving as expected after checking DTP, the problem may sit with trunk link configuration more broadly, not DTP negotiation specifically.
Best Practices
Disable DTP on untrusted or user-facing ports. Use switchport mode access plus switchport nonegotiate on anything connecting to end devices or unknown equipment.
Use manual trunking for critical links. Set switchport mode trunk with nonegotiate on both ends of any link where trunk behavior needs to be predictable and unambiguous, like a core-to-distribution uplink.
Verify, don’t assume. Always check show dtp interface and show interfaces trunk after any change, rather than trusting that the configuration did what you expected.
Limit VLANs on trunks. Use switchport trunk allowed vlan <list> to restrict which VLANs actually cross a trunk, reducing the blast radius if something does go wrong.
Document your DTP modes. A port sitting in dynamic desirable for no clear reason is a common source of confusion for whoever troubleshoots the network after you.
Conclusion
DTP makes trunk formation convenient, but convenience isn’t always what a production network needs. The safest, most predictable approach is usually the most manual one: set trunk mode explicitly, disable negotiation with nonegotiate, and don’t leave DTP running on ports where you don’t have a good reason to. Understanding exactly what each mode does, and what it doesn’t do (like trunk mode not disabling DTP on its own) is what separates a working trunk configuration from one that quietly leaves a security gap open.
FAQs
What is Dynamic Trunking Protocol used for?
DTP negotiates whether a link between two Cisco switches should operate as an access port or a trunk port, without requiring manual configuration on both ends. It only works between Cisco devices, since it’s a Cisco proprietary protocol. In production networks, many engineers disable it entirely and configure trunks manually instead, for predictability and security.
Does setting a port to trunk mode disable DTP?
No, and this is a common misunderstanding. A port set to switchport mode trunk still sends and responds to DTP frames by default. To actually stop DTP negotiation, you need to add switchport nonegotiate on top of the trunk configuration. Without it, the port keeps participating in DTP even though it’s already permanently in trunk mode.
What happens if both ends of a link are set to dynamic auto?
The link stays in access mode, permanently. Dynamic auto only listens for DTP messages. It never initiates. If neither side ever sends a negotiation request, no trunk ever forms, even if both administrators expected one. This is one of the most common causes of a trunk that “should” be working but isn’t.
Why is DTP considered a security risk?
If DTP is left active on a port connecting to an untrusted device, that device can potentially negotiate a trunk link with the switch. Once a trunk forms, traffic from every VLAN allowed on that trunk becomes accessible, not just a single VLAN like a normal access port would expose. This is the basis of a VLAN hopping attack, and it’s why disabling DTP on user-facing ports is a standard security best practice.
How do I verify what DTP mode a port is actually running?
Use show dtp interface <interface-id> to see the current negotiated mode and DTP status directly. show interfaces trunk is also useful, since it shows you which ports are actually operating as trunks right now, regardless of what mode they’re configured for. Checking both together gives you the full picture: what’s configured, and what’s actually happening on the wire.
