The Bryant Advantage CCNP SWITCH Study Guide

Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com

Back To Index
Virtual LANs (VLANs)
Overview

Cliche #1: "If you don't use it, you lose it."
Cliche #2: "Cliches become cliches because more often than not, they're
true."
Why We Create VLANs
Static VLANs
Dynamic VLANs
Trunking
ISL and IEEE 802.1q
Troubleshooting Trunks
The Native VLAN
Dynamic Trunking Protocol (DTP)
Trunking Modes
VLAN Database Mode
VLAN Design Guidelines
End-To-End And Local VLANs
I can vouch for #1, especially when it comes to certification studies. If
you just recently finished your CCNA, a great deal of the information in
this section will seem very familiar; if it's been a while, it's likely you've lost
some of the details -- the details you need to know to pass the SWITCH
exam the first time around.
Even if you did recently get your CCNA and you feel comfortable with
VLANs, don't skip this section. There's plenty of information here that
wasn't in your CCNA studies, but must be part of your CCNP studies.
We'll start with a review of the VLAN basics, and there's nothing more
basic than this question: "If Virtual LANs are so great, what's wrong with
our good old physical LANs?"
Good question. Here's a good answer! (You know from previous studies
that the symbol in the center of the following diagram is a switch - Cisco
might tell you that on exam day, and again they might not.)


One common reason for creating VLANs is to prevent the excess traffic
caused by a switch's default behavior when it receives a broadcast. One
of the first switching concepts you learned was that a switch that receives
a broadcast will forward it out every other port on the switch except the
one that it was originally received on.
Here, we have five PCs each connected to their own switch port. One PC
is sending a broadcast, and by default all other devices in the diagram will
receive it. This network segment is one large broadcast domain. It's also
known as a flat network topology.
Now you just might think, "Big deal. There are only five PCs there. How
many broadcasts can there be?"
It's true that there are only five PCs in this diagram - and it's also true that
this is a good example, but it's not a real-world example.
What if you had a 48-port Cisco switch and every port had a connected
host? We'd have a broadcast being sent to 47 hosts every time a
broadcast was received by the switch. Odds are that all those hosts don't
need that particular packet, and propagating it to all of those other hosts
has two drawbacks:
Unnecessary use of bandwidth
Unnecessary workload on the switch to process and send all of
those broadcasts
Just as we broke up one big collision domain by connecting each host to
a separate switch port (as opposed to a hub or repeater), we can divide
this single large broadcast domain into multiple smaller broadcast
domains by using VLANs.
When I first started studying networking, that sounded like something we
wouldn't want to do. If we're trying to control broadcasts, why are we
creating more broadcast domains? Wouldn't we be better off with just
one broadcast domain?
Creating multiple broadcast domains helps to limit the scope of the
broadcast - in effect, fewer hosts will actually receive a copy of that
broadcast.
When a switch receives a broadcast packet from a host in one particular
VLAN, that switch will forward that broadcast only via ports that are in the
same VLAN. Those VLANs are our smaller broadcast domains, and
that's how having multiple broadcast domains is more efficient than
having one big one.
There is no official restriction to which ports you can put into a VLANs, but
Cisco's best practice is to have one VLAN per IP subnet, and this is a
best practice that works very well in the real world.
The VLAN membership of a host depends on one of two factors:
With static VLANs, it's dependent on the port the host is connected
to
With dynamic VLANs, it's dependent on the host's MAC address
Before we take a look at static VLANs, note that the difference between
these two VLAN types is how the host is assigned to a VLAN. The terms
"static" and "dynamic" do not refer to how the VLAN is actually created.
You'll see what I mean in just a second. Let's get to the static VLANs.



