1

It’s been a few days since I had a chance to post anything.  My daughter just turned 2 and
we’ve been working hard cleaning and getting ready for a big birthday party for her this last
weekend.  It’s been nice taking some time to spend with the Wife and some family and
friends.  I had a chance to talk to Philip, the guy who runs Hack and Tinker, and can say that
I’m excited about some things that are planned in the near future here, so stay tuned!  In the
meantime, let’s dive into our next CCIE topics!

Implementing and troubleshooting VLANs – now THAT sounds like some CCIE Routing and
Switching fun!  For sure, this is really getting to the heart of what we’re really trying to
become great at as CCIE candidates.  Here’s the exam blueprint topics at hand:

2.1.c   Implement and troubleshoot VLAN

2.1.c (i)   Access ports
2.1.c (ii)   VLAN database
2.1.c (iii)   Normal, extended VLAN, voice VLAN

Access Ports
This seems like as good a place as any to talk about DTP.  DTP isn’t a topic unto itself on the
CCIE Blueprint, but plays a key role in a switch’s decision to put a port into an access state or
a trunking state.  Most of Cisco’s switches, especially those targeted at access-layer switches
default to “switchport mode dynamic desirable.”  This means that DTP is turned on and is
actively trying to force ports into a trunking state.  A good practice for all of your switches is
to adjust that to a more secure setting the moment you take it out of the box.  One such default
could be to hard-code them as access ports with the interface switchport mode access
command.  You can also tell the switch not to send DTP frames or negotiate with other
switches that are attempting to send DTP frames with the interface  switchport nonegotiate
command.  You can place a port into a VLAN with the switchport access vlan number
command.  A great command for viewing switching information on a port is the show int
name switchport.  It gives a ton of great information!
2

VLAN Database
VLANs are stored in the VLAN.dat file in flash.  VLANs are automatically added when you
put a port into a non-existant VLAN with the switchport access vlan number command. 
You can name VLANs with the name command.    View VLANs with the show vlan
command.  It is of note that a VLAN can be suspended or shutdown.  A suspended VLAN
will still propagate through VTP, whereas a shutdown VLAN will not.  Suspending a VLAN
in a VTP domain will suspend that VLAN on all switches in the VLAN.  There’s a heck of a
lot more to talk about with VLANs, but we’ll cover those in sections that are dedicated to
their own particular topics, like VTP and spanning-tree.  So, for now, we’ll keep this short
and sweet.

Normal, Extended VLAN and Voice VLAN

Normal VLANs – the ones that we’re already familiar with – are all in the range of 1 – 1005. 
For some time, those were the only VLANs that could exist in a network.  Later, support was
added for the Extended VLAN range of 1006 – 4094.  VTP versions 1 and 2 are not capable
of working with these VLAN numbers, so you must operate your switch in VTP transparent
mode if you plan on using them with these VTP versions.  As for the voice VLAN, this allows
phones to tag traffic over an access port.  When a Cisco phone is plugged into a port running
3

CDP and a voice vlan, the switch uses CDP to tell the phone “tag your own traffic with this
voice VLAN 802.1q tag, and leave traffic from devices attached through you untagged.”

While Cisco doesn’t explicitly include “internal VLANs” with this blueprint topic, I feel it’s
good to comment on here.  Internal VLANs are those that are used by a switch for internal
functions.  An example of an internal function is a VLAN interface.  These can be viewed
with the show vlan internal usage command.  Unfortunately, these VLAN numbers are not
consistent, either between vendors, or even between models made by the same vendor. 
Switches automatically allocate these according to their configured vlan internal allocation
policy direction command.  You can view usage with the show vlan internal usage
command.  One major potential for trouble is that a switch might be using a VLAN that is
already reserved as an internal VLAN number on another switch.  This can produce a very
diffictult scenario to trace and troubleshoot.

Next on our list of blueprint topics:

2.1.d   Implement and troubleshoot trunking

2.1.d (i)   VTPv1, VTPv2, VTPv3, VTP pruning
2.1.d (ii)   dot1Q
2.1.d (iii)   Native VLAN
2.1.d (iv)   Manual pruning

Again, since DTP is not a topic unto itself, I’ll comment on it first, briefly covering its
implications in light of trunks.  Again, the show interface number switchport command
gives a great deal of information about an interface, and can be very useful when
troubleshooting trunking issues.  DTP can negotiate both trunk status, and trunk encapsulation
method.  It will first try to negotiate ISL if supported.  If not, it will negotiate dot1q
encapsulation, and then will fall back into access port mode if trunking cannot benegotiated. 
DTP, when running, can be running in desirable or in auto mode.  A switch in auto mode will
only react to DTP messages, it will not begin sending them.  Only a switch in DTP desirable
mode will actively send DTP frames unprompted.  Remember that configuring DTP will
cause an interface flap, so you don’t want to do it outside of a maintencance window for links
over which critical data passes.  Configure a trunking mode with the interface switchport
mode dynamic desirable or switchport mode dynamic auto commands.  Surprisingly, one
of the requirements for DTP to work is that both switches must have the same VTP domain
name configured, even if that configured name is the NULL domain, which is default.

