Chapter 7. VLAN Trunking and Configuration
This chapter covers the following exam topics:
2.3. Describe switching concepts and perform basic configuration
2.3.a. STP
2.4.b. 802.1q
2.3.c. Port channels
As you learned in Chapter 6, “VLAN and Trunking Concepts,” VLANs are a way for us to segment different networks and decrease the size of our broadcast and collision domains. This chapter delves into how to enable VLANs from a configuration perspective on our Nexus data center switches.
This chapter examines the configuration of VLANs. The major section of the chapter explains how to configure VLANs and VLAN trunks as well as how to statically assign interfaces to a VLAN. This chapter also provides detailed information about VLAN Trunking Protocol (VTP) configuration and verification.
Note
As mentioned in the Introduction’s section “For Those Studying Routing & Switching,” we suggest reading this entire chapter. Although the ICND1 100-101 Official Cert Guide also discusses VLAN and VLAN trunking configuration, and the NX-OS commands are often identical or similar, this chapter includes enough differences that it is worth your time to read and review it in full.
“Do I Know This Already?” Quiz
Use the “Do I Know This Already?” quiz to help decide whether you might want to skim this chapter, or a major section, moving more quickly to the “Exam Preparation Tasks” section near the end of the chapter. Table 7-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. For thorough explanations, see Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
1. Imagine that on Switch 1 you are told to configure port Ethernet 1/1 to participate in VLAN 10. Which commands would enable interface Ethernet 1/1 to participate in VLAN 10? (Choose two answers.)
a. switchport mode trunk
b. switchport access vlan 10
c. no shutdown
d. access vlan 10
e. vlan 10 access
2. A Nexus switch has just arrived from Cisco. The switch has never been configured with any VLANs, but VTP has been disabled. An engineer gets into configuration mode and issues the vlan 22 command, followed by the name Evans-VLAN command. Which of the following are true? (Choose two answers.)
a. VLAN 22 is listed in the output of the show vlan brief command.
b. VLAN 22 is listed in the output of the show running-config command.
c. VLAN 22 is not created by this process.
d. VLAN 22 does not exist in that switch until at least one interface is assigned to that VLAN.
3. Which of the following commands identify switch interfaces as being trunking interfaces—interfaces that currently operate as VLAN trunks? (Choose two answers.)
a. show interface
b. show interface switchport
c. show interface trunk
d. show trunks
4. Imagine that you are told that switch 1 is configured with the switchport mode trunk parameter for trunking on its Eth1/5 interface, which is connected to switch 2. You have to configure switch 2. Which of the following settings for trunking could allow trunking to work? (Choose two answers.)
a. switchport mode trunk
b. shutdown
c. no shutdown
d. access
e. None of the answers are correct.
5. A Nexus switch has just arrived from Cisco. The switch has never been configured. An engineer would like to configure VLAN Trunking Protocol (VTP) in client mode. Which commands would he enter in configuration mode to do this? (Choose two answers.)
a. feature vtp
b. vlan 33 mode client
c. vtp client
d. vtp mode client
Foundation Topics
Cisco Nexus switches require minimal configuration to work, as you have seen in the previous chapters. When you purchase a Cisco Nexus switch, install devices with the correct cabling, and turn on the switch, the switch defaults all the interfaces into a single VLAN, known as VLAN 1. You would never need to configure the switch with any more details than the base configuration if all devices were in a single VLAN 1, and it would work fine until you needed more than one VLAN. But if you want to use VLANs—and most every enterprise network does—you need to make some configurations.
This chapter separates the VLAN configuration details into three major sections:
The first looks at how to configure access interfaces—interfaces used for host connections generally.
The second part shows how to configure interfaces that do use VLAN trunking between multiple switches to extend VLANs beyond a single switch.
The third describes the VLAN Trunking Protocol (VTP), which is a Layer 2 messaging protocol used to distribute the VLAN information between multiple switches.
VLAN Configuration and Verification
This section provides an overview of VLAN support on Nexus switches, including guidelines for VLAN numbering, creating VLANs, assigning access VLANs to an interface, and two VLAN configuration examples.
VLAN Guidelines for Cisco Nexus Switches
Cisco Nexus switches support 4094 VLANs, by default; however, VLANs 3968–4094 are considered reserved for system use. When you are creating VLANs on Nexus switches, it is important not to use one in this reserved range. Table 7-2 outlines some other considerations that are important to note when creating or configuring VLANs on a Nexus switch.
Creating VLANs and Assigning Access VLANs to an Interface
This section shows how to create a VLAN, give the VLAN a name, and assign interfaces to the VLAN. To focus on these basic details, this section shows examples using a single switch, so VLAN trunking is not needed.
For a Cisco Nexus switch to forward frames in a particular VLAN, the switch must be configured to believe that the VLAN exists. In addition, the switch must have nontrunking interfaces (called access interfaces) assigned to the VLAN, and/or trunks that support the VLAN. The configuration steps for access interfaces are as follows, with the trunk configuration shown later in the section “VLAN Trunking Configuration and Verification”:
Step 1. To configure a new VLAN, follow these steps:
A. From configuration mode, use the vlan vlan-id global configuration command to create the VLAN and to move the user into VLAN configuration mode.
B. (Optional) Use the name name VLAN subcommand to assign a name for the VLAN. If not configured, the VLAN name is VLANZZZZ, where ZZZZ is the four-digit decimal VLAN ID.
Step 2. For each access interface (each interface that does not trunk, but instead belongs to a single VLAN), follow these steps:
A. Use the interface command to move into interface configuration mode for each desired interface.
B. Use the switchport access vlan id-number interface subcommand to specify the VLAN number associated with that interface.
C. (Optional) To disable trunking on that same interface, so that the interface does not negotiate to become a trunk, use the switchport mode access interface subcommand.
While the list might look a little daunting, the process on a single switch is actually pretty simple. For example, if you want to put the switch’s ports in three VLANs—11, 12, and 13—you just add three vlan commands: vlan 11, vlan 12, and vlan 13. Then, for each interface, add a switchport access vlan 11 (or 12 or 13) command to assign that interface to the proper VLAN.
VLAN Configuration Example 1: Full VLAN Configuration
Example 7-1 shows the configuration process of adding a new VLAN and assigning access interfaces to that VLAN. Figure 7-1 shows the network used in the example, with one LAN switch (SW1) and two hosts in each of three VLANs (1, 2, and 3). The example shows the details of the two-step process for VLAN 2 and the interfaces in VLAN 2. The configuration of VLAN 3 is deferred until the next example.
Example 7-1 Configuring VLANs and Assigning VLANs to Interfaces
SW1# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Eth1/1, Eth1/2, Eth1/3, Eth1/4
Eth1/5, Eth1/6, Eth1/7, Eth1/8
Eth1/9, Eth1/10, Eth1/11, Eth1/12
Eth1/13, Eth1/14, Eth1/15, Eth1/16
Eth1/17, Eth1/18, Eth1/19, Eth1/20
Eth1/21, Eth1/22, Eth1/23, Eth1/24
Eth1/25, Eth1/26, Eth1/27, Eth1/28,
Eth1/29, Eth1/30, Eth1/31, Eth1/32
! Above, VLANs 2 and 3 do not yet exist. Below, VLAN 2 is added, with name Freds-vlan,
! with two interfaces assigned to VLAN 2.
SW1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)# vlan 2
SW1(config-vlan)# name Freds-vlan
SW1(config-vlan)# exit
SW1(config)# interface Ethernet 1/13 - 14
SW1(config-if)# switchport access vlan 2
SW1(config-if)# end
! Below, the show running-config command lists the interface subcommands on
! interfaces Eth1/13 and Eth1/14.
SW1# show running-config
! Many lines omitted for brevity
! Early in the output:
vlan 2
name Freds-vlan
!
! more lines omitted for brevity
interface Ethernet1/13
switchport access vlan 2
switchport mode access
!
interface Ethernet1/14
switchport access vlan 2
switchport mode access
!
SW1# show vlan brief
VLAN Name Status Ports
---- ---------------------- --------- -------------------------------
1 default active Eth1/1, Eth1/2, Eth1/3, Eth1/4
Eth1/5, Eth1/6, Eth1/7, Eth1/8
Eth1/9, Eth1/10, Eth1/11, Eth1/12
Eth1/15, Eth1/16, Eth1/17, Eth1/18
Eth1/19, Eth1/20, Eth1/21, Eth1/22
Eth1/23, Eth1/24, Eth1/25, Eth1/26,
Eth1/27, Eth1/28, Eth1/29, Eth1/30,
Eth1/31, Eth1/32
2 Freds-vlan active Eth1/13, Eth1/14
SW1# show vlan id 2
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
2 Freds-vlan active Eth1/13, Eth1/14
VLAN Type Vlan-mode
---- ----- ----------
2 enet CE
After the configuration has been added, to list the new VLAN, the example repeats the show vlan brief command (highlighted in gray). Note that this command lists VLAN 2, named Freds-vlan, and the interfaces assigned to that VLAN (Eth1/13 and Eth1/14).
The example surrounding Figure 7-1 uses six switch ports, all of which need to operate as access ports. That is, each port should not use trunking, but instead should be assigned to a single VLAN, as assigned by the switchport access vlan vlan-id command.
For ports that should always act as access ports, add the optional interface subcommand switchport mode access. This command tells the switch to only allow the interface to be an access interface. The upcoming section “VLAN Trunking Configuration and Verification” discusses more details about the commands that allow a port to negotiate whether it should use trunking.
VLAN Configuration Example 2: Shorter VLAN Configuration
Example 7-1 showed several of the optional configuration commands, with a side effect of being a bit longer than is required. Example 7-2 shows a much briefer alternative configuration, picking up the story where Example 7-1 ended and showing the addition of VLAN 3 (refer to Figure 7-1). Note that SW1 does not know about VLAN 3 at the beginning of this example.
Example 7-2 Shorter VLAN Configuration Example (VLAN 3)
SW1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)# interface Ethernet 1/15 - 16
SW1(config-if-range)# switchport access vlan 3
% Access VLAN does not exist. Creating vlan 3
SW1(config-if-range)# ^Z
SW1# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Eth1/1, Eth1/2, Eth1/3, Eth1/4
Eth1/5, Eth1/6, Eth1/7, Eth1/8
Eth1/9, Eth1/10, Eth1/11, Eth1/12
Eth1/17, Eth1/18, Eth1/19, Eth1/20
Eth1/21, Eth1/22, Eth1/23, Eth1/24
Eth1/25, Eth1/26, Eth1/27, Eth1/28,
Eth1/29, Eth1/30, Eth1/31, Eth1/32
2 Freds-vlan active Eth1/13, Eth1/14
3 VLAN0003 active Eth1/15, Eth1/16
Example 7-2 shows how a switch can dynamically create a VLAN—the equivalent of the vlan vlan-id global config command—when the switchport access vlan interface subcommand refers to a currently unconfigured VLAN. This example begins with SW1 not knowing about VLAN 3. When the switchport access vlan 3 interface subcommand was used, the switch realized that VLAN 3 did not exist, and as noted in the shaded message in the example, the switch created VLAN 3, using a default name (VLAN0003). No other steps are required to create the VLAN. At the end of the process, VLAN 3 exists in the switch, and interfaces Eth1/15 and Eth1/16 are in VLAN 3, as noted in the shaded part of the show vlan brief command output.
VLAN Trunking Configuration and Verification
So far, we have discussed configuring a single switch with multiple VLANs. The next step is to see how we can extend a single VLAN or multiple VLANs between multiple switches using VLAN trunking. Trunking configuration between two Cisco switches can be very simple if you just statically configure trunking. NX-OS trunking requires only some straightforward configuration. Because Cisco Nexus switches support only the more modern trunking option (802.1Q), NX-OS does not need a configuration command to define the type of trunking. You could literally add one interface subcommand for the switch interface on each side of the link (switchport mode trunk), and you would create a VLAN trunk that supports all the VLANs known to each switch.
Note
Some IOS switches support DOT1Q and the ISL trunking encapsulation methodology; they can be configured using the switchport trunk encapsulation command. Because NX-OS only supports the standards-based DOT1Q trunking encapsulation, this command is not available in NX-OS.
However, trunking configuration on Cisco Nexus switches includes many more options, including several options for what VLANs can be carried across the trunk as well as whether the trunk will be going to an end host such as a virtualized server that might need VLANs trunked down to it or to another switch.
Cisco Nexus switches support only 802.1Q trunking, as previously mentioned, and so in the configurations of a Cisco Nexus switch, there is no encapsulation command, only a mode trunk command to enable 802.1Q trunking. It’s important to note this difference from other switches where we would have to configure the trunking encapsulation methodology like with Cisco Catalyst switches. Table 7-3 references the two switchport administrative mode commands available in Cisco Nexus switches.
Note
This note is for you CCNA R&S folks: Unlike IOS on Catalyst switches, NX-OS does not dynamically negotiate whether to trunk. As a result, the NX-OS switchport trunk command does not have options that tell the Nexus switch to negotiate the trunking state.
For example, consider the two switches shown in Figure 7-2. This figure shows an expansion of the network of Figure 7-1, with a trunk to a new switch (SW2) and with parts of VLANs 1 and 3 on ports attached to SW2. The two switches use Ethernet link for the trunk. In this case, the trunk has been enabled because both Cisco Nexus switches default to an administrative mode of access, meaning that neither switch initiates the trunk negotiation process. By changing both switches to use trunk mode, which does initiate the negotiation, the switches negotiate to use trunking, specifically 802.1Q, because the 5548s support only 802.1Q. This is done on interface Ethernet 1/1 in Figure 7-2.
Example 7-3 show the basic configuration of setting up a trunk on interface Ethernet 1/1 based on Figure 7-2.
Example 7-3 Trunk Configuration and Verification
SW1# show running-config interface Ethernet 1/1
--some lines omitted--
interface Ethernet 1/1
switchport mode trunk
SW1# show interface Ethernet 1/1 switchport
Name: Ethernet 1/1
Switchport: Enabled
Switchport Monitor: Not enabled
Operational Mode: trunk
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Allowed: 1-4094
Voice VLAN: none
Extended Trust State : not trusted [COS = 0]
Administrative private-vlan primary host-association: none
Administrative private-vlan secondary host-association: none
Administrative private-vlan primary mapping: none
Administrative private-vlan secondary mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
As you can see in the output of Example 7-3, the configuration is pretty simple: We get into interface configuration mode and use the command switchport mode trunk under Ethernet 1/1. This command will enable trunking on Ethernet 1/1 for all VLANs enabled on SW1 to traverse this link. You verify this using the show interface Ethernet 1/1 switchport command to look at the interface’s trunking characteristics. By looking at the output of this command, you see a couple of key things to note:
The operational mode is trunk.
That the switch is trunking with a native VLAN of 1 (more on native VLAN in the note that follows).
If you use only the switchport mode trunk command, the switch, by default, will send all or allow any and all VLANs that have been configured on the switch. You see in the output highlighted in gray that the allowed VLANs are 1–4094, which means that all are allowed.
Note
Native VLAN is by default 1 on all Cisco switches, including Nexus. Native VLAN frames are not encapsulated with any method and are known as untagged, which means that any host on this VLAN can see these frames. Cisco Discovery Protocol (CDP), VTP, and other types of control plane messaging are always sent on the native VLAN 1 by default. You can configure the native VLAN as another VLAN if you want, and in this case, all the frames would be untagged. If you do change the native from its default of 1, it is best practice to do so on other switches as well.
Controlling Which VLANs Can Be Supported on a Trunk
Now that you know how to configure an interface to trunk VLANs from one switch to another, it is important to understand how to control which VLANs are allowed between them. The allowed VLAN list feature provides a mechanism for engineers to administratively disable a VLAN from a trunk. By default, switches include all possible VLANs (1–4094) in each trunk’s allowed VLAN list. However, the engineer can then limit the VLANs allowed on the trunk by using the following interface subcommand:
switchport trunk allowed vlan {add | all | except | remove|none} vlan-list
This command provides a way to easily add and remove VLANs from the list. For example, the add option permits the switch to add VLANs to the existing allowed VLAN list, and the remove option permits the switch to remove VLANs from the existing list. The all option means all VLANs, so you can use it to reset the switch to its original default setting (permitting VLANs 1–4094 on the trunk). The except option is rather tricky; it adds all VLANs to the list that are not part of the command. For example, the switchport trunk allowed vlan except 100-200 interface subcommand adds VLANs 1 through 99 and 201 through 4094 to the existing allowed VLAN list on that trunk.
In addition to the allowed VLAN list, a switch has other reasons to prevent a particular VLAN’s traffic from crossing a trunk. All five reasons are summarized in the following list:
A VLAN has been removed from the trunk’s allowed VLAN list.
A VLAN does not exist in the switch’s configuration (as seen with the show vlan command).
A VLAN does exist, but has been administratively disabled (shutdown).
A VLAN has been automatically pruned by VTP. (VTP is discussed later in this chapter.)
A VLAN’s STP instance has placed the trunk interface into a blocking state.
This section has already discussed the first reason (the allowed VLAN list), so let’s consider the next two reasons in the list. If a switch does not know that a VLAN exists—for example, if the switch does not have a vlan vlan-id command configured, as confirmed by the output of the show vlan command—the switch will not forward frames in that VLAN over any interface. In addition, a VLAN can exist in a switch’s configuration, but also be administratively shut down either by using the shutdown vlan vlan-id global configuration command or by using the shutdown command in VLAN configuration mode. When disabled, a switch will no longer forward frames in that VLAN, even over trunks. So, switches do not forward frames in nonexistent VLANs or a shutdown VLAN over any of the switch’s trunks.
This book has a motive for listing the reasons for limiting VLANs on a trunk: The show interface trunk command lists VLAN ID ranges as well, based on these same reasons. This command includes a progression of three lists of the VLANs supported over a trunk. These three lists are as follows:
VLANs allowed on the trunk (1–4094, by default)
VLANs from the first group that are also in an RSTP forwarding state
VLANs from the second group that are not VTP pruned and not STP blocked
To get an idea of these three lists inside the output of the show interfaces trunk command, Example 7-4 shows how VLANs might be disallowed on a trunk for various reasons. The command output is taken from SW1 in Figure 7-2, after the completion of the configuration, as shown in all the earlier examples in this chapter. In other words, VLANs 1 through 3 exist in SW1’s configuration and are not shut down. Trunking is operational between SW1 and SW2. Then, during the example, the following items are configured on SW1:
Step 1. VLAN 4 is configured.
Step 2. VLAN 2 is shut down, which causes RSTP to use a disabled state for all ports in VLAN 2.
Step 3. VLAN 3 is removed from the trunk’s allowed VLAN list.
Example 7-4 Allowed VLAN List and the List of Active VLANs
! The three lists of VLANs in the next command list allowed VLANs (1-4094),
! Allowed and active VLANs (1-3), and allowed/active/not pruned/STP forwarding
! VLANs (1-3)
SW1# show interfaces trunk
--------------------------------------------------------------------------------
Port Native Status Port
Vlan Channel
--------------------------------------------------------------------------------
Eth1/1 1 trunking -
--------------------------------------------------------------------------------
Port Vlans Allowed on Trunk
--------------------------------------------------------------------------------
Eth1/1 1-4094
--------------------------------------------------------------------------------
Port Vlans Err-disabled on Trunk
--------------------------------------------------------------------------------
Eth1/1 none
--------------------------------------------------------------------------------
Port STP Forwarding
--------------------------------------------------------------------------------
Eth1/1 1-3
--------------------------------------------------------------------------------
Port Vlans in spanning tree forwarding state and not pruned
--------------------------------------------------------------------------------
Eth1/1 1-3
--Some Lines Omitted for Brevity--
! Next, the switch is configured with new VLAN 4; VLAN 2 is shutdown;
! and VLAN 3 is removed from the allowed VLAN list on the trunk.
SW1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)# vlan 4
SW1(config-vlan)# vlan 2
SW1(config-vlan)# shutdown
SW1(config-vlan)# interface Eth1/1
SW1(config-if)# switchport trunk allowed vlan remove 3
SW1(config-if)# ^Z
! The three lists of VLANs in the next command list allowed VLANs (1-2, 4-4094),
! allowed and active VLANs (1,4), and allowed/active/not pruned/STP forwarding
! VLANs (1,4)
SW1# show interfaces trunk
--------------------------------------------------------------------------------
Port Native Status Port
Vlan
Channel
--------------------------------------------------------------------------------
Eth1/1 1 trunking -
! VLAN 3 is omitted next, because it was removed from the allowed VLAN list.
--------------------------------------------------------------------------------
Port Vlans Allowed on Trunk
--------------------------------------------------------------------------------
Eth1/1 1-2,4-4094
--------------------------------------------------------------------------------
Port Vlans Err-disabled on Trunk
--------------------------------------------------------------------------------
Eth1/1 none
! Since VLAN 2 is shutdown, RSTP considers all ports to be in a disabled state, so the
! switch omits VLAN 2 from the "STP Forwarding" List. VLANs 5-4094 are omitted below
! because SW1 does not have them configured.
--------------------------------------------------------------------------------
Port STP Forwarding
--------------------------------------------------------------------------------
Eth1/1 1,4
--------------------------------------------------------------------------------
Port Vlans in spanning tree forwarding state and not pruned
--------------------------------------------------------------------------------
Eth1/1 1,4
--Some Lines Omitted for Brevity--
VTP Configuration and Verification
Now that you know how to enable and control the extension of VLANs between switches, let’s explore a tool created to help ease the pain of configuring VLANs across every switch of your data center; this older Cisco protocol and tool is called the VLAN Trunking Protocol (VTP). VTP is a Cisco proprietary tool on Cisco switches that advertises each VLAN configured in one switch (with the vlan number command) so that all the other switches learn about that VLAN. However, for various reasons, many enterprises choose not to use VTP. If you do choose to use VTP, we want you to understand how to utilize it best for your data center, so we explore what it is and how to use it with your Cisco Nexus switches.
VTP is a Layer 2 messaging protocol that maintains VLAN consistency by managing the addition, deletion, and renaming of VLANs within a VTP domain. A VTP domain is made up of one or more network devices that share the same VTP domain name and that are connected with trunk interfaces. Each network device can be in only one VTP domain. Figure 7-3 shows how VTP is used in a switch network.
Enabling VTP
VTP is disabled by default on the device. You can enable and configure VTP using the command-line interface (CLI). When VTP is disabled, the device does not relay any VTP protocol packets. To enable VTP on a Nexus switch, use the command feature vtp. By default, the switch will then be in VTP server mode. Example 7-5 shows the enabling and verification of VTP.
Example 7-5 VTP Enablement and Verification
SW1# show vtp
% Invalid command at '^' marker.
SW1# configure terminal
SW1(config)# feature vtp
SW1(config)# show vtp status
VTP Status Information
----------------------
VTP Version : 2 (capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 3
VTP Operating Mode : Server
VTP Domain Name : <VTP domain not acquired/configured yet>
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 Digest : 0xB2 0xCC 0x45 0x18 0x7F 0x01 0xCD 0xD7
Configuration last modified by 10.0.128.203 at 0-0-00 00:00:00
Local updater ID is 10.0.128.203
VTP version running : 1
As you can see in the output of Example 7-5, VTP is disabled by default, so there are no associated VTP commands available to you to verify its configuration. To enable VTP, you must use the command feature vtp. After enabling VTP, you can see the default settings by using the show vtp status command. You can see in the output that by default you are in server mode and currently running in version 1. Let’s look at some of the differences between version 2 and version 1 of VTP.
Note
A newer version of VTP (VTP version 3) is currently supported in some of the Cisco Nexus Switches platform. Here are the major benefits of VTPv3:
VTPv3 creates a new mechanism to reduce unintended changes to the database, by introducing the concept of a “primary server.” The primary server is the only device that is allowed to update other devices.
VTPv3 adds support to the entire spectrum of VLANs defined in 802.1Q 1–4095. It also adds support for private VLANs (PVANs).
VTPv3 adds support for the MST database.
VTP maintains a list of trunk ports in the Spanning Tree Protocol (STP) forwarding state by querying STP at boot and listening to the notifications it generates. VTP sets a trunk port to the pruned or joined state by interacting with STP. STP notifies VTP when a trunk port goes to the blocking or forwarding state. VTP notifies STP when a trunk port becomes pruned or joined.
VTP Version 2 supports the following features not supported in VTP Version 1:
Token Ring support: VTP Version 2 supports Token Ring LAN switching and VLANs.
Unrecognized Type-Length-Value (TLV) support: A VTP server or client propagates configuration changes to its other trunks, even for TLVs that it is not able to parse. The unrecognized TLV is saved in NVRAM.
Version-dependent transparent mode: In VTP Version 1, a VTP transparent network device inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Because only one domain is supported, VTP Version 2 forwards VTP messages in transparent mode without checking the version.
Consistency checks: In VTP Version 2, VLAN consistency checks (such as VLAN names and values) are performed only when you enter new information through the CLI or SNMP. Consistency checks are not performed when new information is obtained from a VTP message or when information is read from NVRAM. If the digest on a received VTP message is correct, its information is accepted without consistency checks.
Each switch can use one of three VTP modes: server, client, or transparent (mentioned earlier). Switches use either VTP server or client mode when the switch wants to use VTP for its intended purpose of dynamically advertising VLAN configuration information. Figure 7-4 describes each mode and its properties.
It is always a best practice to configure a domain and password pair for your VTP environment to protect against rogue devices attaching to the network with the same domain name and a higher revision number, which would rewrite the VLANs already distributed with whatever was configured on the switch. Example 7-6 shows how to change the domain and password for your VTP environment. Also, you can configure the switch to use VTP Version 1 or 2. By default, it runs in Version 1.
Example 7-6 VTP Version, Domain, and Password Configuration
SW1# configure terminal
SW1(config)# vtp domain Tyler
SW1(config)# vtp password Evan
SW1(config)# vtp version 2
SW1(config)# show vtp status
VTP Status Information
----------------------
VTP Version : 2 (capable)
Configuration Revision : 1
Maximum VLANs supported locally : 1005
Number of existing VLANs : 3
VTP Operating Mode : Server
VTP Domain Name : Tyler
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP V2 Mode : Enabled
VTP Traps Generation : Disabled
MD5 Digest : 0x46 0xE0 0x71 0x5A 0x6E 0x2D 0x2C 0x4B
Configuration last modified by 10.0.128.203 at 6-9-14 23:13:21
Local updater ID is 10.0.128.203
VTP version running : 2
Limiting VTP Using Pruning
Because you now have a tool to distribute the VLANs across multiple different switches, you also need a tool to control and minimize the risks associated with doing so. This tool is VTP pruning. VTP pruning optimizes the usage of network bandwidth by restricting the flooded traffic to only those trunk ports that can reach all the active network devices. When this protocol is in use, a trunk port does not receive the flooded traffic that is meant for a certain VLAN unless an appropriate join message is received. Figure 7-5 demonstrates how VTP pruning works.
VTP pruning, as shown in Figure 7-5, is a way to determine which VLANs are present and being used on a particular switch (have active hosts). If an active host is not present, you can prune the VLANs off of the trunk links to avoid these switches from having to process flooded traffic from any unused VLANs. This helps from both a bandwidth and CPU perspective. To enable VTP pruning, use the vtp pruning command in global configuration mode.
Note
VTP pruning is a way to use VTP to determine whether VLANs are active and then remove them if needed. Another and more popular way of doing this is by using the switchport trunk allowed vlan command. Using the allowed VLAN solution hard-codes what VLANs are allowed on a trunk link and in turn does not send flooded traffic on a trunk for VLANs that are not allowed. VTP pruning is currently supported only on Nexus 7000s.
Exam Preparation Tasks
Review All Key Topics
Review the most important topics from this chapter, noted with the Key Topic icon in the outer margin of the page. Table 7-4 lists a reference for these key topics and the page number on which each is found.
Command Reference to Check Your Memory
Although you should not necessarily memorize the information in Tables 7-5 and 7-6, this section does include a reference for the configuration and EXEC commands covered in this chapter. Practically speaking, you should memorize the commands as a side effect of reading the chapter and doing all the activities in this exam preparation section. To check and see how well you have memorized the commands as a side effect of your other studies, cover the left side of the table with a piece of paper, read the descriptions in the right side, and see whether you remember the command.
Table 7-5 Chapter 7 Configuration Command Reference
Table 7-6 Chapter 7 EXEC Command Reference