Cisco DTP (Dynamic Trunking Protocol) Negotiation

thank you
Rene
your wonderful

You are welcome Hussein.

Hi Rene,

Can you explain me what does it mean Trunking negotiation is ON does it means that this particular mode is set to send DTP frames . to the my knowledge only Dynamic desirable and ON mode will send out DTP frames and other modes are doesn’t (Dynamic Auto and Access)

Hello Ankit

When we say that DTP negotiation is ON, it means that the port is in a state where, if the proper DTP packets are sent/received, the port may change its trunking functionality. Negotiation is ON in the following states: Dynamic Desirable, Dynamic Auto or Trunk.

DTP negotiation is OFF when a port is in one of the following states: Access or Non-negotiate.

As for the exchanging of DTP frames, these are sent when a port is in the following states: Dynamic Desirable and Trunk.

DTP frames are NOT sent when a port is configured as Dynamic Auto, Non-negotiate or Access.

So, even if a port is in Dynamic Auto and doesn’t send DTP frames, it is still considered Negotiation ON because it can be affected by the DTP frames it receives.

I hope this has been helpful!

Laz

1 Like

We use Switchport no negotiate only on Trunks ? Or we use it on access ports as well ?
Thanks

Hello Abdul

When you configure a port to function as a trunk using the switchport mode trunk command, you are hardwiring that port to function as a trunk. However, it will still send out DTP messages to the other side of the link, and if that side of the link is configured to listen and respond to DTP messages (set to dynamic auto or desireable) it will automatically become a trunk.

By using the switchport nonegotiate command, you disable the sending of any DTP messages completely.

I hope this has been helpful!

Laz

Hello Abdul

The switchport nonegotiate command is only applied on trunk ports. DTP is automatically disabled on ports that are manually configured as access ports.

I hope this has been helpful!

Laz

Hi Rene/Laz,

If we are having trunk mode both side but DTP is disabled means trunking is off, is that mean frame received by switch will be normal frame not tagged one then how frames will be processed by switches b/w each other?

Hello Pradyumna

If you disable DTP, this doesn’t mean that trunking is off. This means that trunk negotiation is off. You can still manually configure a port to function as a trunk simply by using the switchport trunk command.

Whether or not a frame on a particular link will have a tag or not depends on the state in which the link finds itself. If DTP is off, then it depends on the configured switchport mode on the egress port. If DTP is on, then it depends on the result of the negotiation.

I hope this has been helpful!

Laz

Hi Laz,

If we hard coding the interface as a trunk on both side and disable DTP then how interfaces will react as trunk or access and if we are disabling DTP when interfaces are in trunk mode why is this required?

Hello Pradyumna

There are only two ways to disable DTP:

  • configure the port for access mode
  • use the switchport nonegotiate command

If you configure a port as a trunk, you are not disabling DTP. You are hard coding the port to trunk, but the port will still send out DTP messages to the other end saying “I’m a trunk, please become a trunk too!” This means that if there is a port on the other end where DTP has not been disabled, and where it has not been manually configured, it will automatically become a trunk.

I hope this has been helpful!

Laz

Mean when port the port is hardcoded Trunk as well as DTP disabled, port will always be Trunk port but we have to configure it at both sides.

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