DTP (Dynamic Trunking Protocol) fundamentals, labbing / explanation of verification commands, some oddities, and some debugging!

The above Trunk modes in the Topology will be representative of SW1 only, as SW2 will remain with Trunk ports in their default mode of Dynamic Auto, to see the difference in debugs and verification output.

 

Fundamental information for Exam day!

 

DTP is what makes negotiation possible, handling the negotiation between the Trunk ports, and is a Cisco proprietary point-to-point protocol.

DTP has two default timers that cannot be changed, DTP Hello frames being sent every 30 seconds to the remote peer, and dynamically formed Trunks via DTP will timeout after 300 seconds of inactivity.

Again DTP timers CANNOT be changed, so if you see anything other than the default times of 30 / 300, or are asked for the command to change them it does not exist!

There are also 5 DTP modes that will be discussed exhaustively down the post, they are:

• Auto – Default mode, “switchport mode dynamic auto”
• On – “switchport mode trunk”
• Off – “switchport mode access”
• Desirable – “switchport mode dynamic desirable”
• Nonegotiate – “switchport nonegotiate” on “trunk” mode interaces

These will be discussed in the acronym section of verification output in depth while labbing, however these are the “DTP modes” that correspond with the “Trunk modes” that were previously discussed, which is explained exhaustively below.

 

When is a good time to turn DTP off on a switchport? Probably right now!

 

Both in the real world and I would hope on the exam, outside of testing your knowledge on dynamic port behaviors, DTP and Dynamically forming Trunks in general should not be used as it can introduce the problem of a rogue switch Trunking its way into your networks data.

I do not think I have ever seen a dynamically formed trunk in the real world on the job, each side has been (and should be) in “Trunk” mode with “switchport nonegotiate” enabled on both sides – This will still allow a Trunk to form with the switchport in “Trunk” mode without the help of DTP (as long as it has matching encapsulation types).

 

First to review the verification commands, and get familiar with the output

 

I’ll demonstrate from the CLI a couple of different quirks in the verification commands, that I have dug through training materials / Cisco support forums / other IT Forums, and when these questions about DTP verification commands comes up the conversation stops immediately and I have no idea why these oddities have never been addressed that I and others have observed.

Here is an explanation of the output of the verification commands to start with:

“show dtp”

SW1#sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds

Dynamic Trunk timeout is 300 seconds

4 interfaces using DTP

The blue information is our default timers that cannot be changed so that information is not really relevant unless you are asked on an exam what command shows you timer information, and it also shows the number of interfaces containing DTP information.

** Note the # of interfaces using “sh dtp” can be misleading, as can the interfaces using “sh dtp interface” as demonstrated in the quirks segment near the bottom! **

The next DTP verification command is demonstrated with some output here:

“show dtp interface”

SW1#sh dtp int
DTP information for FastEthernet1/0/1:
TOS/TAS/TNS: TRUNK/NONEGOTIATE/TRUNK

TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q

Neighbor address 1: 58971EABC803
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: S6:TRUNK
# times multi & trunk 0
Enabled: yes    <— What happened to NONEGOTIATE? (more on this below)

In STP: no

Statistics

———-

24 packets received (10 good)

14 packets dropped

14 nonegotiate, 0 bad version, 0 domain mismatches,

0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other

14 packets output (14 good)

11 native, 3 software encap isl, 0 isl hardware native

0 output errors

0 trunk timeouts

2 link ups, last link up on Mon Mar 01 1993, 00:32:21

2 link downs, last link down on Mon Mar 01 1993, 00:32:18

I’ve highlighted in blue the “statistics” section just to see the type of output it contains, but its contents is beyond the SWITCH exam scope so I won’t drill into it, and will actually remove it from any “sh dtp int” examples going forward to keep it concise.

More importantly I highlighted in red at the top the information we are looking for at the CCNP level, the TOS / TAS / TNS portion of the output with very similar output to the command “show interface switchport” as discussed here at the bottom of the post.

I’ve also highlighted in green one quirk I cannot find any explanation on, which I will discuss more below in the debug segment.

