VLAN Trunking Protocol and Dynamic Trunking Protocol

VLANs, as we discussed before, are used to create logical broadcast domains on switches. However this information needs to be synchronized between switches. Manual configuration can be tedious in a large scale network, so understanding how to configure VLAN Trunking Protocol and Dynamic Trunking protocol are necessary.

To begin, you must understand the basic function of VTP. VTP is a messaging protocol that CISCO designed to synchronize the VLAN database (vlan.dat) between switches in a common administratively controlled group (VTP domain). This information is only propagated as Layer 2 multicast advertisements across trunk ports. Additionally, all switches abide by synchronizing to the latest change of the database (this is also referred to as the latest revision number). First we must discuss the function of VTP modes: Server mode, Client mode, and Transparent mode, to maintain this control. Each mode can be configured from global configuration mode and can be verified with the show vtp status command.

A switch that is in Server mode has the ability to create, modify and delete VLANs from the Database, and synchronize to the latest change. Synchronization can occur from receiving messages from that originated from a server switch then passed through a client or another server switch. This is also the default mode.

Example 1:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#vtp mode server

Device mode already VTP SERVER.

SW1(config)#exit

SW1#show vtp status

VTP Version :2
Configuration Revision :4
Maximum VLANs supported locally :250
Number of existing VLANs : 9
VTP Operating Mode :Server
VTP Domain Name : POD4
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest

 

:0xFA 0xCF 0x65 0xB5 0x11 0x26 0xF2 0x82

 

Configuration last modified by 10.4.1.2 at 3-1-93 00:02:20

Local updater ID is 10.4.1.3 on interface Vl1 (lowest numbered VLAN interface found)

SW1#

Client mode only will make changes to the VLAN database when and a VTP advertisement with a higher Revision number is received. Synchronization is the same as server mode, where client switches updates its own database with the advertisement received then passes the message along out other trunk ports.

Example 2:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#vtp mode client

Setting device to VTP CLIENT mode.

SW1(config)#vlan 5

VTP VLAN configuration not allowed when device is in CLIENT mode.

SW1(config)#vlan 10

VTP VLAN configuration not allowed when device is in CLIENT mode.

SW1(config)#exit

SW1#vtp

SW1#show vtp status

VTP Version :2
Configuration Revision :4
Maximum VLANs supported locally :250
Number of existing VLANs : 9
VTP Operating Mode :Client
VTP Domain Name : POD4
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest

 

:0xFA 0xCF 0x65 0xB5 0x11 0x26 0xF2 0x82

 

Configuration last modified by 10.4.1.2 at 3-1-93 00:02:20

Transparent mode can create VLANs just like server mode, but instead of synchronizing to the latest revision number, the switch just ignores the message and forwards it out of other trunk ports. Additionally its revision number is always zero.

Example 3:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#vtp mode transparent

Setting device to VTP TRANSPARENT mode.

SW1(config)#vlan 5

SW1(config-vlan)#exit

SW1(config)#exit

SW1#show vtp status

VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 250
Number of existing VLANs : 11
VTP Operating Mode : Transparent
VTP Domain Name : POD4
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest

 

: 0x63 0x01 0x67 0x1E 0x9B 0x4E 0xAF 0x50

 

Configuration last modified by 10.4.1.3 at 3-1-93 00:02:20

To administer a network with the least amount of administration overhead (which may waste manpower), each physical broadcast domain should have one or two VTP servers and the remaining switches should operate in Client mode. However, rogue switches (a switch in Server or Client mode with a higher revision number) have the potential to erasing known VLANS from the database. This is sometimes referred to as a VTP wipeout. To prevent this, authentication can be configured between switches with the VTP password command. Switches with dissimilar authentication will not update one another’s database. Otherwise Transparent mode should be configured, to prevent this possible vulnerability, however the VLAN changes must be updated on each switch within that given VTP domain name.

Dynamic Trunking Protocol is a layer 2 protocol that is responsible for dynamically negotiates trunks between switches. It can aid an administrator in building trunks between switches by the given operating mode that can be configured per interface. However, there are best practices for implementing these modes. These modes are Switchport mode: Dynamic Desirable, Dynamic Auto, Trunk and Access.

 

The first two modes operate by how DTP messages are being sent across the link. Dynamic Desirable mode actively sends DTP packets to negotiate trunks, while Dynamic Auto passively receives DTP packets then sends a response packet to negotiate the trunk.

Example 4:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#interface fastethernet 0/5

SW1(config-if)#switchport mode dynamic desirable

SW1(config-if)#end

SW1#show interface fastethernet 0/5 trunk

Port Mode Encapsulation Status Native vlan
Fa0/5 desirable 802.1q trunking 1

Example 5:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#interface fastethernet 0/5

SW1(config-if)#switchport mode dynamic auto

SW1(config-if)#end

SW1#show interface fastethernet 0/5 trunk

Port Mode Encapsulation Status Native vlan
Fa0/5 auto 802.1q trunking 1

The next two modes, Switchport mode Trunk and Switchport mode Access, actually allow the administrator to manually configure a trunk or a port that will never be a trunk (access).

Example 6:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#interface fastethernet 0/5

SW1(config-if)#switchport mode trunk

SW1(config-if)#end

SW1#show interface fastethernet 0/5 trunk

Port Mode Encapsulation Status Native vlan
Fa0/5 on 802.1q trunking 1

Example 7:

SW1#config terminal

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#interface fastethernet 0/5

SW1(config-if)#switchport mode access

SW1(config-if)#end

SW1#show interface fastethernet 0/5 trunk

Port Mode Encapsulation Status Native vlan
Fa0/5 off 802.1q non-trunking 1

As a general practice, trunks should be configured manually between switches and manually disable on port that connect to end devices or layer 3 devices. By allowing switches to dynamically negotiate its trunk, could potentially allow the switch to negotiate trunking on an unexpected port which could lead to a VTP wipe out.

These technologies are critical for the CCNA exam, and a practice with each of these commands and protocols with make the testing process easier.

Related Training: CCNA Boot Camp

Author: Jason Wyatte

In this article

Join the Conversation

2 comments

  1. charles gwinn Reply

    I’m glad I found this it was very helpfull. I have a question maybe you could answer if you don’t want to thats OK. We have a serveral 6509’s in a existing VTP domain. The engineers are wanting to add a Actelis 2300 and establish a trunk between the two. The first UNI they want to work out of the actelis box needs to go back to an existing Elan domain 34 out of the 6509 with serveral working UNI’s already. I’m thinking all the trunk adds would need to be done manually to avoid any head aches. add dot.q on both ends and the vlan 34 we should be ok I think. Plus there is no way to build a EVC to an existing elan domain without changing them to evpl service first. Thanks

  2. Jason T. Wyatte Reply

    Hello Charles!

    Yes when you have to build trunks between CISCO and non CISCO switches, then you would need to manual create the trunk, set the native vlan to the same value on both sides, manually specify the same vlans that will traverse the trunk, and disable DTP and CDP on the interface. In general, the multicast protocols of CDP and DTP are going to be supported on non CISCO switches and technically would be flooded by those switches when they receive those types of packets. You do seem to have the correct grasp of what needs to be applied. Let me know how the deployment goes.

    Thanks again for answering my blog!

    Jason T. Wyatte