Welcome

Free Additional Resources
Dedication
VLANs
VTP
STP Basics
Advanced Spanning Tree
Advanced Spanning Tree
Security
Multlayer Switching And HighAvailability Services
Intro To Voice VLANs

Intro To Wireless
Network Design and Models
Queueing and Compression
Multicasting
AAA
Exam Detail Review
Hex Conversion Workbook
Command Reference
Cisco Simulator Success Tips
Legal Notices

Welcome to your Bulldog Study
Guide for the CCNP SWITCH
exam!
I know you’re anxious to get
started, so I’ll keep this short…
Your CCNP SWITCH exam prep
requires you to tackle some
complex subjects, with
multilayer switching and
advanced switching features
among them.
In this guide, you’ll find clear
and comprehensive
explanations for each and every

one of these topics, along with
hundreds of illustrations and
configs from live Cisco
switches.
(I do not use simulators in my
books or videos.)
Speaking of videos, I’ve added
a special feature to this ebook
that’s guaranteed to help you
master these complex
concepts.
And just as exciting, these
features don’t cost anything!

At the end of each section,
you’ll find links to videos on my
YouTube computer certification
video training channel that are
related to the topic you just
studied.
You’ll find Video Practice
Exams, 5-minute Video Boot
Camps, and other video types all of which will help you nail
this difficult exam.
You’ll also find links to free
training sessions from my 22hour CCNP SWITCH Video Boot
Camp, available on both DVD

and in downloadable format.
The full course is not quite free,
but in a world of $500 video
courses, you’ll find the price to
be quite refreshing.
I also invite you to join me on
Twitter, Facebook, LinkedIn,
and other social media sites.
I’m there live every day and
happy to chat with you there!
Let’s get started …
… and as always, thanks for
making TBA part of your CCNP

success story!
Chris Bryant

CCIE #12933
“The Computer Certification
Bulldog”
chris@thebryantadvantage.com

Website:
http://www.thebryantadvantage.

Twitter:
http://www.twitter.com/ccie1293
Facebook:
http://on.fb.me/gPq52d

Blog:
http://thebryantadvantage.blogs
YouTube:

http://www.youtube.com/user/cc

Free Resources To
Help You Pass The
CCNP SWITCH Exam!
In addition to this informationpacked CCNP SWITCH Study
Guide, TBA has literally dozens
of additional practice exams,
Video Boot Camps, and
illustrated tutorials to help you
destroy this exam!
First, for some videos….

My YouTube Computer
Certification Channel has quite
a few videos on the CCNP
SWITCH exam:

http://www.youtube.com/user/cc
I hope you’ll click “subscribe”
while you’re out there - I’m
adding new videos AND
certifications on a regular basis,
including Security+ and new
CCNA Security course in 2012,
and then it’s on to the new
Microsoft 2012 certifications!
You’ll also find links to

individual videos on that
channel at the end of most
chapters of this ebook.
I have a separate Videos &
Tutorials page on my website
for each of the CCNP exams here’s the page dedicated to
SWITCH:

http://www.thebryantadvantage.
Be sure to scroll ALL the way
down that page - there are
links to practice exams,
tutorials, and Video Boot
Camps!

For future reference, or for
review, here are my pages for
the ROUTE and TSHOOT
exams:
ROUTE

http://www.thebryantadvantage.
TSHOOT:

http://www.thebryantadvantage.
You can also watch a full and
free hour of my CCNP SWITCH
Bulldog Video Boot Camp on
Udemy.com:

http://www.udemy.com/ccnpswitch-video-boot-camp/
That same course is available
on DVD on my website as well
as Amazon.com!
When I post new videos or
tutorials, or whenever there’s
important news in the
computer certification world, I
always post it on our Facebook
and Twitter feeds as well as the
Bulldog Blog.
I urge you to click these links
and join us!

We have some great
conversations and the
occasional giveaway out there - and if you have a question or
comment, just send it via
Twitter or leave it on Facebook!
I’m always happy to hear from
you!

Twitter:
http://www.twitter.com/ccie1293
Facebook:
http://on.fb.me/gPq52d

Bulldog Blog:
http://thebryantadvantage.blogs

Use all of these resources in
addition to this study guide and thanks for making TBA part
of your CCNP success story!

Chris Bryant
CCIE #12933
“The Computer Certification
Bulldog”

Dedication
Respectfully dedicated to the
late Harry Chapin and his
tireless efforts to fight world
hunger.

Visit http://feedingamerica.org/
to learn how you can help!
(Literally, every dollar helps they turn $1 into 5 meals!)

Photo source: Cindy Funk (via
Wikipedia)

Virtual LANs (VLANs)
Be sure to watch the free VLAN
videos from my YouTube and
Udemy channels linked at the
end of this section!
Cliche #1: “If you don’t use it,
you lose it.”
Cliche #2: “Cliches become
cliches because more often
than not, they’re true.”

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 realworld 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.

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.

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.

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
fastO/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 O/1 and O/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.

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.

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-topoint 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…

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 dotlq, 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 (“dotlq”), and
DTP
ISL and dotlq are both point-topoint 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 dotlq.
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. Dotlq 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 ever/frame.
The 26-byte header that is
added to the frame by ISL
contains the VLAN ID; the 4byte 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, dotlq plays
well with others.
The only additional overhead
dotlq 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 dotlq tag is only 4
bytes in size, and isn’t even
placed on every frame, using
dotlq 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 dot1 q facts you should
be familiar with:
Dotlq actually embeds
the tagging information
into the frame itself.

You’ll occasionally hear
dotlq referred to as
internal tagging.
Dotlq is the “open
standard” or “industry
standard” trunking
protocol and is suitable
for a multivendor
environment.
Since dotlq adds only
one tag, it’s sometimes
called “single tagging”
Note: There’s a 4-byte addition
in both ISL and dotlq, but
they’re located in different
parts of the frame:

ISL: 4-byte tra/ler’(with
CRC value)
dotlq: 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.

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
dotlq doesn’t tag frames
destined for the native VLAN.

Manually Configuring
Trunking Protocols
To manually configure a trunk
port to run ISL or dotlq, use the
switchport trunk encapsulation
command.

Notice that there’s a third
option, negotiate. The trunk
ports will then negotiate
between ISL and dotlq, 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 lOS Help
to display your switch’s
encapsulation choices, and
there aren’t any, that’s a pretty
good sign that your switch
supports only dotlq!

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.

You can verify DTP operation
(or non-operation) with show
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”.

When we looked at the options
for switchport mode, did you
notice that there is no “off”
setting?

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.

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.

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.

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.)

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.

Naming VLANs
You can give your VLAN a more
intuitive name with the name
command.

Running show vlan brief verifies
that the VLAN has been
named…

… but if you want to further
configure the VLAN, you must
do so by number, not by name.

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.

The prompt changed
appropriately, so let’s create
VLAN 30.

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.

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!

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-toend 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-toend 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 accesslayer 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…

… 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…

…and since there’s no startup
configuration, you’re prompted
to go into Setup Mode when
the switch comes back up.

After answering no, we’re
placed at the user exec prompt.
We put a few basic commands
on the switch…

… and just to verify, we run
show vlan brief…

… 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.)

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.

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:

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.

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:

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:

If you answer “Y” to “Delete
filename?”, you’re telling the
lOS 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 …

…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/cc
Here are more free videos I
know you’ll find helpful in your
CCNP
SWITCH studies!
From my YouTube channel:
Static and dynamic VLANs:

http://bit.ly/tCgetc
The mysterious VLAN.DAT file:
http://bit.ly/9FhpE9
VLANs and VTP:
http://bit.ly/dkGVJL
From my CCNP SWITCH course
on Udemy.com:
Root bridges, BPDUs, and a
whole lot more:

http://www.udemy.com/lectures/
and-root-bridae-election-

fundamentals-43929
Path Costs, STP port states,
and again, a LOT more:

http://www.udemy.com/lectures/
bridqe-or-not-path-costs-andstp-port-states-43930

VLAN Trunking
Protocol (VTP)
As a CCNP candidate, you know
that when it comes to Cisco
technologies, there’s always
something new to learn! You
learned about the VLAN
Trunking Protocol (VTP) in your
CCNA studies, but now we’re
going to review a bit and then
build on your knowledge of

both of these important
switching technologies.

Why Do We Need VTP?
VLAN Trunking Protocol (VTP)
allows each switch in a network
to have an overall view of the
active VLANS. VTP also allows
network administrators to
restrict the switches upon
which VLANs can be created,
deleted, or modified.
In our first example, we’ll look
at a simple two-switch setup

and then add to the network to
illustrate the importance of
VTP.

Here, the only two members of
VLAN 10 are found on the same

switch. We can create VLAN 10
on SW1, and SW2 really doesn’t
need to know about this new
VLAN.

We know that the chances of all
the hosts in a VLAN being on
one switch are very remote!
More realistic is a scenario like
the following, where the center
or “core” switch has no ports in

a certain VLAN, but traffic
destined for that VLAN will be
going through that very core
switch.

SW2 doesn’t have any hosts in
VLAN 10, but for VLAN 10 traffic

to successfully travel from SW1
to SW3 and vice versa, SW2
has to know about VLAN 10’s
existence.
SW2 could be configured
manually with VLAN 10, but
that’s going to get very old very
fast. Considering that most
networks have a lot more than
three switches, statically
configuring every VLAN on
every switch would soon take
up a lot of your time, as would
troubleshooting the network
when you invariably leave a
switch out!

Luckily, the major feature of
VTP is the transmission of VTP
advertisements that notify
neighboring switches in the
same domain of any VLANs in
existence on the switch sending
the advertisements.
The key phrase there is “in the
same domain”. By default,
Cisco switches are not in a VTP
domain. Before working with
VTP in a home lab or
production network, run show
vtp status. (The official term for
a VTP domain is “management
domain”, but we’ll just call

them domains in this section.
The only place you’ll probably
see that full phrase is on the
exam.)

There’s nothing next to “VTP
Domain Name”, so a VTP
domain has not yet been
configured. We’ll now change
that by placing this switch into
a domain called CCNP. Watch
this command - it is case

sensitive. By far, a mistyped
VTP domain name is the #1
reason your network’s switches
aren’t seeing the VLANs you
think they should be seeing.
What are the other reasons?
You’ll see later in this section.
Let’s get that VTP domain set….

After configuring the VTP

domain “CCNP” on SW2, SW1 is
also placed into that domain.
Each switch can now
successfully advertise its VLAN
information to the other, and as
switches are added to this VTP
domain, those switches will
receive these advertisements
as well.
A Cisco switch can belong to
one and only one VTP domain.

VTP Modes
In the previous show vtp status

readouts, the VTP Operating
Mode is set to Server. The more
familiar term for VTP Operating
Mode is simply VTP Mode, and
Server is the default. It’s
through the usage of VTP
modes that we can place limits
on which switches can delete
and create VLANs.

It’s not unusual for edge

switches such as SW1 and SW3
to be available to more people
that they should be. If SW2 is
the only switch that’s physically
secure, SW2 should be the only
VTP Server. Let’s review the
VTP Modes and then configure
SW1 and SW3 appropriately.
In Server mode, a VTP switch
can be used to create, modify,
and delete VLANs. This means
that a VTP deployment has to
have at least one Server, or
VLAN creation will not be
possible. This is the default
setting for Cisco switches.

Switches running in Client
mode cannot create, modify, or
delete VLANs. Clients do listen
for VTP advertisements and act
accordingly when VTP
advertisements notify the Client
of VLAN changes.
VTP Transparent mode actually
means that the switch isn’t fully
participating in the VTP
domain. (Bear with me here.)
Transparent VTP switches don’t
synchronize their VTP
databases with other VTP
speakers; they don’t even

advertise their own VLAN
information. Therefore, any
VLANs created on a
Transparent VTP switch will not
be advertised to other VTP
speakers in the domain, making
them locally significant only.
For that reason, using
Transparent VTP mode is
another of the three major
reasons I’ve run into that your
VLANs aren’t being advertised
as thoroughly as you’d like. The
first reason was a mistyped
password - and number three is
coming up.

This mode can come in handy
in certain situations, but be
aware of the differences
between Transparent and
Server mode.
There are two versions of VTP,
V1 and V2, and the main
difference between the two
versions affects how a VTP
Transparent switch handles an
incoming VTP advertisement.
VTP Version 1: The Transparent
switch will forward that
advertisement’s information
only if the VTP version number

and domain name on that
switch is the same as that of
downstream switches.
VTP Version 2: The Transparent
switch will forward VTP
advertisements via its trunk
port(s) even if the domain
name does not match.
To ensure that no one can
create VLANs on SW1 and SW3,
we’ll configure both of them as
VTP Clients. SWI’s configuration
and the resulting output of
show vtp status is shown
below.

Attempting to create a VLAN on
a VTP client results in the
following message:

This often leads to a situation
where only the VTP Clients will
have ports that belong to a yetto-be-created VLAN, but the

VLAN still has to be created on
the VTP Server. VLANs can be
created and deleted in
Transparent mode, but those
changes aren’t advertised to
other switches in the VTP
domain. Also, switches do not
advertise their VTP mode.

Which Switches Should
Be Servers, Which
Should Be Clients?
You have to decide this for
yourself in your production
network, but I will share a

simple method that’s always
worked for me - if you can
physically secure a switch,
make it a VTP server. If
multiple admins will have
access to the switch, you may
consider making that switch a
VTP Client in order to minimize
the chance of unwanted or
unauthorized changes being
made to your VLAN scheme.

The VTP Advertisement
Process
VTP Advertisements are

multicasts, but they are not
sent out every port on the
switch. The only devices that
need the VTP advertisements
are other switches that are
trunking with the local switch,
so VTP advertisements are sent
out trunk ports only. The hosts
in VLAN 10 in the following
exhibit would not receive VTP
advertisements.

Along with the VTP domain
name, VTP advertisements
carry a configuration revision

number that enables VTP
switches to make sure they
have the latest VLAN
information. VTP
advertisements are sent when
there has been a change in a
switch’s VLAN database, and
this configuration revision
number increments by one
before it is sent. To illustrate,
let’s look at the revision
number on Sw1.

The current revision number is
1. We’ll now go to R2 to check
the revision number, add a
VLAN, and then check the
revision number again.

The revision number was 1,
then a VLAN was added. The
revision number incremented to
2 before the VTP advertisement
reflecting this change was sent
to this switch’s neighbors. Let’s
check the revision number on

SW1 now.

The revision number has
incremented to 2, as you’d
expect. But what exactly
happened?
SW1 received a VTP
advertisement from SW2.
Before accepting the changes
reflected in the advertisement,
SW1 compares the revision
number in the advertisement to

its own revision number. In this
case, the revision number on
the incoming advertisement
was 2 and SWI’s revision
number was 1.
This indicates to SW1 that the
information contained in this
VTP advertisement is more
recent than its own VLAN
information, so the
advertisement is accepted.
If SW1’s revision number had
been higher than that in the
VTP advertisement from SW2,
the advertisement would have

been ignored.
In the following example, SW2
is sending out an
advertisement with
revision number 300. The three
switches are running VLANs 10,
20, 30, 40, and 50, and
everything’s just fine. The VTP
domain is CCNP.

Now, a switch that was at
another client site is brought to
this client and installed in the
CCNP domain. The problem is
that the VTP revision number
on the newly installed switch is
500, and this switch only knows

about the default VLAN, VLAN
1.

The other switches will receive
a VTP advertisement with a
higher revision number than
the one currently in their VTP
database, so they’ll synchronize

their databases in accordance
with the new advertisement.
The problem is that the new
advertisements don’t list VLANs
10, 20, 30, 40, or 50, so
connectivity for those VLANs is
lost.
I’ve seen this happen with
switches that were brought it to
swap out with an out-of-service
switch. That revision number
has to be reset to zero! If you
ever see VLAN connectivity
suddenly lost in your network,
but the switches are all
functional, you should

immediately check to see if a
new switch was recently
installed. If the answer is yes, I
can practically guarantee that
the revision number is the
issue.
Cisco theory holds that there
are two ways to reset a switch’s
revision number to zero:
1. Change the VTP
domain name to a
nonexistent
domain, then
change it back to
the original name.

2. Change the VTP
mode to
Transparent, then
change it back to
Server.
In reality, resetting this number
can be more of an art form
than a science. The method to
use often depends on the
model. In the real world, you
should use your favorite search
engine fora phrase such as
reset configuration revision
number zero followed by the
switch model.

Reloading the switch won’t do
the job, because the revision
number is kept in NVRAM, and
the contents of Non-Volatile
RAM are kept on a reload.
It’s a good practice to perform
this reset with VTP Clients as
well as Servers. In short, every
time you introduce a switch to
your network and that switch
didn’t just come out of the box,
perform this reset. And if it did
come out of the box, check it
anyway. ;)
To see the number of

advertisements that have been
sent and received, run show vtp
counters.

I’m sure you noticed that there
are different types of
advertisements! There are
three major types of VTP
advertisements - here’s what
they are and what they do.
Keep in mind that Cisco

switches only accept VTP
advertisements from other
switches in the same VTP
domain.
Summary Advertisements are
transmitted by VTP Servers
every 5 minutes, or upon a
change in the VLAN database.
Information included in the
summary advertisement:
VTP domain name and
version
Configuration revision
number
MD5 hash code

Timestamp
Number of subset
advertisements that will
follow this ad
Subset Advertisements are
transmitted by VTP Servers
upon a VLAN configuration
change. Subset ads give
specific information regarding
the VLAN that’s been changed,
including:
Whether the VLAN was
created, deleted,
activated, or suspended
The new name of the

VLAN
The new Maximum
Transmission Unit
(MTU)
VLAN Type (Ethernet,
Token Ring, FDDI)
Client Advertisement Requests
are just that - a request for
VLAN information from the
client. Why would a client
request this information? Most
likely because the VLAN
database has been corrupted or
deleted. The VTP Server will
respond to this request with a
series of Summary and Subset

advertisements.

Configuring VTP Options
Setting a VTP password is
optional, as is a little
something called VTP Pruning and they’re considered vital in
many of today’s real-world
networks. Let’s take a look at
both, starting with the VTP
password.
Earlier in this section, you saw
how to place a switch into a
VTP domain:

The VTP mode is changed with
the vtp mode command.

VTP allows us to set a
password as well. Naturally, the
same password should be set
on all switches in the VTP
domain. Although this is
referred to as secure VTP,
there’s nothing secure about it the command show vtp
password displays the

password, and this password
can’t be encrypted with service
password-encryption.

And as you’ve likely already
guesses, a mistyped VTP
password is the third of the
three reasons your VLANs
aren’t being properly
advertised. To recap:
1. Mistyped VTP
Domain (by far the
most common

reason)
2. Not realizing you
have a Transparent
mode VTP switch in
your network (rare)
3. Mistyped VTP
Password

VTP Pruning
Trunk ports belong to all VLANs,
which leads to an issue
involving broadcasts and
multicasts. A trunk port will
forward broadcasts and
multicasts for all VLANs it

knows about, regardless of
whether the remote switch
actually has ports in that VLAN
or not!
In the following example, VTP
allows both switches to know
about VLANs 2-19, even though
neither switch has ports in all
those VLANs. Since a trunk port
belongs to every VLAN, they
both forward broadcasts and
multicasts for all those VLANs.
Both switches are transmitting
and receiving broadcasts and
multicasts that they do not
need.

Configuring VTP Pruning allows
the switches to send broadcasts
and multicasts to a remote
switch only if the remote switch
actually has ports that belong
to that VLAN. This simple
configuration will prevent a
great deal of unnecessary
traffic from crossing the trunk.

vtp pruning enables pruning for
all VLANs in the VTP domain,
all VLANs from 2 -1001 are
eligible to be pruned. The
reserved VLANs you see in
show vlan brief - VLANs 1 and
1002 - 1005 - cannot be
pruned.

Note that SW1 had to be
changed to Server mode in
order to enable pruning. Verify
that pruning is enabled with
show vtp status.

Enabling pruning on one VTP
Server actually enables pruning
for the entire domain, but I
wanted to show you that a
switch has to be in Server
mode to have pruning enabled.
It doesn’t hurt anything to
enter the command vtp pruning
on all Servers in the domain,
but it’s unnecessary.
Stopping unnecessary

broadcasts might not seem like
such a big deal in a two-switch
example, but most of our
networks have more than two
switches! Consider this
example:

If the three hosts shown in
VLAN 7 are the only hosts in
that VLAN, there’s no reason for
VLAN 7 broadcasts to reach the
middle and bottom two
switches. Without VTP pruning,
that’s exactly what will happen!
Using VTP pruning here will
save quite a bit of bandwidth.
I’d like to share a real-world
troubleshooting tip with you
here. If you’re having problems
with one of your VLANs being
able to send data across the
trunk, run show interface trunk.
Make sure that all vlans shown

under “vlans allowed and active
in management domain” match
the ones shown under “vlans in
spanning tree forwarding state
and not pruned”.

In this example, VLAN 40 is
allowed and active, but it’s
been pruned. That’s fine if you
don’t have hosts on both sides

of the trunk in VLAN 40, but I
have seen this happen in a
production network where
there were hosts on both sides
of the trunk in a certain VLAN,
and that VLAN had been
pruned. It’s a rarity, but now
you know to look out for it!

VTP Versions
By now, you’ve probably
noticed that the first field in the
readout of show vtp status is
the VTP version. The first

version of VTP was VTP Version
1, and that is the default of
some older Cisco switches. The
next version was Version 2, and
that’s the default on many
newer models, including the
2950.
As RIPv2 has advantages over
RIPvl, VTP v2 has several
advantages over VTPvl.
Version 2 supports Token Ring
VLANs and Token Ring
switching, where Version 1
does not.

When changes are made to
VLANs or the VTP configuration
at the command-line interface
(CLI), Version 2 will perform a
consistency check. on VLAN
names and numbers. This helps
to prevent incorrect/ inaccurate
names from being propagated
throughout the network.
A switch running VTPv2 and
Transparent mode will forward
VTP advertisements received
from VTP Servers in that same
domain.
As with RIP, VTP versions don’t

work well together. Cisco
switches run in Version 1 by
default, although most newer
switches are V2-capable. If you
have a V2-capable switch in a
VTP domain with switches
running V1, just make sure the
newer switch has V2 disabled.
The version can be changed
with the vtp version command.

VTP “Secure Mode”

By setting a VTP password, you
place the entire VTP domain
into Secure Mode. Every switch
in the domain must have a
matching password.

VTP Secure Mode isn’t all that
secure, though - here’s how you
discover the password:

Pretty secure, eh? Let’s try to
encrypt that password --

That’s something to keep in
mind!

VTP Configuration Tips
I’ve configured VTP many
times, and while the following
two tips aren’t Cisco gospel,
they’ve worked well for me.
Unless you have a very good
reason to put a switch into
Transparent mode, stick with
Server and Client. Not only

does this ensure that the VTP
databases in your network will
be synchronized, but it causes
less confusion in the future for
other network admins who
don’t understand Transparent
mode as well as you do.
Some campus networks will
have switches that can be
easily secured - the ones in
your network control room, for
example - and others that may
be more accessible to others.
Your VTP Servers should be the
switches that are accessible
only by you and a trusted few.

Don’t leave every switch in your
VTP domain at the default of
Server, or you’ve made it
possible to create and delete
VLANs on every switch in your
network.

Free Videos From My YouTube
And Udemy Channels!
My 5-part Etherchannel video
series can all be found on this
page on my main website:

http://www.thebryantadvantage.

Video Tutorial on VTP:
http://bit.ly/dkGVJL
http://bit.ly/yUUOdH
Enjoy!

Spanning Tree
Protocol Basics
In today’s networks - heck,
even in yesterday’s networks we love redundancy. A single
point of failure just isn’t
acceptable today, so we’re
going to spend quite a bit of
time in the SWITCH course
learning how to create that
redundancy when it doesn’t

already exist.
With our routing protocols such
as EIGRP and OSPF, redundant
paths can be used in addition
to the primary path to perform
equal-cost and/or unequal-cost
load balancing. That’s a
desirable behavior with routing.
With switching, those
redundant paths need to be
ready to be put into action in
case the primary path fails, but
they won’t be used in addition
to the primary path. This is the
responsibility of the Spanning

Tree Protocol (STP, defined by
IEEE 802.1d).
If you recently earned your
CCNA, much of the first part of
this section will seem familiar.
If it’s been a while since you
studied STP, we’ll get you back
up to speed quickly - and then
we’ll all dive in to advanced
STP features.

LAN Switching Basics
Switches use their MAC address
table to switch frames, but

when a switch is first added to
a network, it has no entries in
this table save for a few entries
for the CPU.
The switch will dynamically
build its MAC table by
examining the source MAC
address of incoming frames.
(The source MAC address is the
first thing the switch looks at
on incoming frames.)
As the switch builds the MAC
table, it quickly learns the hosts
that are located off each port.
But what if the switch doesn’t

know the correct port to
forward a frame to? What if the
frame is a broadcast or
multicast? Glad you asked!
Unknown unicast frames are
frames destined for a particular
host, but there is no MAC
address table entry for that
destination. Unknown unicast
frames are forwarded out every
port except the one they came
in on. Under no circumstances
will a switch send a frame back
out the same port it came in
on.

Broadcast frames are destined
for all hosts, while multicast
frames are destined for a
specific group of hosts.
Broadcast and multicast frames
are also forwarded out every
port except the one they came
in on.
Known unicast frames are
frames destined for a particular
host, and this destination has
an entry in the receiving
switch’s MAC table. Since we
know the right port through
which to forward the frame,
there’s no reason to send it out

all ports, so this frame will be
unicast via that port listed in
the MAC table.
To review:
Unknown unicast, broadcast,
and multicast frames are
forwarded out all ports except
the one upon which they were
originally received
Known unicast frames are
unicast via the port listed in the
MAC address table
That all sounds nice and neat,

right? For the most part, it is.
But as we all know, production
networks are rarely nice and
neat. We don’t want to have
only one known path from
“Point A” to “Point B”.
We want redundancy - that is, if
one path between two hosts is
unusable, there should be a
second path that is almost
immediately available.
The problem is that with
redundant links comes the
possibility of a switching loop.
The Spanning Tree Protocol

(STP) helps to prevent
switching loops from forming,
but what if STP didn’t exist?
What if you decide to turn it
off? Let’s walk through what
would happen in a switching
network with redundant paths if
STP did not exist.

Now this is redundancy! We’ve
got three separate switches
connecting two ethernet
segments, so even if two

separate switches become
unavailable, these hosts would
be able to communicate. But
we better have STP on to
prevent switching loops.
If we didn’t, what would
happen? If Host A sends a
frame to Host C, all three
switches would receive the
frame on their port 0/1. Since
none of the switches would
have an entry for Host A in
their MAC tables, each switch
would make an entry for that
host, listing it as reachable via
port 0/1.

None of the switches know
where Host C is yet, so the
switches will follow the default
behavior for an unknown
unicast address - they will flood
the frame out all ports except
the one it came in on. That
includes port 0/2 on all three
switches.
Just this quickly, without STP,
we have a switching loop. Each
switch will see the frames that
the other two switches just
forwarded out their port 0/2.
The problem is that the source
MAC address is still the address

of Host A, but now the switches
will each be receiving frames
with that source MAC address
on port 0/2.
Since all the switches had port
0/1 as the port for Host A,
they’ll now change that MAC
address table listing to port 0/2
- and again flood the frame.
The frames are just going to
keep going in circles, and that’s
why we call it a switching loop,
or bridging loop.
Switching loops cause three
problems:

Frames can’t reach their
intended destination, either
totally or in part
Unnecessary strain put on CPU
Unnecessary use of bandwidth
Luckily for us, switching loops
just don’t occur that often,
because STP does a great job
of preventing switching loops
before they can occur - and STP
all begins with the exchange of
Bridge Protocol Data Units
(BPDUs).

The Role Of BPDUs
BPDUs are transmitted every
two seconds to the well-known
multicast MAC address 01-80c2-00-00-00. (It might not have
been well-known to you before,
but it is now!) We’ve actually
got two different BPDU types:
Topology Change
Notification (TCN)
Configuration
We’ll talk about TCNs later in
this section, but for now it’s
enough to know that the name

is the recipe - a switch sends a
TCN when there is a change in
the network topology.
Configuration BPDUs are used
for the actual STP calculations.
Once a root bridge is elected,
only that root bridge will
originate Configuration BPDUs;
the non-root bridges will
forward copies of that BPDU.
BPDUs also carry out the
election to decide which switch
will be the Root Bridge. The
Root Bridge is the “boss” of the
switching network - this is the

switch that decides what the
STP values and timers will be.
Each switch will have a Bridge
ID Priority value, more
commonly referred to as a BID.
This BID is a combination of a
2-byte Priority value and the 6byte MAC address.
The BID has the priority value
listed first. For example, if a
Cisco switch has the default
priority value of 32,768 and a
MAC address of 11-22-3344-5566, the BID would be
32768:11-22-33-44-55-66.

Therefore, if the switch priority
is left at the default on all
switches, the MAC address is
the deciding factor in the root
bridge election.
Is that a bad thing? Maybe…

Why You Should Care
About The Winner Of
This Election
Before we take a look at the
root bridge election process
itself, let’s talk a bit about why
we care which switch wins.

Cisco switches are equal, but
some are more equal than
others. In any network you’re
going to have switches that are
more powerful than others
when it comes to processing
power and speed, and your root
bridges are going to have a
heavier workload than the nonroot bridges.
Bottom line: Your most
powerful switches, which are
also hopefully centrally located
in your network, should be your
root bridges.

Note that I said “root bridges”.
Not only can we as the network
admins determine which of our
switches will be the primary
root bridge, we can also
determine the secondary root
bridge - the switch that will
become the root bridge if the
primary root bridge goes down.
After we take a look at the
important defaults of the root
bridge election, along with
several examples, I’ll show you
exactly how to configure any
given Cisco switch in your
network as the primary or

secondary root bridge. As the
network admins, it’s you and I
that should decide this election,
rather than
… well, let’s see what happens
without admin intervention!

The Default Root Bridge
Election Process
Switches are a lot like people when they first arrive, they
announce that they are the
center of the universe.
Unlike some people, the

switches will soon get over it.
But seriously, folks, BPDUs will
be exchanged between our
switches until one switch is
elected Root Bridge, and it’s the
switch with the lowest BID that
will end up being the Root
Bridge.
In this example, we’ll look at a
three-switch network and the
Root Bridge election from each
switch’s point of view. Each
switch is running the default
priority of 32768, and the MAC
address of each switch is the

switch’s letter 12 times.
Through the magic of
technology, all three switches
are coming online at the same
time, all three believe they are
the root bridge, and all three
get very busy announcing that
fact.
Since each of these switches
believe it’s the root bridge, all
six ports in this example will go
to the listening state, allowing
it to hear BPDUs from other
switches.
More about those STP states

later in the course - let’s focus
on the election for now.

SW A has a BID of 32768:aaaa-aa-aa-aa-aa. That switch
will receive BPDUs from both
SW B and SW C, both
containing their individual BIDs.

SW A will see that the BIDs it’s
getting from both of those
switches are higher than its
own, so SW A will continue to
send BPDUs announcing itself
as the Root Bridge.

SW B has a BID of 32768:bbbb-bb-bb-bb-bb. SW B will
receive the BIDs as shown, and
since SW A is sending a lower

BID than SW B’s, SW B will
recognize that SW A is the true
Root Bridge, and SW B will then
recognize SW A as the root.

SW C is in the same situation.
SW C will receive the BIDs as
shown, and since SW A is

sending a lower BID than SW
C’s, SW C will recognize that
SW A is the Root Bridge.
Even though these switches
have quickly agreed that SW A
is the root, this election really
never ends. If a new switch
comes online and advertises a
BID that is lower than SW A’s.
that switch would then become
the root bridge.
In the following example, SW D
has come online and has a BID
lower than the current Root
Bridge, SW A. SW D will

advertise this BID via a BPDU
to SW B, and SW B will realize
that SW D should be the new
root bridge. SW B will then
announce this to the other
switches, and soon SW D is
indeed the root bridge. Since
BPDUs are sent every two
seconds, SW D will be seen as
the new root bridge very
quickly.

To see the local switch’s BID, as
well as that of the current root
bridge, run show spanning-tree
vlan x. We’ll run this command
with another network topology,
this one a simple two-switch
setup with two trunk links
connecting the switches.

There are actually four tip-offs
in this readout that you’re on
the root bridge. The highlighted
text is one - what are the other
three?
The MAC address of the Root
ID (indicating the root) and the

Bridge ID (the info for the local
switch) is the same
There is no root port on this
switch. As you’d expect, the
root port is the port a switch
will use to reach the port. The
root bridge doesn’t need a root
port, and therefore will not
have one
All ports are in Forwarding
(FWD) mode. No ports on the
root bridge for a given VLAN
will be in Blocking (BLK) mode.
What do things look like on the

non-root bridge, you ask? Let’s
take a look at the same
command’s output on SW2.

There are four tip-offs that
you’re not on the root bridge.
One is highlighted. What are
the other three?
No “this bridge is the root”

message
The MAC address of the Root
ID and Bridge ID fields are
different, as shown
This bridge does have a root
port (fast 0/11)
There is a port in Blocking
mode (BLK)
STP works by putting certain
ports into Blocking mode, which
in turn prevents switching loops
from forming. Notice that only
one port in our little two-switch

network is in blocking mode,
and in this case that’s enough
to leave only one available
path between the switches. No
ports on the root bridge will be
put into blocking mode.

The port that SW2 is using to
reach the root bridge is called
the root port, and it wasn’t
selected at random. Each
switch port has an assigned
path cost, and this path cost is
used to arrive at the root path

cost.
Yes, I hate it when two
different values have practically
the same name, too. Here’s a
very short chart to help you
keep them straight:
Path cost: Assigned to an
individual port. Strictly a local
value and is not advertised to
upstream or downstream
switches. A port’s Path Cost is
assigned in accordance with the
speed of the port - the faster
the port, the lower the Path
Cost.

Root path cost: Cumulative
value reflecting the overall cost
to get to the root. Is advertised
to downstream switches via
BPDUs.
The BPDU actually carries the
Root Path Cost, and this cost
increments as the BPDU is
forwarded throughout the
network. A port’s Path Cost is
locally significant only and is
unknown by downstream
switches.
The root bridge will transmit a
BPDU with the Root Path Cost

set to zero. When a
neighboring switch receives this
BPDU, that switch adds the cost
of the port the BPDU was
received on to the incoming
Root Path Cost.
Root Path Cost increments as
BPDUs are received, not sent.
That new root path cost value
will be reflected in the BPDU
that switch then sends out.

The Path Cost is locally
significant only. In the previous
example, SW3 doesn’t have any
idea what the Path Cost on
SW2’s receiving interface is,
and doesn’t particularly care.
No switch downstream of SW3
will know of any Path Costs on
SW2 or SW3 - the downstream

switches will only see the
cumulative cost, the Root Path
Cost.
Let’s go back to our two-switch
example…

…the incoming Root Path Cost
should be the same for both
ports on SW2, since the two
links are the same speed. Let’s
run show spanning-tree vlan 1
again to see what the deciding
factor was.

The costs are indeed the same,
19 for each port. (That’s the
default cost for a 100 Mbps
port. Remember, the port cost
is determined by the speed of
the port.) SW2 is receiving
BPDUs from SW1 on both ports
0/11 and 0/12, and one of
those ports has to be chosen as
the Root Port by SW2. Here’s
the process of choosing a Root
Port, and how these steps
factored into SW2’s decisionmaking process.

1. Choose the port receiving
the superior BPDU. By “superior
BPDU”, we mean the one with
the lowest Root BID. The
BPDUs are coming from the
same switch - SW1 - so this is a
tie.
2. Choose the port with the
lowest Root Path Cost to the
root bridge. That’s a tie here,
too.
3. Choose the port receiving
the BPDU with the lowest
Sender BID. Since the same
switch is sending both BPDUs,
that’s a tie here as well.
4. Choose the lowest sender

Port ID. That was the
tiebreaker here.
Using our three-router network,
we can easily identify the root
ports on both SW B and SW C.
Both ports on SW A will be in
forwarding mode, since this is
the root bridge.

STP isn’t quite done, though. A
designated port needs to be
chosen for the segment
connecting SW B and SW C.
Let’s add a host to that
segment to see why a
designated port needs to be
chosen.

Let’s say that host is
transmitting frames that need
to be forwarded to SW A. There
are two switches that can do
this, but to prevent switching
loops from possibly forming, we
only want one switch to
forward the frames. That’s
where the Designated Port (DP)
comes in. The switch that has
the lowest Root Path Cost will
have its port on this shared
segment become the
Designated Port.
Of course, there’s a chance that
both switches in this example

would have the same Root Path
Cost. In that case, the port
belonging to the switch with
the lowest BID will become the
Designated Port. Additionally,
all ports on the root bridge are
considered Designated Ports.
Here’s a clip from show
spanning vlan 1 on our root
bridge:

Note that both ports are in
“Desg” mode.
Assuming that SW B has a

priority of 32768:bb-bb-bb-bbbb-bb and SW C has a priority
of 32768:cc-cc-cc-cc-cc-cc, port
0/2 on SW B would become a
Designated Port, and port 0/1
on SW C would be placed into
blocking mode.
It’s interesting to note that of
the six ports involved in our
example, five are in forwarding
mode and only one is blocked but placing that one particular
port into blocking mode
prevents switching loops from
forming.

Now we know how root bridges
are elected - but this
knowledge brings up a couple
of interesting questions.
What if our least powerful
switch is elected as the root
bridge?

What if a switch on the very
edge of the network is elected?
(That’s likely to be one of our
least powerful switches, too.)
What if we later add a more
powerful switch and would now
like to make that new switch
the root bridge?
The bottom line: The MAC
address of the switches in our
network should not determine
the location of the primary and
secondary root switches. We the network admins - should.

We have two separate
commands that we can use for
this:
spanning-tree vlan priority
spanning-tree vlan root
(primary / secondary)
We’ll see both of these
commands in action later in this
section. In the meantime, let’s
have a quick Zen lesson…

The Shortest Path Is
Not Always The

Shortest Path
The default STP Path Costs are
determined by the speed of the
port.
10 Mbps Port: 100
100 Mbps Port: 19
1 GBPS Port: 4
10 GBPS Port: 1
If you change a port cost, the
Spanning-Tree Algorithm (STA)
runs and STP port states may
change as a result.
Whether it’s for a job interview,

a practice exam, or the CCNP
SWITCH exam itself, you have
to be careful not to jump to the
conclusion that the physically
shortest path is the logically
shortest path.

If you’re asked which port on
SW3 will be the root port, it’s

easy to look at the physical
topology and decide that it’s
fast 0/3 - after all, that port is a
physically straight shot to the
root. However, the link speeds
will tell a different story. A
nonroot bridge will always
select the path with the lowest
cumulative cost - and here, that
path is the physically longest
path.
SW3 - SW1 Root Path
Cost: 100 (One 10 Mbps
link)
SW3 - SW2 - SW 1 Root
Path Cost: 38 (Two 100

Mbps links)
Whether it’s in the exam room
or a production network, make
sure to check the port speeds
before assuming that the
physically shortest path is the
optimal path.

Changing A Port’s Path
Cost
Like other STP commands and
features, this is another
command that you should have
a very good reason for

configuring before using it.
Make sure to add up the Root
Path Cost for other available
paths before changing a port’s
Path Cost to ensure you’re
getting the results you want …
… and avoid results you don’t
want!
In the following example, SW2
shows a Path Cost of 19 for
both ports 0/11 and 0/12.

We’ll now change the port cost
of 0/12 to 9 for all VLANs…

… and the results are seen
immediately. Note that 0/11
was placed into blocking mode
and 0/12 is in Listening mode,
soon to be Forwarding mode.

Let’s take this one step further.
Right now on this switch, we
have VLANs 1, 20, and 100.
What if we wanted to lower
port 0/11 ’s cost to 5 for VLAN
100 only, but leave it at the
default of 19 for the other
VLANs? We can do this by
specifying the VLAN in the cost
command.

The cost is lowered for this port
in VLAN 100….

… but for VLAN 20, the cost
remains the same.

Again, be careful when
adjusting these costs - but
properly used, this can be a
powerful command for
exercising total control over the
path your switches use to
transport data for a given
VLAN.

The STP Port States

We’ve discussed the Forwarding
and Blocking states briefly, but
you should remember from
your CCNA studies that there
are some intermediate STP
states. A port doesn’t go from
Blocking to Forwarding
immediately, and for good
reason - to do so would invite
switching loops.
The disabled STP port state is a
little odd; you’re not going to
look into the STP table of a
VLAN and see “DIS” next to a
port. Cisco does officially
consider this to be an STP

state, though.
A disabled port is one that is
administratively shut down. A
disabled port obviously isn’t
forwarding frames, but it’s not
even officially taking place in
STP.
Once the port is opened, the
port will go into blocking state.
As the name implies, the port
can’t do much in this state - no
frame forwarding, no frame
receiving, and therefore no
learning of MAC addresses.
About the only thing this port

can do is accept BPDUs from
neighboring switches.
A port will then go from
blocking mode into listening
mode. The obvious question is
“listening for what?” Listening
for BPDUs - and this port can
now send BPDUs as well,
allowing the port to participate
in the root bridge election.
A port in listening mode still
can’t forward or receive data
frames, and as a result the MAC
address table is not yet being
updated.

When the port goes into
learning mode, it’s not yet
forwarding frames, but the port
is learning MAC addresses by
adding them to the switch’s
MAC address table. The port
continues to send and receive
BPDUs.
Finally, a port enters forwarding
mode. This allows a port to
forward and receive data
frames, send and receive
BPDUs, and place MAC
addresses in its MAC table.
Note this is the only state in
which the port is actually

forwarding frames.
To see the STP mode of a given
interface, use the show
spanning-tree interface
command.

STP Timers
You may remember these
timers from your CCNA studies
as well, and you should also
remember that these timers
should not be changed lightly.

What you might not have
known is that if you decide to
change any and all of these
timers, that change must be
configured on the root bridge.
The root bridge will inform the
nonroot switches of the change
via BPDUs.
We’ll prove that very shortly.
Right now, let’s review the STP
timer basics.
Hello Time defines how often
the Root Bridge will originate
Configuration BPDUs. By
default, this is set to 2 seconds.

Forward Delay is the length of
both the listening and learning
STP stages, with a default
value of 15 seconds for each
stage.
Maximum Age, referred to by
the switch as MaxAge, is the
amount of time a switch will
retain the superior BPDU’s
contents before discarding it.
The default is 20 seconds.
The value of these timers can
be changed with the spanningtree vlan command shown
below. The timers should

always be changed on the
root switch, and the current
secondary switch as well.
Verify the changes with the
show spanning-tree command.

Again, these values have to be
changed on the root switch in
order for the change to be
accepted by the rest of the
network. In the following
example, we’ll change the STP

timers on a nonroot switch and
then run show spanning-tree.

SW2 is not the root switch for
VLAN 10 (or any other VLANs at
this point). We’ll change the
STP timers on this switch.

The “Bridge ID” timers have
changed, but the Root ID STP
timers didn’t. The timers listed
next to Root ID are the STP
timers in effect on the network.
The nonroot switch will allow
you to change the STP timers,
but these new settings will not
be advertised via BPDUs unless
this local switch later becomes

the root bridge.
If you feel the need to change
STP timers, it’s a good idea to
change them on both the root
and secondary root switches.
That allows the secondary root
to keep the same timers if the
root goes down and the
secondary then becomes the
primary root.

Deterministic Root
Switch Placement
You might have noticed some

other options with the
spanning-tree vlan command…

If STP is left totally alone, a
single switch is going to be the
root bridge for every single
VLAN in your network. Worse,
that single switch is going to be
selected because it has a lower
MAC address than every other
switch, which isn’t exactly the
criteria you want to use to
select a single root bridge.

The time will definitely come
when you want to determine a
particular switch to be the root
bridge for your VLANs, or when
you will want to spread the root
bridge workload.
For instance, if you have 50
VLANs and five switches, you
may want each switch to act as
the root bridge for 10 VLANs
each. You can make this
happen with the spanning-tree
vlan root command.
In our previous two-switch
example, SW 1 is the root

bridge of VLAN 1. We can
create 3 more VLANs, and SW 1
will always be the root bridge
for every VLAN. Why? Because
its BID will always be lower
than SW 2.
I’ve created three new VLANs,
as seen in the output of show
vlan brief. The edited output of
show spanning-tree vlan shows
that SW 1 is the root bridge for
all these new VLANs.

Let’s say we’d like SW 2 to act
as the root bridge for VLANs 20
and 30 while leaving SW 1 as
the root for VLANs 1 and 10. To
make this happen, we’ll go to
SW 2 and use the spanningtree vlan root primary
command.

SW 2 is now the root bridge for
both VLAN 20 and 30. Notice
that the priority value has
changed from the default.
This command has another
option you should be aware of:

You can also configure a switch
to be the secondary, or
standby, root bridge. If you
want a certain switch to take
over as root bridge if the
current root bridge goes down,
run this command with the
secondary option. This will
change the priority just enough
so that the secondary root
doesn’t become the primary
immediately, but will become
the primary if the current
primary goes down.

Let’s take a look at the root
secondary command in action.
We have a three-switch
topology for this example. We’ll
use the root primary command
to make SW3 the root of VLAN
20. Which switch would become
the root if SW3 went down?

SW2 and SW1 have the same
default priority, so the switch
with the lowest MAC address
will be the secondary root - and
that’s SW2. But what if we want
SW1 to become the root if SW3
goes down? We use the root
secondary command on SW1!

SW1 now has a priority of
28672, which will make SW1
the root if SW3 goes down. A
priority value of 28672 is an
excellent tipoff that the root
secondary command has been
used on a switch. The config
itself shows this command as
well:

Take note of those two default
settings - “mode pvst” and
“extend system- id”. We’ll talk
about the Extended System ID
feature later in this section, and
the PVST default mode is
discussed in the Advanced STP
section.
Ever wondered how the STP
process decides what priority
should be set when the
spanning-tree vlan root
command is used? After all,

we’re not configuring an exact
priority with that command.
Here’s how the STP process
handles this:
If the current root
bridge’s priority is
greater than 24,576,
the switch sets its
priority to 24576 in
order to become the
root. You saw that in
the previous example.
If the current root
bridge’s priority is less
than 24,576, the switch
subtracts 4096 from the

root bridge’s priority in
order to become the
root.
There is another way to make a
switch the root bridge, and
that’s to change its priority with
the spanning-tree vlan priority
command. I personally prefer
the spanning-tree vlan root
command, since that command
ensures that the priority on the
local switch is lowered
sufficiently for it to become the
root.
With the spanning-tree vlan

priority command, you have to
make sure the new priority is
low enough for the local switch
to become the root switch. As
you’ll see, you also have to
enter the new priority in
multiples of 4096.

Where Should The Root
Bridge Be Located?
I’m sure you remember the
Cisco Three-Layer Hierarchical
Model, which lists the three
layers of a switching network -

Core, Distribution, and Access.
Access switches are those
found closest to the end users,
and the root bridge should not
be an access-layer switch.
Ideally, the root bridge should
be a core switch, which allows
for the highest optimization of
STP.
What you don’t want to do is
just blindly select a centrally
located switch, particularly if
you’re visiting a client who has
a configuration like this:

Don’t be tempted to make SW3
the root switch just because it’s
got the most connections to
other switches. You should
never make an access- layer
switch the root switch! The

best choice here is one of the
core layer switches, which
generally will be a physically
central switch in your network.
If for some reason you can’t
make a core switch the root,
make it one of the distribution
switches.

Topology Change
Notifications (TCNs)
Configuration BPDUs are
originated only by the root
bridge, but a TCN BPDU will be
generated by any switch in the

network when one of two
things happen:
A port goes into
Forwarding mode
A port goes from
Forwarding or Learning
mode into Blocking
mode
While the TCN BPDU is
important, it doesn’t give the
other switches a lot of detail.
The TCN doesn’t say exactly
what happened, just that
something happened.

As the TCN works its way
toward the root bridge, each
switch that receives the TCN
will send an acknowledgement
and forward the TCN.

When the root bridge receives
the TCN, the root will also
respond with an
acknowledgement, but this ack
will take the form of a
Configuration BPDU with the
Topology Change bit set.

This indicates to all receiving
switches that the aging time for
their MAC tables should be
changed from the default of
300 seconds to whatever the
Forward Delay value is - by
default, that’s 15 seconds. That
allows the switch to quickly rid
itself of now-invalid MAC
address table entries while
keeping entries for hosts that

are currently sending frames to
that switch.
A natural question is “How long
will the aging time for the MAC
table stay at the Forward Delay
value?” Here’s the quick
formula for the answer:
(Forward Delay) + (Max Age)
Assuming the default settings,
that’s a total of 35 seconds.

TCNs And The Portfast
Exception

Cisco switching veterans just
know that Portfast has to get
involved here somewhere.
Portfast-enabled ports cannot
result in TCN generation, which
makes perfect sense. The most
common usage of Portfast is
when a single PC is connected
directly to the switch port, and
since such a port going into
Forwarding mode doesn’t
impact STP operation, there’s
no need to alert the entire
network about it.
And if you’re fuzzy on what
Portfast is and what it does,

that and many other Cisco
switch features are covered in
the next section!

Load Sharing With The
port-priority Command
We can actually change a port’s
priority for some VLANs and
leave it at the default for other
VLANs in order to perform load
balancing over a trunk. Let’s
take a look at the default
behavior of a trunk between
two switches when we have ten
VLANs, and then change this

behavior just a bit with the
port-priority command.
I’ve created ten VLANs, 11 - 20,
for this example. SW1 is the
root for all ten VLANs. Before
we go forward, using your
knowledge of switching, how
many port or ports in this
example will be in STP Blocking
mode? Which one(s)?

Let’s check with show spanning

vlan 11 on both switches. If
your answer was “one”, you’re
correct!

We would see the same result
for every other VLAN, so at
present the trunk between 0/11
on both switches is carrying the

entire load for all VLANs. What
if we wanted to use the trunk
connecting 0/12 on both
switches to carry the data for
VLANs 15-20, while the trunk
connecting 0/11 carries the
rest?
We can make that happen by
lowering the port priority on
0/12 on one of the switches.
Let’s change the port priority on
SW1 ’s fast 0/12.
Don’t forget to use the VLAN
range option with the spanningtree command - this will save

you quite a bit of typing and
time on your exam.

We didn’t change the root
switch in any way, so SW1 still
shows as the root, and both
trunk ports will still be in
forwarding mode. Note the
change to 0/12’s priority.

The true impact of the
command is seen on SW2,
where 0/12 is now in
Forwarding mode for VLAN 15,
and 0/11 is in Blocking mode.

Let’s check VLAN 11 on SW2 - is
fast 0/11 still in Forwarding
mode for that VLAN?

Yes, it is! VLANs 11 - 15 will
use the trunk between the
switches’ fast 0/11 ports, and
VLANs 15-20 will use the trunk
between the switches’ fast 0/12
ports.
In many instances, you’ll
configure an Etherchannel here
rather than using port priority

to load balance over the trunk
lines. In Ciscoland, it’s always a
good idea to know more than
one way to do something especially when you’re studying
for an exam!
And in this situation, if 0/12
should go down for some
reason….say, the shutdown
command….

…VLANs 15 - 20 would begin
using the 0/11 trunk.

Get The VLAN
Information You Need!
We’re all familiar with show
interface x, but there’s a slight
variation on this command
when it comes to Cisco

switches that will give you a
great deal of helpful
information when it comes to
troubleshooting - show
interface x switchport. There’s
actually a very common issue
indicated in this output

From top to bottom, you can
see whether the switchport is
enabled, what the trunking
mode is (“administrative
mode”), what trunking
encapsulation is in use,
whether trunking’s being

negotiated or not, what the
native VLAN is, and so forth.
This is an excellent VLAN and
trunking troubleshooting
command.
And the problem? I left the
interface shut down. :) Here’s
what the output looks like
when the interface is open.

The reason I’m pointing that
out is that with the basic show
interface command, you’ll see
the phrase “administratively
down” - and you know from
your CCNA studies that this

phrase really means “you forgot
to open the interface.”

When you run show interface
switchport, you’re not going to
see “administratively down”,
but just “down” - which may
lead you to look for a more
complex solution. Just
remember to always check the
interface’s open/shut status
first, no matter what the router
or switch is telling you.
Here’s what the output looks
like when a trunk port is

specified. Note that you can
also see what VLANs are
allowed across the trunk and
which VLANs are being pruned.

The Extended System
ID Feature
Earlier in this section, we took
a look at part of a switch’s
configuration and saw this line:

Defined in IEEE 802.1t, the
Extended System ID feature
greatly extends the number of
STP instances that can be
supported by the switch, which
in turn allows the switch to
support up to 4096 VLANs. The
extended VLANs will be

numbered 1025 - 4096.
You can’t use this feature on all
Cisco switches, though. It is
enabled by default on 2950 and
3550 switches with an IOS
version of 12.1 (8)EA or later.
Here’s how to disable the
Extended System ID:

You may have noticed
something odd about the
Bridge ID with the switches
used in this section, all of which
are running the Extended
System ID feature by default:

The BID priority is the default
priority of 32768 plus the
System ID Extension value
(sys-id-ext). The sys-id-ext
value just happens to be the
VLAN number, so the BID
priority is 32768 + 20, which
equals 32788.
Some switches running CatOS
can support this feature; with

those switches, it’s called STP
MAC Address Reduction.
Disabled by default, it can be
enabled with the set spantree
macreduction command. (set
commands are run on CatOS
switches only - IOS-based
switches use the CLI commands
you see throughout this book.)

Free Videos From My YouTube
and Udemy Channels!
Video Practice Exam on Cisco
switching features:

http://www.youtube.com/watch?
v=dWttGNDQm5I

You might be a root switch….
http://bit.ly/eeAG4W

… or you might not be. Better
watch these videos to make
sure!

http://www.youtube.com/watch?
v=Hxf8f5U3eKU

STP Fundamentals Video Boot
Camp:

http://www.youtube.com/watch?
v=WsIOGEe48Iw

STP Port Costs Video Boot
Camp:

http://www.youtube.com/watch?
v=SEiF2cB3LP0

Be sure to visit my main
YouTube channel page -- I’m
adding new videos on a regular
basis!

http://www.youtube.com/user/cc
My Udemy-hosted CCNP
SWITCH Video Boot Camp has
two longer free STP videos for
you:

BPDUs and Root Bridge Election

Fundamentals:

http://www.udemy.com/lectures/
and-root-bridge-electionfundamentals-43929

Root bridges and STP port
states:

http://www.udemy.com/lectures/
bridge-or-not-path-costs-andstp-port-states-43930

Enjoy - and be sure to watch a
full and free hour of my CCNP
SWITCH Bulldog Boot Camp
DVD, also available on
Amazon.com!

http://www.thebryantadvantage.

Advanced Spanning
Tree
With the fundamentals of STP
nailed down, we’ll dive into
more advanced STP features
and versions. You won’t use all
of these in every network you
do admin work on, but you will
see them out in the field - and
on your CCNP SWITCH exam.

Portfast
Suitable only for switch ports
connected directly to a single
host, Portfast allows a port
running STP to go directly from
blocking to forwarding mode.

If you have an issue with a host
acquiring an IP address via
DHCP, configuring Portfast on
the switch port in question just

might solve the issue. Going
through the normal STP stages
on that port as the host finishes
booting can cause a bit of
havoc with the overall DHCP
process.
A Cisco router will give you an
interesting warning when you
configure Portfast:

That is one long warning.

Not only will the switch warn
you about the proper usage of
Portfast, but you must put the
port into access mode (“nontrunking”) before Portfast will
take effect.
An excellent real-world usage
of Portfast is to allow users to
get their IP addresses from a
DHCP server. If a switchport
has a workstation connected to
a port, that workstation will still
have to wait 30 seconds for the
listening and learning stages of
STP to run before it can
communicate successfully with

the DHCP server.
We all know that 30 seconds
seems like 30 minutes to end
users, especially first thing in
the morning! Running Portfast
on the appropriate switch ports
did speed up their initial
network connectivity.
Portfast can also be enabled
globally, but we’ll get another
warning when we do so:

Personally, I like to configure it

on a per-port basis, but make
sure you know both ways to
configure Portfast. It never
hurts to know more than one
way to do things on a Cisco
exam. And remember, a
Portfast- enabled port will not
send TCP BPDUs when the port
goes into Blocking mode.
There’s a command related to
portfast that I want to share
with you - note the three
effects of this command as
explained by IOS Help:

Good stuff to know!

Uplinkfast
When a port goes through the
transition from blocking to
forwarding, you’re looking at a
50-second delay before that
port can actually begin
forwarding frames. Configuring
a port with Portfast is one way
to get around that, but again,
you can only use it when a
single host device is found off
the port. What if the device
connected to a port is another
switch?

SW3 has two paths to the root
switch. STP will only allow one
path to be available, but if the
open path between SW3 and
SW1 goes down, there will be
approximately a 50-second
delay before the currently
blocked path will be available.
The delay is there to prevent

switching loops, and we can’t
use Portfast to shorten the
delay since these are switches,
not host devices. What we can
use is Uplinkfast.
The ports that SW3 could
potentially use to reach the
root switch are collectively
referred to as an uplink group.
The uplink group includes the
ports in forwarding and
blocking mode. If the
forwarding port in the uplink
group sees that the link has
gone down, another port in the
uplink group will be

transitioned from blocking to
forwarding immediately.
Uplinkfast is pretty much
Portfast for wiring closets. Cisco
recommends that Uplinkfast not
be used on switches in the
distribution and core layers.
Some additional details
regarding Uplinkfast:
The actual transition
from blocking to
forwarding isn’t really
“immediate” - it
actually takes 1 - 3

seconds. Next to a 50second delay, that
certainly seems
immediate!
Uplinkfast cannot be
configured on a root
switch.
When Uplinkfast is
enabled, it’s enabled
globally and for all
VLANs residing on the
switch. You can’t run
Uplinkfast on some
ports or on a per-VLAN
basis - it’s all or
nothing.

The original root port will
become the root port again
when it detects that its link to
the root switch has come back
up. This does not take place
immediately. The switch uses
the following formula to
determine how long to wait
before transitioning the original
root port back to the forwarding
state:
( 2 x FwdDelay) + 5
seconds
Uplinkfast will take immediate
action to ensure that a switch
cannot become the root switch

-- actually, two immediate
actions!
First, the switch
priority will be set to
49,152, which means
that if all other switches
are still at their default
priority, they’d all have
to go down before this
switch can possibly
become the root switch.
Additionally, the STP
Port Cost will be
increased by 3000,
making it highly
unlikely that this switch

will be used to reach
the root switch by any
downstream switches.
And you just know there’s got
to be at least one option with
this command, right? Let’s run
IOS Help and see.

When there is a direct link
failure, dummy multicast
frames are sent to the MAC
destination address 01 -00-0ccd-cd-cd. The max-update-rate
value determines how many of
these frames will be sent in a

100-millisecond time period.

Where To Apply
Uplinkfast
As with all the topics in this
section, it’s not enough to know
the definition of Uplinkfast and
what it does - you’ve got to
know where to configure it for
best results.
Uplinkfast is a wiring-closet
switch feature - it’s not
recommended for core and
distribution-layer switches.
Uplinkfast should be configured
only on access-layer switches.
It’s a safe bet that the root

switches are going to be found
in the core layer, and the
switches that are farthest away
from the root switches will be
the access switches. The access
switches will be the ones
closest to the end users.

Backbonefast
Uplinkfast and Portfast are
great, but they’ve got
limitations on when they can
and should be run. You
definitely can’t run either one in
a network backbone, but the
Cisco-proprietary feature
Backbonefast can be used to
help recover from indirect link
failures.
The key word there is indirect.
If a core switch detects an
indirect link failure - a failure of
a link that is not directly

connected to the core switch in
question - Backbonefast goes
into action.
This indirect link failure is
detected when an inferior BPDU
is received. Now, you may be
asking, “What is an inferior
BPDU?” Glad you asked! Let’s
take a look at a three-switch
setup where all links are
working and STP is running as
expected, paying particular
attention to the STP states on
SW3. All links are assumed to
be running at the same speed.

SW1 has been elected the root
bridge, and sends BPDUs every
two seconds to SW2 and SW3
telling them this. In turn, SW2
takes the BPDU it’s receiving
from SW1 and relays it to SW3.
All is well, until SW2 loses its
connection to SW1, as shown
below - which means that SW2
will start announcing itself as

the root switch. SW3 will now
be receiving two separate
BPDUs from two separate
switches, both claiming to be
the root switch.

SW3 looks at the priority of the
BPDU coming in from SW2, and
compares it to the BDPUs it’s

getting from SW1. SW3 quickly
realizes the BPDU from SW2 is
an inferior BPDU, and simply
ignores it. Once SW3’s MaxAge
timer on the port leading to
SW2 hits zero, that port will
transition to the listening state
and will start relaying the
information contained in the
superior BPDU, the BPDU
coming in from SW1.

The key phrase here is “once
SW3’s MaxAge timer on the
port leading to SW2 hits zero”.
We really don’t want to wait
that long, and with
Backbonefast, we don’t have
to!
When BackboneFast is

configured, this process skips
the MaxAge stage. While this
does not eliminate delays as
efficiently as PortFast and
UplinkFast, but the delay is cut
from 50 seconds to 30.
(MaxAge’s default value is 20
seconds, but the 15-second
Listening and Learning stages
still have to run.)
BackboneFast uses the Root
Link Query (RLQ) protocol. RLQ
uses a series of requests and
responses to detect indirect link
outages.

RLQ requests are transmitted
via the ports that would
normally be receiving BPDUs.
The purpose of these RLQ
requests is to ensure that the
local switch still has
connectivity to the root switch.
The RLQ request identifies the
bridge that is considered the
root bridge, and the RLQ
response will identify the root
bridge that can be accessed via
that port. If they’re one and the
same, everything’s fine.
Upon receiving a RLQ request,
a switch will answer

immediately under one of two
conditions:
The receiving switch is
indeed the root bridge
named in the RLQ
request
The receiving switch
has no connectivity to
the root bridge named
in the RLQ request,
because it considers
a^nother switch to be
the root bridge
The third possibility is that the
receiving switch is not the root,

but considers the root switch
named in the RLQ request to
indeed be the root switch. In
that case, the RLQ request is
relayed toward the root switch
by sending it out the root port.
To put BackboneFast into action
in our network, we have to
know more than the command!
We’ve got to know where to
configure it as well. Since all
switches in the network have to
be able to send, relay, and
respond to RLQ requests, and
RLQ is enabled by enabling
BackboneFast, every switch in

the network should be
configured for BackboneFast
when using this feature.
This feature is enabled globally,
and it’s simple to configure and believe it or not, there are
no additional timers or options
with this command. A true
Cisco rarity! The command to
verify BackboneFast is just as
simple and is shown below.

Root Guard
You know that the root switch
is the switch with the lowest
BID, and that a secondary root
is also elected - that’s the
switch with the next-lowest
BID. You also know that you
can use the spanning-tree vlan
root command to make sure
that a given switch becomes
the root or the secondary root.

We’ve used that command to
name the root and secondary

root switches in the following
network. For clarity’s sake, the
full BID is not shown - just the
switch priority.

Nothing wrong here,
everything’s fine… until another
switch is added to the mix.

The problem here is that SW4
is going to become the root
switch, and SW1 is going to
become the secondary root. If

SW4 is allowed to become the
root bridge, here’s what the
new STP topology will look like.

Depending on the design of
your network, this change in
root switches can have a
negative effect on traffic flow.
There’s also a delay involved
while the switches converge on
the new STP topology. Worse
yet, there’s always the
possibility that R4 isn’t even
under your administrative
control - it belongs to another
network!
STP has no default behavior to
prevent this from happening;
the spanning-tree vlan root
command helps you determine

which switches become the
root and secondary root, but
does nothing to disqualify a
switch from becoming the root.
To prevent SW4 from becoming
the root in this network, Root
Guard must be configured.
Root Guard is configured at the
port level, and disqualifies any
switch that is downstream from
that port from becoming the
root or secondary root.
To prevent SW4 from becoming
the root or secondary root,
SW3’s port that will receive

BPDUs from SW4 should be
configured with Root Guard.
When the BPDU comes in from
SW4, SW3 will recognize this as
a superior BPDU, one that
would result in a new root
switch being elected.
Root Guard will actually block
that superior BPDU, discard it,
and put the port into rootinconsistent state. When those
superior BPDUs stop coming,
SW3 will allow that port to
transition normally through the
STP port states.

Configuring Root Guard is
simple:

There is no interface reset or
reload necessary, but note that
Root Guard- enabled ports act
as designated ports (until a
superior BPDU is received, of
course).
SW4 now comes online and
sends a superior BPDU for VLAN
23 to SW3, which receives the
BPDU on port 0/24 - the port
running Root Guard. Here’s the

console message we receive as
a result on R3:

Additionally, there’s a spanningtree command that will show
you a list of ports that have
been put into root-inconsistent
state, but it’s not as obvious as
some of the other show
spanning-tree commands we’ve
seen:

Those of you who do not like to
type can just enter “inc” for
that last word!
This is the resulting topology:

BPDU Guard
Remember that warning that
we got from the router when
configuring PortFast?

Now, you’d think that would be
enough of a warning, right? But
there is a chance - just a
chance - that someone is going
to manage to connect a switch
to a port running Portfast,
which in turn creates the

possibility of a switching loop.

BPDU Guard protects against
this possibility. If any BPDU,
superior or inferior, comes in on
a port that’s running BPDU
Guard, the port will be shut
down and placed into error
disabled state, shown on the
switch as err-disabled.

To configure BPDU Guard on a
specific port only:

To configure BPDU Guard on all
ports on the switch:

Note that this command is a
variation of the portfast
command.
Naturally, BPDU Guard can only

be configured on ports already
running Portfast. The same
goes for the next feature, BPDU
Filtering.

PortFast BPDU Filtering
What if you don’t want the port
to be put into err-disabled state
when it receives a BPDU? You
can use BPDU Filtering, but you
have to be careful how you
configure it - this feature works
differently when it’s configured
globally as opposed to
configuring it on a per-interface
level.
Globally enabling BPDU
Filtering will enable this
feature on all
switchports running

portfast, and any such
port will stop running
PortFast if the port
receives a BPDU.
Enabling BPDU Filtering
on a specific port or
ports, rather than
enabling it globally, will
result in received
BPDUs being quietly
ignored. Those
incoming BPDUs will be
dropped, and the port
will not send any
BPDUs in return.
To enable BPDU Filtering

globally on all Portfast-enabled
ports:

To enable BPDU Filtering on a
specific port:

To verify global configuration of
BPDU Filtering (and quite a few
other features!):

To verify configuration of BPDU
Filtering on a specific port:

I know what you Bulldogs are
thinking out there - “So what if

you run both BPDU Guard and
Filtering on the same port?” In
that rare case, the port will
only act under the Filtering
rules we’ve gone over here.

Unidirectional Link
Detection (UDLD)
Most problems involving the
physical link will make data
transfer in either direction
impossible. Particularly with
fiber optic, there are situations
where a physical layer issue
disables data transfer in one
direction, but not the other.

UDLD detects these
unidirectional links by
transmitting a UDLD frame
across the link. If a UDLD frame
is received in return, that
indicates a bidirectional link,
and all is well.

If a UDLD frame is not received
in return, the link is considered
unidirectional. It’s really like a
Layer 2 ping. If the UDLD

“echo” is seen, there’s
bidirectional communication; if
the “echo” is not seen, there
isn’t!
UDLD has two modes of
operation, normal and
aggressive. When a
unidirectional link is detected in
normal mode, UDLD generates
a syslog message but does not
shut the port down.
In aggressive mode, the port
will be put into error disabled
state (“err-disabled”) after
eight UDLD messages receive

no echo from the remote
switch. Why is it called
“aggressive”? Because the
UDLD messages will go out at a
rate of one per second when a
potential unidirectional link is
found.
UDLD can be enabled globally
or on a per-port level. To
enable UDLD globally, run the
udld enable command. In this
case, “globally” means that
uDlD will run on all fiber optic
interfaces. For aggressive
mode, run udld aggressive.
(There is no udld normal

command.)

Here are your options for
running UDLD at the interface
level:

Another important detail
regarding UDLD is that to have
it run effectively, you’ve got to
have it configured on both
involved ports. For example, in

the previous two-switch
examples, UDLD would have to
be configured on both switches,
either on the switch ports or
globally.
Now, you may be thinking the
same thing I did when I first
read about aggressive mode…
If aggressive mode shuts a port
down after failing to receive an
echo to eight consecutive UDLD
frames, won’t the port always
shut down when you first
configure UDLD? Personally, I
type very quickly, but even I
can’t enter the UDLD command

on one switch and then connect
to the remote switch and
enable UDLD there within eight
seconds!
When UDLD’s aggressive mode
is first configured on the local
switch, the port will start
sending UDLD frames, but will
not shut down the port when it
doesn’t hear back from a
remote switch within 8
seconds.

The remote switch will first
have to answer back with a
UDLD frame, which makes the
local switch aware of the
remote switch. Then, if the
remote frame stops sending
back an echo frame, the local
switch will shut the port down.

Duplex Mismatches And
Switching Loops
A duplex mismatch between
two trunking switches isn’t
quite a unidirectional link, but it
can indeed lead to a switching
loop. You’re not often going to
change switch duplex settings,
especially on trunk ports, but if
you change one switch port’s
duplex setting, change that of
any trunking partner!
Believe it or not, the switching
loop potential is caused by
CSMA/CD! The full-duplex port

will not perform CSMA/CD, but
the half-duplex port will. The
problem comes in when the
half-duplex port listens to the
segment, hears nothing, and
sends frames as it normally
would under CSMA/CD rules…

… and then the full-duplex port
sends frames without listening
to the segment. We all know
what happens then!

Under CSMA/CD rules, the halfduplex port will then invoke its
random timer and then listen to
the segment again before
attempting to send frames and that includes BPDUs.
One collision does not a
switching loop make, but if the
full-duplex port sends enough
traffic, it effectively drowns out

anything that the half-duplex
port tries to send. Depending
on the location of the root
switch in this network (or if one
of these switches is the root
switch), a switching loop may
well occur. Keep your ports in
the same duplex mode and you
don’t have to worry about this!

Loop Guard
We’ve had BPDU Guard, Root
Guard, and now… Loop Guard!
You can probably guess that
the “loop” being guarded
against is a switching loop…
but how does Loop Guard
prevent switching loops? Let’s
revisit an earlier example to
see how the absence of BPDUs
can result in a switching loop.

In this network, only one port
will be in blocking mode (BLK).
Ports in blocking mode still
receive BPDUs, and right now
everything’s as we would want
it to be. SW3 is receiving a
BPDU directly from the root as
well as a forwarded BPDU from
the secondary root. But what

happens if a physical issue
causes the link between SW2
and SW3 to become a
unidirectional link, where SW3
can send BPDUs to SW2 but
SW2 cannot send them to SW3?

If SW2 cannot transmit to SW3,
the BPDUs will obviously not

reach SW3. SW3 will wait for
the duration of the MaxAge
timer - by default, 20 seconds
- and will then begin to
transition the port facing SW2
from blocking to forwarding
mode. With all six ports in
Forwarding mode, we’ve got
ourselves a switching loop.
Loop Guard does not allow a
port to go from blocking to
forwarding in this situation.
With Loop Guard enabled, the
port will go from blocking to
loop- inconsistent, which is

basically still blocking mode,
and a switching loop will not
form.

Once the unidirectional link
issue is cleared up and SW3
begins to receive BPDUs again,
the port will come out of loopinconsistent state and will be

treated as an STP port would
normally be.
Loop Guard is disabled on all
ports by default, and is enabled
at the port level:

You can also enable Loop
Guard on a global basis:

Strange But True: You
enable Loop Guard on a
per-port basis, but it
operates on a per-VLAN

basis. For example, if you have
your trunk configured to carry
VLANs 10, 20, and 30, and
BPDUs stop coming in for VLAN
10, the port would move to
loop-inconsistent state for VLAN
10 only while continuing to
perform normally for the other
VLANs.

BPDU Skew Detection
You may look at that feature’s
name and think, “What is a
BPDU Skew, and why do I want
to detect it?” What we’re
actually attempting to detect
are BPDUs that aren’t being
relayed as quickly as they
should be.
After the root bridge election,
the root bridge transmits
BPDUs, and the non-root
switches relay that BPDU down
the STP tree. This should
happen quickly all around, since

the root bridge will be sending
a BPDU every two seconds by
default (“hello time”), and the
switches should relay the
BDPUs fast enough so every
switch is seeing a BPDU every
two seconds.
That’s in a perfect world,
though, and there are plenty of
imperfect networks out there!
You may have a busy switch
that can’t spare the CPU to
relay the BPDU quickly, or a
BPDU may just simply be lost
along the way down the STP
tree. That two-second hello

time value doesn’t give the
switches much leeway, but we
don’t want the STP topology
recalculated unnecessarily
either.
BPDU Skew Detection is strictly
a notification feature. Skew
Detection will not take action
to prevent STP recalculation
when BPDUs are not being
relayed quickly enough by the
switches, but it will send a
syslog message informing the
network administrator of the
problem. The amount of time
between when the BPDU

should have arrived and when
it did arrive is referred to as
“skew time” or “BPDU latency”.
A busy CPU could quickly find
itself overwhelmed if it had to
send a syslog message for
every BPDU delivery that’s
skewed. The syslog messages
will be limited to one every 60
seconds, unless the “skew
time” is at a critical level. In
that case, the syslog message
will be sent immediately with
no one-per-minute limit.
And what is “critical”, according

to BPDU Skew Detection? Any
value greater than 1/2 of the
MaxAge value, making the
critical skew time level 10
seconds or greater.

Rapid Spanning Tree
Protocol
So you understand STP, and
you’ve got all these STP
features down - and now here’s
another kind of STP!
Specifically, it’s RSTP, or Rapid
Spanning Tree Protocol. RSTP is
defined by IEEE 802.1w, and is

considered an extension of
802.1d.
The 30-second delay caused by
the listening and learning
states was once considered an
acceptable delay. Then again, a
floppy disk used to be
considered all the storage
space anyone would ever need,
and that theory didn’t exactly
stand the test of time!
Root bridges are still elected
with RSTP, but the port roles
themselves are different
between STP and RSTP. Let’s

take a look at the RSTP port
roles in the following threeswitch network, where SW1 is
the root. Note that SW3 has
multiple connections to the
ethernet segment.

RSTP uses the root port in the
same fashion that STP does. All
nonroot switches will select a
root port, and this port is the
one reflecting the lowest root
path cost. Assuming all links in
this network are running at the
same speed, SW2 and SW3 will
both select the port directly
connected to SW1 as their root
ports. There will be no root port
on a root bridge.

An RSTP designated port is the
port with the best root path
cost. The ports on the root
switch will obviously have the
lowest root path cost for that
network segment, and will be
the DP for that segment. We’ll

assume R3 has the DP for the
segment connected to SW2.

RSTP’s answer to a blocked port
is an alternate port. In this
segment, SW2’s port leading to
SW3 is an alternate port.

In this network, SW3 has two
separate ports on the same
physical segment. One port has
already been selected as the
designated port for that
segment, and the other port
will become the backup port.

This port gives a redundant
path to that segment, but
doesn’t guarantee that the root
switch will still be accessible.

The “rapid” in RSTP comes in
with the new port states. The

STP port states disabled,
blocking, and listening are
combined into the RSTP port
state discarding, which is the
initial RSTP port state.
RSTP ports transition from the
discarding state to the learning
state, where incoming frames
are still discarded; however, the
MAC addresses are now being
learned by the switch.
Finally, an RSTP port will
transition to the forwarding
state, which is the same as the
STP forwarding state.

Let’s compare the transition
states:
STP: disabled > blocking >
listening > learning >
forwarding RSTP: discarding >
learning > forwarding
There are other port types
unique to RSTP, edge ports and
point-to-point ports. An edge
port is just what it sounds like a port on the edge of the
network. In this case, it’s a
switch port that is connected to
a single host, most likely an
end user’s PC.

So why do we care? RSTP edge
ports act like Portfast-enabled
STP ports -- they can go
straight from forwarding to
blocking. If a BPDU comes in an
RSTP edge port, it’s “demoted”
to a regular RSTP port and
generates a TCN BPDU. (More
about that in just a few
seconds.)
A point-to-point port is any port
running in full-duplex mode.
(Any ports running half-duplex

are shared ports.)

Edge Ports And RSTP
Topology Changes
Edge ports play a role in when
RSTP considers a topology
change to have taken place.
Rather, I should say that they
don’t play a role, because RSTP
considers a topology change to
have taken place when a port
moves into Forwarding mode -

unless that port is an edge
port.
When an edge port moves into
Forwarding mode, RSTP doesn’t
consider that a topology
change, since only a single host
will be connected to that
particular port.
When a topology change is
discovered by a switch running
RSTP, that switch sends BPDUs
with the Topology Change (TC)
bit set.
While the concept of a Portfast-

enabled port and an Edge port
in RSTP are the same - both go
immediately to the Forwarding
state and should be connected
only to a single host - there is a
major difference in their
behavior when a BPDU is
received on such a port. An
RSTP Edge Port will simply be
considered a “normal” spanning
tree port after receiving a
BPDU.
Another major difference
between STP and RSTP is the
way BPDUs are handled. With
STP, only the root bridge is

sending BPDUs every two
seconds; the nonroot bridges
simply forward, or relay, that
BPDU when they receive it.
RSTP-enabled switches
generate a BPDU every two
seconds, regardless of whether
they have received a BPDU
from the root switch or not.
(The default value of hello
time, the interval at which
switches send BPDUs, is two
seconds in both STP and RSTP.)
This change not only allows all
switches in the network to have

a role in detecting link failures,
but discovery of link failures is
faster. Why? Because every
switch expects to see a BPDU
from its neighbor every two
seconds, and if three BPDUs
are missed, the link is
considered down.
The switch then immediately
ages out all information
concerning that port.
This cuts the error detection
process from 20 seconds in STP
to 6 seconds in RSTP.

Let’s compare the two protocols
and their link failure detection
times.
When a switch running STP
misses a BPDU, the MaxAge
timer begins. This timer
dictates how long the switch
will retain the last BPDU before
timing it out and beginning the
STP recalculation process. By
default, MaxAge is 20 seconds.
When a switch running RSTP
misses three BPDUs, it will
immediately age out the
superior BPDU’s information

and begin the STP recalculation
process. Since the default hellotime is 2 seconds for both STP
and RSTP, it takes an RSTPenabled switch only 6 seconds
overall to determine that a link
to a neighbor has failed.
The BPDU format is the same
for STP and RSTP, but RSTP
uses all flag bits available in
the BPDU for various purposes
including state negotiation
between neighbors, but STP
uses only the Topology Change
(TC) and Topology Change Ack
(TCA) flags. The details of this

negotiation are out of the
scope of the exam, but can
easily be found on the Internet
by searching for “RSTP” in your
favorite search engine.
The RSTP BPDU is also of a
totally different type (Type 2,
Version 2), which allows an
RSTP-enabled switch to detect
older switches.
Behaviors of three main STP
features we looked at earlier in
this section - Uplinkfast,
Portfast, and Backbonefast are
built-in to RSTP. No additional

config is needed to gain the
benefits of all three.

Per-VLAN Spanning
Tree Versions (PVSTand
PVST+)
The ultimate “the name is the
recipe” protocol, the Ciscoproprietary PVST, well, runs a
separate instance of STP for
each VLAN!
The Good: PVST does allow for
much better fine-tuning of
spanning-tree performance

than does regular old STP.
The Bad: Running PVST does
mean extra work for your CPU
and memory.
The Ugly: PVST is Ciscoproprietary, so it must run over
the Cisco- proprietary trunking
protocol - ISL.
The requirement for PVST to
run ISL becomes a major issue
in a network like this:

PVST doesn’t play well at all
with CST, so Cisco came up
with PVST+. PVST+ is
described by Cisco’s website as
having the same functionality
as PVST, with the + version
using dot1q rather than ISL.
PVST+ is Cisco- proprietary as
well.
PVST+ can serve as an

intermediary between groups of
PVST switches and switches
running CST; otherwise, the
groups wouldn’t be able to
communicate. Using PVST+
along with CST and PVST can
be a little difficult to fine-tune
at first, but this combination is
running in many a network
right now - and working fine!

Rapid Per-VLAN
Spanning Tree Plus
(RPVST +) And PVST+
Now there’s a mouthful!
Cisco being Cisco, you just

know they have to have their
own version of STP! Per-VLAN
Spanning Tree Plus (PVST+) is
just what it sounds like every
VLAN has its own instance of
STP running. PVST+ allows perVLAN load balancing and is also
Cisco-proprietary.
If you configure a switch
running PVST+ to use RSTP,
you end up with RPVST+ Rapid Per-VLAN Spanning Tree
Plus. The good news is that the
command is very simple, and
we’ll use IOS Help to look at
some other options:

The bad news is that doing so
will restart all STP processes,
which in turn results in a
temporary data flow
interruption. If you choose to
make this change, it’s a good
idea to do so when end users
aren’t around.
We’ll revisit an old friend, show
spanning-tree, to verify that
RPVST+ is running on VLAN 1:

Later in the output of that
same command, note that
ports leading to switches have
“P2P Peer (STP)” as the type.

CST And MST
When our friend IEEE 802.1Q
(“dot1q”) is the trunking
protocol, Common Spanning
Tree is in use. With dot1q, all

VLANs are using a single
instance of STP.
Defined by IEEE 802.1s,
Multiple Spanning Tree gets its
name from a scheme that
allows multiple VLANs to be
mapped to a single instance of
STP, rather than having an
instance for every VLAN in the
network. MST serves as a
middle ground between STP
and PVST. CST uses a single
instance of STP, PVST has an
instance for every VLAN, and
MST allows you to reduce the
number of STP instances

without knocking it all the way
back to one.
MST was designed with
enterprise networks in mind, so
while it can be very useful in
the right environment, it’s not
for every network.
The configuration of MST
involves logically dividing the
switches into regions, and the
switches in any given region
must agree of the following:
1. The MST
configuration name

2. The MST instanceto-VLAN Mapping
table
3. The MST
configuration
revision number
If any of these three values are
not agreed upon by two given
switches, they are in different
regions. Switches send MST
BPDUs that contain the
configuration name, revision
number, and a digest value
derived from the mapping
table.

MST configurations can become
quite complex and a great deal
of planning is recommended
before implementing it. No
matter the size of the network,
however, keep the central point
in mind - the purpose of MST is
to map multiple VLANs to a
lesser number of STP instances.
A good way to get a mental
picture of the interoperability of
MST and CST is that CST will
cover the entire network, and
MST is a “subset” of the
network. CST is going to
maintain a loop-free network

only with the links connecting
the MST network subnets, and
it’s MST’s job to keep a loopfree topology in the MST
region. CST doesn’t know
what’s going on inside the
region, and it doesn’t want to
know.

The “IST” in each region stands
for Internal Spanning Tree, and
it’s the IST instance that is
responsible for keeping
communications in the MST
Region loop-free.
Up to 16 MST instances (MSTIs)
can exist in a region, numbered
0 through 15. MSTI 0 is
reserved for the IST instance,
and only the IST is going to
send MST BPDUs.
Occasionally the first ten MST
instances are referred to as
“00” - “09”. These are not hex

values - they’re regular old
decimals.
Here’s the good part -- there’s
no such thing as “VTP For MST”.
Each and every switch in your
MST deployment must be
configured manually. (No, I’m
not kidding!) When you create
VLAN mappings in MST, you’ve
got to configure every switch in
your network with those
mappings - they’re not
advertised.
A good place to start is to
enable MST on the switch:

The name and revision number
must now be set.

To map VLANs to a particular
MST instance:

Note that I could use commas
to separate individual VLANs or
use a hyphen to indicate a
range of them. When mapping
VLANs, remember that by

default all VLANs will be
mapped to the IST.

Why Does Anyone Run
STP Instead Of PVST?
Like the TCP vs. UDP argument
from your CCNA studies, this
seems like a bit of a no-brainer.
STP: 100 VLANs results in one
STP process
PVST: 100 VLANs results in 100
STP processes, allowing for
greater flexibility with trunk
usage (per-VLAN load
balancing, for example)
However, this goes back to

something you must keep in
mind when you’re learning
about all of these great
features - everything we do on
a Cisco switch has a cost in
resources. The more STP
processes a switch runs, the
bigger the hit against the
switch’s memory and CPU. This
is a decision you have to make
in accordance with the switch’s
available resource and the
workload PVST will put on your
switch.
Since Cisco Catalyst switches
run PVST by default, that’s a

good indicator that PVST is the
way to go. Just keep the
resource hit in mind as your
network grows - and the
number of VLANs in that
network with it!

Etherchannels
Etherchannels aren’t just
important for your Cisco
studies, they’re a vital part of
many of today’s networks.
Knowing how to configure and
troubleshoot them is a vital skill
that any CCNP must have.

Etherchannels are part of the
CCNA curriculum, but many
CCNA books either leave
Etherchannels out entirely or
mention them briefly. You may
not have even seen an
Etherchannel question on your
CCNA exam, so we’re going to
begin this section with a review
of what an Etherchannel is and
why we would configure one.
After that review, we’ll begin an
in-depth examination of how
Etherchannels work, and I’ll
show you some real-world
examples of common

Etherchannel configuration
errors to help you master this
skill for the exam and for the
real world.

What Is An
Etherchannel?
An Etherchannel is the logical
bundling of two to eight parallel
Ethernet trunks. This bundling
of trunks is also referred to as
aggregation. This provides
greater throughput, and is
another effective way to avoid
the 50- second wait between

blocking and forwarding states
in case of a link failure.
Spanning-Tree Protocol (STP)
considers an Etherchannel to be
one link. If one of the physical
links making up the logical
Etherchannel should fail, there
is no STP reconfiguration, since
STP doesn’t know the physical
link went down. STP sees only
the Etherchannel, and a single
link failure will not bring an
Etherchannel down.
In this example, there are three
trunks between two switches.

show spanning vlan 10 on
the non-root bridge illustrates
that STP sees three separate
links:

If port 0/19 goes down, port
0/20 will begin the process of
going from blocking to learning.
In the meantime,
communication between the
two switches is lost.
This temporary lack of a
forwarding port can be avoided
with an Etherchannel. By
combining the three physical
ports into a single logical link,
not only is the bandwidth of the
three links combined, but the
failure of a single link will not
force STP to recalculate the
spanning tree.

Etherchannels use the Exclusive
OR (XOR) algorithm to
determine which channel in the
EC to use to transmit data to
the remote switch.
After configuring an
Etherchannel on each switch
with the interface-level
command channel-group, the
output of commands show
interface trunk and show
spanning vlan 10 show STP
now sees the three physical
links as one logical link.

If one of the three physical
links goes down, STP will not
recalculate. While some
bandwidth is obviously lost, the
logical link itself stays up. Data
that is traveling over the
downed physical link will be

rerouted to another physical
link in a matter of milliseconds
- it will happen so fast that you
won’t even hear about it from
your end users!

Negotiating An
Etherchannel
There are two protocols that
can be used to negotiate an
etherchannel. The industry
standard is the Link
Aggregation Control Protocol
(LACP), and the Ciscoproprietary option is the Port

Aggregation Protocol (PAgP).
PAgP packets are sent between
Cisco switches via ports that
have the capacity to be placed
into an etherchannel. First, the
PAgP packets will check the
capabilities of the remote ports
against those of the local
switch ports. The remote ports
are checked for two important
values:
The remote port group
number must match the
number configured on
the local switch

The device ID of all
remote ports must be
the same - after all, if
the remote ports are on
separate switches, that
would defeat the
purpose of configuring
an etherchannel!
PAgP also has the capability of
changing a characteristic of the
etherchannel as a whole if one
of the ports in the etherchannel
is changed. If you change the
speed of one of the ports in an
etherchannel, PAgP will allow
the etherchannel to

dynamically adapt to this
change.
The industry standard bundling
protocol defined in 802.3ad,
LACP assigns a priority value to
each port that has etherchannel
capability. You can actually
assign up to 16 ports to belong
to an LACP-negotiated
etherchannel, but only the
eight ports with the lowest port
priority will be bundled. The
other ports will be bundled only
if one or more of the bundled
ports fails.

PAgP and LACP use different
terminology to express the
same modes. PAgP has a
dynamic mode and auto mode.
A port in dynamic mode will
initiate bundling with a remote
switch, while a port in auto
mode waits for the remote
switch to do so.
LACP uses active and passive
modes, where active ports
initiate bundling and passive
ports wait for the remote
switch to do so.
There’s a third option, on,

which means that there is no
negotiation at all, and neither
LACP nor PAgP are used in the
construction of the
etherchannel.

Configuring
Etherchannels
To select a particular
negotiation protocol, use the
channel-protocoi command.

The channel-group command is

used to place a port into an
etherchannel.

You can see the different
terminology LACP and PAgP use
for the same results - “active”
and “desirable” for the local
port to initiate the EC, “auto”
and “passive” if the remote port
is going to initiate the EC. To
enable the etherchannel with
no negotiation, use the on
option.

For an EC to form, LACP must
have at least one of the two
ports on each physical link set
for “active”; if both ports are
set to “passive”, no EC will be
built. The same can be said for
PAgP and the settings “auto”
and “desirable” - if both ports
are set to auto, the link won’t
join the EC.
To verify both PAgP and LACP
neighbors, you can use the
show pagp neighbor and show
lacp neighbor commands. To
illustrate, I’ve created an EC
using channel-group 1 and the

desirable option, meaning that
PAgP is enabled unconditionally.
The number you see below in
each command is the channel
group number. You can see that
PAgP is running on ports 0/23
and 0/24, and that LACP is not
running at all on that EC.

The ECs we’ve created up to
this point are pure Layer 2 ECs.
We can verify this with the
command show etherchannel
brief.

You may be wondering what
other kind of EC we might see
here! In certain situations, you
may want to apply an IP

address to the EC itself, which
results in a Layer 3
Etherchannel.
We’re on an L3 switch right
now, which gives us the ability
to create an L3 EC. We’ll create
an L3 etherchannel in the
Multilayer Switching section,
and here’s a sneak peek!
With an L2 EC, we bundled the
ports by configuring each port
with the channel-group
command, which automatically
created the port-channel
interface. When configuring an

L3 interface, you must create
the port- channel interface first,
then put the ports into the EC
with the port-channel
command.
IP routing must be enabled on
the L3 switch, and all involved
ports must be configured as
routed ports with the
switchport command.

And now when we run show
etherchannel brief…

…the L3 EC is verified by the
line “Group state = L3”.
You can perform load balancing
over an Etherchannel - and
have that load balacing
determined by source and/or

destination IP and/or MAC
addresses - with the portchannel load-balance
command:

You won’t see “XOR” in all IOS
versions for this command sometimes you’ll see “and”.
That load balances on source
*and* destination IP or MAC
address. Verify with show
etherchannel load-balance.

Troubleshooting
EtherChannels
Once you get an EC up and
running, it generally stays that
way - unless a port setting
changes. From personal
experience, here are a few
things to watch out for:
Changing the VLAN assignment
mode to dynamic. Ports
configured for dynamic VLAN
assignment from a VMPS
cannot remain or become part
of an EC.

The allowed range of VLANs for
the EC must match that of the
ports. Here’s a reenactment of
an EC issue I ran into once. The
configuration of the channelgroup looked just fine…

…but notice that the allowed
VLANs on these two ports is
different. That will prevent an

EC from working correctly.
Here’s the error message that
occurs in a scenario like this:

Interestingly enough, port
fast0/12 is not going to go into
err-disabled mode; instead, you
see this:

When I remove the original
command, I get the EC error
message again, but once I
change port 0/12’s config to
match 0/11 ’s, the EC forms.

show interface trunk and show
interface port-channell verify
that the trunk and the EC are
both up.

Changing a port attribute. Ports
need to be running the same
speed, duplex, native VLAN,
and just about any other value
you can think of! If you change
a port setting and the EC
comes down, you know what to
do change the port setting
back!
SPAN. Ports in an etherchannel
can be source SPAN ports, but
not destination SPAN ports.
The IP address. Naturally, this
is for L3 etherchannels only be sure to assign the IP

address to the logical
representation of the
etherchannel, the port-channel
interface, not to the physical
interfaces bundled in the
etherchannel.

Verifying And
Troubleshooting
Etherchannels
To take a quick look at the ECs
running on a switch, run show
etherchannel summary. In the
following example, we can see
that the EC serving as Port-

Channel 1 is a Layer 2 EC as
indicated by the code “S”, and
is in use as indicated by the
code “U”. You can also see the
ports in the channel.

If it’s real detail you want, use
show etherchannel x detail.

And now… an alternative to
STP!

Flex Links
In the very rare case that you
don’t want to run STP,
configuring Flex Links allows
you to have a backup link that
will be up and running in less
than 50 milliseconds.
It’s doubtful you’d use Flex
Links in a typical production
network, but it can come in
handy in service provider

networks where running STP
might not be feasible.
In the following example, port
0/11 is connected to SW2 and
0/12 to SW3. Using Flex Links,
only the active port will be
carrying data - in this case,
that’s 0/11.

We actually apply no
configuration to the primary
(active) port. All Flex Links
commands will be placed on
the standby port.

Verify with show interface
switchport backup.
Plenty o’ rules for this feature:
Enabling Flex Links for a set of
ports disables STP.
One backup interface per active
interface, please, and an
interface can belong to only
one set of Flex Links.
Obviously, the active and
backup interfaces cannot be
one and the same.

Ports inside an Etherchannel
cannot be individually assigned
as backup or active Flex Ports,
BUT an entire Etherchannel can
be assigned as either.
An Etherchannel can be
assigned as the active port for
a physical port, and vice versa.
This isn’t required reading, but
here’s some additional info
from Cisco regarding this
feature:
http://bit.ly/buHIUt

As I mentioned, this isn’t
something you configure every
day, but it does come in handy
if you can’t run STP for some
reason.

Free Videos From My
YouTube and Udemy
Channels!
Cisco switching feature Video
Practice Exam:

http://www.youtube.com/watch?

v=dWttGNDQm5I

“Root Guard and The
Inconsistent Ports”

http://www.youtube.com/watch?
v=LJq5_OG_0_U

Etherchannels and load
balancing (27-minute video!)

http://www.youtube.com/watch?
v=qpmoQKnkWtk

5-part Etherchannel Video Boot
Camp (on TBA Website)

http://www.thebryantadvantage.

CCNP SWITCH Video Boot
Camp and Preview:

http://www.youtube.com/watch?
v=JunOcLzSctc

CCNP SWITCH Bulldog Boot
Camp DVD:

http://www.thebryantadvantage.

Securing The
Switches
Bulldogs,
I’ve included a bonus section on
AAA elsewhere in this book please reaa that along with this
section. Thanks! -- Chris B.
When we think of network
security, we tend to focus on
protecting our network from

attacks originating outside the
network.
That’s half the battle - but it’s
important to remember that
many successful network
attacks are launched from the
inside, and from some
seemingly innocent sources,
such as…
DHCP
ARP
Rogue switches (Switches
acting as part of our network,

but under the administrative
control of a potential network
attacker)
CDP
Telnet
Unauthorized MAC addresses
Hosts on the same VLAN (!)
So while it’s wise to protect our
network from the outside, we
better take some measures to
protect us from.. the enemy
within.

(Cue dramatic music.)
Seriously, we’ve got some
important work to do here - so
let’s get to it.
The first methods of security
I’m going to talk about in this
chapter aren’t fancy, they aren’t
exciting, and they don’t cost an
arm and a leg. But the basic
security features are the ones
to start with, and I use a fourstep approach to basic network
security:
1. Physical security -

lock those servers,
routers, and
switches up! This is
the most basic form
of network security,
and it’s also the
most ignored.
2. Passwords - set ’em,
change ’em on
occasion. If you’re
relatively new to a
particular job site,
be ready for a fight
on this point from
other admins.
3. Different privilege
levels - not every

user needs the
same level of
access to
potentially
destructive
commands, because
not every user can
handle the
responsibility.
4. Grant remote
access only to those
who absolutely,
positively need it -and when users do
connect remotely,
make that
communication as

secure as possible.
Physical security is just that.
Get the routers and switches
locked up!
Steps two and three go hand in
hand, and much of what follows
may be familiar to you. Don’t
skip this part, though, because
we’re going to tie in privilege
levels when it comes to telnet
access.
You know how to configure the
basic passwords on a switch:

Here’s a quick refresher on
some basic Cisco password
rules and messages….
All passwords appear in the
configuration in clear text by
default except the enable
secret. The command service
password-encryption will
encrypt the remaining
passwords.

The login message shown when
the login command is used in
the above example simply
means that a password needs
to be set to enable this feature.
As long as you enter both the
login and password commands,
it does not matter in what
order you enter them.
Cisco switches have more VTY
lines than routers. Routers
allow up to five simultaneous
Telnet sessions, and obviously
switches allow more! The
default behavior is the same,
however. Any user who telnets

in to the switch will be placed
into user exec mode, and will
then be prompted for the
proper enable mode password.
If neither the enable secret nor
the enable password has been
set, the user will not be able to
enter enable mode.
To place users coming into the
switch via telnet straight into
enable mode, use the
command privilege level 15
under the VTY lines.

Note below how the
configuration appears on the
switch when it comes to the
VTY lines. If you want a
command to be applied to all
16 lines, you don’t have to use
“line vty 0 4” and then “line vty
5 15” - just run the command
line vty 0 15.

The possible issue here is that
any user who telnets in will be
placed into enable mode.
It’s easy to configure, but
maybe we don’t want to give
that high level of access so
easily.

Consider a situation where a
tech support person has to
telnet into a router. Maybe they
know what they’re doing, and
with all due respect, maybe
they don’t. Do you want this
person making changes to the
router without you knowing
about it? It may be better to
assign privilege level 15 to
yourself while assigning the
default value of 0 to others.
I also don’t like having one
password for all telnet users. I
prefer a scheme where each
individual user has their own

password.
Creating a local database of
users and privilege levels
allows us to do this, and it’s a
simple procedure. As a matter
of fact, you already did this at
least once during your CCNA
studies. All you have to do is
create a username / password
database the same way you
create one for PPP
authentication.

The username / password
command allows the
assignment of privilege levels.
If none is specified, level 0 is
the default. With the above
configuration, the first user
would be placed into privileged
exec mode when connecting via
telnet, while the other two
users would be required to
enter the enable password
before they could enter that
mode.
The login local command is
required to have the switch
look to a local database for

authentication information. If a
user doesn’t know their
username/password
combination, they can’t telnet
into this switch.

Port Security
Here’s another basic security
feature that’s regularly
overlooked, but is very
powerful. Port security uses a
host’s MAC address as a
password…

… and if the port receiving this
frame is running port security
and expects frames with that
particular MAC address only,
frames from this host would be
accepted.
However, if a device with a
different MAC address sends
frames to the switch on that
port, the port will take action by default, it will shut down
and go into error-disabled

state. By default, that state
requires manual intervention on
the part of the network admin
to reopen the port.
The switchport port-security
command enables this feature,
and then we have quite a few
options to consider.

Before we can consider the
options, we have to make the
port in question a non-trunking
port. Port security can’t be

configured on a port that even
has a possibility of becoming a
trunk port. Configuring a port
as an access port is the
equivalent of turning trunking
to “off”.
Now, let’s get back to those
options!

The first option to consider is
the maximum value. This is the
maximum number of secure

MAC addresses allowed on the
port. This number can vary I’ve seen Cisco switches that
would allow up to 1024, but
this 2950 will only allow 132.
These addresses can be
configured statically with the
mac-address option, they can
be learned dynamically, or you
can allow a port to do both.
(More on that in just a
moment.)

Now we need to decide the

action the port should take in
case frames with a non-secure
MAC address arrive on the port.
The default port security mode
is shutdown, and it’s just what
it sounds like - the port is
placed into error-disabled state
and manual intervention is
needed to reopen the port. An
SNMP trap message is also
generated.
(You can also use the
errdisable recovery command
to specify how long the port
should remain in that state

before the switch itself resets
the port.)

Protect mode simply drops the
offending frames. Restrict mode
is our middle ground - this
mode drops the offending
frames and will generate both
an SNMP trap notification and
syslog message regarding the
violation, but the port does not
go into err-disabled state.
Before we continue, a note of
caution - throughout this

course, you’ll see ports shut
down for one reason or another,
particularly in the Advanced
STP section. Note that not all of
these features force the port
into err- disabled mode. Be
sure you’re very familiar with
the different states these ports
are put into. (I’ll have a chart
at the end of that section listing
each port state.)
Let’s take a look at the console
messages you’ll see when
running port security in its
default mode, shutdown. I
configured a port on this switch

with port security, one secure
MAC address, and made sure it
didn’t match the host that
would be sending frames on
that port. Sure enough, within
seconds all of this happened:

show interface verifies that this
interface is in error-disabled
state.

That port must now manually

be reopened - of course, after
resolving the security issue that
brought it down in the first
place!
There is a little “gotcha” with
port security that you need to
be aware of. You can specify
the number of secure MAC
addresses, and you can specify
secure MAC addresses as well.
What if you allow for more
secure MAC address than you
actually configure manually, as
shown below?

In this situation, the remaining
secure MAC address will be
dynamically learned - so if a
rogue host with the MAC
address dddd.dddd.dddd
connected to that port right
now, port security would allow
it. Be careful!
In that configuration, these
three addresses would be
considered secure:
aa-aa-aa-aa-aa-aa
cc-cc-cc-cc-cc-cc

The next dynamically learned
MAC address
There is no penalty for hitting
the limit of secure addresses it just means the switch can’t
learn any more secure
addresses.
To verify your port security
configuration, run show portsecurity interface.

The violation mode here is the
default, shutdown. In this
scenario, the port will be shut
down if the number of secure
MAC addresses is reached and
a host whose MAC address is
not among those secure
addresses connects to this port.
Note that “aging time” is set to

zero - that actually means that
secure MAC addresses on this
port will never age out, not that
they have zero minutes before
aging out. You can change this
value with the switchport portsecurity aging command. This
particular switch accepts the
value set in minutes; many
older models want this entered
in seconds. Always use IOS
Help to double-check a
command’s metric!

The aging type value
determines whether a secure

MAC address will absolutely
expire after a certain amount of
time, or whether aging should
be based on inactivity … as IOS
Help shows us!

Port security is a great feature,
but you can’t run it on all ports.
There are a few port types that
you can’t configure with port
security:
trunk ports
ports placed in an
Etherchannel

destination SPAN port
802.1x ports

Why Make Addresses
“Sticky”?
We know a MAC address can be
dynamically learned by the
switch as secure, and we may
want that address marked as
secure in the running
configuration. To do so, enable
sticky learning with this
command:
switchport port-security mac-

address sticky
Why use sticky addresses?
Along with MAC address
flooding, network intruders can
use a spoofed MAC address to
gain access to the network. By
configuring sticky learning, the
dynamically learned secure
MAC addresses are written to
the running configuration,
which in turn helps to prevent
unauthorized network access
via MAC spoofing.
Note: To save these
dynamically learned static

addresses to the startup
configuration, you’ll need to
copy the run config over the
startup config before reloading
the switch.

Dot1x Port-Based
Authentication
Port security is good, but we
can take it a step further with
dot1x port- based
authentication. The name
refers to IEEE 802.1x, the
standard upon which this
feature is based. Unusually
enough, the Cisco
authentication server must be
RADIUS - you can’t use TACACS
or TACACS+.
One major difference between
dot1x port-based

authentication and port security
is that both the host and switch
port must be configured for
802.1x EAPOL (Extensible
Authentication Protocol over
LANs). That’s a major departure
from many of the switch
features we’ve studied to date,
since most other switch
features don’t require anything
of the host. Usually the PC isn’t
aware of what the switch is
doing, and doesn’t need to
know. Not this time!

Keeping those rules in mind, a
typical dot1x deployment
involves:
A dot1x-enabled PC, the
supplicant
A dot1x-enabled switch, the
authenticator

A RADIUS server, the
authentication server (You
cannot use a TACACS+ server
for this purpose.)
But it’s not quite as simple as
that. (You were waiting for
that, right?)
The PC has a single physical
port connected to the switch,
but that physical port is
logically divided into two ports
by dot1x - the controlled and
uncontrolled ports.
Unlike the subinterfaces you’ve

studied and created to date,
you and I as the network
admins do not have to
configure the controlled and
uncontrolled ports. Dot1x will
take care of that - of course, as
long as we remember to
configure the supplicant for
dot1x to begin with!
The controlled port cannot
transmit data until
authentication actually takes
place. The uncontrolled port
can transmit without
authentication, but only the
following protocols can be

transmitted:
Extensible Authentication
Protocol over LANs (EAPOL)
Spanning Tree Protocol (STP)
Cisco Discovery Protocol (CDP)
By default, once the user
authenticates, all traffic can be
received and transmitted
through this port.
To configure dot1x, AAA must
first be enabled. As with
previous configurations, a
method list must be created.

And again, as with previous
configurations, you should use
line as the last choice, just in
case something happens
regarding your login with the
other methods.

To enable dot1x on the switch:

Dot1x must be configured

globally, but every switch port
that’s going to run dot1x
authentication must be
configured as well.

Force-authorized, the default,
does just what it sounds like - it
forces the port to authorize any
host attempting to use the
port, but authentication is not
required. Basically, there is no
authentication on this port
type.
A port in force-unauthorized

state literally has the port
unable to authorize any client even clients who could
otherwise successfully
authenticate!
The auto setting enables dot1x
on the port, which will begin
the process as unauthorized.
Only the necessary EAPOL
frames will be sent and
received while the port’s
unauthorized. Once the
authentication is complete,
normal transmission and
receiving can begin. Not
surprisingly, this is the most

common setting.

SPAN Operation And
Configuration
We’ve secured the ports, but
there will also come a time
when we want to connect a
network analyzer to a switch
port. A common situation is
illustrated below, where we
want to analyze traffic sourced
from the three PCs. To properly
analyze the traffic, the network
analyzer needs a copy of every
frame the hosts are sending -

but how are we going to get it
there?

SPAN allows the switch to
mirror the traffic from the
source port(s) to the
destination port to which the

network analyzer is attached.
(In some Cisco documentation,
the destination port is referred
to as the monitor port.)
SPAN works very well, and the
basic operation is simple.
Studying SPAN for exams and
network usage can seem
complicated at first, though,
because there are several
different versions of SPAN.
The versions are much the
same, though; the real
difference comes in when you
define the source ports. It’s the

location of the source ports that
determines the SPAN version
that needs to run on the switch.
In the above example, we’re
running Local SPAN, since the
destination and source ports
are all on the same switch. If
the source was a VLAN rather
than a collection of physical
ports, VLAN-based SPAN
(VSPAN) would be in effect.
The command monitor session
starts a SPAN session, along
with allowing the configuration
of the source and destination.

The sessions are totally
separate operations, but the
number of simultaneous
sessions you can run differs
from one switch platform to
another. Cat 3550s and 2950s
support only two, but more
powerful switches can run as
many as 64 sessions at once.

Here, ports fast 0/1 - 0/5 have
been configured as the source.
By default, traffic being
received and transmitted will
be mirrored, but this can be
changed to received traffic only
and transmitted traffic only as

shown above.
Using the same session
number, the traffic will be
mirrored to the destination port
0/10. Verify the SPAN
configuration with show
monitor.

SPAN works fine if the source
and destination ports are on
the same switch, but
realistically, that’s not always
going to happen. What if the
traffic to be monitored is on
one switch, but the only vacant
port available is on another
switch?

Remote SPAN (RSPAN) is the
solution. Both switches will
need to be configured for

RSPAN, since the switch
connected to the PCs will need
to send mirrored frames across
the trunk. A separate VLAN will
be created that will carry only
the mirrored frames.
RSPAN configuration is simple,
but there are some factors you
need to consider when
configuring RSPAN:
If there were
intermediate switches
between the two shown
in the above example,
they would all need to

be RSPAN-capable.
VTP treats the RSPAN
VLAN like any other
VLAN. It will be
propagated throughout
the VTP domain if
configured on a VTP
server. Otherwise, it’s
got to be manually
configured on every
switch along the
intermediate path. VTP
Pruning will also prune
the RSPAN VLAN under
the same circumstances
that it would prune a
“normal” VLAN.

MAC address learning is
disabled for the RSPAN
VLAN.
The source and
destination must be
defined on both the
switch with the source
port and the switch
connected to the
network analyzer, but
the commands are not
the same on each.
After all that, the configuration
is simple! Create the VLAN first,
and identify it as the RSPAN
VLAN with the remote-span

command.

SW2 is the source switch, and
the traffic from ports 0/1 - 0/5
will be monitored and frames
mirrored to SW1 via RSPAN
VLAN 30.

As you see, naming the RSPAN
VLAN here doesn’t finish the

job. We now have to define the
reflector port, the port that will
be copying the SPAN traffic
onto the VLAN.

SW1 will receive the mirrored
traffic and will send it to a
network analyzer on port 0/10.

Run show monitor to verify the
configuration.

SPAN Limitations
As I mentioned, SPAN is easy to
configure, but it does have a
few limitations on what ports
can be made source or
destination ports:
Source port notes:
A source port can be
monitored in multiple,
simultaneous SPAN

sessions.
A source port can be
part of an Etherchannel.
A source port cannot be
configured as a
destination port.
A source port can be
any port type Ethernet, FastEthernet,
etc.
Destination port notes:
A destination port can
be any port type.
A destination port can
participate in only one

SPAN session.
A destination port
cannot be a source
port.
A destination port
cannot be part of an
Etherchannel.
A destination port
doesn’t participate in
STP, CDP, VTP, PaGP,
LACP, or DTP.
Trunk ports can be configured
as source and/or destination
SPAN ports; the default
behavior will result in the
monitoring of all active VLANs

on the trunk.
I strongly recommend that you
find the SPAN documentation
for your switch models before
configuring them. SPAN
operation is simple, but the
command options do change.
Finally, you may see the term
“ESPAN” in some SPAN
documentation. This is
Enhanced SPAN, and some of
Cisco’s documentation mentions
that this term has been used so
often to describe different
additions that the term has lost

meaning. You’ll still see it
occasionally, but it doesn’t refer
to any specific addition or
change to SPAN.

Filtering Intra-VLAN
Traffic
At this point in your Cisco
studies, you’re very familiar
with access lists and their
many, many, many uses! Access
lists do have their limitations,
though. While an ACL can filter
traffic traveling between
VLANs, it can’t do anything

about traffic from one host in a
VLAN to another host in the
same VLAN.
Why not? It relates to how
ACLs are applied on a
multilayer switch. You know
that the CAM (Content
Addressable Memory) table
holds the MAC addresses that
the switch has learned, but the
tCaM - Ternary Content
Addressable Memory - cuts
down on the number of lookups
required to compare a packet
against an ACL.

This filtering of packets by the
switch hardware speeds up the
process, but this limits ACL
capability. An ACL can be used
to filter inter-VLAN traffic, but
not intra-VLAN traffic. To filter
traffic between hosts in the
same VLAN, we’ve got to use a
VLAN Access List (VACL).

Even though a VACL will do the
actual filtering, an ACL has to
be written as well. The ACL will
be used to as the match
criterion within the VACL. For
example, let’s say we have the
subnet 172.10.10.0 /24’s
addresses configured on hosts
in VLAN 100. The hosts
172.10.10.1 - 3 are not to be
allowed to communicate with
any other hosts on the VLAN,
including each other. An ACL
will be written to identify these
hosts.

Notice that even though the
three source addresses named
in the ACL are the ones that
will not be allowed to
communicate with other hosts
in the VLAN, the ACL statement
is permit, not deny. The deny
part is coming!
Now the VLAN access-map will
be written, with any traffic
matching the ACL to be
dropped and all other traffic to
be forwarded.
Note that the second accessmap clause has no match

clause, meaning that any traffic
that isn’t affect by clause 10
will be forwarded. That is the
VACL equivalent of ending an
ACL with “permit any”. If you
configure a VACL without a final
“action forward” clause as
shown below, all traffic that
does not match a specific
clause in the VACL will be
dropped.

Finally, we’ve got to apply the
VACL. We’re not applying it to a
specific interface - instead,
apply the VACL in global
configuration mode. The VLAN
to be filtered is specified at the
end of the command with the
vlan- list option.

Some additional notes and tips
regarding VACLs:
Bridged traffic, as well
as non-IP and non-IPX
traffic, should be
filtered with VACLs

VACLs run from top to
bottom, and run until a
match occurs
VACLs have an implicit
deny at the end. The
VACL equivalent of
“permit all” is an
“action forward” clause
with no match criterion,
as shown in the
previous example. If
traffic is not expressly
forwarded, it’s implicitly
dropped!
Only one VACL can be
applied to a VLAN
The sequence numbers

allow you to go back
and add lines without
rewriting the entire
VACL. They are still
active while being
edited.
A routing ACL can be
applied to a SVI to filter
inbound and/or
outbound traffic just as
you would apply one to
a physical interface, but
VACLs are not applied
in that way - they’re
applied in global
configuration mode.

On L3 switches, you may run
into a situation where there’s a
VACL configured, and a
“normal” ACL affecting
incoming traffic is applied to a
routed port that belongs to that
same VLAN. In this case,
packets entering that VLAN will
be matched against the VACL
first; if the traffic is allowed to
proceed, it will then be
matched against the inbound
ACL on that port.

A Possible Side Effect Of
Performing ACL

Processing In Hardware
At the beginning of the VACL
section, I mentioned that ACL
processing in multilayer
switches is performed in
hardware. There will still be
some traffic that is sent to the
CPU for software processing,
and that forwarding rate is
much lower than the rate for
the traffic forwarded by the
switch hardware. If the
hardware hits its storage limit
for ACL configs, resulting in
even more packets begin sent
to the CPU, the switch

performance can degrade. (I’ve
seen that, and it’s ugly. Avoid
it.)
Cisco’s website lists two other
factors that may result in too
many packets being sent to the
CPU, and they may surprise
you:
Excessive logging
Use of ICMP
Unreachable messages
Use the log option with care.
Logging must be performed by
the switch software, not the

hardware.

Private VLANs
If you want to hide a host from
the world - even going as far as
hiding a host from other hosts
in the same VLAN and subnet private VLANs are the way to
go.
Using these is really getting
away from it all.
This concept can throw you a
bit at first, since a private VLAN
is truly unlike anything we’ve

looked at with VLANs to date and the terminology is
different, too. So hang in there
- it’ll be second nature before
you know it.
With private VLANs, we have…
three port types - one type that
talks to everybody, one that
talks to somebody, and one
that talks to practically nobody
two kinds of private VLANs,
primary and secondary
two kinds of secondary VLANs,

community and isolated
Let’s break this concept down,
starting with the port types.
Hosts that need to talk to
everyone will be connected to
promiscuous ports. This port
type can communicate with any
host connected to any of the
other two port types. When you
have a router or multilayer
switch that serves as a default
gateway, that device must be
connected to a promiscuous
port for the network to function
correctly.

Hosts that just need to talk to
some other devices are
connected to community ports.
These hosts can communicate
with other community ports in
the same private VLAN as well
as any device connected to a
promiscuous port.
Hosts that just don’t want
anything to do with almost
anybody are connected to
isolated ports. The only hosts
that these hosts can
communicate with are devices
connected to promiscuous
ports. Even if you have two

isolated ports in the same
private VLAN, those hosts will
not be able to communicate
with each other.
Those are the port types - now
let’s take a striaghtforward look
at the private VLAN types.
The “parent” Private VLAN is
the primary private VLAN.
The “child” Private VLAN is the
secondary private VLAN.
That’s really it.
In our configuration, we’ll be

mapping primary private VLANs
to secondary private VLANs. A
primary Private VLAN can be
mapped to multiple
secondaries, but a secondary
Private VLAN can be mapped to
only one primary.
In turn, we have two secondary
VLAN types.
Ports in a community private
VLAN can communicate with
other ports in the same
community as well as
promiscuous ports in the
primary.

Ports in an isolated private
VLAN can only communicate
with promiscuous ports in the
parent primary VLAN. We’re
limited to one of these per
parent primary VLAN, but since
the ports in an isolated private
VLAN can’t intercommunicate,
we only need one.
Each of these concepts is
illustrated in the following
diagram:

Host A has been placed into an
isolated private VLAN, and will
be able to communicate only
with the router, which is
connected to a promiscuous
port. If we placed another host
in the same isolated private
VLAN that Host A is in now, the

two hosts could not
communicate with each other.
The other hosts are in a
community private VLAN, so
they can communicate with
each other as well as the
router. They can’t communicate
with Host A.
In the following configuration,
we’ll use the following VLANs
and VLAN types:
VLAN 100 as a secondary
private VLAN (community);
ports in this VLAN are fast 0/1 -

5.
VLAN 200 as a secondary
private VLAN (isolated); ports
in this VLAN are fast 0/6- 10.
VLAN 300 will be the primary
private VLAN. This port leads to
a router via fast 0/12.
Creating the first VLAN with
VLAN config mode is no
problem, but look what
happens when we try to make
it a community private VLAN or any kind of private VLAN, for
that matter….

\

Please note that private VLANs
can only be configured when
VTP is in transparent mode.
(Yeah, I know, like it says right
there.) Once we do that,
configuring VLAN 100 as a
community private VLAN is no
problem.

Now we’ll configure VLAN 300
as the primary private VLAN,
and then associate those two
secondary private VLANs with
this primary private VLAN. (This
association is not the mapping I
mentioned earlier.)

So at this point, we’ve…
Configured VTP to run in
transparent mode
Created our secondary private
VLANs, both isolated and
community Created our primary
private VLAN
Created an association
between the secondary and
primary private VLANs
Just one more little thing to
do… place the ports into the
proper VLAN and get that

mapping done! (Okay, that’s
two things.)
The switch port leading to the
router is fast 0/12; that port
must be made promiscuous.

We’ll also need the primary
vlan mapping command on that
interface:

Ports fast 0/1 - 5 are in VLAN
100. We’ll use the interface
range command to configure
that port range all at once with
the private-vlan host and
private-vlan host-association
commands.

On ports fast 0/ 6 - 10 (in VLAN
200), it’s about the same story,
except the host-association
command will end with 200
rather than 100.

You can verify all of your

private VLANs with show vlan
private-vlan (really!) and on an
interface level with the
command show interface
switchport (output truncated):

Note the trunk options at the
end of that output. You can
change those and other trunkrelated values with the
switchport private-vlan trunk

commands.

DHCP Snooping
It may be hard to believe, but
something as innocent as DHCP
can be used for network
attacks. The potential for
trouble starts when a host
sends out a DHCPDiscovery
packet, it listens for DHCPOffer
packets - and as we know, the
host will accept the first Offer it
gets!

Part of that DHCPOffer is the
address to which the host
should set its default gateway.
In this network, there’s no
problem, because there’s only
one DHCP Server. The host will
receive the DHCPOffer and set
its default gateway accordingly.
What if a DHCP server that

does not belong on our network
- a rogue DHCP server - is
placed on that subnet?

Now we’ve got a real problem,

because that host is going to
use the information in the first
DHCPOffer packet it receives and if the host uses the Offer
from the rogue DHCP server,
the host will actually set its
default gateway to the rogue
server’s IP address!
The rogue server could also
have the host set its DNS
server address to the rogue
server’s address as well. This
opens the host and the network
to several nasty kinds of
attacks.

DHCP Snooping allows the
switch to serve as a firewall
between hosts and untrusted
DHCP servers. DHCP Snooping
classifies interfaces on the
switch into one of two
categories - trusted and
untrusted.
DHCP messages received on
trusted interfaces will be
allowed to pass through the
switch. Not only will DHCP
messages received on
untrusted interfaces be dropped
by the switch, the interface
itself will be placed into err-

disabled state.

Now, you’re probably asking
“How does the switch
determine which ports are

trusted and which ports are
untrusted?” By default, the
switch considers all ports
untrusted - which means we
better remember to configure
the switch to trust some ports
when we enable DHCP
Snooping!
First, we need to enable DHCP
Snooping on the entire switch:

You must then identify the
VLANs that will be using DHCP
Snooping. Let’s use IOS Help to
look at the other options

available.

Note that you can use commas
and dashes to define a range of
VLANs for DHCP Snooping. We’ll
create three VLANs on this
switch and then enable DHCP
Snooping only for VLAN 4.

Assuming we have a trusted
DHCP server off port 0/10, we
would then trust that port with
the following command:

From your previous studies,
you’re familiar with the DHCP
Relay Agent Information option.
Usually referred to as Option 82
(we still don’t know what
happened to the first 81
options), this option can be
disabled or enabled with the
following command:

DHCP Snooping is verified with
the show ip dhcp snooping
command.

The key information here, from
top to bottom:
DHCP Snooping is
enabled on the switch
VLAN 4 is the only VLAN
using DHCP Snooping
Option 82 is enabled,
but not allowed on
untrusted ports
The only trusted port is

fast 0/10
Note the “rate limit” for the
untrusted port is set to
“unlimited”. That rate limit
refers to the number of DHCP
packets the interface can
accept in one second (packets
per second).

Dynamic ARP
Inspection
Just as we must protect against
rogue DHCP servers, we have

to be wary of rogue ARP users
as well.
From your CCNA studies, you
know all about Address
Resolution Protocol and how it
operates. A rogue device can
overhear part of the ARP
process in action and make
itself look like a legitimate part
of the network. This happens
through ARP Cache Poisoning.
(This is also known as ARP
Spoofing - be aware of both
names for your exam.)
ARP Cache Poisoning starts

innocently enough - in this
case, through the basic ARP
process on a switch.

Host A is sending an ARP
Request, requesting the host
with the IP address 172.12.12.2
to respond with its MAC
Address. Host B will receive the
request, but before responding,
Host B will make an entry in its

local ARP cache mapping the IP
address 172.12.12.1 to the MAC
address aa-aa-aa-aa-aa-aa.
Once Host A receives that ARP
Reply, both hosts will have a
MAC address - IP address
mapping for the remote host.

The problem comes in if a
rogue host responds to the
original ARP Request with its
own MAC address.

Now Host A will make an entry
in its ARP cache mapping the IP
address 172.12.12.2 to cc-cccc-cc-cc-cc. Meanwhile, the
rogue host will acquire Host B’s
true MAC address via ARP,
which leads to this process:

1. When Host A
transmits data to
the IP address
172.12.12.2 with a
MAC address of cccc-cc-cc-cc-cc, the
data is actually
being received by
the rogue host.
2. The rogue host will
read the data and
then possibly
forward it to Host B,
so neither Host A
nor Host B
immediately notices
anything wrong.

The rogue host has effectively
placed itself into the middle of
the communication, leading to
the term man in the middle for
this kind of network attack.
When the rogue host does the
same for an ARP Request being
sent from Host B to Host A, all
communications between Host
A and Host B will actually be
going through the rogue host.
Enabling Dynamic ARP
Inspection (DAI) prevents this
behavior by building a database
of trusted MAC-IP address
mappings. This database is the

same database that is built by
the DHCP Snooping process,
and static ARP configurations
can be used by DAI as well.
DAI uses the concept of trusted
and untrusted ports, just as
DHCP Snooping does. However,
untrusted ports in DAI do not
automatically drop ARP
Requests and Replies.
Once the IP-MAC address
database is built, every single
ARP Request and ARP Reply
received on an untrusted
interface is examined. If the

ARP message has an approved
MAC-IP address mapping, the
message is forwarded
appropriately; if not, the ARP
message is dropped.
If the interface has been
configured as trusted, DAI
allows the ARP message to
pass through without checking
the database of trusted
mappings. DAI is performed as
ARP messages are received,
not transmitted.
Since DAI uses entries in the
DHCP Snooping database to do

its job, DHCP Snooping must be
enabled before beginning to
configure DAI. After that, the
first step in configuring DAI is
to name the VLAN(s) that will
be using DAI.

Just as with DHCP Snooping,
you can specify a range of
VLANs with hyphens and
commas. Also just as with
DHCP Snooping, all ports are

considered untrusted until we
tell the switch to trust them,
and we do that with the ip arp
inspection trust interface-level
command.

You may have noticed a
validate option in the ip arp
inspection command above.
You can use the validate option
to go beyond DAI’s default
inspection. Let’s use IOS Help
to take a look at our choices:

You can actually specify
validation of more than one of
those addresses.
Here’s what happens with each:
“src-mac” compares the source
MAC address in the Ethernet
header and the MAC address of
the source of the ARP message.
“dst-mac” compares the
destination MAC address in the
Ethernet header and the MAC
destination address of the ARP

message.
“ip” compares the IP address of
the sender of the ARP Request
against the destination address
of the ARP Reply.
We’ll use the “ip” option and
then verify the configuration
with show ip arp inspection.

That show command results in
a great deal of output, but as
you apply DAI in your network,
you should run this command
regularly to spot potential
rogue hosts on your network. A

large number of validation
failures is one indicator of such
a rogue!
If you run DAI in your network,
most likely you’ll run it on all of
your switches. Cisco’s
recommended
trusted/untrusted port
configuration is to have all
ports connected to hosts run as
untrusted and all ports
connected to switches as
trusted. Since DAI runs only on
ingress ports, this configuration
scheme ensures that every ARP
packet is checked once, but no

more than that.
There is no problem with
running DAI on trunk ports or
ports bundled into an
Etherchannel.

IP Source Guard
We can use IP Source Guard to
prevent a host on the network
from using another host’s IP
address. IP Source Guard works
in tandem with DHCP Snooping,
and uses the DHCP Snooping
database to carry out this
operation.
As with DAI, DHCP Snooping
must be enabled before
enabling IP Source Guard.
When the host first comes
online and connects to an
untrusted port on the switch,

the only traffic that can reach
that host are DHCP packets.
When the client successfully
acquires an IP address from the
DHCP Server, the switch makes
a note of this IP address
assignment.

The switch will then
dynamically create an VLAN
ACL (VACL) that will only allow

traffic with the corresponding
source IP address to be
processed by the switch. This
IP address-to-port mapping
process is called binding.

If the host pretends to be
another host on that subnet, or
to spoof that host’s IP address - 172.12.12.100, for example -the switch will simply filter that

traffic because the source IP
address will not match the
database’s entry for that port.

To enable IP Source Guard, use
the ip verify source vlan
command on the appropriate
interfaces once DHCP snooping
has been enabled with ip dhcp
snooping. You can specify a
VLAN range as we have in the
past with commas and dashes,

or with a range as shown
below, entering the first and
last numbers in the range.

You do have the option of using
both the IP and MAC source
addresses to use as match
criteria for incoming frames, or
you can use the default of IP
address only.

To use the MAC source
addresses in addition to the IP
address, use the port-security
option with the ip verify source
command. Using that command
with no options will only use
the IP address in the matching
process.

MAC Address Flooding
Attacks
Since ARP, IP addresses, and

DHCP all have potential
security issues, we can’t leave
MAC addresses out - because
network attackers sure won’t
do so!
A MAC Address Flooding attack
is an attempt by a network
intruder to overwhelm the
switch memory reserved for
maintenance of the MAC
address table. The intruder
generates a large number of
frames with different source
MAC addresses - all of them
invalid. As the switch’s MAC
address table capabilities are

exhausted, valid entries cannot
be made - and this results in
those valid frames being
broadcast instead of unicast.
This has three side effects, all
unpleasant:
As mentioned, the MAC
address table fills to
capacity, preventing
legitimate entries from
being made.
The large number of
unnecessary broadcasts
quickly consumes
bandwidth as well as

overall switch resources
The intruder can easily
intercept packets with a
packet sniffer, since the
unnecessarily
broadcasted packets
will be sent out every
port on the switch including the port the
intruder is using.
You can combat MAC Address
Flooding with two of the
features we addresses earlier in
this section - port-based
authentication and port
security. By making sure our

host devices are indeed who
we think they are, we reduce
the potential for an intruder to
unleash a MAC Address
Flooding attack on our network.
The key isn’t to fight the
intruder once they’re in our
network - the key is to keep
them out in the first place.

VLAN Hopping
We’ve seen how intruders can
use seemingly innocent ARP
and DHCP processes can be
used to harm our network, so it

shouldn’t come as any surprise
that Dot1q tagging can be used
against us as well!
One form of VLAN Hopping is
double tagging, so named
because the intruder will
transmit frames that are
“double tagged” with two
separate VLAN IDs. As you’ll
see in our example, certain
circumstances must exist for a
double tagging attack to be
successful:
The intruder’s host
device must be

attached to an access
port.
The VLAN used by that
access port must be the
native VLAN.
The term “native VLAN”
tips us off to the third
requirement - dot1q
must be the trunking
protocol in use, since
ISL doesn’t use the
native VLAN.

When the rogue host transmits

a frame, that frame will have
two tags. One will indicate
native VLAN membership, and
the second will be the number
of the VLAN under attack. In
this example, we’ll assume that
to be VLAN 100.

The trunk receiving this doubletagged frame will see the tag
for VLAN 25, and since that’s

the native VLAN, that tag will
be removed and then
transmitted across the trunk but the tag for VLAN 100 is still
there!

When the switch on the other
side of the trunk gets that
frame, it sees the tag for VLAN
100 and forwards the frame to
ports in that VLAN. The rogue

now has successfully fooled the
switches and has hopped from
one VLAN to another.
VLAN Hopping seems innocent
enough, but it’s quite the
opposite. VLAN Hopping has
been used for network attacks
ranging from Trojan horse virus
propagation to stealing bank
account numbers and
passwords. That’s why you
often see the native VLAN of a
network such as the one above
set to a VLAN that no host on
the network is a member of that stops this version of VLAN

Hopping right in its tracks.

Notice that I said “this version”.
Switch spoofing is another
variation of VLAN Hopping that
is even worse than double
tagging, because this version
allows the rogue to pretend to
be a member of *all* VLANs in
your network.
Many Cisco switch ports now
run in dynamic desirable mode
by default, which means that a

port is sending out Dynamic
Trunking Protocol frames in an
aggressive effort to form a
trunk. A potential problem
exists, since the switch doesn’t
really know what kind of device
is receiving the DTP frames.

This leads many wellintentioned network admins to
place such a port into Auto
mode, which means that port
will still trunk but it’s not

actively seeking to do so. That
in turn leads to another major
potential problem, because a
rogue host connected to a port
in Auto trunking mode can
pretend it’s a switch and send
DTP frames of its own - leading
to a trunk formed between the
switch and the rogue host!

When that trunk forms, the
rogue host will have access to
all VLANs - after all, this is now

a trunk!
Luckily, there’s a quick defense
for this attack. Every port on
your switch that does not lead
to another known switch should
be placed into access mode.
That disables the port’s ability
to create a trunk, and in turn
disables the rogue host’s ability
to spoof being a switch!

Cisco Discovery Protocol
(CDP) And Potential
Security Issues

Before we talk about how CDP
can pose a security risk to your
network, we need to review
what CDP does in the first
place.
Some networks have clear,
concise network maps that
show you every router, every
switch, and every physical
connection.
Some networks do not.
Part of troubleshooting is
quietly verifying what a client is
telling you. Fact is, you can’t

always take what a client says
at face value; just because he
says two switches are
physically connected, it doesn’t
mean that they are - but you
need to know!
You can check a Cisco device’s
physical connections with Cisco
Discovery Protocol, which runs
by default on Cisco routers and
switches, both globally and on
a per-interface level.
For security purposes, many
admins choose to disable CDP.
Here’s the command to see if

CDP is indeed running on a
router or switch:

That output means that CDP is
indeed enabled. If you see the
following, it’s off.

Here’s how to enable CDP:

The most commonly used CDP
command is show cdp
neighbor. I’ll move over to a
switch that has three physical
connections to other hosts to
show you the output of this
command.

This command shows us every
device this switch is physically
connected to, and gives us a
wealth of information as well!
From left to right…

Device ID is the remote
device’s hostname.
Local Interface is the local
switch’s interface connected to
the remote host.
Holdtime is the number of
seconds the local device will
retain the contents of the last
CDP Advertisement received
from the remote host.
Capability shows you what type
of device the remote host is.
The first two connections are to
a switch, and the third is to a

router.
Platform is the remote device’s
hardware platform. The top two
connections are to a 2950
switch, and the third is to a
2520 router.
Port ID is the remote device’s
interface on the direct
connection.
This is an excellent command
to verify what you’re seeing on
a network map or what a client
is telling you. I’ve been in more
than one situation where a

client said one thing and CDP
directly proved them wrong. It
may be best to use it when
they’re not around, but it can
also prove what you’re telling
the client.
Real-world courtesy: If your
client has CDP turned off, and
you turn it on for
troubleshooting, turn it back off
before you leave. It’s good for
the ol’ job security, too.
The commands cdp run and no
cdp run enable and disable CDP
on a global basis. CDP runs

globally on a Cisco device by
default.
You may want to leave CDP on
globally, but disable it on a
particular interface. To enable
or disable CDP on a perinterface basis, use cdp enable
and no cdp enable.

There are some other CDP
commands you may find
helpful, the first being show cdp
neighbors detail. This command

gives you a lot of detail about
every CDP neighbor, so I won’t
put it all here, but here’s a clip
of the output dealing with just
one of SW1 ’s neighbors. Note
that you can even see the
neighbor’s IOS version with this
command!

And right before I leave the
client site, I’d run show cdp

interface to verify that CDP is
running on the interfaces that it
should be running on - and not
running on the others! Here’s
the partial output of this
command on SW1:

So if CDP’s so great, why do
many network admins choose
to disable it on their networks?

These vulnerabilities should
sound familiar..
CDP sends all information in
clear text
CDP offers no authentication
What we used to do is disable
CDP globally, and that was
that, but it’s not so simple
anymore. Just about every
Cisco network management
product uses CDP in some form
to monitor the network and / or
create reports. What you can
do to minimize the risk of using

CDP is to determine which
interfaces really need to be
running and which ones do not,
and then run CDP on the
interfaces that need it.
In case you run into networks
that (gasp!) run non-Cisco
devices, you may run into the
Link Layer Discovery Protocol
(LLDP). This is the industrystandard equivalent of CDP.
Cisco devices can run it, but it’s
disabled by default.

Telnet And SSH

Telnet’s a great way to
communicate remotely with
routers and switches, but
there’s a problem - all of the
data sent to the remote host,
including passwords, is
transmitted in clear text. Any
would-be network intruder who
intercepts the password
transmission can then easily
enter the network via Telnet,
and then we’re in real trouble!

Secure Shell (SSH) is basically
“encrypted Telnet”, since the
basic operation of SSH is just
like Telnet’s, but the data
(including the password) is
encrypted.

For this very simple and very
powerful reason, SSH is
preferred over Telnet. But I can
hear you now - “Then why does
my company still use Telnet
instead of SSH?” Telnet is very
easy to set up, but SSH does
take a little more work (and
perhaps a little more
hardware).

To use SSH, we’ll have to use
one of the following
authentication methods:
A local database on the
router
Authentication via AAA,
enabled with aaa newmodel
Telnet allows the use of a
password that’s configured
directly on the VTY lines, but
SSH does not.
When using a local database
for SSH, the first step is to

configure login local on the VTY
lines, rather than the login
command we used for the
Telnet configuration. Remove
any passwords from the VTY
lines as well. The login loca^l
command tells the switch to
look to a database on the local
device for valid
username/password
combinations.

Then we’ll create the
username/password database.

When a user attempts to
connect, the user must specify
a username in this database
and supply the password
assigned to that username.
Getting one or the other right
isn’t enough! That’s much more
secure than the one-passwordfits-all configuration many
Telnet configs use.
We could use the
username/password command
to create a database strictly for
Telnet, and the login local

command would have the same
effect. Where the Telnet and
SSH configuration differ is that
the SSH config requires the
following where Telnet does
not:
A domain name must
be specified with the ip
domain-name
command
A crypto key must be
created with the crypto
key generate rsa
command
Create the domain name with

the ip domain-name command.
Also, if the router has no name,
give it one with the hostname
command.

When you generate the key
with crypto key generate rsa,
you’ll get this readout:

• If you’re getting
“unrecognized command” for

valid SSH commands, the most
likely reason is that you
skipped this step.
You may want to accept only
SSH on the vty lines and refuse
attempted Telnet connections.
To do so, enable only SSH with
the transport input command
on the vty lines.

To set the SSH timeout value,
use the ip ssh time-out
command. Note that IOS Help
tells us to enter the command

in seconds, not minutes.

To set the maximum number of
SSH authentication retries, use
the ip ssh authentication-retries
command.

Here are some other SSH
options - another common one
to set is the maxstartups
option.

• There’s one more similarity
between Telnet and SSH - you
can still use ACLs to determine
who should be able to connect
via SSH, and you still use the
access-class command to apply
that ACL to the vty lines. Here,
I’ve created a named ACL that
denies a single host address
and permits all others. The
named ACL is then applied to
the vty lines.

Review: Creating
Banners
For legal reasons, you may
want to warn users that
unauthorized access to the
router or switch is prohibited.
You can present this message,
or any message you feel
appropriate, with the banner
command. (Inappropriate
messages are best left for
home lab practice!)

The banner command has a
few options, the most common
of which is the Message Of The
Day (MOTD) option.

We’ll select motd, then use IOS
Help to view our options.

That description of the LINE
command can be a little
confusing, so using a dollar sign
as the delimiting character,

here’s how to configure a MOTD
banner message.

It doesn’t matter what symbol
or letter you use for the
delimiting character, but you
have to use the same one to
begin and end the message.
When I entered a dollar sign as
the delimiting character, the
switch told me to end my text
message with the dollar sign.
I log out of the switch, then
come back in, and I’m

presented with the MOTD
banner message.

If we want to add a warning to
that - say, a message warning
against unauthorized access we can create a login banner.
That banner’s contents will
appear after the MOTD, but
before the login prompt.

I’ve added a console line
password of cisco as well:

When I log out and then log
back in, I see the MOTD banner
message followed by the login
banner message.

This is how you’ll see the
banners appear in the config:

You may want to present a
banner message to users who
have successfully

authenticated, and you can do
that with the banner exec
command. You can use the
ENTER key for hard breaks in a
banner message, as shown
below.

After logging out and back in,
the exec banner is presented
after I successfully authenticate
with the password cisco.

A Little HTTP Security
With products such as Security
Device Manager, you’ll need to
set up a little something called
“HTTP Secure Server”. This is
required since a web-based
interface doesn’t offer
encryption, and that’s a poor
beginning for a security
implementation.

• You’ll need to enable HTTPS
and HTTP local authentication
with the ip http secure-server
and ip http authentication local
commands. That last command
enables the use of a local
database for HTTPS
authentication; we create that
with the username/ password
command.
• Note the result of the ip http
secure-server command.

You could also use the crypto
key generate rsa command to
create that certificate.

Real-World Security
Plans, Concerns, And
Conversations
This section might help you on
the CCNP SWITCH exam.
It will definitely help you in
real-world networking
situations - so while this topic
isn’t quite as exciting as
configuring security solutions,

it’s just about as important.
This section is about the
important of planning and
having the right conversations
before you start implementing
your security solution.
Conversation with whom, you
ask?

Define Expectations
With Your Client
Your average client expects
that when you’re done
implementing a network

security solution, he’ll be
protected against everything
and everyone that will ever
want to do his network harm.
Forever.
You and I both know that this is
an unrealistic expectation - but
the client might not know that,
and we need to do two things
before we even get started on
this job:
You need to define exactly
what the limits are of the
network solutions, what’s

guaranteed, what’s not, and…
…you need to put this into
writing.
Why go to this trouble? Let’s
say that you put in a security
solution for a client, and
everything’s just fine for three
years. Then someone
somewhere comes up with a
SuperVirus that infects his
network.
That client will say many
things, but “Oh well, that’s just
the way it goes” is not one of

them. He may say a few things
to their corporate attorney, and
then you’re really off to the
races.
Here’s how serious this is Cisco has a security feature
called AutoSecure that has a
setting actually called One-Step
Lockdown. Every Cisco security
best practice you can think of is
applied to this router. And
before it even starts, you’re
presented with a warning that
while Cisco has done
everything they can to make
this a secure solution, they

can’t guarantee that nothing
bad will ever happen to that
router.
And if Cisco can’t guarantee it,
you shouldn’t be guaranteeing
it either.
I don’t say this to scare you but it’s just part of the world we
live in. Be sure you clearly
define expectations and
limitations of any security
solution with your client - and
get him to sign off on it.

Don’t Just Jump In
I’ve known a network admin or
two in my life that weren’t real
big on planning - they just liked
to put their hands on the
routers and start configurin’.
I’m not always the most patient
fellow in the world, but I never
touch the client’s network
without taking care of some
other tasks first. Your
company’s prerequisites likely
differ, but these steps are a
good idea no matter what
you’re implementing.

Test your solution on a pilot
network. Nothing’s worse than
rolling out a security solution
and then finding it’s
incompatible with your OSes,
desktops, or anything else.
Run an audit or have an
auditing firm do it. You’ve gotta
know what’s out there in the
network before you can protect
it - and you can’t depend on the
client or old inventory lists for a
complete picture of the
network. The audit should
include both the hardware and
software in use.

Take an incremental approach.
If something’s going to go
wrong, I’d rather find out about
it while it’s affecting a small
part of the network rather than
the whole thing. Whether it’s
email or security, or anything in
between, never migrate /
install / implement on a
network-wide basis if it can
possibly be helped. Roll it out
incrementally.
Have an emergency plan /
rollback plan / parachute /
whateveryouwannacallit. If
something goes wrong, you

cannot say “Hey, I don’t know
what to do now.” You need to
be ready to put the network
back into its prior, operational
state. This goes for anything
you install on a network.
And during the process, you
should create a few things for
your client (and you) as well:
Create a definitive security
policy. Put it in writing - what
will be allowed, what behaviors
will be prohibited, and what
actions will be taken when an
undesirable behavior takes

place?
Create an incident response
plan. Look, after you leave,
something’s going to happen
sooner or later. Have a plan in
place to handle it and update it
as time goes by.

Free Videos From My YouTube
and Udemy channels: Dotlx
Video Boot Camp:

http://www.youtube.com/watch?
v=2ahUCRSDGpw

Full YouTube Channel - Join Us
Today!

http://www.youtube.com/user/cc

Multilayer Switching
& High Availability
Services And
Protocols
When you’re learning basic
routing and switching theory in
your CCNA studies, the two
processes are taught as
separate operations that
happen on two separate

physical devices -- switches
switch at Layer 2, routers
router at Layer 3, and never
the two shall meet…

… until now.
While they are separate
operations, devices that can
perform both routing and
switching are more and more
popular today. These devices
are Layer 3 switches, or

multilayer switches.

What Is Multilayer
Switching?
Multilayer switches are devices
that switch and route packets
in the switch hardware itself. A
good phrase to describe a
multilayer switch is “pure
performance” - these switches
can perform packet switching
up to ten times as fast as a
pure L3 router.
Multilayer switches make it

possible to have inter-VLAN
communication without having
to use a separate L3 device or
configuring router-on-a- stick. If
two hosts in separate VLANs
are connected to the same
multilayer switch, the correct
configuration will allow that
communication without the
data ever leaving that switch.
When it comes to Cisco
Catalyst switches, this
hardware switching is
performed by a router
processor (or L3 engine). This
processor must download

routing information to the
hardware itself. To make this
hardware-based packet
processing happen, Cat
switches will run either the
older….um, I mean “legacy”
Multilayer Switching (MLS), or
the newer Cisco Express
Forwarding (CEF).
Application-Specific Integrated
Circuits (ASICs) will perform the
L2 rewriting operation of these
packets. You know from your
CCNA studies that while the IP
source and destination address
of a packet will not change

during its travels through the
network, the L2 source and
addresses may and probably
will. With multilayer switching,
it’s the ASICs that perform this
L2 address overwriting.

The CAM And TCAM
Tables
You learned early in your CCNA
studies that we really like
having more than one name for
something in networking - and
that’s particularly true of the
MAC address table, which is

also known as the bridging
table, the switching table, and
the Content Addressable
Memory table - the CAM table.
Multilayer switches still have a
CAM table and it operates just
as an L2 switch’s CAM table
does - but we have a lot more
going on with our L3 switches,
including routing, ACLs, and
QoS.
A simple CAM table can’t
handle all of this, so in addition
to the CAM table we have a
TCAM table - Ternary Content

Addressable Memory. Basically,
the TCAM table stores
everything the CAM table can’t,
including info about ACLs and
QoS.

Multilayer Switching
Methods
The first multilayer switching
(MLS) method is route caching.
Route caching devices have
both a routing processor and a
switching engine. The routing
processor routes a flow’s first
packet, the switching engine

snoops in on that packet and
the destination, and the
switching engine takes over
and forwards the rest of the
packets in that flow.
Now, what exactly does a
“flow” consist of? A flow is a
unidirectional stream of packets
from a source to a destination,
and packets on the same flow
will share the same protocol.
That is, if a source is sending
both WWW and TFTP packets
to the same destination, there
are actually two flows of traffic.
The MLS cache entries support

such unidirectional flows.
Route Caching can be effective,
but there’s one slight drawback
- the first packet in any flow
will be switched by software.
Even though all other packets
in the flow will be hardwareswitched, it is more effective
for us to have all of the packets
switched by hardware - and
that’s what we get with CEF.
Cisco Express Forwarding (CEF)
is a highly popular method of
multilayer switching. Primarily
designed for backbone

switches, this topology-baseo
switching method requires
special hardware, so it’s not
available on all L3 switches.
CEF can’t be configured on
2950 switches, but you will see
it on 3550s and several other
higher-numbered series. CEF is
highly scalable, and is also
easier on a switch’s CPU than
route caching.
CEF has two major components
- the Forwarding Information
Base and the Adjacency Table.

CEF-enabled devices the same
routing information that a
router would, but it’s not found
in a typical routing table. CEFenabled switches keep a
Forwarding Information Base
(FIB) that contains the usual
routing information - the
destination networks, their
masks, the next-hop IP
addresses, etc - and CEF will
use the FIB to make L3 prefixbased decisions.
The FIB’s contents will mirror
that of the IP routing table actually, the FIB is really just

the IP routing table in another
format. You can view the FIB
with the show ip cef command.

Not exactly the routing table
we’ve come to know and love!
However, running CEF doesn’t
prevent us from configuring
access-lists, QoS, or other
“regular” traffic filtering
features that routers use every
day.
The routing information in the

FIB is updated dynamically as
change notifications are
received from the L3 engine.
Since the FIB is prepopulated
with the information from the
routing table, the MLS can find
the routing information quickly.
Should the TCAM hit capacity,
there’s a wildcard entry that
will redirect traffic to the
routing engine.
The FIB takes care of the L3
routing information, but what of
the L2 information we need?
That’s found in the Adjacency

Table (AT). As adjacent hosts
are discovered via ARP, that
next-hop L2 information is kept
in this table for CEF switching.
(A host is considered adjacent
from another if they’re just one
hop apart.)
Like the TCAM, if the AT hits
capacity, there is a wildcard
entry pointing to the L3 engine.
To sum it up:
The FIB contains L3 information
and is created via the IP
routing table.

The AT contains L2 information
and is created via the ARP
table.
There are some special cases
when it comes to adjacencies:
Remember the Null0 route
created by route
summarization? Basically, it’s a
route to nowhere. A null
adjacency is said to be formed
for these packets, and they’re
dropped.
If we have packets that need
some attention from the L3

engine rather than being
switched in hardware (or if they
can’t be switched by hardware
for some reason), that’s a punt
adjacency.
Ingress packets are dropped via
a drop adjacency or a discard
adjacency.
Once the appropriate L3 and L2
next-hop addresses have been
found, the MLS is just about
ready to forward the packet.
The MLS will make the same
changes to the packet as a
router normally would, and that

includes changing the L2
destination MAC address that’s going to be changed to
the next-hop destination, as I’m
sure you remember from your
CCNA studies. The L3
destination will remain the
same.
(The L2 source address will
change as well, to the MAC
address on the MLS switch
interface that transmits the
packet.)
Enabling CEF is about as simple
as it gets. CEF is on by default

on any and all CEF-enabled
switches, and you can’t turn it
off. Remember, CEF is
hardware-based, not softwarebased, so it’s not a situation
where running “no cef” on a
switch will disable CEF. There’s
no such command!
A multilayer switch must have
IP routing enabled for CEF to
run, however. Trying to view
the FIB of a switch with IP
routing not enabled results in
this console readout…

… and then after enabling IP
routing.

As with several advanced L3
switching capabilities, not every
L3 switch can run CEF. For
instance, the 2900XL and
3500XL do not support CEF.
Keep in mind that switches that
do support CEF do so by
default, and CEF can’t be
turned off on those switches!

CEF does support per-packet
and per-destination load
balancing, but the capabilities
differ between Cisco switch
models. The default CEF load
balancing mode is perdestination, where packets for
any particular destination will
take the same path from start
to finish, even if other valid
paths are available.

The Control Plane And
The Data Plane
These are both logical planes

found in CEF multilayer
switching, and I know you
won’t be surprised to find they
are also referred to by several
different names.
These all refer to the control
plane:
“CEF control plane”
“control plane”
“Layer 3 engine” or
“Layer 3 forwarding
engine”
The control plane’s job is to
first build the ARP and IP

routing tables, from which the
AT and FIB will be derived,
respectively.
In turn, the data plane is also
called by several different
names:
“data plane”
“hardware engine”
“ASIC”
The control plane builds the
tables necessary for L3
switching, but it’s the data
plane that does the actual
work! It’s the data plane that

places data in the L3 switch’s
memory while the FIB and AT
tables are consulted, and then
performs any necessary
encapsulation before
forwarding the data to the next
hop.

Exceptions To The Rule
(Of L3 Switching, That
Is)
Exception packets are packets
that cannot be hardware
switched, which leaves us only
one option - software

switching! Comparing hardware
switching to software switching
is much like comparing the hare
to the tortoise - but these
tortoises are not going to win a
race. Here are just a few of the
packet types that must be
software switched:
Packets with IP header
options
Packets that will be
fragmented before
transmission (because
they’re exceeding the
MTU)
NAT packets

Packets that came to
the MLS with an invalid
encap type
Note that packets with TCP
header options are still
switched in hardware; it’s the
IP header options that cause
trouble!

Is “Fast Switching”
Really That Fast?
With so many switching options
available today, it’s hard to
keep up with which option is

fastest, then next-fastest, and
so on. According to Cisco’s
website, here’s the order;
1. Distributed CEF
(DCEF). The name
is the recipe - the
CEF workload is
distributed over
multiple CPUs.
2. CEF
3. Fast Switching
4. Process Switching
(sometimes jokingly
referred to as “slow
switching” - it’s
quite an involved

process and is a
real CPU hog)

Inter-VLAN Routing
Now that we have the
(important) nuts and bolts out
of the way, let’s configure an L3
switch!
Multilayer switches allow us to
create a logical interface, the
Switched Virtual Interface
(SVI), that represents the
VLAN. Remember that the L2
switches you’ve worked with

have an “interface VLAN1” by
default?
interface Vlan1
no ip address
no ip route-cache
shutdown
That’s actually a switched
virtual interface (SVI). An SVI
exists for VLAN 1 by default,
but that’s the only VLAN that
has a “pre-created” SVI. As you
recall from your CCNA studies,
this VLAN 1 SVI is for remote

switch administration.
On an MLS, such a logical
interface can be configured for
any VLAN, and you configure it
just as you would any other
logical interface, such as a
loopback interface - just go into
config mode, create the
interface and assign it an IP
address, and you’re on your
way.

MLS(config)#interface vlan 10

MLS(config-if)#ip address
10.1.1.1 255.255.255.0
Let’s put SVIs to work with a
basic interVLAN routing
configuration.

To allow these two hosts to
communicate, you know that
we’ve got to have an L3 device
- and now we have a different
kind of L3 device than you’ve
used before. This L3 switch will

allow interVLAN communication
without involving a router.
Before we begin configuring,
we’ll send pings between the
two hosts. (In this example, I’m
using routers for hosts, but
there are no routes of any kind
on them.)

As expected, neither host can
ping the other. Let’s fix that!

To get started, we’ll put the
port leading to Host 1 into
VLAN 11, and the port leading
to Host 3 in VLAN 33.

We’re going to create two SVIs
on the switch, one representing
VLAN 11 and the other
representing VLAN 33. Note
that both SVIs show as up/up
immediately after creation.
Some Cisco and non-Cisco

documentation mentions that
you should open the SVIs after
creating them, but that’s not
necessarily the case in the real
world. Couldn’t hurt, though. :)

Only one VLAN per SVI, please.
If you don’t see “up” for the
interface itself and/or the line
protocol, you likely haven’t
created the VLAN yet or placed

a port into that VLAN. Do those
two things and you should see
the following result with show
interface vlan. I’ll only show the
top three rows of output for
each SVI.

Now let’s check that routing
table…

Hmm, that’s not good. We don’t

have one! There’s a simple
reason, though - on L3
switches, we need to enable IP
routing, because it’s off by
default!

Step One In L3
Switching
Troubleshooting: Make
Sure IP Routing Is On!

Now that looks like the routing
table we’ve come to know and

love! In this particular case,
there’s no need to configuring a
routing protocol.
Why? You recall from your
CCNA studies that when routeron-a-stick is configured, the IP
address assigned to the router’s
subinterfaces should be the
default gateway setting on the
hosts.
When SVIs are in use, the
default gateway set on the
hosts should be the IP address
assigned to the SVI that
represents that host’s VLAN.

After setting this default
gateway on the hosts, the
hosts can now successfully
communicate.
Since we’re using routers for
hosts, we’ll use the ip route
command to set the default
gateway.

Can the hosts now
communicate, even though
they’re in different VLANs?

Routed Ports
We also have the option of
configuring a physical port on a
multilayer switch as a routed
port. A few things to note about
these ports:
You assign an IP address to a
routed port in the same manner
in which you would apply one

to an SVI or to a port on a
Cisco router.
There are some big differences
between SVIs and routed ports,
though - for one, routed ports
are physical L3 switch ports, as
opposed to SVIs, which are
logical.
Another difference - routed
ports don’t represent a
particular VLAN as does as SVI.
You configure a routed port
with a routing protocol such as
OSPF or EIGRP in the exact

same manner as you would on
a router. That goes for protocolspecific commands as well as
interface-specific.
If we add a router to our
network as shown below, that’s
what we’ll need to do.

For many Cisco L3 switches, the
ports will all be running in L2
mode by default. To configure a
port as a routed port, use the
no switchport command,
followed by the appropriate IP
address. Note that in the
following configuration, the line
protocol on the switch port
goes down and comes back up
in just a few seconds.

We verify the IP address
assignment with show int fast

0/5.

The switch can now ping
210.1.1.1, the downstream
router.

Now let’s take this just one step
further - what if we wanted the
hosts in the VLANs to be able
to communicate with the
router? They can ping
210.1.1.11, the switch’s

interface in that subnet, but not
210.1.1.1, the router’s
interface.

The router has no path to
either 20.1.1.0 /24 or
30.1.1.0/24, so there’s no way
for the pings to get back to
Host 1 or Host 3.

To remedy that, we’ll now

configure a dynamic routing
protocol between the L3 switch
and the router. We’ll use EIGRP
in this case.

The router now has the VLAN
subnets in its routing table…

… and the hosts now have twoway IP connectivity with the
router’s 210.1.1.1 interface.

It never hurts to make sure the
pings can go the other way,
too!

At first, the details of SVIs and
routed ports might make you
pine for the good ol’ days of
ROAS!
Once you get a little experience
and study in, though, you’ll find
that SVIs and routed ports
really are much more effective
ways of getting the job done on
your network - and on your
exam!
Here’s a quick SVI checklist:

Create the VLAN before the
SVI. The VLAN must be active
when the SVI is created - that
VLAN will not be dynamically
created at that time.
Theoretically, you need to open
the SVI with no shutdown just
as you would open a physical
interface after configuring an IP
address
The SVI and VLAN have an
association, but they’re not the
same thing, and yes, I know
you know that by now. Just a
friendly reminder - creating one

does not dynamically create the
other.
The IP address assigned to the
SVI should be the default
gateway address configured on
the VLAN’s hosts.
The only SVI on the switch by
default is the SVI for VLAN 1,
intended to allow remote
switch administration and
configuration. (Having to drive
in at 3 AM because there’s no
IP address on this interface
really stinks.)

SVIs are a great way to allow
interVLAN communication, but
you must have a routing
protocol configured in addition
to the SVIs. (Tshooting note - if
this inter-VLAN communication
fails, check your SVI addresses
and make sure you have IP
routing enabled on the switch.
More SVI tshooting notes later
in this section.)
You need to create the
VLAN before the SVI,
and that VLAN must be
active at the time of
SVI creation

Theoretically, you need
to open the SVI with no
shut just as you would
open a physical
interface after
configuring an IP
address
Remember that the
VLAN and SVI work
together, but they’re
not the same thing.
Creating a VLAN doesn’t
create an SVI, and
creating an SVI doesn’t
create a VLAN.

Fallback Bridging
Odds are that you’ll never need
to configure fallback bridging,
but it falls under the category
of “it couldn’t hurt to know it”.
CEF has a limitation in that IPX,
SNA, LAT, and AppleTalk are
either not supported by CEF or,
in the case of SNA and LAT, are
nonroutable protocols. If you’re
running any of these on an CEFenabled switch, you’ll need
fallback bridging to get this
traffic from one VLAN to
another.

Fallback bridging involves the
creation of bridge groups, and
the SVIs will have to be added
to these bridge groups.
To create a bridge group:
MLS(config)# bridge-group 1
To join a SVI to a bridge group:
MLS(config)#interface vlan 10
MLS(config-if)#bridge-group 1

Router-On-A-Stick vs.
Switched Virtual

Interfaces
Those of you who earned your
CCNA working with me know
that I love configuring routeron-a-stick, and that they’re also
quite effective and quite stable.
So what’s the big deal about
SVIs?
As much as I like ’em, ROAS
configs do have a few
drawbacks:
Not the most intuitive config in
the world. I know that when

you look at a completed ROAS
config, you’ll wonder how you
could make a mistake with it but I’ll put it this way: In my
CCNA ROAS material, the
troubleshooting section is
larger than the configuration
section.
We’re sending a lot of traffic up
and down a single trunk line
from the L2 switch to the
router.
And the phrase “single trunk
line” brings to mind another
phrase that we really hate -

“single point of failure”. If the
port on either side of the trunk
goes out, or the cable itself
goes down, we’re SOL (Sure
Outof Luck).
Those drawbacks lead us to
SVIs, which have advantages
that neatly map to ROAS’s
deficiencies:
No single point of failure
Faster than ROAS
Don’t need to configure a trunk
between the L2 switch and the

router
Generally speaking, if you have
an L3 switch, you’re much
better off using SVIs for interVLAN communication rather
than ROAS.

SVI “Up And Up”
Checklist
We saw each of these in action
during the lab, and I want you
to have a quick t-shooting list
for your SVIs… so if you don’t
see your SVI interface and line

protocol up, check these points
first:
Make sure you created the
VLAN that the SVI represents.
You know how the switch
creates a VLAN dynamically if
you try to put a port into a
VLAN that doesn’t exist yet?
Well, the switch isn’t doing this
for you. Creating an SVI for
VLAN 11 does not dynamically
create VLAN 11 itself.
A valid port must be placed into
the VLAN we just talked about and by “valid”, I mean the port

is physically up and has been
placed into forwarding mode by
STP for that same VLAN.
Be sure you created the SVI
you meant to create. Everybody
mistypes a number once in a
while… say, “vlan 12” when you
meant “vlan 11”.

Routed Port Checklist
On the L3 switch itself, be sure
to enable ip routing.
On the port, be sure you’ve run
the no switchport command as

well as applying an IP address
and any protocol-specific
commands you need for your
particular config (the OSPF
commands neighbor or ip ospf
priority, for example).

An Etherchannel - SVI
Similarity
We’re not actually bundling
ports with SVIs as we do with
Etherchannels, but there is an
interesting similarity between
the two:

SVIs remain “up/up” as long as
the ports in the VLAN it
represents are up, even if
there’s only one.
Etherchannels remain “up/up”
as long as the ports in the
Portchannel are up, even if
there’s only one. (The available
bandwidth goes down, though.
And yes, I knew you know
that.)
So what?
So this: If you have a port in a
VLAN that’s not actually

handling data, but is doing
something else - like serving as
a SPAN destination port
connected to a network
monitor, for example - the SVI
would stay up even if all of the
other ports in the VLAN went
down, since this SPAN
destination port would stay up.
Having an SVI stay up in that
situation isn’t good - we can
end up having a black hole in
our routing process. Here’s
Wikipedia’s definition of a black
hole in space:

“According to the general
theory of relativity, a black hole
is a region of space from which
nothing, not even light, can
escape. It is the result of the
deformation of spacetime
caused by a very compact
mass.”
A black hole in routing is the
result of an SVI remaining up
when there are actually no
“up/up” interfaces in that VLAN
except for those connected to
network monitors or similar
devices.

To avoid this, we can exclude
such ports from the “up/up”
calculation with the switchport
autostate exclude command.
Using that interface-level
command on ports like the one
previous described will exclude
(get it?) that port from the
“up/up” determination.

Router Redundancy
Techniques
In networking, we’ll take as
much redundancy as we can
get. If a router goes down,

we’ve obviously got real
problems. Hosts are relying on
that router as a gateway to
send packets to remote
networks. For true network
redundancy, we need two
things:
A secondary router to
handle the load when
the primary goes down
A protocol to get the
networks using that
secondary router as
quickly as possible
Time is definitely of the

essence here, in more ways
than one - we need a protocol
to quickly detect the fact that
the primary router’s down in
the first place, and then we
need a fast cutover to the
secondary router.
Now you may be thinking, “Why
is Chris talking about router
redundancy in a switching
course?”
With the popularity of L3
switches, you’ll often be
configuring these protocols on
multilayer switches - so often

that Cisco now tests your
knowledge of these protocols
on the CCNP Switch exam
rather than Route.
Running router redundancy
protocols on your multilayer
switches actually makes the
cutover to a backup device a
little faster than configuring
them on routers, since our end
users are generally attached to
the L3 switches themselves,
making this truly first-hop
redundancy (or “1-hop
redundancy” in some
documentation).

With the importance of these
protocols in today’s networks,
we better be ready for exam
questions and real-world
situations.
We have several different
methods that allow us to
achieve the goal of redundancy,
and a very popular choice is
HSRP - the Hot Standby
Routing Protocol.
Please note: In the following
section, I’m going to refer to
routers rather than L3 switches,
since the HSRP terminology

itself refers to “Active routers”,
“Standby routers”, and so forth.
The commands and theory for
all of the following protocols
will be the same on a
multilayer switch as they are on
a router.

Hot Standby Routing
Protocol
Defined in RFC 2281, HSRP is a
Cisco-proprietary protocol in
which routers are put into an
HSRP router group. Along with
dynamic routing protocols and

STP, HSRP is considered a highavailability network service,
since all three have an almost
immediate cutover to a
secondary path when the
primary path is unavailable.
One of the routers in the HSRP
router group will be selected as
the Active Router, and that
router will handle the routing
while the other routers are in
standby, ready to handle the
load if the primary router
becomes unavailable.
In this fashion, HSRP ensures a

high network uptime, since it
routes IP traffic without relying
on a single router.
The terms “active” and
“standby” do not refer to the
actual operational status of the
routers - just to their status in
the HSRP group.
The hosts using HSRP as a
gateway don’t know the actual
IP or MAC addresses of the
routers in the group. They’re
communicating with a
pseudorouter, a “virtual router”
created by the HSRP

configuration. This virtual
router will have a virtual MAC
and IP address as well, just like
a physical router.
The standby routers aren’t just
going to be sitting there,
though! By configuring multiple
HSRP groups on a single
interface, HSRP load balancing
can be achieved.
Before we get to the more
advanced HSRP configuration,
we better get a basic one
started! We’ll be using a tworouter topology here, and keep

in mind that one or both of
these routers could be
multilayer switches as well. For
ease of reading, I’m going to
refer to them only as routers.

R2 and R3 will both be
configured to be in standby
group 5. The virtual router will
have an IP address of
172.12.23.10 /24. All hosts in
VLAN 100 should use this
address as their default
gateway.

The show command for HSRP is
show standby, and it’s the first
command you should run while
verifying and troubleshooting

HSRP. Let’s run it on both
routers and compare results.

R3 is in Active state, while R2 is
in Standby. The hosts are using
the 172.12.123.10 address as
their gateway, but R3 is

actually handling the workload.
R2 will take over if R3 becomes
unavailable.
An IP address was assigned to
the virtual router, but not a
MAC address. However, there is
a MAC address under the show
standby output on R3, the
active router. How did the HSRP
process arrive at a MAC of 0000- 0c-07-ac-05?
Well, most of the work is
already done before the
configuration is even begun.
The MAC address 00-00-0c-07-

ac-xx is HSRP’s well-known
virtual MAC address, and xx is
the group number in
hexadecimal. That’s a good skill
to have for the exam, so make
sure you’re comfortable with
hex conversions.
In this example, the group
number is 5, which is expressed
as 05 with a two-bit hex
character. If the group number
had been 17, we’d see 11 at
the end of the MAC address one unit of 16, one unit of 1.
The output of the show standby

command also tells us that the
HSRP speakers are sending
Hellos every 3 seconds, with a
10-second holdtime. These
values can be changed with the
standby command, but HSRP
speakers in the same group
should have the same timers.
You can even tie down the
hello time to the millisecond,
but it’s doubtful you’ll ever need
to do that.

A key value in the show
standby command is the
priority. The default is 100, as
shown in both of the above
show standby outputs. The
router with the highest priority
will be the primary HSRP router,
the Active Router.
The router with the highest IP
address on an HSRP-enabled
interface becomes the Active
Router if there is a tie on
priority.
We’ll raise the default priority
on R2 and see the results.

R2 now has a higher priority,
but R3 is still the Active Router.
R2 will not take over as the
HSRP primary until R3 goes
down - OR the preempt option
is configured on R2 with the
standby command. In effect,
the preempt option resets the
HSRP process for that group.

In just a few seconds, a
message appears that the local
state has changed from
standby to active. Show
standby confirms that R2, the
local router, is now the Active
Router - the primary. R3 is now
the standby. So if anyone tells
you that you have to take a
router down to change the
Active router, they’re wrong you just have to use the

preempt option on the standby
priority command.
What you do not have to do is
configure the preempt
command if you want the
standby to take over as the
Active Router if the current
Active Router goes down.
That’s the default behavior of
HSRP. The preempt
command is strictly intended to
allow a router to take over as
the active router without the
current active router going
down.

On rare occasions, you may
have to change the MAC
address assigned to the virtual
router. This is done with the
standby mac-address
command. Just make sure
you’re not duplicating a MAC
address that’s already on your
network!

The MAC address will take a

few seconds to change, and the
HSRP routers will go into Learn
state for that time period.
A real-world HSRP
troubleshooting note: If you
see constant state changes
with your HSRP configuration,
do what you should always do
when troubleshooting - check
the physical layer first.
We can do some load balancing
with HSRP, but it’s not quite the
load balancing you’ve learned
about with some dynamic
protocols. Let’s say we have six

hosts and two separate HSRP
devices. For HSRP load
balancing, there will be two
HSRP groups created for the
one VLAN.
R2 will be the primary for Group
1 and R3 will be the primary for
Group 2. (In production
networks, you’ll need to check
the documentation for your
software, because not all
hardware platforms support
multiple groups.)
R2 is the Active for Group 1,
which has a Virtual IP address

of 172.12.23.11 /24. R3 is the
Active for Group 2, which has a
Virtual IP address of
172.12.23.12 /24. The key to
load balancing with HSRP is to
configure half of the hosts to
use .11 as their gateway, and
the remaining hosts should use
.12.

This is not 50/50 load
balancing, and if the hosts
using .11 as their gateway are
sending much more traffic than
the hosts using .12, HSRP has
no dynamic method of

adapting. HSRP was really
designed for redundancy, not
load balancing, but there’s no
use in letting the standby
router just sit there!
Some other HSRP notes:
HSRP updates can be
authenticated by using
the standby command
with the authentication
option.

If you’re configuring
HSRP on a multilayer
switch, you can
configure HSRP on
routed ports, SVIs, and
L3 Etherchannels.
HSRP requires the
Enhanced Multilayer
Software Image (EMI)
to run on an L3 switch.
Gig Ethernet switches
will have that image,
but Fast Ethernet
switches will have
either the EMI or
Standard Multilayer
Image (SMI). Check

your documentation.
The SMI can be
upgraded to the EMI.
(Hint: It’ll cost ya.)
HSRP can run on
Ethernet, Token Ring,
and FDDI LANs. Some
HSRP documentation
states that Token Ring
interfaces can support a
maximum of three
HSRP groups.
You saw several HSRP states in
this example, but not all of
them. Here they are, presented
in order and with a quick

description.
Disabled - Some HSRP
documentation lists this as a
state, others do not.
I don’t consider it one, but
Cisco may. Disabled means that
the interface isn’t running HSRP
yet.
Initial (Init) -- The router goes
into this state when an HSRPenabled interface first comes
up. HSRP is not yet running on
a router in Initial state.

Learn -- At this point, the router
has a lot to learn! A router in
this state has not yet heard
from the active router, does not
yet know which router is the
active router, and it doesn’t
know the IP address of that
router, either. Other than that,
it’s pretty bright. ;)
Listen -- The router now knows
the virtual IP address, but is
not the primary or the standby
router. It’s listening for hello
packets from those routers.
Speak -- The router is now

sending Hello messages and is
active in the election of the
primary and standby routers.
Standby -- The router is now a
candidate to become the active
router, and sends Hello
messages.
Active -- The router is now
forwarding packets sent to the
group’s virtual IP address.
Note that an HSRP router
doesn’t send Hellos until it
reaches the Speak state. It will
continue to send Hellos in the

Standby and Active states as
well.
There’s also no problem with
configuring an interface to
participate in multiple HSRP
groups on most Cisco routers.
Some 2500, 3000, and 4000
routers do not have this
capability. Always verify with
show standby, and note that
this command indicates that
there’s a problem with one of
the virtual IP addresses!

HSRP Interface
Tracking
Using interface tracking can be
a little tricky at first, but it’s a
feature that can really come in
handy. Basically, this feature
enables the HSRP process to

monitor an additional interface;
the status of this interface will
dynamically change the HSRP
priority for a specified group.
When that interface’s line
protocol shows as “down”, the
HSRP priority of the router is
reduced. This can lead to
another HSRP router on the
network becoming the active
router - but that other router
must be configured with the
preempt option.
In the following network, R2 is
the primary due to its priority of

105. R3 has the default priority
of 100. R2 will therefore be
handling all the traffic sent to
the virtual router’s IP address of
172.12.23.10. That’s fine, but
there is a potential single point
of failure.
If R2’s Serial0 interface fails,
the hosts will be unable to
reach the server farm. HSRP
can be configured to drop R2’s
priority if the line protocol of
R2’s Serial0 interface goes
down, making R3 the primary
router. (The default decrement
in the priority when the tracked

interface goes down is 10.)

The show standby output on R2

shows the tracked interface,
the default decrement of 10,
and that the line protocol of the
tracked interface is currently
up. We’ll test the configuration
by shutting the interface down
manually.

Not only does the HSRP

tracking work to perfection - R2
is now the standby and R3 the
primary - but the show standby
command even shows us that
the line protocol is
administratively down, rather
than just “down”. Running show
standby on R3 verifies that R3
now sees itself as the Active
router.

We’ll now reopen the Serial0

interface on R2. Since we also
put the preempt option on that
router’s HSRP configuration, R2
should take over as the Active
router.

Just that quickly, R2 is again
the Active router. If you’re
running HSRP interface

tracking, it’s a very good idea
to configure the preempt option
on all routers in the HSRP
group.
The #1 problem with an HSRP
Interface Tracking configuration
that is not working properly is a
priority / decrement value
problem.
As I mentioned earlier, the
default decrement is 10, and
that’s fine with the example we
just worked through. If R2 had
a priority of 120, the decrement
of 10 would not be enough to

make R3 the Active router.
You can change the default
decrement at the end of the
standby interface command.
The following configuration
would result in a priority value
decrement of 25 when the
tracked interface goes down.

That does not change the
decrement value for all

interfaces - just the one we’re
tracking with that particular
statement, serial0. If we
configure a second interface for
tracking and do not supply a
decrement value, that interface
will have a decrement value of
10.
I’ve configured interface
tracking for S1 and verified with
show standby - here’s the
pertinent information:

Note that this interface’s

priority is now 65! It’s using the
HSRP priority default of 100,
then has 25 decremented from
that because serial0 is down,
and then another 10
decremented because serial1 is
down.

Troubleshooting HSRP
We’ve discussed several
troubleshooting steps
throughout the HSRP section,
but the show standby command
can indicate other HSRP issues
as well. I’ve deliberately

misconfigured HSRP on this
router to illustrate a few.

We’ve got all sorts of problems
here! In the Group 5 readout,
we see a message that the

subnet is incorrect; naturally,
both the active and standby
routers are going to be
unknown.
In the Group 1 readout, the
Active router is local but the
Standby is unknown. This is
most likely a misconfiguration
on our part as well, but along
with checking the HSRP config,
always remember “Troubleshooting starts at the
Physical layer!”
One Physical layer issue with
HSRP I’ve run into in both

practice labs and production
networks is an unusual number
of state transitions. You can
spot this and most other HSRP
issues with debug standby.

This is an extremely verbose

command, and a very helpful
one. If you have the
opportunity to run HSRP in a
lab environment, run this one
often during your configuration
to see the different states and
values being passed around the
network. (Never practice
debugs at work or in any
production environment.)
If you see HSRP states
regularly transitioning,
particularly between Speak and
Standby, check your cabling you’d be surprised how often
that happens, especially in

labs.
Frankly, most HSRP issues you
run into fall into these
categories:
The secondary router didn’t
become the Active router when
it should have.
The former Active router didn’t
take back over when it came
back online.
If either of those happens to
you, check these values:
Is the preempt command

properly configured? (I put this
first in the list for a reason.)
What are the priority values of
each HSRP speaker?
Watch your decrement values
with HSRP interface tracking.
Don’t get cute with these. If
you’re having a problem with
interface tracking and you see
decrements that don’t end in 0
or 5, I can practically guarantee
they’re misconfigured.
(I don’t know exactly why, but
this happens fairly often,

especially in lab environments
when you get tired of using
decrements that don’t end in 5
or 0.)
Whew! That’s a lot of detail and only one of our redundancy
choices.
Great news, though - many of
the HSRP concepts you’re
currently mastering are the
same or similar to what we’re
doing with VRRP - the Virtual
Router Redundancy Protocol.

Virtual Router
Redundancy Protocol.
Defined in RFC 2338, VRRP is
the open-standard equivalent
of the Cisco- proprietary HSRP.
VRRP works very much like
HSRP, and is suited to a
multivendor environment. The
operation of the two is so
similar that you basically
learned VRRP while going
through the HSRP section!
There are some differences, a
few of which are:
VRRP’s equivalent to

HSRP’s Active router is
the Master router.
(Some VRRP
documentation refers to
this router as the IP
Address Owner.) This is
the router that has the
virtual router’s IP
address as a real IP
address on the
interface it will receive
packets on.
The physical routers in
a VRRP Group combine
to form a Virtual Router.
Note that the VRRP
Virtual Router uses an

IP address already
configured on a router
in its group, as opposed
to how the HSRP router
is assigned a separate
IP address.
VRRP Advertisements
are multicast to
224.0.0.18.
VRRP’s equivalent to
HSRP’s Standby router
state is the Backup
state.
The MAC address of
VRRP virtual routers is
00-00-5e-00-01-xx, and
you guessed it - the xx

is the group number in
hexadecimal.
“preempt” is a default
setting for VRRP
routers.
As of IOS Version
12.3(2)T, VRRP now has
an Object Tracking
feature. Similar to
HSRP’s Interface
Tracking feature, a WAN
interface can be tracked
and a router’s VRRP
priority dropped when
that interface goes
down.

Gateway Load Balancing
Protocol (GLBP)
HSRP and its open-standard
relation VRRP have some great
features, but accurate load
balancing is not among them.
While both allow a form of load
sharing, it’s not truly load
balancing. The primary purpose
of the Gateway Load Balancing
Protocol (GLPB) is just that load balancing! It’s also
suitable for use only on Cisco
routers, because GLBP is Ciscoproprietary.

As with HSRP and VRRP, GLBP
routers will be placed into a
router
group. However, GLBP allows
every router in the group to
handle some of the load in a
round-robin format, rather than
having a primary router handle
all of it while the standby
routers remain idle. With GLBP,
the hosts think they’re sending
all of their data to a single
gateway, but actually multiple
gateways are in use at one
time.

That’s a major benefit of GLBP
over HSRP and VRRP, since the
latter two aren’t really built for
load balancing. They don’t
perform any balancing by
default, and configuring it is
both an inexact science and a
pain in the behind.
GLBP also allows standard
configuration of the hosts, who
will all have their gateway
address set to the virtual
router’s address - none of this
“some hosts point to gateway
A, some hosts point to gateway
B” business we had with HSRP

load balancing.
The key to GLBP is that when a
host sends an ARP request for
the MAC of the virtual router,
one of the physical routers will
answer with its own MAC
address. The host will then
have the IP address of the
GLBP virtual router and the
MAC address of a physical
router in the group.
In the following illustrations,
the three hosts send an ARP
request for the MAC of the
virtual router.

The Active Virtual Gateway
(AVG) will be the router with
the highest GLBP priority, and
this router will send back ARP

responses containing different
virtual MAC addresses.
The three hosts will have the
same Layer 3 address for their
gateway, but a different L2
address, accomplishing the
desired load balancing while
allowing standard configuration
on the hosts. (If the routers all
have the same GLBP priority,
the router with the highest IP
address will become the AVG.)
In the following illustration, R3
is the AVG and has assigned a
virtual MAC of 22-22-22-22-22-

22 to R2, 33-33-33-33-33-33 to
itself, and 44-44-44-4444-44 to
R4. The routers receiving and
forwarding traffic received on
this virtual MAC address are
Active Virtual Forwarders
(AVFs).

If the AVG fails, the router
serving as the standby AVG will
take over. If any of the AVFs
fails, another router will handle
the load destined for a MAC on

the downed router. GLBP
routers use Hellos to detect
whether other routers in their
group are available or not.
GLBP groups can have up to
four members.
GLBP’s load balancing also
offers the opportunity to finetune it to your network’s needs.
GLBP offers three different
forms of MAC address
assignment, the default being
round-robin. With round-robin
assignments, a host that sends
an ARP request will receive a

response containing the next
virtual MAC address in line.
If a host or hosts need the
same MAC gateway address
every time it sends an ARP
request, host-dependent load
balancing is the way to go.
Weighted MAC assignments
affect the percentage of traffic
that will be sent to a given AVF.
The higher the assigned
weight, the more often that
particular router’s virtual MAC
will be sent to a requesting
host.

GLBP is enabled just as VRRP
and HSRP are - by assigning an
IP address to the virtual router.
The following command will
assign the address 172.1.1.10
to GLBP group 5.

To change the interface priority,
use the glbp priority command.
To allow the local router to
preempt the current AVG, use
the glbp preempt command.

GLBP Weighting
A router can be configured to
give up its role as the AVF if its
overall weight drops below a
configured value. The default
weight of a GLBP AVF is 100.
The router is configured with
upper and lower weight
thresholds, and should the
router’s weight fall below its
lower threshold, it gives up the
role of AVF.
When the router’s GLBP weight
exceeds the higher threshold, it
resumes the role of GLBP AVF.

Before configuring the GLBPspecific commands, we
configure track statements to
number and name the
interfaces being tracked. IOS
Help shows us our options:

The choices at the end, ip and
line-protocol, determine what is
being tracked. The line-protocol
option does just what you think

it would - it tracks the line
protocol to see whether it’s up
or not.
The ip option is followed only
by routing, as shown in the
next track statement.

After taking a look at our
options with IOS Help, I’ll
configure a GLBP weight of 105
on the fast 0/0 interface, a
lower threshold of 90, and an

upper threshold of 100. I’ll set a
decrement of 10 for both
tracking statements created
earlier.

Server Load Balancing
We’ve talked at length about
how Cisco routers and
multilayer switches can work to

provide router redundancy - but
there’s another helpful service,
Server Load Balancing, that
does the same for servers.
While HSRP, VRRP, and CLBP all
represent multiple physical
routers to hosts as a single
virtual router, SLB represents
multiple physical servers to
hosts as a single virtual server.
In the following illustration,
three physical servers have
been placed into the SRB group
ServFarm. They’re represented
to the hosts as the virtual
server 210.1.1.14.

The hosts will seek to
communicate with the server at
210.1.1.14, not knowing that
they’re actually communicating

with the routers in ServFarm.
This allows quick cutover if one
of the physical servers goes
down, and also serves to hide
the actual IP addresses of the
servers in ServFarm.
The basic operations of SLB
involves creating the server
farm, followed by creating the
virtual server. We’ll first add
210.1.1.11 to the server farm:

The first command creates the
server farm, with the real
command specifying the IP
address of the real server. The
inservice command is required
by SLB to consider the server
as ready to handle the server
farm’s workload. The real and
inservice commands should be
repeated for each server in the
server farm.
To create the virtual server:

From the top down, the vserver
was named VIRTUAL_SERVER,
which represents the server
farm ServFarm. The virtual
server is assigned the IP
address 210.1.1.14, and
connections are allowed once
the inservice command is
applied.
You may also want to control
which of your network hosts

can connect to the virtual
server. If hosts or subnets are
named with the client
command, those will be the
only clients that can connect to
the virtual server. Note that this
command uses wildcard masks.
The following configuration
would allow only the hosts on
the subnet 210.1.1.0 /24 to
connect to the virtual server.

Network Monitoring
Tools

Actively monitoring your
network is another part of a
high-availability design -- and
the following tools and
protocols play an important role
in that monitoring.
SNMP
The Simple Network
Management Protocol is used
to carry network management
information between network
devices, and you’re going to
find it in just about any network
that uses anyone’s network
management tools --

particularly Cisco’s.
An SNMP deployment basically
consists of three parts:
A monitoring device, the SNMP
Manager
The SNMP instance running on
the monitored devices, officially
called the SNMP Agents
A database containing all of
this info, the Management
Information
Bases(MIB)

The Manager will question the
Agents at a configurable
interval, basically asking if
there are any problems the
Manager needs to know about
(“polling”).

This is a proactive approach
(sorry for the buzzword), but
the only way to get nearimmediate notification of
critical events through polling

alone is to poll the Agents quite
often - and that can be a big
use of bandwidth along with
increasing the hit on the
managed device’s CPU.
To work around those issues,
we can configure SNMP
managed devices to send traps
when certain events occur.

There are some serious security

considerations with SNMP and
the different versions available
to us.
There are three versions of
SNMP; v1, v2c, and v3. Version
3 has both authentication and
encryption capabilities, where
the earlier version do not. Use
version 3 whenever possible;
use of the other versions should
be restricted to allowing readonly access.
How do you do that? When you
configure SNMP community
strings - a kind of combination

of password and authority level
- you’ll have the option to
configure the string as readonly or read-write.

That command allows hosts
identified by access-list 15 to
have read-only access to all

SNMP objects specified by this
community string. Restrict
read-write access to your SNMP
objects as much as is practical
with your network and network
personnel.
To configure the location of the
SNMP server on the monitored
device so the local device
knows where to send the traps,
use this command:

Syslog

Syslog delivers messages about
network events in what a friend
once called “kinda readable
format”. These messages can
be really helpful in figuring out
what just happened in both
your home lab and production
network - you just have to
remain calm and read the
message.
That sounds flip, but I’ve seen
and heard plenty of network
admins panic because
something’s gone wrong in their
network, and they don’t know
what it is, and they totally miss

the Syslog message on their
screen. True, that message can
be hidden in a batch of other
output, but I bet it’s there - and
as we’ve seen a few times in
this course, the message may
well spell out exactly what the
problem is.
While part of the Syslog
message will be in easily
understood text, part of it’s
going to have some numbers
and dashes in it. After we take
a look at the different severity
levels and some sample
configurations, we’ll “decipher”

the “kinda readable” part of a
Syslog message.

Logging To A Host
The basic command for sending
logging messages to a specific
host is straightforward, but I’ve
found the level command that
goes with it sometimes trips
Cisco network admins up. Let’s
take a look at the different
logging options with IOS Help.
The commands we’re focusing
on are at the very top and very
bottom of the IOS Help options.

Identifying the logging host is
easy enough - we just need to
follow logging with the
hostname or IP address of that
host. It’s the trap command you
have to watch, since that sets
the logging level itself.

Selecting a trap level means
that all log messages of the
severity you configure and all
those with a lower numeric
value are sent to the logging
server. If you want all log
messages to be sent, you don’t
have to enter every number just number 7, the debug level,
which is the highest numeric
level.
I’ve occasionally seen instances
where the desired log
messages were not being sent
to the server. The first thing
you should check is the logging

trap level. If you want debug
logs sent to the server, you
must specify that level.

You can use the actual name or
the level behind logging trap.
Just make sure to set the level
high enough to get the desired
results!
Let’s take a “kinda typical”
Syslog message that you’ve
seen quite often by this point in
your studies and examine it
closely.

About as commonplace as it
gets, right? Those are some
odd characters at the
beginning, though. The very
beginning of that is the
timestamp, which you can set
to different formats with the
service timestamps command.
Right now it’s set to uptime,
showing that this router’s been
up for five days and five hours.
I prefer the datetime option,
which I’ll show you here along
with the syntax of the
command via IOS Help:

Note the immediate change of
the timestamp format.
The “SYS” in that message is
the facility; “SYS” indicates a
System message. When you’re
configuring routing protocols,
you’ll see messages with
“OSPF”, “EIGRP”, or “RIP” there.
The “5” is the severity, which in
this case is the “Notifications”

level. That’s followed by the
mnemonic (“CONFIG_I”, for
Config Interface in this case)
and the message-text, which is
the final part of the Syslog
message.

Cisco SLA
In your Frame Relay studies,
you were introduced to the
Committed Information Rate
(CIR). The CIR is basically a
guarantee given to the
customer by the Frame Relay
service provider where the

provider says..
“For X dollars, we guarantee
you’ll get “Y” amount of
bandwidth. You may get more,
but we guarantee you won’t get
less.”
Given that guarantee of
minimum performance, the
customer can then plan the
WAN appropriately.
The SLA is much the same, only
this agreement (the Service
Level Agreement, to be
precise) can be between

different groups..
..it can be much like the CIR,
where a service provider
guarantees a certain level of
overall network uptime and
performance…
… or it can be between the
internal clients of a company
and the network team at the
same company.
The SLA can involve bandwidth
minimums, but it can involved
just about any quality-related
value in your network, including

acceptable levels of jitter in
voice networks. From Cisco’s
“IOS IP Service Level
Agreements” website:
“With Cisco IOS IP SLAs, users
can verify service guarantees,
increase network reliability by
validating network
performance, proactively
identify network issues, and
increase Return on Investment
(ROI) by easing the
deployment of new IP services.”
“Cisco IOS IP SLAs use active
monitoring to generate traffic in

a continuous, reliable, and
predictable manner, thus
enabling the measurement of
network performance and
health.”
Now that’s quite an agreement.
According to the same site, a
typical SLA contains the
following assurances:
Network availability percentage
Network performance (often
measured by round-trip delay)
Latency, jitter, packet loss, DNS

lookup time
Trouble notification response
time
Resolution time
Reimbursement schedule when
above assurances are not met
Cisco IOS IP SLA usage
includes:
Performance visibility SLA
monitoring
IP service network health
readiness

Edge-to-edge network
availability monitoring
Business-critical app
performance monitoring
Network operation
troubleshooting
There are two parties involved
in the overall SLA process, the
self- explanatory Source and
Responder. Once we configure
SLA, the source kicks off the
process…
Control packets are sent to the

Responder on UDP port 1967 in
an attempt to create a control
connection similar to that of
FTP - it’s basically an
agreement on the rules of
communication. In this case,
the rules sent to the Responder
are the protocol and port
number it should listen for and
a time value indication how
long it should listen.
If the Responder agrees to the
rules, it will send a message
back to the Source indicating its
agreement, and will then start
listening! (If the Responder

doesn’t agree, it will indicate
that as well, and our story ends
here.)
We now go from controlling to
probing, as the Source sends
some test packets to the
Responder. What’s the Source
testing? The approximate
length of time it take the
Responder to - you guessed it respond!
The Responder adds
timestamps both as the packets
are accepted and returned to
the Sender. This gives the

Sender a better idea of the
overall time it took the
Responder to process the
packets.
Some notes regarding the time
measurements going on here…
It bears repeating that the
Responder places two
timestamps on the returned
packets - one indicating when
the packet arrived and another
indicating when it left. This
allows the Sender to determine
how long it took the Responder
to process the packets.

This dual timestamping allows
the Sender to determine if
there were any delays either as
the packet went from Sender to
Receiver or vice versa. (Similar
to our old friends BECN and
FECN from Frame Relay.)
All of this time measurement
and timestamping only works if
the involved devices have the
same time set - and that’s what
NTP is all about. The Network
Time Protocol is not a part of
your CCNP SWITCH exam
studies, but it is important to
know for working in real- world

networks. I have an idea it
might show up on other exams,
too!
There’s some excellent
information on Cisco’s SLA
white paper site:
http://bit.ly/ahY5dh
Configuring SLA can be a bit
tricky - I’ve seen the IOS
commands vary more than
usual between IOS version.
While the basic process is the
same..
Config the probe and send it

Config the object to be probed
… the commands to get you
there vary. Here’s a Cisco PDF
on the subject:

http://www.cisco.com/en/US/doc
I certainly wouldn’t memorize
every single step, but knowing
the basic commands (“ip sla
monitor” and “show ip sla
statistics”, for example)
certainly couldn’t hurt.

Configuring A Cisco
Multilayer Switch As A

DHCP Server
As a CCNA and future CCNP,
you’re familiar with the basic
purpose of DHCP and the basic
process a host goes through in
order to get an IP address from
a DHCP server… but let’s review
it anyway!
The initial step has the DHCP
client sending a broadcast
packet, a DHCPDiscover
packet, that allows the host to
discover where the DHCP
servers are.

The DHCP servers that receive
that DHCPDiscover packet will
respond with a DHCPOffer
packet. This packet contains an
IP address, the time the host
can keep the address (the
“lease”), a default gateway,
and other information as
configured by the DHCP server
admin.
If the host receives DHCPOffer
packets from multiple DHCP
servers, the first DHCPOffer
packet received is the one
accepted. The host accepts this
offer with a DHCPRequest

packet, which is also a
broadcast packet.
The DHCP server whose offered
IP address is being accepted
sends a unicast DHCPAck (for
“acknowledgement”) back to
the host.
Note that two broadcast
packets are involved in the
DHCP address assignment
process. You remember from
your CCNA studies that there is
a certain circumstance where
broadcasts may not reach their
intended destination. I’ll remind

you what that is and show you
how we’re going to get around
it later in this section.
The commands to configure a
Cisco router and a multilayer
switch as a DHCP server are
the same. There’s one “gotcha”
involving using an L3 switch as
a DHCP Server that I’ll point
out as we dive into the config.
Careful planning is the first step
to success when working with
Cisco routers, and that’s
particularly true of a DHCP
deployment. We may have a

situation where we want to
exclude a certain range of
addresses from the DHCP pool,
and oddly enough, we need to
do that in global configuration
mode.
Actually, let me point out that
“gotcha” right here - when you
use an L3 switch as a DHCP
Server, the switch must have an
IP address from any subnet
that it’s offering addresses
from.
Let’s say we are going to assign
addresses to DHCP clients from

the 11.0.0.0 /8 range, but we
don’t want to assign the
addresses 11.1.1.1 - 11.
1.1.255. We need to use the ip
dhcp excluded-address
command to do that, and
again, that’s a global command.
(I mention that twice because
that drives everyone crazy - it’s
very easy to forget!)

Note that there are no masks

used in this command - just the
numerically lowest and highest
IP addresses in the excluded
range.
Finally, we’re ready to create
the DHCP pool! We enter DHCP
config mode with the ip dhcp
pool command, followed by the
name we want the pool to
have.

The range of addresses to be

assigned to the clients is
defined with the network
command. Note that for the
mask, we’re given the option of
entering the value in either
prefix notation or the more
familiar dotted decimal.

We can specify a domain name
with the domain-name
command, and give the clients
the location of DNS servers
with the dns-server command.

The DNS servers can be
referred to by either their
hostname or IP address.

To specify a default router for
the clients, use the defaultrouter command.

Not only can you specify the

length of the DHCP address
lease, you can be really specific
about that value - down to the
minute! The lease can also be
made indefinite with the infinite
option.

At the beginning of this section,
I mentioned that a Cisco router
acting as a DHCP server will
check for IP address conflicts

before assigning an IP address.
This check consists of the
router sending two ping
packets to an IP address before
assigning that address; those
pings will time out in 500
milliseconds.
If the ping times out, the
address will be assigned. If an
echo returns, obviously that
address should not and will not
be assigned!
If you want to change either
the number of pings sent or the
ping timeout value during this

process, use the ip dhcp ping
packets and ip dhcp ping
timeout commands. Note that
these are global commands as
well. You can also disable this
pinging by entering zero for the
ping packets value.

Finally, if you need to disable
the DHCP service on this router,

run the no service dhcp
command. It can be reenabled
at any time with the service
dhcp command. (DHCP
capabilities should be enabled
by default, but it never hurts to
make sure.)
Now, about those broadcasts
….
IP Helper Addresses
While routers accept and
generate broadcasts, they do
not forward them. That can
present quite a problem with

DHCP requests when a router is
between the requesting host
and the DHCP server. The initial
step in the DHCP process has
the host generating a
DHCPDiscover packet - and
that packet is a broadcast.

If this PC attempts to locate a
DHCP server with a broadcast,
the broadcast will be stopped
by the router and will never get
to the DHCP server. By
configuring the ip helperaddress command on the
router, UDP broadcasts such as
this will be translated into a
unicast by the router, making
the communication possible.
The command should be
configured on the interface that
will be receiving the broadcasts
-- not the interface closest to
the destination device.

A Cisco router running the ip
helper-address command is
said to be acting as a DHCP
Relay Agent, but DHCP
messages are not the only
broadcasts being relayed to the
correct destination. Nine
common UDP service
broadcasts are “helped” by
default:
TIME, port 37
TACACS, port 49

DNS, port 53
BOOTP/DHCP Server,
port 67
BOOTP/DHCP Client,
port 68
TFTP, port 69
NetBIOS name service,
port 137
NetBIOS datagram
service, port 138
IEN-116 name service,
port 42
That’s going to cover most
scenarios where the ip helperaddress command will be
useful, but what about those

situations where the broadcast
you need forwarded is not on
this list? You can use the ip
forward-protocol command to
add any UDP port number to
the list.
To remove protocols from the
default list, use the no ip
forward-protocol command. In
the following example, we’ll
add the Network Time Protocol
port to the forwarding list while
removing the NetBIOS ports.
Remember, you can use IOS
Help to get a list of commonly
filtered ports!

The DHCP Relay Agent
And “Option 82’
In many cases, simply
configuring the appropriate ip
helper-address command on a
Cisco router is enough to get
the desired results when it
comes to DHCP. In some
networks, particularly larger
ones, you may find it necessary
for the DHCP Relay Agent - in
this case, the Cisco router - to
insert information about itself
in the DHCP packets being
forwarded to the server.

On Cisco routers, this is done
by enabling the Relay Agent
Information Option, also known
as Option 82. (No word on what
happened to the first 81
options.)
This is enabled with the ip dhcp
relay information option
command.

Free Videos From My YouTube
and Udemy Channels!

HSRP Video Practice Exam:

http://www.youtube.com/watch?
v=3qdVgErdMA4

My YouTube Channel:

http://www.youtube.com/user/cc

IP Telephony & Voice
VLANs
If you don’t have much (or any)
experience with Voice Over IP
(VoIP) yet, you’re okay for now
- you’ll be able to understand
this chapter with no problem. I
say “for now” because all of us
need to know some basic VoIP.
Voice and security are the two
fastest-growing sectors of our

business. They’re not going to
slow down anytime soon,
either. Once you’re done with
your CCNP, I urge you to look
into a Cisco voice certification.
There are plenty of good
vendor-independent VoIP books
on the market as well.
Most Cisco IP phones will have
three ports. One will be
connected to a Catalyst switch,
another to the phone ASIC, and
another will be an access port
that will connect to a PC.

As is always the case with voice
or video traffic, the key here is
getting the voice traffic to its
destination as quickly as
possible in order to avoid jitter
and unintelligible voice
streams. (“jitter” occurs when
there’s a delay in transmitting

voice or video traffic, perhaps
due to improper queueing.)
With Cisco IP Phones, there is
no special configuration needed
on the PC
- as far as the PC’s concerned,
it is attached directly to the
switch. The PC is unaware that
it’s actually connected to an IP
Phone.
The link between the switch
and the IP Phone can be
configured as a trunk or an
access link. Configuring this link

as a trunk gives us the
advantage of creating a voice
VLAN that will carry nothing but
voice traffic while allowing the
highest Quality of Service
possible, giving the delaysensitive voice traffic priority
over “regular” data handled by
the switch.
Configuring the link as an
access link results in voice and
data traffic being carried in the
same VLAN, which can lead to
delivery problems with the
voice traffic. The problem isn’t
that the voice traffic will not

get to the switch - it simply
may take too long. Voice traffic
is much more delay- sensitive
than data traffic.

The phrase “delay-sensitive” is
vague, so let’s consider this:
The human ear will only accept
140 - 150 milliseconds of delay
before it notices a problem with
voice delivery. That’s how long

we have to get the voice traffic
from source to destination
before the voice quality is
compromised.

Voice VLANs
When it comes to the link
between the switch and the IP
Phone, we’ve got four choices:
Configure the link as an
access link
Configure the link as a
trunk link and use
802.1p

Configure the link as a
trunk link and do not
tag voice traffic
Configure the link as a
trunk link and specify a
Voice VLAN
If we configure the link as an
access link, the voice and data
traffic is transmitted in the
same VLAN.
It’s recommended you make
the port a trunk whenever
possible. This will allow you to
create a Voice VLAN, which will
be separate from the regular

data VLAN on the same line.
The creation of Voice VLANs
also makes it much easier to
give the delay-sensitive voice
traffic priority over “regular”
data flows.
The command to create a voice
VLAN is a simple one - it’s the
choices that take a little getting
used to. The “PVID” shown in
these options is the Port VLAN
ID, which identifies the data
VLAN.

Let’s look at these options from
top to bottom.
The <1 - 4094> option creates
a voice VLAN and will create a
dotlq trunk between the switch
and the IP Phone. As with data
VLANs, if the Voice VLAN has
not been previously created,
the switch will create it for you.

The dot1p option has two
effects:
The IP Phone grants
voice traffic high

priority
Voice traffic is sent
through the default
voice native VLAN,
VLAN 0
Note the console message
when the dot1p option is
enabled:

The none option sets the port
back to the default.
Finally, the untagged option
results in voice packets being
put into the native VLAN.

As always, there are just a few
details you should be aware of
when configuring :
When Voice VLAN is
configured on a port,
Portfast is automatically
enabled -- but if you
remove the Voice VLAN,
Portfast is NOT
automatically disabled.
Cisco recommends that
QoS be enabled on the
switch and the switch
port connected to the

IP phone be set to trust
incoming CoS values.
The commands to
perform these tasks are
mis qos and the
interface-level
command mis qos trust
cos, respectively.
You can configure voice
VLANs on ports running
port security or 802.1X
authentication. It is
recommended that port
security be set to allow
more than one secure
MAC address.
CDP must be running

on the port leading to
the IP phone. CDP
should be globally
enabled on all switch
ports, but take a few
seconds to make sure
with show cdp neighbor.
Voice VLAN is supported
only on L2 access ports.
Particularly when
implementing video
conferencing, make
sure your total overall
traffic doesn’t exceed
75% of the overall
available bandwidth.
That includes video,

voice, and data! Cisco
also recommends that
voice and video
combined not exceed
33% of a link’s
bandwidth. This allows
for network control
traffic to flow through
the network and helps
to prevent jitter as well.
A voice VLAN’s dependency on
CDP can result in problems.
Believe it or not, there is such a
thing as CDP Spoofing, and that
can result in an issue with
anonymous access to Voice

VLANs. Basically, CDP Spoofing
allows the attacker to pretend
to be the IP Phone!
This issue is out of the scope of
the exam, but if you’ve got
voice VLANs in your network or
are even thinking about using
them, you should run a search
on “cdp spoofing voice vlan”
and start reading!

Voice And Switch QoS
I mentioned jitter earlier, but
we’ve got three main enemies

when it comes to successful
voice transmission:
jitter
delay
packet loss
To successfully combat these
problems, we have to make a
decision on what QoS scheme
to implement - and this is one
situation where making no
decision actually is making a
decision!
Best-effort delivery is the QoS
you have when you have no

explicit QoS configuration - the
packets are simply forwarded in
the order in which they came
into the router. Best-effort
works fine for UDP, but not for
voice traffic.
The Integrated Services Model,
or IntServ, is far superior to
best-effort. I grant you that’s a
poor excuse for a compliment!
IntServ uses the Resource
Reservation Protocol (RSVP) to
do its job, and that reservation
involves creating a high-priority
path in advance of the voice
traffic’s arrival.

The device that wants to
transmit the traffic does not do
so until a reserved path exists
from source to destination. The
creation of this path is
sometimes referred to as
Guaranteed Rate Service (GRS),
or simply Guaranteed Service.
The obvious issue with IntServ
is that it’s not a scalable
solution - as your network
handles more and more voice
traffic, you’re going to have
more and more reserved
bandwidth, which can in turn
“choke out” other traffic.

That issue is addressed with
the Differentiated Services
Model, or DiffServ. Where
IntServ reserves an entire path
in advance for the entire voice
packet flow to use, DiffServ
does not reserve bandwidth for
the flow; instead, DiffServ
makes its QoS decisions on a
per-router basis as the flow
traverses the network.
If DiffServ sounds like the best
choice, that’s because it is - and
it’s so popular that this is the
model we’ll spend the most
time with today.

(Besides, it’s pretty easy to
configure the best-effort model
- just don’t do anything!)

The DiffServ Model At
Layer Two
As mentioned earlier, DiffServ
takes a DifferentView (sorry,
couldn’t resist) of end-to-end
transmission than that taken by
IntServ. The DiffServ model
allows each network device
along the way to make a
separate decision on how best
to forward the packet toward

its intended destination, rather
than having all forwarding
decisions made in advance.
This process is Per- Hop
Behavior (PHB).

The core tasks of Diffserv QoS
are marking and classification.
(They are two separate

operations, but they work very
closely together, as you’ll see.)
Marking is the process of
tagging data with a value, and
classification is taking the
appropriate approach to
queueing and transmitting that
data according to that value.
It’s best practice to mark traffic
as close to the source as
possible to ensure the traffic
receives the proper QoS as it
travels across the network. This
generally means you’ll be
marking traffic at the Access
layer of the Cisco switching

model, since that’s where our
end users can be found.
At Layer 2, tagging occurs only
when frames are forwarded
from one switch to another. We
can’t tag frames that are being
forwarded by a single switch
from one port to another.

You know that the physical link
between two switches is a
trunk, and you know that the
VLAN ID is tagged on the frame
before it goes across the trunk.
You might not know that
another value - a Code of
Service (CoS) value - can also
be placed on that frame. Where
the VLAN ID indicates the VLAN
whose hosts should receive the
frame, the CoS is used by the
switch to make decisions on
what QoS, if any, the frame
should receive.
It certainly won’t surprise you

to find that our trunking
protocols, ISL and IEEE 802.1Q
(“dot1q”) handle CoS
differently. Hey, with all the
differences between these two
that you’ve already mastered,
this is easy!
The ISL tag includes a 4-bit
User field; the last three bits of
that field indicate the CoS
value. I know I don’t have to
tell you this, but three binary
bits give us a range of decimal
values of 0 - 7.
The dotlq tag has a User field

as well, but this field is built a
little differently. Dotlq’s User
field has three 802.1p priority
bits that make up the CoS
value, and again that gives us a
decimal range of 0 - 7.
Of course, there’s an exception
to the rule! Remember how
dotlq handles frames destined
for the native VLAN? There is
no tag placed on those frames - so how can there be a CoS
value when there’s no tag?

The receiving switch can be
configured with a CoS to apply
to any incoming untagged
frames. Naturally, that switch
knows that untagged frames
are destined for the native
VLAN.

The DiffServ Model At
Layer Three
Way back in your Introduction

To Networking studies, you
became familiar with the UDP,
TCP, and IP headers. One of the
IP header fields is Type
Of Service (ToS), and that ToS
value is the basis for DiffServ’s
approach to marking traffic at
Layer Three.
The IP ToS byte consists of…
an IP Precedence value,
generally referred to as
IP Prec (3 bits)
a Type Of Service value
(4 bits)

a zero (1 bit)
DiffServ uses this 8-bit field as
well, but refers to this as the
Differentiated Services (DS)
field. The DS byte consists of….
a Differentiated Service
Code Point value
(DSCP,6 bits,RFC 2474)
an Explicit Congestion
Notification value (ECN,
2 bits, RFC 2481)
The 6-bit DSCP value is itself
divided into two parts:

a Class Selector value,
3 bits
a Drop Precedence
value, 3 bits
These two 3-bit values also
have a possible range of 0 - 7
overall (000 - 111 in binary).
Here’s a quick description of the
Class Selector values and their
meanings:
Class 7 (111) - Network
Control, and the name is the
recipe - this value is reserved
for network control traffic (STP,
routing protocol traffic, etc.)

Class 6 (110) - Internetwork
Control, same purpose as
Network Control.
Class 5 (101) - Expedited
Forwarding (EF, RFC 2598) Reserved for voice traffic and
other time-critical data. Traffic
in this class is practically
guaranteed not to be dropped.
Classes 1 - 4 (001 - 100) Assured Forwarding (AF, RFC
2597) - These classes allow us
to define QoS for traffic that is
not as time- critical as that in
Class 5, but that should not be

left to best-effort forwarding,
which is….
Class 0 (000) - Best-effort
forwarding. This is the default.
We’ve got four different classes
in Assured Forwarding, and RFC
2597 defines three Drop
Precedence values for each of
those classes:
High-3
Medium - 2
Low -1
The given combination of any

class and DP value is expressed
as follows:
AF (Class Number)(Drop
Precedence)
That is, AF Class 2 with a DP of
“high” would be expressed as
“AF23”.

To Trust Or Not To
Trust, That Is The
Question
Just as you and I have to make
a decision on whether to trust

something that’s told to us, a
switch has to make a decision
on whether to trust an
incoming QoS value.

Once that decision is made,
one of two things will happen.
If the incoming value is
trusted, that value is
used for QoS.
If the incoming value is
not trusted, the

receiving switch can
assign a preconfigured
value.
It’s a pretty safe bet that if the
frame is coming from a switch
inside your network, the
incoming value should be
trusted. It’s also better to be
safe than sorry, so if the frame
is coming from a switch outside
your administrative control, it
should not be trusted. The
point at which one of your
switches no longer trusts
incoming frames is the trust
boundary.

We’ve also got to decide where
to draw the line with a trust
boundary when PCs and IP
Phones are involved. Let’s walk
through a basic configuration
with an IP Phone attached to
the switch. Here’s a quick
reminder of the physical
topology:

The first command we’ll use
isn’t required, but it’s a great
command for those admins who
work on the switch in the
future:

It never hurts to indicate which
port the phone is attached to.

Now to the required
commands! Before we perform
any QoS on this switch, we
have to enable it - QoS is
disabled globally by default.

We can trust values on two
different levels. First, we can
trust the value unconditionally,
whether that be CoS, IP Prec,
or DSCP. Here, we’ll
unconditionally trust the
incoming CoS value.

We can also make this trust
conditional, and trust the value
only if the device on the other
end of this line is a Cisco IP
phone. lOS Help shows us that
the only option for this
command is a Cisco IP phone!

If you configure that command
and show mls qos interface

indicates the port is not
trusted, most likely there is no
IP Phone connected to that
port. Trust me, I’ve been there.
:)

There’s another interesting QoS
command we need to consider:

If an IP Phone is the only
device on the end of the link,
what “appliance” are we talking
about? Why are we discussing
extending the trust? To what
point are we extending the
trust? Let’s take another look at
our diagram:

Remember, we’ve got a PC
involved here as well. The IP
Phone will generate the voice

packets sent to the switch, but
the PC will be generating data
packets. We need to indicate
whether QoS values on data
received by the phone from the
PC should be trusted or
overwritten.
In other words, should the trust
boundary extend to the PC?
The best practice is to not trust
the QoS values sent by the PC.
Some applications have been
known to set QoS values giving
that application’s data a higher
priority than other data. (Can

you believe such a thing?)
That’s one reason the default
behavior is to not trust the CoS
value from the PC, and to set
that value to zero.

To overwrite the CoS value sent
by the PC and set it to a value
we choose, use the switchport
priority extend cos command.

Frames received from the PC
are now trusted and will have
their priority set to 2. If we had
chosen to trust those same
frames and allow their CoS to
remain unchanged after
transmission from the PC, we
would use the switchport
priority extend trust command.

The word “boundary” doesn’t

appear in the command, but
this command has the effect of
extending the trust boundary
beyond the phone to the PC.

Other QoS Methods To
Improve VOIP Speed &
Quality
We’ve talked at length about
using a priority queue for voice

traffic, but there are some
other techniques we can use as
well. As with any other QoS,
the classification and marking
of traffic should be performed
as close to the traffic source as
possible. Access-layer switches
should always perform this
task, not only to keep the extra
workload off the core switches
but to ensure the end-to-end
QoS you wanted to configure is
the QoS you’re getting.
Another method of improving
VOIP quality is to configure RTP
Header Compression. This

compression takes the
IP/UDP/RTP header from its
usual 40 bytes down to 2 - 4
bytes.

RTP header compression is
configured with the interfacelevel ip rtp header-compression
command, with one option you

should know about - passive. If
the passive option is
configured, outgoing packets
are subject to RTP compression
only if incoming packets are
arriving compressed.

“Power Over Ethernet”
I don’t anticipate you’ll see
much of POE on your exam, if
at all, but it is a handy way to
power the phone if there’s just
no plug available!
With POE, the electricity

necessary to power the IP
Phone is actually transferred
from the switch to the phone
over the UTP cable that already
connects the two devices!

Not every switch is capable of
running POE. Check your
particular switch’s

documentation for POE
capabilities and details.
The IEEE standard for POE is
802.3af. There is also a
proposed standard for HighPower POE, 802.3at. To read
more than you’d ever want to
know about POE, visit
www.poweroverethernet.com.
By default, ports on POEcapable switches do attempt to
find a device needing power on
the other end of the link. We’ve
got a couple of options for POE
as well:

The auto setting is the default.
The consumption option allows
you to set the level of power
sent to the device:

And naturally, the never option
disables POE on that port.
POE options and capabilities
differ from one device to the
next, so check your switch’s

documentation *carefully*
before using POE.

Wireless
Wireless Basics
Hard to believe there was once
a time when a laptop or PC had
to be connected to an outlet to
access the Internet, isn’t it?
Wireless is becoming a larger
and larger part of everyday life,
to the point where people
expect to be able to access the
Net or connect to their network

while eating lunch.
Wireless networks are generally
created by configuring Wireless
Access Points (WAP or AP,
depending on documentation).
If you’re connecting to the
Internet or your company’s
network from a hotel or
restaurant, you’re connected to
a lily pad network.
Unlike the physical networks
we’ve discussed previously in
this course, the WAPs in a lily
pad network can be owned by
different companies. The WAPs

create hotspots where Internet
access is available to anyone
with a wireless host - and
hopefully, a username and
password is required as well!
WAPs are not required to create
a wireless network. In an ad
hoc WLAN (“wireless LAN”), the
wireless devices communicate
with no WAP involved. Ad hoc
networks are also called
Independent Basic Service Sets
(iBSS or IBSS, depending on
whose documentation you’re
reading).

There are two kinds of
infrastructure WLANs. While a
Basic Service Set (BSS) will
have a single AP, Extended
Service Set WLANs (ESS), have
multiple access points. An ESS
is essentially a series of
interconnected BSSes.
Hosts successfully connecting
to the WAP in a BSS are said to
have formed an association
with the WAP. Forming this
association usually requires the
host to present required
authentication and/or the
correct Service Set Identifier

(SSID). The SSID is the public
name of the wireless network.
SSIDs are case-sensitive text
strings and can be up to 32
characters in length.

Cisco uses the term AP instead

of WAP in much of their
documentation; just be
prepared to see this term
expressed either way on your
exam and in network
documentation. I’ll call it an AP
for the rest of this section.
A BSS operates much like a
hub-and-spoke network in that
all communication must go
through the hub, which in this
case is the AP.
We went over three different
service set types in that
section, so to review:

Independent Basic
Service Sets have no
APs; the few wireless
devices involved
interact directly. An
IBSS network is also
called an ad hoc
network.
Basic Service Sets have
a single AP.
Extended Service Sets
have multiple APs,
which allow for a larger
coverage area than the
other two types and
also allow roaming
users to fully utilize the

WLAN.

Creating An Association
There’s quite a bit going on
when a client forms an
association with an AP, but
here’s an overview of the entire
process. The client is going to
transmit Probe Requests, and in
turn the AP response with
Probe Responses.
Basically, the Probe Request is
the client yelling “Anybody out
there?” and the Probe

Response is the AP saying "I’m
Over Here!”

When the client learns about
the AP, the client then begins
the process of association. The
exact information the client
sends depends on the
configuration of the client and
the AP, but it will include
authentication information such
as a pre-shared key.

If the client passes the
authentication process, the AP
then records the client’s MAC
address and accepts the
association with the client.

Roamin’, Roamin’,
Roamin’
APs can also be arranged in
such a way that a mobile user,

or roaming user, will
(theoretically) always be in the
provider’s coverage area. Those
of us who are roaming users
understand the “theoretical”
part!
Roaming is performed by the
wireless client. Under certain
circumstances that we’ll discuss
in just a moment, the client will
actively search for another AP
with the same SSID as the AP
it’s currently connected to.
There are two different
methods the client can use to

find the next AP - active
scanning and passive scanning.
With active scanning, the client
sends Probe Request frames
and then waits to hear Probe
Responses. If multiple Probe
Responses are heard, the client
chooses the most appropriate
WAP to use in accordance with
vendor standards.
Passive scanning is just what it
sounds like - the client listens
for beacon frames from APs. No
Probe Request frames are sent.
Roaming networks use multiple

APs to create overlapping areas
of coverage called cells. While
your signal may occasionally
get weak near the point of
overlapping, the ESS allows
roaming users to hit the
network at any time. (We
hope!)

Roaming is made possible by

the Inter-Access Point Protocol
(lAPP).
For roaming users to remain
connected to the same network
as they roam, the APs must be
configured with the same SSlDs
and have knowledge of the
same IP subnets and VLANs
(assuming VLANs are in use,
which they probably are).
How does our client decide it’s
time to move from one AP to
another? Any one of the
following events can trigger
that move, according to Cisco’s

website:
Client has not received
a beacon from an AP for
a given amount of time
The maximum data
retry count has been
reached
A change in the data
rate
Why would the data rate
change? With wireless, the
lower the data rate, the greater
the range. The 802.11 standard
will automatically reduce the
data rate as the association

with an AP deteriorates.

L2 Roaming vs. L3
Roaming
The difference between the two
is straightforward - L2 roaming
is performed when the APs the
client is roaming are on the
same IP subnet, while L3
roaming occurs when the APs
are on different IP subnets.

Service Set Identifier
(SSID)

When you configure a name for
your WLAN, you’ve just
configured a SSID. The SSID
theory is simple enough - if the
wireless client’s SSID matches
that of the access point,
communication can proceed.
The SSID is case-sensitive and
it has a maximum length of 32
characters.

A laptop can be configured with
a null SSID, resulting in the
client basically asking the AP
for its SSID; if the AP is
configured to broadcast its
SSID, it will answer and
communication can proceed.

A classic “gotcha” with SSIDs is
to configured the AP to not

broadcast its SSID. This would
seem to be a great move for
your WLAN’s security … but is
it?

As you’ve already guessed, this
is not an effective security
measure, because the SSID
sent by the client is not
encrypted. It’s quite easy to

steal, and obviously no
unencryption is needed!

WLAN Authentication
(And Lack of Same)
Of course, you don’t want just
any wireless client connecting
to your WLAN! The 802.11
WLAN standards have two
different authentication
schemes - open system and
shared key. They’re both pretty
much what they sound like.
Open system is basically one

station asking the receiving
station “Hey, do you recognize
me?”
Hopefully, shared key is the
authentication system you’re
more familiar with, since open
system is a little too open!
Shared key uses Wired
Equivalent Privacy (WEP) to
provide a higher level of
security than open system.
There’s just one little problem
with WEP. Okay, a big problem.
It can be broken in seconds by
software that’s readily available

on the Web. Another problem is
the key itself. It’s not just a
shared key, it’s a static key, and
when any key or password
remains the same for a long
time, the chances of it being
successfully hacked increase
substantially.
These two factors make WEP
unacceptable for our network’s
security. Luckily, we’ve got
options…

A Giant LEAP Forward

The Extensible Authentication
Protocol (EAP) was actually
developed originally for PPP
authentication, but has been
successfully adapted for use in
wireless networks. RFC 3748
defines EAP.
Cisco’s proprietary version of
EAP is LEAP, the Lightweight
Extensible Authentication
Protocol. LEAP has several
advantages over WEP:
There is two-way
authentication between
the AP and the client

The AP uses a RADIUS
server to authenticate
the client
The keys are dynamic,
not static, so a different
key is generated upon
every authentication
Recognizing the weaknesses
inherent in WEP, the Wi-Fi
Alliance (their home page is
http://wi-fi.org) saw the need
for stronger security features in
the wireless world. Their
answer was Wi-Fi Protected
Access (WPA), a higher
standard for wireless security.

Basically, WPA was adopted by
many wireless equipment
vendors while the IEEE was
working on a higher standard
as well, 802.11i - but it wasn’t
adopted by every vendor. As a
result, WPA is considered to
work universally with wireless
NICs, but not with all early APs.
When the IEEE issued 802.11i,
the Wi-Fi Alliance improved the
original WPA standards, and
came up with WPA2. As you
might expect, not all older
wireless cards will work with
WPA2.

To put it lightly, both WPA and
WPA2 are major improvements
over WEP. Many wireless
devices, particularly those
designed for home use, offer
WEP as the default protection so don’t just click on all the
defaults when you’re setting up
a home wireless network! The
WPA or WPA2 password will be
longer as well - they’re actually
referred to as passphrases.
Sadly, many users will prefer
WEP simply because the
password is shorter.

Wireless Networking
Standards, Ranges, and
Frequencies
Along with the explosion of
wireless is a rapidly-expanding
range of wireless standards.
Some of these standards play
well together, others do not.
Let’s take a look at the wireless
standards you’ll need to know
to pass the exam and to work
with wireless in today’s
networks.
The standards listed here are
all part of the 802.11x

standards developed by the
IEEE.
802.11a has a typical data rate
of 25 MBPS, but can reach
speeds of 54 MBPS. Indoor
range is 100 feet. Operating
frequency is 5 GHz.
802.11b has a typical data rate
of 6.5 MBPS, but can reach
speeds of 11 MBPS. Indoor
range is 100 feet. Operating
frequency is 2.4 GHz.
802.11g has a typical data rate
of 25 MBPS, a peak data rate of

54 MBPS, and an indoor range
of 100 feet. Operating
frequency is 2.4 GHz. 802.11g
is fully backwards-compatible
with 802.11b, and many routers
and cards that use these
standards are referred to as
“802.11b/g”, or just “b/g”. .11g
and .11b even have the same
number of non-overlapping
channels (three).
You can have trouble with
802.11g from an unexpected
source - popcorn!
Well, not directly, but

microwave ovens also share
the 2.4 GHz band, and the
presence of a microwave in an
office can actually cause
connectivity issues. (And you
thought they were just
annoying when people burn
popcorn in the office
microwave!) Solid objects such
as walls and other buildings can
disturb the signal in any
bandwidth.
802.11n has a typical data rate
of 200 MBPS, a peak data rate
of 540 MBPS, and an indoor
range of 160 feet. Operating

frequency is either 2.4 GHz or 5
GHz.

Infrared Data
Association (IrDA)
The IrDA is another body that
defines specifications, but the
IrDA is concerned with
standards for transmitting data
over infrared light. IrDA 1.0
only allowed for a range of 1
meter and transmitted data at
approximately 115 KBPS. The
transmission speed was greatly
improved with IrDA 1.1, which

has a theoretical maximum
speed of 4 MBPS. The two
standards are compatible.
Keep in mind that neither IrDA
standard has anything to do
with radio frequencies - only
infrared light streams.
The IrDA notes that to reach
that 4 MBPS speed, the
hardware must be 1.1
compliant, and even that might
not be enough - the software
may have to be modified as
well. Which doesn’t sound like
fun.

Antenna Types
A Yagi antenna (technically, the
full name is “Yagi-Uda
antenna”) sends its signal in a
single direction, which means it
must be aligned correctly and
kept that way. Yagi antennas
are sometimes called
directional antennas, since they
send their signal in a particular
direction.

In contrast, an Omni
(“omnidirectional”) antenna
sends a signal in all directions
on a particular plane.
Since this is networking, we
can’t just call these antennae

by one name! Yagis are also
known as point-to-point and
directional antennas] Omni
antennas are also known as
omnidirectional and point-tomultipoint antenna.
Both Yagi and Omni antennas
have their place in wireless
networks. The unidirectional
signal a Yagi antenna sends
makes it particularly helpful in
bridging the distance between
APs. The multidirectional signal
sent by Omni antennas help
connect hosts to APs, including
roaming laptop users.

Courtesy of wikipedia.org, here
are some “antenna terms” you
should be familiar with:
Gain refers to the directionality
of an antenna. Antennae with
low gains emit radiation at the
same power in all directions,
where a high-gain antenna will
focus its power in a particular
direction or directions.
dBi stands for
Decibel(isotropic), and I won’t
go far into this territory, I
promise! dBi is a common value
used to truly measure the gain

of a given antenna when
compared to a fictional antenna
that distributes energy in all
directions.
And you thought we had it bad
with BGP. :)
Bandwidth refers to the range
of frequencies over which the
antenna is effective. There are
several methods of increasing
bandwidth, including the use of
thicker wires and combining
multiple antennas into a single
antenna.

Polarization refers to the
physical positioning and
orientation of the antenna.

CSMA/CA
From your CCNA studies, you
know all about how a “Wired
LAN” avoids collisions. Through
the use of IEEE 802.3,
CSMA/CD (Carrier Sense
Multiple Access with Collision
Detection), only one host can
transmit at a time - and even if
multiple hosts transmit data
onto a shared segment at once,

jam signals and random timers
help to minimize the damage.
With “Wireless LANs”, life isn’t
so simple. Wireless LANs can’t
listen and send at the same
time - they’re half-duplex - so
traditional collision detection
techniques cannot work.
Instead, wireless LANs will use
IEEE standard 802.11,
CSMA/CA, (Carrier Sense
Multiple Access with Collision
Avoidance).
Let’s walk through an example
of Wireless LAN access, and

you’ll see where the
“avoidance” part of CSMA/CA
comes in.
The foundation of CSMA/CA is
the Distributed Coordination
Function (DCF). The key rule of
DCF is that when a station
wants to send data, the station
must wait for the Distributed
Interframe Space (DIFS) time
interval to expire before doing
so. In our example, Host A
finds the wireless channel to be
idle, waits for the DIFS timer to
expire, and then sends frames.

Host B and Host C now want to
send frames, but they find the
channel to be busy with Host
A’s data.

The potential issue here is that
Host B and Host C will
simultaneously realize Host A is
no longer transmitting, so they

will then both transmit, which
will lead to a collision. To help
avoid (there’s the magic word!)
this, DCF requires stations
finding the busy channel to also
invoke a random timer before
checking to see if the channel is
still busy.
In DCF-speak, this random
amount of time is the Backoff
Time. The formula for
computing Backoff Time is
beyond the scope of the exam,
but the computation does
involve a random number, and
that random value helps avoid

collisions.

The Cisco Compatible
Extensions Program
When you’re looking to start or
add to your wireless network,
you may just wonder
“How The $&!(*% Can I Figure
Out Which Equipment Supports
Which Features?”
A valid question!
Thankfully, Cisco’s got a great
tool to help you out - the Cisco

Compatible Extension (CCX)
website. Cisco certification isn’t
just for you and I - Cisco also
certifies wireless devices that
are guaranteed to run a desired
wireless feature.
The website name is a little
long to put here, and it may
well change, so I recommend
you simply enter “cisco
compatible extension” into your
favorite search engine - you’ll
find the site quickly. Don’t just
enter “CCX” in there - you’ll get
the Chicago Climate Exchange.
I’m sure they’re great at what

they do, but don’t trust them to
verify wireless capabilities!

Lightweight Access
Points and LWAPP
Originally, most access points
were autonomous - they didn’t
depend on any other device in
order to do its job. The BSS we
looked at earlier in this section
was a good example of an
autonomous AP.

The problem with autonomous
APs is that as your wireless
network grows - and it will! - it
becomes more difficult to have
a uniform set of policies applied
to all APs in your network. It’s
imperative that each AP in your

network enforce a consistent
policy when it comes to security
and Quality of Service - but
sometimes this just doesn’t
happen.
Many WLANs start small and
end up being not so small! At
first, centralizing your security
policies doesn’t seem like such
a big deal, especially when
you’ve only got one access
point.

As your network grows larger
and more access points are
added, having a central policy
does become more important.
The more WAPs you have, the
bigger the chance of security
policies differing between them
- and the bigger the chance of
a security breach.
Let’s say you add two WAPs to
the WLAN network shown

above. Maybe they’re
configured months apart,
maybe they’re configured by
different people - but the result
can be a radically different set
of security standards.

We’ve now got three very
different WLAN security
protocols in place, and the
difference between the three is
huge, as you’ll soon see.

Depending on which WAP the
laptop uses to authenticate to
the WLAN, we could have a
secure connection - or a very
non-secure connection.
This simple example shows us
the importance of a standard
security policy, and that’s made
possible through the concept of
the Cisco Unified Wireless
Network, which has two major
components - Lightweight
Access Points (LAP or WLAP)
and WLAN Controllers (WLC).
The WLC brings several

benefits to the table:
Centralization,
management, and
distribution of security
policies and
authentication
Allows mobile users to
receive a consistent
level of service and
security from any AP in
the network
Detection of rogue APs
Configuring the access points
as LAPs allows us to configure a
central device, the WLAN

Controller, to give each of the
LAPs the same security policy.
The protocol used to do so, the
aptly-named Lightweight
Wireless Access Point Protocol
(LWAPP), detects rogue (fake)
access points as well.
How does the WLC perform this
rogue AP detection? The LAP
and WLC actually have digital
certificates installed when
they’re built - X.509 certificates,
to be exact. A rogue AP will not
have this certificate, and
therefore can’t authenticate to
become part of the network.

These certificates are
technically referred to as MiCs,
short for Manufacturing

Installed Certificates.
The WLC is basically the
manager of the WLAN, with the
LAPs serving as the workers.
The WLAN Controller will be
configured with security
procedures, Quality of Service
(QoS) policies, mobile user
policies, and more. The WLC
then informs the LAps of these
policies and procedures,

ensuring that each LAP is
consistently enforcing the same
set of wireless network access
rules and regulations.
LAPs cannot function
independently, as Autonomous
APs can. LAPs are dependent
on the presence of a WLC and
cannot function properly
without one. Conversely,
Autonomous APs cannot work
with a WlC, since Autonomous
APs do not speak LWAPP.
(LWAPP is Cisco-proprietary:
the industry standard is

CAPWAP, the Control and
Provisioning of Wireless Access
Points.)
LAPs can be configured with
static IP addresses, but it’s
common to have an LAP use
DHCP to acquire an IP address
in the same fashion a host
device would use. If the LAP is
configured to get its IP address
via DHCP and the first attempt
to do so fails, the LAP will
continue to send DHCP
Discovery messages until a
DHCP Server replies.

Now the LAP must associate
with a WLC. The LAP will use
the Lightweight Wireless Access
Point Protocol (LWAPP) to do
so.
If the LAP does not receive an
L2 LWAPP Discovery Response,
or if the LAP doesn’t support L2
LWAPP in the first place, it’ll
send an L3 LWAPP Discovery
message.
If a WLC receives that
Discovery message and is
running L2 LWAPP, it will
respond with a LWAPP L2

Discovery Response.
We have two modes for LWAPP
- L2 mode and L3 mode. If the
LAP is running L2 mode, the
LAP will send an L2 LWAPP
Discovery message in an
attempt to find a WLC that is
running L2 LWAPP.

If a WLC receives that
Discovery massage and is

running L2 LWAPP, it will
respond with a LWAPP L2
Discovery Response.

If the LAP does not receive an
L2 LWAPP Discovery Response,
or if the LAP doesn’t support L2
LWAPP in the first place. it’ll
send an L3 LWAPP Discovery
massage.

If that doesn’t work, the entire
process begins again with the
LAP sending a DHCP Discovery
message.
Now the LAP needs to associate
with one of the WLCs it has
discovered. To do so, the LAP
sends a LWAPP Join Request,
and the WLC returns a LWAPP
Join Response.

How does the LAP know where
to send that LWAPP Join
Request? After receiving an IP
address of its own via DHCP,
the LAP must learn the IP
address of the WLC via DHCP
or DNS. To use DHCP, the DHCP
Server must be configured to
use DHCP Option 43.
When Option 43 is in effect, the

DHCP Server will include the IP
addresses of WLCs in the
Option 43 field of the DHCP
Offer packet. The LAP can then
send L3 LWAPP Discovery
Request messages to each of
the WLCs.
The LAP can also broadcast
that Join Request to its own IP
subnet, but obviously that’s
only going to work if the WLC is
actually on the subnet local to
the LAP.
Once this Join has taken place,
a comparison is made of the

software revision number on
both the LAP and WLC. If they
have different versions, the LAP
will download the version
stored on the WLC.
There will be two forms of
traffic exchanged between the
LAP and WLC:
Control traffic
Data traffic
While LWAPP L2 traffic is
encapsulated in an Ethernet
frame (EtherType OxBBBB), L3
LWAPP traffic uses UDP source

port 1024 and the following
destination ports for control
and data traffic:
Control traffic:
Destination UDP port is
12223
Data traffic: Destination
UDP port is 12222
LWAPP uses secure key
distribution to ensure the
security of the control
connection between the two the control messages will be
both encrypted and
authenticated. The encryption

is performed by the AES-CCM
protocol. (The previously
mentioned LWAPP Join Request
and Response messages are
not encrypted.)
The data packets passed
between the LAP and WLC will
be LWAPP- encapsulated essentially, LWAPP creates a
tunnel through which the data
is sent - but no other
encryption or security exists by
default.
Just as we had L2 and L3
roaming, we also have LWAPP

L2 and L3 mode. A lightweight
AP will first use LWAPP L2 mode
to attempt to locate a WLC; if
none is found, the AP will then
use LWAPP L3 mode.
Many networks will have more
than one WLC, which is great
for redundancy, but how does
the AP decide which WLC to
associate with if it finds more
than one? The AP will simply
use the WLC with the fewest
associated APs. This prevents
one WLC from being
overloaded with associations
while another WLC in the same

network remains relatively idle.
Many Cisco Aironet access
points can operate
autonomously or as an LAP.
Here are a few of those
models:
1230 AG Series
1240 AG Series
1130 AG Series
Sounds simple enough, but
there are some serious
restrictions to APs that have
been converted from
Autonomous mode to

Lightweight mode. Courtesy of
Cisco’s website, here are the
major restrictions:
Roaming users cannot roam
between Lightweight and
Autonomous APs.
Wireless Domain Services
(WDS) cannot support APs
converted from Autonomous to
Lightweight. Those Lightweight
APs will use WLCs, as we
discussed earlier.
The console port on a
converted Lightweight AP is

read-only. Converted APs do
not support L2 LWAPP.
Converted APs must be
assigned an IP address and
discover the IP address of the
WLC via one of three methods:
DNS
DHCP
A broadcast to its own
IP subnet
You can telnet into lightweight
APs if the WLC is running
software release 5.0 or later.

You can convert the
Lightweight AP back to
Autonomous mode. Check
Cisco’s website for directions. If
tech forums are any indication,
this can be more of an art form
than a science.
Some other Aironet models
have circumstances under
which they cannot operate as
LAPs - make sure to do your
research before purchasing!

The Cisco Wireless
Control System and

Wireless Location
Appliance
The examples in this section
have shown only one WLC, but
it’s common to have more than
one in a wireless network, due
to either the sheer number of
LAPs and/or the desire for
redundancy. We don’t want our
entire wireless network to go
down due to a WLC issue and a
lack of a backup!
To monitor those WLCs and the
LAPs as well, you can use the
Cisco Wireless Control System.

There’s a little hype in this
description, but here’s how
Cisco’s website describes the
WCS:
“The Cisco WCS is an optional
network component that works
in conjunction with Cisco
Aironet Lightweight Access
Points, Cisco wireless LAN
controllers and the Cisco
Wireless Location Appliance.
With Cisco WCS, network
administrators have a single
solution for RF prediction, policy
provisioning, network

optimization, troubleshooting,
user tracking, security
monitoring, and wireless LAN
systems management. Robust
graphical interfaces make
wireless LAN deployment and
operations simple and costeffective. Detailed trending and
analysis reports make Cisco
WCS vital to ongoing network
operations.
Cisco WCS includes tools for
wireless LAN planning and
design, RF management,
location tracking, Intrusion
Prevention System (IPS), and

wireless LAN systems
configuration, monitoring, and
management.”
The Wireless Location
Appliance mentioned in that
description actually tracks the
physical location of your
wireless network users.

The Location Appliance
And RF Fingerprinting
Your fingerprints can prove who
you are; they can also prove
who you are not. In a similar

vein, a device’s RF Fingerprint
can prove that it is a legitimate
access point - or prove that it is
not!
All of the devices in our WLAN
have a role in RF Fingerprinting.
The APs themselves will collect
Received Signal Strength
Indicator information, and will
send that information to the
WLAN Controller (WLC) via
LWAPP.

In turn, the WLAN Controller
will send the RSSI information
it receives from the APs to the
Location Appliance. Note that
Simple Network Management
Protocol is used to do this;
make sure not to block SNMP
communications between the

two devices.

What else can be tracked in the
Location Appliance?
Laptop and palm clients
RFID Asset Tags (Radio
Frequency Identifier)
VoIP clients

The CiscoWorks
Wireless LAN Solution
Engine
There is an easier way to
manage autonomous networks
- the CiscoWorks Wireless LAN
Solution Engine (WLSE). Cisco’s
website defines this product as
“a centralized, systems-level
application for managing and
controlling an entire
autonomous Cisco WLAN
infrastructure”.
The CiscoWorks WLSE acts as
the manager of the

autonomous APs. If there’s a
need to change the config on
the APs, we’ve got two choices:
Perform them on each
individual AP
Perform the change on
the WLSE
Not much of a choice there!
CiscoWorks WLSE has quite a
few features to help make our
WLANs run smoothly:
Proactive monitoring of
thresholds and alerting
the admin to potential

issues before they
become critical, which
assists with capacity
planning and
monitoring network
performance as new
clients are added
Reporting and tracking
features to help with
problem diagnosis,
troubleshooting, and
resolution
Centralized AP configs
allow us to change
multiple AP configs
simultaneously
Execute multiple

firmware upgrades
simultaneously
Creation of templates
that can be used to
quickly configure new
APs
Very effective at
detecting rogue APs
and either shut the
rogue down or alert the
admin and let the
admin handle the rogue
shutdown
When an AP is lost,
WLSE will tell that AP’s
neighbors to increase
their cell coverage

(“self-healing network”)
There are two versions of
WLSE. The full version
(generally referred to as simply
“WLSE”) can manage a
maximum of 2500 devices.
WLSE Express is for smaller
networks that have 100 or
fewer devices to manage.
If you’re using WLSE Express,
you’ll need to set up an AAA
server.
If the WDS device is an AP, the
limit is 60.

If it’s an Integrated Services
Router, the limit is 100.
The limit on the number of APs
is determined by the device in
use as the WDS:
Once the deployment is
complete, the infrastructure
APs are communicating with
the WDS AP, and the WDS AP is
in turn sending any necessary
information to CiscoWorks
WLSE.

The limiton the number of APs
is determined by the device in
use as the WDS:
If the WDS device is an
AP, the limit is 60.
If it’s an Integrated

Services Router, the
limit is 100.
If it’s a switch running
WLSM (Wireless LAN
Services Module), the
limit is 600.
Remember that all limits are
theoretical and your mileage
may vary!

Wireless Repeaters
You don’t see many “wired”
repeaters in today’s networks,
but wireless repeaters are a

common sight in today’s
wireless networks.
From the Linksys website,
here’s their description / sales
pitch for one of their wireless
repeaters:
“Unlike adding a traditional
access point to your network to
expand wireless coverage, the
<wireless repeater> does not
need to be connected to the
network by a data cable. Just
put it within range of your main
access point or wireless router,
and it “bounces” the signals out

to remote wireless devices.
This “relay station” or
“repeater” approach saves
wiring costs and helps to build
wireless infrastructure by
driving signals into even those
distant, reflective corners and
hard-to-reach areas where
wireless coverage is spotty and
cabling is impractical.”
We all know that when it comes
to range and throughput
capabilities, vendors do tend to
state maximum values. Having
said that, the following values

are commonly accepted as true
when it comes to wireless
repeaters.
The overlap of coverage
between a wireless repeater
and a wired AP should be much
greater than the overlap
between two APs. The repeater
and AP coverage should overlap
by at least 50 percent. From
personal experience, I can
vouch for the fact that this is a
minimum.
The repeater must use the
same RF channel as the wired

AP, and naturally must share
the same SSID.
Since the repeater must receive
and repeat every frame on the
same channel, there is a sharp
decrease in overall
performance. You should
expect the throughput to be cut
by about 50%.
An Autonomous AP can serve
as a wireless repeater, but a
Lightweight AP cannot.

The Cisco Aironet

Desktop Utility
The ADU is a very popular
choice for connecting to APs, so
let’s take a detailed look at our
options with this GUI. As you’ll
see in the following pages, the
ADU allows us to do the
following:
Configure an encryption
scheme
Establish an association
between the client and one or
more APs, as well as listing the
APs in order of preference for

that association
Configure authentication
methods and passphrases
Enable or disable the local
client’s radio capabilities
The install process is much like
any other software program,
but here’s a specific warning I’d
like you to see.

After clicking Next, you’ll be
prompted to decide if you’re
using the ADU or the Microsoft
tool. While the MS tool is okay you can still see the Tray Utility,
which we’ll discuss later, and
perform some other basic tasks

- using the ADU does give you
config options and capabilities
that the MS tool does not.
For example, you can use
disable the radio capability of
the client with the ADU, but not
with the Microsoft tool. I’ve
used both and I much prefer
the ADU.
Once the install’s done, we
launch ADU, which opens to the
Current Status tab.
Note: If you print this section,
you may see some choices that

look lighter than others. That
simply means they’re grayed
out in the application, and it’s a
good idea to note when certain
choices are available and when
they’re not!

Clicking on the Advanced tab
shows more detailed

information regarding the APs,
including the AP Name, IP
address, and MAC address.

The Profile Management tab
allows us to create additional
profiles as well as editing the

Default profile.

One limitation of this particular
software is that only one card
can be used at a time - but we
can create up to 16 profiles!
This allows you to create one
profile for office use, another

for home, another for hot spots,
etc.
In this example, we’ll look at
the options for modifying the
Default profile. After clicking
Modify, we’ll see these tabs:

The Security tab is what we’re

most interested in, since we
have quite a few options there.
Here’s the default setting…
None.

In ADU, all drop-down and
check boxes are only enabled if
they’re related to the security
option you’ve chosen. Since

None is selected by default,
everything else on the screen is
disabled.
When I select
WPA/WPA2/CCKM, some
options become available.
(CCKM is Cisco Centralized Key
Management, which allows
roaming users to roam between
APs very quickly - according to
their website, in less than 150
milliseconds.)

I clicked on the drop-down box
to illustrate that the
WPA/WPA2/CCKM EAP choices
are now available. You can’t
see it due to that drop-down
box, but the 802.1x choices are
still unavailable.

After clicking Configure, here
are the options we’re presented
with.

The next available security
option was WPA/WPA2
Passphrase. Note that once I
choose that option, both EAP

drop-down boxes are again
disabled.

Clicking Configure presents us
with only one option, and it’s
the one we’d expect.

Let’s go back to the main
window and select 802.1x.

Note the WPA/WPA2/CCKM EAP

selections are still disabled, but
the dotlx EAP window is now
enabled. If we click Configure,
the EAP choices are the same
as they were when we selected
WPA/WPA2/CCKM EAP - except
for Host-Based EAP, which is
only available with 802.1x.

The previous methods have the
authentication server generate
a key and then pass that key to
the client, but what if we want
to configure the keys
ourselves? We simply use the
aptly-named Pre-Shared Key
option.
Let’s take a look at the PreShared Key values. I went back
to the main screen, chose PreShared Key, and again both EAP
drop-down boxes were
disabled. I then clicked
Configure and here’s the result
- simple enough!

Naturally, a WEP key configured
here must match that of the AP
you want the client to associate
with. Ad Hoc networks are fairly
rare today, but if you’re working
without an IP and using WEP
keys, the key must be agreed
upon by each client in the Ad
Hoc network. (This tends to be

the trickiest part of configuring
an Ad Hoc network!)
A couple of points to remember
from the Security Options tab..
The default is None
Drop-down boxes are enabled
only if you choose an option
related to that box - when we
chose WPA/WPA2/CCKM, the
dot1x EAP box was disabled,
and vice versa
The Advanced tab has some
options that you’ll generally

leave at the defaults, but let’s
take a look at them anyway!

If you want to list your APs in
order of preference, click
Preferred APs and then enter
their MAC addresses in the

following fields.

Configuring preferred APs does
not mean that your client is
limited to these APs. If your
client is unable to form an
association with any APs
specified here, the client can
still form an association with

other APs.

The Aironet System
Tray Utility
We’re all familiar with the
generic icon on a laptop or PC
that shows us how strong (or
weak) our wireless signal is.
The Aironet System Tray Utility
(ASTU) gives us that
information and a lot more.
Instead of just indicating how
strong the wireless signal is,
the icon will change color to
indicate signal strength and

other important information.
At the beginning of the ADU
install, we saw this window,
following by a prompt to
choose the Cisco tool or a thirdparty tool:

A reminder - you can still see
the ASTU if you’re working with
the Microsoft utility, but the
ADU’s overall capabilities are
diminished. Naturally, Cisco
recommends you use the ADU.
Having used both, I agree!
The only problem with the
ASTU is that the colors aren’t
exactly intuitive, so we better
know what they mean. Here’s a
list of ASTU icon colors and
their meanings.
Red - This does not mean that
you don’t have a connection to

an access point! It means that
you do have connectivity to an
AP, and you are authenticated
via EAP if necessary, but that
the signal strength is low.
Yellow - Again, you are
connected to an AP and are
authenticated if necessary, but
signal strength is fair.
Green - Connection to AP is
present, EAP authentication is
in place if necessary, and signal
strength is very good.
Light Gray - Connection to AP

is present, but you are *not*
EAP- authenticated.
Dark Gray - No connection to
AP is present.
White - Client adapter is
disabled.
If you’re connecting to an ad
hoc network, just substitute
“remote client” for “AP” in the
above list. The key is to know
that red, green, and yellow are
referring to signal strength,
light gray indicates a lack of
EAP authentication, dark gray

means there is no connection
to an AP or remote client, and
white means the adapter is
disabled.

Interpreting The Lights
On A Cisco Aironet
Adapter Card
We have two lights on a Cisco
Aironet card. The green light is
the Status LED, and the amber
light is the Activity LED. We’ve
got quite a few combinations
with those two lights, so let’s
take a look at what each of the

following LED readouts
indicates.
Status off, Activity off Naturally, this means the card
isn’t getting power!
Status blinking slowly, Activity
off - the adapter’s in Power
Save mode.
Status on, Activity off - adapter
has come out of Power Save
mode.
Both lights blinking in an
alternating fashion - adapter is

scanning for its network.
Both lights blinking slowly at
the same time - adapter has
successfully associated with an
AP (or other client if you have
an Ad Hoc network)
Both lights blinking quickly at
the same time - adapter is
associated and is sending or
receiving data

Tips On Configuring The
WLAN Controller
Many Cisco products can now

be configured via a GUI or at
the CLI, and WLAN Controllers
are no exception. The GUI is
actually built into the controller,
and allows up to five admins to
browse the controller
simultaneously.
Real-world note: If you’re on a
controller with four other
admins, make sure you’re all
talking to each other while
you’re on there. Nothing more
annoying than configuring
something and having someone
else remove the config.

The GUI allows you to use
HTTP or HTTPS, but Cisco
recommends you enable only
HTTPS and disable HTTP
access.
To enable or disable HTTP
access, use the config network
webmode ( enable/disable)
command.
To enable or disable HTTPS
access, use the config network
secureweb (enable/disable)
command.
Cisco has an excellent online

PDF you can use as a guide to
get started with a WLAN
controller configuration - how
to connect, console default
settings, etc. Links tend to
change so I will not post it
here, but to get a copy, just do
a quick search on “cisco
wireless lan controller
configuration guide”. It’s not
required reading for the exam,
but to learn more about WLAN
controllers, it’s an excellent
read.

An Introduction To

Mesh Networks - And
An Age-Old Problem
A wireless mesh network is
really just what it sounds like a collection of access points
that are logically connected in a
mesh topology, such as the
following.

Real-world note: Not all APs
can serve as a mesh AP. The
most popular mesh AP today is
probably the Cisco Aironet 1500
series.

This is obviously a very small
mesh network, but several APs
have multiple paths to the AP
that has a connection to the
WLC. From our CCNA studies,
we already know that we need
a protocol to determine the
optimal path - and it’s not the
Spanning Tree Protocol.
The Cisco-proprietary Adaptive
Wireless Path Protocol (AWPP)
will discover neighboring APs
and decide on the best path to
the wired network by
determining the quality of each
path and choosing the highest-

quality path.
Much like STP, AWPP will
continue to run even after the
optimal path (the “root path”)
to the wired network from a
given AP is chosen. AWPP will
continually calculate the quality
of the available paths, and if
another path becomes more
attractive, that path will be
chosen as the root path.
Likewise, if the root path
becomes unavailable, AWPP
can quickly select another root
path.

Avoid A Heap Of Trouble
With H-REAP
The almost-ridiculously named
Hybrid Remote Edge Access
Point can really help a remote
location keep its wireless
access when its access point
loses sight of its Controller.
The H-REAP is an atypical
controller-based AP. When your
average AP can’t see its own
WlC any longer, it can’t offer
wireless to its clients. When a
H-REAP encounters that
situation, it begins to act like

an autonomous AP - an AP that
can offer wireless with no help
from anyone or anything else.
Config of an H-REAP is beyond
the scope of the CCNP SWITCH
exam, but if you have need for
a wireless solution for remote
sites that can’t afford to have
wireless services unavailable,
check this solution out!

Network Design And
Models
In this section, you’re going to
be reintroduced to a
networking model you first saw
in your CCNA studies. No, it’s
not the OSI model or the
TCP/IP model - it’s the Cisco
Three-Layer Hierarchical Model.
About all you had to do for the
CCNA was memorize the three

layers and the order they were
found in that model, but the
stakes are raised here in your
CCNP studies. You need to
know what each layer does,
and what each layer should not
be doing. This is vital
information for your real- world
network career as well, so let’s
get started with a review of the
Cisco three-layer model, and
then we’ll take a look at each
layer’s tasks. Most of the
considerations at each layer are
common sense, but we’ll go
over them anyway!

The Cisco Three-Layer
Hierarchical Model

The Core Layer
The term core switches refers
to any switches found here, the

core layer. Switches at the core
layer allow switches at the
distribution layer to
communicate, and this is more
than a full-time job. It’s vital to
keep any extra workload off the
core switches, and allow them
to do what they need to do switch!
The core layer is the backbone
of your entire network, so we’re
interested in high-speed data
transfer and very low latency.
That’s it! The core layer is the
backbone of our network, so
we’ve got to optimize data

transport.
Today’s core switches are
generally multilayer switches switches that can handle both
the routing and switching of
data. The throughput of core
switches must be high, so
examine your particular
network’s requirements and
switch documentation
thoroughly before making a
decision on purchasing core
switches. We want our core
switches to handle switching,
and let distribution-layer
switches handle routing.

Core layer switches are usually
the most powerful in your
network, capable of higher
throughput than any other
switches in the network.
Remember, everything we do
on a Cisco router or switch has
a cost in CPU or memory, so
we’re going to leave most
frame manipulation and
filtering to other layers.
The exception is Cisco QoS, or
Quality of Service. Advanced
QoS is generally performed at
the core layer. We’ll go into
much more detail regarding

QoS in another section, but for
now, know that QoS is basically
high-speed queuing where
special consideration can be
given to certain data in certain
queues. Leave ACLs and other
filters for other parts of the
network.
We always want redundancy,
but you want a lot of
redundancy in your core layer.
This is the nerve center of your
entire network, so fault
tolerance needs to be as high
as you can possibly get it. Root
bridges should also be located

in the core layer whenever
possible.

The Distribution Layer
The demands on switches at
this layer are high. The accesslayer switches are all going to
have their uplinks connecting to
these switches, so not only do
the distribution-layer switches
have to have high-speed ports
and links, they’ve got to have
quite a few to connect to both
the access and core switches.

That’s one reason you’ll find
powerful multilayer switches at
this layer - switches that work
at both L2 and L3.
Distribution-layer switches
must be able to handle
redundancy for all links as well.
Examine your network topology
closely and check vendor
documentation before making
purchasing decisions on
distribution-layer switches. The
distribution layer is also where
routing should take place when
utilizing multilayer switches,
since the access layer is busy

with end users and we want
the core layer to be concerned
only with switching, not
routing.
While QoS is often found
operating at the core layer,
you’ll find it in the distribution
layer as well. The distribution
layer also serves as the
boundary for broadcasts and
multicasts, thanks to the L3
devices found here. (Recall
from your CCNA studies that
Layer 3 devices do not forward
broadcasts or multicasts.)

The Access Layer
End users communicate with
the network at this layer. VLAN
membership is handled at this
layer, as well as traffic filtering
and basic QoS.
Redundancy is important at this
layer as well - hey, when isn’t
redundancy important? - so
redundant uplinks are vital. The
uplinks should also be scalable
to allow for future network
growth.
You also want your access layer

switches to have as many ports
as possible, and again, plan for
future growth. A 12-port switch
may be fine one week, but a
month from now you might just
wish you had bought a 24-port
switch. A good rule of thumb
for access switches is “low cost,
high switchport-to-user ratio”.
Don’t assume that today’s
sufficient port density will be
just as sufficient tomorrow!
You can perform MAC address
filtering at the access layer,
although hopefully there are
easier ways for you to perform

the filtering you need. (MAC
filtering is a real pain to
configure.) Collision domains
are also formed at the access
layer.

The Enterprise
Composite Network
Model
This model is much larger than
the Cisco three-layer model, as
you’ll see in just a moment. I
want to remind you that
networking models are
guidelines, and should be used

as such. This is particularly true
of the Enterprise Composite
Network Model, which is one
popular model used to design
campus networks. A campus
network is basically a series of
LANs that are interconnected
by a backbone.
Before we look at this model,
there’s some terminology you
should be familiar with.
Switch blocks are units of
access-layer and distributionlayer devices. These layers
contain both the traditional L2

switches (found at the access
layer) and multilayer switches,
which have both L2 and L3
capabilities (found at the
distribution layer). Devices in a
switch block work together to
bring network access to a unit
of the network, such as a single
building on a college campus or
in a business park.
Core blocks consist of the highpowered core switches, and
these core blocks allow the
switch blocks to communicate.
This is a tremendous
responsibility, and it’s the major

reason that I’ll keep mentioning
that we want the access and
distribution layers to handle as
many of the “extra” services in
our network whenever possible.
We want the core switches to
be left alone as much as
possible so they can
concentrate on what they do
best - switch.
The design of such a network is
going to depend on quite a few
factors - the number of LANs
involved, the physical layout of
the building or buildings
involved being just two of them

- so again, remember that
these models are guidelines.
Helpful guidelines, though!
The Enterprise Composite
Network Model uses the term
block to describe the three
layers of switches we just
described. The core block is the
collection of core switches,
which is the backbone
mentioned earlier. The access
and distribution layer switches
are referred to as the switch
blocks.
Overall, there are three main

parts of this model:
The Enterprise Campus
The Enterprise Edge
The Service Provider
Edge
The Enterprise Campus consists
of the following modules:
Campus Infrastructure
module
Server Farm module
Network Management
module
Enterprise Edge (yes,
again)

In turn, the Campus
Infrastructure module consists
of these modules:
Building Access module
(Access-layer devices)
Building Distribution
module (Distributionlayer devices)
Campus Backbone
(Interconnects multiple
Distribution modules)
Let’s take a look at a typical
campus network and see how
these block types all tie in.

How The Switch Blocks
And Core Blocks Work
Together

The smaller switches in the
switch block represent the
access-layer switches, and
these are the switches that
connect end users to the

network. The distribution-layer
switches are also in the switch
block, and these are the
switches that connect the
access switches to the core.
All four of the distribution layer
switches shown have
connections to both switches in
the core block, giving us the
desired redundancy. The core
block serves as the campus
backbone, allowing switches in
the LAN 1 Switch Block to
communicate with switches in
the LAN 2 Switch Block.

The core design shown here is
often referred to as dual core,
referring to the redundant
fashion in which the switch
blocks are connected to the
core block. The point at which
the switch block ends and the
core block begins is very clear.
A smaller network may not
need switches to serve only as
core switches, or frankly, may
not be able to afford such a
setup. Smaller networks can
use a collapsed core, where
certain switches will perform
both as distribution and core

switches.

In a collapsed core, there is no
dedicated core switch. The four
switches at the bottom of the
diagram are serving as both
core and distribution layer
switches. Note that each of the
access switches have
redundant uplinks to both
distribution / core switches in

their switch block.

The Server Farm Block
As much as we’d like to get rid
of them sometimes, we’re not
going to have much of a
network without servers! In a
campus network, the server
farm block will be a separate
switch block, complete with
access and distribution layer
switches. The combination of
access, distribution, and core
layers shown here is sometimes
referred to as the Campus

Infrastructure.

Again, the distribution switches
have redundant connections to
the core switches. So far we
have a relatively small campus

network, but you can already
get a good idea of the sheer
workload the core switches will
be under.

The Network
Management Block
Network management tools are
no longer a luxury - in today’s
networks, they’re a necessity.
AAA servers, syslog servers,
network monitoring tools, and
intruder detection tools are
found in almost every campus
network today. All of these

devices can be placed in a
switch block of their own, the
network management block.

Now our core switches have
even more to contend with but we’re not quite done yet.
We’ve got our end users
located in the first switch

blocks, we’ve got our server
farm connected to the rest of
the network, we’ve got our allimportant network
management and security block
set up… what else do we need?
Oh yeah…. internet
connectivity! (And WAN
access!) Two blocks team up to
bring our end users those
services - the Enterprise Edge
Block and the Service Provider
Edge Block.

Internet and WAN connectivity
for a campus network is a twoblock job - one block we have

control over, the other we do
not. The Enterprise Edge Block
is indeed the edge of the
campus network, and this block
of the routers and switches
needed to give the needed
WAN connectivity to the rest of
the campus network.
While the Service Provider Edge
Block is considered part of the
campus network model, we
have no control over the actual
structure of this block. And
frankly, we don’t really care!
The key here is that this block
borders the Enterprise Edge

Block, and is the final piece of
the Internet connectivity puzzle
for our campus network.
Take a look at all the lines
leading to those core switches.
Now you know why we want to
dedicate as much of these
switches’ capabilities to pure
switching - we’re going to need
it!

PPDIOO
Now there’s an acronym.
PPDIOO is a Cisco lifecycle

methodology, and it stands for…
Prepare. At this stage, we’re
answering the musical
questions “What is our final
goal, what hardware do we
need to get there, and how
much is this going to cost?” The
questions here are broad.
Plan. You’re still asking
questions, they’re just a bit
different. “What does the client
have now, can the current
network support the network
we want to have, and if so,
what steps do we need to take

to get there?” At this point, the
questions are getting more
specific.
Design. Now we’re really
getting detailed. “How exactly
are we going to build this
network?”
Implement. The design
becomes a reality.
Operate. The (hopefully)
mundane day-to-day network
operation.
Optimize. “What current

operations could we be doing in
a more efficient manner?”
Here’s a link to a Cisco PDF on
this topic. Not required reading
for the exam, but it certainly
couldn’t hurt. Warning:
buzzwords ahead.

Queueing And
Compression
We covered CoS and IP
Telephony QoS in another
section, but there’s a chance
that you’ll see some more
general QoS questions on your
CCNP SWITCH exam. With that
in mind, here’s a bonus chapter
on QoS!
In today’s networks, there’s a

huge battle for bandwidth.
You’ve got voice traffic, video
traffic, multicasts, broadcasts,
unicasts…. and they’re all
fighting to get to the head of
the line for transmission! The
router’s got to make a decision
as to which traffic should be
treated with priority, which
traffic should be treated
normally, and which traffic
should be dumped if congestion
occurs.
Cisco routers offer several
options for this queueing
procedure, and it won’t surprise

you to know that you need to
know quite a few of them to
become a CCNP! Beyond
certification, it’s truly important
to know what’s going on with a
network’s queues - and the only
way to learn queueing is to
dive right in, so let’s get
started!
Here’s a (very) basic overview
of the queuing dilemma facing
a router:

Three different kinds of traffic,
and they all want to be
transmitted first by the router.
Of course, we could break this
down further by specifying the
sender and receiver - “if Host A
sends data to Host B, send that
first”. Developing a successful

queuing strategy takes time
and planning, because not all
this data can go first.

First In, First Out
FIFO is just what it sounds like
- there is no priority traffic, no
traffic classes, no queueing
decision for the router to make.
This is the default for all Cisco
router interfaces, with the
exception of Serial interfaces
running at less than E1 (2.048
MBPS) speed. FIFO is fine for
many networks, and if you have

no problem with network
congestion, FIFO may be all
you need. If you’ve got traffic
that’s especially time-sensitive
such as voice and video, FiFO is
not your best choice.

Flow-Based Weighted
Fair Queueing
What’s so “fair” about Weighted
Fair Queueing (WFQ)? WFQ
prevents one particular stream
of network traffic, or flow, from
using most or all of the
available bandwidth while

forcing other streams of traffic
to sit and wait. These flows are
defined by WFQ and require no
access list configuration. Flowbased WFQ is the default
queueing scheme for Serial
interfaces running at E1 speed
or below.
Flow-Based WFQ takes these
packet flows and classifies
them into conversations. WFQ
gives priority to the interactive,
low-bandwidth conversations,
and then splits the remaining
bandwidth fairly between the
non-interactive, high-bandwidth

conversations.
In the following exhibit, a
Telnet flow reaches the router
at the same time as two FTP
flows. Telnet is low-volume, so
the Telnet transmission will be
forwarded first. The two
remaining file transfers will
then be assigned a comparable
amount of bandwidth. The
packets in the two file transfers
will be interleaved - that is,
some packets for Flow 1 will be
sent, then some for Flow 2, and
so on. The key here is that one
file transfer flow will not have

priority over the other.

Enabling flow-based WFQ is
simple enough. We don’t even
have to configure it on the
following Serial interface, since
WFQ is enabled by default on
all serial interfaces running at
or below E1 speed, but let’s
walk through the steps:

The Congestive Discard
Threshold dictates the number
of packets that can be held in a
single queue. The default is 64.
Let’s change it to 200.

To verify your queuing
configuration, run show queue
followed by the interface type

and number.

The Dynamic Conversation
Queues are used for normal,
best-effort conversations. We’ll
change that to 200 as well.

Then again, maybe we won’t.
Let’s change it to 256 instead
and use lOS Help to show any

other options.

The final WFQ option is the
number of Reservable
Conversation Queues. The
default here is zero. These
queues are used for specialized
queueing and Quality of Service
features like the Resource
Reservation Protocol (RSVP).
We’ll set this to 100.

show queue verifies that all
three of these values have

been successfully set, as does
show queueing fair.

What Prevents WFQ
From Running?
Earlier in this section, l
mentioned that serial interfaces
running at E1 speed or lower
will run WFQ by default.
However, if any of the following
features are running on the
interface, WFQ will not be the

default.
Tunnels, Bridges,
Virtual Interfaces
Dialer interfaces, LAPB,
X.25

Class-Based Weighted
Fair Queuing
The first reaction to WFQ is
usually something like this:
“That sounds great, but
shouldn’t the network
administrator be deciding which
flows should be transmitted

first, rather than the router?”
Good question! There’s an
advanced form of WFQ, ClassBased Weighted Fair Queuing
(CBWFQ) that allows manual
configuration of queuing - and
CBWFQ does involve access list
configuration.
Since the name is the recipe,
the first step in configuring
CBWFQ is to create the classes
themselves. If you’ve already
passed your BCRAN exam, this
will all look familiar to you. If
not, no problem at all, we’ll
take a step-by-step approach to

CBWFQ.
We’ll first define two classes,
one that will be applied to TCP
traffic sourced from 172.10.10.0
/24, and another applied to FTP
traffic from 172.20.20.0 /24.
The first step is to write two
separate ACLs, with one
matching the first source and
another matching the second.
Don’t write one ACL matching
both.

Now two class maps will be
written, each calling one of the

above ACLs.

By the way, we’ve got quite a
few options for the match
statement in a class map, and
up to 64 classes can be
created:

At this point, we’ve created two

class maps that aren’t really
doing anything except matching
the access list. The actual
values applied to the traffic are
contained in our next step, the
policy map.

The values we’ll set for both
classes are the bandwidth and
queue-limit values. For traffic

matching class 17210100, we’ll
assign bandwidth of 400 and a
queue limit of 50 packets; for
traffic matching class
17220200, we’ll assign
bandwidth of 200 and a queue
limit of 25 packets. The
bandwidth assigned to a class
is the value CBWFQ uses to
assign weight.
The more bandwidth
assigned to a class, the
lower the weight
The lower the weight,
the higher the priority
for transmission

If no queue limit is configured,
the default of 64 is used.
Finally, we need to apply this
policy map to the interface! As
with ACLs, a Cisco router
interface can have one policy
map affecting incoming traffic
and another affecting outgoing
traffic. We’ll apply this to traffic

leaving Serial0.

Here’s a classic “gotcha” - to
apply a policy map, you’ve got
to disable WFQ first. The router
will be kind enough to tell you
that. The exam probably won’t
be that nice. :) Remove WFQ
with the no fair-queue
command, then we can apply
the policy map.

To view the contents of a policy
map, run show policy-map.

CBWFQ configuration does have
its limits. By default, you can’t
assign over 75% of an
interface’s bandwidth via
CBWFQ, because 25% is
reserved for network control
and routing traffic. To illustrate,
I’ve rewritten the previous
policy map to double the
requested bandwidth settings.
When I try to apply this policy

map to the serial interface, I
get an interesting message:

Why is 358 Kbps all that’s
available? Start with the
bandwidth of a serial interface,
1544 kbps. Only 75% of that
bandwidth can be assigned
through CBWFQ, and 1544 x .75
= 1158. We can assign only
1158 kbps of a T1 interface’s
bandwidth in the policy map.

We have already assigned 800
kbps to class 17210100, leaving
only 358 kbps for other classes.
Keep this 75% rule in mind - it’s
a very common error with
CBWFQ configurations. Don’t
jump to the conclusion that
bandwidth 64 is the proper
command to use when you’ve
got a 64 kbps link and you want
to enable voice traffic to use all
of it. Always go with a
minimum of 75% of available
bandwidth, and don’t forget all
the other services that will
need bandwidth as well!

If you really need to change
this reserved percentage - and
you should have a very good
reason before doing so - use
the max-reserved-bandwidth
command on the interface. The
following configuration changes
the reservable bandwidth to
85%.

The “reservable bandwidth”
referenced in this command
isn’t just the bandwidth
assigned in CBWFQ. It also

includes bandwidth allocated
for the following:
Low Latency Queuing
(LLQ)
IP Real Time Protocol
(RTP) Priority
Frame Relay IP RTP
Priority
Frame Relay PVC
Interface Priority
Queuing
Resource Reservation
Protocol (RSVP)

CBWFQ And Packet

Drop
Earlier in this section, we used
the queue-limit command to
dictate how many packets a
queue could hold before
packets would have to be
dropped. Below is part of that
configuration, and for this
particular class the queue is
limited to holding 50 packets.

If the queue is full, what

happens? No matter how
efficient your queuing strategy,
sooner or later, the router is
going to drop some packets.
The default method of packet
drop with CBWFQ is tail drop,
and it’s just what it sounds like
- packets being dropped from
the tail end of the queue.

Tail drop may be the default,
but there are two major issues
with it. First, this isn’t a very
discriminating way to drop
traffic. What if this were voice
traffic that needed to go to the
head of the line? Tail drop
offers no mechanism to look at
a packet and decide that a
packet already in the queue
should be dropped to make
room for it.
The other issue with tail drop is
TCP global synchronization.
This is a result of TCP’s
behavior when packets are lost.

Packets dropped due to
tail drop result in the
TCP senders reducing
their transmission rate.
As the transmission
slows, the congestion is
reduced.
All TCP senders will
gradually increase their
transmission speed as a
result of the reduced
congestion - which
results in congestion
occurring all over again.
The result of TCP global
synchronization? When the TCP

sender simultaneously slow
their transmission, that results
in underutilization of the
bandwidth. When the TCP
senders all increase their
transmission rate at the same
time, the bandwidth is
oversubscribed, packets are
dropped and must be
retransmitted, and the entire
process begins all over again.
Basically, the senders are either
sending too little or too much
traffic at any given time.
To avoid the TCP Global
Synchronization problems,

Random Early Detection (RED)
or Weighted Random Early
Detection (WRED) can be used
in place of Tail Drop. RED will
proactively drop packets before
the queue gets full, but the
decision of which packets will
be dropped is still random.
WRED uses either a packet’s IP
Precedence or Differentiated
Services Code Point (DSCP) to
decide which packets should be
dropped.
WRED gives the best service it
can to packets in a priority
queue. If the priority queue

becomes full, WRED will drop
packets from other queues
before dropping any from the
priority queue.
The random-detect command is
used to enable WRED. You
know it can’t be just that
simple, right? You must keep in
mind that when WRED is
configured as part of a class in
a policy map, WRED must not
be running on the same
interface that the policy is
going to be applied to.

Both RED and WRED are useful
only when the traffic in
question is TCP-based.

Low Latency Queueing
CBWFQ is definitely a step in
the right direction, but what
we’re looking for is a guarantee
(or something close to it) that
data adversely affected by
delays is given the highest

priority possible. Low Latency
Queuing (LLQ) is an “add-on”
to CBWFQ that creates such a
strict priority queue for such
traffic, primarily voice traffic,
allowing us to avoid the jitter
that comes with voice traffic
that is not given the needed
priority queuing. (Cisco
recommends that you use an
LLQ priority queue only to
transport Voice Over IP traffic.)
Since we’re mentioning
“priority” so often here, it
shouldn’t surprise you to learn
that the command to enable

LLQ is priority.
Before we configure LLQ, there
are a couple of commands and
services we’ve mentioned that
don’t play well with LLQ:
WRED and LLQ can’t
work together. Why?
Because WRED is
effective only with TCPbased traffic, and the
voice traffic that will
use LLQ’s priority queue
is UDP-based. The
random-detect and
priority commands can’t

be used in the same
class.
By its very nature, LLQ
doesn’t have strict
queue limits, so the
queue-limit and priority
commands are mutually
exclusive.
Finally, the bandwidth
and priority commands
are also mutually
exclusive.
In the following example, we’ll
create an LLQ policy that will
place any UDP traffic sourced
from 210.1.1.0 /24 and

destined for 220.1.1.0 /24 into
the priority queue - IF the UDP
port falls in the 17000-18000 or
2000021000 range. The priority
queue will be set to a
maximum bandwidth of 45
kbps. The class class-default
defines what happens to traffic
that doesn’t match any other
classes, and we’ll use that class
to apply fair queuing to
unmatched traffic.

Priority Queuing (PQ)
The “next level” of queuing is
Priority Queuing (PQ), where
four predefined queues exist:
High, Medium, Normal, and
Low. Traffic is placed into one
of these four queues through

the use of access lists and
priority lists. The High queue is
also called the strict priority
queue, making
PQ and LLQ the queueing
solutions to use when a priority
queue is needed.

These four queues are

predefined, as are their limits:
High-Priority Queue: 20
Packets
Medium-Priority Queue:
40 Packets
Normal-Priority Queue:
60 Packets
Low-Priority Queue: 80
Packets
It won’t surprise you to learn
that these limits can be
changed. Before we configure
PQ and change these limits,
there’s one very important
concept that you must keep in

mind when developing a PQ
strategy. PQ is not roundrobin; when there are
packets in the High queue,
they’re going to be sent
before any packets in the
lower queues. If too many
traffic types are configured to
go into the High and Medium
queues, packets in the Normal
and Low queues may never be
sent! This is sometimes
referred to as traffic starvation
or packet starvation. (I
personally think it’s more like
queue starvation, but the last
thing we need is a third name

for it.)
The moral of the story: When
you’re configuring PQ, be very
discriminating about how much
traffic you place into the upper
queues.
Configuring PQ is simple. The
queues already exist, but we
need to define what traffic
should go into which queue. We
can use the incoming interface
or the protocol to decide this,
and we can also change the
size of the queue with this
command.

If we choose to use protocol to
place packets into the priority
queues, access lists can be
used to further define queuing.

Let’s say we want IP traffic
sourced at 20.1.1.0 /24 and
destined for 30.3.3.0 /27 to be
placed into the High queue.
We’d need to write an ACL
defining that traffic and call
that ACL from the priority-list
command.

To place all TCP DNS traffic into
the Medium queue, use the
protocol option with the
priority-list command. We’ll use
lOS Help to show us the options
after the queue name.

As you can see, the router will
list many of the more common
TCP ports.
To place packets coming in on
the Ethernet0 interface into the
Normal queue, use the
interface option with the
pr/’ority-list command.
Finally, the default queue sizes
can be changed with the
queue-limit command. This is
an odd little command in that if
you just want to change one
queue’s packet limit, you still
have to list the values for all

four queues - and all four
values must be entered in the
order of high, medium, normal,
and low. In the following
example, we’ll double the
capacity of the Normal queue
while retaining all other default
queue sizes.

Priority queuing is applied to
the interface with the prioritygroup command.

show queueing verifies that PQ
is now in effect on this
interface.

Show queueing priority displays
the priority lists that have been
created, along with the
changes to each queue’s

defaults. Note that the queue
limit is only shown under
Arguments ("Args”) if it’s been
changed. Also, ACLs and port
numbers in use are shown on
the right.

Custom Queueing (CQ)
Custom Queueing (CQ) takes
PQ one step further - CQ
actually allows you to define

how many bytes will be
forwarded from every queue
when it’s that queue’s turn to
transmit. CQ doesn’t have the
same queues that PQ has,
though. CQ has 17 queues, with
queues 1 - 16 being
configurable.
Queue Zero carries network
control traffic and cannot be
configured to carry additional
traffic. By default, the packet
limit for each configurable
queue is 20 packets and each
will send 1500 bytes when it’s
that queue’s turn to transmit.

The phrase “network control
traffic” in regards to Queue
Zero covers a lot of traffic.
Traffic that uses Queue Zero
includes
Hello packets for EIGRP,
OSPF, IGRP, ISIS
Syslog messages
STP keepalives
CQ uses a round-robin system

to send traffic. When it’s a
queue’s turn to send, that
queue will transmit until it’s
empty or until the configured
byte limit is reached. By
configuring a byte-limit, CQ
allows you to allocate the
desired bandwidth for any and
all traffic types.
Configuring CQ is basically a
three-step process:
Define the size of the
queues
Define what packets
should go in each

queue
Define the custom
queue list by applying
the list to the
appropriate interface

Defining The Custom
Queue Size
To change the capacity of any
queue from the default of 20
packets, use the queue-list x
queue x limit command. The
following configuration changes
Queue 1’s queue limit to 100
packets.

Defining The Packets To
Be Placed In Each
Custom Queue
Traffic can be placed into a
given queue according to its
protocol or incoming interface.
If the protocol option is used,
an ACL can be used to further
define the traffic. In the
following example, traffic
sourced from network 100.1.1.0
/25 and destined for 200.2.2.0

/28 will be placed into Queue 2.

To queue traffic according to
the incoming interface, use the
interface option with the
queue-list command. All traffic
arriving on ethernet0 will be
placed into Queue 4.

To change the amount of bytes

a queue will transmit when the
round-robin format allows it to,
use the byte-count option.
Here, we’ll double the default
for Queue 3.

A default queue can also be
created as a “catch-all” for
traffic that isn’t matched by
earlier arguments. Since this
example has used queues 1 - 4,
Queue 5 will be used as the
default queue.

There’s one more common

queue-list configuration you
should know about. All traffic
using a specific port number
can be assigned to a specific
queue. The configuration isn’t
the most intuitive I’ve seen, so
let’s go through a queue-list
command that places all WWW
traffic into queue 2. We’ll start
by looking at all the options for
the queue-list command.

We’ll use the protocol option
and look at the options there.

The next step is where the
confusion tends to come in.
After ip, the next value is the
queue number itself. The next
value is the protocol type.

Finally, the port number is
configured, which ends the
command. I won’t show all the
port numbers that lOS Help will
display, but it’s a good idea for
test day to know your common
port numbers. And I don’t mean
just the BCRAN test - I mean
any Cisco test. You should
know them by heart anyway,
but five minutes review before
any exam wouldn’t hurt. :)

Defining The Custom
Queue List By Applying
It To The Appropriate
Interface
To apply the custom queue to
an interface, use the customqueue-list command. To verify
the configuration, run show
queueing custom and show
queueing interface serialO.

Note that the latter command
shows all 17 queues, including
the control queue Queue Zero.

Queueing Summary
I know from experience that
keeping all of these queueing
strategies straight is tough
when you first start studying
them. I strongly advise you to
get some hands-on experience
configuring queueing, and
here’s a chapter summary to
help you keep them straight.
This summary is NOT a
substitute for studying the
entire chapter!
Weighted Fair Queueing (FlowBased)

No predefined limit on
the number of queues
Assigns weights to
traffic flows
Low-bandwidth,
interactive
transmissions are given
priority over highbandwidth
transmissions
The default queueing
strategy for physical
interfaces running at or
less than E1 speed,
AND that aren’t running
LAPB, SDLC, Tunnels,
Loopbacks, Dialer

Profiles, Bridges, Virtual
Interfaces, orX.25.
Priority Queueing
Four predefined queues
High priority queue
traffic is always sent
first, sometimes at the
expense of lower
queues whose traffic
may receive inadequate
attention
Not the default under
any circumstances,
must be manually
configured

A maximum of 64
classes can be defined
Custom Queueing
17 overall predefined
queues; Queue Zero is
used for network
control traffic and
cannot be configured to
carry other traffic,
leaving 16 configurable
queues
Uses a round-robin
transmission approach
A maximum of 64
classes can be defined

Not the default under
any circumstances,
must be manually
configured

Deciding On A Queueing
Strategy
The key to a successful
queueing rollout is planning.
Much like network design,
there’s no “one size fits all”
solution for queueing. This is
where your analytical skills
come in. You’re familiar with
the phrase “measure twice, cut

once”? You want to measure
your queueing strategy at least
twice before applying it on your
network!
This decision often comes down
to whether you’ve got voice
traffic on your network. If you
do, Priority Queueing is
probably your best choice. PQ
offers a queue (the High
queue) that will always offer
the highest priority to traffic but you must be careful and not
choke out traffic in the lower
queues at the expense of
priority traffic.

If there’s no delay-sensitive
traffic such as voice or video,
Custom Queueing works well,
since CQ allows you to
configure the size of each
queue as well as allocating the
maximum amount of bandwidth
each queue is allowed to use.
In comparison to PW and CQ,
Weighted Fair Queueing
requires no access-list
configuration to determine
priority traffic, because there
isn’t any priority traffic. Both
low-volume, interactive traffic
as well as higher-volume traffic

such as file transfers gets a fair
amount of bandwidth.

Link, Header, And
Payload Compression
Techniques
There are two basic
compression types we’re going
to look at in this section. First,
there’s link compression, which
compresses the header and
payload of a data stream, and
is protocol-independent. The
second is TCP/IP header

compression, and the name is
definitely the recipe.
When it comes to link
compression, we can choose
from Predictor or Stacker
(STAC). The actual operation of
these compression algorithms
is out of the scope of this
exam, but in short, the
Predictor algorithm uses a
compression dictionary to
predict the next set of
characters in a given data
stream. Predictor is easier on a
router’s CPU than other
compression techniques, but

uses more memory. In contrast,
Stacker is much harder on the
CPU than Predictor, but uses
less memory.
There’s a third compression
algorithm worth mentioning.
Defined in RFC 2118, the
Microsoft Point-To-Point
Compression makes it possible
fora Cisco router to send and
receive compressed data to and
from a MS client.
To use any of these
compression techniques, use
the compress interface-level

command followed by the
compression you want to use.
Your options depend on the
interface’s encapsulation type.
On a Serial interface using
HDLC encapsulation, stacker is
the only option.

Using PPP encapsulation on the
same interface triples our
options.

Keep in mind that the
endpoints of a connection using
link compression must agree on
the method being used.
Defined in RFC 1144, TCP/IP
Header Compression does just
what it says - it compresses the
TCP/IP header. Just as
obviously, it’s protocoldependent. This particular RFC
is very detailed, but it’s worth

reading, particularly the first
few paragraphs where it’s
noted that TCP/IP HC is truly
designed for low-speed serial
links.
TCP/IP HC is supported on
serial interfaces running HDLC,
PPP, or Frame Relay.
Configuring TCP/IP HC is
simple, but it’s got one
interesting option, shown below
with IOS Help.

If the passive option is

configured, the only way the
local interface will compress
TCP/IP headers before
transmission is if compressed
headers are already being
received from the destination.
Finally, if your network requires
the headers to remain intact
and not compressed, the
payload itself can be
compressed while leaving the
header alone. Frame Relay
allows this through the use of
the Frame Relay Forum.9,
referred to on the router as
FRF.9. This can be enabled on a

per-VC basis at the very end of
the frame map command. The
following configuration would
compress the payload of frames
sent to 172.12.1.1, but the
header would remain intact.

Choosing Between
TCP/IP HC And Payload
Compression
The main deciding factor here

is the speed of the link. If the
serial link is slow - and I mean
running at 32 kbps or less TCP/IP HC is the best solution
of the two. TCP/IP HC was
designed especially for such
slow links. By contrast, if the
link is running above 32 kbps
and less than T1 speed, Layer 2
payload compression is the
most effective choice.
What you don’t want to do is
run them both. The phrase
“unpredictable results” best
describes what happens if you
do. Troubleshooting that is a lot

more trouble than it’s ever
going to be worth. Choose L2
compression or TCP/IP HC in
accordance with the link speed,
and leave it at that.

Multicasting
Ever since you picked up your
first CCNA book, you’ve heard
about multicasting, gotten a
fair idea of what it is, and
you’ve memorized a couple of
reserved multicasting IP
addresses.
Now as you prepare to become
a CCNP, you’ve got to take that
knowledge to the next level

and gain a true understanding
of multicasting. Those of you
with an eye on the CCIE will
truly have to become
multicasting experts!
Having said that, we’re going to
briefly review the basics of
multicasting first, and then look
at the different ways in which
multicasting can be configured
on Cisco routers and switches.

What Is Multicasting?
A unicast is data that is sent

from one host directly to
another, while a broadcast is
data sent from a host that is
destined for “all” host
addresses. By “all”, we can
mean all hosts on a subnet, or
truly all hosts on a network.
There’s a bit of a middle ground
there! A multicast is that
middle ground, as a multicast is
data that is sent to a logical
group of hosts, called a
multicast group. Hosts that are
not part of the multicast group
will not receive the data.

Some other basic multicasting
facts:
There’s no limit on how
many multicast groups
a single host can

belong to.
The sender is usually
unaware of what host
devices belong to the
multicast group.
Multicast traffic is
unidirectional. If the
members of the
multicast group need to
respond, that reply will
generally be a unicast.
Expressed in binary, the
first four bits of a
multicast IP address are
1110.
The range of IP
addresses reserved for

multicasting is the Class
D range, 224.0.0.0 239.255.255.255.
The overall range of Class D
addresses contains several
other reserved address ranges.
The 224.0.0.0 - 224.0.0.255
range is reserved for network
protocols. Packets in this range
will not be forwarded by
routers, so these packets
cannot leave the local segment.
This block of addresses is the
local network control block.

Just as Class A, Class B, and
Class C networks have private
address ranges, so does Class
D. The Class D private address
range is 239.0.0.0 239.255.255.255. Like the
other private ranges, these
addresses can’t be routed, so
they can be reused from one
network to another. This block
of addresses is the
administratively scoped block.
These addresses are also called
limited scope addresses.
The 224.0.1.0 238.255.255.255 range is the

globally scoped address range,
and these addresses are
acceptable to assign to
internet-based hosts - with a
lot of exceptions.
Here are some other individual
reserved multicast addresses:
224.0.0.5 - All OSPF
Routers
224.0.0.6- All OSPF DRs
224.0.0.9- All RIPv2
routers
224.0.0.10 - All EIGRP
routers
224.0.0.12 - HSRPv2

224.0.1.1 - Network
Time Protocol (NTP)
224.0.0.1 - “All hosts”
224.0.0.2 - “All
multicast routers”
There are some individual
addresses in the Class D range
that you should not use. Called
unusable multicast addresses
or unstable multicast
addresses, there’s quite a few
of these and you should be
aware of them when planning a
multicast deployment. The
actual addresses are beyond
the scope of the CCNP SWITCH

exam, but you can find them
easily using your favorite
search engine.

The RPF Check
A fundamental difference
between unicasting and
multicasting is that a unicast is
routed by sending it toward the
destination, while a multicast is
routed by sending it away from
its source.
“toward the destination” and
“away from its source” sound

like the same thing, but they’re
not. A unicast is going to follow
a single path from source to
destination. The only factor the
routers care about is the
destination IP address - the
source IP address isn’t a factor.
With multicast routing, the
destination is a multicast IP
group address. It’s the
multicast router’s job to decide
which paths will lead back to
the source (upstream) and
which paths are downstream
from the source. Reverse Path
Forwarding refers to the

router’s behavior of sending
multicast packets away from
the source rather than toward a
specific destination.
The RPF Check is run against
any incoming multicast packet.
The multicast router examines
the interface that the packet
arrived on. If the packet comes
in on an upstream interface that is, an interface found on
the reverse path that leads
back to the source - the packet
passes the check and will be
forwarded.

If the packet comes in on any
other interface, the packet is
dropped.
Since we have multicast IP
addresses and multicast MAC
addresses, it follows that we’re
going to be routing and
switching multicast traffic. We’ll
first take a look at multicasting
from the router’s perspective.
Just as there are different
routing protocols, there are
different multicasting protocols.
The BSCI test focuses on
Protocol Independent Multicast

(PIM), so we’ll stick with that
one.
When a router runs a
multicasting protocol, a
multicast tree will be created.
The source sits at the top of
the tree, sending the multicast
stream out to the network. The
recipients are on logical
branches, and these routers
need to know if a downstream
router is part of the multicast
group. If there are no
downstream routers that need
the multicast stream, that
router will not forward the

traffic. This prevents the
network from being overcome
with multicast traffic.

In the above illustration, there
are three multicast group
members, each labeled “MG”. A
multicasting protocol will
prevent a router from sending
multicast traffic on a branch
where it’s not needed. The
middle branch of this multicast
tree has no member of the
multicast group, so multicast
traffic shouldn’t be sent down
that branch.
The left branch does have a
member at the edge, as does
the right branch, so traffic for
that multicast group will flow

all the way down those two
branches. The routers on the
multicast tree branches that
receive this traffic are referred
to as leaf nodes.
That’s all fine - but how does a
device join a multicast group in
the first place? That job is
performed by IGMP, the
Internet Group Management
Protocol. There are three
versions of IGMP in today’s
networks, and these three
versions have dramatic
differences in the way they
work.

IGMP Version 1
A host running IGMP v1 will
send a Membership Report
message to its local router,
indicating what multicast group
the host wishes to join. This
Membership Report’s
destination IP address will
reflect the multicasting group
the host wishes to join. (This
message is occasionally called
a Host Membership Report as
well.)

A router on every network
segment will be elected IGMPvl
Querier, and that router will
send a General Query onto the
segment every 60 seconds. If
there are multiple routers on
the segment, only one router
will fill this role, as there’s no
need for two routers to forward
the same multicast traffic onto

a segment. (Different protocols
elect an IGMPvl querier in
different ways, so there’s no
one way to make sure a given
router becomes the Querier
with v1.)

This query is basically asking
every host on the segment if
they’d like to join a multicast
group. These queries are sent
to the reserved multicast

address 224.0.0.1, the “allhosts on this subnet” address.
A host must respond to this
query with a Membership
Request under one of two
conditions:
The host would like to
join a group, OR
The host would like to
continue its
membership in a
multicast group it has
already joined!
That second bullet point means
that a host, in effect, must

renew a multicast group
membership every minute.
That’s a lot of renewing, and a
lot of Membership Requests
taking up valuable bandwidth
on that segment. In effect,
IGMPvl gives a host two ways
to join a multicast group:
Send a Membership
Report
Respond to a
Membership Request
The process for a host leaving a
multicast group isn’t much
more efficient. There is no

explicit “quit” message that a
host running IGMP v1 can send
to the router. Instead, the
host’s group membership will
time out when the router sees
no Membership Report for three
minutes.

In the above scenario, the host

was a member of a multicast
group, but stopped sending
Membership Reports two
minutes ago. The problem is
that the router will not age that
membership out for a total of
three minutes, so not only has
the router been unnecessarily
sending multicast traffic onto
this segment for the last two
minutes, but will continue doing
so for another minute before
finally aging out the multicast
group membership.
If it occurs to you that IGMPvl
could be a great deal more

efficient, you’re right. That’s
why IGMPv2 was developed!
A major difference between the
two is that IGMPv2 hosts that
wish to leave a group do not
just stop sending Membership
Reports, and there’s no threeminute wait to have the
membership age out. IGMPv2
hosts send a Leave Group
message to the reserved
multicast address

In return, the Querier will send
a group-specific query, which
will be seen by all hosts on the
segment. This query specifically
asks all hosts on the segment if
they would like to receive
multicast traffic destined for the

group the initial host left. If
another host wants to continue
to receive that traffic, that host
must send a Membership
Report back to the Querier.

If the Querier sends that groupspecific query and gets no
response, the Querier will stop
forwarding multicast traffic for

that group onto that segment.
An IGMPv2 Querier will send
out General Queries, just as
IGRPvl Queriers do.
Another major difference
between IGMPvl and v2 is that
there is a one- step way to
make a certain IGMPv2 router
become the Querier, and that’s
to make sure it has the lowest
IP address on the shared
segment.
As you’d expect, there are
some issues that arise when

you’ve got some hosts on a
segment running IGMPvl and
others running IGMPv2, or one
router running IGMPvl and
another router running IGMPv2.
The different scenarios are
beyond the scope of the exam,
but for those of you who’d like
to learn more about the
interoperability of the IGMP
versions (and especially if you’d
like to be a CCIE one day), get
a copy of RFC 2236 off the
Internet and start reading!
IGMP Version 3 is also now
available on many Cisco

devices. The major
improvement in IGMPv3 is
source filtering, meaning that
the host joining a multicast
group not only indicates the
group it wants to join, but also
chooses the source of the
multicast traffic. Multicast
group members sent IGMP v3
messages to 224.0.0.22. When
a host makes that choice
regarding the source of the
multicast stream, it can take
one of two forms:
“I will accept multicast
traffic from source x”

“I will accept multicast
traffic from any source
except source x”
If you’d like to do some
additional reading on any IGMP
version, here are the RFC
numbers:
IGMP vl: RFC 1112
IGMP v2: RFC 2236
IGMP v3: RFC 3376
Now that the hosts are using
IGMP to join the desired
multicast group, we’ve got to
get that traffic to them. For

that, we’ll use PIM - Protocol
Independent Multicast. There
are three modes of PIM you
must be fluent with to pass
theCCNP exams as well as two
different PIM versions. You’ll
see all these modes and
versions in production networks
as well, so it’s vital to
understand the concepts of all
of them.

PIM Dense Mode
Operation
The first decision to make when

implementing a multicasting
protocol is which one to
choose. PIM Dense is more
suited for the following
situations:
The multicast source
and recipients are
physically close
There will be few
senders, but many
recipients
All routers in the
network have the
capability to forward
multicast traffic
There will be a great

deal of multicast traffic
The multicast streams
will be constant
When PIM Dense is first
configured, a router will send a
Hello message on every PIMenabled interface to discover its
neighbors. Once a multicast
source begins transmitting, PIM
Dense will use the prune-andflood technique to build the
multicasting tree. Despite the
name, the flooding actually
comes first. The multicast
packets will be flooded
throughout the network until

the packets reach the leaf
routers.

The initial flooding ensures that
every router has a chance to
continue to receive multicast
traffic for that specific group. If

a leaf router has no hosts that
need this multicast group’s
traffic. the leaf router will send
a Prune message to the
upstream router. The Prune
message’s IP destination
address is 224.0.0.13.
The routers with hosts who
belong to this multicast group
are marked with “MG”. Since
none of the leaf routers know
of hosts who need this
multicast group’s traffic, they
will all send a Prune message
to 224.0.0.13.

If the upstream router receiving
the prune also has no hosts
that need this multicast group’s

traffic, that router will then
send a Prune to its upstream
neighbor as well. Here, the
router in the right-hand column
that is receiving a Prune from
its downstream neighbor knows
of no hosts that need the
traffic, so that router will send
a Prune upstream. In the other
two columns, the routers
receiving the Prune do have a
need for the multicast traffic, so
the pruning in those branches
stops there.

The router receiving that Prune
also knows of no hosts that are
members of this multicast

group, so -- you guessed it -that router will send a Prune to
the upstream router.

Logically, the multicast tree
now looks like this:

One branch of the tree has
been completely pruned, while
the leaf routers on the other
two branches have been

pruned. This group’s multicast
traffic will now only be seen by
these five routers.
The other routers were pruned
to prevent sending multicast
traffic to routers that didn’t
need that traffic flow, but what
if one of the pruned routers
later learns of a host that
needs to join that group? The
pruned router will then send a
Join message to its upstream
neighbor.

Where PIM Dense builds the
multicasting tree from the root
down to the branches, PIM
Sparse takes the opposite
approach. PIM Sparse builds
the multicast tree from the leaf
nodes up. PIM Dense creates a
source- based multicast tree,
since the tree is based around
the location of the multicast
traffic’s source. PIM Sparse
creates a shared multicast tree,
referring to the fact that
multiple sources can share the
same tree - “one tree, many
groups”.

PIM Sparse Mode is best suited
for the following situations:
The multicast routers
are widely dispersed
over the network
There are multiple,
simultaneous multicast
streams
There are few receivers
in each group
The multicast traffic will
be intermittent
The root of a PIM Sparse tree is
not even necessarily the source
of the multicasting traffic. A

PIM Sparse tree has a
Rendezvous Point (RP) for its
root. The RP serves as a kind of
“central distribution center”,
meaning that a shared tree will
create a single delivery tree for
a multicast group.
The routers discover the
location of the RP in one of
three different fashions.
Statically configuring
the RP’s location on
each router
Using an industrystandard bootstrap

protocol to designate
an RP and advertise its
location
Using the Ciscoproprietary protocol
Auto-RP to designate
an RP and advertise its
location
The shared tree creation begins
in the same fashion that a
source-based tree does - with a
host sending a Membership
Report to a router.

If there is already an entry in
the router’s multicast table for
224.1.1.1, the ethernet
interface shown here will be
added as an outgoing interface
for that group, and that’s it.
If there is no entry for
224.1.1.1, the router will send
a Join message toward the RP.

If the upstream router is the RP,
it will add the interface that
received the Join to the list of
outgoing interfaces for that
group; if the upstream router is
not the RP, it will send a Join of
its own toward the RP.
The three routers marked MG
have hosts that want to join
this particular multicast group,
and we’re assuming that the
multicast group is new, with no
prior neighbors. Note that one
router in the left column has no
hosts that want to join the
group, but it’s still sending a

Join message.

R2 has hosts that want to join
the multicast group 224.1.1.4.
R2 has no entry in its

multicasting table for this
group, so it sends a Join toward
the RP. R1 receives the Join,
checks its multicast table, and
sees it has no entries for
224.1.1.4. Even though R1 has
no hosts that need to join this
group, R1 will send a Join of its
own toward the RP. The RP
receives the Join message and
adds the interface upon which
the Join was received to the
outgoing multicast list for
224.1.1.4.
Sparse Mode uses Join
messages as keepalives as

well. They are sent every 60
seconds, and the membership
will be dropped if three hellos
are missed. To avoid
unnecessary transmission of
multicast traffic, the multicast
routers can send Prune
messages to end their
membership in a given
multicast group.
Using the same network setup
we used for the PIM Dense
example, we see that while the
operation of PIM Sparse is
much different - there is no
“flood-and-prune” operation -

the resulting multicast tree is
exactly the same.

PIM Sparse-Dense Mode
Many multicasting networks use
a combination of these two

methods, Sparse-Dense mode.
A more accurate name would
be “Sparse-Or- Dense” mode,
since each multicast group will
be using one or the other. If an
RP has been designated for a
group, that group will use
Sparse Mode. If there’s no RP
for a group, obviously Sparse
Mode is out, so that group will
default to Dense Mode.

RP Discovery Methods
It’s one thing to decide which
router should be the RP, but it’s

another to make sure all the
other routers know where the
RP is! The available methods
depend on the PIM version in
use.
PIM Version 1: Static
configuration or Auto-RP
PIM Version 2: Static
configuration, Auto-RP, or
bootstrapping, the open
standard method.
Let’s take a closer look at these
methods using the following
hub-and- spoke network,

beginning with the static
configuration method. All
routers are using their SerialO
interfaces on the 172.12.123.0
/24 network, with their router
number as the fourth octet.

Each router will have multicast
routing enabled with the ip
multicast- routing command.
Under the assumption that we
will not have many recipients,
we’ll configure these routers for
sparse mode. (If we had many
recipients, we’d use dense
mode.) All three routers will
have R1 configured as the RP.

The command show ip pim
neighbor verifies that PIM is
running and in Version 2 on all
interfaces.

Both R2 and R3 show R1 as the

RP for the multicast group
224.Q.1.4G, which is the RPDiscovery multicast group.

You don’t have to use the same
router as the RP for every
single multicasting group. An
access-list can be written to
name the specific groups that a
router should serve as the RP
for, and that access-list can be
called in the ip pim rp-address
command. You’ll see this
limitation configured on R1
only, but it would be needed on

R2 and R3 as well.

There’s one more option in the
ip pim rp-address command
you should note. See the
override option in the above
lOS Help readout? Using that
option will allow this static RP
configuration to override any
announcement made by AutoRP, Cisco’s proprietary method
of announcing RPs to multicast
routers running Sparse Mode.

(Auto-RP is now supported by
some non-Cisco vendors.)
And how do you configure AutoRP? Glad you asked!

Configuring Auto-RP
Auto-RP will have one router
acting as the mapping agent
(MA), and it is the job of this
router to listen to the multicast
address 224.0.1.39. It’s with
this address that routers
announce themselves as
candidate RPs (C-RP). The MA

listens to the candidate
announcements, and then
decides on a RP for each
multicast group. The MA then
announces these RPs on 224.0.
1.40 via RP-Announce
messages.
We’ll first configure R2 and R3
as candidate RPs. PIM Sparse is
already running on all three
routers’ serial interfaces and
multicasting has been enabled
on all three routers as well.

The scope value sets the TTL of
the RP-Announce messages.
Now that the candidate RPs are
configured, R1 will be
configured as the mapping
agent.

As multicast groups are added
to the network, both R2 and R3

will contend to be the RP by
sending their RP-Announce
messages on 224.0. 1.39. As
the mapping agent, R1 will
decide which router is the RP,
and will make that known via
RP-Discovery messages sent on
224.0.1.40.

Using The
Bootstrapping Method
PIM Version 2 offers a openstandard, dynamic method of
RP selection. If you’re working
in a multivendor environment

and want to avoid writing a
standard configuration, you
may need to use this method.
In the real world, I use Auto-RP
every chance I get. It’s just a
little more straightforward in
my opinion, but as I always say,
it’s a really good idea to know
more than one way to get
something done!
The bootstrap method’s
operation is much like Auto-RP,
but the terminology is much
different.

Candidate Bootstrap
Routers (C-BSRs) and
Candidate Rendezvous
Points (C-RPs) are
configured.
A Bootstrap Router
(BSR) is chosen from
the group of C-BSRs.
The BSR sends a
notification that the CRPs will hear, and the CRPs will send
Candidate-RPAdvertisements to the
BSR.
The BSR takes the
information contained

in these advertisements
and compiles the
information into an RPSet. The RP-Set is then
advertised to all PIM
speakers. The
destination multicast
address for bootstrap
messages is 224.0.0.13.

To configure R1 as a C-BSR:

To configure R2 and R3 as CRPs:

Handling Multicast
Traffic At Layer 2
Routers and Layer 3 switches
have the capability to make
intelligent decisions regarding
multicast traffic, enabling them
to create multicast trees and
avoid unnecessary transmission
of multicast streams. Layer 2
switches do not. One of the first
things you learn about Layer 2
switches in your CCNA studies
is that they handle multicast
traffic in the exact same way
they handle broadcasts - by
flooding that traffic out every

single port except the one the
traffic came in on.
That’s a very inefficient manner
of handling multicasting, so two
different methods of helping
Layer 2 switches with
multicasting have been
developed: IGMP Snooping and
CGMP, the Cisco Group
Membership Protocol.
So what is IGMP Snooping
“snooping” on? The IGMP
reports being sent from a host
to a multicast router. The
switch listens to these reports

and records the multicast
group’s MAC address and the
switch port upon which the
IGMP report was received. This
allows the switch to learn which
ports actually need the
multicast traffic, and will send it
only to those particular ports
instead of flooding the traffic.

IGMP Snooping is not supported
by all Cisco switch hardware
platforms, but is supported by
the 2950 and 3550 families by
default, as shown here on a
2950:

To turn IGMP snooping off, run
the command no ip igmp
snooping.

From experience, I can tell you
that one deciding factor
between IGMP Snooping and
CGMP is the switch’s processor
power. IGMP Snooping is best
suited for high-end switches
with CPU to spare. If CPU is an
issue, consider using CGMP.

Cisco Group
Membership Protocol
(CGMP)
If a Layer Two switch doesn’t
have the capabilities to run
IGMP Snooping, it will be able
to run CGMP - Cisco Group
Membership Protocol. (As long
as it’s a Cisco switch, that is CGMP is CIsco-proprietary!)
CGMP allows the multicast
router to work with the Layer
Two switch to eliminate
unnecessary multicast
forwarding.

CGMP will be enabled on both
the multicast router and the
switch, but the router’s going to
do all the work. The router will
be sending Join and Leave
messages to the switch as
needed. PIM must be running
on the router interface facing
the switch before enabling
CGMP, as you can see:

Let’s look at two examples of
when CGMP Join and Leave
messages will be sent, and to

where.

When CGMP is first enabled on
both the multicast router and
switch, the router will send a
CGMP Join message, informing
the switch that a multicast
router is now connected to it.
This particular CGMP Join will
contain a Group Destination
Address (GDA) of
0000.0000.0000 and the MAC

address of the sending
interface.
The GDA is used to identify the
multicast group, so when this is
set to all zeroes, the switch
knows this is an introductory
CGMP Join. This GDA lets the
switch know that the multicast
router is online.
The switch makes an entry in
its MAC table that a multicast
router can be found off the port
that the CGMP Join came in on.
The router will send this CGMP
Join to the switch every minute

to serve as a keepalive.

A workstation connected to port
0/5 now wishes to join
multicast group 225.1.1.1. The
Join message is sent to the
multicast router, but first it will
pass through the switch. The
switch will do what you’d
expect it to do - read the
source MAC address and make
an entry for it in the MAC

address table as being off port
fast 0/5 if there’s not an entry
already there. (Don’t forget
that the MAC address table is
also referred to as the CAM
table or the bridging table.)

The router will then receive the
Join request, and send a CGMP
Join back to the switch. This
CGMP Join will contain both the

multicast group’s MAC address
and the requesting host’s MAC
address. Now the switch knows
about the multicast group
225.1.1.1 and that a member of
that group is found off port fast
0/5.
In the future, when the switch
receives frames destined for
that multicast group, the switch
will not flood the frame as it
would an unknown multicast the switch will forward a copy
of the frame to each port that it
knows leads to a member of
the multicast group.

CGMP Leaves work much the
same way, but the router and
switch have to allow for the
possibility that there are still
other members on the switch
that still need that multicast
group’s traffic. In the following
example, two hosts that are
receiving traffic from the
multicast group 225.1.1.1 are
connected to the same switch.
One of the hosts is sending an
CGMP Leave. The multicast
router receives this request,
and in return sends a groupspecific CGMP query back to the

switch. The switch will then
flood this frame so hosts on
every other port receives a
copy. Any host that wishes to
continue to receive this group’s
traffic must respond to this
query.
As shown below, the remaining
host will send such a response,
and the router in turn will send
a CGMP Leave to the switch,
telling the switch to delete only
the host that originally sent the
CGMP Leave from the group.

If no other host responds to the
Group-Specific Query, the router
will still send a CGMP Leave to
the switch. However, the CGMP
Leave will tell the switch to
remove the entire group listing

from the MAC table.
You may be wondering how the
switch differentiates CGMP
Joins and Leaves from all the
other frames it processes. The
switch recognizes both of those
by their destination address of
01-00-0c-dd-dd-dd, a reserved
Layer 2 address used only for
this purpose.

Enabling CGMP
The additional configuration
needed to run CGMP depends

on the switch model.
On Layer 3 switches, CGMP is
disabled. CGMP is enabled at
the interface level with the
following command:

On Layer 2 switches, CGMP is
enabled by default.

Joining A Multicast
Group - Or Not!

After all this talk about dense,
sparse, and sparse-dense
mode, we need to get some
routers to actually join a
multicasting group! Before we
do, there are two command
that are close in syntax but far
apart in meaning, and we need
to have these two commands in
mind before starting the next
configuration.
The interface-level command ip
igmp join-group allows a router
to join a multicast group.
The interface-level command ip

igmp static-group allows a
router to forward packets for a
given multicast group, but the
router doesn’t actually accept
the packets.
In the following configuration,
R1 is the hub router of a huband-spoke configuration and
the RP for the multicast group
239.1.1.1. R2 and R3 will be
made members of this group.

We’ll configure R1 as the RP for
the group 239.1.1.1. Don’t
forget to enable multicasting on
the router before you begin the
interface configuration - the
router will tell you to do so, but

the exam probably will not!

We’ll verify the neighbor
relationships with show ip pim
neighbor.

We’ll also verify that R2 and R3
see R1 as the RP for 239.1.1.1

with show ip pim rp.

Ever wonder how you can test
whether routers have correctly
joined a multicast group?
Here’s an old CCIE lab trick ping the multicast IP address of
the group with the extended
ping command.

R1’s pings to 239.1.1.1 are
failing because there are no
members of that multicast
group. Let’s fix that by making
R2 and R3 members.

Let’s take a look at the
multicasting route table on R2
with show ip mroute.

This table is quite different
from the IP routing table we’re
used to, so let’s take a few
minutes to examine this table.
Note that there are two entries
for 239.1.1.1. The first is a
“star, group” entry. The star
(“*”) represents all source

addresses, while the “group”
indicates the destination
multicast group address. This
entry is usually referred to as
*,G in Cisco documentation.
The second entry is a
“Source,Group” entry, usually
abbreviated as S,G in technical
documentation. The Source
value is the actual source
address of the group, while the
Group is again the multicast
group address itself.
When spoken, the *,G entry is
called a “star comma G” entry;

the S,G entry is called a “S
comma G” entry.
Note the RPF neighbor entry
O.O.O.O for the
172.12.123.1,239.1.1.1 entry.
That will always be O.O.O.O
when you’re running sparse
mode, as we are here.
Also note that each entry has
some flags set. It couldn’t hurt
to know the meanings of some
of the more often-set flags:
D - Dense Mode entry

S - Sparse Mode entry
C - Connected, referring a
member of the group being on
the directly connected network
L - Local Router, meaning this
router itself is a member of the
group
P - Pruned, indicates the route
has been, well, pruned. :)
T - Shortest Path Tree,
indicates packets have been
received on the tree.
To wrap this up, let’s go back to

R1 and test this configuration.
We’ll send pings to 239.1.1.1
and see what the result is.

Both downstream members of
the multicast group 239.1.1.1
responded to the ping.
There are some other
commands you can use to
verify and troubleshoot
multicasting, one being show ip

pim interface.

Note the “DR” entry. On
multiaccess segments like the
one we’ve got here, a PIM
Designated Router will be
elected. The router with the
highest IP will be the DR. The
DR election is really more for
ethernet segments with more
than one router than for NBMA
networks like this frame relay
network. The PIM DR has two
major responsibilities:

Send IGMP queries onto
the LAN
If sparse mode is
running, transmit PIM
join and register
messages to the RP
You can verify IGMP group
memberships with show ip
igmp groups.

With video and voice traffic
becoming more and more
popular in today’s networks,
multicasting and Quality Of

Service (QoS) are going to
become more and more
important. I urge you to
continue your multicasting
studies after you earn your
CCNP, and for those of you with
your eyes on the big prize - the
CCIE - you’ll truly have to
become a multicasting master!

AAA
This is a bit of bonus reading
for your CCNP SWITCH exam.
This section from my CCNA
Security Study Guide covers
more AAA than you’re likely to
see on your CCNP SWITCH
exam, but I do recommend you
spend some time studying it to
go along with the Security
section in this course. Enjoy!

Authentication, Authorization,
and Accounting, commonly
referred to in the Cisco world as
AAA, is a common feature in
today’s networks. In this
section, we’ll examine exactly
what each “A” does, and then
configure AAA at the commandline interface and with Cisco
SDM.
Each “A” is a separate function,
and requires separate
configuration. Before we begin
to configure AAA, let’s take a
look at each “A” individually.

Authentication
Authentication is the process of
deciding if a given user should
be allowed to access the
network or a network service.
As a CCNA and future CCNP,
you’ve already configured
authentication in the form of
creating a local database of
usernames and passwords for
both Telnet access and PPP
authentication. This is
sometimes called a selfcontained AAA deployment,
since no external server is

involved.
It’s more than likely that you’ll
be using a server configured for
one of the following security
protocols:
TACACS+, a Ciscoproprietary, TCP-based
protocol
RADIUS, an openstandard, UDP-based
protocol originally
developed by the IETF
An obvious question is “If
there’s a TACACS+, what about

TACACS?” TACACS was the
original version of this protocol
and is rarely used today.
Before we head into AAA
Authentication configuration,
there are some other TACACS+
/ RADIUS differences you
should be aware of:
While TACACS+
encrypts the entire
packet, RADIUS
encrypts only the
password in the initial
client-server packet.
RADIUS actually

combines the
authentication and
authorization
processes, making it
very difficult to run one
but not the other.
TACACS+ considers
Authentication,
Authorization, and
Accounting to be
separate processes.
This allows another
method of
authentication to be
used (Kerberos, for
example), while still
using TACACS+ for

authorization and
accounting.
RADIUS does not
support the Novell
Async Services
Interface (NASI)
protocol, the NetBIOS
Frame Protocol Control
protocol, X.25 Packet
Assembler /
Disassembler (PAD), or
the AppleTalk Remote
Access Protocol (ARA or
ARAP). TACACS+
supports all of these.
RADIUS
implementations from

different vendors may
not work well together,
or at all.
RADIUS can’t control
the authorization level
of users, but TACACS+
can.
Regardless of which “A” you’re
configuring, AAA must be
enabled with the global
command aaa new-model. The
location of the TACACS+ and /
or RADIUS server must then be
configured, along with a shared
encryption key that must be
agreed upon by the client and

server. Since you’re on the way
to the CCNP, that’s what we’ll
use here.

The aaa new-model command
carries out two tasks:
enables AAA
overrides every
previously configured
authentication method
for the router lines especially the vty lines!

More on that “especially the vty
lines” a little later in this
section.
Multiple TACACS+ and RADIUS
servers can be configured, and
the key can either be included
at the end of the above
commands or separate from
that, as shown below.

Now comes the interesting
part! We’ve got a TACACS+
server at 172.1.1.1, a RADIUS
server at 172.1.1.2, and the

router is configured as a client
of both with a shared key of
CCNP for both. Now we need to
determine which servers will be
used for Authentication, and in
what order, with the aaa
authentication command. Let’s
take a look at the options:

The first choice is whether to
configure a named
authentication list, or a default
list that will be used for all
authentications that do not
reference a named list.

In this example, we’ll create a
default list.

Remember our old friend the
enable password? We can
configure Authentication to use
the enable password, and we
could also use a line password.
More common is the local
username authentication, which
will use a database local to the
router.
That sounds complicated, but

to build a username/password
database, just use the
username/password command!

The username /password
command creates a local
database that can be used for
multiple purposes, including
authenticating Telnet users. We
could create a local database
and use it for AAA
Authentication, but in this
example we’ll use the TACACS+
and RADIUS servers. To do so,
we need to drill a little deeper

with the aaa authentication
command.

The group radius and group
tacacs commands configure the
router to use those devices for
Authentication - but it’s
interesting that we were able
to configure more than one
Authentication source.

Actually, we can name a
maximum of four methods, and
they’ll be used in the order
listed. In the above command,
the default list will check the
RADIUS server first. If there’s
an error or a timeout, the
second method listed will be
checked.
If a user’s authentication is
refused by the first method, the
second method is not used, and
the user’s authentication
attempt will fail.
Interestingly enough, “none” is

an option with the aaa
authentication command.

If you’re concerned that all
prior listed methods of
authentication may result in an
error or timeout, you can
configure none at the end of
the aaa authentication
command.
Of course, if none is the only
option you select, you’ve
effectively disabled

authentication. Here, I’ve
configured a default list on R3
that is using only one
authentication option - none! I
then apply that list to the vty
lines and attempt to telnet to
R3 from R1.

Note that I was not prompted
for a vty password. Not a good
idea!

And speaking of bad ideas….

Be VERY Careful When
Configuring
Authentication - You
CAN Lock Yourself Out!
Sorry for all the yelling, but
believe me - if you put half of
the AAA authentication in
place, and log out without
finishing it, you can end up
locked out of your own router!
I’ll illustrate on a very basic
setup using R1 and R3.

These routers are directly
connected at their S1
interfaces, and R3 is configured
with a vty password of tuco. To
allow users to enter privilege
mode 15 (exec mode), we’ll
use an enable secret of CCNP.
No username is configured on
R3 for vty access, so when we
telnet to R3 from R1, we will be
prompted only for the vty
password. When we run the
enable command, we’ll be
prompted for the enable secret
password.

And all is well! Now we’ll start
configuring AAA on R3 via the
telnet connection. The first step
is to run the aaa new-model
command.

At this point, we’re interrupted
for some reason, so we save
the config on R3 before logging

out.

Once lunch --1 mean, the
interruption is over, we’ll log
back in to R3 from R1.

Hmm. We weren’t asked for a
username before. Let’s try both
the vty and enable passwords
for that username.

A couple of things to note…

One authentication attempt
timed out in the time it took
me to cut and paste that
config.
When a username/password
authentication attempt failed here, two of them did - we
were not told whether it was
the username, password, or
both that were bad.
Finally, we were denied access
to a router we could log into
before the interruption.

The problem here is that we’re
being asked for a username
that doesn’t actually exist!
Once you enable AAA, you’ve
got to define the authentication
methods immediately
afterwards. Right now, no one
can successfully telnet to that
router, and someone’s going to
have to connect to it via the
console port and finish the
configuration.
So let’s do just that. We’ve got
the aaa new-model command
in place, so we’ll now define a

local username/password
database and have that serve
as the default authentication
method. We’ll configure a
named list called AAA_LIST and
have R3’s vty lines use that list
for authentication.

Note that neither the vty line
password nor the enable
password are shown when
they’re entered. No asterisks,

no nothing!
It’s an excellent idea to leave
yourself a “back door” into the
network by configuring a local
database with only one
username and password - one
known only by you and perhaps
another administrator - and
ending the aaa authentication
command with local.
That way, if something happens
to the one or two primary
methods, you’ve always got an
emergency password to use.

Using AAA For
Privileged EXEC Mode
And PPP
The most common usage for
AAA Authentication is for login
authentication, but it can also
be used as the enable
password itself or to
authenticate PPP connections.
If you want to configure the
router to use AAA
Authentication for the enable
password, use the aaa
authentication enable
command. Note that you

cannot specify a named list for
the enable password, only the
default list.

The above configuration would
first look to the TACACS+
server to authenticate a user
attempting to enter privileged
EXEC mode, then the RADIUS
server, and then would finally
allow a user to enter with no
authentication needed.

To use AAA Authentication for
PPP connections, use the aaa
authentication ppp command.

The above command would
first look to the TACACS+
server to authenticate PPP
connections, then RADIUS, then
the router’s local database.

Why You Shouldn’t Stop
Configuring

Authentication Until
You’re Done!
Configuring authentication isn’t
a long process, but make sure
you’re not going to be
interrupted! (Or as sure as you
can be in our business.) If you
configure aaa new-model on a
router, you can no longer
configure a single VTY line
password, as shown below.

Now, you’d think this would
make the administrator realize
that they need to make a
default list - but then again,
maybe they don’t realize it.
Maybe they don’t know how
and don’t want to ask.
Maybe they headed for lunch.
It doesn’t matter, because the

end result is that no one can
telnet in with the router
configured like this. A method
list must be configured along
with the aaa new-model and
login authentication commands.
Before moving on to
Authorization, let’s review the
steps for an AAA configuration
using a TACACS+ server for
telnet authentication. First, we
have to enable AAA, define the
location of the TACACS+ server
and create the case-sensitive
key.

Next, create a default AAA
method list that uses TACACS+,
and will allow users to connect
with no authentication if there’s
a failure with TACACS+.

Apply the default AAA list to the
VTY lines, and we’re all set!

Authorization

Authentication decides whether
a given user should be allowed
into the network; Authorization
dictates what users can do
once they are in.
The aaa authorization
command creates a user profile
that is checked when a user
attempts to use a particular
command or service. As with
Authentication, we’ll have the
option of creating a default list
or a named list, and AAA must
be globally enabled with the
aaa new-model command.

Privilege Levels And
AAA Authorization
Privilege levels define what
commands a user can actually
run on a router. There are three
predefined privilege levels on
Cisco routers, two of which

you’ve been using since you
started your Cisco studies even if you didn’t know it!
When you’re in user exec
mode, you’re actually in
privilege level 1, as verified
with show privilege’.

By moving to privileged exec
mode with the enable
command, you move from level
1 to level 15, the highest level:

There’s actually a third
predefined privilege level, Level
Zero, which allows the user to
run the commands exit, logout,
disable, enable, and logout.
Obviously, a user at Level Zero
can’t do much.
There’s a huge gap in network
access between levels 1 and
15, and the remaining levels 214 can be configured to fill that

gap. Levels 2-14 can be
configured to allow a user
assigned a particular privilege
level to run some commands,
but not all of them.
Assume you have a user who
should not be allowed to use
the ping command, which by
default can be run from
privilege level 1:

By moving the ping command
to privilege level 5, a user must
have at least that level of
privilege in order to use ping.

To change the privilege level of
a command, use the privilege
command. (lOS Help shows
approximately 30 options
following privilege, so l won’t
put all of those here.)

A user must now have at least
a privilege level of 5 to send a

ping. Let’s test that from both
level 1 and 15.

Note that the user is not told
they’re being denied access to
this command because of
privilege level. The ping works
successfully from Level 15.
There are two options for
assigning privilege levels to
users, one involving AAA and
one not. To enable AAA
Authorization to use privilege

levels, use the aaa
authorization command
followed by the appropriate
option:

The full command to use the
TACACS+ server to assign
privilege levels, followed by the
local database, is as follows:

Getting authorization to work
exactly the way you want it to

does take quite a bit of
planning and testing due to the
many options.
Privilege levels can also be
assigned via the router’s local
database. To do so, use the
privilege option in the middle of
the username/password
command.

That would assign a privilege
level of 5 to that particular user.
The Authorization feature of
AAA can also assign IP

addresses and other network
parameters to Mobile IP users.
How this occurs is beyond the
scope of the ISCW exam, but
you can refer to RFC 2905 for
more details. Perhaps more
details than you’d like to know!

Accounting
Authentication decides who can
get in and who can’t;
authorization decides what
users can do once they get in;
accounting tracks the resources
used by the authorized user.

This tracking can be used for
security purposes (detecting
users doing things they
shouldn’t be doing), or for
tracking network usage in order
to bill other departments in
your company.
As with authentication and
authorization, accounting
requires that AAA be globally
enabled. The aaa accounting
command is used to define the
accounting parameters -- and
lOS Help shows us that there
are quite a few options!

Earlier in this section, we talked
about privilege lists, and
accounting can be configured to
track any given privilege level.
Even that seemingly simple
task takes a good deal of lOS
digging, as shown below.
Overall, AAA supports six
different accounting formats, as
shown below in lOS Help.

Here’s a brief look at each
category and what accounting
information can be recorded.
Commands: Information
regarding EXEC mode
commands issued by a user.
Connection: Information
regarding all outbound
connections made from
network access server. Includes

Telnet and rlogin.
EXEC: Information about user
EXEC terminal sessions.
Network: Information
regarding all PPP, ARAP, and
SLIP sessions.
Resource: Information
regarding start and stop
records for calls passing
authentication, and stop
records for calls that fail
authentication.
System: Non-user-related

system-level events are
recorded.
To finish the aaa accounting
command, let’s assume we
want to enable auditing of
privileged mode commands. As
IOS Help will show you, to do
this you have to know the level
number of the mode you wish
to audit, and privileged exec
mode is level 15.

Both authorization and
accounting offer so many
different options that it’s
impossible to go into all of
them here, and you’re not
responsible for complex
configurations involving either
one on your ISCW exam.

You should know the basic
commands and that AAA must
be globally enabled before
either can be configured. Also,
there are no enable, login, or
local options with accounting we’re limited to using TACACS+
and/or RADIUS servers for
accounting purposes.

Hot Spots And Gotchas
An AAA Authentication

statement generally has more
than one option listed. They’re
checked in the order in which
they are listed, from left to
right. If the first option is
unavailable, the next is
checked. However, if the first
option FAILS the user’s
authentication attempt, the
user is denied authentication
and the process ends.
If you enable AAA with the aaa
new-model command and then
do not complete the
Authentication configuration, no
one can authenticate.

It’s also legal to specify none as
the only authentication option,
but that basically disables
authentication!

You can use a named list with
aaa authentication login, but
not with aaa authentication
enable.

Real-world note that may come
in handy on exam day:

Don’t get too clever and name
your lists “AAA”. That tends to
confuse others. For example, in
the aaa authentication login
command, I would not use this
command:

That command uses a list
named “AAA” for
authentication. Again, it’s just
not something I like to do, but
it is legal.
What does each “A” mean?
Authentication - Can the user

come in?
Authorization - What can the
user do when they come in?
Can they assign privilege
levels? IP addresses? Delete
configurations? Assign ACLs?
Change the
username/password database,
perhaps?
Accounting - What network
resources did the user access,
and for how long?
The Accounting information
that can be recorded falls into

six main categories:
command - accounting
for all commands at a
specified privilege level
exec - accounting for
exec sessions
system - Non-user
system events, that is
network - All networkrelated service requests
(NCP, ARA, SLIP)
connection - outbound
connections (Telnet,
rlogin)
resource - stop and
start records

With accounting, we can save
information to RADIUS
orTACACS+ servers.

And finally, a quick RADIUS vs.
TACACS+ comparison:
RADIUS:
Open-standard protocol
Runs on UDP
Can’t control
authorization level of
users
Authentication and

authorization are
combined, so running a
separate authorization
protocol is not practical
TACACS+:
Cisco-proprietary
protocol
Runs on TCP
Can control
authorization level of
users
Authentication and
authorization are
separate processes, so
running a separate

authorization protocol is
possible

CCNP SWITCH Exam
Details You Must
Know!
Chris Bryant, CCIE #12933

VLANs:
Hosts in static VLANs inherit
their VLAN membership from
the port’s static assignment,
and hosts in dynamic VLANs are
assigned to a VLAN in
accordance with their MAC
address. This is performed by a
VMPS (VLAN Membership Policy
Server).

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.

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 they
must belong to all
VLANs. Trunking must
be disabled to make a
port a dynamic port.

It takes two commands to
configure a port to belong to a
single VLAN:

If two hosts can’t ping and

they’re in the same VLAN, there
are two settings you should
check right away. First, check
those speed and duplex
settings on the switch ports.
Second, check that MAC table
and make sure the hosts in
question have an entry in the
table to begin with.

ISL is Cisco-proprietary and
encapsulates every frame
before sending it across the
trunk. ISL doesn’t recognize the
native VLAN concept.

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, and such frames are
called giants. Frames less than
64 bytes are called runts.)

Dotlq does not encapsulate
frames. A 4-byte header is
added to the frame, resulting in
less overhead than ISL. If the

frame is destined for hosts
residing in the native VLAN,
that header isn’t added.

For trunks to work properly, the
port speed and port duplex
setting should be the same on
the two trunking ports.

Dotlq does add 4 bytes, but
thanks to IEEE 802.3ac, the
maximum frame length can be
extended to 1522 bytes.

To change the native VLAN:

The Cisco-proprietary Dynamic
Trunking Protocol actively
attempts to negotiate a trunk
line with the remote switch.
This sounds great, but there is
a cost in overhead - DTP
frames are transmitted every
30 seconds. To turn DTP off:

Is there a chance that two

ports that are both in one of
the three trunking modes will
not successfully form a trunk?
Yes - if they’re both in dynamic
auto mode.

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.

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.

VTP:
Place a switch into a VTP
domain with the global

command vtp domain.

In Server mode, a VTP switch
can be used to create, modify,
and delete VLANs. This means
that a VTP deployment has to
have at least one Server, or
VLAN creation will not be
possible. This is the default
setting for Cisco switches.

Switches running in Client
mode cannot be used to create,

modify, or delete VLANs. Clients
do listen for VTP
advertisements and act
accordingly when VTP
advertisements notify the Client
of VLAN changes.

Transparent VTP switches don’t
synchronize their VTP
databases with other VTP
speakers; they don’t even
advertise their own VLAN
information! Therefore, any
VLANs created on a
Transparent VTP switch will not
be advertised to other VTP

speakers in the domain, making
them locally significant only.

VTP advertisements carry a
configuration revision number
that enables VTP switches to
make sure they have the latest
VLAN information.

When you introduce a new
switch into a VTP domain, you
have to make sure that its
revision number is zero.

Theory holds that there are two
ways to reset a switch’s
revision number to zero:
1. Change the VTP
domain name to a
nonexistent
domain, then
change it back to
the original name.
2. Change the VTP
mode to
Transparent, then
change it back to
Server.

Reloading the switch won’t do
the job, because the revision
number is kept in NVRAM, and
the contents of Non-Volatile
RAM are kept on a reload.

Summary Advertisements are
transmitted by VTP servers
every 5 minutes, or upon a
change in the VLAN database.

Subset Advertisements are
transmitted by VTP servers
upon a VLAN configuration

change.

Configuring VTP Pruning allows
the switches to send broadcasts
and multicasts to a remote
switch only if the remote switch
actually has ports that belong
to that VLAN. This simple
configuration will prevent a
great deal of unnecessary
traffic from crossing the trunk.
All it takes is the global
configuration command vtp
pruning.

Real-world troubleshooting tip:
If you’re having problems with
one of your VLANs being able
to send data across the trunk,
run show interface trunk. Make
sure that all vlans shown under
“vlans allowed and active in
management domain” match
the ones shown under “vlans in
spanning tree forwarding state
and not pruned”. It’s a rarity,
but now you know to look out
for it!

As RIPv2 has advantages over
RIPv1, VTP v2 has several

advantages over VTPv1. VTPv2
supports Token Ring switching,
Token Ring VLANs, and runs a
consistency check. VTPvl does
none of these.

Cisco switches run in Version 1
by default, although most
newer switches are V2-capable.
If you have a V2-capable switch
such as a 2950 in a VTP domain
with switches running V1, just
make sure the newer switch is
running V1. The version can be
changed with the vtp version

command.

Spanning Tree Basics
Switches use their MAC address
table to switch frames, but
when a switch is first added to
a network, it has no entries in
its table. The switch will
dynamically build its MAC table
by examining the source MAC
address of incoming frames.

BPDUs are transmitted by a
switch every two seconds to
the multicast MAC address 0180-c2-00-00-00. We’ve actually
got two different BPDU types:
Topology Change
Notification (TCN)
Configuration
As you’d expect from their
name, TCN BPDUs carry
updates to the network
topology. Configuration BPDUs
are used for the actual STP
calculations.

The Root Bridge is the “boss” of
the switching network - this is
the switch that decides what
the STP values and timers will
be.

This BID is a combination of a
default priority value and the
switch’s MAC address, with the
priority value listed first. For
example, if a Cisco switch has
the default priority value of
32,768 and a MAC address of

11-22-3344-55-66, the BID
would be 32768:11-22-33-4455-66. Therefore, if the switch
priority is left at the default,
the MAC address is the deciding
factor.

Each potential root port has a
root port cost, the total cost of
all links along the path to the
root bridge. The BPDU actually
carries the root port cost, and
this cost increments as the
BPDU is forwarded throughout
the network.

The default STP Path Costs are
determined by the speed of the
port.
10 MBPS Port: 100
100 MBPS Port: 19
1 GBPS Port: 2
10 GBPS Port: 1
Be careful not to jump to the
conclusion that the physically
shortest path is the logically
shortest path.

Hello Time is the interval
between BPDUs, two seconds
by default.

Forward Delay is the length of
both the listening and learning
STP stages, with a default
value of 15 seconds.

Maximum Age, referred to by
the switch as MaxAge, is the
amount of time a switch will
retain a BPDU’s contents before
discarding it. The default is 20
seconds.

The value of these timers can
be changed with the spanningtree vlan command shown
below. The timers should
always be changed on the
root switch, and the
secondary switch as well.

There are two commands that
will make a non-root bridge the
root bridge for the specified
VLAN. If you use the root
primary command, the priority
will automatically be lowered
sufficiently for the local switch
to become the root. If you use
the vlan priority command, you
must make sure the priority is
low enough for the local switch
to become the root.

Ideally, the root bridge should
be a core switch, which allows
for the highest optimization of
STP.

Advanced Spanning
Tree
Suitable only for switch ports
connected directly to a single
host, PortFast allows a port
running STP to go directly from
blocking to forwarding mode.

What if the device connected to
a port is another switch? We
can’t use PortFast to shorten
the delay since these are
switches, not host devices.
What we can use is Uplinkfast.

Uplinkfast is pretty much
PortFast for wiring closets.
(Cisco recommends that
Uplinkfast not be used on
switches in the distribution and

core layers.)

Some additional details
regarding Uplinkfast:
The actual transition
from blocking to
forwarding isn’t really
“immediate” - it
actually takes 1 - 3
seconds.
Uplinkfast cannot be
configured on a root
switch.
When Uplinkfast is

enabled, it’s enabled
globally and for all
VLANs residing on the
switch. You can’t run
Uplinkfast on some
ports or on a per-VLAN
basis - it’s all or
nothing.

Uplinkfast will take immediate
action to ensure that the switch
cannot become the root switch.
First, the switch priority will be
set to 49,152, which means

that if all other switches are
still at their default priority,
they’d all have to go down
before this switch can possibly
become the root switch.
Additionally, the STP Port Cost
will be increased by 3000,
making it highly unlikely that
this switch will be used to reach
the root switch by any
downstream switches.

The Cisco-proprietary feature
BackboneFast can be used to

help recover from indirect link
failures. BackboneFast uses the
Root Link Query (RLQ) protocol.

Since all switches in the
network have to be able to
send, relay, and respond to RLQ
requests, and RLQ is enabled
by enabling BackboneFast,
every switch in the network
should be configured for
BackboneFast. This is done with
the following command:

Root Guard is configured at the
port level, and basically
disqualifies any switch that is
downstream from that port
from becoming the root or
secondary root.
Configuring Root Guard is
simple:

If any BPDU comes in on a port
that’s running BPDU Guard, the
port will be shut down and
placed into error disabled state,
shown on the switch as errdisabled.

UDLD detects unidirectional
links by transmitting a UDLD
frame across the link. If a UDLD
frame is received in return, that
indicates a bidirectional link,
and all is well. If a UDLD frame
is not received in return, the
link is considered unidirectional.

UDLD has two modes of
operation, normal and
aggressive. When a
unidirectional link is detected in
normal mode, UDLD generates
a syslog message but does not
shut the port down. In
aggressive mode, the port will
be put into error disabled state
(“err-disabled”) after eight
UDLD messages receive no
echo from the remote switch.

Loop Guard prevents a port
from going from blocking to
forwarding mode due to a
unidirectional link. Once the
unidirectional link issue is
cleared up, the port will come
out of loop-inconsistent state
and will be treated as an STP
port would normally be.

BDPU Skew Detection is strictly
a notification feature. Skew
Detection will not take action

to prevent STP recalculation
when BDPUs are not being
relayed quickly enough by the
switches, but it will send a
syslog message informing the
network administrator of the
problem.

Comparison of STP / RSTP post
states:
STP: disabled > blocking >
listening > learning >
forwarding

RSTP: discarding > learning >
forwarding

When a switch running RSTP
misses three BPDUs, it will
immediately begin the STP
recalculation process. Since the
default hello-time is 2 seconds
for both STP and RSTP, it takes
an RSTP-enabled switch only 6
seconds overall to determine
that a link to a neighbor has
failed. That switch will then age
out any information regarding
the failed switch.

When our old friend IEEE
802.1Q (“dot1q”) is the
trunking protocol, Common
Spanning Tree is in use. With
dotlq, all VLANs are using a
single instance of STP.

Per-VLAN Spanning Tree (PVST)
is just what it sounds like every VLAN has its own
instance of STP running.

Defined by IEEE 802.1s,
Multiple Spanning Tree gets its
name from a scheme that
allows multiple VLANs to be
mapped to a single instance of
STP, rather than having an
instance for every VLAN in the
network.

The switches in any MST region
must agree of the following:

1. The MST
configuration name
2. The MST instanceto-VLAN Mapping
table
3. The MST
configuration
revision number
If any of these three values are
not agreed upon by two given
switches, they are in different
regions.

Each and every switch in your

MST deployment must be
configured manually.

To map VLANs to a particular
MST instance:

Note that I could use commas
to separate individual VLANs or
use a hyphen to indicate a
range of them.

Networking Models
The core layer is the backbone
of your entire network, so we’re
interested in high-speed data
transfer and very low latency that’s it!

Today’s core switches are
generally multilayer switches switches that can handle both
the routing and switching of
data.

Advanced QoS is generally
performed at the core layer.

Not only do the distributionlayer switches have to have
high-speed ports and links,
they’ve got to have quite a few
to connect to both the access
and core switches. That’s one
reason you’ll find powerful
multilayer switches at this layer
- switches that work at both L2
and L3.

End users communicate with
the network at the Access layer.
VLAN membership is handled at
this layer, as well as traffic
filtering and basic QoS.
Collision domains are also
formed at the access layer.

A good rule of thumb for access
switches is “low cost, high
switchport-to- user ratio”. Don’t
assume that today’s sufficient

port density will be just as
sufficient tomorrow!

Switch blocks are units of
access-layer and distributionlayer devices.

Core blocks consist of the highpowered core switches, and
these core blocks allow the
switch blocks to communicate.

Dual core is a network design
where the switch blocks have
redundant connections to the
core block. The point at which
the switch block ends and the
core block begins is very clear.

In a collapsed core, there is no
dedicated core switch. The
distribution and core switches
are the same.

AAA servers, syslog servers,
network monitoring tools, and
intruder detection tools are
found in almost every campus
network today. All of these
devices can be placed in a
switch block of their own, the
network management block.

The Enterprise Edge Block
works with the Service Provider
Edge Block to bring WAN and
Internet access to end users.

To configure port autorecovery
from err-disabled state, define
the causes of this state that
should be recovered from
without manual intervention,
then enter the duration of the
port’s err-disabled state in
seconds with the following
commands:

Etherchannels
Spanning-Tree Protocol (STP)
considers an Etherchannel to be
one link. If one of the physical
links making up the logical
Etherchannel should fail, there
is no STP reconfiguration, since
STP doesn’t know the physical
link went down.

There are two protocols that
can be used to negotiate an
etherchannel. The industry
standard is the Link

Aggregation Control Protocol
(LACP), and the Ciscoproprietary option is the Port
Aggregation Protocol (PAgP).

PAgP and LACP use different
terminology to express the
same modes. PAgP has a
dynamic mode and auto mode.
LACP uses active and passive
modes, where active ports
initiate bundling and passive
ports wait for the remote
switch to do so.

To select a particular
negotiation protocol, use the
channel-protocol command.

The channel-group command is
used to place a port into an
etherchannel.

Ports bundled in an
Etherchannel need to be
running the same speed,
duplex, native VLAN, and just
about any other value you can
think of! If you change a port
setting and the EC comes
down, you know what to do change the port setting back!

QOS
The three basic reasons for
configuring QoS are delays in
packet delivery, unacceptable
levels of packet loss, and jitter
in voice and video traffic. Of
course, these three basic
reasons have about 10,000
basic causes! ;)

Best-effort is just what it
sounds like - routers and
switches making their “best
effort” to deliver data. This is

considered QoS, but it’s kind of
a “default QoS”. Best effort is
strictly “first in, first out”
(FIFO).

Integrated Services is much like
the High-Occupancy Vehicle
lanes found in many larger
cities. If your car has three or
more people in it, you’re
considered a “priority vehicle”
and you can drive in a special
lane with much less congestion
than regular lanes. Integrated
Services will create this lane in

advance for “priority traffic”,
and when that traffic comes
along, the path already exists.

Integrated Services uses the
Resource Reservation Protocol
(RSVP) to create these paths.
RSVP guarantees a quality rate
of service, since this “priority
path” is created in advance.
With Differentiated Services
(DiffServ), there are no
advance path reservations and
there’s no RSVP. The QoS

policies are written on the
routers and switches, and they
take action dynamically as
needed.
Since each router and switch
can have a different QoS policy,
DiffServ takes effect on a perhop basis rather than the perflow basis of Integrated
Services. A packet can be
considered “high priority” by
one router and “normal priority”
by the next.

Layer 2 switches have a Class
Of Service field that can be
used to tag a frame with a
value indicating its priority. The
limitation is that a switch can’t
perform CoS while switching a
frame from one port to another
port on the same switch. If the
source port and destination
port are on the same switch,
QoS is limited to best-effort
delivery. CoS can tag a frame
that is about to go across a
trunk.

Classification is performed
when a switch examines the
kind of traffic in question and
comparing it against any given
criterion, such as an ACL.

The point in your network at
which you choose not to trust
incoming QoS values is the
trust boundary. The process of
changing an incoming QoS
value with another value is
marking.

Placing the traffic into the
appropriate egress queue, or
outgoing queue, is what
scheduling is all about.

Tail Drop is aptly named,
because that’s what happens
when the queue fills up. The
frames at the head of the
queue will be transmitted, but
frames coming in and hitting
the end of the line are dropped,
because there’s no place to put

them.

Random Early Detection (RED)
does exactly what the name
says - it detects high
congestion early, and randomly
drops packets in response. This
will inform a TCP sender to
slow down. The packets that
are dropped are truly random,
so while congestion is avoided,
RED isn’t a terribly intelligent
method of avoiding congestion.

WRED will use the CoS values
on a switch and the IP
Precedence values on a router
to intelligently drop frames or
packets. Thresholds are set for
values, and when that
threshold is met, frames with
that matching value will be
dropped from the queue.

Both RED and WRED are most
effective when the traffic is
TCP-based, since both of these

QoS strategies take advantage
of TCP’s retransmission
abilities.

Enabling QoS on a switch is
easy enough:

Basic steps to creating and
applying a QoS policy:

1. Use an ACL to
define the traffic to
be affected by the
policy.
2. Write a class-map
that calls the ACL.
3. Write a policy-map
that calls the classmap and names the
action to be taken
again the matching
traffic.
4. Apply the policymap with the
service-policy
command.

Traffic should generally be
classified and marked at the
Access layer.
Low Latency Queuing (LLQ) is
an excellent choice for core
switches. The name says it all low latency!
Weighted Fair Queuing gives
priority to low-volume traffic,
and high- volume traffic shares
the remaining bandwidth.

Multilayer Switching
Multilayer switches are devices
that switch and route packets
in the switch hardware itself.

The first multilayer switching
(MLS) method is route caching.
This method may be more
familiar to you as NetFlow
switching. The routing
processor routes a flow’s first
packet, the switching engine
snoops in on that packet and
the destination, and the

switching engine takes over
and forwards the rest of the
packets in that flow.

A flow is a unidirectional
stream of packets from a
source to a destination.

Cisco Express Forwarding (CEF)
is a highly popular method of
multilayer switching. Primarily
designed for backbone

switches, this topology-based
switching method requires
special hardware, so it’s not
available on all L3 switches.

CEF-enabled switches keep a
Forwarding Information Base
(FIB) that contains the usual
routing information - the
destination networks, their
masks, the next-hop IP
addresses, etc - and CEF will
use the FIB to make L3 prefixbased decisions. The FIB’s
contents will mirror that of the

IP routing table.

The FIB takes care of the L3
routing information, but what of
the L2 information we need?
That’s found in the Adjacency
Table (AT).

On an MLS, a logical interface
representing a VLAN is
configured like this:

You need to create the
VLAN before the SVI,
and that VLAN must be
active at the time of
SVI creation
Hosts in that SVI’s VLAN
should use this address
as their gateway.
Remember that the
VLAN and SVI work
together, but they’re
not the same thing.
Creating a VLAN doesn’t
create an SVI, and
creating an SVI doesn’t

create a VLAN.

The ports on multilayer
switches are going to be
running in L2 mode by default,
so to assign an IP address and
route on such a port, it must be
configured as an L3 port with
the no switchport command.

To put a port back into
switching mode, use the
switchport command.

CEF has a limitation in that IPX,
SNA, LAT, and AppleTalk are
either not supported by CEF or,
in the case of SNA and LAT, are
nonroutable protocols. If you’re

running any of these on an CEFenabled switch, you’ll need
fallback bridging to get this
traffic from one VLAN to
another.
Defined in RFC 2281, HSRP is a
Cisco-proprietary protocol in
which routers are put into an
HSRP router group.
One of the routers will be
selected as the primary, and
that primary will handle the
routing while the other routers
are in standby, ready to handle
the load if the primary router

becomes unavailable.
The MAC address OO-OO-Oc07-ac-xx is reserved for HSRP,
and xx is the group number in
hexadecimal.
On rare occasions, you may
have to change the MAC
address assigned to the virtual
router. This is done with the
standby mac-address
command.

The following configuration
configures an HSRP router for

interface tracking. The router’s
HSRP priority will drop by 1O
(the default decrement) if the
line protocol on SerialO goes
down.

Defined in RFC 2338, VRRP is
the open-standard equivalent
of HSRP. VRRP works very much
like HSRP, and is suited to a
multivendor environment.

As with HSRP and VRRP, GLBP
routers will be placed into a
router group. However, GLBP
allows every router in the group
to handle some of the load,
rather than having a primary
router handle all of it while the
standby routers remain idle.

The Active Virtual Gateway
(AVG) in the group will send
requesting hosts ARP responses

containing virtual MAC
addresses. The virtual MAC
addresses are assigned by the
AVG as well, to the AVFs Active Virtual Forwarders.

To add a server’s IP address to
a server farm:

To create the virtual server for
the server farm:

Switch Security
A local database of passwords
is just one method of
authenticating users. We can
also use RADIUS servers
(Remote Authentication Dial-In
User Service, a UDP service) or

TACACS+ servers (Terminal
Access Controller Access
Control System, a TCP service).
To enable AAA on a switch:

Port security uses a host’s MAC
address for authentication.

The number of secure MAC
addresses defined here includes
static and dynamically learned
addresses.

One major difference between
dot1x port-based
authentication and port security
is that both the host and switch
port must be configured for
802.1x EAPOL (Extensible
Authentication Protocol over
LANs).
Until the user is authenticated,
only the following protocols can
travel through the port:
EAPOL

Spanning-Tree Protocol
Cisco Discovery
Protocol
By default, once the user
authenticates, all traffic can be
received and transmitted
through this port.
To configure dot1x, AAA must
first be enabled.

SPAN allows the switch to
mirror the traffic from the
source port(s) to the

destination port, the
destination port being the port
to which the network analyzer
is attached.
Local SPAN occurs the
destination and source ports
are all on the same switch. If
the source was a VLAN rather
than a collection of physical
ports, VLAN-based SPAN
(VSPAN) would be in effect.
RSPAN (Remote SPAN) is
configured when source and
destination ports are found on
different switches.

The command monitor session
will start a SPAN session, along
with allowing the configuration
of the source and destination.
SPAN Source port notes:
A source port can be
monitored in multiple
SPAN sessions.
A source port can be
part of an Etherchannel.
A source port cannot
then be configured as a
destination port.
A source port can be
any port type -

Ethernet, FastEthernet,
etc.
SPAN Destination port notes:
A destination port can
be any port type.
A destination port can
participate in only one
SPAN session.
A destination port
cannot be a source
port.
A destination port
cannot be part of an
Etherchannel.
A destination port

doesn’t participate in
STP, CDP, VTP, PaGP,
LACP, or DTP.

To filter traffic between hosts in
the same VLAN, we’ve got to
use a VLAN Access List (VACL).
A sample configuration follows:

Dot1q tunneling allows a
service provider to transport
frames from different
customers over the same
tunnel - even if they’re using
the same VLAN numbers. This
technique also keeps customer
VLAN traffic segregated from
the service provider’s own VLAN
traffic.
The configuration is very
simple, and needs to be
configured only on the service
provider switch ports that are
receiving traffic from and
sending traffic to the customer

switches.

The service provider switches
will accept CDP frames from
the customer switches, but will
not send them through the
tunnel to the remote customer
site. Worse, STP and VTP
frames will not be accepted at
all, giving the customer a
partial (and inaccurate) picture
of its network.
To tunnel STP, VTP, and CDP

frames across the services
provider network, a Layer 2
Protocol Tunnel must be built.

Voice VLANs
As is always the case with voice
or video traffic, the key here is
getting the voice traffic to its
destination as quickly as
possible in order to avoid jitter
and unintelligible voice
streams. The human ear will
only accept 140 -150
milliseconds of delay before it

notices a problem with voice
delivery. That means we’ve got
that amount of time to get the
voice traffic from Point A to
Point B.
802.1p is a priority
tagging scheme that
grants voice traffic a
high priority. All voice
traffic will go through
the native voice VLAN,
VLAN 0.
802.1q will carry traffic
in a VLAN configured
especially for the voice
traffic. This traffic will

have a CoS value of 2.

Some Voice VLAN commands
and their options:

To configure the phone to
accept the CoS values coming
from the PC:

To configure the phone not to
trust the incoming CoS value:

We can also make this trust
conditional, and trust the value
only if the device on the other
end of this line is a Cisco IP
phone.

If you configure that command

and show mls qos interface
indicates the port is not
trusted, most likely there is no
IP Phone connected to that
port. Trust me, I’ve been there.
:)

Performing
Hexadecimal
Conversions
Cisco certification candidates,
from the CCNA to the CCIE,
must master binary math. This
includes basic conversions, such
as binary-to-decimal and
decimal-to-binary, as well as
more advanced scenarios
involving subnetting and VLSM.

Newcomers to hexadecimal
numbering are often confused
as to how a letter of the
alphabet can possibly represent
a number. Worse, they may be
intimidated - after all, there
must be some incredibly
complicated formula involved
with representing the decimal
11 with the letter “b”, right?

Wrong.
The numbering system we use
every day, decimal, concerns
itself with units of ten. Although

we rarely stop to think of it this
way, if you read a decimal
number from right to left, the
number indicates how many
units of one, ten, and one
hundred we have. That is, the
number “15” is five units of one
and one unit of ten. The
number “289” is nine units of
one, eight units of ten, and two
units of one hundred. Simple
enough!
Units Units Units
Of 100 Of 10 Of 1
The
decimal

0

1

5

“15”
The
decimal
“289”

2

8

9

Hex numbers are read much
the same way, except the units
here are units of 16. The
number “15” in hex is read as
having five units of one and
one unit of sixteen. The
number “289” in hex is nine
units of one, eight units of
sixteen, and two units of 256
(16 x 16).
Units

Units

Of Units Of 1
256 Of 16
The hex
numeral
“15”
The hex
numeral
“289”

0

1

5

2

8

9

Since hex uses units of sixteen,
how can we possibly represent
a value of 10, 11, 12, 13, 14, or
15? We do so with letters. The
decimal “10” is represented in
hex with the letter “a”; the
decimal 11 with “b”; the

decimal “12” with “c”, “13” with
“d”, “14” with “e”, and finally,
“15” with “f”. (Remember that a
broadcast.) MAC address of
“ffff.ffff.ffff” is a Layer 2
broadcast.)

Practice Your
Conversions For Exam
Success
Now that you know where the
letters fall into place in the
hexadecimal numbering world,
you’ll have little trouble
converting hex to decimal and

decimal to hex - if you practice.
How would you convert the
decimal 27 to hex? You can see
that there is one unit of 16 in
this decimal; that leaves 11
units of one. This is
represented in hex with “1b” one unit of sixteen, 11 units of
one.

Work From Left To
Right To Perform
Decimal - Hexadecimal
Conversions.

Units Units Units Hexad
of
of 16 of 1 Value
256
Decimal
Number 0
“27”

1

B(11) 1b

Converting the decimal 322 to
hex is no problem. There is one
unit of 256; that leaves 66.
There are four units of 16 in 66;
that leaves 2, or two units of
one. The hex equivalent of the
decimal 322 is the hex figure
142 - one unit of 256, four units
of 32, and 2 units of 2.

Units Units Units Hexad
of
of 16 of 1 Value
256
Decimal
Number 1
“322”

4

2

142

Hex-to-decimal conversions are
even simpler. Given the hex
number 144, what is the
decimal equivalent? We have
one unit of 256, four units of
16, and four units of 4. This
gives us the decimal figure 324.

Units Units Units D
of
of 16 of 1 Va

256
Hexadecimal
Number
1
“144”

4

4

25
64
=

What about the hex figure c2?
We now know that the letter
“c” represents the decimal
number “12”. This means we
have 12 units of 16, and two
units of 2. This gives us the
decimal figure 194.

Units
Units Units D
of
of 16 of 1 va
256
Hexadecimal

Number “c2” 0

12

2

I have written 20 practice
questions that will help you
practice your hexadecimal
conversion skills. Once you
practice with these questions,
and know exactly how each
answer was arrived at, you’ll
have no problem with
hexadecimal conversions on
your Cisco exams.
Best of luck!
To your success,

19

Chris Bryant, CCIETM #12933
1. Convert the following
hexadecimal number to
decimal: 1c
2. Convert the following
hexadecimal number to
decimal: f1
3. Convert the following
hexadecimal number to
decimal: 2a9
4. Convert the following
hexadecimal number to
decimal: 14b
5. Convert the following
hexadecimal number to
decimal: 3e4

6. Convert the following
decimal number to
hexadecimal: 13
7. Convert the following
decimal number to
hexadecimal: 784
8. Convert the following
decimal number to
hexadecimal: 419
9. Convert the following
decimal number to
hexadecimal: 1903
10. Convert the following
decimal number to
hexadecimal: 345
11. Convert the following
hex number to binary: 42

12. Convert the following
hex number to binary: 12
13. Convert the following
hex number to binary: a9
14. Convert the following
hex number to binary: 3c
15. Convert the following
hex number to binary: 74
16. Convert the following
binary string to hex:
00110011
17. Convert the following
binary string to hex:
11001111
18. Convert the following
binary string to hex:
01011101

19. Convert the following
binary string to hex:
10011101
20. Convert the following
binary string to hex:
11010101
Before we go through the
answers and how they were
achieved, let’s review the
meaning of letters in
hexadecimal numbering:
A = 10, B = 11, C = 12, D =
13, E = 14, F = 15. (And
remember that ffff.ffff.ffff is a
Layer 2 broadcast !)

Conversions involving
hexadecimal numbers will use
this chart:
256 16 1

1. Convert the following
hexadecimal number to
decimal: 1c

There is one unit of 16 and
twelve units of 1. 16 + 12 =

28.

2. Convert the following
hexadecimal number to
decimal f1

There are fifteen units of 16
and 1 unit of 1.
240 + 1 = 241

3. Convert the following
hexadecimal number to

decimal 2a9

There are two units of 256,
ten units of 16, and nine units
of 1.
512 + 160 + 9 = 681

4. Convert the following
hexadecimal number to
decimal 14b

There is one unit of 256, four
units of 16, and 11 units of 1.
256 + 64 + 11 = 331

5. Convert the following
hexadecimal number to
decimal 3e4

There are three units of 256,
fourteen units of 16, and four
units of 1.
768 + 224 + 4 = 996

6. Convert the following
decimal number to
hexadecimal: 13
When converting decimal to
hex, work with the same chart
from left to right. Are there any
units of 256 in the decimal 13?
No.

Are there any units of 16 in
the decimal 13? No.

Are there any units of 1 in the
decimal 13? Sure. Thirteen of
them. Remember how we
express the number “13” with a
single hex character?

The answer is “d”. It’s not
necessary to have any leading
zeroes when expressing the
number.

7. Convert the following
decimal number to

hexadecimal: 784
Are there any units of 256 in
the decimal 784? Yes, three of
them, for a total of 768. Place a
“3” in the 256 slot, and subtract
768 from 784.

784 - 768 = 16
Obviously, there’s one unit of 16
in 16. Since there is no
remainder, we can place a “0”
in the remaining slots.

The final result is the hex
number “310”.

8. Convert the following
decimal number to
hexadecimal: 419
Are there any units of 256 in
the decimal 419? Yes, one, with
a remainder of 163.

Are there any units of 16 in the
decimal 163? Yes, ten of them,
with a remainder of three.

Three units of one takes care of
the remainder, and the hex
number “1a3” is the answer.

9. Convert the following
decimal number to
hexadecimal: 1903
Are there any units of 256 in
the decimal 1903? Yes, seven
of them, totaling 1792. This

leaves a remainder of 111.

Are there any units of 16 in the
decimal 111? Yes, six of them,
with a remainder of 15.

By using the letter “f” to
represent 15 units of 1, the
final answer “76f” is achieved.

10. Convert the following
decimal number to
hexadecimal: 345
Are there any units of 256 in
345? Sure, one, with a
remainder of 89.

Are there any units of 16 in 89?
Yes, five of them, with a
remainder of 9.

Nine units of nine give us the
hex number “159”.

11. Convert the following hex
number to binary: 42
First, convert the hex number
to decimal. We know “42” in
hex means we have four units
of 16 and two units of 1. Since

64 + 2 = 66, we have our
decimal.
Now we’ve got to convert that
decimal into binary. Here’s our
chart showing how to convert
the decimal 66 into binary:

12. Convert the following hex
number to binary: 12
First, convert the hex number
to decimal. The hex number

“12” indicates one unit of
sixteen and two units of one; in
decimal, this is 18.
Now to convert that decimal
into binary. Use the same chart
we used in Question 11:

13. Convert the following hex
number to binary: a9

First, convert the hex number
to decimal. Since “a” equals 10
in hex, we have 10 units of 16
and nine units of 1. 160 + 9 =
169
Now convert the decimal 169 to
binary:

14. Convert the following hex
number to binary: 3c

First, convert the hex number
to decimal. We have three units
of 16 and 12 units of 1 (c =
12), giving us a total of 60 (48
+ 12).
Convert the decimal 60 into
binary:

15. Convert the following hex
number to binary: 74

First, convert the hex number
to decimal. We have seven
units of 16 and four units of 1,
resulting in the decimal 116
(112 + 4).
Convert the decimal 116 into
binary:

The correct answer: 01110100

16. Convert the following
binary string to hex:

00110011
First, we’ll convert the binary
string to decimal:

To finish answering the
question, convert the decimal
51 to hex. Are there any units
of 256 in the decimal 51? No.
Are there any units of 16 in the
decimal 51? Yes, three, for a
total of 48 and a remainder of
three. Three units of one gives
us the hex number “33”.

17. Convert the following
binary string to hex:
11001111
First, we’ll convert the binary
string to decimal:

Now convert the decimal 207 to
hex. Are there any units of 256
in the decimal 207? No. Are
there any units of 16 in the
decimal 207? Yes, twelve of

them, for a total of 192 and a
remainder of 15. Twelve is
represented in hex with the
letter “c”. Fifteen units of one
are expressed with the letter
“f”, giving us a hex number of
“cf”.

18. Convert the following
binary string to hex:
01011101
First, convert the binary string
to decimal:

Now convert the decimal 93 to
hex. There are no units of 256,
obviously. How many units of
16 are there? Five, for a total of
80 and a remainder of 13. We
express the number 13 in hex
with the letter “d”. The final
result is the hex number “5d”.

19. Convert the following
binary string to hex:
10011101

As always, convert the binary
string to decimal first:

Now convert the decimal 157 to
hex. There are no units of 256.
How many units of 16 are there
in the decimal 157? Nine, for a
total of 144 and a remainder of
13. You know to express the
number 13 in hex with the
letter “d”, resulting in a hex
number of “9d”.

20. Convert the following
binary string to hex:
11010101
First, convert the binary string
to decimal:

Now convert the decimal 213 to
hex. No units of 256, but how
many of 16? Thirteen of them,
with a total of 208 and a
remainder of 5. Again, the

number 13 in hex is
represented with the letter “d”,
and the five units of one give
us the hex number “d5”.

Command Reference
VLANs

show vlan is the full command

to see information regarding all
VLANs on the switch, including
some reserved ones you
probably aren’t using.

show vlan brief gives you the
information you need to
troubleshoot any VLAN-related
issue, but limits the information
shown on the reserved VLANs.

switchport nonegotiate turns
DTP frames off, but the port
must be hardcoded for trunking
to do so.

switchport mode access and
switchport access vlan x work
together to place a port into a
VLAN. The first command
prevents the port from
becoming a trunk port, and the
second command is a static
vlan assignment.

switchport trunk allowed vlan is
used to disallow or allow VLANs

from sending traffic across the
trunk, as shown with the below
lOS Help readout.

switchport trunk encapsulation
is used to define whether ISL or
dot1q will be used on the trunk.

switchport trunk native vlan x is
used to change the native VLAN

of the trunk. This should be
agreed upon by both endpoints.
Be prepared to see an error
message while you’re changing
this, as shown below.

VTP
show vtp counters displays the
number of different VTP
advertisements send and
received by the switch.

show vtp status displays just
about anything you need to
know about your VTP domain,
including domain name and
revision number.

vtp domain is used to define

the VTP domain.

vtp mode is used to define the
switch as a VTP Server, Client,
or as running in Transparent
mode.

To configure VTP in secure
mode, set a password on all
devices in the VTP domain with
vtp password. Verify with show
vtp password.

Enable VTP pruning with vtp
pruning, and check the VTP
version with vtp version.

Basic Spanning Tree
show spanning tree interface x
will display the STP settings for
an individual port.

Advanced Spanning
Tree
Portfast can be enabled on the
interface level or globally with
the spanning-tree portfast and
spanning portfast default
commands.

Below, you’ll see how to enable

the STP features Uplinkfast,
Backbonefast, Root Guard,
BPDU Guard, Loop Guard, and
UDLD. Several important
options are also shown. You
must know these commands
and exactly what they do.

To enable Multiple Spanning
Tree:

Basic Switch Operation

Create an SVI on an L3 switch:

Configure the switch’s VTY lines
to accept Secure Shell
connections:

Use the interface-range
command to configure a
number of interfaces with one
command. Use speed and
duplex to adjust those settings
for an interface, and use

description to, well, describe
what the ports are doing!

Multicasting
Enable multicasting with ip

multicast-routing. Statically
configure the RP location with
ip pim rp-address. Enable
Sparse Mode on the interfaces

How to limit the multicast
groups a router can serve as
the RP for:

Configure routers as PIM RPs
with send-rp-announce, and as
PIM Mapping Agents with sendrp-discovery.
R3(config)#ip pim send-rpannounce serialO scope 5
R1 (config)#ip pim send-rpdiscovery serial O scope 5
Bootstrapping Commands:

To configure R1 as a C-BSR:
R1(config)# ip pim bsrcandidate To configure R2 and
R3 as C-RPs: R2(config)# ip
pim rp-candidate

Enable CGMP on a router and
switch as shown below. Note
that the router interface must
be PIM-enabled first.

Quality Of Service
To enable QoS:
SW2(config)#mls qos
To configure an interface to

trust the incoming CoS:
MLS(config-if)# mls qos trust
cos
To change your mind and take
the trust off:
SW2(config-if)# no mls qos
trust
To create COS-DSCP and IP
PREC-DSCP maps:
SW2(config) mis qos dscpmutation
The mutation map needs to be

applied to the proper interface:
SW2(config-if)mls qos dscpmutation MAP_NAME
To create a QoS policy, write an
ACL to identify the traffic and
use a class-map to refer to the
ACL:
SW1(config)#access-list 105
permit tcp any any eq 80
SW1(config)#class-map
WEBTRAFFIC
SW1(config-cmap)#match
access-group 105

QoS policies are configured
with the policy-map command,
and each clause of the policy
will contain an action to be
taken to traffic matching that
clause.

SW1 (config)#policy-map
LIMIT_WEBTRAFFIC_BANDWIDTH
SW1 (config-pmap)#class
WEBTRAFFIC SW1 (configpmap-c)#police 5000000
exceed-action drop SW1
(config-pmap-c)#exit
Finally, apply the policy to an
interface with the service-policy

command. SW1(config)#
service-policy
LIMIT_WEBTRAFFIC_BANDWIDTH
in

Multilayer Switching
To create a Switched Virtual
Interface:
MLS(config)#interface vian
10 MLS(config-if)#ip address
10.1.1.1 255.255.255.0
To configure a multilayer switch
port as a switching port:

MLS(config)# interface fast 0/1
MLS(config-if)# switchport
To configure basic HSRP:

To change HSRP timers:

To change HSRP priority and
allow a router to take over from
an online Active router:
R2(config-if)#standby 5 priority
150 preempt

To change the HSRP virtual
router MAC address:

R2(config-if)#standby 5 macaddress 0000.1111.2222
To configure GLBP:

MLS(config-if)# gibp 5 ip
172.1.1.10
To change the interface priority,
use the glbp priority command.
To allow the local router to
preempt the current AVG, use
the glbp preempt command.
MLS(config-if)# glbp 5 priority
150 MLS(config-if)# glbp 5
preempt

To configure members of the
server farm “ServFarm”
MLS(config)# ip slb serverfarm

ServFarm MLS(config-slbsfarm)# real 210.1.1.11
MLS(config-slb-real)# inservice

To create the SRB virtual
server:
MLS(config)# ip slb vserver
VIRTUAL_SERVER MLS(configslb-vserver)# serverfarm
ServFarm MLS(config-slbvserver)# virtual 210.1.1.14
MLS(config-slb-vserver)#
inservice

To allow only specified hosts to
connect to the virtual server:
MLS(config-slb-vserver)# client
210.1.1.0 0.0.0.255

Switch Security/Tunnel
Commands
To enable AAA and specify a
RADIUS or TACACS server:
SW2(config)#aaa new-model
SW2(config)#radius-server host
?

Hostname or A.B.C.D IP
address of RADIUS server
To define a default method list
for AAA authentication:
SW2(config)#aaa
authentication login default
local group radius
To configure port security:

To specify secure MAC
addresses:

To set the port security mode:

To enable Dotlx on the switch:

Dotlx must be configured
globally, but every switch port
that’s going to run dotlx
authentication must be
configured as well.

To verify a remote SPAN
session, create the VLAN that
will carry the mirrored traffic:

Configure the source ports and

destination as shown on the
source switch:

To create a VLAN ACL, first
write an ACL specifying the
traffic to be affected.

Finally, we’ve got to apply the

VACL. We’re not applying it to a
specific interface - instead,
apply the VACL in global
configuration mode.
SW2(config)# vlan filter
NO_123 vlan-list 100

For dotlq tunneling, the
following configuration would
be needed on the service
provider switch ports that will
receive traffic from the
customer:

By default, CDP, STP, and VTP
will not be sent through the
dot1q tunnel. To send those
frames to the remote network,
create an L2 protocol tunnel.
This command has quite a few
options, so I’ve shown as many
as possible below.

Creating a private VLAN:

Voice VLANs
The basic Voice VLAN
configuration is as follows:

To configure the switch to trust
incoming CoS values if they’re
sent by a Cisco IP phone:
MLS(config-if)# mls qos trust
cos
MLS(config-if)# mls qos trust
device cisco-phone

Five Tips For Success
On Cisco Simulator
Questions
If there’s one type of Cisco
exam question that causes
anxiety among test-takers, it
has to be the dreaded
“simulator question”. In this
kind of question, the candidate
is presented with a task or
series of tasks that must be

performed on a router
simulator.
Certainly, this type of question
is important. Cisco has stated
for the record that these
questions are given more
weight than the typical multiple
choice questions. Cisco has also
stated that partial credit is
given in multiple-task simulator
questions; that is, if you are
asked to do three things and
you get two of them right, you
do get some points for that.
Given all that, not a day goes

by that I don’t see a CCNA or
CCNP candidate post a note on
the Net about what simulator
questions are like, what will be
asked, and how to prepare for
them.
The conventional wisdom is
that it’s impossible, if not
difficult, to pass a Cisco exam if
you miss the simulator
questions. That fact is
responsible for a lot of the
anxiety I see out there. But as
with most anxiety and fear, this
anxiety can be conquered with
knowledge.

There are five simple steps
toward conquering the dreaded
simulator questions and nailing
your CCNA or CCNP exam.
Follow these steps, and you’ll
be on your way to walking out
of that testing room with a
passing grade in your hand and
a grin on your face!

1. Proper Performance
Prevents Poor
Performance
The best thing you can do to
get over your anxiety about
simulator questions is to make
sure you’re properly prepared
for them.
You have to go beyond just
reading books! While simulator
programs have come a long
way, working on them
exclusively is just not enough.
You need to put in some work
on real Cisco equipment.

I hear you already: “I can’t
afford my own equipment”. Yes,
you can. It’s cheaper than you
think.
Let’s look at the cost of
simulators vs. Cisco equipment.
A simulator program will set
you back $150 - $200. From
what I’ve seen on ebay, these
programs have little resale
value.

It’s cheaper than ever before to
put together your own Cisco
lab. You

don’t need anything incredibly
fancy, and there are dozens of
dealers on ebay who have premade CCNA and CCNP kits.
They’ll sell you your cables,
transceivers, and everything
else you need to get started.
When you’ve completed your
CCNA or CCNP, you then have a
choice to make. You can sell
your lab on ebay or possibly
back to the dealer who you
bought it from in the first place,
or you can keep it and add
some equipment for your next
level or study. You’re basically

leasing the lab, not buying it.
There is no substitute for
working on Cisco routers. When
you walk into a network center,
do you see real Cisco routers
and switches, or do you see
stacks of simulators?
Great chefs learn to cook in real
kitchens, not kitchen
simulators.
Great Cisco engineers learn
routing and switching on real
routers and switches. When you
do this, you’ll solve the

simulator questions easily.

2. Relax.
Sounds simple, right? The
problem here is the “fear of the
unknown”. Most of the emails I
get on this topic are from
candidates who are worried
about what tasks they’re going
to be asked to configure.
Relax.
You’re not going to be asked
anything above the level of the
exam. For the CCNA exams, I
would think you’d be asked
something along the lines of

configuring a VLAN or a routing
protocol. Certainly you’ll agree
that a CCNA should know how
to do that. (Would you hire a
CCNA who didn’t know how to
create a VLAN?)
Change your mental approach
to simulator questions. Look
upon them as a chance to
PROVE you know what you’re
doing. People who don’t know
what they’re doing might get
lucky with a multiple choice
questions, but there’s a simple
rule with simulator questions:
You either know how to do it or

you don’t.
This is a chance to prove to
Cisco that you are a true CCNA
or CCNP. Look on these
questions as opportunities, not
obstacles.

3. All the information
you need is right in
front of you.
I occasionally see a post or get
an email from a candidate who
says there’s not enough
information to answer the
question. This is incorrect. The
simulator questions on Cisco
exams are straightforward, and
all the information you need is
right there in front of you.
Make sure to take the tutorial
at the beginning on the exam.
You do not lose any time by

doing so, and there’s a
thorough walkthrough of a
simulator question in the
tutorial. I know you’re anxious
to get started
when you walk into the testing
room, but you must consider
going through the tutorial part
of your exam prep.
Cisco’s not trying to trick you
with these questions. Just
make sure you know where to
look for the information you
need BEFORE you actually start
the exam - go through the

tutorial carefully.

4. Use lOS Help in the
simulator when
possible, but don’t
depend on it being
available.
IOS Help is the Cisco engineer’s
best friend. I’ve tackled and
passed the CCIE Lab, and I can
tell you point blank that anyone
who says they remember all
the available commands is lying
to you. We all use IOS Help. It’s
great to use in lab
environments, too.

You should be very familiar
with IOS Help in your CCNA and
CCNP study, and use it every
chance you get However, don’t
depend on it being available in
your exam. You can certainly
try to use it; it’s not like you
lose points for doing so. But
don’t be surprised if it’s not
available.
The same goes for “show”
commands. Know the important
ones, but again, don’t depend
on them on exam day.

5. Type out your answer
in Notepad before
entering it into the
simulator. If Notepad
isn’t available, write out
your answer first.
I’ve heard different reports on
whether Notepad is available in
testing centers. Having said
that, it’s very important for you
to write out your answer one
way or the other before
entering it into the simulator.
It’s not that you cannot remove

your configuration on the
simulator after you enter it. I
found writing out my answer
before entering it really helped
me on my way up the Cisco
certification ladder, and current
candidates have told me it
really helps as well. Give it a
try!
I know that the simulator
questions on Cisco exams can
make you a little nervous,
particularly the first time you
have to answer them. Using
these five techniques will help
you nail these important

questions, and will help you
emerge victorious on exam day.
To Your Success,
Chris Bryant
CCIE #12933

Legal Notices
Copyright Information:
Cisco®,
Cisco®
Systems,
CCIETM, CCNP, CCNA, Cisco
Certified Network Administrator,
Cisco
Certified
Network
Professional, and Cisco Certified
Internetwork
Expert
are
registered
trademarks
of
Cisco® Systems, Inc., and/or
its affiliates in the U.S. and

certain countries.
All other products and company
names are the trademarks,
registered trademarks, and
service marks of the respective
owners. Throughout this Study
Package, The Bryant Advantage
has used its best efforts to
distinguish
proprietary
trademarks from descriptive
names
by
following
the
capitalization styles used by the
manufacturer.
Disclaimer:

This publication, The Bryant
Advantage CCNP SWITCH
Exam© Study Package, is
designed and intended to assist
candidates in preparation for
the CCNP SWITCH exam for the
Cisco
Certified
Network
Professional ® certification. All
efforts have been made by the
author to make this book as
accurate and complete as
possible, but no guarantee,
warranty, or fitness are implied,
expressly or implicitly.
The enclosed material is
presented on an “as is” basis.

Neither the author, The Bryant
Advantage, Inc., or the parent
company assume any liability
or responsibility to any person
or entity with respect to loss or
damages incurred from the
information contained in this
workbook.
This Study Package is an
original work by the Author. Any
similarities between materials
presented in this Study Guide
and actual CCNP® exam
questions
are
completely
coincidental.

Copyright 2012 © The Bryant
Advantage

The Bryant Advantage is not sponsored by
endorsed by, or affiliated with Cisco
System, Inc. Cisco®, Cisco System®,
CCDATM, CCNATM, CCDPTM, CCNPTM,
CCIETM, CCSITM, the Cisco System logo,
and the CCIE logo are trademarks or
registered trademarks of Cisco System,
Inc. in the United States and certain other
countries.