A quick breakdown of what on Earth all those acronyms are:

• TOS = Trunk Operational Status
• TAS = Trunk Administrative Status
• TNS = Trunk Negotiation Status
• TOT = Trunk Operational Type
• TAT = Trunk Administrative Type
• TNT = Trunk Negotiation Type

See a trend there?

The top three “Status” outputs refer to the Trunks current mode, its configured (or default) mode, and its current negotiation status which is either Trunk or Access as demonstrated below shortly.

The bottom three “Type” refers to the encapsulation in the same 3 manners, however as seen on the output above, when a side is hard coded with an encapsulation type it will populate that across all three TOT/TAT/TNT fields whereas dynamic interfaces will not.

To review from Fa1/0/1:

SW1#sh dtp int
DTP information for FastEthernet1/0/1:
TOS/TAS/TNS: TRUNK/NONEGOTIATE/TRUNK
TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q

This is a hard coded Trunk port, which requires the encapsulation set first (dot1q in this case), also configured for nonegotiate which is what it shows for its Admin Status.

If I remove the nonegotiate configuration let us a have a look:

SW1(config)#int fa1/0/1
SW1(config-if)#no switchport nonegotiate
SW1(config-if)#
*Mar 1 01:13:05.765: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
*Mar 1 01:13:08.793: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
SW1(config-if)#
SW1(config-if)#do sh dtp int
DTP information for FastEthernet1/0/1:
TOS/TAS/TNS: TRUNK/ON/TRUNK
TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q

As can be seen it did bounce the interface, but then allowed it to negotiate with SW2, and now the Admin Status field has changed from NONEGOTIATE to ON.

The next field down for the 3 encapsulation types is straight forward on a “switchport mode trunk” interface, as you must choose a hard coded encapsulation before you can hard code a trunk on an interface, so the output will be either 802.1Q/802.1Q/802.1Q or ISL/ISL/ISL.

To look at the dynamic side of things we look to SW2’s interface Fa1/0/1 output:

SW2#sh dtp int
DTP information for FastEthernet1/0/1:
TOS/TAS/TNS: ACCESS/AUTO/ACCESS
TOT/TAT/TNT: NATIVE/ISL/NATIVE

So we have a much different output here.

The TOS/TAS/TNS going across shows it is currently operating as an Access Port, in Dynamic Auto mode, and its negotiated to be an Access Port.

So even with nonegotiate turned off, this is not forming or negotiating a Trunk with SW1, and it can be seen why in the second line of NATIVE/ISL/NATIVE.

It shows “Native” because that interface has not negotiated to use otherwise to form a Trunk, it shows the hard coded type is ISL which does not match SW1’s connected interface (causing the Trunk not to form), and shows Native again because so far that is what has been negotiated!

So to make it truly dynamic, in the spirit of the holidays, I put Fa1/0/1 on SW2 encapsulation type back into negotiate and all should be well:

SW2(config-if)#int fa1/0/1
SW2(config-if)#switchport trunk encap neg
SW2(config-if)#
*Mar 1 01:28:31.188: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
*Mar 1 01:28:34.023: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 1 01:28:34.199: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
*Mar 1 01:29:03.224: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
SW2(config-if)#
SW2(config-if)#do sh dtp int
DTP information for FastEthernet1/0/1:
TOS/TAS/TNS: TRUNK/AUTO/TRUNK

TOT/TAT/TNT: 802.1Q/NEGOTIATE/802.1Q

It can take 10 or 15 seconds for DTP to bring interfaces back up due to that 30 second time, but the interface did eventually bounce, and when it came back it is now showing TRUNK and 802.1Q/NEGOTIATE/802.1Q meaning it is Operating and Negotiated 802.1Q because the Administrative Type is set to Negotiate!

A side note, issuing “switchport trunk encap negotiate” on an interface will not show up in show run, just like “switchport mode dynamic auto” will not either, I issued both on Fa1/0/1 on SW2 and this is the interfaces running config:

SW2(config-if)#do sh run
Building configuration…

