VLAN Trunking Protocol
In Figure 4-4, two VLANs extend over multiple switches using trunking. Because each switch sharing trunks must support common VLAN information for the trunks to function correctly, Cisco created the VLAN Trunking Protocol (VTP) for creating and managing that VLAN information. It should be noted that any VLAN created on a switch is in an inactive state until VTP is configured.
A collection of switches that are under the same administrative control and will support the same range of configured VLANs are said to be in the same VTP domain. A domain name is simply a unique identifier up to 32 characters long used to identify the switches that will share the same VTP information. The domain name is also case sensitive.
VTP packets are sent to destination address 01-00-0C-CC-CC-CC with a SNAP type of 0x2003. Each switch can operate in one of three modes:
Server (default)
Client
Transparent
In server mode, the switch has a list of all the VLANs for that domain. It can add, delete, or rename any VLAN, and the configuration information is stored in nonvolatile random-access memory (NVRAM). In client mode, the switch obtains its information for the VLAN database from a VTP server, and it cannot make any modifications to it. The information learned by the client switch is not stored in NVRAM. If the client switch is rebooted, the switch must dynamically learn all the VLAN information again from a VTP server. In transparent mode, a switch does not participate in VTP; it merely passes the VTP advertisements to other switches. In transparent mode, the switch can be configured to add, delete, and modify, and the information is stored in NVRAM.
Certain requirements must be met before VTP can be used to manage a domain and distribute VLAN information. Each switch must have a configured trunk port, use the same domain name, and be directly connected. As noted earlier, the trunk port is used to send the VTP information to the adjacent switch. VTP can automatically distribute VLAN information to all other switches in the same domain through a trunk port, or allow manually for each switch to be configured. The dynamic process using server/client mode is administratively palatable because it is easy to implement; a server switch is configured with VLANs, and the rest of the switches in that domain receive that information. On the other hand, server/client mode can pose potential risks on the network, which will be discussed in this section shortly. Transparent mode requires manually configuring each switch.
VTP has four types of messages:
Summary advertisements (0x01)
Subset advertisement (0x02)
Advertisement requests (0x03)
Join (0x04)
The two types of VTP versions, version 1 and version 2, have some major differences. Version 2 has support for Token Ring. In version 2, switches running in transparent mode forward VTP advertisements they receive regardless of VTP version or domain name; switches configured for VTP version 1 ignore VTP advertisements with a different VTP domain name than the one configured. Cisco switches default to version 1.
Summary Advertisement
A switch configured as a VTP server sends a summary advertisement every 5 minutes to inform other connected switches of the domain name and revision number. The revision number is tied to changes in VLAN information and increments each time a modification is made on the VTP server switch. When a switch receives a revision number, it compares it to its own. If the number is the same or lower, the switch ignores the summary advertisement.
In Example 4-2, the debug output shows that the switch received a summary advertisement that has a lower revision number than the one that is currently on the switch. Therefore, the switch will ignore the VTP message.
Example 4-2. Debug Output of Summary Advertisement
VTP: domain Cisco, current rev = 6 found for summary pkt VTP: summary packet rev 2 lower than domain Cisco rev 6
If the revision number is higher, it will update the VLAN database with the information received. The VTP revision number is extremely important because a higher value revision number always wins. Imagine a situation where a switch used only for testing is accidentally connected to a production network. If the test switch is configured with the same VTP domain name as the production network and has a higher revision number, all production switches in that domain will synchronize to it. All previously used VLAN information is overwritten in favor of the VLAN database on the test switch. If the test switch has not been configured for the same VLANs as the production environment, switched ports will revert back to being members of VLAN 1, resulting in loss of connectivity. Always check the revision number of a new switch before bringing it on the network regardless if the switch is going to operate in client or server mode. Make sure the revision number is lower than the production server mode switch. An easy way to ensure that a new switch does not affect the operation of the other switches in the VTP domain is to simply change the domain name of the new switch to something bogus and back to the valid domain name. At this point, it is safe to bring the new switch to the production network, because any time a VTP domain name is changed, the revision number is reset. A reboot will also reset the revision number.
Subset Advertisement
Subset advertisement sends the list of VLANs to the client and server switches. This is the actual database that is being pushed to the switches. The subset advertisement gives information about the name of the VLAN, its status, type, and so on. More than one switch can be configured as a VTP server, and VTP servers will negotiate VLAN information until their databases are synchronized using subset advertisement messages. In Example 4-3, the switch receives information about VLANs 12, 30, 34, 100, and notification of a new VLAN, 111. This output can be collected using the set trace vtp command on the switch. Only during networking troubleshooting and as a last measure should the set trace command be used because the command taxes the resources of the switch.
Example 4-3. Debug of Subset Advertisement
VTP/Active: Opening vlan_EVENT_ET event - vlan=vlan12 mode=3 VTP/Active: Closing event VTP/Active: Opening vlan_EVENT_ET event - vlan=vlan30 mode=3 VTP/Active: Closing event VTP/Active: Opening vlan_EVENT_ET event - vlan=vlan34 mode=3 VTP/Active: Closing event VTP/Active: Opening vlan_EVENT_ET event - vlan=vlan0100 mode=3 VTP/Active: Closing event VTP/Active: Opening vlan_EVENT_ET event - vlan=vlan0111 mode=1 vtp_vlan_change_notification: vlan = 111, mode = 1 2003 Sep 04 10:44:16.110 setVtpVlanInformation: vlanNo [111], mode [1], remoteSp an [0], remote_span [0] primary[0] PType[0], mistp[0] 2003 Sep 04 10:44:16.250
Advertisement Request
An advertisement request is sent when a switch has rebooted, the domain name has been changed, or the VTP summary revision number is higher than what is locally on the switch. As noted in Example 4-4, the switch is requesting VTP database information from its directly connected neighbor.
Example 4-4. VTP Advertisement Request
VTP: tx vtp request, domain Cisco, start value
Join
VTP join messages prevent the upstream switches from pruning a VLAN on a trunk. The "VLAN Pruning" section later in this chapter will expand the role of this message type.
VTP Example 1
Figure 4-7 shows two switches participating in VTP domain. The server switch will propagate its VLAN information to the client switch. Any VLAN changes must occur on Switch1. The client, Switch2, will not lose its VLAN information if its connection is severed to the VTP server. However, VLAN information will be lost if the client switch is rebooted.
Figure 4-7. VTP Between Two Switches
VTP Example 2
Switch1 is a VTP server that is configured with VLANs 2 and 3 (see Example 4-5). Switch2, a new device on the network, is connected on the same VTP domain as Switch1, as shown in Figure 4-7.
Normally, bringing a new switch on the network is a rudimentary process, but in this case, the revision number of Switch2 is higher than Switch1. The higher VTP revision number will cause Switch1 to synchronize to Switch2. Switch1 believes that Switch2 has newer information than it. Using the set trace command, the router will generate a log message (see Example 4-6).
Example 4-5. Output of show vlan Command on Switch1
Switch1 (enable) show vlan
VLAN Name Status IfIndex Mod/Ports, Vlans
---- -------------------------------- --------- ------- ------------------------
1 default active 5 1/1
2/1-2
6/1-48
10/7-48
2 vlan2 active 157 10/1-3
3 Vlan3 active 173 10/4-6
Example 4-6. Debug of VTP on Switch1 Learning of a Higher Revision Number
VTP: i summary, domain = Cisco, rev = 4, followers = 1 VTP: domain Cisco, current rev = 1 found for summary pkt VTP: summary packet rev 4 greater than domain Cisco rev 1
As a result, Switch1 loses VLANs 2 and 3, and any ports associated with those VLANs default back to VLAN 1. Remember, the highest revision number wins regardless of the mode of the switch. The output from Example 4-7 shows all ports are once again associated with VLAN 1.
Example 4-7. Output of show vlan Command on Switch1 After Synchronizing with Switch2
Switch1 (enable) show vlan
VLAN Name Status IfIndex Mod/Ports, Vlans
---- -------------------------------- --------- ------- ------------------------
1 default active 5 1/1
2/1-2
6/1-48
10/1-48
1002 fddi-default active 6
1003 token-ring-default active 9
1004 fddinet-default active 7
1005 trnet-default active 8
VTP Mode Best Practices
Some environments still deploy VTP server/client mode, while others stick with transparent mode. It is recommended that you configure VTP for transparent mode for a number of reasons, aside from the revision number issue. If an engineer accidentally erases a VLAN, the switch through the VTP mechanism will propagate that information to the rest of the domain. In addition, VTP server/client mode currently only supports VLANs 1-1024. The extended VLAN range, 1024-4096, requires the switch to be configured in transparent mode. The rule of thumb is keep everything simple, because in the long run it can save time and money.
Thus far, the discussion throughout this chapter has been on theory and design considerations. The following section introduces some rudimentary examples on configuring the aforementioned topics. Cisco provides quite a bit of information on its site about how to configure various protocols, features, and so forth. Chapter 5, "Using Catalyst Software," is exclusively dedicated to providing configuration examples that will familiarize the reader on the more common configurations seen in the enterprise network.
