Disable DTP on a switch

[WhiteHat]

Hello My Friends, 

      I hope you are okay and in a good health, I have a friend who attended CCNA exam yesterday, She got a question about which can disable DTP on a switch or something similar, the two options confused her is configure port as trunk or configure port as static access, 

She chose configure port as trunk referring to this statement. 

The DTP packets are not sent in these three circumstances:

1.) Either the port is a static access port configured by the command switchport mode access

2.) Or the port is a static trunk port configured with the command switchport mode trunk and at the same time, the DTP negotiation is deactivated using the command switchport nonegotiate

3.) The port is a routed port configured with the command no switchport

In my opinion her answer is wrong and the correct is configure port as static access . 

I believe that Trunk port doesn't initiate a DTP packet but doesn't disable it, But the static access disables both the negotiation and the DTP mode. and referring to the following output as well it confirms my point of view 

Switch1(config)#int fa0/1
Switch1(config-if)#sw mod trun
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
Switch1(config-if)#do sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
1 interfaces using DTP

Switch1(config-if)#do sh int sw
Name: Fa0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On

Result after switching the port to access on switch2
Switch2(config-if)#do sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
0 interfaces using DTP

Switch2(config-if)#do sh int sw
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off

Your opinions are highly apreciated 

I wish you all a very lovely day 

[willwetherman]

Hi,

I agree that the answer should be to configure the port as static access. Also note that when configuring the interface as a trunk with DTP enabled, the interface always trunks and sends DTP messages to attempt to negotiate a trunk on the other end of the link as well.

I always refer to the following which clearly explains the behaviour

switchport mode trunk says: “Always trunk on this end, and I will send DTP to attempt to negotiate a trunk on the other end.”

switchport nonegotiate says: “Do not send or respond to DTP from this end. Disable all DTP on this port.”

switchport mode dynamic desirable says: “Ask the other end to trunk using DTP and trunk if the negotiation succeeds. If DTP negotiation fails then become an access port.”

switchport mode dynamic auto says: “If the other end asks me to be a trunk with DTP, then become a trunk, but I wont initiate any negotitation from this end. If no one asks me to become a trunk then I will become an access port.”

switchport mode access says: “Never trunk on this end and never send out DTP messages"

switchport trunk encapsulation says: “Do not negotiate the trunk protocol with DTP. Only use the trunk protocol specified in this command (isl or dot1q).

I hope that this helps

[willwetherman]

Hi,

I agree that the answer should be to configure the port as static access. Also note that when configuring the interface as a trunk with DTP enabled, the interface always trunks and sends DTP messages to attempt to negotiate a trunk on the other end of the link as well.

I always refer to the following which clearly explains the behaviour

switchport mode trunk says: “Always trunk on this end, and I will send DTP to attempt to negotiate a trunk on the other end.”

switchport nonegotiate says: “Do not send or respond to DTP from this end. Disable all DTP on this port.”

switchport mode dynamic desirable says: “Ask the other end to trunk using DTP and trunk if the negotiation succeeds. If DTP negotiation fails then become an access port.”

switchport mode dynamic auto says: “If the other end asks me to be a trunk with DTP, then become a trunk, but I wont initiate any negotitation from this end. If no one asks me to become a trunk then I will become an access port.”

switchport mode access says: “Never trunk on this end and never send DTP messages"

switchport trunk encapsulation says: “Do not negotiate the trunk protocol with DTP. Only use the trunk protocol specified in this command (isl or dot1q).

I hope that this helps

edit: You may see a variation of the above that states that 'switchport mode access' says "Never trunk on this end, and I will send out DTP messages to help my link partner reach the same conclusion", however, after configuring a port as mode access and enabling 'debug dtp packets' I didn't observe any DTP packets sent out of the interface so it appears to disable DTP on the interface completely.

[willwetherman · Accepted solution]

Sorry I'm not sure why my posts have been duplicated.