!
interface FastEthernet1/0/1
!
interface FastEthernet1/0/2
switchport mode dynamic desirable
switchport trunk encapsulation isl
!

As can be seen, Fa1/0/1 shows as a completely default / unconfigured port, and I included a preview into what I have cooking between the Trunk of SW1 and SW2’s Fa1/0/2 interface 🙂

What happens when two Dynamic Desirable Trunks have different encap types!

First to quickly show the SW1 and SW2 configuration for interface Fa1/0/2 on each:

SW1

!
interface FastEthernet1/0/2
switchport trunk encapsulation isl
switchport mode dynamic desirable
!

SW2

!
interface FastEthernet1/0/2
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
!

Now for the output they show on each side for “sh dtp int”:

SW1

DTP information for FastEthernet1/0/2:
TOS/TAS/TNS: ACCESS/DESIRABLE/ACCESS
TOT/TAT/TNT: NATIVE/ISL/ISL

SW2

DTP information for FastEthernet1/0/2:
TOS/TAS/TNS: ACCESS/DESIRABLE/ACCESS
TOT/TAT/TNT: NATIVE/802.1Q/802.1Q

This one again demonstrates, two sides of a Trunk with different hard coded Encapsulation Types will not form a Trunk, as can be seen that this is showing as an Access port in the top “Mode” output for this Trunk interface.

The “Type” fields shows it is currently running its Native VLAN (as it has not negotiated one), that the Administrative (hard coded) 802.1Q, so its Trunk Negotiation Type will also be 802.1Q by reading the output per field from left to right.

I’ll spare the output, but to remedy this you can either hard code the remote sides encap type, but given you may not have that on exam day “switchport trunk encap negotiate” will work as well to allow the Trunk to form!

One last thing on the topic of “show dtp interfaces” – Access port output:

DTP information for FastEthernet1/0/11:
TOS/TAS/TNS: ACCESS/NONEGOTIATE/ACCESS
TOT/TAT/TNT: UNKNOWN/NEGOTIATE/UNKNOWN

^This is with “switchport mode access” and “switchport nonegotiate” configured

DTP information for FastEthernet1/0/12:
TOS/TAS/TNS: ACCESS/OFF/ACCESS
TOT/TAT/TNT: NATIVE/NEGOTIATE/NATIVE

^This is with only “switchport mode access” configured

DTP information for FastEthernet1/0/12:
TOS/TAS/TNS: ACCESS/AUTO/ACCESS
TOT/TAT/TNT: NATIVE/NEGOTIATE/NATIVE

^This is the same port set to default settings / unconfigured

So I cover all the bases of the output, these are your access ports, with their different configuration types and the output that is seen.

I think that is quite enough of that, onto some of the quirks I’ve found with verification output that I haven’t been able to find an answer for!

 

The quirks with the DTP verification commands

 

To introduce my first WTF moment, I will post the output from SW1’s Fa1/0/1 output from “sh dtp interface” again to demonstrate an oddity:

SW1#sh dtp int
DTP information for FastEthernet1/0/1:
TOS/TAS/TNS: TRUNK/NONEGOTIATE/TRUNK
TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q
Neighbor address 1: 58971EABC803
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: S6:TRUNK
# times multi & trunk 0
Enabled: yes    <—–WHAT??!?
In STP: no

Even though its Administrative Config is “nonegotiate” this interface shows it is still DTP enabled, and if that was not odd enough, here is a switchport that is a hard coded Access Port also with “nonegotiate” configured:

DTP information for FastEthernet1/0/11:
TOS/TAS/TNS: ACCESS/NONEGOTIATE/ACCESS
TOT/TAT/TNT: UNKNOWN/NEGOTIATE/UNKNOWN
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    <—– CORRECT!

In STP: no

The trunk port at the top shows NONEGOTIATE in its TAS, then lower in the output shows as “Enabled: yes” for DTP, and I cannot find an answer as to why that is.

The only way I could confirm it was not sending DTP messages was to run a debug on SW2 which I will demonstrate right at the end.

