VLAN Trunking Protocol 39
VTP Process and Revision Numbers
The VTP update process begins when a switch administrator, from a VTP server switch, adds,
deletes, or updates the configuration for a VLAN. When the new configuration occurs, the VTP
server increments the old VTP revision number by 1, and advertises the entire VLAN
configuration database along with the new revision number.
The VTP revision number concept allows switches to know when VLAN database changes have
occurred. Upon receiving a VTP update, if the revision number in a received VTP update is larger
than a switch’s current revision number, it believes that there is a new version of the VLAN
database. Figure 2-2 shows an example in which the old VTP revision number was 3, the server
adds a new VLAN, incrementing the revision number to 4, and then propagates the VTP database
to the other switches.
Figure 2-2 VTP Revision Number Basic Operation
Cisco switches default to use VTP server mode, but they do not start sending VTP updates until
the switch has been configured with a VTP domain name. At that point, the server begins to send
its VTP updates, with a different database and revision number each time its VLAN configuration
changes. However, the VTP clients in Figure 2-2 actually do not have to have the VTP domain
name configured. If not configured, the client will assume it should use the VTP domain name in
the first received VTP update. However, the client does need one small bit of configuration,
namely, the VTP mode, as configured with the vtp mode global configuration command.
VTP clients and servers alike will accept VTP updates from other VTP server switches. When
using VTP, for better availability, a switched network using VTP needs at least two VTP server
switches. Under normal operations, a VLAN change could be made on one server switch, and the
other VTP server (plus all the clients) would learn about the changes to the VLAN database. Once
learned, both VTP servers and clients store the VLAN configuration in their respective vlan.dat
files in flash memory; they do not store the VLAN configuration in NVRAM.
1 Add New VLAN
4 Rev 3 Rev 4
5 Sync New VLAN Info
VTP
Client
VTP
client
VTP
Server
3 Send VTP Advertisement
4 Rev 3 Rev 4
3 Send VTP Advertisement
5 Sync New VLAN Info
2 Rev 3 Rev 4
With multiple VTP servers installed in a LAN, it is possible to accidentally overwrite the VTP
configuration in the network. If trunks fail and then changes are made on more than one VTP server,
the VTP configuration databases could differ, with different configuration revision numbers. When the
formerly-separated parts of the LAN reconnect using trunks, the VTP database with a higher revision
number is propagated throughout the VTP domain, replacing some switches’ VTP databases. Note also
that because VTP clients can actually originate VTP updates, under the right circumstances, a VTP
client can update the VTP database on another VTP client or server. See http://www.ciscopress.com/
1587201968 and look for downloads, to download a document that describes how a client could update
the VLAN database on another VTP client or server. In summary, for a newly-connected VTP server or
client to change another switch’s VTP database, the following must be true:
■ The new link connecting the new switch is trunking.
■ The new switch has the same VTP domain name as the other switches.
■ The new switch’s revision number is larger than that of the existing switches.
■ The new switch must have the same password, if configured on the existing switches.
The revision number and VTP domain name can be easily seen with a Sniffer trace; to prevent DoS
attacks with VTP, set VTP passwords, which are encoded as message digests (MD5) in the VTP
updates. Also, some installations simply use VTP transparent mode on all switches, which
prevents switches from ever listening to other switch VTP updates and erroneously deleting their
VLAN configuration databases.