DTP thoughts

So, I started to dive a little deeper into DTP for some reason.. just wanted to think out loud a bit and make sure my thinking is correct.

I'm just gonna type up various thoughts and number them for better organization.. anyone can respond to any or all if they wish.

Thought #1. There are two ways to disable DTP generation on a switchport... Either by configuring a switchport to "switchport mode access" ... OR... "switchport mode trunk" followed by "switchport nonegotiate" (and note, that you can also do "switchport nonegotiate" on a switchport following "switchport mode access," but its just overkill since DTP is already turned off by setting it to access)

2. In the SWITCH FLG, on page 72, it states that Access mode function "Puts the interface into permanent nontrunking mode and negotiates to convert the link into a nontrunk link." Now I know that both the OCG and FLG have mistakes, but not sure if there is errata that can be downloaded for the FLG like there is for the OCG? So, is this a mistake? My thinking was that setting a port to access mode would disable DTP.. see the following output:

DSW1#sho run int fa0/11
Building configuration...

Current configuration : 58 bytes
!
interface FastEthernet0/11
switchport mode access
end

And then....

DSW1#sho dtp int fa0/11
DTP information for FastEthernet0/11:
TOS/TAS/TNS: ACCESS/OFF/ACCESS
TOT/TAT/TNT: NATIVE/NEGOTIATE/NATIVE
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

Also, when doing a "debug dtp all", I don't see any dtp being received from the other side.

In addition, I found a Cisco pdf with interesting info too.. I was going to copy/paste a link to this Cisco PDF, but it's super long, so I'll just say how to find it. Google "cisco basics dtp" and the first link there which is a pdf (albeit an old one), claims "switchport mode access - This command puts the interface (access port) into permanent nontrunking mode. The interface will generate DTP frames, negotiating with the neighboring interface to convert the link into a nontrunk link."

3. The bold text from the last part really gets me. Maybe Cisco switches USED to generate dtp frames even when configured in Access mode, but not anymore, and the FLG is just not updated? Also, I guess it wouldn't matter even if a switchport configured in access mode DID send dtp frames, since it can't be negotiated into a trunk regardless, hence no security risk?

4. Even when I set all of my switchports to access mode.. and it appears off when doing a "show dtp int fa0/x" the output of other commands have somewhat conflicting info... such as:

(Still says all interfaces using DTP, when all are in access mode)
DSW1#sho dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
26 interfaces using DTP

And...
DSW1#sho int counters protocol status
FastEthernet0/11: Other, IP, Spanning Tree, CDP, VTP, DTP

5. In researching a little, I see that the destination MAC address in DTP frames is 01:00:0c:cc:cc:cc, which is the same used for CDP, VTP, DTP, PAgP, UDLD, etc.. so disabling DTP entirely means you would tell the switch to stop accepting frames to 01:00:0c:cc:cc:cc, which would also impact CDP, VTP, PAgP frames, etc. ? But even though "sho dtp" says all interfaces using DTP, that doesn't imply that they're generating DTP frames, rather still listening for them.

Alright I know this post was long, but I just like to get down to all the details, it really helps me understand things better. I'm already comforatble with the trunk outcomes for all combinations, but I was just looking for a little more of the specifics since that FLG comment threw me a little. This is my first time deep diving into DTP.. Any comments are appreciated!

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

drkat

To my knowledge.... DTP is only turned off with non negotiate if it is in access mode it still generates frames
Here's a good post i think clears it up

Disabling Dynamic Trunking Protocol (DTP) - Packet Life

ColbyG

drkat wrote: »

To my knowledge.... DTP is only turned off with non negotiate if it is in access mode it still generates frames
Here's a good post i think clears it up

Disabling Dynamic Trunking Protocol (DTP) - Packet Life

Putting a port into static acces mode does it as well. Here's a thread discussing it:

networking-forum.com - View topic - Port Security Question

NetworkVeteran

Interesting, Colby. The CCIE R&S Certification Exam Guide says:

