DTP not setting a trunk on dynamic desirable

[eugenioGastelum]

I have this simple configuration, Switch0 is set to dynamic desirable and all others to dynamic auto. The three of them are using rapid-pvst on spanning tree (just mentioning it if it may be affecting)

Since Switch0 is on dynamic desirable, it's DTPs are being sent with dynamic desirable as well, and when they arrive at the switches 1&2 the trunkport is not being set. If I re do this topology with just two switches rather than 3 it does work. But not if there's more than 2 switches.

The output on the switches 2&3 when the DTP arrives says something about cero or more than 1 neighbors, which makes sense considering it's 3 switches.

Does DTP not work when there's more than 1 switch like in this current topology. Also, where in the DTP protocol it even mentions something about neighbors? I don't recall studying that DTPs packets contain information about neighbors so that receiving switches know that "There are cero or more than 1 neighbours".

This is the output from the swtich 2&3 when they receive their DTP from switch 0 asking for dynamic desirable

[M02@rt37]

Hello @eugenioGastelum,

It's important to note that DTP operates on a point-to-point basis. When a switch sends a DTP frame, it expects a response from a single neighbor. In a simple topology with two switches, the negotiation works because there is only one potential neighbor for each switch.

However, in your current topology with three switches, the DTP frames from Switch0 are received by both Switches 1 and 2. This leads to confusion because DTP expects a single response but receives multiple responses, which results in the error message about having zero or more than one neighbor.

DTP itself does not explicitly contain information about the number of neighbors. The error message you see is generated by the switch's software when it encounters an unexpected situation during the DTP negotiation process.

To do to resolve:

--Instead of relying on DTP, manually configure the trunk ports on Switches 1 and 2 using the "switchport mode trunk" command. This ensures that the trunk link is established without relying on DTP negotiation.

--If you don't require dynamic trunk negotiation, you can disable DTP on Switches 1 and 2 by using the "switchport nonegotiate" command. This forces the switches to form a trunk link without DTP negotiation.

--If your intention is to have multiple switches connected in a chain, you may need to consider adjusting your topology. For example, you could introduce a trunk link between Switches 1 and 2, while keeping Switch0 connected to one of them. This way, the DTP negotiation occurs between Switch0 and the intermediate switch, reducing the confusion caused by multiple responses.

[eugenioGastelum]

Thanks a lot! Very helpful, it makes sense.

However just a tiny bit more, this issue does not happens when the switches replies to the BPDUs, it happens as soon as they received a BPDU, there are no replies.

Iin packet tracer this is the order of the events (imagine it is a video)

1. The BPDU is originated at switch 0
2. The BPDU sails towards the hub
3. The BPDU is repeated out of both of hubs ports that connect to switch 1 & 2
4. Both repeated BPDUs arrive at switch 1 & 2 respectively

It's already on step 4 that such log of "cero or more than 1 neighbors" shows up, as if the BPDU or switch 1 & 2 are aware of the neighbors context. The error was not really happening on the reply back to switch 0 and confusing switch 0 for received 2 responses for his 1 BPDU. The error is at the moment the BPDU arrives at switch 1 & 2

Could that just be a bug of packet tracer and the real log about "cero or more than neighbours" should have displayed on the replied BPDUs rather than as soon as they were received?

[M02@rt37]

You're welcome @eugenioGastelum,

In the context of DTP and BPDU processing, the error message about "zero or more than one neighbors" typically occurs during the processing of received BPDUs rather than upon their arrival. The switch evaluates the information in the received BPDU and determines the appropriate action based on its spanning tree algorithm.

Regarding the behavior you observed in Packet Tracer, it is important to note that Packet Tracer is a simulation tool, and its behavior may not always reflect the exact behavior of real-world networking devices. Therefore, the specific timing or display of error messages in Packet Tracer may not precisely match what you would see on physical Cisco switches.

It would be beneficial to test the configuration on physical Cisco switches or using network simulators that closely mimic the behavior of actual devices.

[eugenioGastelum]

Many thanks! I don't have physical cisco switches/hub to try out with, but I'll assume for now it was a packet tracer bug on showing the error when the frame arrived at switch 1&2 rather than on the replies of said DTPs towards switch 0

[MHM Cisco World]

 these cases 

Both side must correct config to make link trunk' otherwise it will be access or limited.

[MHM Cisco World]

I use my phone' I see it now 

There is hub inbetween SW's

This sure make issue in protocol include dtp

One side send dtp but other side not hearing dtp and run interface as access not trunk

This happened because collision of add hub in between SW

[MHM Cisco World]

I run same lab in GNS3 and use wireshark I connect only two and same behave, 
I check the DTP header in wireshark there is indication that FCS is unverified 
this can indicate that the frame bit is somehow effect when passing the hub. so this lab I dont think it happend between two SW in real but sure there is issue in real network when connect three SW with hub 

[eugenioGastelum]

Thanks! Just one question, what is the FCS? Is there some documentation somewhere as to what are the DTP headers? I can't find it nor the RFC of DTP (dynamic trunk)

[MHM Cisco World]

Frame Check Sequence (FCS) Explained - YouTube