VTP for VLAN management

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Segmenting networks with VLANs
    Network virtualization takes very different approaches at the software and hardware levels to divide or group network resources into logical units independent of the physical layer. It is typically a matter of implementing secure strategies. We show the technical underpinnings of VLANs.
  • OpenStack installation with the Packstack installer
    At first sight, an OpenStack installation might seem like rocket science, but you can launch a fully functional cloud environment with minimal effort in a relatively short time with the Packstack automation tool.
  • Virtual switching with Open vSwitch
    Virtualization with Vmware, KVM, and Xen is here to stay. But up to now, no virtual switch has supported complex scenarios. Open vSwitch supports flows, VLANS, trunking, and port aggregation just like major league switches.
  • Virtual networks with Hyper-V in Windows Server 2016
    Microsoft provides some interesting virtualization features in current and future versions of Windows Server. You can connect or isolate virtual machines, and Windows Server 2016 even supports virtual switches.
  • Affordable hardware switch for SDN
    Most OpenFlow-ready hardware switches are prohibitively expensive if you just want to set up a small-scale test lab. Northbound Networks has stepped in with a Kickstarter campaign, filling the gap with the Zodiac FX switch.
comments powered by Disqus