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 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?
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.
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!!
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.
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?
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.
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 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.
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.
