Understanding VTP

VTP is a Cisco proprietary, Layer 2 multicast messaging protocol that can ease some of the administrative burden associated with maintaining VLANs. VTP maps VLANs across all media types and VLAN tagging methods between switches, enabling VLAN configuration consistency throughout a network. VTP reduces manual configuration steps required at each switch to add a VLAN when the VLAN extends to other switches in the network. Further, VTP minimizes potential configuration mismatches and manages the addition, deletion, and renaming of a VLAN in a more secure fashion than making manual changes at every switch. VTP is a value-add software feature specific to Cisco Catalyst switch products such as the 1900, 2820, 2948G, 3000, 4003, 5000 family, and 6000 family.

Not infrequently, users confuse the difference between VTP, ISL, 802.1Q, DISL, and DTP. All of these protocols involve trunks, but have different purposes. Table 12-1 compares these protocols.

Table 12-1. Summary of Trunk-Related Protocols

Protocol

Description

ISL

Cisco's proprietary trunk encapsulation method for carrying VLANs over FE or GE interfaces

802.1Q

An IEEE standard for carrying VLANs over FE or GE trunks that is essentially a subset of Cisco's current implementation of 802.1Q, which uses a Per-VLAN Spanning Tree implementation like ISL Trunk Protocol

DISL

Cisco's first generation trunk establishment protocol provides several options to enable the configuration of trunks at the other end of a switch link(s)

DTP

Cisco's second generation trunk establishment protocol establishes trunk negotiation options with links that may be using either 802.1Q or ISL as the trunk encapsulation type

VTP

Cisco's method of distributing VLAN information

ISL and 802.1Q specify how to encapsulate or tag data transported over trunk ports. The encapsulation and tagging methods identify a packet's source VLAN. This enables the switches to multiplex the traffic from multiple VLANs over a common trunk link. Chapter 8, "Trunking Technologies and Applications" describes these two methods and how they function.

DISL and DTP help Catalysts to automatically negotiate whether to enable a common link as a trunk or not. The Catalyst software included DISL until Cisco incorporated support for 802.1Q. When 802.1Q was introduced, the protocol needed to negotiate whether to use ISL or 802.1Q encapsulation. Therefore, Cisco introduced the second generation trunk negotiation protocol, DTP. DISL and DTP are described in Chapter 8.

VTP provides a communication protocol between Catalysts over trunks. The protocol allows Catalysts to share information about VLANs in the VTP management domain. VTP operates only after DISL/DTP complete the trunk negotiation process and functions as a payload of ISL/802.1Q. VTP does not work over non-trunk ports. Therefore, it cannot send/receive any messages until DISL or DTP negotiate a link into trunk status. VTP works separately from ISL and 802.1Q in that VTP messages transport configuration data, whereas ISL and 802.1Q specify encapsulation methods. If you have a protocol analyzer capable of decoding these protocols and set it up to capture trunk traffic, it displays VTP as encapsulated within an ISL or 802.1Q frame. Figure 12-12, discussed later in this chapter, shows a VTP frame encapsulated in ISL.

VTP primarily distributes VLAN information. You must configure VTP before you can configure any VLANs. Chapter 5 presented the three steps for creating a VLAN. Specifically, the steps include:

1. Assign the Catalyst to a VTP domain (unless the Catalyst is configured in VTP transparent mode, discussed later.)

2. Create the VLAN.

3. Associate ports to the VLAN.

Chapter 5 described the details of the last two steps, but deferred the discussion about VTP domains to this chapter.

A VTP domain associates Catalysts with a common configuration interest. Catalysts within a VTP domain share VLAN information with each other. If an administrator on a Catalyst creates or deletes a VLAN, the other Catalysts in the VTP domain automatically become aware of the change in the list of VLANs. This helps to ensure administrative conformity between the Catalysts. Without configuration uniformity, Spanning Tree might not, for example, converge upon an optimal topology for the VLANs. VTP also serves to eliminate configuration steps for you. Without VTP, you need to manually create and delete VLANs in each Catalyst. But with VTP, VLANs automatically propagate to all other Catalysts throughout the VTP management domain. This is the principle benefit of VTP. Although this might not sound significant in a small network, it becomes particularly beneficial in larger networks.

