Disabling Dynamic Trunking Protocol (DTP)
Cisco's Dynamic Trunking Protocol can facilitate the automatic creation of trunks between two switches. When two connected ports are configured in dynamic mode, and at least one of the ports is configured as desirable, the two switches will negotiate the formation of a trunk across the link. DTP isn't to be confused with VLAN Trunking Protocol (VTP), although the VTP domain does come into play.

DTP on the wire is pretty simple, essentially only advertising the VTP domain, the status of the interface, and it's DTP type. These packets are transmitted in the native (or access) VLAN every 60 seconds both natively and with ISL encapsulation (tagged as VLAN 1) when DTP is enabled.

DTP is enabled by default on all modern Cisco switches. But a responsible network engineer has to ask himself, "why?" Do you really want switches to form trunks on their own? I certainly don't, for several reasons.
First, it's simply bad design; trunks should be present where they were intended, and only where they were intended. Second, leaving switch ports set to dynamic mode is a gaping security hole. If all it takes is the right DTP packet to form a trunk from an access port, an intruder can easily inject traffic into whatever VLANs are allowed on the port (by default, all of them). Fortunately, these two issues can be resolved by configuring a static switchport mode, either "access" or "trunk", as best practice dictates.
! Access port Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 10 ! Trunk port Switch(config-if)# switchport mode trunk Switch(config-if)# switchport trunk encapsulation dot1q
However, even when a port is statically configured in such a manner, DTP is still active on the port. If you've ever attempted to setup a trunk between two switches in different VTP domains and received the following error, you can thank DTP:
%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/1 because of VTP domain mismatch.
Recall that DTP advertisements include the VTP domain name. A switch won't form a trunk on a DTP-enabled port to a switch advertising a different VTP domain, even if the ports are manually configured in trunking mode. Nice, eh? Fortunately we can kill DTP once and for all with the switchport nonegotiate command on the interface.
Switch(config-if)# switchport nonegotiate
This configuration prevents DTP packets from being sent, effectively disabling trunk negotiation and evaluation of the VTP domain.
Comments
Spot on. What about the Native Vlan, should it be dedicated exclusively for trunk links?
Just a quick correction.. You need to set the encapsulation before configuring the port as Trunk port. This is somehow strange but that is how CISCO implemented it.
I would suggest against disabling the CDP on access ports (or at least directly on the physical port) but it would be wiser to do it on data vlans. That is because Cisco IP phones use cdp (for whatever reason) so it might be handy to run it on the voice wlan and configure ports to support phones with "switchport voice vlan xx" command.
At least, that's what I do.
CDP is used by the switches and routers to identify if a Cisco IP Phone is attached. It's necessary if your going to use auto QOS to configure your switches and routers and establish the trust boundary.
Like I said: "If POSSIBLE I also disable the CDP protocol on access ports." If you are using IP Phones you shouldn't disable CDP. In VoIP environments, CDP is a protocol used for communicating to the IP Phones what VLAN ID they need to use in the 802.1q Ethernet header. After the phones have set their Ethernet frames to have the Voice VLAN ID, the Ethernet switch permits and switches the traffic correctly.
But if you aren't using IP Phones you can disable CDP, because vulnerabilities in the CDP protocol could be used to potentially harm your components. Tools, like Yersinia, could be used by hackers to exploit vulnerabilities in the CDP or other protocols.
Just to verify, if I am manually establishing access & trunk ports on switches and routers using either switchport mode access or switchport mode trunk, I can kill DTP using the switchport nonnegotiate command and not affect current or future VTP operation?
DasSG, you are absolutely right. Killing the DTP process on trunk or access ports doesn't affect the working of VTP.
Great post! It might be worth mentioning that in addition to the potential security and stability benefits of disabling DTP, disabling DTP on your trunk ports can potentially reduce your recovery time in the event of a trunk failure by up to 2 seconds.
Very cool post! Helped resolve a trunking issue between a 3750 a 4948.
I kept getting that error...
But not anymore! ;) Thanks Stretch!
Good post !!
There is an article here, showing why you should disable DTP: http://www.think-security.com/
I'm trying to figure out why this protocol was ever created! I mean, you either know if a line is a trunk or not. The idea of asking the switches to decide is ludicrous. But at some point SOMEBODY sat down and invested time and energy into this protocol...but why?
MB, I can tell you that we use it in certain circumstances. We have some remote switches, and everyone once in while the remote personnel disconnect a cable, then reconnect it. If this is an interswitch trunk cable, and they put the cable into the wrong port, disabling DTP means total loss of connectivity (because one side is trunked, the other is access). By using DTP, we can recover connectivity without sending a tech into the field.
Hi Jeremy,
I have been doing some testing on DTP and am not seeing these results. Specifically, if I have both sides of the trunk configured static with "switchport trunk encap dot1q" and "switchport mode trunk" without disabling DTP via "switchport nonegotiate" and I have the switches in different VTP domains, the trunk still comes up fine. This is between a 3550 and a 3560. Below, Cat1 is a 3560 and Cat2 is a 3550
Cat1#sh run int fa0/24 Building configuration... Current configuration : 95 bytes ! interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk end Cat1#show vtp status VTP Version : running VTP2 Configuration Revision : 1 Maximum VLANs supported locally : 1005 Number of existing VLANs : 8 VTP Operating Mode : Server VTP Domain Name : test VTP Pruning Mode : Disabled VTP V2 Mode : Enabled VTP Traps Generation : Disabled MD5 digest : 0x5B 0xED 0x49 0x98 0x53 0x43 0x6C 0xD1 Configuration last modified by 0.0.0.0 at 3-1-93 00:17:35 Local updater ID is 0.0.0.0 (no valid interface found) Cat1#show interface trunk Port Mode Encapsulation Status Native vlan Fa0/24 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/24 1-4094 Port Vlans allowed and active in management domain Fa0/24 1,10,20,30 Port Vlans in spanning tree forwarding state and not pruned Fa0/24 1,10,20,30 Cat2#show run int fa0/24 Building configuration... Current configuration : 95 bytes ! interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk end Cat2#show vtp status VTP Version : running VTP2 Configuration Revision : 1 Maximum VLANs supported locally : 1005 Number of existing VLANs : 6 VTP Operating Mode : Server VTP Domain Name : ccna VTP Pruning Mode : Disabled VTP V2 Mode : Enabled VTP Traps Generation : Disabled MD5 digest : 0xB6 0x17 0x3E 0xF2 0x13 0xBD 0x40 0xE1 Configuration last modified by 22.22.22.22 at 3-1-93 00:17:08 Local updater ID is 22.22.22.22 on interface Lo0 (first layer3 interface found) Cat2#show interface trunk Port Mode Encapsulation Status Native vlan Fa0/24 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/24 1-4094 Port Vlans allowed and active in management domain Fa0/24 1,40 Port Vlans in spanning tree forwarding state and not pruned Fa0/24 1,40


Very good post, I always use the switchport nonegotiate command to disable the DTP protocol. If possible I also disable the CDP protocol on access ports, because it could also be a possible security hole.