By default, each of those hosts is in VLAN 1. VLAN 10 has been created
and when one host in VLAN 10 sends a broadcast, the only hosts that will
receive a copy of that broadcast are the other hosts in VLAN 10.
In networking, sometimes it seems that when we fix one problem, the fix
results in another possible issue. That's certainly true here - not only will
broadcasts not be forwarded between VLANs, but no traffic will be
forwarded between VLANs.
This may be exactly what we wanted, but we're going to have to introduce
an OSI Model Layer Three device to perform routing between the two
VLANs.
We used to just have two "official" methods of allowing inter-VLAN
communication, but now we have three:
"router on a stick"
Introducing a router to our network
Running a Layer 3 switch
The reason I say "official" is that in your CCNA studies, you learned about
only the first two methods, even though L3 switches have been around for
a few years now and are quite commonplace.
If you studied for the CCNA with my materials, you know that I mentioned
L3 switches to you so you wouldn't look silly in a job interview ("I'm quite
sure if there was such a thing as an L3 switch, Mr. Interviewer, Chris
Bryant would have said something about them.").
I also made it clear that when it came to your CCNA exam, a switch is a
layer 2 device and that's it. You now need to leave that thinking behind,
and we'll spend plenty of time with L3 switches later in the course.
Every once in a while I run into a student who tells me "we don't use
VLANs." If you're using a Cisco switch, you're using VLANs whether you
know it or not! Let's run show vlan brief on a Cisco switch straight out of
the box.
SW2#show vlan br
VLAN Name Status Ports
---- -------------------------------- --------- --------------------------
-----
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
We're already using VLANs, even though we haven't configured one. By
default, all Cisco switch ports are placed into VLAN 1. The default VLAN
is also known as the native VLAN.
The five VLANs shown here - 1, 1002, 1003, 1004, and 1005 - cannot be
deleted.
SW2(config)#no vlan 1002
Default VLAN 1002 may not be deleted.
Note: While our Ethernet hosts are placed into VLAN 1 by default, all five
of those VLANs just mentioned are default VLANs. You'll probably never
use 1002 - 1005, but that's a good range to know for your exam.
There's one more reason that may lead you to create VLANs. If you have
a network segment with hosts whose very existence should not be known
by the rest of the network, just put these hosts into their own VLAN.
(This comes in handy with secret servers, too. Not so much with secret
squares or secret squirrels.)
Unless you then intentionally make them known to the rest of the
network , these hosts will not be known or reachable by hosts in other
VLANs.
In the following example, all hosts are on the 172.12.123.0 /27 subnet,
with their host number as the final octet. Every host can ping every other
host.
For now. Heh heh heh.
Each host is connected to the switch port that matches its host number.
These hosts are on the same subnet to illustrate inter-VLAN connectivity
issues. As mentioned previously, it's standard practice as well as Cisco's
recommendation that each VLAN have its own separate IP subnet.



The problem right now is that every host will receive every broadcast
packet sent out by every other host, since all switch ports are placed into
VLAN 1 by default. Perhaps we only want Host 2 to receive any
broadcast sent by Host 1. We can make this happen by placing them into
another VLAN.
We'll use VLAN 12 in this case. By placing switch ports 0/1 and 0/2 into
VLAN 12, hosts that are not in that VLAN will not have broadcast packets
originated in that VLAN forwarded to them by the switch.
SW1(config)#int fast 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
% Access VLAN does not exist. Creating vlan 12

SW1(config-if)#int fast 0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 12
One of the many things I love about Cisco switches and routers is that if
you have forgotten to do something, the Cisco device is generally going to
remind you or in this case actually do it for you. (You'll see an exception
to this later in this very section.) I placed port fast0/1 into a VLAN that did
not yet exist, so the switch created it for me.
Note: This VLAN was created dynamically, but that doesn't make it a
dynamic VLAN. I'm not playing games with words there - remember, the
terms "static" and "dynamic" when it comes to VLANs refer to the method
used to assign hosts to VLANs, not the manner in which the VLAN was
created.
It's easy to put a port into a static VLAN, but there are two commands
needed to place a port into one. By default, these ports are running in
dynamic desirable trunking mode, meaning that the port is actively
attempting to form a trunk. (More on these modes and trunks themselves
later in the course.) The problem is that a trunk port belongs to all VLANs
by default, and we want to put this port into a single VLAN.
To do so, we run the switchport mode access command to make the port
an access port, and access ports belong to one and only one VLAN. After
doing that, we placed the port into VLAN 12 with the switchport access
vlan 12 command.
After configuring VLANs, always run show vlan brief to verify the config.
The output shows that ports 0/1 and 0/2 have been placed into VLAN 12.

Host 1 can still ping Host 2, but to ping the other hosts (or send any traffic
to those other hosts), we have to get L3 involved in one of the three
methods mentioned earlier:
router-on-a-stick
A router itself
Use an L3 switch
Even though Host 3 and Host 4 are on the same IP subnet as Host 1,
they're in different VLANs and therefore cannot ping each other.
HOST1#ping 172.12.123.2
Sending 5, 100-byte ICMP Echos to 172.12.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

HOST1#ping 172.12.123.3
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

HOST1#ping 172.12.123.4
Sending 5, 100-byte ICMP Echos to 172.12.123.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
What if Hosts 1 and 2 still couldn't ping each other, even though they're
obviously in the same subnet and the same VLAN? There are two places
you should look that might not occur to you right away. First, check speed
and duplex settings on the switch ports.
Second, check the MAC table on the switch and make sure the hosts in
question have an entry in the table to begin with. Nothing is perfect, not
even a Cisco switch, and every once in a very great while the switch may
not have learned a MAC address that it should know.
Throughout this chapter, I've used show vlan brief to check VLAN
membership. Here's what the full show vlan command displays:

