Configuring VLANs on Cisco Switches
Configuring VLANs on Cisco Switches
Cisco Switches
AUGUST 10, 2016 by ed harmoush leave a comment
We’ve before written about VLANs and what they can do as a concept. This
article will focus on configuring VLANs on Cisco switches.
We will look at each command necessary to configure the topology below. If this
topology looks familiar, it is because you saw it in the article which described
how VLANs operated on a conceptual level.
We will first look at what goes into configuring the access ports in the topology
below, followed by what goes into configuring the trunk ports. Then we will look
at some verification and show commands to validate what is configured. Finally,
we will look at the default configuration for a switch port, so we know our
starting point when we are applying the commands we discuss.
Access Ports
An access port is a switch port that is a member of only one VLAN. There are
two parts to configuring an access port: creating the VLAN in the switch’s VLAN
Database and assigning the switch port to a VLAN.
SwitchX(config)# vlan 10
From this point, you can also optionally name the VLAN. While not explicitly
necessary for traffic to flow, it is best practice to provide a name for each VLAN.
This will make the VLAN easier to identify.
To name a VLAN, simply use the name; command directly after creating it.
For VLAN 20, we will create and name the VLAN on SwitchX:
SwitchX(config)# vlan 20
SwitchX(config-vlan)# name ORANGE
Note that a VLAN only has to be added to the database once. If a VLAN already exists in
the VLAN database, it is not necessary to re-create it – you can jump directly to the next
step. Later in this article we will look at some show commands used to determine if a
VLAN has already been created.
The switchport mode access command sets the port as an access port, and
the switchport access vlan <#>command designates the port as a member of
VLAN 10.
Some versions of Cisco switches automatically create the VLAN in the VLAN
Database when you assign an access port to a VLAN:
However, it is not recommended that you depend on this. Some switches will do
it, some will not. Some switches will not create the VLAN and also not report any
errors, leaving you confused as to why traffic might not be flowing. Moreover,
this creates the VLAN with a generic name – the name for VLAN 30 above
defaults to VLAN0030, which is not very helpful.
SwitchX(config)# vlan 30
SwitchX(config-vlan)# name BLUE
Then we will set Eth0/2 and Eth0/3 as access ports in VLANs 10 and 30,
respectively:
SwitchXSwitchY
Note, if you are following along with this configuration guide in your own lab, you may
not see the creation and naming of the VLANs appear in the running configuration. This
is because the default VTP mode causes VLAN database information to appear in
another file (vlan.dat). To force the configuration to appear in your running-
configuration, use the command vtp mode transparent. Beyond that, VTP’s operation
is outside the scope of this article.
Trunk Ports
As discussed before, a trunk port is a switch port that is carrying more than one
VLAN.
Traffic traversing a trunk port is still in the form of 1s and 0s. To designate
which 1s and 0s belong to which VLANs, a VLAN Tag is added to all traffic leaving
a trunk port. The 802.1q standard specifies the ubiquitous format for the VLAN
tag.
Just like switchport mode access set the port as an access port, switchport
mode trunk will set the port as a trunk port.
Some switches support more than one method for adding the VLAN tag. Namely,
some switches support the antiquated ISL method of VLAN tagging. Before these
switches allow you to set a port as a trunk port, they force you to set a tagging
method, also called an encapsulation method:
SwitchX(config)# interface Ethernet1/1
SwitchX(config-if)# switchport mode trunk
Command rejected: An interface whose trunk encapsulation is "Auto" can not be
configured to "trunk" mode.
For these switches, you simply use the switchport trunk encapsulation
dot1q command before setting the switchport as a trunk port:
This is all you need to create a trunk port. With the configuration above, the
switch will forward traffic from all VLANs in the VLAN Database out the
configured trunk port.
That being said, there are some additional helpful settings you can apply to a
trunk port to modify the default behavior. We will discuss two of them in the
sections that follow.
Native VLAN
The Native VLAN is the one VLAN on a trunk port which is allowed to remain
untagged. By default, this is set to VLAN 1, but this can be changed by an
administrator.
To set the Native VLAN, you use this command:
After setting this command, any time SwitchX is sending traffic on VLAN 2 out
the trunk port Eth1/1, it will do so without adding a VLAN tag. Moreover, anytime
SwitchX receives untagged traffic on trunk port Eth1/1, SwitchX will assign that
traffic to VLAN 2.
An important point to remember: both switches on either end of the same trunk
must have the same Native VLAN. Otherwise, you easily run the risk of a host in
one VLAN being able to communicate with a host in another VLAN.
We will also set another VLAN as the Native VLAN for Eth2/1 and Eth2/2 ports,
facing Router1 and Router2, respectively. This is to show that the Native VLAN
configuration is a per-interface configuration, not a per-deviceconfiguration. But
keep in mind, in most deployments the Native VLAN is typically consistent
across all ports.
Take a look at the illustration. Notice that the trunk port to Router1 is only
processing traffic for VLAN 10 and 20, but if the trunk port is left to its default
behavior, SwitchX will be forwarding traffic to Router1 from VLANs 10,
20, and 30. The VLAN 30 traffic will simply be dropped by Router1, but it does
needlessly add congestion to the link.
To solve this, we will add an Allowed VLAN list to Eth2/1 on SwitchX to restrict
which VLANs are traversing the trunk port:
This will limit the VLANs which are traversing the trunk port to Router1 to only
the VLANs which actually need to be on that link.
The trunk port to Router2 can also be limited to only carry traffic for VLAN 20
and 30. Below is another way of applying an Allowed VLAN list which shows how
to add VLANs to the list after initially creating it:
Notice the important keyword add in the second command above. This instructs
the switch to add VLAN 30 traffic to whatever VLANs are already allowed on the
link.
Had the keyword add been omitted, the switch will have replaced the current
Allowed VLAN List (which was allowing just VLAN 20) with the new one (which
was allowing just VLAN 30). If Router1 was the gateway for the traffic in VLAN
20, all that traffic would now be dropped – creating a decidedly poor experience
for the users in that VLAN.
As such, it is very important to either apply the full list of VLANs in one
command (as in the first example), or to use the add command to add VLANs to
the current allowed VLAN list.
You also have the option of using the remove keyword to remove individual
VLANs from the allowed VLAN list.
In fact, the remove keyword provides one more way to apply an allowed VLAN list
to a trunk port. Take a look at the link between SwitchX and SwitchY. Notice
VLAN 20 does not need to be traversing that link.
Rather than simply adding an Allowed VLAN list with VLANs 10 and 30, you can
also simply remove VLAN 20 from the default configuration. We’ll show you how
it works with the trunk port between the switches (Eth1/1):
This automatically applies an Allowed VLAN list for every VLAN except VLAN 20:
Since the default trunk port behavior was to allow all VLANs, removing VLAN 20
caused the switch to apply an Allowed VLAN list which included every VLAN (1 –
4094), except VLAN 20.
That said, this is typically not the way you would apply a new Allowed VLAN list
to an interface – the removekeyword is more often used to remove individual
VLANs from an already added Allowed VLAN list. We will remove the Allowed
VLAN list on Eth1/1, and leave that port configured as a default trunk port –
allowing traffic for all VLANs to traverse the trunk:
SwitchXSwitchY
Show Commands
The commands above explain the steps for configuring VLANs on Cisco
Switches. The output at the end of each section displayed the way the
configurations appears in the running-configuration. However, the running-
configuration will only show how a device is configured – it will not show how a
device operates.
This is an important distinction – a talented network engineer needs to not only
know how to configure VLANs, but also how to validate their operation as well.
To that end, we will discuss five show commands that can be used to verify a
device’s operation – how it is actually handling traffic.
SwitchXSwitchY
For both switches, the command displays VLANs 1, 10, 20, and 30. These are
the only VLANs that were created in the VLAN database. Should the switch
receive traffic tagged for a VLAN other than these, that traffic will be discarded.
For each VLAN, the VLAN’s name is also provided. Notice VLANs 10, 20, and 30
are named RED, ORANGE, and BLUE, respectively.
Also notice VLAN 1 exists and is named default, despite us not explicitly
creating it. This is because VLAN 1 is the default configuration that every switch
port starts out in. The switch will not allow you to delete VLAN 1 or change its
name.
The Status column reflects whether the VLAN is active on the switch. A VLAN can
become inactive for two reasons. The first is explicitly using
the shutdown command within the VLAN configuration mode. The second is a
VLAN existing in the database, but having no access ports or trunk ports utilizing
that VLAN.
On the far right of output, under the Ports column, you get a list of
each access port in each VLAN. We configured SwitchX’s Eth0/0 interface in
VLAN 10, and the output reflects that. Also notice the port Eth1/1 is nowhere to
be found. This is because Eth1/1 was configured as a trunk port, and will not be
visible in the output of show vlan brief.
There are four sections to the output of this command. To the untrained eye, it
might appear like some of the information is duplicate – but this is not the case.
SwitchXSwitchY
The first section of the output lists each interface which is operationally
behaving like a trunk port. This will make more sense a little later in the article
when we discuss a mechanism that lets a switch port automatically determine
whether it should be a trunk port. In the case above, we explicitly configured
ports Eth1/1, Eth2/1, and Eth2/2 on SwitchX and port Eth1/1 on SwitchY as trunk
ports.
The first section also lists what method of Encapsulation is in use (i.e., what
method of VLAN tagging), as well as the VLAN configured as the Native VLAN for
each trunk.
The third section, labeled Vlans allowed and active in management domain, is a
combination of the section before it (Vlans allowed on trunk) and the VLANs
which are created in the VLAN database (i.e., visible in show vlan brief). Despite
all VLANs being allowed on Eth1/1 (as indicated by the 1-4094 in the second
section), only VLANs 1, 10, 20, and 30 exist in the VLAN database.
The fourth section, labeled Vlans in spanning tree forwarding state and not
pruned, is a combination of the last two sections and the ports the Spanning Tree
Protocol deems as safe to forward traffic.
The Spanning Tree Protocol (STP) exists to ensure the L2 domain does not
contain any loops. If any are detected, those ports are disabled. In our topology,
there are no loops, so the output of the fourth section looks identical to the
output of the third section because STP did not disable any ports. STP is a
fascinating protocol, but its operation is outside the scope of this article – it will
be the subject of a future article.
Rather than try to sift through all that, you can specify a particular interface to
get those same 26 pieces of information for just the desired interface using the
command show interfaces <intf> switchport.
For the sake of brevity and relevance, the output below has been trimmed to
just show the lines which relate to something discussed in this article. There is
an example of the full output of this command later in this article.
The description of each line in the output above is in the table that follows.
Line(s) Description
Switchport
Enabled if the port is functioning as a L2 port. Disabled if the po
port.
These two tell you how the switchport is configured and how the
operating. In our case, we configured ports as access Ports and t
reflected above. But as alluded to before, there is a protocol calle
Administrative Mode and Operational switchports to automatically negotiate becoming a trunk port. In
Mode
have a particular Administrative mode set and the Operational m
the switchport is actually acting as a trunk or access port. This w
when we get into the specifics of DTP below.
Administrative Trunking DTP not only negotiates trunk status, it also negotiates encapsul
Encapsulationand Operational Trunking two commands show you what encapsulation method is configu
Encapsulation and what encapsulation method is negotiated (Operational).
Negotiation of Trunking This indicates the switchport’s participation in DTP. Again, it w
sense below when we elaborate on DTP.
This displays the VLAN membership if the port is configured or
Access Mode VLAN port. Note that even our trunk port (SwitchY’s Eth 2/2) has an en
but it doesn’t have an effect until the interface becomes an acces
This displays the Native VLAN setting for the port. Again, even
Trunking Native VLAN have an entry for this setting (see SwitchX’s Eth0/1), but it will
the interface is configured or negotiated as a trunk port.
This is a reflection of the VLANs permitted via an Allowed VLA
Trunking VLANs Enabled SwitchX’s trunk port was limited to just VLANs 20 and 30, and
output above.
Typically, the show interfaces status command is associated with seeing
whether devices are plugged into a switchport or not (connected vs notconnect
in the Status column). However, this command can also reveal some information
about the VLAN configuration of a switchport.
Namely, if you see a number in the VLAN column, then the switchport is an
access Port in the provided VLAN. And if you see the word trunk, then the
switchport is configured as a trunk port.
Namely, if you see a number in the VLAN column, then the switchport is an
access Port in the provided VLAN. And if you see the word trunk, then the
switchport is configured as a trunk port.
SwitchXSwitchY
show spanning-tree
The show spanning-tree command is obviously mostly associated with verifying
the Spanning Tree Protocol, but it can also provide useful VLAN configuration
information.
Earlier we talked about show vlan brief, which provides information about
interfaces configured as access ports. We also talked about show interfaces
trunk, which provides information about interfaces configured as trunk ports.
The show spanning-tree vlan <VLAN-ID#> command provides information
on both access ports and trunk ports.
Specifically, you can use this command to see every switchport a VLAN is
exiting.
SwitchXSwitchY
We configured SwitchX with one access port in VLAN 10 (Eth0/0), and two trunk
ports which are permitting VLAN 10 (Eth1/1 and Eth2/1). Looking at the output
of the show spanning-tree vlan 10 command on SwitchX, we can see all three of
the ports that VLAN 10 traffic is egressing.
SwitchXSwitchY
We can see that VLAN 10 on SwitchX is going to Router1 and SwitchY, as well as
a third device (which we know is Host A, who isn’t participating in CDP). VLAN 20
on SwitchY is only going to SwitchX. Using these two commands in conjunction
with each other is a great way to trace the L2 path through a network between
two devices.
Note, the output of the command show spanning-tree vlan <#> above has been
trimmed to focus on just the features discussed in this article.
Cisco created DTP to further the idea of ‘plug and play’ switches. They created a
protocol where if two switches were linked to each other, they could
automatically determine whether their interlink should be a trunk port or an
access port. It works based upon four modes an interface can be set to:
Even with the switch port mode statically set, however, your switch will still send
DTP frames. This is how the otherside knows how your side is configured. Again,
if you own both sides the risk is negligible, but if you might not control the other
side, then this is undesirable.
You can disable the sending of DTP frames by also adding to the interface
configuration this command: switchport nonegotiate. This will disable the
periodic sending of DTP frames to advertise the switch port mode of the local
switch.
You can view whether a switch port has negotiation disabled in the output of the
command above. The specific line which indicates it is the following:
Negotiation of Trunking: On
Whether a switch port is statically set (or negotiated) as an access port or not,
this attribute exists and is configurable via the switchport access
vlan <#> command. Of course, it doesn’t affect the behavior of the switchport
unless the switchport becomes an access port.
A potential use case is if you are transitioning a port from a trunk port to an
access port, you can “preset” the access-port VLAN so that once you apply the
switchport mode access command, it is already in the appropriate VLAN.
In any case, notice the default configuration has every switchport in VLAN 1.
We discussed DTP earlier, but we did not mention that DTP also negotiates the
encapsulation method.
Trunking Native Mode VLAN indicates the Native VLAN on the port. Once again,
this setting will only take place if the port becomes a trunk port. This setting can
be modified with the switchport trunk native vlan <#> command.
Trunking VLANs Enabled reflects the Allowed VLAN list applied to the
port. ALL indicates no VLANs have been restricted from the trunk, and therefore
every VLAN in the VLAN database will traverse down the trunk. As with the other
trunk configurations, this has no effect if the port is in access mode.
As with all written guides, practice is key. We encourage you to build out the
topology above in a lab or emulator (GNS3 / Packet-Tracer) and to practice
configuring VLANs using the commands described above.
If you want an additional challenge, build out the topology in the VLAN
Challenge from the other article. Note, you will need to disable CDP and DTP on
most of your interfaces to avoid warnings.
If you are able to successfully build out that topology (as well as answer the two
challenge questions in the previous article), then you can rest assured knowing
you have mastered the concept of Configuring VLANs on Cisco switches.