Cisco DTP (Dynamic Trunking Protocol) Negotiation

Hello Pradyumna

Let’s assume you have a trunk link between SW1 and SW2. If you configure the port on SW1 as a trunk and you also configure the switchport nonegotiate command, the result is you will have a trunk port on this end that will not send out DTP messages.

In order to get this trunk link to function, you must configure the port on SW2 manually as a trunk as well. If you don’t, it will try to listen for DTP messages, it will hear none, and it will remain in the default state of access and the link will not function.

If you configure SW2 as a trunk, then the link will come up. At this point it doesn’t matter if SW2 is sending DTP messages, the result will be the same. But it is good practice to disable it, because at some point in the future, when you disconnect the switches and connect them in a different topology, the state of DTP may affect what the link ends up becoming, possibly causing undesired behaviour.

I hope this has been helpful!

Laz

Thanks Laz understood now

Hi,

I have one question. So the trunk negotiation would works if the two switches belong to the same VTP domain. The switch will throw an error says “Unable to perform trunk negotiation on port Et0/1 because of VTP domain mismatch.” My understanding is VTP will work after a trunk link establishes. So if I want to do a trunk between two VTP domain, I have to do the trunk in a nonnegotiable way , correct? Since trunk is the prerequisite for VTP to work, why Cisco won’t allow DTP to work if the two switches are not in the same VTP domain? It’s kinda like which comes first, the chicken or the egg . Sorry my question is kinda like I try to find quarrel in a straw. I’m just confused why they design it this way , is there any reason for it?

Appreciate your help like always.

Helen

Hello Helen

When DTP is enabled, ports will send a DTP packet every 60 seconds. The DTP packet itself contains, among other things, the name of the VTP domain (if it exists) that is configured on the switch. Take a look at this wireshark capture taken from this cloudshark capture.

image

So even before any VTP advertisements are exchanged, the VTP domain is contained within the DTP negotiation packets, and this is how devices know if they can form a trunk or not.

No need to apologize, it is great to see that you want to get really deep into the understanding of how these things work. That’s an important part of learning and understanding the concepts… way to go!!

I hope this has been helpful!

Laz

Hi Should we configure

switchport no negotiate on trunk ports & even on access ports ?

thank you

Hello Abdul

Yes, that is best practice. If you keep DTP enabled, a user in an enterprise network environment can bring in their own switch and connect it to the network jack that their PC was connected to. If they configure the switch correctly, they could configure a trunk with access to all VLANs on the network, thus causing a security breach. The best practice is to disable negotiation on all ports.

I hope this has been helpful!

Laz

hi switchport nonegotiate on accessports will help to prevent any hacker on access port. even if he bring some bad software .

But using switchport no negotiate on trunk links how it will be more secured ? how it will protect the network switch is already connected to another switch so no one can come?

sorry im revising so conceprs are getting clear

Hello Abdul

You are correct that the switchport nonegotiate command will not be very beneficial for protecting a switch from an attacker that wants to spoof a switch. It is more beneficial for use on access ports.

However, this command on a trunk port can be useful. It can make configuration and network modification much easier. It makes the switch behaviour much more predictable. What if you modify your topology and the port you used as a trunk is now used for an access port? You won’t remember on which ports you have disabled negotiation and on which you haven’t What if you change your topology around often? In such cases, it is safest to disable negotiation on all ports to ensure that any changes in the future won’t cause your network to become vulnerable.

I hope this has been helpful!

Laz

1 Like

Hi Rene,

What’s the purpose for disabling DTP negotiation beyond of not sending/receiving them?

Hello Jesus

Beyond simply disabling the sending and receiving of DTP messages, it is important to disable DTP in situations where ports may inadvertently change modes. For example, a switchport with DTP enabled will remain in access mode if a PC is connected to that port. But what if a malicious user plugs in a switch on that port and causes the switchport to change to trunk mode? That user will now potentially have access to all the trunks configured on the switch.

So it is more of a security issue rather than simply eliminating DTP messages from the network.

I hope this has been helpful!

Laz

Hello, everyone.

I thought that the switchport mode dynamic auto option tells DTP to passively wait for a negotiation message from the switch the interface is connected to and to not attempt any negotiation unless a message is received from the other side.

However, in my CML lab, despite my switches being configured for dynamic auto, they’re sending DTP messages.
obrázok

obrázok

obrázok

Note that they’re not forming a trunk but why are they sending DTP messages? They’re configured for dynamic auto, not dynamic desirable.

Thank you.

David

Hello David

Even though a Cisco switch port configured with switchport mode dynamic auto is passive in terms of initiating a trunk negotiation, it still sends out DTP frames. This behavior is part of the DTP’s design. If you take a look at the capture, you’ll see that the DTP messages being sent tell the other end of the mode the local switch is set to. It includes information on the administrative and operational mode of the local port. This information simply tells the switchport at the other end that “I am DTP enabled, and this is my status.” That specific DTP message won’t actually change anything on the other end, since the DTP configuration operates passively, but it is informational in nature.

I hope this has been helpful!

Laz

Hello @lagapidis

if thats the case, the statements in the snippet is not the correct, right ?

Hello Sathish

Yes, you are correct, my post from 2017 is actually incorrect. I have made the corrections to the post however.

Thanks for pointing that out!

Laz

1 Like