A parallel benefit of the management domain limits the extent to which changes can be propagated. Figure 12-1 shows a Catalyst system with two management domains wally and world. Domain wally has VLANs 1, 2, 3, and 4 configured, and domain world has VLANs 1, 2, 3, and 10 configured. Assuming there are no Layer 3 issues, workstations assigned to the same VLAN can communicate with each other even though they are in different management domains. A station in VLAN 2 in wally belongs to the same broadcast domain as a station in VLAN 2 in world.

Figure 12-1. VLAN Distribution in a Catalyst Network

Suppose a network administrator decides to add a VLAN 5 to both domains. If you create VLAN 5 in wally, VTP propagates the new VLAN throughout the domain wally. When the VTP announcement reaches the border Catalyst in world, that Catalyst ignores the information from wally. The administrator needs to also create VLAN 5 in world to spread the VLAN existence.

Suppose the administrator decides to remove VLAN 3 from world. At a Catalyst in domain world, the administrator clears VLAN 3. What happens to VLAN 3 in wally? Nothing. When the border Catalyst in world advertises a VTP announcement to the Catalyst in wally, the wally border Catalyst ignores the information and retains VLAN 3.

Tip

In this case where the administrator deletes a VLAN, VTP propagates the deletion information to the other Catalysts in the management domain. Any hosts attached to ports in the deleted VLAN lose network connectivity because all Catalyst ports in the domain assigned to the VLAN become disabled.

At times, network administrators get new equipment. The equipment, of course, arrives with no configuration. But you cannot immediately start to create VLANs. You must first define a VTP domain. If your Catalyst is configured in the default server VTP mode and you do not assign a Catalyst to a VTP domain, the Catalyst does not let you create a VLAN as demonstrated in Example 12-1. Note that the Catalyst posts a message to the console stating that it refuses to change any VLAN status until it has a domain name. The message also references a VTP server. This is described in more detail later in the section "Configuring VTP Mode."

Example 12-1 Creating a VLAN with No VTP Domain Configured

   Console> (enable) set vlan 10 name willitwork   Cannot add/modify VLANs on a VTP server without a domain name.   Console> (enable) 

What constitutes a VTP domain? Three required conditions associate Catalysts to a common VTP domain:

• The Catalysts must have the same VTP domain name.

• They must be adjacent.

• Trunking must be enabled between the Catalysts.

The first prerequisite for VTP domain membership involves the management domain name. Catalysts identify their VTP management domain membership through the domain name. All Catalysts that you want to be in the same domain must have the same management domain name. Catalysts initially obtain their VTP management domain name either through command-line configuration or configuration file, or, if trunks are enabled, automatically from a neighbor Catalyst. To manually configure a Catalyst into a management domain, use the set vtp domain name command. Full usage is shown in Example 12-2.

