
VTP for VLAN management
Mod Comms
Virtual LANs (VLANs) are used widely in modern network infrastructures. A VLAN can divide a physical LAN into small pieces of virtual LAN to contain broadcast traffic in a limited, reasonable range. In technical terms, it breaks the network into different broadcast domains.
All hosts in a switched network are required to listen and supply resources to process broadcast messages, even when they are not the target. Decreasing the frequency of broadcast messages by breaking the network into domains can avoid wasting host CPU power. Also, limiting the broadcast can prevent switches from wasting bandwidth to forward messages to unnecessary ports. Finally, because hosts in different VLANs cannot communicate with each other directly, VLAN can also provide security.
A host can be assigned to any VLAN regardless of geographic location, as long as the switches are connected by trunk links. VLANs need to be created on all switches on the path through which VLAN traffic passes. For example, in Figure 1 (see also Listing 1 for the configuration commands), VLAN20 needs to be created on SW1 and SW2 for red hosts to communicate, whereas VLAN 30 must be on SW2 and SW3 for the blue hosts to communicate. If you want the green hosts to communicate, all three switches would need VLAN10.
Listing 1: VLAN Configuration Commands
SW1(config)#vlan 10 SW1(config-vlan)#name Accounting_Dept SW1(config-vlan)#vlan 20 SW1(config-vlan)#name IT_Dept SW2(config)#vlan 10 SW2(config-vlan)#name Accounting_Dept SW2(config-vlan)#vlan 20 SW2(config-vlan)#name IT_Dept SW2(config-vlan)#vlan 30 SW2(config-vlan)#name Marketing_Dept SW3(config-vlan)#vlan 10 SW3(config-vlan)#name Accounting_Dept SW3(config-vlan)#vlan 30 SW3(config-vlan)#name Marketing_Dept

After VLAN configuration, the
show vlan
command verifies the settings (Listing 2). The VLAN information shown in the listing is also called the VLAN database. Besides the three VLANs that were just added manually, VLANs 1002 to 1005 are reserved for system usage. VLAN1 is the default VLAN, to which all ports are assigned if no configuration is made.
Listing 2: show vlan
SW2#show vlan VLAN Name Status Ports ---- -------------------------------- --------- ----------------------------- 1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/5, Fa0/6, Fa0/7, Fa0/8, Fa0/9, Fa0/10, Fa0/11, Fa0/12 10 Accounting_Dept active 20 IT_Dept active 30 Marketing_Dept active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active <--Output Omitted-->
By default, only VLAN2 to VLAN1001 are available for custom use. The VLAN configuration is stored in a file named vlan.dat
located in flash memory (Listing 3) instead of in the running configuration file (unless you are using transparent mode or off mode, which I address in a later section). Even if the running configuration file is erased, the VLAN information exists until you delete the vlan.dat
file.
Listing 3: Flash Memory Content
SW2>show flash Directory of flash:/ 1 -rw- 4414921 Aug 22 2017 00:00:02 c2960-lanbase-mz.122-25.FX.bin 2 -rw- 736 Aug 22 2017 10:53:02 vlan.dat 64016384 bytes total (59600727 bytes free)
If you assign ports to the correct VLAN, everything should be fine. I only show the command lines for SW1, because they are similar on SW2 and SW3:
SW1(config)#int fastEthernet 0/1 SW1(config-if)#switchport access vlan 10 SW1(config)#int fastEthernet 0/2 SW1(config-if)#switchport access vlan 20
Imagine you have more than 100 switches in your network. Every time a new VLAN is created, you will need to find the path through which VLAN traffic passes, so you can create the VLAN in the right switches. You also need to consider redundant paths, because the topology might change from time to time. This scenario is definitely a nightmare. Practically, VLANs are created on all switches to make sure they all can forward the traffic.
VTP Basic Configuration
Logging in to every switch individually to create or remove a VLAN is not fun. The VLAN Trunking Protocol (VTP) helps simplify such a boring and repetitive job. With VTP, you only need to manage the VLAN database at the VTP server; then, the VTP server propagates the VLAN information to all other VTP switches in the same VTP domain by using VTP update messages. For security reasons, the VTP password is also needed for a switch to join a VTP domain if a password has been set. The basic VTP configuration shown in Listing 4 should be placed on all switches in the same VTP domain.
Listing 4: VTP Configuration
SW1(config)#vtp domain admin Changing VTP domain name from NULL to admin SW1(config)#vtp password magazine Setting device VLAN database password to magazine
VTPs have four operating modes – server, client, transparent, and off – each of which behaves differently with local VLAN database modifications and VTP update messages. Table 1 summarizes the operating modes.
Tabelle 1: VTP Operating Modes
Server |
Client |
Transparent |
Off Mode* |
|
---|---|---|---|---|
Local VLAN configuration allowed? |
Yes |
No |
Yes |
Yes |
VTP updates generated? |
Yes |
Yes |
No |
No |
VTP updates forwarded? |
Yes |
Yes |
Yes |
No |
Own VLAN database synchronized with VTP updates? |
Yes |
Yes |
No |
No |
*Only version 3 supports VTP off mode. |
Server Mode
The default VTP operating mode is server mode, which allows VLAN database modification. It also advertises the most recent VLAN information to other switches. In Figure 2, SW4 is a VTP server. When the local VLAN database has changed, it sends VTP updates to its neighbors. For redundancy, you may have two or more VTP servers in a domain. If a server receives a VTP update, it compares the configuration revision number of the update message and its own VLAN database revision number. If the received revision number is larger, it accepts and updates its own database. The operating mode and configuration revision number can be verified with the
show vtp status

