VLAN Trunking Protocol
Imagine you just configured 50 VLANs in your local switch. If you want to have these VLANs span your five switches in your network, you have to configure each switch with those exact VLANs. That is at least 200 more configurations that you have to perform before you can even begin to assign the VLANs to their respective ports.
To minimize the administrative overhead involved in replicating VLAN configurations on the remaining switches in your internetwork, Cisco has created a proprietary protocol called VLAN Trunking Protocol (VTP). With VTP, you have to make the initial VLAN configuration on only a single switch. This switch has a special role to propagate any VLAN revisions (additions, changes, or deletions) to the rest of the switches that want to receive these updates, known collectively as a VTP domain. These messages are sent as multicasts to a unique MAC address that only Cisco devices participating in VTP will hear (01-00-0C-CC-CC-CC).
A VTP domain is similar to a large corporation in that there are specific job responsibilities and functions that everyone must perform in accordance to a job role. The switches inside a VTP domain also have a hierarchy in the roles that they can perform and the responsibilities of the switches that result from that role. These roles are dictated by the VTP mode in which they operate and ultimately define the level of VLAN configuration allowed on the switches and whether the VLAN information is stored and propagated. The three VTP modes in which a switch can operate are server, client, and transparent mode, which are discussed in the following sections.
VTP only advertises the VLANs that are configured. It does not advertise the VLAN interface assignments because switches can contain different hardware.
In the corporation analogy, a switch operating in server mode would be considered the CEO of the network. It is responsible for maintaining the VLAN information for the rest of the network by telling everyone else what to do. In server mode, you have complete autonomy and are able to make any additions, deletions, or changes to the VLAN configurations. Because this functionality seems to be a reasonable function of all switches, server is the default VTP mode of all switches.
After you make a revision to the VLAN information in the VLAN database, the changes are propagated across trunk links to other switches in the VTP domain to synchronize their VLAN databases with the server’s configuration. Each VTP advertisement from the VTP server contains a revision number in the message. When other switches receive this information, they compare the revision number of the new message to the last revision received. If the information is new (higher revision number), the switches apply those changes to their VLAN configurations. If the
revision number is the same as the advertisement, the switches know that they have the latest information and ignore the update. In instances when the revision number advertised is lower than the current one in the database, they send an update to the sender because the sender’s information is older than what they contain in their VLAN databases.
Imagine the chaos your company would have if everyone in the organization was the CEO. You would have everybody trying to tell each other what to do and nothing would ultimately get done. At some point, you need to have faithful workers who follow every word that the CEO tells them. In other words, you need yes-men.
The yes-men in the VTP domain are those switches that operate in client mode. Their sole purpose is to take the configuration revision from server switches and incorporate them into their operations. These switches also propagate those changes to other switches to ensure that the advertisement is heard across the entire VTP domain. Unlike switches in server mode, however, client mode switches do not permanently store their VLAN information in the VLAN database. Thus if switches in client mode reboot, they do not contain any VLAN information until they receive an update from the VTP server.
Because they receive their configuration from the VTP server, switches in VTP client mode cannot add, change, or delete VLANs. In fact, the IOS reports back an error similar to the following: VTP VLAN configuration not allowed when device is in CLIENT mode. This lack of functionality is actually quite useful when new switches are added to an existing VTP domain so they do not accidentally advertise incorrect VLAN information to switches in the VTP domain (assuming their revision number is higher).
To round out the corporation analogy, the inevitable third type of worker in large corporations is the disgruntled employee. These employees believe they know how to run the company better than the CEO, so they do things their way. However, to ensure that they keep their jobs, they don’t let anyone know about their delusions.
Similarly, switches running in transparent mode also do their own thing in the sense that they are allowed to add, change, and remove VLAN configurations. In addition, they store those VLAN configurations in their VLAN database so they are present when the switch reboots. The key difference between server and transparent mode switches is that transparent mode switches do not advertise their configurations to other switches. In addition, they also do not use any configuration revisions being advertised by server switches.
They do, however, send those advertisements out their trunk ports to other switches in case there are client mode switches downstream from them. In other words, the switch is transparent because the advertisements from the server seem to pass right through them.
So why have transparent mode in the first place? Basically, transparent mode enables you to create your own VLAN configurations that are contained within a single switch. This is useful if you have VLANs connected to that switch that are not used by any other switches in the domain.
The obvious follow-up question to this is, “Why use VTP on this switch if it does not listen to the VTP server revisions or advertise its own VLANs?” To answer this question, take a look at the exhibit in Figure 15.5. When the switch in server mode sends its VTP revision to the switch operating in transparent mode, that switch ignores the advertisement and passes it to the client switches below. If the transparent switch did not participate in VTP, it would drop those advertisements from the server and the client switches would never receive the configuration revisions.
Transparent mode is full of quirks above its normal VTP responsibilities. For instance, when running in VTP transparent mode, you have the ability to use extended-range VLANs. When using normal-range VLANs, you are limited to using 1-1005 as your VLAN ID. When running VTP in transparent mode (and using 802.1q trunks), your range of VLAN IDs can be extended to 1006-4094. Be advised, however, since switches in transparent mode do not advertise their VLANs, VTP does not recognize VLANs above 1005.
Furthermore, transparent mode stores the VLANs that you configure in the running and startup configurations as opposed to the VLAN database; therefore, you will see the VLANs you configured when you show the running or startup configurations in the IOS. Following this logic, it makes sense why other switches do not receive advertisements of VLANs from switches in transparent mode since it is actually the VLANs stored in the VLAN database that are advertised in VTP.
Make sure you understand the functions of each VTP role. Also, remember that you must be in either server or transparent mode to make any VLAN configuration changes in a switch.
VTP Revision Mayhem Recall that when adding a new switch to an existing VTP domain, it is highly rec ommended that you put the switch in client mode. If you left your switch in the default server mode, you could possibly have a higher revision number than the existing server of the domain. If you add that switch to the domain and you do not have any VLANs configured, when you advertise that to the rest of the VTP domain, the client and the other server use that configuration because it has a higher number. That would cause all the VLANs to be removed in all switches because your VLAN database does not con tain any VLAN configurations.
To reset your revision number, you can either change the name of your VTP domain to a bogus domain name and set it back to the existing domain name or set your switch to transparent mode followed by returning it to server or client mode.
VLAN traffic is being sent over trunk links to other switches no matter whether or not the VLAN is active on an interface. In other words, if a user connected to VLAN 2 sends a broadcast, that message is replicated to all switches in the domain regardless of whether VLAN 2 is assigned to a switch port. This could consume unnecessary bandwidth on the trunk links connecting the switches. To minimize the traffic overhead, you can configure VTP pruning on the VTP server of the domain. When enabled, switches advertise to each other which VLANs are active. With this information, the switch can limit VLAN traffic to other switches that do not have the VLAN active on an interface, minimizing the amount of unnecessary traffic that is sent to other switches on the trunk link.
Configuring and Verifying VTP
- Configure, verify, and troubleshoot VTP
Similar to the VLAN configurations, VTP is stored in the VLAN database. From global configuration mode, you can easily change the VTP mode of the switch from server to transparent or client mode. In addition, you can define your VTP domain name as well as assign an MD5 password for VTP updates. The domain name (and password if configured) are case sensitive and must match in all switches in the VTP domain or the VTP updates will be ignored from other switches and VTP will not function. To configure VTP-specific properties, use the vtp command followed by the VTP parameter you want to configure as illustrated in the following configuration example:
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#vtp domain CCNA
Changing VTP domain name from NULL to CCNA
Switch(config)#vtp password imustmatch
Setting device VLAN database password to imustmatch To communicate with other switches in the VTP domain, the VTP domain name has to be CCNA as shown in this switch. In addition, the VTP password must also match in all configurations to ensure VTP updates are authenticated from each other.
The default VTP domain is Null. If you connect your switch to an existing VTP domain while running in server or client mode, the switch will inherit the VTP domain name from a VTP server’s summary advertisement.
To change the default VTP mode from server to client or transparent, you simply need to use the vtp mode command in global configuration followed by the mode you wish the switch to participate in:
Switch(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
Be prepared to configure VTP parameters in a switch.
The show vtp status command is a critical command for verifying your VTP configuration. As demonstrated in Figure 15.6, the show vtp status command displays the revision number of the VTP updates from the server, the operating mode, domain name, pruning status, and the MD5 digest of the password.
Given the output(s) of the show vtp status command, be able to identify the operating mode and what functionality the switch has because of that VTP mode. In addition, be able to troubleshoot VTP inconsistencies such as non-matching VTP domain and MD5 passwords.
The concepts and configurations are very critical to comprehend for the CCNA exam. The following challenge tests your comprehension of the concepts and configuration of VLANs, trunks, and VTP.
- How many broadcast domains are present in the switch by default and what VLAN(s) are present?
- Enter global configuration and change your VTP domain to VTPMaster.
- Create the VTP password for the domain to be allhailme.
- Change the VTP mode to client.
- You need to create two separate broadcast domains in your local switch for the ExamCram and the ExamPrep departments. Configure them with VLAN numbers 100 and 200, respectively, and apply the configuration. Why will this fail?
- Change your VTP mode back to the default, add the VLANs, and exit the VLAN database.
- Apply VLAN 100 to interface Fast Ethernet 0/1.
- Apply VLAN 200 to interface Fast Ethernet 0/2.
- Make Fast Ethernet 0/24 an interface to carry all VLAN traffic to a neighboring switch, using the IEEE standard VLAN tagging.
In solving this Challenge the switch is configured, by default, for a single broadcast domain in the management VLAN 1. The configuration for steps 1–4 is as follows:
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#vtp domain VTPMaster
Changing VTP domain name from NULL to VTPMaster
Switch(config)#vtp password allhailme
Setting device VLAN database password to allhailme
Setting device to VTP CLIENT mode.
Any VLAN creation will fail at this point because you cannot add, change, or delete VLANs in VTP client mode. The remaining configuration steps are demonstrated here:
Setting device to VTP SERVER mode.
Switch(config)#interface FastEthernet 0/1
Switch(config-if)#switchport access vlan 100
Switch(config)#interface FastEthernet 0/2
Switch(config-if)#switchport access vlan 200
Switch(config)#interface FastEthernet 0/24
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk