Mod Comms

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.

Figure 3: The problem of mixed revision numbers.

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.