Just to add - if you configure a port as mode access and issue 'show dtp interface' you will see the following which also indicates that DTP messages are not being sent out of the interface

vIOS-L2-01#show dtp interface gigabitEthernet 0/0
DTP information for GigabitEthernet0/0:
TOS/TAS/TNS: ACCESS/OFF/ACCESS
TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q
Neighbor address 1: 000000000000
Neighbor address 2: 000000000000
Hello timer expiration (sec/state): never/STOPPED
Access timer expiration (sec/state): never/STOPPED
Negotiation timer expiration (sec/state): never/STOPPED
Multidrop timer expiration (sec/state): never/STOPPED
FSM state: S1:OFF
# times multi & trunk 0
Enabled: no
In STP: no

Statistics
----------
0 packets received (0 good)
0 packets dropped
0 nonegotiate, 0 bad version, 0 domain mismatches,
0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other
0 packets output (0 good)
0 native, 0 software encap isl, 0 isl hardware native

[WhiteHat]

Thank willwetherman ..Much appreciated

[weylin.piegorsch]

Previous answers are incomplete.

See here: http://packetlife.net/blog/2008/sep/30/disabling-dynamic-trunking-protocol-dtp/

Or for the TL;DR version: to disable DTP on a specific switchport, you need to do any one of these three things (note, these are mutually exclusive so you can only pick one of these) from INTERFACE CONFIG mode:

1. issue the single command "switchport mode access"
2. issue the command "no switchport"
3. issue the two commands "switchport mode trunk" and "switchport nonegotiate"

Issuing the command switchport mode trunk -by itself- does not actually disable DTP on the port.  So your friend was, in fact, in error, but not for any of the reasons stated above.  Of the two choices presented to her, the only fully-correct option was "configure as static access".

weylin

[CERKYR]

Hello,

My configurationS : 

All interfaces between switchs are mode Trunk.

All iinterfaces for computers on mode Access

All other port disabled.

Vlan 1 is disabled.

Switchs are not physically available.

Passwords are very strong.

Why use nonegociate in these configurations ?

Regards,

[weylin.piegorsch]

Assume all interfaces are "switchport" interfaces.  In this case:

- for host ports, "switchport mode access" serves to disable DTP, and "switchport nonegotiate" is immaterial.

- for inter-switch interfaces configured statically as "switchport mode trunk", DTO is still operating (passing and processing DTP frames).  Since it's statically trunk, then it has no effect other than existing, so you could theoretically do away with the nonegotiate command here too.

What to answer on the test?  See above.

What to do in practice?

1. if you prefer a simpler "show run" output so as to focus on the things that make a meaningful difference, don't worry about this.  It won't have any effect.  It takes precious little CPU cycles and negligible link usage.

2. if you prefer a cleaner link utilization, I recommend nonegotiate on all ports.  You might prefer this if any of: you don't want to have to deal with DTP bugs; you want to use a set-and-forget parameter to reduce even a little CPU usage; you don't want DTP to take up *any* link utilization or wireshark data; or, if you don't want to deal with the effects of "switchport mode auto" (or whatever is the command) on any adjacent switchport if it accidently happens to appear.  In this case you *need* nonegotiate on the trunk ports.

On the access port it's not strictly needed, but I've found it useful in order to have a consistent compliance policy, and so that the operations team doesn't get confused about the parameter one way sometimes and another way other times.  Firstly, you might come across a computer that requires access to multiple VLANs (examples: happens a lot in datacenters, and also APs require this), and configuring a counter port (that is normally access) to a trunk port then requires nonegotiate.  It's easy to forget to add that parameter, especially if you don't actually understand the whole of your enterprise architecure and mistake interswich vs computer ports, and instead mistakenly see it as ports 1-10 always have it and 11-48 never do.  Additionally, I've gotten tired of dealing with my operations team getting complacent about the inconsistency, and not properly resetting things especially after a "default interface <xyz>" command when something is decommissioned or something new is setup.