VLAN Document
VLAN Document
VLAN Document
Table 1-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
1. In a LAN, which of the following terms best equates to the term VLAN?
a. Collision domain
b. Broadcast domain
c. Subnet
d. Single switch
e. Trunk
2. Imagine a switch with three configured VLANs. How many IP subnets are required, assuming
that all hosts in all VLANs want to use TCP/IP?
a. 0
b. 1
c. 2
d. 3
e. You cannot tell from the information provided.
3. Switch SW1 sends a frame to switch SW2 using 802.1Q trunking. Which of the answers
describes how SW1 changes or adds to the Ethernet frame before forwarding the frame to
SW2?
a. Inserts a 4-byte header and does change the MAC addresses
b. Inserts a 4-byte header and does not change the MAC addresses
c. Encapsulates the original frame behind an entirely new Ethernet header
d. None of the other answers are correct.
4. Imagine that you are told that switch 1 is configured with the dynamic auto parameter for
trunking on its Fa0/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. on
b. dynamic auto
c. dynamic desirable
d. access
5. A 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 Hannahs-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.
6. Which of the following commands identify switch interfaces as being trunking interfaces:
interfaces that currently operate as VLAN trunks? (Choose two answers.)
a. show interfaces
b. show interfaces switchport
c. show interfaces trunk
d. show trunks
Foundation Topics
Figure 1-1 Creating Two Broadcast Domains with Two Physical Switches and No VLANs
With support for VLANs, a single switch can accomplish the same goals of the design in Figure 1-1—
to create two broadcast domains—with a single switch. With VLANs, a switch can configure some
interfaces into one broadcast domain and some into another, creating multiple broadcast domains.
These individual broadcast domains created by the switch are called virtual LANs (VLAN).
For example, in Figure 1-2, the single switch creates two VLANs, treating the ports in each VLAN as
being completely separate. The switch would never forward a frame sent by Dino (in VLAN 1) over
to either Wilma or Betty (in VLAN 2).
Figure 1-2 Creating Two Broadcast Domains Using One Switch and VLANs
Designing campus LANs to use more VLANs, each with a smaller number of devices, often helps
improve the LAN in many ways. For example, a broadcast sent by one host in a VLAN will be
received and processed by all the other hosts in the VLAN—but not by hosts in a different VLAN.
Limiting the number of hosts that receive a single broadcast frame reduces the number of hosts that
waste effort processing unneeded broadcasts. It also reduces security risks, because fewer hosts see
frames sent by any one host. These are just a few reasons for separating hosts into different VLANs.
The following list summarizes the most common reasons for choosing to create smaller broadcast
domains (VLANs):
To reduce CPU overhead on each device by reducing the number of devices that receive each
broadcast frame
To reduce security risks by reducing the number of hosts that receive copies of frames that the
switches flood (broadcasts, multicasts, and unknown unicasts)
To improve security for hosts that send sensitive data by keeping those hosts on a separate
VLAN
To create more flexible designs that group users by department, or by groups that work together,
instead of by physical location
To solve problems more quickly, because the failure domain for many problems is the same set
of devices as those in the same broadcast domain
To reduce the workload for the Spanning Tree Protocol (STP) by limiting a VLAN to a single
access switch
This chapter does not examine all the reasons for VLANs in more depth. However, know that most
enterprise networks use VLANs quite a bit. The rest of this chapter looks closely at the mechanics of
how VLANs work across multiple Cisco switches, including the required configuration. To that end,
the next section examines VLAN trunking, a feature required when installing a VLAN that exists on
more than one LAN switch.
Figure 1-7 Layer 2 Switch Does Not Route Between the VLANs
Note
The figure refers to subnets somewhat generally, like “subnet 10,” just so the subnet
numbers do not distract. Also, note that the subnet numbers do not have to be the same
number as the VLAN numbers.
Figure 1-7 shows the switch as if it were two switches broken in two to emphasize the point that
Layer 2 switches will not forward data between two VLANs. When configured with some ports in
VLAN 10 and others in VLAN 20, the switch acts like two separate switches in which it will forward
traffic. In fact, one goal of VLANs is to separate traffic in one VLAN from another, preventing frames
in one VLAN from leaking over to other VLANs. For example, when Dino (in VLAN 10) sends any
Ethernet frame, if SW1 is a Layer 2 switch, that switch will not forward the frame to the PCs on the
right in VLAN 20.
The network as a whole needs to support traffic flowing into and out of each VLAN, even though the
Layer 2 switch does not forward frames outside a VLAN. The job of forwarding data into and out of a
VLAN falls to routers. Instead of switching Layer 2 Ethernet frames between the two VLANs, the
network must route Layer 3 packets between the two subnets.
That previous paragraph has some very specific wording related to Layers 2 and 3, so take a moment
to reread and reconsider it for a moment. The Layer 2 logic does not let the Layer 2 switch forward
the Layer 2 protocol data unit (L2PDU), the Ethernet frame, between VLANs. However, routers can
route Layer 3 PDUs (L3PDU), packets, between subnets as their normal job in life.
For example, Figure 1-8 shows a router that can route packets between subnets 10 and 20. The figure
shows the same Layer 2 switch as shown in Figure 1-7, with the same perspective of the switch being
split into parts with two different VLANs, and with the same PCs in the same VLANs and subnets.
Now Router R1 has one LAN physical interface connected to the switch and assigned to VLAN 10,
and a second physical interface connected to the switch and assigned to VLAN 20. With an interface
connected to each subnet, the Layer 2 switch can keep doing its job—forwarding frames inside a
VLAN, while the router can do its job—routing IP packets between the subnets.
Note
Because the router has a single physical link connected to the LAN switch, this design is
sometimes called a router-on-a-stick.
As a brief aside about terminology, many people describe the concept in Figures 1-8 and 1-9 as
“routing packets between VLANs.” You can use that phrase, and people know what you mean.
However, note that this phrase is not literally true, because it refers to routing packets (a Layer 3
concept) and VLANs (a Layer 2 concept). It just takes fewer words to say something like “routing
between VLANs” rather than the literally true but long “routing Layer 3 packets between Layer 3
subnets, with those subnets each mapping to a Layer 2 VLAN.”
Figure 1-10 Multilayer Switch: Layer 2 Switching with Layer 3 Routing in One Device
This chapter introduces the core concepts of routing IP packets between VLANs (or more accurately,
between the subnets on the VLANs). Chapter 19, “IPv4 Routing in the LAN,” shows how to configure
designs that use an external router with router-on-a-stick. This chapter now turns its attention to
configuration and verification tasks for VLANs and VLAN trunks.
Note
The term default VLAN (as shown in the exam topics) refers to the default setting on the
switchport access vlan vlan-id command, and that default is VLAN ID 1. In other
words, by default, each port is assigned to access VLAN 1.
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
2 enet 100010 1500 - - - - - 0 0
The example begins with the show vlan brief command, confirming the default settings of five
nondeletable VLANs, with all interfaces assigned to VLAN 1. (VLAN 1 cannot be deleted, but can be
used. VLANs 1002–1005 cannot be deleted and cannot be used as access VLANs today.) In
particular, note that this 2960 switch has 24 Fast Ethernet ports (Fa0/1–Fa0/24) and two Gigabit
Ethernet ports (Gi0/1 and Gi0/2), all of which are listed as being in VLAN 1 per that first command’s
output.
Next, the example shows the process of creating VLAN 2 and assigning interfaces Fa0/13 and Fa0/14
to VLAN 2. Note in particular that the example uses the interface range command, which causes the
switchport access vlan 2 interface subcommand to be applied to both interfaces in the range, as
confirmed in the show running-config command output at the end of the example.
After the configuration has been added, to list the new VLAN, the example repeats the show vlan
brief command. Note that this command lists VLAN 2, name Freds-vlan, and the interfaces assigned
to that VLAN (Fa0/13 and Fa0/14). The show vlan id 2 command that follows then confirms that
ports Fa0/13 and Fa0/14 are assigned to VLAN 2.
The example surrounding Figure 1-11 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. However, as configured in Example 1-1,
these interfaces could negotiate to later become trunk ports, because the switch defaults to allow the
port to negotiate trunking and decide whether to act as an access interface or as a trunk interface.
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” discusses more details about the commands that
allow a port to negotiate whether it should use trunking.
Note
The book includes a video that works through a different VLAN configuration example
as well. You can find the video on the DVD and on the companion website.
Example 1-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 Fa0/15 and Fa0/16 are in VLAN 3, as noted in the shaded part of
the show vlan brief command output.
Note
Do not change VTP settings on any switch that also connects to the production network
until you know how VTP works as explained in Chapter 5.
VLAN Trunking Configuration
Trunking configuration between two Cisco switches can be very simple if you just statically configure
trunking. For example, if two Cisco 2960 switches connect to each other, they support only 802.1Q
and not ISL. 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 supported all the
VLANs known to each switch.
However, trunking configuration on Cisco switches includes many more options, including several
options for dynamically negotiating various trunking settings. The configuration can either predefine
different settings or tell the switch to negotiate the settings, as follows:
The type of trunking: IEEE 802.1Q, ISL, or negotiate which one to use
The administrative mode: Whether to always trunk, always not trunk, or negotiate
First, consider the type of trunking. Cisco switches that support ISL and 802.1Q can negotiate which
type to use, using the Dynamic Trunking Protocol (DTP). If both switches support both protocols, they
use ISL; otherwise, they use the protocol that both support. Today, many Cisco switches do not
support the older ISL trunking protocol. Switches that support both types of trunking use the
switchport trunk encapsulation {dot1q | isl | negotiate} interface subcommand to either configure
the type or allow DTP to negotiate the type.
DTP can also negotiate whether the two devices on the link agree to trunk at all, as guided by the
local switch port’s administrative mode. The administrative mode refers to the configuration setting
for whether trunking should be used. Each interface also has an operational mode, which refers to
what is currently happening on the interface, and might have been chosen by DTP’s negotiation with
the other device. Cisco switches use the switchport mode interface subcommand to define the
administrative trunking mode, as listed in Table 1-2.
Table 1-2 Trunking Administrative Mode Options with the switchport mode Command
For example, consider the two switches shown in Figure 1-12. This figure shows an expansion of the
network shown in Figure 1-11, 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 a Gigabit Ethernet link for the trunk. In this case, the
trunk does not dynamically form by default, because both (2960) switches default to an administrative
mode of dynamic auto, meaning that neither switch initiates the trunk negotiation process. By
changing one switch to use dynamic desirable mode, which does initiate the negotiation, the switches
negotiate to use trunking, specifically 802.1Q because the 2960s support only 802.1Q.
Figure 1-12 Network with Two Switches and Three VLANs
Example 1-3 begins by showing the two switches in Figure 1-12 with the default configuration so that
the two switches do not trunk.
Example 1-3 Initial (Default) State: Not Trunking Between SW1 and SW2
Click here to view code image
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none
! Note that the next command results in a single empty line of output.
SW1# show interfaces trunk
SW1#
First, focus on the highlighted items from the output of the show interfaces switchport command at
the beginning of Example 1-3. The output lists the default administrative mode setting of dynamic
auto. Because SW2 also defaults to dynamic auto, the command lists SW1’s operational status as
“access,” meaning that it is not trunking. (“Dynamic auto” tells both switches to sit there and wait on
the other switch to start the negotiations.) The third shaded line points out the only supported type of
trunking (802.1Q) on this 2960 switch. (On a switch that supports both ISL and 802.1Q, this value
would by default list “negotiate,” to mean that the type of encapsulation is negotiated.) Finally, the
operational trunking type is listed as “native,” which is a reference to the 802.1Q native VLAN.
The end of the example shows the output of the show interfaces trunk command, but with no output.
This command lists information about all interfaces that currently operationally trunk; that is, it lists
interfaces that currently use VLAN trunking. With no interfaces listed, this command also confirms
that the link between switches is not trunking.
Next, consider Example 1-4, which shows the new configuration that enables trunking. In this case,
SW1 is configured with the switchport mode dynamic desirable command, which asks the switch to
both negotiate as well as to begin the negotiation process, rather than waiting on the other device. As
soon as the command is issued, log messages appear showing that the interface goes down and then
back up again, which happens when the interface transitions from access mode to trunk mode.
! The next command formerly listed a single empty line of output; now it lists
! information about the 1 operational trunk.
SW1# show interfaces trunk
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
2 enet 100010 1500 - - - - - 0 0
To verify whether trunking is working now, the middle of Example 1-4 lists the show interfaces
switchport command. Note that the command still lists the administrative settings, which denote the
configured values along with the operational settings, which list what the switch is currently doing. In
this case, SW1 now claims to be in an operational mode of trunk, with an operational trunking
encapsulation of dot1Q.
The end of the example shows the output of the show vlan id 2 command, which now lists G0/1,
confirming that G0/1 is now operationally trunking. The next section discusses the meaning of the
output of this command.
For the exams, you should be ready to interpret the output of the show interfaces switchport
command, realize the administrative mode implied by the output, and know whether the link should
operationally trunk based on those settings. Table 1-3 lists the combinations of the trunking
administrative modes and the expected operational mode (trunk or access) resulting from the
configured settings. The table lists the administrative mode used on one end of the link on the left, and
the administrative mode on the switch on the other end of the link across the top of the table.
Table 1-3 Expected Trunking Operational Mode Based on the Configured Administrative Modes
Finally, before leaving the discussion of configuring trunks, Cisco recommends disabling trunk
negotiation on most ports for better security. The majority of switch ports on most switches will be
used to connect to users. As a matter of habit, you can disable DTP negotiations altogether using the
switchport nonegotiate interface subcommand.
Figure 1-13 Before IP Telephony: PC and Phone, One Cable Each, Connect to Two Different
Devices
The term IP telephony refers to the branch of networking in which the telephones use IP packets to
send and receive voice as represented by the bits in the data portion of the IP packet. The phones
connect to the network like most other end-user devices, using either Ethernet or Wi-Fi. These new IP
phones did not connect via cable directly to a voice switch, instead connecting to the IP network using
an Ethernet cable and an Ethernet port built in to the phone. The phones then communicated over the
IP network with software that replaced the call setup and other functions of the PBX. (The current
product from Cisco that perform this IP telephony control function is called Cisco Unified
Communications Manager.)
The migration from using the already-installed telephone cabling, to these new IP phones that needed
UTP cables that supported Ethernet, caused some problems in some offices. In particular:
The older non-IP phones used a category of UTP cabling that often did not support 100-Mbps or
1000-Mbps Ethernet.
Most offices had a single UTP cable running from the wiring closet to each desk, but now two
devices (the PC and the new IP phone) both needed a cable from the desktop to the wiring
closet.
Installing a new cable to every desk would be expensive, plus you would need more switch
ports.
To solve this problem, Cisco embedded small three-port switches into each phone.
IP telephones have included a small LAN switch, on the underside of the phone, since the earliest IP
telephone products. Figure 1-14 shows the basic cabling, with the wiring closet cable connecting to
one physical port on the embedded switch, the PC connecting with a short patch cable to the other
physical port, and the phone’s internal CPU connecting to an internal switch port.
Figure 1-14 Cabling with an IP Phone, a Single Cable, and an Integrated Switch
Sites that use IP telephony, which includes most every company today, now have two devices off each
access port. In addition, Cisco best practices for IP telephony design tell us to put the phones in one
VLAN, and the PCs in a different VLAN. To make that happen, the switch port acts a little like an
access link (for the PC’s traffic), and a little like a trunk (for the phone’s traffic). The configuration
defines two VLANs on that port, as follows:
Data VLAN: Same idea and configuration as the access VLAN on an access port, but
defined as the VLAN on that link for forwarding the traffic for the device connected to the
phone on the desk (typically the user’s PC).
Voice VLAN: The VLAN defined on the link for forwarding the phone’s traffic. Traffic in
this VLAN is typically tagged with an 802.1Q header.
Figure 1-15 illustrates this design with two VLANs on access ports that support IP telephones.
Figure 1-15 A LAN Design, with Data in VLAN 10 and Phones in VLAN 11
Example 1-5 Configuring the Voice and Data VLAN on Ports Connected to Phones
Click here to view code image
Note
CDP, discussed in the ICND1 book’s Chapter 33, “Device Management Protocols,” must
be enabled on an interface for a voice access port to work with Cisco IP Phones. CDP is
enabled by default, so its configuration is not shown here.
The following list details the configuration steps for easier review and study:
Step 1. Use the vlan vlan-id command in global configuration mode to create the data and voice
VLANs if they do not already exist on the switch.
Step 2. Configure the data VLAN like an access VLAN, as usual:
A. Use the interface type number command in global configuration mode to move into
interface configuration mode.
B. Use the switchport access vlan id-number command in interface configuration mode to
define the data VLAN.
C. Use the switchport mode access command in interface configuration mode to make this
port always operate in access mode (that is, to not trunk).
Step 3. Use the switchport voice vlan id-number command in interface configuration mode to set
the voice VLAN ID.
Verifying the status of a switch port configured like Example 1-5 shows some different output
compared to the pure access port and pure trunk port configurations seen earlier in this chapter. For
example, the show interfaces switchport command shows details about the operation of an interface,
including many details about access ports. Example 1-6 shows those details for port F0/4 after the
configuration in Example 1-5 was added.
Example 1-6 Verifying the Data VLAN (Access VLAN) and Voice VLAN
Click here to view code image
Working through the first three highlighted lines in the output, all those details should look familiar for
any access port. The switchport mode access configuration command statically configures the
administrative mode to be an access port, so the port of course operates as an access port. Also, as
shown in the third highlighted line, the switchport access vlan 10 configuration command defined the
access mode VLAN as highlighted here.
The fourth highlighted line shows the one small new piece of information: the voice VLAN ID, as set
with the switchport voice vlan 11 command in this case. This small line of output is the only piece of
information in the output that differs from the earlier access port examples in this chapter.
These ports act more like access ports than trunk ports. In fact, the show interfaces type number
switchport command boldly proclaims, “Operational Mode: static access.” However, one other
show command reveals just a little more about the underlying operation with 802.1Q tagging for the
voice frames.
As mentioned earlier, the show interfaces trunk command—that is, the command that does not
include a specific interface in the middle of the command—lists the operational trunks on a switch.
With IP telephony ports, the ports do not show up in the list of trunks either—providing evidence that
these links are not treated as trunks. Example 1-7 shows just such an example.
However, the show interfaces trunk command with the interface listed in the middle of the
command, as is also shown in Example 1-7, does list some additional information. Note that in this
case, the show interfaces F0/4 trunk command lists the status as not-trunking, but with VLANs 10
and 11 allowed on the trunk. (Normally, on an access port, only the access VLAN is listed in the
“VLANs allowed on the trunk” list in the output of this command.)
Example 1-7 Allowed VLAN List and the List of Active VLANs
Configure these ports like a normal access port to begin: Configure it as a static access port and
assign it an access VLAN.
Add one more command to define the voice VLAN (switchport voice vlan vlan-id).
Look for the mention of the voice VLAN ID, but no other new facts, in the output of the show
interfaces type number switchport command.
Look for both the voice and data (access) VLAN IDs in the output of the show interfaces type
number trunk command.
Do not expect to see the port listed in the list of operational trunks as listed by the show
interfaces trunk command.
Chapter Review
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this
chapter’s material using either the tools in the book, DVD, or interactive tools for the same material
found on the book’s companion website. Refer to the “Your Study Plan” element for more details.
Table 1-4 outlines the key review elements and where you can find them. To better track your study
progress, record when you completed these activities in the second column.
Command References
Tables 1-6 and 1-7 list configuration and verification commands used in this chapter, respectively. As
an easy review exercise, cover the left column in a table, read the right column, and try to recall the
command without looking. Then repeat the exercise, covering the right column, and try to recall what
the command does.
Table 1-6 Chapter 1 Configuration Command Reference