** An important side note, a hard coded switchport will show as “Enabled: no” with or without “nonegotiate”, but if a non-switch device plugs into an unconfigured port it will show “Enabled: yes” in the “sh dtp interface” output for the Access interface – So hard coded Access Ports are not DTP enabled but unconfigured Access Ports are! **

Another very important behavior I have found with “sh dtp” is that once the # of interfaces using DTP field is increased, it does not go back down when unused as I will demonstrate here by plugging / unplugging R1 into unconfigured ports:

SW1#sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
5 interfaces using DTP

SW1#
*Mar 1 02:31:23.335: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to down
*Mar 1 02:31:24.342: %LINK-3-UPDOWN: Interface FastEthernet1/0/11, changed state to down
*Mar 1 02:31:26.011: %LINK-3-UPDOWN: Interface FastEthernet1/0/15, changed state to up
*Mar 1 02:31:27.018: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/15, changed state to up
*Mar 1 02:31:31.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/15, changed state to down
*Mar 1 02:31:32.294: %LINK-3-UPDOWN: Interface FastEthernet1/0/15, changed state to down
*Mar 1 02:31:35.213: %LINK-3-UPDOWN: Interface FastEthernet1/0/18, changed state to up
*Mar 1 02:31:36.220: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/18, changed state to up
*Mar 1 02:31:40.607: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/18, changed state to down
*Mar 1 02:31:41.614: %LINK-3-UPDOWN: Interface FastEthernet1/0/18, changed state to down
*Mar 1 02:31:46.890: %LINK-3-UPDOWN: Interface FastEthernet1/0/21, changed state to up
*Mar 1 02:31:47.897: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/21, changed state to up
SW1#sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
8 interfaces using DTP

SW1#

As can be seen the interfaces go up/down almost immediately each time from me unplugging and replugging the cable, and all this information is reflected in the # of interfaces using DTP as highlighted at the bottom.

This also keeps the port in its “sh dtp interface” output as well as demonstrated here:

DTP information for FastEthernet1/0/15:
TOS/TAS/TNS: ACCESS/AUTO/ACCESS
TOT/TAT/TNT: UNKNOWN/NEGOTIATE/UNKNOWN

DTP information for FastEthernet1/0/18:
TOS/TAS/TNS: ACCESS/AUTO/ACCESS
TOT/TAT/TNT: UNKNOWN/NEGOTIATE/UNKNOWN

Just look like a standard, unconfigured Access Port, and there is no way to clear these dynamically learned DTP entries from either verification command.

They do not time out after 300 seconds (5 minutes) of being inactive going from the Timestamp of *Mar 1 02:31:47.897 from jumping around ports above, I will unplug to get the timestamp to confirm its been over 5 minutes:

SW1#
*Mar 1 02:45:51.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/21, changed state to down
*Mar 1 02:45:52.982: %LINK-3-UPDOWN: Interface FastEthernet1/0/21, changed state to down
SW1#sh dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
8 interfaces using DTP
SW1#

So its been about 15 minutes, and no change in the “sh dtp” or “sh dtp int” output. There is no command to “clear” this information, the switch has had to be reloaded to remove the dynamically learned entries.

*** Making any sort of hard coded trunk interfaces will also up the DTP interfaces # and have its information recorded to “sh dtp interface” even if you remove the configs and no cable was ever plugged into the interface ***

Different ways to turn off DTP on an interface so it does not send Hellos

• “switchport mode access” – The switch will still have a DTP informational reference to the port in verification commands, but is not DTP Enabled when hard coded, with or without the “nonegotiate” command
• “switchport nonegotiate” – Turns off DTP on a hard coded Trunk interface with “switchport mode trunk”, it will still show as “Enabled: yes” in verification output for some reason though debugs will confirm it is not sending DTP Hellos
• “no switchport” – Issued also at interface level, turns switchport into a routed port, stops DTP messages as it is now a Layer 3 interface
• “switchport mode dot1q-tunnel” will also technically disable DTP on an interface as the feature does not use DTP, however this function is used to create Layer 2 VLAN Tunnels back to Service Providers, so I don’t anticipate seeing on the R/S exam
• Ports will only use DTP if there is a Trunk configuration hard coded onto them, or a device plugged in, otherwise unused and unconfigured ports will not use DTP – If a device is plugged into an unconfigured port however it will use DTP!

