Notes and discussion around my journey toward a Cisco Certified Internetworking Expert (CCIE) Routing and Switching Certification. The views expressed here are my own and do not represent those of my employer, or Cisco, or indeed any other organisation, person or entity! The information here is not guaranteed to be accurate and I will not be held responsible for the consequences of its use. Discussion is welcomed; abuse really is not, and I reserve the right to redact comments.

Monday, 29 June 2015

Some lab notes for Dynamic Trunking Protocol

Dynamic Trunking Protocol (DTP) Notes

Effect of 'switchport mode access' on DTP

After disabling DTP on all other ports, using 'switchport nonegotiate' and enabling 'debug dtp packets' I started investigating the effect of different port settings on DTP. I had been reading some discussion about whether an access port would still send out some DTP packets even after being turned into an access port using the 'switchport mode access' command.

So I put the port into dynamic desirable mode on both ends, successfully established a trunk, and then set one end as an access port.

So we can see that only one final DTP packet is sent and received to advise that the port has been placed in Access mode. It then ignores any further DTP packets, even though I can see them still being sent from the other end if I disable and enable DTP by putting the port on the other end into access mode, then back to dynamic desirable.

'switchport nonegotiate' limitations

'switchport nonegotiate'cannot be configured on a port already configured as a DTP trunk i.e. dynamic desirable or dynamic auto. It doesn't just switch DTP off on the port; you would have to place the port into 'switchport mode access' or 'switchport mode trunk' first.

Trunk encapsulation negotiation

Manually setting encapsulation on one end of the link

When DTP is used to negotiate encapsulation ('switchport trunk encapsulation negotiate'), which is default, then the trunk will be negotiated, if both switches support it, as

ISL, then

802.1q, if ISL is not supported by both switches.

However, even between two switches that support ISL, if encapsulation is set manually, using 'switchport trunk encapsulation isl | dot1q', at only one end, then DTP will negotiate that encapsulation on the link.

Limitations on the 'switchport mode trunk' command

The 'switchport mode trunk' command is used to manually set a link to always be a trunk. DTP packets are still sent out of the interface, so a trunk could still be formed with an 'active' DTP port.

However, the 'switchport mode trunk' command cannot be applied if encapsulation is negotiated. The encapsulation must be set manually.

DLS1(config-if)#switchport mode trunk

Command rejected: An interface whose trunk encapsulation is "Auto" can not be configured to "trunk" mode.

The error message is slightly misleading, referring to "Auto" encapsulation. This confused me the first time I saw it, until I realised it was referring to 'switchport trunk encapsulation negotiate' i.e. negotiated encapsulation. It would be great if Cisco kept their error messages consistent with their command syntax!