command (Listing 5).
Listing 5: show vtp status
SW4#show vtp status VTP Version : 2 Configuration Revision : 6 Maximum VLANs supported locally : 255 Number of existing VLANs : 8 VTP Operating Mode : Server VTP Domain Name : admin VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0xFC 0xCB 0xFA 0x57 0x4D 0x07 0x6E 0xA1
Client Mode
To change a switch to client mode, use the
vtp mode client
command. While VTP is working in client mode, VLAN modification is not allowed. A warning message is displayed when modifying a VLAN database locally in client mode:
SW2(config)#vtp mode client Setting device to VTP CLIENT mode. SW2(config)#vlan 50 VTP VLAN configuration not allowed when device is in CLIENT mode.
The switch will receive and check the revision number of the VTP update. As in server mode, client mode updates its own database only if the configuration revision number is larger than its own. You might be surprised to learn that a client also can generate a VTP update to other switches, just like a server. According to Cisco documentation [1], the only difference between a server and a client is the ability to modify the VLAN database locally. In Figure 2, SW3 is a VTP client. It receives VTP update messages from SW4, accepts and updates its database, and propagates the VTP update to SW2.
Transparent Mode
Transparent mode allows the switch to modify the VLAN database locally but does not accept any VTP updates. However, it works as a forwarder to propagate the VTP update messages. In Figure 2, SW2 is working in transparent mode; it does not update its own database, but it does forward VTP messages to SW1. As you might guess, the command to set a switch to transparent mode is:
vtp mode transparent
Moreover, transparent mode stores the VLAN database in the configuration file.
Off Mode
Off mode is only supported in VTP version 3. It neither accepts nor forwards VTP update messages. The VLAN database is allowed to change locally. To change the VTP version and then make the switch run in VTP off mode, enter:
vtp version 3 run vtp mode off
Like transparent mode, off mode stores the VLAN database in the configuration.
VTP Version 1 and 2
VTP versions 1 and 2 are similar. The major difference is that version 2 supports token ring; version 1 transparent mode only forwards version 1 VTP updates, whereas version 2 forwards both version 1 and 2 updates. If devices support version 3, you do not want to use version 1 or 2 because, as I mentioned earlier, whether in server mode or client mode, the switch will update its VLAN database if the received VTP update message has a larger configuration revision number. This situation creates a big problem. Assume all switches are using VTP version 2 or lower, as shown in Figure 3.

