Disabling Dynamic Trunking Protocol (DTP)
By stretch | Tuesday, September 30, 2008 at 1:22 a.m. UTC
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.
Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 10 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.
September 30, 2008 at 6:19 a.m. UTC
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.
September 30, 2008 at 3:55 p.m. UTC
Spot on. What about the Native Vlan, should it be dedicated exclusively for trunk links?
September 30, 2008 at 6:48 p.m. UTC
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.
September 30, 2008 at 9:21 p.m. UTC
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.
October 1, 2008 at 12:13 a.m. UTC
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.
October 1, 2008 at 5:35 p.m. UTC
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.
October 2, 2008 at 4:37 p.m. UTC
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?
October 17, 2008 at 9:43 p.m. UTC
DasSG, you are absolutely right. Killing the DTP process on trunk or access ports doesn't affect the working of VTP.
October 21, 2008 at 10:42 p.m. UTC
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.
November 21, 2008 at 12:26 a.m. UTC
Very cool post! Helped resolve a trunking issue between a 3750 a 4948.
I kept getting that error...
But not anymore! ;) Thanks Stretch!
February 11, 2009 at 11:18 a.m. UTC
Good post !!
April 2, 2009 at 8:42 p.m. UTC
There is an article here, showing why you should disable DTP: http://www.think-security.com/
January 26, 2010 at 4:30 p.m. UTC
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?
February 13, 2011 at 4:48 a.m. UTC
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.
June 20, 2011 at 2:48 p.m. UTC
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 220.127.116.11 at 3-1-93 00:17:08 Local updater ID is 18.104.22.168 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
June 15, 2012 at 1:03 p.m. UTC
On a struggle to identify whitch interfaces were running DTP, I found a very useful command that shows all protocols running on Catalyst switches.
SW-01#show interfaces counters protocol status Protocols allocated: Vlan1: Other, IP Vlan50: Other, IP, ARP FastEthernet0/1: Other, IP FastEthernet0/2: Other, IP, Spanning Tree, CDP "
July 20, 2012 at 10:55 a.m. UTC
What software you used to capture DTP in 'dtp_capture.png'??
September 6, 2012 at 7:20 a.m. UTC
I configured on trunk ports the "switchport nonegotiate" command to disable DTP. Now I've found in my logs spanningtree changes, which are caused by DTP changes (port becomes non-trunk, port becomes trunk again). Where can I find information about this strange behaviour - it must be a bug.
Config of ports as example:
interface TenGigabitEthernet1/29 description to xxxxx, TE 1/30 switchport trunk encapsulation dot1q switchport trunk native vlan 56 switchport mode trunk switchport nonegotiate .... interface TenGigabitEthernet1/30 description to yyyyy, TE 1/29 switchport trunk encapsulation dot1q switchport trunk native vlan 56 switchport mode trunk switchport nonegotiate ....
Log message as it appears in the switch log file and on the NMS:
%DTP-5-TRUNKPORTON: Te1/29 has become dot1q trunk.
October 15, 2012 at 6:55 p.m. UTC
@JoeAstorino From http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml#using_vtp_net Trunk will form if both side don't use DTP (via "switchport nonegotiate") or setting the trunk mode as "on" (via "switchport mode trunk")
February 15, 2013 at 12:44 p.m. UTC
March 19, 2013 at 12:39 p.m. UTC
Very informative post as usual, however I have a correction for the DTP packets interval.
DTP is sent every 30 seconds not 60. So please correct it or correct me if I'm wrong :)
keep up the good work
October 10, 2013 at 9:14 a.m. UTC
Great Post! Easy to follow and to the point.
February 25, 2015 at 11:04 a.m. UTC
thanks for this one. I'm a Layer 2 guy myself and I have a friend who did mostly BGP throughout his career. He will start a new job soon where he also has to do L2 and I help him out with getting to know this better. it was great just sending him this post and now he knows a lot more about switchport security. still have a lot to do with port security, private VLANs and so on but from now on this is a reference (not only)for future trainees
June 20, 2016 at 3:12 p.m. UTC
HI, i know this is an older post, but would really appreciate some information, im running a port-channel in a lab enviroment, i have the created the port-channel using mode "on/PAGP/LACP" now on the PortChannel i set the switchport mode and encapsulation to trunk/dot1q on both sides, however as soon as i configure "switchport nonegotiate", the portchannel goes down, is this normal behaviour? i can only assume because DTP is disabled,this causes the logical port-channel to not bind the physical interfaces?