In this article well be taking a look at another Layer 2 concept, the VLAN Trunking Protocol (VTP). In this article well explore the basic operation and elements of VTP, including the benefits that it provides from network traffic and configuration perspective.
The main concepts to be covered in this article include:
- Overview of the VLAN Trunking Protocol
- VTP Modes
- VTP Pruning
Overview of the VLAN Trunking Protocol
The VLAN Trunking Protocol (VTP) is an interesting Layer 2 feature of Ciscos Catalyst switch line, and one that is definitely useful, especially in large, switched environments that include multiple Virtual Local Area Networks (VLANs). In the last article in this series, we took at look at the concept of a VLAN, along with VLAN tagging protocols like ISL. If you recall, the purpose of configuring VLAN tagging was to allow traffic from multiple VLANs to cross a trunk link used to interconnect switches. While this capability is great in large environments, VLAN tagging does nothing to help ease the burden of configuring individual VLANs on multiple switches. This is where VTP steps in to help.
The main purpose of VTP is to provide a facility by which individual Cisco switches can be managed as a group for VLAN configuration purposes. For example, if VTP is enabled on all of your Cisco switches, the creation of a new VLAN on one switch makes that VLAN available on all switches with the same VTP management domain. A VTP management domain is simply a group of switches that participate in sharing VTP information. A given switch can be part of only one VTP management domain at a time, and is part of no VTP management domain by default.
It should be immediately obvious why VTP is so beneficial. Imagine an environment in which a network administrator must manage 20 or more switches. Without VTP, the creation of a new VLAN would require the administrator to define that new VLAN on all necessary switches individually, a process that is unnecessarily time-consuming. Instead, with VTP, the administrator could define that VLAN once, and have VTP worry about propagating the information to all other switches in the same domain automatically. The main benefit of VTP is the efficiency that it provides in terms of adding and deleting VLANs, as well as making changes to VLAN configurations in large environments.
In general, configuring VTP on a Cisco Catalyst switch is not a difficult task. In fact, once a VTP management domain name is defined on each switch, the process by which switches exchange VTP information is automatic and requires no further configuration or day-to-day management. However, in order to full appreciate how VTP works within a given VTP domain, you must first understand the different VTP modes for which a switch can be configured. These are outlined in the next section.
VTP Modes
If you intend to make a switch part of a VTP management domain, each switch must be configured in one of three possible VTP modes. The VTP mode assigned to a switch will determine how the switch interacts with other VTP switches in the management domain. The three VTP modes that can be assigned to a Cisco switch include server mode, client mode, and transparent mode. Each of these roles is outlined below:
- Server Mode Once VTP is configured on a Cisco switch, the default mode used is Server Mode. In any given VTP management domain, at least one switch must be in Server Mode. When in Server Mode, a switch can be used to add, delete, and modify VLANs, and this information will be passed to all other switches in the VTP management domain.
- Client Mode When a switch is configured to use VTP Client Mode, it is simply the recipient of any VLANs added, deleted, or modified by a switch in Server Mode within the same management domain. A switch in VTP client mode cannot make any changes to VLAN information.
- Transparent Mode A switch in VTP Transparent Mode will pass VTP updates received by switches in Server Mode to other switches in the VTP management domain, but will not actually process the contents of these messages. When individual VLANs are added, deleted, or modified on a switch running in transparent mode, the changes are local to that particular switch only, and are not passed to other switches in the VTP management domain.
Based on the roles of each VTP mode, the use of each should be more or less obvious. For example, if you had 15 Cisco switches on your network, you could configure each of them to be in the same VTP management domain. Although each could theoretically be left in the default Server Mode, it would probably be easier to leave only one switch in this configuration, and then configure all remaining switches for VTP Client Mode. Then, when you need to add, delete, or modify a VLAN, that change can be carried out on the VTP Server Mode switch and passed to all Client Mode switches automatically. In cases where you need a switch to act in a relatively standalone manner, or dont want it to propagate information about its configured VLANs, use Transparent Mode.
VTP Pruning
Although the configuration of trunk links (using protocols like ISL) allows traffic from multiple VLANs to travel across a single link, this is not always optimal. For example, imagine a situation where three switches are connected by two trunk links, as shown below. In this case, all three switches include ports that are part of VLAN 1, but only Switches A and B include ports in VLAN 2. In this case, traffic for VLAN 2 would still be passed to Switch C, even though it does not have any ports configured for VLAN 2.
When VTP Pruning is implemented in a VTP management domain, traffic for a given VLAN is only passed to a switch across a trunk link if necessary. In this case, implementing VTP Pruning in the management domain would ensure that traffic for VLAN 2 is never passed to Switch C until such time as Switch C actually has VLAN 2 ports configured.
First Appeared at 2000Trainers.com
Dan DiNicolo is a technical trainer, consultant, author, and the managing editor of the free IT learning web site 2000Trainers.com. When he’s not busy traveling the world as an IT volunteer with organizations like Geekcorps, Dan makes his home in the snowy northern backwoods of Canada.