All the information you need for basic and intermediate VLAN
troubleshooting is contained in show vlan brief, so I prefer to use that
version of the command.
You know that all ports are placed into VLAN 1 by default, and all ports in
the above configuration except 0/1 and 0/2 are indeed in VLAN 1. In the
more detailed field at the bottom of the show vlan output, note that the
default VLAN type set for VLANs 1 and 12 is "enet", short for ethernet.
The other VLANs are designed for use with FDDI and Token Ring, and
you can see the defaults follow that designation. The only other default
seen here is the MTU size of 1500.
Notice that all the VLAN-related configuration has been placed on the
switch - we haven't touched the hosts. With static VLANs, the host
devices will assume the VLAN membership of the port they're connected
to. The hosts don't even know about the VLANs, nor do they care.
By the way, if you just want to see the ports that belong to a specific
VLAN, run the command show vlan id followed by the VLAN number. This
command shows you the ports that belong to that VLAN, the status of
those ports, the MTU of the VLAN, and more.
SW1#show vlan id ?
WORD ISL VLAN IDs 1-1005
SW1#show vlan id 5
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
5 VLAN0005 active Fa0/5, Fa0/11, Fa0/12
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ - ------- ---- -------- ------ ------
5 net 100005 1500 - - - - - 0 0
Remote SPAN VLAN
----------------
Disabled
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
SW1#
The actual configuration of dynamic VLANs is out of the scope of the
SWITCH exam, but as a CCNP you need to know the basics of VMPS - a
VLAN Membership Policy Server.
When you move a user from one port to another using static VLANs, you
have to change the configuration of the switch to reflect these changes.
Using VMPS results in these changes being performed dynamically,
because the port's VLAN membership is decided by the source MAC
address of the device connected to that port. (Yet another reason that the
first value a switch looks at on an incoming frame is the source MAC
address.)
VMPS uses a TFTP server to help in this dynamic port assignment
scheme. A database on the TFTP server that maps source MAC
addresses to VLANs is downloaded to the VMPS server, and that
downloading occurs every time you power cycle the VMPS server.
VMPS uses UDP to listen to client requests.
An interesting default of VMPS is that when a port receives a dynamic
VLAN assignment, PortFast is automatically enabled for that port! There's
no problem with PortFast being turned off on that port if you feel it
necessary, but keep this autoenable in mind.
What if we had to move Host 1's connection to the switch to port 0/6?
With static VLANs, we'd have to connect to the switch, configure the port
as an access port, and then place the port into VLAN 12. With VMPS, the
only thing we'd have to do is reconnect the cable to port 0/6, and the
VMPS would dynamically place that port into VLAN 12.
When dynamic VLANs are in use, the port number isn't important - the
MAC address of the host connected to the port is the deciding factor
regarding VLAN membership.
I urge you to do additional reading regarding VMPS. It's a widely used
switching service, and it's a good idea to know the basics. Use your
favorite search engine for the term configuring vmps and you'll quickly find
some official Cisco documentation on this topic.
Some things to watch out for when configuring VMPS:
The VMPS server has to be configured before configuring the ports
as dynamic.
PortFast is enabled by default when a port receives a dynamic VLAN
assignment.
If a port is configured with port security, that feature must be turned
off before configuring a port as dynamic.
Trunking ports cannot be made dynamic ports, since by
definition trunking ports must belong to all VLANs. Trunking must be
disabled to make a port a dynamic port.
Final Time I'll Mention This: With static VLANs, the host's VLAN
membership is the VLAN to which its switch port has been assigned.
With dynamic VLANs, it is dependent upon the host device's MAC
address.
As for the relation between VLANs and subnets, it's Cisco's
recommendation that there be every VLAN be a separate subnet.
Trunking
It's highly unlikely that all members of a particular VLAN are all going to
be connected to one switch. We're much more likely to see something
like this:



To allow the hosts in these two VLANs to communicate with other hosts in
the same VLAN, we have to create a trunk on that physical connection
between the two switches.
A trunk is simply a point-to-point connection between two physically
connected switches that allows frames to flow between the switches.
By default, a trunk port is a member of all VLANs, so traffic for any and all
VLANs can travel across this trunk, and that includes broadcast traffic.
The beauty and danger of trunks is that by default, our switch ports are
actively attempting to form a trunk. Generally, that's a good thing, but
we'll see later in the course that this can lead to trouble.
On these switches, the ports on each end of the connection between the
switches are actively attempting to trunk. Therefore, the only action
needed from us is to physically connect them with a crossover cable. In
just a few seconds, the port light turns green and the trunk is up and
running. The command show interface trunk will verify trunking.