VTPv1, VTPv2, VTPv3 and VTP Pruning

The original VTP allowed network admins to create VLANs once on a server and allow that
to propagate out to all members of the VTP domain, saving time and administrative burden. 
Going back to our CCNA days, we remember the huge caveat: it can blow everything up if
you plug in a switch with a higher revision number than your production environment. 
VTPv1 can only carry the normal VLAN ranges and does not allow for carrying unrecognized
information.  In other words, it is not extensible enough to realize that it might need to carry
and transmit information that it does not itself understand.  In other other words, it is not
forward-compatible.  VTPv2 fixed this by allowing the carrying of unrecognized information
carried in VTP TLV frames.  VTP v1 and v2 allow for clients and servers, where only a
server can be configured by an administrator to make changes to the VLAN database.  They
4

also support transparent mode, where the switch with forward VTP information, but will not
pay any attention to it locally.  VTP domain name can be configured with the vtp domain
name command.  Version is configured with the vtp version number command.  VTP can
require a password with the vtp password string command.  VTP will only run on the trunk
ports of a switch.  View VTP information with the show VTP status command.  Cisco
switches run VTP by default with a domain name that is NULL.  VTP domain name should,
at a very minimum be set before moving switches into production, as the first switch that has
a VTP domain name configured will update all switches in the NULL domain with the name
and VLAN database of the first switch that ends up having a VTP domain assigned. 
(Yikes!!!)  For environments where VTPv1 or VTPv2 are the only options, running your
switches in transparent mode is usually a better option.  Configure this with the vtp mode
transparent command.

VTPv3 is relatively new and might not be supported on all of your switches, so do some
checking before starting to implement it in your production environment.  The main driver for
moving to VTPv3 is really the fact that it fixes the issue where you can overwrite your VLAN
database by inserting a switch with a higher revision number than what you have in
production.  It does this by essentially redifining the server role.  VTPv3 has VTP secondary
servers and a VTP primary server.  It also has better password implementation (they’re no
longer stored in plaintext), the abililty to advertise (but not prune) extended VLANs, the
ability to turn off completely rather than just be put into transparent mode, and the ability to
work with MST and private VLANs.

Here’s the infuriating part about Cisco’s brilliant new version of VTP: you can’t activate it
unless VTP is already running.

Think about that – it essentially means that you have to momentarily run VTP in version 1 or
2, which both have massive risk involved if configured in the wrong order.  If you are coming
from an environment that does not use VTP because of those risks, but decide to use VTPv3
because it is “safe”, you could still end up destroying the VLAN database on your switches,
because the default behavior of all switches with a null VTP domain name is to automatically
reconfigure themselves with the whatever VTP domain name they first hear other than the
null VTP domain.  Granted, this would only happen if you aren’t following the best practice
of putting switches into VTP transparent mode when you deploy them if you aren’t using
VTP, but it still bears repeating: Don’t begin this process unless you are 100% certain that all
of your switches are already in the same VTP domain, or they are all in VTP transparent
mode.

Once you are sure that you can do so without destroying your environment, configure VTPv3
by first using assigning a VTP domain name.  If, at that point, your network still exists (yes,
I’m paranoid), configure VTP versions with the global vtp version 3 command.  You can
now configure your switch as a client, server, or transparent switch for any of the VTP
instances that are now running – MST, VLANs or unknown.  By default, switches will be
VTP servers for all instances, though this can be changed with the vtp mode client
<instance> command.
5

Notice though, that even a VTP server cannot make changes to its VLAN database.

This hints at the major improvement in VTP v3 over its predecessors: protection against
accidentally overwriting the VLAN database.

In VTPv3, not even VTP servers assert their own VLAN databases as the database that all
other switches in the VTP domain should run.  Even if a VTPv3 server exists with a higher
configuration revision, it will not cause other VTP domain members to overwrite their VLAN
database.  In order to cause this replication, the switch must become the PRIMARY server,
which causes it to inform all other switches in the VTP domain that it has been configured by
an administrator become the source of new VLAN information.  Do this by backing out of
global config mode (so, back into privileged exec mode) and using the vtp primary
<instance> command.  It will show you that it verifies with other switches that there is not
already a server configured as the VTP Primary server.