"switchport mode access - Never trunks; sends DTP to help other side reach same conclusion".

This wouldn't be the first or last time a Cisco Press book contains faulty information, but I'm going to lab it up just to see the behavior for myself.

NetworkVeteran

Colby, I checked on a Catalyst 6500. "switchport mode access" disables DTP, both according to the command-line and a sniffer trace. Additionally, I checked the Catalyst 6500 Configuration Guide and it says that "To support the switchport nonegotiate command, you must enter the switchport mode trunk command." In other words, "switchport nonegotiate" is only needed when "switchport mode trunk" is set.

Thanks for sharing.

This leaves me puzzled, why these various authors thought it was necessary when "switchport mode access" was set. Perhaps 2950/3550 behavior is different?

NetworkVeteran

Bingo! This behavior may vary by platform, hence the differences in experiences--

The Catalyst 6500 docs say "To support the switchport nonegotiate command, you must enter the switchport mode trunk command."

The Catalyst 3560 docs say, "This command is valid only when the interface switchport mode is access or trunk (configured by using the switchport mode access or the switchport mode trunk interface configuration command). This command returns an error if you attempt to execute it in dynamic (auto or desirable) mode."

The focus of the CCIE is the 3560. It's only natural for the author to describe its operation.

It would be only natural for the authors to describe their operating behavior.

NetworkVeteran

On the 2960 and 3560 the behavior is the same. +1 Cat6500 docs. -1 Cat2960/3560 docs.

Trials with 2960 and 3560.

MrBrian

Thanks for the interest guys! To be clear, I know this could be outside the scope of an exam or what not, but I'm just one of those curious types. Thanks for the posts NetworkVeteran, sounds like you went off on a tangent too lol.

I sure wish there was more documentation on some of these proprietary protocols. I guess what I really need to do is a bunch of sniffing to see what is actually going on. I know that once you put the port in access mode, it more or less doesn't matter security wise if you send DTP out or not, since the link can't be negotiated into a trunk anyway.

But still, I want to know exactly what the devices are sending out. It turns out the DTP frame consists of a status code(which refers to what mode its in), a DTP type(which refers to the encapsulation used), the neighbor's mac address, and interestingly, the VTP domain. I guess if the port was switchport mode access, and it did in fact send DTP still, that someone could glean your VTP domain name, if used. But again, it wouldn't matter since they can't form the trunk.

However, it really looks like DTP messages are not generated once the port is in access mode. I come to this conclusion based on the fact I did not see debug messages and from the output of "show dtp int fa0/x," which says "enabled: no." Which is interesting because I've seen multiple places out there claiming that an access mode port will still send DTP, including an old Cisco doc.

I found another blog where the author did a trace on a 2950, and his findings were that when a switchport is put in access mode, it will send ONE dtp frame out, and then be quiet. Interesting... That result kind of satisfies both standpoints, that theoretically dtp is disabled, but then again it sends dtp(albeit just the one frame). The link to that is below, and its the last part of the page. Now I need to set up my home lab so I can do some wiresharking!! I guess that's the best way to see what's really happening for my own eyes. I only have 2950's and 3550's though, so the 3560 could be different.

http://www.kimiushida.com/bitsandpieces/articles/packet_analysis_dtp/

MrBrian

Another thing to point out is the "nonegotiate" feature. I found that this can be configured only when the switchport is first set to either "switchport mode access" or "switchport mode trunk." If it is in auto or desirable, the command is rejected. That is because "nonegotiate" will definitely stop DTP messages from being generated.

However, if it is true that a switchport placed in access mode does NOT send out DTP, then the "nonegotiate" command on top of that would be just for looks, and not actually perform anything extra. Nothing new though, as I've seen many people claim this in different places online. However, I've also seen people saying that an access mode port WILL send out DTP, and that you'd need to also do "nonegotiate" to stop DTP on it. It's interesting to see conflicting statements regarding technical things like this, however different platforms and ios versions could vary on this.. well, makes it kinda fun to research..