As mentioned a few times here, for some reason my hard coded Trunk interface with Nonegotiate configured still shows as “Enabled: yes” in “sh dtp interface”, so I ran a debug from SW2 to verify if its sending traffic.

Debug output from before and after “nonegotiate” is configured on SW1’s Fa1/0/1

Here is a quick demonstration of DTP debugging, first showing the types of debugs you can run, and then messing with the DTP configs a bit to generate different output:

“debug dtp …” sub-commands

SW2#
SW2#debug dtp ?
aggregation Show DTP debug user message aggregation
all All DTP debugging messages
decision Show DTP debug decision table
events DTP events
oserrs DTP OS errors
packets DTP packet processing
queue Show DTP debug packet queueing
states DTP state transitions
timers DTP timer events

Turning on debugging and confirming Hellos are 30 seconds apart

SW2#debug dtp events
DTP events debugging is on
SW2#
*Mar 1 02:54:59.751: DTP-event:Fa1/0/2:Received packet event ../dyntrk/dyntrk_process.c:2208
*Mar 1 02:55:29.757: DTP-event:Fa1/0/2:Received packet event ../dyntrk/dyntrk_process.c:2208
SW2#

Turning off nonegotiate on SW1 Fa1/0/1 and returning to SW2 and let it cook

SW1(config-if)#no switchport nonegotiate
SW1(config-if)#
ASR#2
[Resuming connection 2 to sw2 … ]

*Mar 1 02:55:59.764: DTP-event:Fa1/0/2:Received packet event ../dyntrk/dyntrk_process.c:2208
*Mar 1 02:56:00.082: DTP-event:Fa1/0/1:Received packet event ../dyntrk/dyntrk_process.c:2208
*Mar 1 02:56:29.770: DTP-event:Fa1/0/2:Received packet event ../dyntrk/dyntrk_process.c:2208
*Mar 1 02:56:32.093: DTP-event:Fa1/0/1:Received packet event ../dyntrk/dyntrk_process.c:2208
*Mar 1 02:56:59.776: DTP-event:Fa1/0/2:Received packet event ../dyntrk/dyntrk_process.c:2208
*Mar 1 02:57:02.108: DTP-event:Fa1/0/1:Received packet event ../dyntrk/dyntrk_process.c:2208

So it is generally now sending Hellos on each interface every 30 seconds, give or take a second, and there is one important thing to note here:

You never see DTP Packets sent from the local router, only received from the remote router when running DTP debugs! Important detail for exam day!!!

This is such an important detail to know if you are asked “What command would allow the network administrator to see DTP Hellos being sent by the local switch?” – The answer would be absolutely none!

So remember that one very important fact for the exam day, DTP Debugs only capture received DTP events, not sent!

Very good and widely unknown command to view non-formed Trunk interfaces!

To wrap this up, here is a command that will show you interfaces that are configured to Trunk improperly, like the case of mismatching encapsulation types, which I have configured here on SW2 by changed its encap to ISL:

SW2#sh int trunk

^Nothing showing, both trunks are down, lets have a closer look

SW2#sh int fa1/0/1 trunk

Port          Mode Encapsulation       Status          Native vlan
Fa1/0/1       auto          isl                 not-trunking     1

Port Vlans allowed on trunk
Fa1/0/1 1

Port Vlans allowed and active in management domain
Fa1/0/1 1

Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/1 none

^Just like the full output of “sh int trunk” for non-forming trunks!

SW2#sh int fa1/0/2 trunk

Port          Mode         Encapsulation       Status          Native vlan
Fa1/0/2     desirable          802.1q           not-trunking      1

^I redacted the full output, but both my trunks do not seem to be trunking.

***This is very important to note as far as Trunk troubleshooting commands, to find configured trunks that are not active, know this for exam day!!!!!!***

And that is about all I have to say about that.

*Thump!*