From left to right, you can see...
the ports that are actually trunking (if none are, you'll see no output)
the trunking mode each post is using
the encapsulation type
the status of the trunk, either "trunking" or "not trunking"
the "native vlan"
Further down in the output, you can see the VLAN traffic that is allowed to
go across the trunk.
Just as important is where you will not see trunk ports listed. When we
took our first look at the show vlan brief command earlier in this section,
there was something a little odd...
SW2#show vlan br
VLAN Name Status Ports
---- -------------------------------- --------- --------------------------
-----
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
There are 10 ports shown, but this is a 12-port switch. Note that ports
0/11 and 0/12 do not appear in the output of show vlan brief, and if you
ran the full show vlan command, they wouldn't show up there, either.
The ports didn't just disappear, thankfully - ports that are trunking will not
appear in the output of show vlan or show vlan brief.
Always run both show vlan and show interface trunk when verifying your
switch configuration or troubleshooting.
Now we know that frames can be sent across a trunk - but how does the
receiving switch know the destination VLAN?
The frames are tagged by the transmitting switch with a VLAN ID,
reflecting the number of the VLAN whose member ports should receive
this frame. When the frame arrives at the remote switch, that switch will
examine this ID and then forward the frame appropriately.
You may have had a CCNA flashback when I mentioned "dot1q" earlier.
There were quite a few differences between the trunking protocols ISL
and dot1q, so let's review those before we examine a third trunking
protocol that you might not have seen during your CCNA studies.
For a trunk to form successfully, the ports must agree on the speed, the
duplex setting, and the encapsulation type. Many Cisco switches offer the
choice of ISL and IEEE 802.1q - and your exam just might discuss these
encap types!
Inter-Switch Link Protocol (ISL),IEEE 802.1q ("dot1q"), and DTP
ISL and dot1q are both point-to-point protocols.
That's about it for the similarities. Discussing the differences will take
longer.
ISL is Cisco-proprietary, making it unsuitable for the dreaded "multivendor
environment". That's the least of our worries with ISL, though.
ISL will place both a header and trailer onto the frame, encapsulating it.
That doesn't sound like a big deal, but when you think of adding that
overhead to every single frame, it then becomes a big deal - especially
when we compare ISL's overhead to dot1q.
Since ISL places both a header and trailer, ISL is sometimes referred to
as "double tagging".
But wait - there's more!
The default VLAN is also known as the "native VLAN", and ISL does not
use the concept of the native VLAN. Dot1q does use this concept and will
not place any additional overhead onto a frame destined for the native
VLAN. ISL ignores the native VLAN concept and therefore will
encapsulate every frame.
The 26-byte header that is added to the frame by ISL contains the VLAN
ID; the 4-byte trailer contains a Cyclic Redundancy Check (CRC) value.
The CRC is a frame validity scheme that checks the frame's integrity.
In turn, this encapsulation leads to another potential issue. ISL
encapsulation adds 30 bytes total to the size of the frame, potentially
making them too large for the switch to handle. The maximum size for an
Ethernet frame is 1518 bytes. Frames larger than that are called giants; if
the frame is just a few bytes over that limit, it's a baby giant.
For that reason, if one trunking switch is using ISL and its remote partner
is not, the remote partner will consider the ISL-encapsulated frames as
giants. (?)
In contrast to ISL, dot1q plays well with others.
The only additional overhead dot1q places onto a frame is a 4-byte
header, resulting in less overhead than ISL and resulting in a maximum
frame size of 1522 bytes. If the frame is destined for the native VLAN,
even that small header isn't added.
Since the dot1q tag is only 4 bytes in size, and isn't even placed on every
frame, using dot1q lessens the chance of oversized frames. When the
remote switch receives an untagged frame, the switch knows that these
untagged frames are destined for the native VLAN.
Other dot1q facts you should be familiar with:
Dot1q actually embeds the tagging information into the frame itself.
You'll occasionally hear dot1q referred to as internal tagging.
Dot1q is the "open standard" or "industry standard" trunking protocol
and is suitable for a multivendor environment.
Since dot1q adds only one tag, it's sometimes called "single tagging"
Note: There's a 4-byte addition in both ISL and dot1q, but they're located
in different parts of the frame:
ISL: 4-byte trailer (with CRC value)
dot1q: 4-byte tag inserted into the frame
Troubleshooting Trunks
I've created a lot of trunks over the years, and I've bumped into quite a
few real-world "gotchas" to share with you.
For trunks to work properly, the port speed and port duplex setting
should be the same on the two trunking ports. ISL switches don't
care about the native VLAN setting, because they don't use the
native VLAN to begin with.
Giants are frames that are larger than 1518 bytes, and these can
occur on ISL since ISL adds 30 overall bytes to the frame. Some
Catalyst switches have Cisco-proprietary hardware that allows them
to handle the larger frames. Check the documentation for your
switch to see if this is the case for your model.
Dot1q does add 4 bytes to the frame, but thanks to IEEE 802.3ac,
the maximum frame length can be extended to 1522 bytes. (The
opposite of a giant is a runt. While giants are too large to be
successfully transmitted, runts are frames less than 64 bytes in size.)
Both switches must be in the same VTP domain for a trunk to form.
Watch those domain names, they're case-sensitive. It's also
possible to form a trunk between two switches that don't belong to
any VTP domain, but they both have to not belong to one.
If you're working on a multilayer switch (also called a "Layer 3
switch"), make sure the port you want to trunk is a Layer 2 port by
configuring the interface-level command switchport on that port.
You can configure a 10, 100, or 1000 Mbps interface as a trunk.
Changing the native VLAN on one switch does not dynamically
change the native VLAN on a remote trunking partner.
Most Cisco switches used to support both ISL and dot1q, but that is no
longer the case. For example, the popular 2950 switches don't support
ISL. Make sure to check Cisco's online documentation site at
www.cisco.com/univercd for a particular switch model if you must have
one particular trunking protocol.
How Do Access Ports Handle Encapsulation And Tagging?
Easy -- they don't. Since access ports belong to one and only one VLAN,
there's no need to encapsulate or tag them with VLAN ID information.

Changing The Native VLAN
By default, the native VLAN is VLAN 1. The native VLAN is the VLAN the
port will belong to when it is not trunking.
The native vlan can be changed with the switchport trunk native vlan
command, but you should be prepared for an error message very quickly
after configuring it on one side of the trunk. We'll change the native vlan
setting on fast 0/11 on one side of an existing trunk and see what
happens.
SW1(config-if)#switchport trunk native vlan 12
1d21h: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer
vlan id 1 on FastEthernet0/11 VLAN12.
1d21h: %SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet0/11 on VLAN0001.
Inconsistent peer vlan.
1d21h: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/11 on
VLAN0012. Inconsistent local vlan.

1d21h: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on
FastEthernet0/11 (12), with SW2 FastEthernet0/11 (1).
SW1#show int fast 0/11 trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 12
The trunk itself doesn't come down, but those error messages will
continue until you have configured the native vlan on the remote switch
port to be the same as that on the local port it's trunking with.
When you're running dot1q, your choice of native VLAN is particularly
important, since dot1q doesn't tag frames destined for the native VLAN.
Manually Configuring Trunking Protocols
To manually configure a trunk port to run ISL or dot1q, use the switchport
trunk encapsulation command.
Rack1SW1(config-if)#switchport trunk encapsulation ?
dot1q Interface uses only 802.1q trunking encapsulation when trunking
isl Interface uses only ISL trunking encapsulation when trunking
negotiate Device will negotiate trunking encapsulation with peer on
interface
Notice that there's a third option, negotiate. The trunk ports will then
negotiate between ISL and dot1q, and naturally it must be a protocol that
both ports support. If the negotiating ports support both protocols, ISL will
be selected.
By the way, if you use IOS Help to display your switch's encapsulation
choices, and there aren't any, that's a pretty good sign that your switch
supports only dot1q!
SW1(config)#interface fast 0/11
SW1(config-if)#switchport trunk encapsulation ?
% Unrecognized command
There's a third trunking protocol we need to be aware of. The Dynamic
Trunking Protocol is a Cisco-proprietary point-to-point protocol that
actively attempts to negotiate a trunk line with the remote switchport. This
sounds great, but there is a cost in overhead - DTP frames are
transmitted every 30 seconds.
If you decide to configure a port as a non-negotiable trunk port, there's no
need for the port to send DTP frames. Also, if there's a device on the
other end of the line that can't trunk at all - a firewall, for example - there's
no need to send DTP frames.
DTP can be turned off at the interface level with the switchport
nonegotiate command, but as you see below, you cannot turn DTP off
until the port is no longer in dynamic desirable trunking mode.
SW2(config)#int fast 0/8
SW2(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.
SW2(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
SW2(config-if)#switchport mode trunk
SW2(config-if)#switchport nonegotiate
You can verify DTP operation (or non-operation) with show dtp.
SW1#show dtp
Global DTP information
Sending DTP Hello packets every 30 seconds
Dynamic Trunk timeout is 300 seconds
4 interfaces using DTP
There is a show dtp interface command as well, but it's extremely
verbose. It will show you which interfaces are running DTP, which the
basic show dtp command will not do.
While we've got those trunking modes in front of us, let's examine exactly
what's going on with each one.
Trunk mode means just that - this port is in unconditional trunk mode and
cannot be an access port. Since this port cannot negotiate, it's standard
procedure to place the remote trunk port in trunk mode.
Turning off DTP when you place a port in trunk mode is a great idea,
because there's no use in sending negotiation frames every 30 seconds if
no negotiation is necessary.
Dynamic desirable is the default setting for most Cisco switch ports
today. If the local switch port is running dynamic desirable and the
remote switch port is running in trunk, dynamic desirable, or dynamic
auto, a trunk will form. This is because a port in dynamic desirable mode
is sending and responding to DTP frames.
If you connect two 2950s with a crossover cable, a trunk will form in less
than 10 seconds with no additional configuration needed.
Dynamic auto is the "oddball" trunking mode. A port configured as
dynamic auto (often called simply "auto") will not actively negotiate a
trunk, but will accept negotiation begun by the remote switch. As long as
the remote trunk port is configured as dynamic desirable or trunk, a trunk
will form.
It's important to note that the trunk mode does not have to match between
two potential trunk ports. One port could be in dynamic desirable and the
other in trunk mode, and the trunk would come up.
Is there a chance that two ports that are both in one of these three modes
will not successfully form a trunk? Yes - if they're both in dynamic auto
mode.
You can expand the show interface trunk command we examined earlier
in this section to view the trunking mode of a particular interface. Port
0/11 is running in dynamic desirable mode.

We can change the mode with the switchport mode command. By
changing the port to trunk mode, the mode is "on".
SW2(config)#int fast 0/11
SW2(config-if)#switchport mode trunk


SW2#show interface fast 0/11 trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/11 1-4094
Port Vlans allowed and active in management domain
Fa0/11 1
Port Vlans in spanning tree forwarding state and not pruned
Fa0/11 1
When we looked at the options for switchport mode, did you notice that
there is no "off" setting?
SW2(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
When a port is configured as an access port, that unconditionally turns
trunking off. switchport mode access is the command that turns trunking
off. Here's the show interface trunk command displaying the information
for the port leading to HOST 1 after configuring the port as an access
port.
SW1#show interface fast 0/1 trunk
Port Mode Encapsulation Status Native vlan
Fa0/1 off 802.1q not-trunking 1
Port Vlans allowed on trunk
Fa0/1 12
Port Vlans allowed and active in management domain
Fa0/1 12
Port Vlans in spanning tree forwarding state and not pruned
Fa0/1 12
Through the various show commands we've used in this section, you
might have noticed that trunk ports allow traffic for VLANs 1 - 4094 to
cross the trunk line. This is the default, but it can be changed with the
switchport trunk allowed vlan command. The various options with this
command do take a little getting used to, so let's take a closer look at
them.
SW1(config-if)#switchport trunk allowed vlan ?
WORD VLAN IDs of the allowed VLANs when this port is in trunking mode
add add VLANs to the current list
all all VLANs
except all VLANs except the following
none no VLANs
remove remove VLANs from the current list
except - Follow this option with the VLANs whose traffic should not be
allowed across the trunk. We'll configure interface fast 0/11 and 0/12 to
not trunk for VLAN 1000 and look at the results with show interface trunk.
SW1(config)#interface fast 0/11
SW1(config-if)#switchport trunk allowed vlan except 1000
SW1(config-if)#interface fast 0/12
SW1(config-if)#switchport trunk allowed vlan except 1000
SW1#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 1
Fa0/12 desirable 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/11 1-999,1001-4094
Fa0/12 1-999,1001-4094
Port Vlans allowed and active in management domain
Fa0/11 1,12
Fa0/12 1,12
Port Vlans in spanning tree forwarding state and not pruned
Fa0/11 1,12
Fa0/12 12
VLAN 1000 is not allowed to trunk through interfaces fast 0/11 and fast
0/12. To allow VLAN 1000 to trunk through these interfaces again, we'll
use the add option of this command. (To remove additional VLANs, we
would use remove.)
SW1(config)#int fast 0/11
SW1(config-if)#switchport trunk allowed vlan add 1000
SW1(config-if)#int fast 0/12
SW1(config-if)#switchport trunk allowed vlan add 1000

SW1#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 1
Fa0/12 desirable 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/11 1-4094
Fa0/12 1-4094
Port Vlans allowed and active in management domain
Fa0/11 1,12
Fa0/12 1,12
Port Vlans in spanning tree forwarding state and not pruned
Fa0/11 1,12
Fa0/12 12
VLAN 1000 is again allowed to trunk through these two interfaces.
The more drastic choices are all and none. To disable trunking for all
VLANs, the none option would be used. To enable trunking for all VLANs
again, we'll use the all option.
SW1(config)#int fast 0/11
SW1(config-if)#switchport trunk allowed vlan none
SW1(config-if)#int fast 0/12
SW1(config-if)#switchport trunk allowed vlan none

SW1#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 1
Fa0/12 desirable 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/11 none
Fa0/12 none
Port Vlans allowed and active in management domain
Fa0/11 none
Fa0/12 none
Port Vlans in spanning tree forwarding state and not pruned
Fa0/11 none
Fa0/12 none
SW1(config)#int fast 0/11
SW1(config-if)#switchport trunk allowed vlan all
SW1(config-if)#int fast 0/12
SW1(config-if)#switchport trunk allowed vlan all

SW1#show interface trunk
Port Mode Encapsulation Status Native vlan
Fa0/11 desirable 802.1q trunking 1
Fa0/12 desirable 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/11 1-4094
Fa0/12 1-4094
Port Vlans allowed and active in management domain
Fa0/11 1,12
Fa0/12 1,12
Port Vlans in spanning tree forwarding state and not pruned
Fa0/11 none
Fa0/12 none

Naming VLANs
You can give your VLAN a more intuitive name with the name command.
SW1(config)#vlan 10
SW1(config-vlan)#name ENGINEERING
Running show vlan brief verifies that the VLAN has been named...
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/13, Fa0/14
Fa0/15, Fa0/16, Fa0/17, Fa0/18
Fa0/19, Fa0/20, Fa0/21, Fa0/22
Fa0/23, Fa0/24
10 ENGINEERING active
... but if you want to further configure the VLAN, you must do so by
number, not by name.
SW1(config)#vlan ENGINEERING
Command rejected: Bad VLAN list - character #1 is a non-numeric
character ('E').

SW1(config)#vlan 10
SW1(config-vlan)#
VLAN Database Mode
You'll notice that all of the configurations in this study guide use the CLI
commands to configure VLANs. There is a second way to do so, and
that's using VLAN database mode.
I personally don't like using this mode, because it's very easy to save your
changes incorrectly - which of course means that your changes aren't
saved! It's always a good idea to know how to do something more than
one way in Ciscoland, though, so let's take a look at this mode. You enter
this mode by typing vlan database at the command prompt.
SW1#vlan database
SW1(vlan)#
The prompt changed appropriately, so let's create VLAN 30.
SW1(vlan)#vlan 30
VLAN 30 added:
Name: VLAN0030
No problem! Let's exit this mode the way we always do, by using ctrl-z,
and then verify the creation of the VLAN. To save some room, I'll show all
VLANs except VLAN 1.
SW1(vlan)#^Z
SW1#show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------

10 ENGINEERING active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
Do you see a VLAN 30 there? I sure don't. And no matter how many
times you do what we just did, you'll never see VLAN 30 - because vlan
database mode requires you to type APPLY to apply your changes, or to
type EXIT to leave this mode and save changes. I'll do both here, and
notice that when you exit by typing EXIT, the APPLY is, well, applied!
SW1(vlan)#vlan 30
VLAN 30 added:
Name: VLAN0030
SW1(vlan)#apply
APPLY completed.
SW1(vlan)#exit
APPLY completed.
Exiting....
SW1#show vlan br
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------

10 ENGINEERING active
30 VLAN0030 active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active
Cisco switches were actually giving a message a few years ago anytime
you used the vlan database command that this mode was being phased
out. I imagine they got tired of helpdesk calls from people who didn't
know about the EXIT and APPLY. (Did you notice that when we left this
mode with ctrl-z, the switch didn't tell us the changes were not being
applied?)
Cisco seems to have changed their minds about getting rid of this mode,
and while you probably won't see it on your exam, it's a good idea to know
these details for dealing with real-world networks.
VLAN Design
Learning to design anything from a class or study guide can be frustrating,
because like snowflakes, no two networks are alike. What works well for
"Network A" may be inefficient for "Network B". You need to know about
the following VLAN design types for both the exam and the real world, but
as always you've got to be able to apply your critical thinking skills
knowledge to your particular real-world network's needs.
In my CCNP ROUTE Study Guide's discussion of Cisco's Three-Layer
Hierarchical Networking Model, I mention that it's important to let the
Distribution layer handle the "little things" in order to allow the core
switches to do what they do best - switch!
With VLAN design, we're looking at much the same scenario. If we don't
control broadcast and multicast traffic, it can soon affect our network
negatively, particularly if we allow it to flow through the core switches.
Your VLAN scheme should keep as many broadcasts and multicasts
away from the core switches as is possible.
There are two major VLAN designs, end-to-end and local. Watch the
details here, as one is following the 80/20 rule and the other is following
the 20/80 rule.
End-to-End and Local VLANs
With end-to-end VLANs, the name is the recipe as end-to-end VLANs will
span the entire network. The physical location of the user does not
matter, as a user is assigned to a single VLAN, and that VLAN will remain
the same no matter where the user is.
The very nature of an end-to-end VLAN and its spanning of the entire
network makes working with this VLAN type a challenge, to say the least.
End-to-end VLANs can come in handy as a security tool and/or when the
hosts have similar resource requirements - for example, if you had certain
hosts across the network that needed access to a particular network
resource, but you didn't even want your other hosts to know of the
existence of that resource.
End-to-end VLANs should be designed with the 80/20 rule in mind, where
80 percent of the local traffic stays within the local area and the other 20
percent will traverse the network core en route to a remote destination.
End-to-end VLANs must be accessible on every access-layer switch
to accommodate mobile users.
Many of today's networks don't lend themselves well to this kind of
configuration. The following network diagram is simplified, but even this
network would be difficult to configure with end-to-end VLANs if the hosts
need connectivity to the Internet and/or corporate servers located across
a WAN. With Internet access becoming more of a requirement than a
luxury for today's end users, 80/20 traffic patterns aren't seen as often as
they once were.


Local VLANs are designed with the 20/80 rule in mind. Local VLANs
assume that 20 percent of traffic is local in scope, while the other 80
percent will traverse the network core. While physical location is
unimportant in end-to-end VLANs, users are grouped by location in Local
VLANs.
More and more networks are using centralized data depositories, such as
server farms - and even in the simplified network diagram above, the end
user must go across a WAN to reach the server farm, another reason that
80/20 traffic patterns aren't seen as often as they were in the past.
The Mystery And Mayhem Of The VLAN.DAT File
I always say that you should never practice your CCNP skills at work -
and that is definitely true with this part of the course. Having said that, I
get regular emails from CCNP candidates working with home labs that run
into an interesting and/or frustrating situation. Let's take a look at the
situation first and then come up with a solution.
Let's say you've been practicing on a Cisco switch and decide to erase
the config. You were working with three VLANs...
SW1#show vlan brief
VLAN Name
---- ------------------
1 default

100 VLAN0100
200 VLAN0200
300 VLAN0300
... and you want to start your labs over, which means getting rid of those
VLANs. You run write erase to erase the switch startup config and then
reload the switch...
SW1#write erase
Erasing the nvram filesystem will remove all configuration file
firm]
[OK]
Erase of nvram: complete
SW1#
2d22h: %SYS-7-NV_BLOCK_INIT: Initalized the geometry of nvram
SW1#reload
Proceed with reload? [confirm]
.. and since there's no startup configuration, you're prompted to go into
Setup Mode when the switch comes back up.
Would you like to enter the initial configuration dialog? [yes/no]:
After answering no, we're placed at the user exec prompt. We put a few
basic commands on the switch...
Switch>enable
Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z
Switch(config)#hostname SW1
SW1(config)#line con 0
SW1(config-line)#logging synchronous
SW1(config-line)#exec-t 0 0
SW1(config-line)#^Z
SW1#wr
Building configuration...
[OK]
SW1#
... and just to verify, we run show vlan brief...
SW1#show vlan brief
VLAN Name
---- --------------
1 default

100 VLAN0100
200 VLAN0200
300 VLAN0300
... and the VLANs are still there.
The first time you run into this, you might think you somehow erased the
config incorrectly, so you do it again. At least I did. But I don't care how
many times you erase the router config, those VLANs are still gonna be
there.
Why?
The file that contains the actual VLAN information isn't the startup config
file - it's the VLAN.DAT file, contained in Flash. (For clarity's sake, I've
removed the date you'll see next to each file name.)
SW1#show flash
Directory of flash:/
2 -rwx 2980731 c2950-i6q4l2-mz.121-19.EA1c.bin
3 -rwx 962 config.text
4 -rwx 317 env_vars
5 -rwx 5 private-config.text
6 -rwx 736 vlan.dat
7 -rwx 110 info
8 drwx 2432 html
85 -rwx 110 info.ver

It's actually the VLAN.DAT file you need to erase to get rid of your
switch's VLAN information. The command to do so isn't difficult at all, but
the prompt is a little tricky.
The command is delete vlan.dat:
SW1#delete vlan.dat
Delete filename [vlan.dat]?
As you'd expect, you're asked whether you really want to delete that
particular file. Do NOT answer "yes" or "y" - just hit the Enter key to
accept the default answer contained in the brackets. After you do that,
you're asked one more question:
SW1#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
You're then asked to confirm the delete. Again, don't answer "Y" or "yes"
- just accept the default answer by hitting the Enter key.
SW1#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
SW1#
You won't see a "file deleted" message - you'll just be put back at the
prompt.
If you don't have a vlan.dat file in Flash, you will see this message:
SW1#delete vlan.dat
Delete filename [vlan.dat]?
Delete flash:vlan.dat? [confirm]
%Error deleting flash:vlan.dat (No such file or directory)
Now, you're probably thinking I made a pretty big deal out of accepting
those default answers and not entering "yes". And you're right, I did - and
here's why:
SW1#delete vlan.dat
Delete filename [vlan.dat]? y
Delete flash:y? [confirm]
%Error deleting flash:y (No such file or directory)
If you answer "Y" to "Delete filename?", you're telling the IOS to delete a
file actually named "y", which is not going to give us the results we want.
After deleting the vlan.dat file, reloading the switch, and adding the same
commands as we did before ...
SW1#show vlan brief
VLAN Name
---- ------------------------
1 default

1002 fddi-default
1003 token-ring-default
1004 fddinet-default
1005 trnet-default
.. the VLANs are truly gone!
Here's a link to a video on my YouTube Cisco Certification Video Channel
that shows this information on a live Cisco switch.
http://bit.ly/c7wx5G
You can also find over 400 free Cisco CCNA and CCNP videos on my
YouTube channel:
http://www.youtube.com/user/ccie12933
Enjoy!
Copyright 2010 The Bryant Advantage. All Rights Reserved.