At first (Figure 3.1), SW1, SW2, and SW3 are connected in the same VTP domain running VTP version 1 or 2. All switches have VLAN databases with configuration revision number 5, and all databases are synchronized. Imagine a situation in which SW3 is disconnected, unmounted, and taken away for some other purpose (Figure 3.2). During that time, it is changed to server mode and its VLAN database is modified (e.g., VLANs are added or removed) so that the revision number has been increased to 6 (Figure 3.3). Before SW3 is returned to the original network (Figure 3.4), a smart network administrator will use the write erase
command to clear the configuration and set it to VTP client mode and think that it is now safe to plug SW3 to the original production network.
Server SW1 will try to synchronize client SW3 once it is connected to the original production network again. Unfortunately, the VTP configuration and VLAN databases are stored in flash storage when running in server or client mode, but not in the configuration file. After erasing the configuration, the VLAN database of SW3 is still there. In version 1 or 2, the VTP client also generates VTP updates. After SW3 is plugged to the production network, it propagates an update with a higher revision number so that SW1 and SW2 accept the VLAN database that is not correct for the production network. If some VLANs are deleted in these changes, hosts that are assigned to these VLANs will not be able to communicate. Worse still, administrators will run scheduled backups for the configuration file but might forget to do so for the vlan.dat
file (where the VLAN database is). A great deal of time may be needed to recover from this mistake. The correct steps for this scenario should be to change SW3 to transparent mode first, to reset the revision number to 0 and then change to client mode before connecting to the original VTP domain.
VTP Version 3
To overcome the false update issue, VTP version 3 [2] has introduced the primary and secondary server concept. Enter the vtp version 3
command to tell the switches to use VTP version 3. The vtp mode server
command only sets a switch to indicate a secondary server. However, all VTP version 3 switches do not accept a VLAN update unless the update is generated by a primary server. The only way to change the VLAN database is first to promote a secondary server to a primary server with the vtp primary vlan
command (Listing 6), modify the VLAN database, and finally demote it back to a secondary server for safety. By changing to transparent mode and then back to server mode, the primary server will act as a secondary server again.
Listing 6: Promoting Secondary Server
SW1#vtp primary vlan This system is becoming primary server for feature vlan No conflicting VTP3 devices found. Do you want to continue? [confirm] SW1# SW1#show vtp status VTP Version : 3 (capable) VTP version running : 3 VTP Domain Name : admin VTP Pruning Mode : Disabled VTP Traps Generation : Disabled Device ID : aabb.cc00.0400 Feature VLAN: -------------- VTP Operating Mode : Primary Server Number of existing VLANs : 23 Number of existing extended VLANs : 2 Configuration Revision : 2 <--Output Omitted-->
Some other features are also added in version 3; for example, increasing the VLAN propagating range from 1-1005 in previous versions to 1-4095. VTP version 3 also supports propagating Multiple Spanning Tree Protocol (MSTP) instance tables.
VTP Pruning
The VTP pruning feature can automatically block unnecessary traffic that passes through trunk links to avoid wasting bandwidth. In the scheme depicted in Figure 4, SW3 does not need any VLAN traffic other than VLAN10, so it notifies SW2 to prune all other VLAN traffic. SW2 only needs VLAN30 traffic, but it combines the SW3 request and tells SW1 to prune all VLANs other than VLAN10 and VLAN30.

The configuration is surprisingly easy. Just go to the VTP server and enter the command
vtp pruning
and all switches in the VTP domain will enable the pruning feature.
Conclusion
VTP is a convenient tool for VLAN management, but after hearing too many sad stories about the false database update incident, I strongly recommend using version 3 only, rather than version 1 or 2. VTP is a Cisco proprietary protocol, but you might consider an equivalent open standard called Generic VLAN Registration Protocol (GVRP) [3] for non-Cisco products.