Example 12-2 set vtp Usage

   cat6> (enable) set vtp ?   Usage: set vtp [domain <name>] [mode <mode>] [passwd <passwd>]                  [pruning <enable|disable>] [v2 <enable|disable>          (mode = client|server|transparent           Use passwd '0' to clear vtp password)   Usage: set vtp pruneeligible <vlans>          (vlans = 2..1005           An example of vlans is 2-10,1005) 

The Catalyst accepts domain names up to 32 characters long. Example 12-3 shows a VTP domain name configuration example. The administrator configures the Catalyst as a member of the VTP domain wally.

Example 12-3 set vtp domain Example

   Console> (enable) set vtp domain wally   VTP domain wally modified   Console> (enable) 

What domain and VLAN do the Catalysts belong to when they have a clean configuration? If no VTP domain is assigned to the Catalysts, the domain is NULL. All ports belong to VLAN 1. Use the command show vtp domain any time to discover what VTP domain a Catalyst belongs to as illustrated in Example 12-4.

Example 12-4 show vtp domain Output

   Console> (enable) show vtp domain   Domain Name                      Domain Index VTP Version Local Mode  Password   -------------------------------- ------------ ----------- ----------- ----------   wally                            1            2           server      -   Vlan-count Max-vlan-storage Config Revision Notifications   ---------- ---------------- --------------- -------------   5          1023             0               disabled   Last Updater    V2 Mode  Pruning  PruneEligible on Vlans   --------------- -------- -------- -------------------------   0.0.0.0         disabled disabled 2-1000   Console> (enable) 

For example, in the highlighted portion of Example 12-4, the Catalyst's display indicates that it belongs to the domain wally. If the Domain Name field is blank, the domain is NULL.

Tip

VTP domain names are case sensitive. A VTP domain name San Jose is not the same as san jose. Catalysts with the former domain name cannot exchange VLAN configuration information with Catalysts configured with the later domain name.

As an example of how Catalysts obtain VTP membership, consider the Catalyst system in Figure 12-2 where multiple Catalysts interconnect over trunks, but no management domain is assigned.

Figure 12-2. A Catalyst VTP Domain Example

Cat-A, Cat-B, Cat-C, and Cat-E all have trunk connections to other Catalysts, whereas Cat-D and Cat-F only attach through access ports. This prevents Cat-D and Cat-F from receiving VTP messages from any of the other Catalysts. Entering the command show vtp domain reveals an output similar to that seen in Example 12-4, but with no domain name assigned on any unit. Assume that you attach to Cat-A's console port to make configurations, and you enter the command set vtp domain wally. What happens to the other Catalysts in the network? You examine the VTP status on each Catalyst with the show vtp domain command, and you discover that Cat-A, Cat-B, Cat-C, and Cat-E all learn about the management domain, but not Cat-D and Cat-F. Cat-D and Cat-F fail to learn about the management domain because they do not have trunk ports on which to receive VTP updates.

By setting the VTP domain in one unit, all other Catalysts attached with trunk ports automatically learn about VTP domain wally and configure themselves as part of the domain. This works because Cat-B, Cat-C, and Cat-E had trunk connections and did not already belong to a VTP domain. If however, you had previously associated them with a different domain, they would ignore the VTP announcement for wally.

At this point, you can create new VLANs in Cat-A, Cat-B, Cat-C, and Cat-E, but not Cat-D and Cat-F. You can only create VLANs in Catalysts configured with a VTP domain name (as mentioned earlier, this assumes the default setting of VTP Server Mode as discussed in the next section). Because D and F do not have a domain name, you cannot create VLANs in them. So how do you add VLANs to Cat-D and Cat-F? You need to manually enter a VTP domain name in these two units before you can create any VLANs in them. When you assign them to a domain, they do not make any VTP announcements because there is no trunk link. But they do belong to a management domain. Alternatively, you can enable the links between Cat-A and Cat-D and Cat-C and Cat-F as trunks. When they are enabled as trunks, Cat-D and Cat-F can then receive VTP updates and become members of the management domain wally.

The requirements for defining a VTP domain are listed earlier. One of the requirements is that Catalysts with the same VTP domain name must be adjacent to belong to the same management domain. In Figure 12-3, Catalysts interconnect with trunk links and belong to several management domains. Two of the domains have the same name, but are separated by other domains. Even though the Catalysts in the first and last domain have the same management domain name, they actually belong to two different domains from a system point of view.

Figure 12-3. A Multiple VTP Domain Network

Whenever a Catalyst makes a VTP announcement, it includes the VTP domain name. If the receiving Catalyst belongs to a different management domain, it ignores the announcement. Therefore, VTP announcements from the wally domain on the left of the drawing are never seen by the Catalysts in the wally domain on the right of the drawing.

Tip

If you are installing a domain border switch that connects two domains, it becomes a member of the management domain that it first hears from. Therefore, be sure to attach it to the domain that you want it to belong to first. Make sure that it acquires the VTP domain name, and then attach it to the other domain. Otherwise, you need to manually configure the domain name.

Warning

A side effect of VTP domains can prevent an ISL trunk link from negotiating correctly with dynamic ISL (DISL). When DISL initiates trunk negotiation, it includes the VTP domain name in the message. If the two ends of the link belong to different domains, the trunk fails to establish automatically. To enable a trunk on border Catalysts between domains, set both ends of the trunk to ON or nonegotiate.