Once this is complete, VLAN database replication will kick off.  This is obviously a FAR
more controlled method of replication as compared to VTPv1 and v2.

VTP Pruning
While most think of administrative ease of management as the main reason to run VTP, VTP
Pruning is actually another benefit that might make running VTP in your environment
worthwhile.  VTP pruning is a function that allows VTP to take notice of times when a VLAN
exists in the VLAN database, but a switch does not have any ports or downstream neighbors
that need to receive this traffic.  The switch can inform the upstream neighbors that it can
prune the unneeded VLANs from its trunks.  The main benefit of this is that it will prevent
broadcasts or unknown packets from being sent across trunks if the VLANs that those packets
are sent on have been pruned on the neighboring switch.  Verify that a VLAN is allowed or
pruned with the show interface number trunk command.  Even in VTPv3 environments,
only standard VLAN numbers (2-1001) are eligible to be pruned via VTP.  With VTP
pruning, you define which VLANs are allowed to be pruned.  That means that the VLANs
you designate CAN be stripped away, whereas VLANs that you do not define cannot.  Define
pruning eligible VLANs with the interface switchport trunk pruning vlan number
6

command.  You can verify pruning operation with the show interface number pruning
command.  Note that the output of this command shows the VLANs that the local switch is
requesting to have forwarded from the neighbor switch, as well as the VLANs that are being
pruned out toward that neighbor, and that the two do not necessarily have to be the same.  In
order to activate VTP pruning, use the vtp pruning command on a VTP server in the
domain.  In VTP versions 1 and 2, this will automatically enable VTP pruning throughout the
entire VTP domain.  For VTPv3, you need to enable pruning on every switch in the domain. 
VTP is a Cisco-proprietary standard, which means that VTP pruning will not work with other
vendor switches.  In such an environment, manual VLAN pruning would be needed to
accomplish pruning, and to prevent non-Cisco switches from breaking the pruning functions. 
The reason VTP pruning breaks when facing a non-Cisco switch it that the non-Cisco switch
won’t speak VTP, and therefore, won’t be able to communicate which VLANs it needs and
which can be pruned, so as a fallback, the Cisco switches have to assume that all VLANs are
needed on the port.

dot1Q
Unsurprisingly, 802.1q is the only trunking encapsulation covered on the CCIE exams.  ISL
has all but gone by the wayside.  On some switches, you may still need to configure dot1q on
your trunks by using the interface encapsulation dot1q command, but even that is becoming
incresingly rare these days.  The dot1q header is inserted into an Ethernet frame and adds 32
bits to the ethernet frame’s size.  This header contains a Priority Code Point field, which is a
3-bit field that can hold a CoS value, followed by a Drop Eligible Indicator, indicating
whether this frame should be considered to be of lower priority, in case of congestion leading
to the need to drop certain frames, and then a 12-bit VLAN ID field.  12 bits gives you 4096
possible values, and values 0 and 4095 are reserved, which explains why switches support
VLAN ID numbers from 1-4094.

Native VLAN
The native VLAN is the VLAN that can traverse the trunk without being tagged.  A native
VLAN mismatch will cause trunks to malfunction, as traffic will end up in the VLAN of the
receiving switch’s native VLAN.  You can tell trunks to tag the native VLAN with the global
vlan dot1q tag native command.  If a switch is configured this way and receives untagged
traffic, it will discard those frames, so it’s important to make sure that this is configured on
both sided of the trunks.  Again, as this is a CCIE-level blog, I won’t go into any further
details, as it’s usually pretty safe to assume that Engineers reading this are well familiar with
these concepts.

Manual Pruning
We covered the pruning concept in the VTP pruning section.  VLANs can also be manually
pruned.  On a trunk interface, use the switchport trunk allowed vlan numbers command to
define the allowed vlans list.  Again, you can verify that a VLAN is allowed or pruned with
the show interface number trunk command.  One of the most important reasons we need to
understand manual pruning is because VTP is a Cisco-proprietary protocol.  This means that
when using VTP pruning, only Cisco switches will know how to perform pruning via VTP. 
7

So, when facing a non-Cisco switch, if you want to prune VLANs, it will be necessary to
manually do so.

Thanks again for stopping by – it’s been great to keep discovering the depths of Layer 2 and
Cisco switching.  I’ll try and keep these coming at a more regular pace now that things have
slowed down after the holidays.  Stay tuned for our next exam topic on EtherChannel… and
then for the next one, which will be absolutely massive: Spanning-Tree.  I’ve had these in
development for weeks now and I’m very excited to be close to being ready to post.  Stay
tuned!