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.

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.

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.

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.

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.

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).

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.

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.