VTP Modes | Cisco Catalyst LAN Switching

VTP Modes

Referencing the set vtp ? output of Example 12-2, notice that you have the option to configure a VTP mode. You can configure VTP to operate in one of three modes: server, client, or transparent. The three modes differ in how they source VTP messages and in how they respond when they receive VTP messages. Table 12-2 summarizes the differences between the three modes.

Table 12-2. VTP Mode Comparisons

Feature

Server

Client

Transparent

Source VTP Messages

Yes

Listen to VTP Messages

Yes

Create VLANs

Yes

Yes*

Remember VLANs

Yes

Yes*

*Locally significant only.

Source VTP Messages

Whenever you create a VLAN that you want VTP to automatically distribute to the other Catalysts in the management domain, you must create the VLAN on a Catalyst configured as a VTP server. After you create the VLAN, the VTP server automatically distributes the VLAN information through a VTP message called a VTP subset advertisement, which is described in more detail in the section, "Subset Advertisements." This message informs the other Catalysts in the management domain about the new VLAN. The Catalyst where you configure the new VLAN generates the initial subset advertisement which it sends out its trunk interfaces. Other servers and clients continue the propagation to other Catalysts in the network.

Catalysts configured in transparent mode, however, never generate VTP messages. When you create a VLAN on a transparent device, the VLAN information stays local and is not advertised to any other device even if it has trunk connections to other Catalysts.

Listen to VTP Messages

Only Catalysts configured as server or client pay attention to VTP messages. Whenever they receive a message with the VTP multicast address 01-00-0C-CC-CC-CC and an SNAP type value of 0x2003, the receiving Catalyst sends the frame to the Supervisor module where it is processed. If the Supervisor determines that the information included in the update supercedes the information that it has, it updates the VLAN information and creates updated messages to other neighbor Catalysts. The Catalyst uses the VTP configuration revision number to recognize if it has older or current data. The configuration revision number usage is discussed later in this chapter.

When a Catalyst configured in transparent mode receives a VTP update, the Catalyst does not send the frame to the Supervisor. Rather, it locally ignores the frame. If, however, the Catalyst has other trunk links connected, it floods the frame out the other trunk ports. But the VTP message does not change the transparent Catalyst's configuration as it does for a server or client device.

Create VLANs

If you desire to create a VLAN, you must create it on a Catalyst configured in server or transparent mode. These are the only modes authorized to accept set vlan and clear vlan commands. The difference between them, though, is the behavior after you create the VLAN. In the case of the server mode, the Catalyst sends VTP advertisements out all trunk ports to neighbor Catalysts. Transparent mode Catalysts do not issue any type of VTP announcement when a VLAN is created. The new VLAN is only locally significant. If you build an entire network with Catalysts configured in transparent mode, you need to create new VLANs in each and every Catalyst as an individual command. Catalysts in transparent mode do not, for all intents and purposes, participate in VTP. To them, it is as if VTP does not exist. You do not need to assign the transparently configured Catalyst to a VTP domain before you can create any local VLANs. VTP transparent mode switches do not advertise changes or additions made for VLANs on the local switch, but they pass through VLAN additions or changes made elsewhere.

Catalysts configured as clients do not have the authority to create any VLANs. If you associate a client port to a VLAN that it does not know about, the Catalyst generates a message informing you that you must create a VLAN on a server before it can move the ports to the VLAN. If, after assigning the ports to the VLAN, you look at the VLAN status with the show vlans command, you might notice that the ports belong to the new but non-existent VLAN and are in a suspended state preventing the forwarding of frames in the VLAN. When you actually create the VLAN on a server in the same management domain as the client, the client eventually hears about the new VLAN and interprets this as authorization to activate ports in the new VLAN.

Similarly, you cannot delete VLANs in a client, only in a server or transparent device. Deleting a VLAN in a transparent device only affects the local device as opposed to when you delete a VLAN from a server. When deleting a VLAN from a server, you get a warning message from the Catalyst informing you that this action places any ports assigned to the VLAN within the management domain into a suspended mode, as shown in Example 12-5.

Example 12-5 Clearing a VLAN in a Management Domain

   Console> (enable) clear vlan 10   This command will deactivate all ports on vlan 10   in the entire management domain   Do you want to continue(y/n) [n]?y   Vlan 10 deleted   Console> (enable)

Tip

Clearing a VLAN does not cause the ports in the management domain to reassign themselves to the default VLAN 1. Rather, the Catalysts keep the ports assigned to the previous VLAN, but in an inactive state. You need to reassign ports to an active VLAN before the attached devices can communicate again.

Remember VLANs

Whenever you create, delete, or suspend a VLAN in a server or transparent Catalyst, the Catalyst stores the configuration information in NVRAM so that on power up it can recover to the last known VLAN configuration. If the unit is a server, it also transmits configuration information to its Catalyst neighbors.

Clients, on the other hand, do not store VLAN information. When a Catalyst configured in client mode loses power, it forgets about all the VLANs it knew except for VLAN 1, the default VLAN. On power up, the client cannot locally activate any VLANs, except VLAN 1, until it hears from a VTP server authorizing a set of VLANs. Any ports assigned to VLANs other than VLAN 1 remain in a suspended state until they receive a VTP announcement from a server. When the client receives a VTP update from a server, it can then activate any ports assigned to VLANs included in the VTP announcement.

VTP VLAN Distribution Demonstrated

Consider Figure 12-4 to illustrate the differences between a server (Cat-A), client (Cat-C), and transparent (Cat-B) configuration, where one of each is linearly cascaded with a transparent device (Cat-B) in the middle.

Figure 12-4. VLAN Distribution for VTP Modes Server, Client, and Transparent

graphics/12fig04.gif

Table 12-3 shows the starting condition and all subsequent conditions for Catalysts A, B, and C.

Table 12-3. Status for Catalysts in Figure 12-4 Demonstrating Server, Client, and Transparent Mode

Configured VLANs for:

Step #

Event

Cat-A

Server

Cat-B

Transparent

Cat-C

Client

Starting Condition.

Create VLAN 2 in Cat-C.

Assign ports to VLAN 2 in Cat-C.

Create VLAN 2 in Cat-A.

1, 2

Create VLAN 10 in Cat-B.

1, 2

1, 10

1, 2

Lose and restore power on Cat-A and Cat-B.

1, 2

1, 10

1, 2

Lose power on Cat-A and Cat-C. Restore power to Cat-C only.

N/A

1, 10

Restore power on Cat-A.

1, 2

1, 10

1, 2

Create VLAN 20 on all three Catalysts.

1, 2, 20

1, 10, 20

1, 2, 20

In the starting configuration of Step 1, the Catalysts have a VTP domain name assigned to them. In reality, VTP in Cat-B isn't really participating and can be ignored for now. All three Catalysts start with only the default VLAN 1. In Step 2, the administrator starts work on the client and tries to create a new VLAN. But because Cat-C is a client, Cat-C rejects the command, posts an error to the console, and does not create any new VLAN. Only VLAN 1 remains in existence. The administrator assigns ports to VLAN 2 in Step 3 with the set vlan command. Even though VLAN 2 does not exist yet, Cat-C accepts the port assignment, moves ports to VLAN 2, and places them in the suspend state. However, Cat-C only knows about VLAN 1.

In Step 4, the administrator moves to Cat-A, a server, and creates VLAN 2 which then gets propagated to its neighbor, Cat-B. But Cat-B, configured in transparent mode, ignores the VTP announcement. It does not add VLAN 2 to its local VLAN configuration. Cat-B floods the VTP announcement out any other trunk ports to neighbor Catalysts. In this case, Cat-C receives the VTP update, checks the VTP management domain name, which matches, and adds VLAN 2 to its local list. Cat-C then activates any ports assigned to VLAN 2. Any devices attached to ports in VLAN 2 on Cat-A now belong to the same broadcast domain as ports assigned to VLAN 2 on Cat-C. If Layer 3 permits, these devices can now communicate with each other.

The administrator now moves (or Telnets) to Cat-B in Step 5 and creates a new broadcast domain, VLAN 10. As a Catalyst configured in transparent mode, the Catalyst is authorized to create VLAN 10. But Cat-B does not propagate any information about VLAN 10 to the other Catalysts. VLAN 10 remains local to Cat-B and is not a global VLAN.

A disaster occurs in Step 6 when the facility loses power to Cat-A and Cat-B. But, because you are a savvy network engineer, you configured them in server and transparent modes so they can remember their VLAN configuration information. Although Cat-A and Cat-B remain without power, Cat-C continues to operate based upon the last VLAN configuration it knew. All ports on Cat-C remain operational in their assigned VLANs. When power is restored to Cat-A and Cat-B, both Catalysts remember their authorized VLANs and enable them. Cat-A also issues VTP messages to neighbors. This does not affect the operations of Cat-B or Cat-C, though, because they both remember their configuration.

Now consider what happens if Cat-A and Cat-C lose power. In Step 7, this occurs, but power is restored to Cat-C before Cat-A. When Cat-C recovers, it starts with only VLAN 1 authorized. Ports in any other VLAN are disabled until Cat-C hears a VTP message from a server. If Cat-A takes one hour to recover, Cat-C remains in this state the entire time. When Cat-A finally restarts in Step 8, it sends VTP messages that then authorize Cat-C to enable any ports in VLANs included in the VTP announcement.

Finally, the administrator creates another VLAN for the entire management domain. In Step 9, the administrator creates VLAN 20. But this takes two configuration statements. The administrator must create the VLAN in Cat-A and in Cat-B. Now there are two global VLANs in the domain. Any devices in VLAN 20 belong to the same broadcast domain, regardless of which Catalyst they connect to. VLAN 1 is the other global broadcast domain. Any devices in VLAN 1 can also communicate with each other. But, devices in VLAN 1 cannot communicate with devices in VLAN 20 unless there is a router in the network.