You are on page 1of 1394

Hi there!

Thanks for purchasing my ICND1
Study Guide! Whether you’re
preparing for success on the
CCENT 100-101 exam or you’re
going all the way to the CCNA 200120 exam, you’ve made an
excellent choice.
(Those of you preparing for the
CCNA 200-120 exam should also

grab my ICND2 Study Guide to go
along with this one.)
You’re about to benefit from the
same clear, comprehensive CCENT
and CCNA instruction that
thousands of students around the
world have used to earn their
certifications. They’ve done it, and
you’re about to do the same!
On the next page or two, I’ve listed
some additional free resources that
will definitely help you on your
way to the CCENT, the CCNA, and

to real-world networking success.
Use them to their fullest, and let’s
get started on your exam pass!
Chris Bryant
“The Computer Certification
Bulldog”

Udemy:
https://www.udemy.com/u/chrisbryan
Over 30,000 happy students have
made me the #1 individual

instructor on Udemy, and that link
shows you a full list of my free and
almost-free Video Boot Camps!
Use the discount code
BULLDOG60 to join my 27-hour
CCNA Video Boot Camp for just
$44! You can also follow this link,
which has the discount built in.

https://www.udemy.com/ccna-ondemand-video-boot-camp/?
couponCode=bulldog60&ccManual=

YouTube:
http://www.youtube.com/u/ccie12933

(Over 325 free training videos!)
Website:
http://www.thebryantadvantage.com
(New look and easier-to-find
tutorials in January 2014!)
Facebook: http://on.fb.me/nlT8SD
Twitter:
https://twitter.com/ccie12933
See you there!

Chris B.

Copyright © 2013 The Bryant
Advantage, Inc.
All rights reserved. This book or any
portion thereof may not be reproduced
or used in any manner whatsoever
without the express written permission
of the publisher except for the use of
brief quotations in a book review.
No part of this publication may be
stored in a retrieval system,
transmitted, or reproduced in any way,
including but not limited to photocopy,

photograph, magnetic, or other record,
without the prior agreement and written
permission of the publisher.
The Bryant Advantage, Inc., has
attempted throughout this book to
distinguish proprietary trademarks from
descriptive terms by following the
capitalization style used by the
manufacturer. Copyrights and
trademarks of all products and services
listed or described herein are property
of their respective owners and
companies. All rules and laws
pertaining to said copyrights and
trademarks are inferred.
Printed in the United States of America

First Printing, 2013
The Bryant Advantage, Inc.
9975 Revolutionary Place
Mechanicsville, VA 23116

Table Of Contents:
Free CCENT and CCNA Resources
The Fundamentals Of Networking
Ethernet (Header is “You Got Your
Ethernet In My Cabling!”)
Hubs & Repeaters (Header is
“Hubs, Repeaters, and a little more
Ethernet”)
Switching Fundamentals and
Security

Introduction To WANs (Header is
“A Network Admin’s Book Of
WANs)
DNS, DHCP, And ARP
Router Memory, Configs, and More
IP Addresses and the Routing
Process
Config Modes and Fundamental
Commands
Static Routing
The Wildcard Mask

OSPF
Access Lists and The Network
Time Protocol
Route Summarization
IP Version 6
NAT and PAT
ROAS and L3 Switching
Binary Math and Subnetting
Mastery

The Fundamentals Of
Networking
(With A Little Zen Thrown In)
Before we dive into the nuts and
bolts of networking, let’s ask
ourselves one question:
What is networking?
Why are we doing all of this stuff
with routers, and switches, and who
knows what else?
That’s two questions, I grant you,
but you get the point.

Networking was once simple. We
had a few end users with terminals,
and maybe a printer in the room,
and that was about it.

Things got just a little more
complicated after that.
Our end users and company owners

were thrilled that everyone could
now print to one printer – and then
it seemed like everyone wanted
something else!
“Wouldn’t it be great if we could
send each other files?”
“Hey, can we set up the network so
we can save data to a central
location?”
“We’re adding ecommerce to our
business – can we set up our
ecommerce servers so that only
certain people can have access to
them?”
“We need to add voice

conferencing to our network.”
“Wouldn’t it be great if we could
see a person’s face while they host
an online meeting for the
company?
When the first computer networks
were put together – and for many
networks after that – services we
use today without a second thought,
such as GoToMeeting and other
video / voice conference tools,
were fantasies.
They’re fantasies no longer, and our

networks have grown and grown
and grown in order to handle these
services and make them available
to our end users in an efficient
manner.
Of course, we also have to secure
our networks, and the tools we use
to do so can complicate our
network operations.
In short, we can have a collection
of devices like the ones shown here
all in one network, and it’s our job
to get them to work together.

If you’re new to networking, I know
from experience that the thought of
putting all of the stuff together can
be intimidating. It was for me the
first time I put a network together,
and we didn’t even have some of
these devices yet!

Here’s the key to success in this
field, and to keeping calm when
your studies intimidate you – it’s all
about the fundamentals.
Success with networking, whether
it’s on certification exams or in
real-world server rooms, is all
about knowing and applying the
fundamentals.
The material you’re about to study –
networking models, TCP and UDP
operation, and other networking
fundamentals – is actually the most

important part of your network
studies. After all, if you don’t know
how the fundamentals work, you
can’t possibly master the more
advanced concepts.
I’m mentioning all of this now for
one reason.
One night, when you’re tired and
you’re hitting your studies hard, it’s
easy to look at the OSI model and
think to yourself, “Do I REALLY
need to know this stuff?”

I know because I used to wonder
that, too. I’ve been there.
After 10+ years of experience with
networking and having helped
thousands of networking students
around the world meet and exceed
their career goals, I can tell you that
yes, you REALLY do need to know
this material!
You’ll see why as we dive into the
networking models and proceed
through the course. Let’s get to it!

The OSI Networking Model

The OSI model isn’t just something
to memorize for the exam and then
forget. You’ll find it helpful for
real-world troubleshooting and for
breaking networking down into
“pieces” that are easier to learn.
We’ll first take an introductory look
at the OSI model, getting familiar
with what’s going on at each level,
and then we’ll use it to create a path
for CCENT and CCNA exam
success.

Here’s the OSI model:

As network administrators, we’re
primarily concerned with the
bottom three layers. As CCENT and
CCNA candidates, we’re concerned
with all seven layers, so let’s start
at the top of the model and work our
way down.

The Application Layer

That’s not everything you need to
know for the exam, but it’s a great
start. The Application layer is
where our end users interact with
the network.

The Application layer performs
important behind-the-scenes tasks:
Makes sure the remote
communications partner is
available (remember, it takes
two to network)
Ensures that both ends of the
communication agree on a
myriad of rules, including
data integrity, privacy, and
error recovery (or lack of
same)

The Presentation Layer

This layer answers one basic
question, and that question is…
“How should this data be
presented?”
Ever opened a PDF with a nonPDF-friendly word processing app?
You can end up with hundreds of
pages of unreadable garbage – just
page after page of text that means
nothing to you. That’s a Presentation
Layer issue.

Encryption takes place at this layer,
and you’re going to hear a lot about
encryption in this and future
courses!

The Session Layer
This layer is the manager of the
overall data transfer process. It
handles the creation, maintenance,
and teardown of the communication
channel between the two parties
(the “session”, hence the name of
this layer!).

The Transport Layer
The main purpose of the Transport
layer is to establish a logical endto-end connection between two
systems.
That’s not the only thing going on
here! Most of the additional
Transport layer functions involve
either the Transmission Control
Protocol (TCP) or the User
Datagram Protocol (UDP). Those
two protocols are so important, they
have their own section in the course
– a section that could be worth
100+ points on your exam, so we’ll
be hitting a lot of detail there.

Now we come to the OSI layers that
you and I, the network admins, have
regular interaction with.

The Network Layer
For the router, the Network layer
processes answer two basic
questions:
What valid paths exist from
here to “Point B”?
Of those paths, what is the
best path to get to “Point B”?
Boy, that was simple! Class over!
Wellllll, it’s not quite that easy.
We’ll dive into the details later in

this course. Right now, it’s enough
to know that IP addresses
(172.12.123.1, for example) are
used at the Routing layer.
There’s another important address
we use in our networks, and that
one runs at the next layer down.

The Data Link Layer

We’ll be spending a lot of time with
switches in this course, and our
switches run at this layer, as do
these protocols:
Ethernet
HDLC (High Data Link
Control)
PPP (Point-to-Point Protocol)
Frame Relay
This address running at this layer is

usually referred to as the MAC
address, but it literally has four
other names:
Layer 2 address
Hardware address
Burned-in address (BIA)
Physical address
The first name makes perfect sense,
since we’re at Layer 2, but what
about those others?
This address is actually burned into
the hardware, so you see where the

“hardware” and “burned-in” names
come from. Be careful with that last
name, though. We sometimes call
the MAC address the “physical
address” because it physically
exists on the hardware – NOT
because it runs at the Physical
Layer of the OSI model, because it
doesn’t.
Right now, I want to introduce you
to a set of terms that sound like they
do the same thing, but we need to be
very clear on the difference:
Error detection
Error correction

Remember: Detecting something
doesn’t mean you’re correcting it.
Here’s why I’m bringing this up
right now….
The data link layer performs error
detection via the Frame Check
Sequence (FCS). The actual
operation of the FCS goes beyond
the scope of the CCENT exam, but
as a network admin you really
should know the FCS fundamentals:
1. The sender runs a
mathematical formula (an
algorithm) against the
contents of the frame.

2. The sender places the result of
that value into the FCS field
of the frame, and then sends
the frame.
3. The receiver of the frame runs
the same algorithm against the
contents of the frame. If the
resulting value matches that
contained in the FCS field, the
frame is fine. If that resulting
value does not match, that
frame is considered corrupt
and is then discarded.

So why no error recovery? It’s the
recipient of the frame that detects
the error, not the sender, and the
recipient can’t retransmit the frame
to itself! All the recipient can do is
let the sender know there was a
problem.

The Physical Layer

All the work we do at the upper
layers of the OSI model is all about
sending the data across the Physical
layer in the form of ones and
zeroes.
The data our end users create is
going to be eventually be
“translated” into 1s and 0s.
Anything having to do with a
physical cable or the standards in
use – the pins, the connectors, and
the actual electric current – is

running at the Physical layer.
With our end users entering data /
sending photos / watching videos /
whatever, it sounds like we have to
do a lot of work to turn all of that
into ones and zeroes.
It’s almost like we need a plan to
do so…. and here it is!

The Data Chopping Process

This is actually known as the
overall data transmission process.
It’s also a good reminder for
network newcomers as to what
we’re actually doing here.
When the end user sends data, the
data goes through all seven layers
of the OSI model, but it doesn’t
keep the same form – otherwise the
physical layer would be getting
HUGE chunks of data and have no
idea what to do with it!

Instead, the Transport layer begins
the process of taking the data and
segmenting it into smaller units, and
each layer below the Transport
layer will break the units up into
even smaller units, until the data has
been transformed into a stream of
ones and zeroes that can
successfully be transmitted by the
Physical layer.
I can guarantee the following data
unit terms and their associated OSI
layers will show up on your
CCENT and CCNA exams.

At the Application, Presentation,
and Session layers, data is simply
referred to as “data”. While there
are important operations going on at
these layers, the “chopping” of the
data hasn’t started yet.
That process begins at the Transport
layer, where the data is placed into
segments.
At the Network layer, data is placed
into packets.

At the Data Link layer, data is
placed into frames.
Finally, at the Physical layer, data
takes the form of bits, and those bits
are all ones and zeroes!
For your exams, be very clear about
the data transmission unit
associated with each OSI layer.
There’s a little extra overhead
involved with the OSI model. Each
layer is going to add its own header

that will be removed by the same
layer on the other end of the
session. These headers are layerspecific. The Transport layer
doesn’t care about the contents of
any header except the one placed
there by the Transport layer on the
other end of the session.
There are almost always exceptions
in networking, so let’s introduce
you to one right now. Each of the
top six layers will place only a
header on the data except for the
Data Link layer, which will add
both a header and a trailer.

This combination of data and a
layer-specific header is a Protocol
Data Unit (PDU), and there’s a PDU
for each layer shown above.
They’re usually referred to by the
layer – L7 PDU, L6 PDU, etc.
Once the data is successfully

transmitted by the Physical layer,
the data flows back up the model on
the other end of the session. As
you’d expect, each layer removes
the header added by its counterpart
on the other end of the session
(“same-layer interaction”).

Let’s do a quick comparison of
same-layer and adjacent-layer
interaction.
“Same-layer interaction” refers to
an OSI layer on one end of the
session removing the header placed
on it by the same layer at the other
end of the session.

Adjacent-layer interaction refers
to the interaction between layers of

the OSI model on the same host.
For example, the Application layer
can have adjacent-layer interaction
with the Presentation layer, the
Presentation layer can have
adjacent-layer interaction with both
the Application and Session layers
(the ones directly above and below
it), and so forth.
We’ve spent a lot of time with the
OSI model, and while we’re not
done with it, there’s another
networking model….

The TCP / IP Networking Model

This model also uses layers to
illustrate the data transport process,
but only five layers as opposed to
the OSI model’s seven.
For the CCENT and CCNA exams,
it’s an excellent idea to know the
following:
The layers of the TCP/IP and
OSI models (check!)
The responsibilities of each

layer (check!)
How the layers of the two
models map to each (coming
up!)
Enough prologue and dialogue…
here’s the latest version of the
TCP/IP model!

Let’s map the OSI model to the TCP

model:

The Application layer of the
TCP/IP model maps to the top three
layers of the OSI model
(Application, Presentation,
Session). After that, it’s a one-toone layer mapping all the way
down.
You TCP/IP model veterans know
this is a LOT easier to deal with
than the previous model, which
follows:

The Internet layer is bulging a little
bit, since I wanted to put at least
two of the known names for that
layer in there. Don’t even get me

started on the multiple names I’ve
seen over the years for the bottom
layer. We’re all happier with the
much more intuitive, new TCP/IP
model.
There’s nothing tricky about these
models, and they will be easy
points for you on exam day. Having
said that, on exam day, quickly
double-check any questions you’re
given on these models to be sure of
the model you’re being asked about.
If you’re asked about the OSI
model, don’t give an answer of a
layer in the TCP/IP model.

Here’s the magic question I just
KNOW some of you are asking:

Why Do We Use Models, Anyway?

Mostly just to aggravate you on
exam day.
Just kidding! It only seems that way.
One reason is that networking
models help software vendors
create (we hope) interoperable
products.
For our purposes, breaking the

overall networking process into
smaller pieces makes it a lot easier
to learn networking in the first
place.
This is a very important point, not
just for this section, but for all of
your studies – Cisco and otherwise.
It’s really easy to become
overwhelmed when you start
learning this stuff.
Here’s a surefire cure for that
feeling: Just take it one feature at a
time. Learn one thing about the

subject matter at a time, and soon
you’re got it all mastered.
That’s worked for me for over 15
years and it’ll work for you, too.
Now back to the “why” regarding
these models…
Using a networking model to
structure your troubleshooting
approach is a real help, especially
since most of what you and I do as
network admins is troubleshooting.

(It’s not like we configure our
networks from scratch every single
day.)
I always tell students to start
troubleshooting at the Physical
layer, and you’ll see what I mean as
we perform troubleshooting
throughout the course. In my
experience, there are two kinds of
network troubleshooters:
1. Those who have a structured
approach.
2. Those who don’t have a

structured approach, and are
basically just trying things
blindly because they don’t
truly understand what they’re
doing.
You want to be #1.
In short – or in long – these
networking models aren’t just
something to memorize for your
exams. You’ll be using them
throughout your career, even if
you’re not consciously thinking
about it.
Let’s take a closer look at two new
friends that operate at the Transport
layer. There’s a ton of fertile

ground for exam questions in this
section!

TCP vs. UDP
Here are the similarities between
the two:
They both operate at the
Transport layer of the OSI
model.
They both perform something
called “multiplexing”.
You knew the first one, and we’ll
talk about the second one later in
this section – I promise!
That’s about it for the similarities.

Let’s get to the differences!
TCP Characteristics:
Guarantees delivery of
segments
Performs error detection
Performs “windowing”
“Connection-Oriented”,
meaning a two-way
communication between the
two endpoints will take place
before data is actually
exchanged

If those terms are new to you, that’s
fine, we’ll define them in a moment.
First, let’s take a look at UDP:
UDP Characteristics:
“Best-effort delivery”, which
is good, but not guaranteed
No error detection due to
lack of Sequence or Ack
numbers
No windowing
“Connectionless”, meaning
there’s no pregame
communication between the

two endpoints – the data
exchange just starts!
Even if you don’t know what
windowing is, you have to admit
that TCP already sounds a lot better
than UDP. That very first
characteristic of each – TCP
guaranteeing delivery of segments
while UDP doesn’t guarantee it –
well, that sounds like enough for me
to use TCP for everything and UDP
for nothing!
That’s not the case in the real

world. Many vital protocols,
including the protocol that handles
the very important work of
dynamically assigning IP addresses,
uses UDP.
On top of that, the two most delaysensitive types of network traffic
we have – voice and video – use
UDP.
Why?
That question has a one-word

answer, and you just might figure
out that one word as we examine
the overall operation of both
protocols, starting with TCP and a
curious process called the “threeway handshake”.

TCP and the Three-Way
Handshake

You’ve probably shaken hands
many times in your life, but have
you ever taken part in a three-way
handshake?
Let’s take this one step further:
How in the world can you even
have a three-way handshake?
Here’s how and why:
With TCP, there’s some work to be
done before any segments are
transmitted. The involved devices
have to agree on some basic

parameters before any
transmissions can happen, including
the Initial Sequence Number (ISN).
Here’s exactly how this handshake
proceeds…
The initiating server sends a TCP
segment with the SYN bit set. That
SYN stands for SYNchronization,
and the primary value being
synchronized is the TCP Sequence
number.

The recipient responds with a TCP
segment of its own, and this one has
the Acknowledgement bit set as
well as the SYN bit, which is why
we call this a “SYN/ACK”.

Part of that SYN/ACK is the server
acknowledging receipt of the
original SYN, so it makes sense that
the server getting the SYN/ACK
needs to ack that. That’s the final
step of our 3-way handshake!

Summing up:
1. The initiating server sends a

SYN in an effort to
synchronize TCP values with
the recipient.
2. The receiving server sends a
SYN/ACK back for two
reasons – one, to
acknowledge receipt of the
original SYN, and to further
the synchronization process.
3. The initiating server sends an
ACK to let the other server
know the SYN/ACK was
received, and that’s the end of

the handshake.
Now let’s take a look at the UDP 3way handshake:
< crickets chirping >
That’s it, because UDP doesn’t
have a 3-way handshake.
Sounds like another strike against
UDP.
Now for another great TCP
feature….

How TCP Detects and Recovers
From Lost Segments

While the following is technically
not error detection, it’s a very
important concept of TCP – how
TCP realizes segments have been
lost, and how TCP recovers from
lost segments.
The TCP header contains separate
fields for the sequence number and
acknowledgement number, and it’s
those two values that allow TCP to
detect and recover from lost
segments.

In the following example, one host
is sending four segments to another.
Each of the segments has a
sequence number, and it’s that
sequence number that tells the
recipient in what order the segments
should be reassembled.
Here’s an illustrated look at the
process, starting with S1 sending
four 1500-byte segments to S2:

Once the four segments are
received by S2, it would be a really
good idea to let S1 know the
segments arrived safely.
S2 does that by sending a segment
back to S1, but there will be no data
in the segment. The ack number will
be set, but it will not be set to the
number of the last segment S2
received, as you might expect.
Instead, it’ll be the number of the
next data segment S2 expects to see,
and with this pattern that would be
7500.

The natural assumption is that the
ack would be set to 6000, but when
S2 tells S1 the next segment number
it expects to see, this cumulative
acknowledgement scheme allows
TCP to realize when segments have
been lost.
Let’s see what happens when one of

those four segments is lost.

S2 will send an ACK of 3000 back
to S1.

When S1 sees that ACK of 3000
coming in, it knows the segment
with SEQ 3000 wasn’t seen by S2,
so S1 will then retransmit that
particular segment. S2 will then
send an ACK for that retransmitted
segment indicating the NEXT
sequence number it expects to see.

In networking studies, as in life, one
answer tends to lead to another
question. In this case, that question
is “How does S1 know how many
segments it can send before it has to
receive an ACK?”
Another question: “Why doesn’t the
recipient just send an ACK for
every segment it receives?”

Here’s why!

Flow Control and Windowing

Let’s step back to the TCP threeway handshake. We know that
during that handshake, parameters
are negotiated and agreed upon, one
of those being the initial sequence
number (ISN).
Another value negotiated during this
handshake is the initial size of the
window, which determines how
many bytes of data the recipient is
willing to take in before it has to
send an ACK.

Note this is the initial size of the
window. It’s vital to remember that
the size of the window is dynamic,
not static. As the recipient realizes
it can handle that initial amount of
data effectively, the recipient will
indicate to the sender that it can
send more data before expecting an
ACK.

To reiterate a couple of important
points regarding windowing:
The initial size of the
window is negotiated and
agreed upon during the threeway handshake.
The size of the window is

expressed in bytes.
The size of the window is
dynamic, and it’s changed by
the recipient, not the sender.
This flow control can raise
or lower the size of the
window, also referred to as a
sliding window.
The recipient will lower the size of
the window as it sees that errors
and / or dropped segments are
starting to creep in.

You can see why TCP flow control
is such a great feature. It allows
segment transmission to stay close
to maximum speed while also
letting the recipient slow the flow
down when transmission is too fast.
UDP offers no flow control.

Right now, TCP is looking pretty
darn good, and UDP isn’t.
There’s one word that describes
UDP’s advantage over TCP. Before
we trash UDP’s reputation entirely,
let’s see what that word is.

UDP’s Advantage Over TCP
Let’s compare the TCP and UDP
headers.
TCP’s header and data location:

UDP’s header:

Quite a difference in size, and that
difference leads us to that single
word that makes UDP so
attractive… overhead.
While TCP offers so many more

features than UDP, those features
come at the cost of additional
overhead. These headers are
attached to every segment, and that
really adds up – especially with the
delay-sensitive voice and video
traffic found on today’s networks.
UDP is used for voice and video
traffic for this very reason.
The UDP header is much smaller
than the TCP header, and it’s worth
your time to note the two headers
have three fields in common:
Source port

Destination port
Checksum
For clarity’s sake, in the TCP
header I listed a “Flags” section.
That’s actually nine individual 1-bit
flags, which include the ACK and
SYN flags mentioned throughout
this section.

This Just In: A UDP / TCP
Similarity!

One factor UDP and TCP have in
common is a little something called
“multiplexing”. Before we see how
multiplexing works, let’s see why
we need it in the first place.
You don’t need to know the ins and
outs of IP addressing at this point in
the course. It’s enough to know that
IP addresses are used as a
destination when data is sent to a
network host.

So far, so good – until one host
starts sending multiple flows of
information to the other host. How
is the recipient supposed to handle
that?
Let’s say the host at 10.1.1.11 is
sending three different flows of data
to 10.1.1.100:

A file transfer via the Trivial
File Transfer Protocol
Email via the Simple Mail
Transfer Protocol
Webpage data via HTTP

The server needs a way to keep the
incoming flows separate so it can
send the TFTP data to the
application that will handle that
data, SMTP data to the appropriate

application, and so on. That’s
where our new best friends come in
– well-knownport numbers!
These port numbers may not be
well-known by you (yet), but they
are to our network devices. I’ll
have a bigger list of well-known
port numbers for you later in this
section, and it would be an
excellent idea for you to have those
down cold for your exam. Let me
introduce you to three of them now:
TFTP: UDP port 69

HTTP: TCP port 80
SMTP: TCP port 25
The three data flows in our example
will have the same source and
destination IP addresses, but they’ll
have different, pre-assigned port
numbers. Those different port
numbers are the reason the recipient
knows how to handle the three
incoming flows that all originated
from the same host.

When a host receives data marked
as UDP port 69, it knows that traffic
should be delivered to the TFTP
application, TCP port 80 traffic
should go to the HTTP application,
and so forth.
These port numbers also allow the
host to mix the three data types
when sending to 10.1.1.100, rather
than sending all the TFTP data first,

then the SMTP data, then the HTTP
data. This mixing of data streams is
multiplexing.

When you hear the term “socket”,
you might think of a physical part of
a network host, but it’s actually
logical. The socket is simply a
combination of IP address and port
number. The socket for the TFTP
traffic heading for 10.1.1.100
would be expressed as

10.1.1.100:69.
You’ll sometimes see a socket (try
saying THAT really fast three
times!) expressed in this format:
IP address, transport protocol,
port number
Using that mode of expression, the
TFTP socket on 10.1.1.100 would
be (10.1.1.100, UDP, 69).
I’m sure you’ll agree with me that

the port number system works
nicely as long as the hosts agree on
the port used for a given protocol.
For example, if 10.1.1.11 is using
TCP port 55 for TFTP, we’re in a
lot of trouble.
That’s why most protocols use the
same port number at all times, and
these port numbers are well-known
port numbers. Two bits of info for
you on those:
Any port number below 1024
is a reserved, well-known
port number.

You do NOT have to
memorize 1024 port numbers
for your exams.
I strongly recommend you memorize
the port numbers listed throughout
the rest of this section. You’ll find
them helpful in both your
networking studies and real-world
network administration. They’re not
just something to memorize for your
exam that you’ll never use again,
and like the OSI model layer, they
become second nature to you.

TCP’s Four-Way Handshake
(What?)

I didn’t want to hit you with this
during the TCP/UDP comparison,
since we had enough going on. Now
that you’ve got all of this down, I
want to show you TCP’s four-way
handshake.
The three-way handshake we saw
earlier was during the connection
establishment; the four-way
handshake we’re about to see is the
connection termination. I’ve seen

this expressed in several different
ways over the years, but in the end
each device needs to send a
segment with the FIN bit set and
they each need to ACK the FIN they
receive.

We’ll wrap this section up with a
couple of well-known port numbers

it would behoove ye to know, and
then we’ll move on to Ethernet!
TCP 20: File Transfer Protocol
(file transfer)
TCP 21: File Transfer Protocol
(control)
TCP 22: Secure Shell (SSH)
TCP 23: Telnet
TCP 25: Simple Mail Transfer
Protocol
TCP and UDP 53: Domain Name
System

UDP 67, 68: Dynamic Host
Configuration Protocol
UDP 69: Trivial File Transfer
Protocol
TCP 80: Hypertext Transfer
Protocol
TCP 110: Post Office Protocol
(Current version: 3)
UDP 161: Simple Network
Management Protocol
TCP 443: Secure Sockets Layer
(“HTTPS”)
UDP 514: Syslog (Short for System
Logging – more on that in your

ICND2 studies)
UDP 546, 547: DHCP For IP
Version 6
This is a great list to get started
with, but it’s hardly all of the wellknown port numbers. The list on the
following page is WAY beyond the
scope of the CCENT and CCNA,
but it’s a great reference list for
future studies.

http://en.wikipedia.org/wiki/List_of_

With those in mind, let’s march on
to Ethernet – and BEYOND!

You Got Your Ethernet
In My Cabling!
(You Got Your Cabling In My
Ethernet!)
When we get to Wide Area
Networks, we’ll run into quite a
few different encapsulations -HDLC, Frame Relay, and PPP in
particular.
With Local Area Networks,
whether we’re connecting a host to
a switch….

… or we’re connecting two
switches…

… or we’re connecting a switch to
a router…

…. we’re likely using Ethernet and
Ethernet cables. In this section,
we’ll talk a bit about how Ethernet
works, and the different types of
cables we’ll use in this network.
And note that I said “Cables With
An S”, because not all Ethernet
cables are the same!
Actually, not all Ethernet types are
the same, so let’s start there.

Not All Ethernets Are The Same

“Ethernet” is really an umbrella
term at this point, encompassing
several different types of Ethernet,
different capacities, and different
challenges. For both a successful
exam experience and a solid
networking career, it’s a great idea
to be comfortable with these values.
Most kinds of Ethernet cables are
Unshielded Twisted-Pair (UTP).
The name is the recipe – the wires
inside the cable are indeed pairs of

twisted cables.
Why twist ’em? Twisting pairs of
wires inside the cable cuts down on
electromagnetic interference (EMI).
EMI can interfere with the
electrical signals carried by the
wires, which in turn is really going
to screw around with our network.
EMI can come from other cables,
and also (and infamously) from
elevators. I know of more than one
network that would slow down at
lunchtime and quitting time because

that’s when the elevators were in
heavy usage, and the network
cables werun right next to the
elevator shaft, which in turn gave
our network the shaft.
We can even have EMI problems
from other wires in the same cable!
This crosstalk happens when a
signal “crosses over” from one pair
of wires to another, making the
signal on both sets of wires
unusable.
Near-end crosstalk (NEXT) occurs

when wires are crossed or crushed.
The conductors inside the wires
don’t have to be exposed, but if the
conductors are too close, the signal
traveling on one wire can interfere
with the signal on another wire.
Here are some common Ethernet
types that run on regular old copper
cabling, along with their official
IEEE name and more common
name. All have a maximum cable
length of 100 meters.
Ethernet’s official standard is

802.3, is generally referred
to as 10Base-T, and runs at
10 Megabits per second
(Mbps).
Fast Ethernet (802.3u) is
usually called 100Base-T,
and runs at 100 Mbps.
Gigabit Ethernet (802.3ab) is
generally called 1000Base-T,
and runs at 1000 Mbps.
10 Gig Ethernet (802.3an) is

NOT called 10000Base-T.
It’s usually called 10GBaseT, and runs at – you guessed
it! – 10 GBPS.
There’s a huge difference between
10GBase-T and 10Base-T. Watch
that G!
We also have a version of Gig
Ethernet that runs on fiber-optic
cable. That version is 802.3z, and
is often called 1000Base-LX. This
version has a max cable length of
5000 meters, as opposed to 100

meters with all the other versions
we’ve seen.
So with that huge max cable length,
why aren’t we running everything
on 802.3z? It’s the sheer cost of the
fiber optic cable. It’s a lot more
expensive to install and
troubleshoot than copper cable.

Multiple Standards Usually Equal
Multiple Nightmares

Luckily, this isn’t one of those
situations.
When you send an Ethernet frame
from Point A to Point B, there’s a
chance the frame could go across a
“regular” Ethernet link, then a Gig
Ethernet link, and then a Fast
Ethernet link as it arrives at its
destination.

If we had to do some kind of
translation every time a frame went
from one Ethernet type to the other,
we’d be doing a lot of translations
and adding big time to our
transmission time and overall
network workload. Fear not – we
don’t have to do anything like that.
All of our different Ethernet
standards have the same overall
frame format:

Header, data, trailer. That’s it!

There’s another tool that allows us
to seamlessly use network and host
devices with different Ethernet
capabilities – autonegotiation.
Autonegotiation didn’t work all that
well years ago, and it got to the
point where most network admins
manually set card and port settings.
Cisco went so far as to make it a
best practice NOT to use
autonegotiation.
I mention this because I don’t want
you more-experienced network

admins glossing over this section,
thinking “Hey, autonegotiation
doesn’t work.” Autonegotiation has
come so far since the bad old days
that it’s actually mandatory for Gig
Ethernet over copper, and it’s an
important part of the overall Gig
Ethernet standards.
Having said that, let’s see how
autonegotiation works!
In this example, we have a host
device connected to a Cisco switch
port. The host is running 10BaseT,

and the switch port has a top
capability of 1000BaseT.

The devices announce their
capabilities via Fast Link Pulse
(FLP). The logical question: “Fast
as compared to what?”
Fast as compared to the Normal
Link Pulse (NLP)! Basically, the
NLP is sent by an Ethernet device

when it has no data frames to send –
it’s saying “Hello, I’m still here!”
Here’s the NLP, compliments of
Wikipedia:

Here’s the Fast Link Pulse, which
autonegotiation-enabled devices
use to announce their capabilities:

After the devices exchange this
information…

… they come to an agreement on the
values to use. As you’d expect, the

lowest speed is the one selected,
and full-duplex is preferred over
half-duplex. In this situation, the PC
port and the switch port it’s
connected to would run at 10 Mbps,
full duplex.
Autonegotiation will dynamically
adjust if a port capacity changes.
Let’s say you replace that PC with a
PC that can run at Fast Ethernet
speed.

If we manually set all of our switch
port settings, we’d have to change
the speed on that port manually.
With autonegotiation, the switch
will realize the new capacity of the
device connected to that port, and
voila – a 100 Mbps link!
I highly recommend you use
autonegotiation on both ends of a
link such as this one, or don’t use it
at all. You can end up with a link
that isn’t working at its real
capacity due to a duplex mismatch
– a link where one endpoint is
running at half-duplex and the other

end is running at full-duplex.
When using Cisco switches, if
autonegotiation is turned off on the
other end of the link, the switch
should still be able to sense the
speed capacity of the other
endpoint. If for some reason the
speed capacity can’t be detected,
the lowest speed supported will be
used.
That probably doesn’t surprise you,
but this might. If that detected speed
is less than or equal to 100 Mbps,

the switch will set its port speed to
half-duplex. Hello, duplex
mismatch!
In this example, the Cisco switch
has successfully detected the
capacity of the remote endpoint to
be 100 Mbps. No problem there,
but a problem does arise when the
Cisco switch sets its port connected
to that host to half-duplex as a result
of that speed.

Duplex mismatches have a special
place in Network Heck, because
they can be difficult to spot. The
two devices will still be able to
exchange data, but it’s going to be a
slow, inefficient process.
Run autonegotiation on both ends or
don’t run it at all.

Crossover and Straight-Through
Cables
We’re going to use a simple
network for this demo, and the two
separate physical connections will
require two different cable types.

A PC’s network sends on pins 1 and

2 and a switch sends on pins 3 and
6. In turn, the PC receives on pins 3
and 6, and the switch receives on
pins 1 and 2. This means we can
use a straight-through cable to
connect the PC to the switch.
The cable name comes from the
wires inside the cable. Assuming
we’re using Ethernet or Fast
Ethernet for this connection (a safe
assumption), we’re going to have
four wires inside the cable, and
each wire goes straight through
from one end to another.

What exactly does “straight
through” mean in this situation? The
wire connected to Pin 1 at one end
goes straight through to Pin 1 at the
other end, the wire on Pin 2 goes
straight through to Pin 2 at the other
end, and the wires on Pins 3 and 6
go straight through to those pins on
the other end.
If you enjoy making your own
cables and you run into a
connection issue right away, I can
practically guarantee the problem is
that one of those wires in your
straight-through cable is crossing

over to another pin.
Gigabit Ethernet can use straightthrough cables as well, but to carry
data that quickly, it follows that
we’ll have more wires inside the
cable. Where Ethernet and Fast
Ethernet have 4 overall wires
inside the cable, Gigabit Ethernet
has eight. In a Gigabit straightthrough cable, one wire goes from
Pin 1 to Pin 1, one wire from Pin 2
to Pin 2, and so forth for all eight
pins.
Wires crossing over inside the
cable isn’t always bad. Sometimes

we want those wires to cross over
in the cable – hence the name
“crossover cable”, our next cable
type!
Crossover cables are necessary
when we’re connecting two devices
of the same type, and in a typical
network, that’s going to be two
switches. When we tackle
switching in this course, you’ll see
why interconnecting switches is so
common. Our first step in this
interconnection is choosing the right
cable!

We can’t use a straight-through
cable for a switch-to-switch
connection, since they use the same
pins to send and receive. We’d have
the same pins sending data on both
ends (a bad idea) and pins 3 and 6
on each end listening for data that
will never arrive (sad!).
Communication between the
switches is made possible with a
crossover cable. The four wires
inside the cable “cross over” from
one pin to another inside an
Ethernet or Fast Ethernet crossover
cable:

Wire on Pin 1 crosses over to
Pin 3
Wire on Pin 2 crosses over to
Pin 6
Wire on Pin 3 crosses over to
Pin 1
Wire on Pin 6 crosses over to
Pin 2
With this setup, when a switch
sends data on the two pins used to
send data (Pins 1 and 2), the switch
on the other end of the cable will
receive the data on pins used to
receive data (Pins 3 and 6).

Gigabit Ethernet crossover cables
have those same wires cross over
in addition to the following:
Wire on Pin 4 crosses over to
Pin 7
Wire on Pin 5 crosses over to
Pin 8
Wire on Pin 7 crosses over to
Pin 4
Wire on Pin 8 crosses over to
Pin 5
Now it’s time for a little “real
world vs. theory” chat.

After reading that cabling section,
some of you are saying “Hey, I used
a straight-through cable to connect
two switches with no trouble.” And
you’re right – you just might have.
Most Cisco switches will recognize
what you’re trying to do when you
connect them to each other with a
straight-through cable, and the
switch will dynamically adjust
itself to make the straight-through
cable work.
Pretty cool!

When it comes to your CCENT and
CCNA tests, though, you need to
forget about that. Be clear on when
you’d use a straight-through cable
as opposed to a crossover cable:
Devices transmit on same
pins = crossover cable
Devices transmit on different
pins = straight-through cable

Both straight-through and crossover
cables end with RJ-45 connectors,
which “snap” right into place when
connected to a PC NIC or switch /
router Ethernet port.
Five Names, One Address

Several protocols and services
you’ll be introduced to in this
course have more than one name,
and we’ll start that tradition with
the next topic, known by all of these
names:
MAC address (Media Access
Control)
Physical address (because
the address physically exists
on the network card)
Layer 2 address

Burned-In address (BIA – the
name comes from the address
being physically burned into
the NIC)
Ethernet address
That’s nothing! We used to have
seven names for this address, but
the terms “NIC address” and “LAN
address” have pretty much fallen by
the wayside. Throughout the
courses, I’ll use the term “MAC
address”, but you should be
familiar with all the names listed

here.
The MAC address is used by
switches to send frames to the
proper destination in the most
efficient manner possible, a process
you’ll be introduced to in the
Switching section. Before we see
how that works, I want to introduce
you to the address format and the
characters we’ll see in this address.
The MAC address is six bytes long
(48 bits), and can be expressed in
either of these formats:

aa-bb-cc-11-22-33
aabb.cc11.2233

MAC addresses consist of
hexadecimal values, and if that
phrase gives you anxiety,
fuggetaboutit. By the time this
section is over and you get some
practice in, you’ll be working with
hex like a champ – or more
accurately, like a CCENT and
CCNA!
You’ll hear me say this throughout
the course, and I’ll start now: The

key to mastering hex, binary, and
subnetting is practice. Reading
about it is not enough!
The MAC address has two parts,
the first being the Organizationally
Unique Identifier (OUI, not
pronounced like the French word
for “yes”, but Oh-You-Eye). The
OUI is assigned to hardware
vendors by the Institute of
Electrical and Electronics
Engineers (IEEE).
The name is the recipe – the OUI is

unique to that organization and is
not assigned to another org.
The second half of the MAC
address is simply a value not
previously used by the hardware
vendor with that particular OUI.
Using the earlier MAC address
example, we see that…
The OUI of the address is aabb-cc
The vendor has not yet used

11-22-33 with that particular
OUI, so the vendor is doing
so now
There’s a special MAC address for
broadcast frames, and as we get to
that topic, let’s take a look at the
three overalltypes of network
traffic.
Unicast traffic – Destined for
one particular host
Multicast traffic – Destined

for a group of hosts
Broadcast traffic – Destined
for everybody
You can spot broadcast and
multicast MAC addresses by using
the following rules:
The broadcast MAC address
is ff-ff-ff-ff-ff-ff (or FF-FFFF-FF-FF-FF, as case
doesn’t matter in hex).

We have a range of multicast
MAC addresses. The first
half of a multicast MAC
address will always be 0100-5e. The second half will
fall in the range of 7F-FF-FF.
Watch that 7!
Remember that Ethernet header and
trailer I mentioned briefly?
No?
Well, I don’t blame you, it was a
fast mention. Let’s take a more
detailed look at both the header and
trailer.

The Ethernet Header And Trailer
Here’s a high-level look at the
overall Ethernet frame:

A detailed look at the header:

From left to right, a quick look at
each field:

The preamble is there for
synchronization purposes.
The nuts and bolts of this
field are (thankfully) way
beyond the scope of the
CCENT and CCNA exams. If
you’d like to read more about
this field, check out the
Wikipedia entry for Ethernet.
The Start Frame Delimiter
(SFD) indicates the preamble
has ended and the destination
MAC address is on deck.

Both the destination and
source addresses are MAC
addresses.
Finally, the type (EtherType)
field indicates the protocol
type carried in the data field.
In today’s networks, that’s
likely IPv4 or IPv6, but it can
be plenty of other protocols.
Here’s a detailed look at the
Ethernet trailer contents:

That’s it!
Considering the FCS is the Ethernet
caboose, it’s easy to think there’s
not much going on there, but the
FCS is a vital error detection tool.
It’s basically a three-step process:

The sender runs an algorithm
against the contents of the
frame, and takes the result of
that algorithm and puts it in
the FCS field. The result is
the checksum.
The receiver runs the exact
same algorithm against the
same contents, and expects to
come up with the same
checksum contained in the
FCS field of the incoming
frame.

If the results are the same, the
frame is fine. If the results
are not the same, something
happened to the frame
contents as the frame went
across the wire, and the
frame is dumped.
There is no explicit notification
from the receiver to sender that the
frame was discarded. The FCS
brings us error detection, but not
correction.
But Wait – There’s More!

We saw two common network
connections earlier (PC to switch,
switch to switch), and there’s
another one I want to introduce you
to – connecting your laptop or PC
directly to a switch or router in
order to configure it. For that
physical connection, you’ll need yet
another type of cable.

When you physically connect your
laptop to a router or switch, you’ll

be connecting to the Console port
on the network device. For this,
you’ll need a rollover cable, also
called a console cable. There are 8
wires inside the rollovercable, and
they each roll over to a different pin
at the other end: Pin 1 to Pin 8, Pin
2 to Pin 7, Pin 3 to Pin 6, and so on.
One end of the console cable will
have an RJ-45 connector, similar to
that on the end of a land line phone
wire. You’ll feel (and maybe hear)
that end of the cable snap into the
Console port.

It’s the other end of the console
cable you need to be aware of.
Some console cables have a DB-9
connector on one end, and modern
laptops don’t have a DB-9 port. If
that’s your situation, get an adapter
for your cable – you can find them
online at any major cable dealer.
(And even most minor ones!)
The need for an adapter is a good
thing to find out before you visit a
client site.
Rollover cables are easy to spot,

since they’re almost totally flat and
usually colored light blue.
Here’s a link to a page on
PacketByte.com that shows you a
console cable, along with two other
cable types that you’ll find in any
great Cisco home lab!

http://packetbyte.com/Content/Cablin
Next up – hubs and repeaters. You
might not see many of them in
today’s networks, but you need to

understand how they work in order
to really grasp switch operation –
and you’ll see hubs, repeaters, and
switches on your exam, so let’s hit
it!

Hubs, Repeaters, And
A Little More Ethernet
Cisco switches operate at the Data
Link layer, but to fully understand
and appreciate how switches
operate (and to be fully prepared
for the CCENT and CCNA exams),
we need to look at the devices that
preceded switches.
These devices are still in some
networks, but for reasons you’re
about to discover, repeaters and

hubs aren’t terribly popular. If you
never work with either in a
production network, to be blunt,
you’re not really missing anything.
Having said that, you might miss out
on some vital exam points if you’re
not familiar with them, so let’s dive
right in!

Repeaters And Hubs

Both repeaters and hubs are Layer 1
devices.
So with a repeater, what exactly are
we repeating, and why?
When you’re listening to a radio
station (non-satellite, that is), you
know how the signal starts
gradually breaking up as you get
farther and farther away from the
station? That gradual weakening of

the signal is called attenuation, and
attenuation happens to any
electrical signal, including the ones
and zeroes we’re sending across the
wire.
Let’s say we have two hosts 175
meters apart, and the maximum
effective cable length is 100 meters.
Obviously, that’s going to be a
problem, since the signal will be
strong when it leaves the
transmitting host, but weak or
practically nonexistent when it
arrives at the other host.

That’s the problem repeaters helped
us resolve. A repeater takes an
incoming signal and then generates
a new, clean copy of that exact
signal.

A hub operates in the same fashion,
but the hub has more ports. That’s
pretty much the only difference
between the two. Some hubs have
greater capability than others, but a
basic hub is simply a multiport
repeater.
These hubs and repeaters seem
pretty sweet, right? Why would we
ever need anything more
complicated and expensive than
that?
To answer that question, let’s see

what happens when a hub is in the
middle of a simple little four-PC
network.

Using a hub here means that only
one PC can send data at a time,
because what we have here is one

giant collision domain, meaning
that data that one host sends can
collide with data sent by another
host. The result: All data involved
in the collision is unusable.
To prevent this, hosts on a shared
Ethernet segment such as this will
use Carrier Sense Multiple Access
with Collision Detection,
thankfully referred to as
CSMA/CD. Here’s the CSMA/CD
process:
A host that wants to send data
will first listen to the wire,

meaning that it checks the
shared media to see if it’s in
use.
If the media is in use, the host
backs off for a few
milliseconds before listening
to the wire again.
If the media is not in use, the
host sends the signal.
If two PCs happen to send
data at the exact same time,

the voltage on the wire will
change, indicating to the hosts
that there has been a data
collision.
In that situation, the PCs that
sent the data will generate a
jam signal, which indicates
to the other hosts on the
shared media that they
shouldn’t send data right
now.
The PCs that sent the data
will then invoke a backoff

timer, set to milliseconds.
When each host’s random
timer expires, they will each
begin the CSMA/CD process
from the beginning where
they listen to the wire. Since
the backoff timer value is
totally random, it’s unlikely
the two hosts will have the
same problem again.
This entire process happens pretty
quickly, but we’d prefer to have no
collisions at all, since collisions
slow down the network. With the
ultra-delay-sensitive voice and

video traffic today’s networks have
to handle, delays due to collisions
and retransmissions are totally
unacceptable – just another reason
you won’t see many repeaters and
hubs in today’s production
networks.
There’s another big issue with hubs
and repeaters, this one having to do
with broadcasts.
Just as the current network is a
single collision domain, tis also a
single broadcast domain. Every

single time one of those PCs on that
hub sends a broadcast, every other
PC on the hub is going to receive a
copy of that broadcast, even if that
PC doesn’t need or want the
broadcast.

I want to drive this into your brain
right now:
Everything we do on a router or
switch has a cost.
I don’t mean a financial cost. I mean
a cost in time, a cost to our
available processor power, and/or
a cost to our available bandwidth.
Let’s say there are 64 PCs attached
to that hub, and only 3 of the other
PCs ever need to get a copy of the

broadcast sent by that particular
PC.
That leads to several unnecessary
costs to our network:
The hub has to create and
send 60 unnecessary copies
of the data.
Each PC that doesn’t need the
broadcast still has to take the
time to examine the incoming
broadcast, because they don’t
know they don’t need it until

they do that.
The bandwidth required to
send these 60 unnecessary
copies adds up.
It’s a great idea to limit the scope of
our broadcasts. In other words,
limiting the transmission of
broadcasts to hosts that actually
need them. That’s a topic we’ll
come back to quite a bit in the next
section of the course.

Right now, it’s enough to see that
between the possible data
collisions and unnecessary
propagation of broadcasts, hubs and
repeaters have serious limitations
in today’s networks.
Two devices that can help us with
these collisions and broadcasts are
bridges and switches, and we’ll
cover those thoroughly in the next
section of the course!
Take a moment to join over 28,000
students in my free and almost-free

Video Boot Camps on Udemy!
There’s something for everyone,
and there’s a discount code on the
opening page for every paid course!
My students have made me the #1
individual instructor on Udemy out
of over 8000 teachers, and these
courses are the reason why!
Some free, some paid, all great!
See you there!

https://www.udemy.com/u/chrisbryan

Switching
Fundamentals And
Security
(Or, “I’d Rather Fight Than
Not Switch!”)
There was one more step between
hubs / repeaters and the move to
switches, and it was a giant step
forward.
The introduction of bridges meant
we could create smaller collision

domains, which in turn resulted in
fewer collisions. Sounds great, and
it was, but bridges didn’t
necessarily replace our hubs and
repeaters. Bridges would typically
be placed between multiple
repeaters and hubs, as shown in the
next illustration.

Having more collision domains may
sound like a bad thing at first, but
the more collision domains you
have, the fewer overall collisions.
In this network, we still have the
potential for collisions, but by

logically segmenting the network
with a bridge, the chance of
collisions is lessened.
Bridges don’t affect broadcasts.
When any host on this network
sends a broadcast, every other host
on the network will receive a copy.
It’s unlikely every other host on the
network actually needs that
broadcast, so we’re very interested
in limiting the scope of broadcasts.

Bridges were definitely a step up
from hubs and repeaters, but we
needed more help with collisions
and any help we could get with
broadcasts. We got all of that and
more with the introduction of

switches.
Let’s replace the hubs, repeaters,
and bridge in our network with a
single switch.

This is the universal representation
of a switch, and if you’re shown

one on an exam, you’ll be expected
to know it’s a switch without Cisco
telling you. Same goes for a hub and
bridge. Here’s the full lineup:

By connecting each host to a
separate switch port, we create a
collision domain for each host.
Collisions literally cannot occur!
Where we had one collision domain
with a hub or repeater, we now
have four separate collision

domains on our network by using a
switch.

In addition to eliminating
collisions, each host will now have

far more bandwidth available.
When hosts are connected to
individual switch ports, they no
longer have to share bandwidth
with other hosts. With the correct
switch configuration and network
cards, each host can theoretically
run at 200 Mbps (100 Mbps
sending, 100 Mbps receiving).
Cisco switch default settings are
great in many cases, but one thing
Cisco switches do not do by default
is break up broadcast domains.
Each host connected to that switch
is its own collision domain, but

they’re still all in one big broadcast
domain. We know what that means
– lots of unnecessary broadcasts!

This is one default setting you’ll
want to change, and we’ll see how
to do that later in this very section.

Before we move forward, let’s
review the key concepts of hubs vs.
switches.
With hubs, we have one big
collision domain consisting
of all connected hosts. With
switches, each individual
switch port is its own little
collision domain.
Hubs allow only one device
to transmit at a time, resulting
in shared bandwidth.
Switches allow hosts to

transmit simultaneously.
When one host connected to a hub
sends a broadcast, every other host
on the hub receives that broadcast
and we have no way around that.
Switches have the same behavior
by default, but we CAN do
something about it, and we will do
just that in the VLAN section of this
course.
Microsegmentation is a term
occasionally used in Cisco
documentation to describe the “one

host, one collision domain”
segmentation performed by
switches. It’s not a term I hear
terribly often today, but you might
see it in Cisco docs – or Cisco
exams.
The Frame Forwarding DecisionMaking Process
A Cisco switch will do one of three
things with an incoming frame:
Forward it
Filter it

Flood it
The entire decision-making process
is pretty simple. Having said that,
there’s a lot of information in this
section. Just take one of these three
processes at a time and you’ll have
this all mastered.
There’s one little oddity I want to
introduce to you, and this onequestion practice exam will do just
that:

When a frame enters a switch,
which of the following does the
switch look at first?
A. The source MAC address of
the frame
B. The destination MAC address
of the frame
It makes perfect sense that the
switch would look at the destination
address of the frame first. After all,
the switch wants to get that frame to
the right destination, and what
better way to do that than to look at

the destination address first, right?
Wrong!
The switch will look at the
destination MAC of the frame after
it looks at the source MAC address.
The logical question at this point is
“Why does the switch even care
where the frame came from?”
The answer: “Because source

addresses are how the switch
builds and maintains its dynamic
MAC address table.”
That’s not the only reason for this
behavior, as you’ll see in this
section, but it’s the major reason.
When we work with dynamic
routing protocols in this course,
you’ll see EIGRP and OSPF used to
build a routing table. The switches
have no equivalent to those routing
protocols, so the switches have to
build their MAC tables another

way.
We could build a MAC address
table with static entries, but that
approach has serious drawbacks:
Every time you add a host to the
switch, you’d have to remember to
make a static MAC address entry
for that host, and that’s really easy
to forget – and even easier to
mistype.
If a port goes down and you switch
the host connected to the bad port to
a good port, you won’t have full

connectivity until you add a new
static entry for that host’s MAC
address. It’s easy in the heat of
battle to forget to remove the old
entry, leading to future hassles when
someone connects to that port.
If I have a choice between letting
the hardware do the work and me
doing the work, I’ll let the
hardware do it every time. That
doesn’t make me lazy, it makes me
smart. It’s much more efficient to let
the hardware carry out dynamic
operations than forcing the admins
to handle everything statically.

Let’s take a look at how a switch
builds that all-important table, and
we’ll see each of those frame
forwarding options in action.
We’ll start with four hosts and one
switch, using a very odd topology
in part of our network to illustrate
one of those forwarding options.
Note that Hosts A and B are
connected to a hub, which in turn is
connected to a switch.
Each host will use its letter 12
times to make up its MAC address.

We’ll assume the switch has just
been added to the network, which
brings up another important point.
When you first power a switch on,
there will be a few entries in the

MAC address for the CPU. It’ll
look something like this:

SW1#show mac address-table
Mac Address Table
-----------------------------Vlan
Mac Address
--------------- -------All
0008.7de9.9800
All
0100.0ccc.cccc
All
0100.0ccc.cccd
All
0100.0cdd.dddd

Type
---STAT
STAT
STAT
STAT

Total Mac Addresses for this c

The only way the switch knows
where the hosts are is for you and I

to add a bunch of static entries
(bad) or let the switch learn the
addresses dynamically (good).
By the way, the MAC address table
is also known as the switching
table, the Content Addressable
Memory (CAM) table, and the
bridging table (even though it’s not
on a bridge).
Let’s begin with Host A sending a
frame to Host C.

The frame enters the switch on port
0/1, and the switch looks at the
source MAC address of the frame
and asks itself one question:
“Do I have an entry for this MAC
address in my table?”
There’s no grey area. There either
is an address or there isn’t. In this
case, since we just turned the
switch on, there’s no entry for aaaa-aa-aa-aa-aa in the MAC table.
The switch makes the entry, and our
MAC table now looks like this:

SW1#show mac address-table
Mac Address Table
------------------------------

Vlan
Mac Address
Ty
--------------- --------All
0008.7de9.9800
ST
All
0100.0ccc.cccc
ST
All
0100.0ccc.cccd
ST
All
0100.0cdd.dddd
ST
1
aaaa.aaaa.aaaa
DY
Total Mac Addresses for this c

Note the CPU entries are static, but
the Host A entry is dynamic.
At long last, we get to the frame
forwarding decision! Here are our

choices again:
Forward
Filter (drop)
Flood
The switch now examines the
destination MAC address “bb-bbbb-bb-bb-bb” and asks itself
another simple question:
“Do I have an entry for this
destination MAC address in my
MAC table?”

When the answer is “no”, as it is
here, the switch floods the frame. A
copy of that frame will be sent out
every single port on the switch
except the port the frame came in
on.
This particular type of frame is an
unknown unicast frame, since the
frame is a unicast (destined for one
particular host), but the port that
leads directly to that destination is
unknown.

Basically, the switch is saying “I
have no idea where this destination
host is, so I’ll just make sure it gets
where it should by sending a copy
out EVERY port except the one it

came in on.”
Flooding ensures the frame will get
where it needs to go, and it also
guarantees the other hosts in this
LAN will get the frame, and that’s a
huge waste of bandwidth and
switch resources.
Flooding frames doesn’t seem like
such a big deal, but we really want
to limit flooding due to the costs we
talked about earlier. If this is a 64port switch, and we have a host on
every port, that means the switch
has to send 63 copies of any
flooded frame, 62 of which are

unnecessary.
Nothing wrong with flooding
frames as you add a host or a
switch to a network – it really can’t
be avoided – but after that, we’d
rather not have a lot of flooding.
And as you’re about to see, we
won’t.
Host C will now respond to Host A
with a frame of its own.

The switch begins the process by
checking out the source MAC
address of that frame. Will there be
an entry for cc-cc-cc-cc-cc-cc?

SW1#show mac address-table dyn
Mac Address Table
------------------------------

Vlan
Mac Address
Type
Ports -------------- ------1
aaaa.aaaa.aaaa
DYNAM
Total Mac Addresses for this c

Nope! In that case, the switch
creates one:

SW1#show mac address-table dyn
Mac Address Table
------------------------------

Vlan
Mac Address
Typ
--------------- -------- --1
aaaa.aaaa.aaaa
DYNA
1
cccc.cccc.cccc
DYNA

Now we’ll start to see the dynamic
entries in that table work for us.
The switch now checks the MAC
table for the destination address of
aa-aa-aa-aa-aa-aa, and there is an
entry, showing that host to be found
off port 0/1.
The address is known, so there’s no
reason to flood the frame. The
frame will only be forwarded out
port 0/1. Much more efficient than
flooding, and easier on our
network!

If Host A responds to Host C, the
switch will have an entry for Host
C’s MAC address where it didn’t
have one earlier. Frames from Host
A to Host C will now be sent
directly out port 0/2, rather than
being flooded.

Let’s jump ahead to another
scenario, where the topology is the
same and the switch has a dynamic
MAC entry for each host.
Please note this is not a topology
you’re going to see very often in
production networks, if at all. It’s
strictly presented here to illustrate
the third option for the switch’s
frame forwarding process.
On this particular network, we have

an unusual setup where Hosts A and
B are connected to a hub that in turn
is connected to a switch. To the
switch, both hosts are found off port
0/1, and that leads us to our third
possibility for incoming frames.
When Host A sends a frame to Host
B, Host B will get a copy of it
through the hub, as will the switch.
The switch checks the source MAC
address, sees an entry, checks the
destination MAC, sees an entry …
and then realizes both the source
and destination are found off the
same port!

On the (very) rare occasion this
happens, the switch will filter the
frame, which is a fancy way of
saying the switch will simply drop
the frame.

Let’s review these three switching
decisions and when the switch uses
each one:
Flooding happens when the switch
has no entry for the frame’s
destination MAC address. When a
frame is flooded, a copy of it is sent
out every port on the switch except
the one it came in on. Unknown
unicast frames are always flooded.
Forwarding happens when the
switch has an entry for the frame’s
destination MAC address. When a

frame is forwarded, it’s sent out
only the port indicated by the MAC
address table.
Filtering happens when the source
and destination MAC addresses are
known to the switch and are found
off the same port. Technically,
filtering also occurs when a frame
is not sent out a port because the
destination is a known unicast.
Filtering = not sending a frame out a
port.

You’re probably tired of hearing the
phrase “except the port it came in
on”, but it is important. We don’t
get to say “never” in networking
very often, but this is one of those
times:
Switches never send a frame back
out the same port the frame came
in on.
In addition to flooded frames,
there’s another type of frame sent
out every port except its arrival
port, and that’s a broadcast frame.

Broadcast frames are intended for
all hosts, and have a destination
MAC address of ff-ff-ff-ff-ff-ff
(also expressed as FF-FF-FF-FFFF-FF. Case doesn’t matter in hex
addresses).
Those Dynamically Learned MAC
Addresses (Again)
When I was going on about
dynamically learned MAC
addresses earlier, I’m sure this
question entered your mind:

“Just how long do those dynamic
addresses STAY in the table?”
Great question! The default aging
time for dynamically learned MAC
addresses is 5 minutes, and that
timer is reset when a frame comes
in with that particular source MAC
address.
In short, as long as the switch hears
from a host within any given fiveminute period, the host’s MAC
address stays in the table.

As always with time-based IOS
commands, be sure to use IOS Help
to check the unit of time that
particular command uses.
For example, if I asked you to set
that MAC address aging time to 10
minutes, and you already knew the
IOS command to change that value
is mac address-table aging-time,
you might be tempted to enter the
following command:

mac address-table aging-time 1

And that would be wrong. Really
wrong, because IOS Help shows us
the time unit for this particular
command is seconds, which means
the proper command is….

SW1(config)#mac-address-table
<0-0>
Enter 0 to disabl
<10-1000000> Aging time in sec
SW1(config)#mac-address-table

I strongly recommend you use IOS
Help to check any numeric value.
Time-related commands use
different combinations of seconds,
minutes, hours, days, etc. - you get
the idea. Data-based commands use

megabits, kilobits, and other bitrelated measurements.
In short: Use IOS Help! That’s why
it’s there!
Hopping down from my soapbox,
let’s continue…
Switches dynamically adapt their
MAC address table when there’s a
physical change to that switch’s
connections, and this saves you a
LOT of work and hassle. Take this

switch, where Host D is connected
to port 0/3.

As sometimes happens, port 0/3
goes down, and we need to get the
host connected to that switch back
on the network ASAP.
(I guarantee when a port goes

down, the user connected to that
port will be a ridiculously highranking person in your company.)
With dynamic MAC entries, all we
have to do is plug the cable into an
unused port, and we’re all set. As
soon as frames come in from Host
D onto the new port, the switch
realizes this and does two things:
Removes the Host D-to-port
0/3 mapping from its MAC
table
Adds the Host D-to-port 0/4
mapping to its MAC table

If we relied on static entries, we’d
have to do that removal and
addition manually. Remember, tis
not lazy to let the switch do the
work of maintaining the MAC table
– tis smart!
Also, the more manual entries you
create, the higher the odds of

mistyping an entry, which leads to
more troubleshooting and more time
spent.
In addition to the frame forwarding
decision, the switch has to make a
decision on how to process the
frames. This is something you and I
as network admins aren’t going to
spend time configuring, but as future
CCENTs and CCNAs, we need to
know how each processing method
works.
Let’s get to it!

The Frame Processing Methods

They’re short and simple:
Store-and-forward
Cut-through
Fragment-free
Just about everything in networking
has pluses and minuses, and that’s
true with each of these methods.
Store-and-forward is just what it
sounds like. The entire frame is

stored by the switch, and then
forwarded. We need to keep our eye
on two particular values in the
frame -- the Frame Check Sequence
and the destination MAC address.

The FCS allows the recipient to
determine if the data was corrupted
during transmission, and when
store-and-forward is in use, the
storage of the entire frame allows
the switch to check the FCS before
actually forwarding the frame. This
allows the greatest level of error
detection of our three processing
methods – and we love error
detection!
With cut-through switching, the
switch reads the MAC addresses on
the incoming frame and then begins
to forward the frame even as part of

it is still being received. The FCS
is not checked, so there is zero
error detection.
The middle ground between storeand-forward and cut-through is
occupied by fragment-free
processing. This processing makes
the assumption that if there’s
corruption in the frame, it’s in the
first 64 bytes. As you’d guess, that’s
exactly where fragment-free
processing checks for problems! If
no corruption is found in the first 64
bytes, the rest of the frame is
assumed to be free of errors, and

the forwarding process begins.
Comparing these three methods is
like comparing TCP and UDP.
Everything about one particular
method sounds great – store-andforward, in this case. If this method
gives us total error detection, and
the others do not, what’s the
tradeoff? Why not always use storeand-forward processing?
The tradeoff is time. Store-andforward is the slowest of the three
methods, with cut-through being the

fastest and fragment-free right in the
middle.
Let’s review the ups and downs of
these methods:
Store-and-forward: Best error
detection. Slowest of the three.
Cut-through: No error detection.
Fastest of the three.
Fragment-free: The middle ground

in both level of error detection and
time.
It’s time to head for the wonderful
world of Virtual LANs! Don’t let
the word “virtual” intimidate you.
VLANs are simple to create and
easy to work with.
And they’ll be all over your
production networks along with
your CCENT and CCNA exams, so
let’s hit ‘em!

Virtual LANs (VLANs)

One major reason for creating
VLANs goes back to a default
switch behavior. We’ll quickly
review that particular behavior
before we move on to VLAN
creation.
We have two default switch
behaviors that combine to give us a
bit of a headache:
All hosts connected to the

switch are on the same
physical Local Area Network
(LAN).
When a switch receives a
broadcast, it sends a copy of
that broadcast out every port
except the one the broadcast
came in on.

No big deal with a four-host
network, but we don’t have many

four-host networks in this world or
the planet Zeutron.
If that’s a 64-port switch, 63 hosts
are going to get a copy of a
broadcast sent by any host on that
switch, and it’s unlikely all 63 hosts
need it. There’s a lot of wasted
bandwidth and wasted network
resources right there.
As more and more hosts are added
to the network, you end up with
more and more broadcasts, and
soon the switch is so busy handling

broadcasts that it can’t carry out
basic switching functions in an
efficient manner, and the network
ends up coming to a standstill.
This continual, gradual increase in
broadcasts is a broadcast storm,
and it can sink your network.
A broadcast storm isn’t something
that strikes out of nowhere. It’s a
gradual degradation of the switch’s
capability to handle its basic
functions. Limiting the scope of
broadcasts in our network is a big

step toward preventing broadcast
storms.
To illustrate exactly how Virtual
LANs help us do just that, I’ll
assign an IP address to each of our
hosts, and then we’ll run some show
commands on our live Cisco
switches!

We’re going to use pings throughout
this course to test connectivity. If
you haven’t seen a ping before, it’s
a fundamental connectivity test
where a series of packets is sent to
the remote address we specify. If
the packets leave and packets come

back from that pinged address, the
test is passed!
Much more on pings throughout the
course.
We’ll send pings from 172.34.34.4
to the other three hosts. I’m using
Cisco routers for our hosts, so these
pings will look different than any
you’ve run on a PC.

Host4#ping 172.34.34.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
!!!!!
Success rate is 100 percent (5

Host4#ping 172.34.34.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
!!!!!
Success rate is 100 percent (5
Host4#ping 172.34.34.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
!!!!!
Success rate is 100 percent (5

I hate sentences that end with five
exclamation points, but I love pings
that do so. When you see that, you
know you have IP connectivity to
the remote host you pinged.

I did go to each host and send pings
to each of the other hosts, and we
do have connectivity all the way
around. With that connectivity
verified, let’s have our first look at
a Cisco switch configuration.
I occasionally have a student tell
me their Cisco network doesn’t use
VLANs, but that just means they
haven’t configured additional
VLANs. By default, VLAN 1
already exists on Cisco switches,
and all ports are members of that
VLAN. VLAN 1 is so important,
you can’t even delete it from the

switch.
A key command to view and verify
VLAN configuration and operation
is show vlan brief, so we’ll start
with that one.
SW1#show vlan brief

VLAN Name
---- ----------------------------------------------1
default
Fa0/2, Fa0/3, Fa0/4
Fa0/6, Fa0/7, Fa0/8
Fa0/10

1002
1003
1004
1005

fddi-default
token-ring-default
fddinet-default
trnet-default

VLAN 1 is even named “default”!
Under “ports”, you can see the 10
ports that are members of this
VLAN, and at the bottom of this
output you see the other four default
VLANs. You may never use them,
but it’s a really good idea to have
that numeric range of default
VLANs memorized.
When a host in a VLAN sends a

broadcast, a copy of that broadcast
will be sent out every port that is a
member of that VLAN.
Sounds familiar, right? But there’s
good news – we can create multiple
VLANs that will help us limit the
number of broadcasts forwarded
throughout our network. Each VLAN
is a separate broadcast domain.
For example, say we want only
Host 2 to receive any broadcast
sent by Host 4, and vice versa. We
can make that happen by placing

those hosts into their own VLAN!
We do that at the port level with the
switchport access vlan command:
SW1(config-if)#interface fast

SW1(config-if)#switchport acce
% Access VLAN does not exist.
SW1(config-if)#interface fast
SW1(config-if)#switchport acce

If you try to put a port into a VLAN
that doesn’t yet exist, the switch is
kind enough to create that VLAN for
you.

Now Hosts 2 and 4 are in VLAN
24, and Hosts 1 and 3 are still in
VLAN 1. We’ll verify that with
show vlan brief:

VLAN Name

---- ----------------------------------------------1
default
Fa0/3, Fa0/5, Fa0/6
Fa0/8, Fa0/9, Fa0/10
24 VLAN0024
Fa0/4
1002 fddi-default
1003 token-ring-default
1004 fddinet-default
1005 trnet-default

This simple little configuration
does a lot to limit the scope of
broadcasts! Previously, when all
four hosts were in the same VLAN
and one host sent a broadcast, the

switch would make sure every other
host on the switch got a copy of it.
Now, when any member of either
VLAN sends a broadcast, only the
other members of that particular
VLAN get a copy of it.
Using the 64-port switch example,
if we had 32 ports in each VLAN,
the load on the switch would be cut
in half every time a host sent a
broadcast. Instead of sending out 63
copies, the switch would send out
31 copies of a broadcast sent out by
any host. That’s a big load taken off
our switch, and a lot of saved

bandwidth.
You already know that in
networking, there’s almost always a
tradeoff. Something this good must
have a drawback, right?
Well, yeah, and here it is. If Host 4
sends a broadcast right now, Hosts
1 and 3 won’t see it. What about
other types of traffic, like pings?
Let’s see:
Host4#ping 172.34.34.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
.....
Success rate is 0 percent (0/5
Host4#ping 172.34.34.2
Type escape sequence to
abort.

Sending 5, 100-byte ICMP Echos
!!!!!
Success rate is 100 percent (5
Host4#ping 172.34.34.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
.....
Success rate is 0 percent (0/5

When you ping a remote host and
get five periods back, that’s bad.
There’s no connectivity to the
pinged destination, and that’s what
we see here for inter-VLAN traffic.
Host 4 can still ping Host 2, since
they’re in the same VLAN, but Host
4 can no longer ping hosts in the
other VLAN.
Traffic cannot travel from one
VLAN to another unless a Layer 3
device gets involved. That’s likely
to be a router, but it doesn’t have to
be.

There are two techniques for interVLAN communication you should
be ready to configure and
troubleshoot on the CCENT and
CCNA exams:
Layer 3 Switches (not a
misprint)
“Router On A Stick” (not a
joke or misprint)
Since both of these involve routing,
I want you to go through all the
routing sections in this course
before we tackle those. For that
reason, these two features are

covered thoroughly in a later
section of the course.
Right now, let’s take a little trip
to…
The Planet Of The Models
Network models, that is! (Sorry
about that.)
Not all switches are alike – some
are a lot more powerful than others,

some have different capabilities
than others – and it’s vital to put
your more powerful switches in the
proper place in your network.
That’s where the Cisco 3-Layer
Switching Model comes in.
The first time you hear the term
campus network, the word campus
may make you think of a college or
university. While you might find a
campus network there, this term is
used to describe any network that
connects physically close buildings.

The Cisco Switching Model
consists of three layers:
Access switches, those
closest to the end users
Distribution switches, the
switches that connect
Access-layer switches to
Core-layer switches
Core switches, your
powerhouse switches.

This model’s purpose is totally
different than that of the OSI or TCP
models, and maps to neither.
In the following example, traffic
that goes from a PC in BLDG1 to a
PC in BLDG2 must go through at
least one switch in each layer. End

users are connected only to Accesslayer switches.

This particular design gives us
quite a bit of redundancy. If one
path between the buildings goes
down, we have other available
paths. Even if one of our core
switches goes down, we can still

get data from building to building,
from host to host.
Redundancy is a fancy way of
saying “we’ve got a backup plan”,
and in networking and in life, we’ll
take as many backup plans as we
can get!
We need a process that allows us to
pick the fastest path between
switches while having those backup
paths standing by, and luckily, we
have such a process – the Spanning
Tree Protocol (STP). More about

STP coming up soon.
Right now, let me introduce you to
another vital switching topic:

Basic Switch Security

“Basic” security might not sound
exciting, but these fundamentals can
really save your network (and your
behind!)
The first tip is about as basic as it
gets.
Put locks between your hardware
and people!
Your server room should be locked.
Ideally, your server and router
cabinets should be secured as well,
but that’s only going to happen in a
perfect world. Keep at least one

locked door between nonnetworking personnel and your
network hardware.
Unused VLANs - An Often
Overlooked Security Feature
Cisco switch ports have some
undesirable defaults:
They’re open, where router
interfaces are shut by default

They’re actively attempting
to trunk by default, meaning
they are available for
connection to another switch
(newer Cisco models don’t
have this issue)
All ports are in VLAN 1, and
that’s common knowledge
These are undesirable defaults
when it comes to unused ports on a
switch. From top to bottom, here’s
how we can change those defaults
to increase switch security:

Close unused ports with the
shutdown command
Prevent the port from trunking
with the switchport mode
access command
Place the port into an unused
VLAN
I personally just close unused
switch ports, but both Cisco and I
recommend strongly that you either
close such ports, prevent them from

trunking, or create a VLAN strictly
for those ports and place them into
that VLAN. No ports that are
actually connected to hosts should
be in that VLAN.
Port Security
When we learned how the switch
builds its MAC address table, I
mentioned (several times) that the
switch will examine the source
MAC address of a frame before
anything else.

I’m mentioning it again, and with
good reason. That behavior makes
port security possible!
Let’s assume you have a VP that
uses a laptop with a MAC address
of bb-bb-bb-bb-bb-bb. She
suspects that someone else is using
her office while she’s gone, and she
wants to make sure that no other
laptop except hers can connect to
the network from her office. We can
accomplish this with port security.
When you enable port security, the

switch will first inspect the source
MAC address of an incoming
frame, as usual.
If the incoming source MAC
address is considered secure, the
user will be able to access the
network. If the source MAC is
considered non-secure, the port
will take one of several actions.
The source MAC address of the
incoming frame really acts as a
password.
In this lab, we’ll set a secure MAC

address of aa-aa-aa-aa-aa-aa on
interface fast 0/2 and see what
happens when a host with a
different MAC address connects to
the port.

SW1(config)#int fast 0/2
SW1(config-if)#switchport port
aging
Port-security a
mac-address Secure mac addr
maximum Max secure addresse
violation
Security violat
<cr>

SW1(config-if)#switchport port
SW1(config-if)#switchport port
H.H.H
48 bit mac address
sticky Configure dynamic se

SW1(config-if)#switchport port

aaaa.aaaa.aaaa

Take note of the following:
Port security is off by default. To
enable it, use the switchport portsecurity command. Without that, the
other commands are useless.
Note the format of the MAC
address in the port-security
command.
I didn’t set the number of secure

MAC addresses. The default
number is one, and that’s enough for
our purposes right now.
I didn’t set the violation mode. The
default mode is shutdown, and
we’ll look at the details of all three
modes in just a few minutes!
After connecting a host with the
MAC address 00e0.1e68.91f0 to
port 0/2 and generating some traffic
through that port, this is the result of
show interface:

SW1#show int fast 0/2
FastEthernet0/2 is down, line

With the default settings for port
security left intact, this is what
happened when a frame came in
with a non-secure source MAC
address. The port was shut down
and put into err-disabled state. To
get this port back up and running,
you have to clear up the problem
AND shut that port down, then
reopen it.
We know in our hearts that port

security made that happen, but how
can we verify that? With these two
show port-security commands!
Show port-security gives you some
good, fundamental information.

SW1#show port-security
Secure Port MaxSecureAddr Cu
SecurityViolation Security Ac
(Count)
------------------------------------------------Fa0/2
1
Shutdown
------------------------------------------------Total Addresses in System (exc

: 0
Max Addresses limit in System
port) : 1024

To get even more details, run show
port-security interface.
SW1#show port-security int
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
SecureStatic Address Aging
Maximum MAC Addresses
Total MAC Addresses
Configured MAC Addresses
Sticky MAC Addresses
Last Source Address

fas
: E
: S
: S
: 0
: A
: D
: 1
: 1
: 1
: 0
: 0

Security Violation Count

: 1

From top to bottom, you can see that
port security is enabled on fast 0/2,
the port is secure AND shut down,
the maximum number of MAC
addresses, the number of static
(“configured”) and dynamic
(“sticky”) MAC addresses seen on
that port, and the exact MAC
address that caused the port to shut
down!
I’ll remove the previous config, and
we’ll configure the switch to learn

a single dynamic MAC address on
that same port, and to make that
dynamically learned address the
secure address. (I’ve also reset the
port that was shut down.)

SW1(config)#int fast 0/2
SW1(config-if)#no switchport p
aaaa.aaaa.aaaa
SW1(config-if)#no switchport p

SW1(config)#int fast 0/2
SW1(config-if)#switchport port
SW1(config-if)#switchport port
aging
Port-security a
mac-address Secure mac addr
maximum Max secure addresse
violation
Security violat
<cr>

SW1(config-if)#switchport port
H.H.H
48 bit mac address
sticky Configure dynamic se

SW1(config-if)#switchport port

A “sticky” MAC address is one
learned dynamically by the switch
port. In this case, the very next
source MAC address the port sees
will be the single secure MAC
address.
After sending traffic through that
port from the same host we used in
the previous lab, here are the

results of show port-security
interface:
SW1#show port-security int
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
SecureStatic Address Aging
Maximum MAC Addresses
Total MAC Addresses
Configured MAC Addresses
Sticky MAC Addresses
Last Source Address
Security Violation Count

The port is secure, it’s up, there’s
one sticky MAC address, and you

fas
: E
: S
: S
: 0
: A
: D
: 1
: 1
: 0
: 1
: 0
: 0

see the last source address. All is
well!
These two scenarios lead us to the
musical question, “Can you have a
port learn sticky addresses AND
configure a static address or two?”
You certainly can! You just have to
leave room for the sticky learning
when you configure the number of
secure MAC addresses. Let’s say
your port security configuration has
two requirements:

The address aa-aa-aa-aa-aaaa must be configured as a
statically secure address.
The next source MAC
address the port sees should
also be learned as a sticky
secure address.
Here’s how we tackle that:

SW2(config)#int fast 0/2
SW2(config-if)#switchport mode
SW2(config-if)#switchport port
SW2(config-if)#switchport port
aaaa.aaaa.aaaa

SW2(config-if)#switchport port

SW2(config-if)#switchport port
aging
Port-security a
mac-address Secure mac addr
maximum Max secure addresse
violation
Security violat
<cr>

SW2(config-if)#switchport port

We configured one static secure
address, enabled sticky learning,
and left room for one address to be
learned via the maximum 2
command.

After sending traffic through that
port successfully, we’ll verify our
config with show port-security int
fast 0/2.
SW2#show port-security int
Port Security
Port Status
Violation Mode
Aging Time
Aging Type
SecureStatic Address Aging
Maximum MAC Addresses
Total MAC Addresses
Configured MAC Addresses
Sticky MAC Addresses
Last Source Address
Security Violation Count

fas
: E
: S
: S
: 0
: A
: D
: 2
: 2
: 1
: 1
: 0
: 0

Looks good! Port security is
enabled, the port is secure and up,
and we met our requirements – we
have one statically configured
secure MAC (“configured MAC
addresses”), and the switch has
learned one secure address
dynamically – the one shown as
“last source address”.
Let’s take a look at those violation
mode options:

SW2(config-if)#switchport port
protect
restrict

Security violation p
Security violation r

shutdown

Security violation s

IOS Help often gives us a great
description of the options we’re
looking at. This isn’t one of those
times, so here’s the description we
need…
The default mode is shutdown, and
this mode shuts the port down
(duh), transmits a message to the
log indicating the action taken, and
drops the violating frames. The
interface status will be errdisabled, (short for error-disabled)
meaning it must be manually
reopened. The LED on the switch

above the disabled port will go
dark.
restrict drops the violating frames
and transmits a message to the log
indicating an issue, but does not
shut the port down.
protect simply drops the violating
frames.
Port security is a simple and
powerful feature, and here’s another
one running on our Cisco switches

– the Spanning Tree Protocol.
A Taste Of STP
Redundancy is a fancy way of
saying “we’ve got a backup plan”,
and in networking, we’ll take as
many backup plans as we can get!
We can never assume that a switch
will be 100% operational forever,
because it just doesn’t work that
way. (Not even Cisco switches are
infallible!)

Whether we’re dealing with
switching or routing, we always
want a redundant path between any
given two points. That allows us to
avoid a single point of failure, a
term used for a point in the network
that, if broken, brings the network to
a halt.
Speaking of redundancy, in the
following diagram there are
multiple paths from Host A or Host
B to Host C or Host D.

Right now, we have several
possibilities for paths for sending
frames from Host A to Host D:
Sw1 - Sw3
Sw1 - Sw2 - Sw3
Sw1 - Sw4 - Sw3

Sw1 - Sw2 - Sw4 - Sw3
Sw1 - Sw4 - Sw2 - Sw3
If Sw2 or Sw4 goes down, frames
can still be sent between the four
hosts. Let’s assume that Sw2 is
accidentally powered down. (As
the philosopher Christopher
Moltisanti said, “It happens.”)

There are still paths open for the
hosts to successfully transmit
frames to each other. Even if Sw4
suddenly went down in addition to
Sw2, the link between Sw1 and
Sw3 would be enough to allow the
hosts to send frames to each other.
Now that’s redundancy!

Often, a networking feature,
service, or protocol will deliver a
great benefit and a potential
problem. In this case, our redundant
switching network could be subject
to switching loops.
Let’s bring Sw2 and Sw4 back into
our network.

The good news: We have multiple
paths between hosts on either side
of the switches, which gives us
redundancy.
The bad news: We have multiple
paths between hosts on either side
of the switches, which gives us the
possibility of switching loops.
A switching loop forms when a
frame is transmitted and ends up
being sent back and forth between
the same switches, never reaching
its destination.
This can happen for various reasons
- a corrupt MAC table, duplicate
MAC addresses on network hosts

(due to programmable network
cards that allow manual assignment
of MAC addresses), or destination
hosts being unavailable. None of
these are common, but they do
happen.
A switching loop looks much like
this:

Here’s what happened:
Host A sends a frame to Host
D, and it arrives at Sw1
Sw1’s MAC table says to
reach Host D, the frame
should be forwarded to Sw4

Sw4’s MAC table says to
reach Host D, the frame
should be forwarded to Sw2
Sw2’s MAC table says to
reach Host D, the frame
should be forwarded to Sw1
That forwarding process goes on
and on, with the frame just circling
in a logical loop, never reaching its
destination.
Cisco switches use the Spanning
Tree Protocol (STP) to prevent
switching loops, and STP is
enabled by default. You’ll learn
much more about STP in your

ICND2 studies, but you need to
know its basics now.
STP will determine a loop-free path
for frames, and ports that are not on
that path will be placed into
blocking mode.
In our previous example, STP
would determine a “best path” from
Host A to Host D, and would use
only ports along that path to
transport frames from A to D.
If the best path becomes
unavailable, STP would quickly
recalculate the metrics to determine
the new best path, and ports along
that path would be brought out of

blocking mode.
Do not assume that the physically
shortest path from one host to
another in a switching network is
the path STP will choose as best.
STP uses port speeds along a path
to determine the port costs and the
best paths.
This is strictly an overview of STP,
and you will learn much more about
it during your ICND2 and CCNP
studies. In the meantime, you now
know what a switching loop looks

like, and that STP’s primary
purpose in a switching network is
to prevent those loops from
forming. STP is on by default, and I
strongly suggest you keep it on.
Starting Your Switch
Troubleshooting At Layer 1
A switch is a Layer 2 device, but
you should begin your
troubleshooting at Layer 1. With
that in mind, there are some lights
on the front of a typical Cisco
switch that’ll help you nail switch

issues quickly.
Here are the panels for the Cisco
2950 and 2960 switch models, in
that order:

You’ll find these lights on the front
left of these particular switch
models.
If all of these lights are out, there’s
a great chance the switch is not
getting any power. Check the

socket. Plugs can come loose over
time, and a plug that looks secure in
the socket may not be secure enough
to deliver power.
SYST: The System light
No light: The switch is off.
Green light: Up and running!
Amber light: Uh oh. We have
power, but something else is wrong

(I know that’s not much to go on, but
it’s a starting point!)
RPS: Redundant Power Supply
status.
Off: Well, your RPS is off. Or you
don’t have one.
Solid green: Connected and ready
to roll.
Flashing green: Connected, but

currently supplying power to
another device, so it can’t help your
switch right now.
Solid amber: The RPS itself is in
standby OR in fault.
Flashing amber: Internal power
supply of a switch has failed and
the RPS is getting power to that
switch.
MODE: You’ll see a green light on
either STAT, DUPLX, or SPEED,

and the light toggles through the
three as you continue to press the
MODE button.
STAT: If this one’s green, it means
the individual STATUS light now
displayed for each port is accurate.
DUPLX: If green, means the
individual DUPLEX light now
displayed for each port is accurate.
SPEED: If green, indicates each
individual SPEED light for each

port is accurate.
As you view the port status, duplex,
and speed values via the MODE
button, the individual port LEDs
will change. Here’s what the port
LED indicates for all three of these
values:
STATUS:
Flashing green: Traffic going
through interface properly

Solid green: The port’s up, but no
traffic is going through the port
Flashing Amber: Blocked by STP
(not necessarily a bad thing)
Off: Port is not physically up (may
be administratively shut down)

DUPLEX:
Green: Port is running at full-

duplex
Off: Port is running at half-duplex

SPEED:
Flashing green: Port running at Gig
Ethernet speed
Solid green: Port running at Fast
Ethernet speed

Off: Port running at Ethernet speed
Watch that last one. It’s really easy
to look at an off LED and think
there’s a problem.
Now that we know our switches are
up and running properly, we need to
be sure they can communicate with
each other. We do that over trunks.
Like TCP and UDP, this is a feature
that works beautifully when you
stick with the defaults. For our

CCENT and CCNA exams, we have
to be 100% crystal clear on
trunking operations, and that
includes the similarities and
differences with our two trunking
protocols. Let’s jump right in!
Trunking
Trunking is the process of allowing
frames to flow between physically
connected switches. A tag
indicating the destination VLAN is
placed on the frame by the
transmitting switch (“frame

tagging”).
In the following network, we have
two hosts in VLAN 10, and they’re
connected to separate, trunking
switches. A frame would be tagged
“VLAN 10” before being sent
across the trunk. When the receiving
switch processes that incoming
frame, the switch knows that frame
should be distributed only to
members of VLAN 10.
This allows members in the same
VLAN to communicate when they

are physically connected to
different switches, which is a
common need since VLANs can and
usually do span multiple switches.

We need the help of a trunking
protocol to build this trunk. Not all

Cisco switches support both of
these protocols, but for your CCNA
and CCENT exams, it’s an excellent
idea to know them both and the
differences between them.
The Inter-Switch Protocol(ISL) is
a Cisco-proprietary trunking
protocol, meaning it can only be
used between two Cisco switches.
The entire frame is encapsulated
before transmission across the
trunk.
IEEE 802.1Q, generally known as

“dot1q”, is the industry standard
trunking protocol. (“Industry
standard” is a fancy way of saying
“everybody’s switches can run
this”.) If a non-Cisco switch is
involved in the trunk, this is the
trunking protocol to use.
Dot1q does not encapsulate the
entire frame. Instead, a 4-byte value
containing the VLAN ID is added to
the Ethernet header.
The key difference between the two
is the way they handle - or do not
handle - the native vlan. By default,
the native vlan is VLAN 1. The
native vlan is the “default vlan”.

When dot1q is ready to transmit a
frame destined for the native vlan
over the trunk, the protocol will not
put that 4-byte value on the frame.
Instead, the frame is transmitted
“as-is”. This helps to cut down
even more on overhead.
When the receiving frame sees there
is no VLAN tag on the frame, it
assumes the frame is intended for
the native vlan, and it is forwarded
accordingly. Dot1q allows for a
different VLAN to be selected as
the native VLAN.

ISL doesn’t even know what a
native VLAN is! Worse, every
single frame transmitted over an ISL
trunk will be encapsulated. That
means a lot of additional overhead
as compared to dot1q.
Summing up:

ISL is the Cisco-proprietary
trunking protocol. ISL
encapsulates every frame
before it crosses the trunk,
and doesn’t recognize the
native VLAN concept.
Dot1q is the industry
standard, places only a 4byte header onto a frame, and
won’t even do that if the
frame is destined for the
native VLAN.
ISL is so clunky that many Cisco
switches don’t support it, including
the popular home lab 2950 and

2960 switches.
Access Ports, Trunk Ports, And
Trunk Port Settings
A Cisco switch port is going to be
an access port or a trunk port. It
cannot be both.
An access port belongs to one and
only one VLAN. Once you
configure a port as an access port,
that port cannot trunk.
The default behavior of a trunk port
is that it is a member of all VLANs,
but you will not see this indicated
by show vlan brief. Here’s the

output of that command on our
switch where fast0/11 and 0/12 are
trunking (ports 9 and 10 removed
for clarity):

SW1#show vlan br
VLAN Name
---- ------------------------------------------1
default
Fa0/2, Fa0/3, Fa0/4
Fa0/6, Fa0/7, Fa0/8
1002 fddi-default
1003 token-ring-default
1004 fddinet-default
1005 trnet-default

Notice that 0/11 and 0/12 are

missing from the port list. They’re
seen with the show interface trunk
command.

SW1#show interface trunk
Port
Mode
Encap
Native vlan
Fa0/11
desirable
802.1
Fa0/12
desirable
802.1
Port
Fa0/11
Fa0/12

Vlans allowed on t
1-4094
1-4094

Port
Fa0/11
Fa0/12
Port
Fa0/11
Fa0/12

Vlans allowed and
1
1
Vlans in spanning
1
none

Let’s use IOS Help to look at our
trunking options. We have several
options, but they’re not all visible
in one place.

SW1(config-if)#switchport mode
access

Set trunking mode to

dynamic
trunk

Set trunking mode to
Set trunking mode to

The top choice refers to access
ports. When you configure a port as
an access port, this is in effect
turning trunking OFF.
The dynamic option will
dynamically negotiate trunk mode,

while the trunk option
unconditionally turns trunking on for
this port. dynamic has a few
options we need to know as well.

SW1(config-if)#switchport mode
auto

Set trunking mode dy

desirable Set trunking mode dy

We have dynamic auto and
dynamic desirable, and these
options are generally referred to
simply as “auto” and “desirable”.
There’s one more “hidden” trunk
port setting. Note this is an

interface-level command.

SW1(config-if)#switchport none

Therefore, according to IOS Help,
we actually have five options for
trunk ports.
On means the switchport is
unconditionally trunking, whether
the other end of the trunk likes it or
not.
Off means the port will not trunk
with the remote partner under any
circumstances. This mode is the
result of making a port an access

port.
Desirable means the port will
actively attempt to trunk. If the
remote port is in on, desirable, or
auto mode, a trunk will result.
Auto means the port will trunk, but
the other side must initiate trunking.
If the remote port is in desirable or
on mode, a trunk will result. If both
sides are in auto mode, no trunk
will result.

Finally, nonegotiate means the
local port will go into permanent
trunking mode, but Dynamic
Trunking Protocol (DTP) frames
are not sent across the trunk.
There’s a slight difference in the
default trunk port mode between
two popular Cisco home lab
switches. The 2950 defaults to
dynamic desirable, where the 2960
(and most new Cisco switches)
default to dynamic auto. Those of
you who own 2950s or studied for
the previous version of the exam,
note the change!

Filtering VLAN Traffic Allowed
Across The Trunk
We can filter traffic going across
our trunks on a per-VLAN basis.
Before we get to the commands that
allow you to make this happen, let’s
talk about why you might want to
use this option.

In this network, there’s no reason to
send VLAN 30 traffic to the switch
that only has hosts in VLAN 20.
There’s also no reason to send
VLAN 20-based traffic to the
switch that only has hosts in VLAN
30.

I’ll use IOS Help so you can see the
entire command and options:

SW1(config)#int fast 0/6
SW1(config-if)#switchport trun
allowed Set allowed VLAN ch
native
Set trunking native
pruning
Set pruning VLAN ch

SW1(config-if)#switchport trun
vlan Set allowed VLANs when

SW1(config-if)#switchport trun
WORD
VLAN IDs of the allo
add
add VLANs to the cur
all
all VLANs
except all VLANs except the
none
no VLANs
remove remove VLANs from th

This is an interface-level command,
so we can filter VLAN 20 on fast
0/6 and VLAN 30 on fast 0/8 (our
two trunks). With these options, we
have different ways we could do
this, one being the except option.

SW1(config-if)#switchport trun
WORD
VLAN IDs of the allowe

SW1(config-if)#switchport trun
SW1(config-if)#int fast 0/8
SW1(config-if)#switchport trun

Verify with show interface trunk.
SW1#show int trunk

Port
Mode
Native vlan
Fa0/6
desirable
Fa0/8
on
Port
Fa0/6
Fa0/8

Encap

802.1
802.1

Vlans allowed on trun
1-29,31-4094
1-19,21-4094

VLAN 20 is missing from “VLANs
allowed on trunk” on fast 0/6, and
VLAN 30 is missing from “VLANs
allowed on trunk” on fast 0/8. Just
what we wanted!
You have to see the big picture with
this command and where you filter

VLANs. Here’s the same network
we just used – with two switches
added:

In this case, you wouldn’t want to

filter either VLAN 20 or 30, since
there are downstream switches that
need traffic destined for both
VLANs, and the only way for those
switches to get that traffic is via the
switches that don’t have hosts in
both VLANs.
Let’s say those two switches were
just added to the network, and you
now need to adjust the VLAN
filtering we just configured.
Actually, we need to negate the
filtering. The most efficient way to
do that is with the all option. (We
could also use the “add” option to

add the denied VLANs back to our
“permitted” list.)

SW1(config-if)#switchport trun
WORD
VLAN IDs of the allo
add
add VLANs to the cur
all
all VLANs
except all VLANs except the
none
no VLANs
remove remove VLANs from th

SW1(config-if)#switchport trun
SW1(config-if)#int fast 0/8
SW1(config-if)#switchport trun

SW1#show int trunk

Port

Mode

Encap

Native vlan
Fa0/6
desirable
Fa0/8
on
Port
Fa0/6
Fa0/8

802.1
802.1

Vlans allowed on trun
1-4094
1-4094

Verified with show interface trunk,
the previously denied VLANs are
now allowed!
With our switches trunking, we
need to let them exchange VLAN
information. It’s important for our
switches to know about all VLANs
in the network, not just the VLANs

configured on the switch.
Let’s revisit that last network:

By default, the switches with no
hosts in VLANs 20 and 30 won’t
know those VLANs exist. Without
some way of letting them know,
they’ll drop incoming frames
destined for the VLAN they don’t
have ports in, and our connectivity
is in a handbasket and headed for a
really hot place.
Luckily, we have a protocol that
will let all of our switches know
about all VLANs. It’s VTP – the
VLAN Trunking Protocol.

VLAN Trunking Protocol (VTP)

VTP allows switches to advertise
VLAN information between other
members of the same VTP domain,
which allows a consistent view of
the switched network across all
switches in that domain.
When a VLAN is created on one
switch in a VTP domain, all other
VTP devices in the domain are
notified of that VLAN’s existence.
Switches in the VTP domain will
know about every VLAN, even

VLANs that have no members on
that switch.
This information is shared between
VTP devices in the form of
summary advertisements. A VTP
Server will send one of these
advertisements every five minutes,
and immediately upon a change in
its VTP database.
There are three separate VTP
modes.

In Server mode, VLANs can be
created, modified, and deleted.
When these actions are taken, the
changes are advertised to all
switches in the VTP domain.
VTP Servers can originate,
forward, and process VTP summary
ads. VTP Servers keep VLAN
configuration info upon reboot by
storing that information in nonvolatile RAM (NVRAM).
In client mode, the switch cannot
modify, create, or delete VLANs.

VTP clients cannot retain VLAN
configuration information upon
reboot.
VTP clients keep this information in
their running configuration, but not
in NVRAM. If a VTP client is
reloaded, it must obtain this
information from a VTP server
when it comes back up. VTP clients
can accept and process summary
advertisements.
The third VTP mode is transparent
mode. Take special note of the

differences between transparent
mode and the other two VTP modes.
Switches in transparent mode
forward the VTP advertisements
received from other switches, but
they do not process the information
contained in those ads.
VLANs can be created, deleted, and
modified on a switch in VTP
transparent mode, but those changes
are not advertised to the other
switches in the VTP domain. They
are locally significant only.

Transparent VTP switches keep
their VLAN information in
NVRAM, just as VTP Servers do.
Setting the VTP mode of a Cisco
switch is done with the vtp mode
command.
SW1(config)#vtp mode ?
client
Set the device
server
Set the device
transparent Set the device

Some important VTP notes:

As you’d expect, the VTP domain
name must match for VTP devices
to successfully exchange
information.
There are three versions of VTP,
with v3 being the most recent and
the only one with cryptographic
capabilities for the optional
password. The other two leave the
optional password sitting there in
clear text.
The domain name is case-sensitive,
so “CISCO” and “cisco” are two
different domains.
The VTP domain is set with the vtp
domain command. When you see

the domain name changed from
NULL to a new name, NULL
indicates there was no previous
domain name.
SW1(config)#vtp domain CCNA
Changing VTP domain name from

To distribute information about a
newly-created VLAN, the switch
upon which that VLAN is created
must be in Server mode.
You can’t have a VTP domain with
only VTP clients.

By the way, this is what happens
when you try to create a VLAN on a
switch configured as a VTP client:

SW1(config)#vtp mode client
Setting device to VTP CLIENT m
SW1(config)#vlan 20
VTP VLAN configuration not all

The switch is kind enough to remind
you that you cannot create, modify,
or delete VLANs on a VTP client. I
doubt the exam will be so kind.
The main VTP verification
command is show vtp status. This

command will display the local
switch’s operating mode, the VTP
domain name, the configuration
revision number, and more.

SW1#show vtp status
VTP Version
Configuration Revision
Maximum VLANs supported locall
Number of existing VLANs
VTP Operating Mode
VTP Domain Name
VTP Pruning Mode
VTP V2 Mode
VTP Traps Generation
MD5 digest
0x0B 0xF9 0x37 0x57
Configuration last modified by
Local updater ID is 74.92.187.

Note the innocent little
configuration revision number.
When you take a switch that’s been
in use in one network (production
or lab, it doesn’t matter), and insert
it into another network without
zapping that config revision number
back to zero, there’s a big chance
for big trouble.

Why I’m Spending Time On VTP
Revision Numbers

You may not see these numbers on
your CCENT exam, but there is a
huge issue with these numbers that
EVERY Cisco network admin
should know about. Consider this a
bonus real-world lesson.
Here’s the problem: If you take a
switch from one network and put
into another network, you have to
reset the config revision number to
zero on that switch BEFORE you

put it into another network, or you
risk overwriting all the VLAN
information in that second network!
This chances for this are greater
than most people realize. Let’s say
you work for a consulting firm
that’s been nice enough to put
together a Cisco practice lab for
you and the other admins. Let’s also
say a client network has a switch
suddenly go bad, and the firm
doesn’t have any new switches
sitting around.

Where do you think that switch is
going to come from?
From the practice lab, that’s where!
Nothing wrong with that – we do
what we have to do to keep the
client up and running – but you
must reset that revision number. If
you don’t, and the revision number
on your practice lab switch is
higher than that of the switches in
the client’s network, the client’s
VLAN information will be
overwritten by the lab switch.

It’s very likely that the VLANs are
changed more often on the lab
switch than the client switches, so
the chance that the lab switch has a
higher config revision number is
very high.
There are several methods to reset
that revision number to zero, and
the quickest one is to change the
VTP domain name to another name,
then set it to whatever you need it to
be. (Don’t use the original name.)
Here’s a switch with a config

revision number of 5. To set it to
zero, I’ll change the VTP domain
name to CCNA, then verify with
show vtp status.

SW1#show vtp status
VTP Version
Configuration Revision
Maximum VLANs supported locall
Number of existing VLANs
VTP Operating Mode
VTP Domain Name
SW1(config)#vtp domain CCNA
Changing VTP domain name from

SW1#show vtp status
VTP Version

Configuration Revision
Maximum VLANs supported locall
Number of existing VLANs
VTP Operating Mode
VTP Domain Name

When you get the switch to the
client site, set the name to whatever
the client’s using, and verify one
more time.

SW1(config)#vtp domain CLIENTS
Changing VTP domain name from

SW1#show vtp status
VTP Version
Configuration Revision
Maximum VLANs supported locall
Number of existing VLANs

VTP Operating Mode
VTP Domain Name

When this switch receives a VTP
summary ad from another switch on
the client network, it will overwrite
its VLAN information with the info
contained in that ad.
This is likely more than you’ll need
to know about VTP for the CCENT
exam, but it’s important that you
know about resetting the VTP
domain name. If for some reason
resetting the name doesn’t reset the
config revision number, do some

research on the Net – there are
other methods, but this one is the
most popular and is generally
effective.
That’s it for switching - for now!
Near the end of the course, you’ll
find a section on Router-On-AStick and Layer 3 switches. Those
lessons will sink in quickly for you
once you’ve gone through the
routing sections in this course.
Right now, let’s move forward and
work with hexadecimal

conversions.

The Joy Of Hex

I really mean that. Hex questions
are going to be a joy for you on the
exam. With solid practice, you’re
going to nail these questions quite
easily, because working with hex is
just like counting on your fingers
(almost).
If hex intimidates you in any way, or
you’re not familiar with it, take a
deep breath because I’m going to
ease your mind in this section.

We did a little hex work in another
section, but to get it down cold and
nail every question on exam day,
we have to get in some more
practice!
The MAC addresses we worked
with in this section and that you’ll
see in production networks are
written in hexadecimal, and
converting a decimal value to hex
and from hex to decimal are vital
skills that will come in handy on
exam day.

One major difference between the
decimal system you and I use every
day and the hex system is that in
hex, we’ll have letters that
represent certain numeric values.
When you read that, your reaction
might have been something along
the lines of “Great, we’re going to
use letters for numbers. This must
be some kind of super-complicated
double-secret-probation kind of
math!”
Wrong! It’s neither super-

complicated nor on double-secret
probation. It’s actually simple –
with practice!
The numbering system we use every
day, decimal, uses units of 10. We
don’t stop to think about it like that
because we’re so familiar with it. If
I ask you to give me 35 cents, you
don’t think “Okay, that’s 3 units of
10 cents and 5 units of 1 cent.”
You’d just give me the money.
Same if I asked you to loan me 712
dollars. You don’t think “Okay,

that’s 7 units of 100, 1 unit of 10,
and 2 units of 1.” You just think
“How can I get out of here without
giving Chris this money?”
I kid, but you get the point.

“35”
Decimal
“712”

Units
of 100

Units
of 10
3

Units
of 1
5

7

1

2

Hex numbers are read much the

same way, except we’re using units
of 16 and their multiples rather than
units of 10. For example…
The hex value “35”
represents 3 units of 16 and 5
units of 1.
The hex value “712”
represents 7 units of 256 (16
× 16), 1 unit of 16, and 2
units of 1.
Units of

Units

Units

256
Hex
“35”
Hex
“712”

7

of 16

of 1

3

5

1

2

The logical question at this point:
“Since hex is based on units of 16,
how can we represent a value of
10, 11, 12, 13, 14, or 15?”
The answer: “That’s where the
letters come in!”

Those six values are represented by
the following letters:
A = 10
B = 11
C = 12
D = 13
E = 14
F = 15
And that’s it! The case of the letter
doesn’t matter – both “a” and “A”
represent 10, and so forth.

For your CCENT and CCNA
exams, you should be ready to
convert a hex value to decimal, and
vice versa. I’ve listed some of each
below, and this is a good way for
you get started with your
conversion skills.
The answers and explanations are
given after the initial lists.
Another great way to get some
practice in – when you have a few
minutes here and there at work or at
home, just grab a piece of paper
and something to write with, and
write down some random decimal,

then practice converting them to
hex. These smaller practice periods
really add up to success on exam
day!
Convert the following hex values
to decimal:
1c
F1
2a9
14b
3e4

13
784
419
1903
345
The answers and explanations:
1c = 1 unit of 16, 10 units of 1 = 16
+ 10 = 26
F1 = 15 units of 16, 1 unit of 1 =
240 + 1 = 241

2a9 = 2 units of 256, 10 units of 16,
9 units of 1 =
512+ 160 + 9 = 681
14b = 1 units of 256, 4 units of 16,
11 units of 1 =
256 + 64 + 11 = 331
3e4 = 3 units of 256, 14 units of 16,
4 units of 4 =
768 + 224 + 4 = 996
13 = 1 unit of 16, 3 units of 1 = 16

+ 3 = 19
784 = 7 units of 256, 8 units of 16,
4 units of 1 =
1792 + 128 + 4 = 1924
419 = 4 units of 256, 1 unit of 16, 9
units of 9 =
1024 + 16 + 9 = 1049
103 = 1 units of 256, 0 units of 16,
3 units of 1 =
256 + 1 = 257

345 = 3 units of 256, 4 units of 16,
5 units of 1 =
768 + 64 + 5 = 837
Convert the following decimal
values to hex:
42
22
790
105
174
Answers and explanations:

This is one of those processes that
looks like it would take a long time
when you read about it, but when
you put it into action, it takes only
seconds.
For this conversion, just use this
simple little chart and work from
left to right:
256

16

42

Any units of 256 in 42? No, so
leave that blank.

1

Any units of 16 in 42? Sure, 2 of
them. That equals 32, which in turn
gives us a remainder of 10.
Any units of 1 in 10? Yep, 10 of
them! We represent that with the
letter “A” in hex.
Final answer: The decimal value 42
converts to the hex value 2A.

42

256
0

Next value: 22

16
2

1
A

256

16

1

22

Any units of 256 in 22? No, so we
leave that blank.
Any units of 16 in 22? Yes, one of
them, with a remainder of 6.
There are six units of 1 in 6, so the
final conversion is the decimal
value 22 to the hex value 16.
256
22

16
1

1
6

Next value: 790
256

16

1

790

Any units of 256 in 790? Yes, three
of them, for a total of 768. That
gives us a remainder of 22.
Any units of 16 in 22? Sure, one of
them, giving us a remainder of six.
There are six units of 1 in six, so
our conversion of the decimal 790
results in the hex value 316.

790

256
3

16
1

1
6

16

1

Next value: 105
256
105

Any units of 256 in 105? No, so we
skip that one.
Any units of 16 in 105? Six of them,
for a total of 96 and a remainder of
9. There are 9 units of 1 in 9, so our
conversion of the decimal 105

gives you the hex value 69.
256
105

16
6

1
9

16

1

Next decimal: 174
256
174

Any units of 256 in 174? Nope, so
we skip that one.
Any units of 16 in 174? 10 of them,

and 10 is represented by “A” in
hex. We have a remainder of 14,
which in turn is represented by “E”
in hex.
The decimal 174 converts to the hex
value AE.
256
174

16
A

1
E

And that’s it! With the “mystery” of
hex out of the way, the conversions
are simple, and they’ll be easy
points for you on exam day – with
practice, that is!

That just about wraps up this
section, and while the following
videos aren’t required viewing,
they’re certainly helpful!
There are quite a few free Cisco
switching videos on my YouTube
channel, including the following…
and while you’re out there, be sure
to join my 10,000+ subscribers so
you’re the first to know about every
new video!
Video Practice Exam on Cisco
Switching Fundamentals:

http://www.youtube.com/watch?
v=OLrj3qzTGw4
“You Might Just Be A Root Switch
If…”
http://www.youtube.com/watch?
v=9Db_5o_eXKE
“You Might Not Be A Root Switch
If….”
http://www.youtube.com/watch?
v=Hxf8f5U3eKU

Odd Switch Behavior:
http://www.youtube.com/watch?
v=XuAXVVhILZ8
Cisco Switching Video Practice
Exam:
http://www.youtube.com/watch?
v=u8oAvpGsJYw
Over 325 free videos right here,
along with your opportunity to
subscribe to my YouTube channel!

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

See you there – and in the next
section!
Chris B.

A Network Admin’s
Book Of WANs
(Well, a summary, anyway.)
This section is an intro to WANs,
and when I say “intro”, I mean
“intro”!
When one router wants to talk to
another over a long distance, that’s
our Wide Area Network at work,
and we have plenty of options for
our WANs.
It won’t surprise you to learn that
each option has plenty of details.

Those are details we aren’t going to
visit today. The CCENT doesn’t go
into detail on WANs. You’ll hit
plenty of labs and details regarding
HDLC, Frame Relay, and PPP in
your CCNA studies, but for right
now, let’s take an introductory look
at these and other WAN options!
Here’s a typical WAN connection…

… except, of course, routers in a

production network WAN will not
be directly connected. There are
generally devices belonging to the
WAN service provider between the
two routers that we don’t
configured. More on those in a
minute. Right now, let’s talk about
some of the encapsulation options
for our WAN!
HDLC And PPP
With a point-to-point WAN link, we
have two options for encapsulation:
The High Data-Link Control
Protocol (HDLC)

The Point-to-Point Protocol
(PPP)
A Cisco serial interface is running
HDLC by default…
R3#show int s1

Serial1 is up, line protocol i
Hardware is HD64570

Internet address is 172.12.1

Encapsulation HDLC, loopback

… but for reasons we’ll see during
our PPP discussion, you’ll likely
want to change this default.

The version of HDLC running on
Cisco routers is actually a version
of HDLC developed by Cisco
themselves. It’s not Ciscoproprietary, and is technically
known as cHDLC. Most if not all
documentation on this version of the
protocol refers to it simply as
HDLC, and I’ll do the same in this
book.
What was wrong with the original
HDLC, you ask? It didn’t offer
multiprotocol support, and that was
not going to work with Cisco
routers. Cisco simply added a
TYPE field to the original version,

and voila – multiprotocol support!
I’d Rather Switch Than Fight
HDLC’s Shortcomings
Even though HDLC is the default
encap on Cisco serial interfaces, it
has some real shortcomings when
compared to PPP. It’s not as much
an argument of “HDLC stinks” as it
is “PPP is great”!
PPP offers many features that
HDLC does not, including:
Authentication through the
use of the Password

Authentication Protocol
(PAP) and the ChallengeHandshake Authentication
Protocol (CHAP)
Support for error detection
and error recovery features
Multiprotocol support (which
Cisco’s HDLC does offer, but
the original HDLC does not)
Those aren’t all of PPP’s
advantages over HDLC, but they’re
the most important to us as network
admins.
No look at WAN protocols would
be complete without a look at

Frame Relay. The following intro to
Frame is from my ICND2 book, and
when you hit that one and pursue
your CCNA, we’ll run several labs
so you can see it in action. Right
now, let’s see how Frame Relay
works – and what the heck a “frame
cloud” is!
Frame Relay
Point-to-point networks are nice,
but there’s a limit to scalability. It’s
just not practical to build a
dedicated PTP link between every
single router in our network, nor is
it cost-effective. It would be a lot
easier (and cheaper) to share a

network that’s already in place, and
that’s where Frame Relay comes in!
A frame relay network is a
nonbroadcast multi-access
(NBMA) network. “nonbroadcast”
means that broadcasts are not
transmitted over frame relay by
default, not that they cannot be sent.
“multiaccess” means the frame
relay network will be shared by
multiple devices.
The frame provider’s collection of
frame relay switches has a curious
name - frame relay cloud. You’ll
often see the frame provider’s
switches represented with a cloud

drawing in network diagrams, much
like this:

We have two kinds of equipment in
this network:
The Frame Relay switches,
AKA the Data Circuitterminating Equipment
(DCE). These belong to the
frame relay provider, and we

don’t have anything to do
with their configuration. The
CSU/DSU that supplies
clockrate to our router may
be on our property, but it’s
still considered to be DCE.
The routers, AKA the Data
Terminal Equipment. We
have a lot to do with their
configuration!
Each router’s serial interface will
be connected to a CSU/DSU, and
the DCE must send a clockrate to
that DTE. If the clockrate isn’t
there, the line protocol will go
down.

Those two frame switches are not
going to be the only switches in that
cloud. Quite the contrary, there can
be hundreds of them! For
simplicity’s sake, the following
diagram will have less than that.

The point at which our network

meets that of the service provider is
the demarcation point, sometimes
referred to as the “demarc point” or
the “point of presence”.
You and I, the network admins,
don’t need to list or even know
every possible path in that cloud.
Frankly, we don’t care. The key
here is to know that not only will
there be multiple paths through that
cloud from Router A to Router B,
but data probably will take different
paths through that cloud.
That’s why we call this connection
between the routers a virtual
circuit. We can send data over it

anytime we get ready, but data will
not necessarily take the same path
through the provider’s switches
every time.
Consider this your Frame Relay
teaser! In the ICND2 material,
we’ll get much more into the nuts
and bolts of running Frame on
Cisco routers, including plenty of
lab work. Right now, let’s take a
very brief look at running Ethernet
over a WAN!

“Strong Enough For A WAN,
Made For A LAN”

We couldn’t even consider using
Ethernet for a WAN for many years,
since it really was designed for a
LAN. That’s no longer the case,
though!
Basically, using Ethernet for a
WAN (an EWAN) is set up much
like Frame Relay, in that we have
our connection to the service
provider’s devices, and what
happens in the cloud is the business
of the service provider. (In
Ethernet-over-WAN terminology,

the point of connection to the
service provider is called the point
of presence.)
In CiscoLand, we use Ethernet over
Multiprotocol Label Switching
(EoMPLS) for Ethernet over
WANs, and frankly, it’s pretty
darned complicated. Definitely not
something we’re getting into during
your CCENT studies! At this point,
it’s really enough just to know that
Ethernet is becoming a more and
more popular WAN option!

Between And About The Lines
We’ll discuss the cables inside our
LAN in another section. Right now,
let’s talk a little about the cable that
makes our WAN possible.
Our leased line is our physical
connection to the service provider.
It’s that simple. What’s not as
simple is keeping up with the
zillion names we’ve given the
leased line over the years.
When I first started working on the
WAN side of the ball, I heard all of
the terms listed here in my first
couple of days – I thought they were
all separate lines! Or links,

depending on who was talking!
Serial line
T1 (or “T1 line”)
PTP link (Point-to-Point)
You can substitute the word “link”
for “line” in any or all of those.
They’re all leased lines. More
about those in your ICND2 studies.

Home WAN Access

Household access to a WAN was
once limited to a slow-by-today’sstandards connection to an internet
services provider. (I still have the
baseballs from winning the regular
season and playoffs in my 1993
Prodigy Fantasy Baseball League.)
It wasn’t much, but we were darn
glad to have it!
For many of us, the argument about
internet access vs. using the phone
is in the past. Analog modems
(“dialup modems”) are still out

there, and we can’t use the phone
and access the Internet at the same
time with those.
Many of today’s home users utilize
digital subscriber lines (DSL) to
connect to the Internet, with a
specialized piece of equipment on
each end of the connection.
Man, when DSL came along, it was
party time! It’s always on, no
dialup needed (“Do we have an
AOL disk anywhere?”), and you
could access the Internet while
someone else used the phone!
The home user connects via a DSL
Modem, which in turn

communicates with the service
provider’s DSL Access Multiplexer
(DSLAM).
We’ll see multiplexing pop up later
in the course, so let’s define that
term now. Multiplexing is the
process of sending multiple data
streams simultaneously over a
single channel. The data is then
“demultiplexed” once it’s crossed
the channel.

Illustration courtesy of Wikipedia,
user “The Anome”.
In the case of DSL, we’re using the
phone line, so we’re multiplexing
computer data and voice data. This
allows us to access the Internet
while someone else uses the phone.
Might not sound like much today,
but it was kind of a big deal back
then!
There are several DSL types,
collectively referred to as “xDSL”.
I won’t list all of them here, but
there are two in particular you
should be aware of – and you might
be reading this over one right now!

ADSL is Asymmetric DSL,
the DSL type that delivers
greater speed in the
downstream direction (to the
customer) than upstream.
Most DSL connections are
this of this type.
SDSL is Symmetric DSL,
where the upload and
download streams flow at the
same rate.
Not all home internet access is via
the telephone line! Many homes
connect through their cable
connection. I’ve done so myself,

and when the ‘net connection would
drop, the first thing we’d do in our
troubleshooting (after checking the
cables, of course) was to check to
see if the cable TV was still
working. If it wasn’t, we knew
there was a provider issue.
This concludes our quick look at
our WAN technologies and DSL
variations. We’ll hit Frame, PPP,
and HDLC hard during your CCNA
studies. If you’re interested in going
way beyond the scope of the exam
regarding DSL, check out
Wikipedia – they have more on DSL
than you might want to know!

Onward!

DNS, DHCP, and ARP
There are network services that run
almost flawlessly, to the point
where we don’t really give them
much thought on a day-to-day basis.
For our CCENT and CCNA exams,
we need to give these services a
LOT of thought!
We’ll start by taking a look at our
Layer 2 and Layer 3 address
acquisition methods, and we’ll

work in some L3 IP address
assignment work as well. Let’s get
started!
One Data Transmission, Two
Destination Addresses
As network admins, we spend a lot
of time concerning ourselves with
IP addresses -- assigning them,
filtering them, etc. We don’t think
about MAC addresses that often,
but data going from Host A to Host
B must have a destination MAC
address for Host B as well as a

destination IP address!

To get these two required
destination addresses, Host A will
use two separate protocols:
Domain Name System (DNS)
for the IP address
Address Resolution Protocol
(ARP) for the MAC address

Host A will require the IP address
first, since it must know the IP
address of the remote host in order
for the ARP process to work
properly. Let’s take a quick look at
the DNS process.
Domain Name System
Host A will know the computer
name of Host B. For this discussion
we’ll assume that name to be
“hostb”. Now it needs an IP address
and a MAC address for that
hostname, and DNS will help it get
that IP address.

The DNS process is very simple.
Each host will have the IP address
of a DNS server, and a host needing
the IP address of another host will
send a DNS Request to the DNS
server.
Note that all devices in the
following example are on the same
network segment. There are no
routers involved.

The natural question: “How does
Host A know the IP address of the
DNS server in the first place?” That
happens in one of two ways:

The DNS server address is
hard-coded on Host A
The DNS server address was
learned via DHCP
Let’s look at the output of ipconfig
/all for the wireless connection on a
PC. Note the DNS server locations.

Wireless LAN adapter Wireless
Connection-specific DNS Suf
sbx13912.richmva.wayport.net

Description . . . . . . . .
(2.4GHz and 5GHz)

Physical Address. . . . . .

DHCP Enabled. . . . . . . .

Autoconfiguration Enabled .
Link-local IPv6 Address . .
fe80::3122:85f1:77bc:140%12(Pr

IPv4 Address. . . . . . . .

Subnet Mask . . . . . . . .

Lease Obtained. . . . . . .
AM

Lease Expires . . . . . . .
AM

Default Gateway . . . . . .

DHCP Server . . . . . . . .

DHCPv6 IAID . . . . . . . .

DHCPv6 Client DUID. . . . .
F0-1F-AF-22-12-E5
DNS Servers . . . . . . . . .

Primary WINS Server . . . . .

NetBIOS over Tcpip. . . . . .

Now that Host A has the IP address
of Host B, we’re halfway home, but
now Host A needs that MAC
address to send data successfully to
Host B -- and that’s where the
Address Resolution Protocol
(ARP) comes in.

The Address Resolution Protocol
We have a DNS server that took
care of the hostname-IP address
resolution, but now we need the
MAC address of Host B, and there
is no ARP server on the network.
That’s because there is no such
thing as an “ARP Server”. The ARP
process uses a series of broadcasts
and replies.
Host A is the host needing the MAC

address of a remote device, so it’ll
be Host A that sends out the initial
ARP Request. This request is a
Layer 2 broadcast, meaning….
The source MAC address
will be that of Host A
The destination MAC
address will be ff-ff-ff-ff-ff-ff
The source IP address will
be that of Host A
The destination IP address
will be that of Host B
(learned via DNS)

In this particular topology, all other
devices will see the request. Host C
and the DNS server will see the
destination IP address of 10.1.1.2,

see that it’s not theirs, and will
simply ignore the ARP Request.
Host B will see that it is an ARP
Request and that it does match its IP
address, so Host B will send an
ARP Reply containing its MAC
address.

Thanks to DNS and ARP, Host A
now has the IP and MAC address of
Host B, and can successfully send
data to that host.

This is a nice, neat little process,
but those ARP requests are
broadcasts, and we’re always
interested in minimizing those.
Wouldn’t it be great if the PC could
keep a list of MAC addresses it
learns for a while – a cache of
addresses, perhaps?
Behold the ARP Cache! These

caches contain an IP address-toMAC address mapping table such
as the one shown here on a
Windows PC with the command arp
-a :
C:\>arp -a
Internet Address
192.168.5.1

Physica
00-90-f

This table mentions “Physical
Address”, one of several names
used to describe the MAC address.
It’s still a Layer 2 address, despite
that name; it’s called a “Physical
Address” because it physically
exists on the card.

After learning Host B’s IP and
MAC addresses, Host A enters
them into its ARP cache. The next
time Host A needs to send data to
Host B, the information needed to
do so is right there in the ARP
cache and no ARP Request needs to
be sent.
In our previous example, we had a
switch in the middle of our
network, and that didn’t affect the
ARP process at all. Switches have
no problem forwarding the
broadcasted ARP Request, and
since the ARP Reply is a unicast,
there’s no issue there.

If we have a router in the mix, we
do have a problem, because routers
don’t forward broadcasts. (For
clarity’s sake, the switches and
cables are not included in the
following illustrations.)

All is not lost! Using Proxy ARP,
the router can answer the request
with the MAC address of the
interface that received the ARP

Response – in this case, Ethernet0.

Host A has no idea the MAC
address it received in the ARP
Response is actually not that of
Host B, but rather that of the
Ethernet0 interface of the router.
Host A doesn’t care, either. All
Host A knows is that it sent an ARP
Request and got a Response. Now

when Host A sends data to Host B,
the data will have the following
destinations:
IP destination address is Host
B’s IP address
MAC destination address is
the one assigned to the
router’s E0 interface
Proxy ARP is a little odd to work
with at first, and can result in some
unexpected source and destination
MAC addresses at different points
in your network. If you’re not aware
of these changes in MAC addresses
when you use a network traffic

analysis tool, you may wonder
where those addresses are coming
from!
Let’s walk through an example of
when, how, and if MAC and IP
addresses change as a result of
Proxy ARP.
Two simple rules to remember:
The source and destination
MAC addresses will only
change when routers are
involved, since that’s when
Proxy ARP has to step in.
The source and destination IP
addresses do not change,

period.
For this example, we’ll use the
same network, but with MAC and
IP address assigned to the hosts and
the router’s Ethernet interfaces.

Host A sends an ARP Request for

the MAC address of Host B. The
router receives the Request on its
E0 interface, and sends a Proxy
ARP response back to Host A. This
request tells Host A the MAC
address of the device at 10.3.1.2 is
11-11-11-11-11-11, which is
actually the MAC address on the
router’s E0 interface.

As a result, when Host A sends data
to Host B…
The source IP and MAC
addresses are that of Host A
The destination IP address is
that of Host B

BUT…the destination MAC
is that of R1’s E0 interface!

Now the router will forward that
data to Host B. The destination IP
and MAC will be that of Host B,
but the source MAC address will
be that of the router’s E1 interface -

the interface that’s forwarding the
data.

As a result, Host A’s ARP cache
will look like this:
C:\>arp -a
Internet Address

Physical

10.3.1.2

11-11-11-

The IP address never changes in
this scenario, but the MAC address
does as a result of Proxy ARP.
That’s enough ARPing around for a
while! Let’s talk about how these
hosts get their own IP address in the
first place!
Dynamic Host Configuration
Protocol
A host needs some very important
information before it can even start
to act as part of the network:

What’s my IP address?
What’s my network mask?
What are the IP addresses of
the DNS servers?
What’s my default gateway?
We have two options for getting that
info to the host:
Visit each workstation and
configure the information
manually
Enable each workstation for
DHCP
You might think there’s no big

difference, since each option
involves visiting the workstations.
The difference is in how many
times you end up doing that.
Sooner or later, some of that
information is going to change and
the hosts will need to know about
these changes.
If you previously hardcoded the
information on all hosts, you’ll now
have to go out and visit every
workstation again and change the
information manually.
If you used DHCP to begin with,
you now just have to change the

information on the DHCP server,
and then push that information out to
the hosts.
When the choice is between visiting
the hundreds or thousands of hosts
on a typical network or using DHCP
to dynamically handle IP address
assignment information, there really
is no choice.
When you have the choice to do
something manually or to let the
router or switch do the work, it’s
almost always a great idea to let the
hardware do the work. That doesn’t
make your lazy, it makes you smart.
Your time is your most valuable

resource – make it count.
Also, consider our mobile users –
and today, everybody’s a mobile
user! If you’re a laptop owner,
there’s no way hardcoding that IP
address information on your laptop
would work out, since you’ll need
to be on one network at the coffee
shop, another at the airport, another
at the grocery store, and on and
on…
In short, today’s networks demand
dynamic assignment of IP address
information, and that’s what DHCP
is all about.
There are four basic steps that

allow a host (the DHCP Client) to
acquire all of this information from
a DHCP Server, and you can easily
keep them in mind by using the
acronym DORA:
Discover
Offer
Request
Acknowledgement
Let’s take a look at each of those
steps.
The client begins the process by
sending a DHCP Discover message

with the destination IP address
255.255.255.255 (a broadcast). The
client has to send a broadcast, since
it has no idea where the DHCP
server is.
Basically, this step is the host
yelling “Hey, anybody out there a
DHCP Server?”

Any DHCP server that receives that

message will respond with a DHCP
Offer. The Offer contains the
following:
The IP address the DHCP
Server is offering the Client
The network mask the DHCP
Server is offering the Client
The amount of time the Client
can keep this information if
the Offer is accepted (the
lease)
The IP address of the DHCP
Server making the offer

Since the original DHCP Discovery
sent by the host is a broadcast, more
than one DHCP Server may see it
and respond with an Offer.
That’s great, since we always like
having a choice! The choice made
by the host in this example isn’t
exactly made by a scientific
method, though – the host simply

accepts the first Offer it gets.
The DHCP Offer is also a
broadcast. That’s necessary since
the client doesn’t have an IP
address yet. By sending this
message as a broadcast, the client is
guaranteed to see it (and other
clients will just ignore it).
The client then broadcasts a DHCP
Request, identifying the DHCP
Offer it’s accepting. This is usually
a broadcast, and the DHCP Server
whose offer is being accepted can
tell that via a “Transaction ID”
value in the DHCP Request
message. (Under certain

circumstances, such as the client
renewing a previous lease, this can
be a unicast.)

Finally, the DHCP Server whose
offer was accepted sends a DHCP
Acknowledgement back to the client
with any other information the

Client needs. The client doesn’t yet
have its IP address officially, so
this message is also a broadcast.
The process is now complete and
the client’s all set. Of course, we’re
going to verify that in just a
moment!

You can see the IP address a host

has been assigned, along with the
lease length and other information,
with ipconfig /all. You can verify
that the host is running DHCP with
this command as well.
DHCP Enabled. . . . . . . . .
Autoconfiguration Enabled . .

Link-local IPv6 Address . . .
fe80::3122:85f1:77bc:140%12(Pr
IPv4 Address. . . . . . . . .
Subnet Mask . . . . . . . . .
Lease Obtained. . . . . . . .
7:21:59 AM

Lease Expires . . . . . . . .
8:54:37 AM
Default Gateway . . . . . . .
DHCP Server . . . . . . . . .
DHCPv6 IAID . . . . . . . . .
DHCPv6 Client DUID. . . . . .
1F-AF-22-12-E5

I’m sure you noticed the DHCPv6
information near the bottom of that
output. We’ll discuss DHCPv6 in
the IP Version 6 section of this
course!

Working Around Routers With
DHCP
The DHCP process is nice and
clean as long as we have a DHCP
server on each physical subnet in
our network, like this…

… but what happens when we get
routers involved?

Our nice, clean process just got a
bit messy.
Why? Routers don’t forward
broadcasts, and the entire DHCP
process is dependent on broadcasts.

To solve this problem, we need a
little help from the ip helperaddress command, which allows
the router to serve as a DHCP relay
agent.
The “helper” part comes in as the
router is now allowed to take an
incoming broadcast and make two
major address changes to that
packet:
The source IP address is
changed to that of the router
interface that received the
packet
The destination IP address is

changed to the IP address of
the DHCP server. Since that
destination address of the
packet is no longer a
broadcast, the router can
route it successfully. Slick,
eh?
First things first! We need the ip
helper-address command on the
router interface that will be
receiving DHCP broadcasts from
clients. In this network, we’d only
need it on the Ethernet0 interface on
R1, but it’s commonplace to see it
on all router interfaces that face

LANs.

R1 config:
Interface ethernet0

Ip helper-address 172.23.2

Here are the source and destination
IP addresses of a DHCP Discover
packet as it arrives on the E0
interface of R1:
Source: 0.0.0.0
Destination:
255.255.255.255 (broadcast)
The router then changes those two
values before routing the packet:
Source: 172.12.123.1 (R1’s
E0 interface)
Destination: 172.23.23.100
(The DHCP Server)

When the DHCP server replies with
an offer, the router will see the
message is destined for an interface
on the router itself. That’s a tipoff to
the router that this is a DHCP
message that needs to be relayed, so
it sets the destination address to
255.255.255.255 and then relays
away!

In networking, a solution tends to
lead to another question, and a
logical question here would be
“What if we have more than one
DHCP server on our network?”

No worries, we’ll just configure
multiple helper addresses!

R1 config:
Interface ethernet0
Ip helper-address 172.23.23
Ip helper-address 172.23.23

This option does allow

communication from that remote
LAN to both DHCP servers, but
doesn’t perform any kind of
workload balancing (or “load
balancing”, in network-speak). To
do that, we’d have to start adjusting
the delay values on those DHCP
servers, and that’s way beyond the
scope of your CCENT and CCNA
studies.
Besides, we have to leave
something for later studies!

Configuring DHCP With Cisco
Routers

Our Cisco router can serve as a
DHCP server, and all information
about the packet types, messages,
etc., stands.
We create an address pool with ip
dhcp pool < POOLNAME >. Once
we’re in DHCP pool configuration
mode, you can create… well, we’ll
see!
The odd thing about using a Cisco
router as a DHCP server is that
your config starts by identifying the

addresses you do NOT want to be
assigned to hosts from the address
pool.
Let’s say you’re assigning
addresses from the 10.1.1.0 /24
subnet, and you don’t want to have
the first five addresses in that
subnet assigned to hosts. Identify
the excluded addresses with the ip
dhcp excluded-address command,
which is NOT found in the ip dhcp
pool command options – it’s a
command onto itself:

R1(config)#ip dhcp excluded-ad
A.B.C.D

Low IP address

R1(config)#ip dhcp excluded-ad
A.B.C.D

High IP address

<cr>

R1(config)#ip dhcp excluded-ad
?
<cr>

R1(config)#ip dhcp excluded-ad

Note that you’re identifying a range
with those two addresses. You can
also use this command to enter a
single excluded address. Let’s say
the Ethernet interface facing the

inside hosts uses the IP address
10.1.1.100. We want to exclude that
from the pool, and that’s no
problem – you can use the ip dhcp
excluded-address command as
many times as necessary.

R1(config)#ip dhcp excluded-ad

R1(config)#ip dhcp excluded-ad

We’ll start our pool config with the
ip dhcp pool command:
R1(config)#ip dhcp pool ?
WORD

Pool name

R1(config)#ip dhcp pool NETWOR
<cr>

R1(config)#ip dhcp pool NETWOR
R1(dhcp-config)#

We drop into DHCP config mode,
and that’s where our options finally
show up! A lot of them! There are
almost 30 options with this
command, so I’ve left in only the
ones we use most often:
R1(dhcp-config)#?

DHCP pool configuration comman

default-router

Default

dns-server

DNS ser

domain-name

Domain

exit
configuration mode

Exit fr

host

Client

lease

Address

network

Network

no
defaults
relay

Negate

Functio

A typical DHCP configuration,
along with a little help from IOS
Help to see the options:

R1(dhcp-config)#default-router
Hostname or A.B.C.D

Router’

R1(dhcp-config)#default-router

R1(dhcp-config)#dns-server ?
Hostname or A.B.C.D

Server’

R1(dhcp-config)#dns-server 100
Hostname or A.B.C.D
<cr>

Server’

R1(dhcp-config)#dns-server 10.

Hostname or A.B.C.D Server’s
<cr>

R1(dhcp-config)#dns-server 10.

R1(dhcp-config)#domain-name ?
WORD Domain name

R1(dhcp-config)#domain-name th

R1(dhcp-config)#lease ?
<0-365>

Days

infinite

Infinite lease

R1(dhcp-config)#lease 10 ?
<0-23>

Hours

<cr>
R1(dhcp-config)#lease 10 0 ?
<0-59>
<cr>

Minutes

R1(dhcp-config)#lease 10 0 0?
<0-59>

R1(dhcp-config)#lease 10 0 0 ?
<cr>

R1(dhcp-config)#lease 10 0 0

Watch those lease numbers! And
you know what I’m going to say
next – always use IOS Help to
verify numeric values of a
command before entering the

command!
That’s enough DHCP for now –
let’s head to the next section!
Before you do, though, head out to
Udemy and join my free and almostfree CCNA, CCNP, CCENT, and
Security Video Boot Camps!
You can join my 27-hour CCNA
Video Boot Camp for just $44 with
the BULLDOG60 coupon code, and
all videos are fully downloadable!

https://www.udemy.com/u/chrisbryan
See you there!

Router Memory,
Configs, and More

This is a great section full of “nuts
and bolts” – quite a few details that
are important for both your exam
performance and your network’s
performance.
I guarantee you’ll use the
information in this section for the
rest of your Cisco routing and
switching career. This info really is
that important. You can’t

troubleshoot effectively without
knowing this material.
You also can’t pass your exams
without it, so let’s have at it!
Router And Switch Memory
The memory components and
functions discussed in this section
are the same for routers and
switches, but to keep from saying
“routers and switches” 500 times,
I’ll just say “routers”.
Let’s examine these four memory
components closely and see what
each one does -- and what is

retained and NOT retained on a
reload.
ROM: Read-Only Memory. ROM
stores the router’s bootstrap startup
program, operating system
software, and power-on diagnostic
test programs (POSTs).
Flash Memory: Generally referred
to simply as “flash”, the IOS images
are held here. Flash is erasable and
reprogrammable ROM. Flash
memory content is retained by the
router on reload.
RAM: Random-Access Memory.
Stores operational information such
as routing tables and the running

configuration file. RAM contents
are lost when the router is powered
down or reloaded.
NVRAM: Non-volatile RAM.
NVRAM holds the router’s startup
configuration file. NVRAM
contents are not lost when the router
is powered down or reloaded.
Some important comparisons:
RAM contents are lost on
reload, where NVRAM and
Flash contents are not.
NVRAM holds the startup

configuration file, where
RAM holds the running
configuration file.
We’ll talk about the startup and
running configuration files later in
this section. Right now, let’s take a
look at the boot process of a Cisco
router, and then talk about the
dreaded Setup Mode!
The Router Boot Process
When a Cisco router powers up, it
first runs a series of POSTs
(Power-On Self Tests). A POST is
a diagnostic test designed to verify

the basic operation of the network
interfaces, memory, and CPU.
Depending on the model of router
you’re using, you’ll see messages
regarding the POSTs passed as the
router boots. Here, I’ve reloaded a
Cisco 2950 switch, and you can see
some of the POSTs being run and
thankfully passed at the very
beginning of the bootup process.

Initializing flashfs…
Done initializing flashfs.
POST: System Board Test : Pass
POST: Ethernet Controller Test
ASIC Initialization Passed
POST: FRONT-END LOOPBACK TEST

Here are the POSTs shown when I
reloaded a 2960 switch:

POST: CPU MIC register Tests :
POST: CPU MIC register Tests :
POST: PortASIC Memory Tests :
POST: PortASIC Memory Tests :

POST: CPU MIC interface Loopba
POST: CPU MIC interface Loopba

POST: PortASIC RingLoopback Te
POST: PortASIC RingLoopback Te

POST: PortASIC CAM Subsystem T
POST: PortASIC CAM Subsystem T

POST: PortASIC Port Loopback T
POST: PortASIC Port Loopback T

“Status Passed” is always a good
thing!
POSTs are particularly effective at
detecting major problems, such as a
broken fan, early in the boot
process. If the POST detects a
critical problem that would cause
the router to overheat after booting,
the POST will fail, give you a clear
message as to why the POST failed
, and the boot process stops. In the
event a fan fails, you’ll see a
message regarding an
“environmental factor”.
And once that pain in your stomach

that feels like someone kicked you
goes away, you can start
troubleshooting. (Seriously, the first
time you see a POST fail, it’s
painful!)
Let’s assume our fictional router
has a good fan and move forward!
After the router passes the POST, it
looks for a source from which to
load a valid Internetwork Operating
System (IOS) image. The router has
three sources from which it can
load an IOS image, and it’s a good
idea to know these sources and the
order in which the router will look
in each for that image:

1. Flash memory (the
default).
2. A TFTP server. (Trivial
File Transfer Protocol)
3. Read-Only Memory
(ROM)
To change that order, a change must
be made to the configuration
register. It’s similar to the
Microsoft Registry in that you
should never change this value
unless you are sure of the result.
More on that later.
Once the IOS is found, the router
looks for a valid startup
configuration file. By default, the

router will look for the startup
configuration file in Non-Volatile
RAM (NVRAM). If there’s no
startup file there, the router looks
for a TFTP Server.
If no valid startup configuration file
is found, the router prompts you to
enter setup mode, where the router
runs the system configuration
dialogue, a series of questions
involving basic router setup.
A lot of questions.
Setup Mode, The CLI, and Pain
When you take a Cisco router out of

the box and boot it up for the first
time, it’s dumber than a bag of
rocks.
Well, not quite. It’s not dumb. You
just haven’t told it anything yet. A
router doesn’t automagically know
what IP addresses you want to
assign to its interfaces, what
security features you do and do not
want to run, or any of your other
preferences. We have two ways to
tell it these things:
Setup Mode
Manually configuration via

the Command-Line Interface
(CLI)
Seems like a pretty simple choice,
doesn’t it?
Well……
I’m all for automating processes
and letting devices dynamically
learn things that we could tell it
statically (MAC addresses, for
instance). That’s not because I’m
lazy, it’s because allowing dynamic
learning is generally more efficient
than maintaining static
configurations.
However, Setup Mode is not

dynamic. You’re still going to have
to tell the router what it needs to
know, and with Setup Mode, you do
so by answering a series of
questions.
A lot of questions.
Here’s the prompt to enter Setup
Mode:

--- System Configurat

Would you like to enter the in
dialog? [yes/no]:

If you answer “yes”, you’re going to

enter Setup Mode, which is a fancy
way of saying the device is going to
start asking you questions about
what you do and do not want to
configure.
If you answer “no”, you’ll be taken
to the Command-Line Interface
(CLI), and you’ll have to configure
the device with no prompting.
Sounds like choosing Setup Mode
is a no-brainer! There’s nothing
technically wrong with Setup
Mode, but I’ve seen many admins
that get tired of answering questions
in a few minutes and wish they
could just forget the whole thing

and get back to the CLI. ( I
personally lose my patience with
Setup Mode in about 30 seconds.)
Let’s answer “y” to that innocent
little question and see what Setup
Mode is all about.

Would you like to enter the in
dialog? [yes/no]: y

At any point you may enter a q
help.
Use ctrl-c to abort configurat
Default settings are in square

Basic management setup configu
connectivityfor management of
setup will ask youto configure
system

Would you like to enter basic
[yes/no]:

Sure, we’ll go with basic
management setup. Sounds great!
By the way, when you see two
responses in the brackets, you have
to manually enter one of them – you
can’t just hit Enter.
When you see one value in
brackets, like [Router], that’s the
default response. To accept that,

just hit the Enter key, which is what
I did here.

Configuring global parameters:
Enter host name [Router]:

The enable secret is a passw
access to privileged EXEC and
This password, after entered,
configuration.
Enter enable secret:

Understandably, there’s no default
for the enable secret password!
Let’s say that we want to enter our
enable secret password later, or not
to configure one at all. Let’s see if

we can get around this…
Enter enable secret:
No defaulting allowed
Enter enable secret:
No defaulting allowed
Enter enable secret:

Nope! This is one reason many
admins don’t care for Setup Mode.
You’re going to be asked questions
regarding services you have no
intention of running, and believe
me, you’re going to get tired of it.
How do we get out of this mode
without saving changes? There was
a hint earlier in the config…..

At any point you may enter a q

Use ctrl-c to abort configurat

Default settings are in square

Simple enough, as long as you
noticed that at the beginning! Let’s
try the ctrl-c keystroke and see what
happens.

Configuration aborted, no chan
Press RETURN to get started!

We’re thrown out of Setup Mode
and once you hit RETURN, you’re
back at the command-line interface

(CLI).
There’s nothing technically wrong
with Setup Mode. It’s just unwieldy,
and most admins want to get out of
it the first time they try it. Make
sure you keep that keystroke in mind
for both the exam and working with
real-world networks!
As for configuring from the CLI, all
you have to do is type enable at that
prompt, then you’re ready to enter
configuration mode with conf t
(short for “configure terminal”)
Finally, if you’d like to enter Setup
Mode from the router prompt,
simply type setup.

R2#setup

--- System Configurat
Continue with configuration di

Fundamental Router (And Switch)
Commands
To see the active configuration on
the router, enter the command show
running-config. There won’t be
much of a config on there now, but
we’ll take care of that soon.
This router has multiple Serial
interfaces, and since their default

configs all look the same, I’ve cut a
few of them out for clarity.
Router#show run
Building configuration…
Current configuration:
service timestamps debug up
service timestamps log uptime

no service password-encryption
hostname Router
ip subnet-zero
interface Ethernet0

no ip address
shutdown

interface Serial0
no ip address
shutdown
!
line con 0
transport input none
line aux 0
line vty 0 4

We worked with the console and
VTY lines on a switch elsewhere in
the course, and outside of the router
having fewer VTY lines (the switch
had 16 lines, the router only has
five), the Telnet commands and
privilege level 15 command work
just the same here.
Note these defaults in that config:
The router’s name is
“Router”
no service passwordencryption is in the config by
default
The interfaces are all shut

down
Changing the router’s name is easy,
so we’ll start there. Just use the
hostname command followed by
the name you want the router to
have.
Router#conf t
Router(config)#hostname R1
R1(config)#

The router prompt changed
immediately and the hostname of the
router is now R1. You rarely have
to reload aCisco router in order for
commands to take effect.

Let’s take a look at the no service
password-encryption command.
When we looked at enable
passwords and enable secret
passwords, we learned the enable
password is in clear text by default,
and the enable secret is encrypted
by default.
Let’s set an enable password of
CISCO and an enable secret of
CCNA and compare the two in the
running configuration.

R1(config)#enable password CIS
R1(config)#enable secret CCNA

While we’re at it, we’ll configure a

VTY line password of CCENT for
our incoming Telnet users, and set
the privilege level to 15 for all of
them.

R1(config)#line vty 0 4
R1(config-line)#password CCENT
R1(config-line)#privilege leve

What do the passwords look like in
the running configuration?

enable secret 5 $1$.2Ut$44fqDN
enable password CISCO
line vty 0 4
privilege level 15
password CCENT
login

The enable secret password is
encrypted, but the enable and VTY
line passwords are just sitting there
in clear text, waiting to be read.
What if we want to encrypt all of
the passwords in the configuration?
We’d run the command service
password-encryption!

R1(config)#service password-en
R1(config)#<no confirmation me

We didn’t get a message that the
service has been enabled
successfully, so how do we know
the passwords were encrypted? By

viewing the configuration!

enable secret 5 $1$.2Ut$44fqDN
enable password 7 047822352C0E

line vty 0 4
privilege level 15
password 7 01302521753F
login

The enable password and VTY line
passwords are now encrypted!
The numberin the password
statements - “5” and “7”,
respectively - refer to the level of
encryption, with 7 being the highest.
You really need to secure those

passwords somewhere before you
encrypt them, because running no
service password-encryption will
not immediately decrypt those
passwords!
This encryption is actually rather
weak. Cisco warns against
depending on it, as it’s easily
cracked in a matter of seconds by
readily available programs. It’s a
good defense against someone
peeking over your shoulder at the
config (the “over-the-shoulder
network attack”) and is certainly
preferable to leaving the passwords
in the config in clear text. It’s a

good first step in network security.
Interface Defaults And
Troubleshooting
Regarding the interface defaults,
two things jump out at us. The
interfaces do not have IP addresses,
and they’re shut down. “shut down”
and “down” are two very different
things, as you’ll soon see. Right
now the interfaces are
administratively shut down.

R1#show interface serial0
Serial0 is administratively do
Hardware is HD64570

MTU 1500 bytes, BW 1544 Kbit
Encapsulation HDLC, loopback
Last input never, output 00:
Last clearing of “show inter
Input queue: 0/75/0 (size/ma
Queueing strategy: weighted
Output queue: 0/1000/64/0 (s
Conversations 0/1/256 (ac
Reserved Conversations 0/
5 minute input rate 0 bits/s
5 minute output rate 0 bits/
0 packets input, 0 bytes,
Received 0 broadcasts, 0
0 input errors, 0 CRC, 0
14 packets output, 1540 b
0 output errors, 0 collis
0 output buffer failures,
0 carrier transitions
DCD=up DSR=up DTR=down RT

Do not panic at the amount of output

with this command! You don’t need
to know what every single thing
means, but you do need to get used
to running this command and using
the info at the top of the output.
You’ll certainly gain that skill in
this course, since we’ll be using
this command quite often during our
lab work.
This command is often the first step
in troubleshooting, and more than
one network admin has put an IP
address on a router interface and
then wondered why they couldn’t
ping a remote device. You have to
open the interface manually, and we

do that with the no shutdown
command (often abbreviated as “no
shut”).
Immediately after opening a serial
interface, you will see a few
additional messages, as shown
below.
R1(config)#int s0
R1(config-if)#no shutdown

00:35:35: %LINK-3-UPDOWN: Inte

00:35:36: %LINEPROTO-5-UPDOWN:
Serial0, changed state to up

00:35:58: %LINEPROTO-5-UPDOWN:
Serial0, changed state to down

From top to bottom, we see that…
The interface state changed to
“up” - sounds good.
The line protocol changed to
“up” - that sounds good, too.
The line protocol went down
about 22 seconds later,
according to the timestamps
in bold - that doesn’t sound
good.

Before we start troubleshooting,
let’s run show interface serial0.
For the rest of this section, I’ll
show only the top lines of this
command output.

R1#show int serial0
Serial0 is up, line protocol i

The news looks half-good, but we
need all-good.
The line protocol is the logical
state of the interface, while serial0
is up refers to the physical state of
the interface. This somewhat
common combination of up/down
means the interface is fine

physically, but there’s a logical
problem.
We’ll talk a bit about this in the
WAN section of the course, but a
Serial interface is one half of a
DTE/DCE connection - the DTE
end, specifically. The DCE end
must supply a clockrate to the DTE.
If that clockrate is not present, the
line protocol will go down.
Once this clocking is in place, the
line protocol will come up. There’s
no need to shut and reopen the
serial interface. When the line
protocol comes up, you’ll see the
link come up, and all is well!

What if there’s a physical problem
with the interface? Let’s say
someone’s working in a crowded
router cabinet and accidentally
dislodges a serial cable. You’ll first
see this…

20:26:56: %LINK-3-UPDOWN: Inte
state to down

20:26:57: %LINEPROTO-5-UPDOWN:

… andthis with show interface
serial0:

R1#show interface serial0
Serial0 is down, line protocol

This particular output shows
Serial0 as being down, not
administratively down. There’s a
big difference! When you see the
physical interface status as “down”,
that indicates a physical problem
with the interface.
Real-world hint: Don’t start
troubleshooting the router until you
check your cables! Always begin
troubleshooting at Layer 1.
A great command that allows you to
check for a cable without checking
in person is show controller serial.
This command will give you a lot
of output you don’t need and only

Cisco tech support will understand,
but what we need is right at the top
and in plain language!

R1#show controller serial 0
HD unit 0, idb = 0x127990, dri
at 0x12DD18 buffer size 1524 H
cable

No cable, no network! After
plugging the cable back in, we get a
message that both the interface and
line protocol are back up….

20:36:35: %LINK-3-UPDOWN: Inte
state to up
20:36:36: %LINEPROTO-5-UPDOWN:
Interface Serial0, changed sta

… which we verify with show
interface serial and show
controller serial.

R1#show int serial0
Serial0 is up, line protocol i
R1#show controller serial 0
HD unit 0, idb = 0x127990, dri
at 0x12DD18 buffer size 1524 H
DTE cable

I know these “up / down”
combinations are a little confusing
at first, so here’s a list that has
always helped me remember what
to look for when a given
combination shows up:
interface is administratively down,

line protocol is down - This means
the interface is shut down. Open it
with the no shutdown command.
interface is down, line protocol is
down - There’s a physical
connectivity issue with the
interface. Always check the cable
first. Always.
interface is up, line protocol is
down - The interface is physically
fine, but there’s a logical problem.
Check for a clockrate command on
the DCE, and make sure
encapsulations match (more about
that in the WAN section)

interface is down, line protocol is
up - Can’t happen. The logical part
of the router can’t be up if the
physical part is down.
interface is administratively down,
line protocol is up - Can’t happen,
same reason.
interface is up, line protocol is up
- That’s what we want!
The Startup Configuration And/Or
The Running Configuration
We have two configuration files
running on a router at any one time,

the startup-config and runningconfig files. Depending on how
recently you saved your work, the
contents of the two files may be the
same, but there is an important
difference between the two when
you’ve configured the router but
have not yet saved that new
configuration.
During the boot process, the router
looks for its startup configuration
file. If none is found, the router
prompts you to enter Setup Mode.
Here, I’ve just reloaded a Cisco
router that did have a startup
configuration file. I won’t show the

entire thing, but note the IP address
assigned to the Loopback0 interface
is 2.2.2.2 255.255.255.255.

R2#show start
interface Loopback0
ip address 2.2.2.2 255.255.25
no ip directed-broadcast

Let’s change the address to
22.22.22.22 and run show start
again.

R2(config)#int loopback0
R2(config-if)#ip address 22.22
R2#show start
interface Loopback0

ip address 2.2.2.2 255.255.25

We changed the address, but that
change doesn’t appear in the startup
configuration. Let’s use show
interface to see if the IP address
was indeed changed, followed by
show run.

R2#show int loopback0
Loopback0 is up, line protocol
Hardware is Loopback
Internet address is 22.22.22
R2#show run
Building configuration…
Current configuration:
interface Loopback0

ip address 22.22.22.22 255.25
no ip directed-broadcast

There’s the new address! The IP
address change isn’t in the startupconfig file because we haven’t
saved the changes. The runningconfig file does show the change.
To save our change and have the
startup-configuration file reflect the
change, we need to copy the
running-config file to the startupconfig file. Sounds like we need to
use the copy command, and I’m
going to use IOS Help to show you
a very important detail about this

command.
Actually , two details – the first
being that you run the copy
command from the enable prompt.
R2#copy ?
/erase
flash:
flh:
ftp:
null:
nvram:
rcp:
running-config
startup-config
system:
tftp:
R2#copy run ?

Erase de
Copy fro
Copy fro
Copy fro
Copy fro
Copy fro
Copy fro
Copy fro
Copy fro
Copy fro
Copy fro

ftp:
lex:
null:
nvram:
rcp:
running-config
startup-config
system:

Copy to
Copy to
Copy to
Copy to
Copy to
Update (
Copy to
Copy to

tftp:

Copy to

As you go through your Cisco
studies and your Cisco career,
you’ll use the copy command more
often than you might think. I
certainly have!
Remember the command syntax:

The first location is where
you’re copying from
The second location is where
you’re copying to
The commands copy run start and
copy start run have vastly different
meanings.
copy run start -- Copying the
running config over the startup
config
copy start run -- Copying the
startup config over the running
config

Success is in the details!
How Cisco Routers Work Hard To
Save You From Embarrassment
(And Possible Job Loss)
You’re working overnight to config
a router for a client, and you work
on it for hours, and you forget to
save your changes while you’re
working.
What if you decide to reload the
router and you’re got quite a few
unsaved changes? Or just one? The
running configuration is kept in

RAM and is lost on the reload,
while the startup configuration file
is kept in NVRAM and will be
loaded when the router is started,
so unsaved changes will not be kept
on a reload.
The router will ask you a very
important question if you attempt a
reload and the running config is
different from the startup config. To
illustrate, I’ll change R2’s hostname
to Router2 and then try a reload
without saving the change.
R2(config)#hostname Router2
Router2#reload
System configuration has been

The router is in effect asking you
“You’ve made some changes, but
haven’t saved them. Do you want
to?”
When you see a single answer in
those brackets, you can just hit
Enter to accept that answer. Here,
we have two choices. What
happens if I hit Enter?
% Please answer ‘yes’ or
System configuration has
% Please answer ‘yes’ or
System configuration has

‘no’.
been
‘no’.
been

At least the router’s polite about
forcing you to answer!

To save the changes, I’ll enter yes.
As a result, two things happened, as
shown in the following example…
“Building configuration…”
indicates the copy took place
successfully
I’m being asked to confirm
that I still want a reload
Since there’s only one answer in the
brackets, “confirm”, I can hit the
Enter key to accept that default.
After I do so, the reload begins!
System configuration has been
Building configuration…

[OK]
Proceed with reload? [confirm]

When the switch finishes reloading,
the latest hostname is indeed
shown, so we know the startup
configuration was successfully
updated.
Router2>

The Importance Of Keeping Extra
Copies Of Your Configs

You know how many PC owners
“mean” to keep backups of their
hard drives, but never really do
anything about it until their hard
drive fails?
Unfortunately, there are network
admins out there who aren’t as
diligent with keeping up-to-date
backups of their router and switch
configs as they should be.
I know we’re always busy with

something, but this process doesn’t
take very long, and you’re going to
be very happy that you have them if
you ever need them.
Why would you ever need them?
I’ve seen three different situations
where these backups came in handy.
In order of probability:
Network attackers changing
or deleting the config
An honest mistake made by a
network admin

Just as any file can become
corrupt over time, so can a
startup-config file
You can actually save a router’s
config to the flash memory of
another router if that router has
enough space in its flash, but the
most common method of saving
config files is to use a TFTP Server.

When you hear “TFTP Server”, you
tend to think of a traditional server.
Such a server can act as a TFTP
Server, but so can a laptop or a
Cisco router. I know network

admins who literally have dozens of
backup router configs stored on
their laptop, and when it comes to
updating an IOS, a Cisco router can
make a great TFTP Server.
On occasion, changing a router’s
IOS is more of an art form than a
science. Sometimes it goes
beautifully, on occasion it does not.
Here’s a quick real-world tip
regarding config file backups.
Before working on a client’s config
file, just copy and paste the config
from the router to a Notepad or
Word file. If things go badly with
your config changes, you don’t have

to guess about the startup config you’ve got a copy right there.
Updating A Router IOS
The trickiest part of changing a
router’s IOS image might be getting
the image you want! You can
download IOSes from Cisco, but a
Cisco Connection Online (CCO)
login is not enough.
The rules change as to who can and
cannot download IOS images, so I
won’t list those rules here, but you
can find out quickly by searching
Cisco’s site. Just keep in mind that

you can’t just go out to Cisco’s
website to download the latest IOS
image for your router on a whim.
Once you get the IOS you want, that
file needs to be put on a TFTP
server the router has access to. That
TFTP server can be another Cisco
router or a typical server, but
generally it’s going to be your
laptop.

If you have to perform an IOS
upgrade, you might be tempted to do
so remotely rather than physically
visit the client site - until you see
the following warning! I’ve
telnetted into a router and issued the
copy tftp flash command, and that
means we’re copying from a TFTP
server to the router’s Flash.
Here’s the warning I received, and
I’ve bolded the very, very important
part:
BRYANT_AS_5#copy tftp flash
**** NOTICE ****
Flash load helper v1.0

This process will accept the c
then terminate the current sys
the ROM based image for the co
Routing functionality will not
during that time. If you are l
telnet, this connection will t
Users with console access can
copy operati
[There are active users logged
system] Proceed? [confirm]

As you guessed, I answered “n” and
left the router up and running.
Once you do finish copying the new
IOS to Flash, this is one of the rare
occasions where you have to reload
the router for the change to take
effect. Before copying to Flash,

though, run show flash to see how
much room you have left!
The following output indicates we
don’t have much room left on this
particular router, so copying a new
IOS image to this router without
deleting the current one is just about
impossible.
BRYANT_ADVANTAGE_2#show flash

System flash directory:
File Length
Name/status
1
7432656 c2500-i-l.120
2
[7432720 bytes used, 955888 av
8388608 total] 8192K bytes of
board System flash (Read ONLY)

The Configuration Register

One day, you will have to change
the config register, most likely to
perform a password recovery. I
will just give this warning one time:
If you change the register to an
incorrect value and then reload the
router, you can cripple the router
and even Cisco can’t bring it back.
You really just have to be careful
and get the right value for what
you’re trying to do before you
change the config register. Another
key is to change the register back to
the original value once you’re done

with your work.
To see the current config register
value, run the always-helpful
command show version. The config
register value is at the very bottom
of that output, but while we’re here,
let’s take a look at all of this
information.
R1#show version

Cisco IOS Software, C2600 Soft
Version 12.4(15)T1
2, RELEASE SOFTWARE (fc3)

Technical Support: http://www.

Copyright (c) 1986-2010 by Cis

Compiled Fri 22-Jan-10 00:53 b

ROM: System Bootstrap, Version
SOFTWARE (fc1)
R1 uptime is 6 minutes

System returned to ROM by powe

System image file is “flash:c2
15.T12.bin”

< Huge Security Warning Edited

Configuration register is 0x21

The first bolded field tells you what
IOS software and version this

router is running.
The second bolded field shows you
how long the router’s been up, why
the router went down the last time it
did so (“reload”), and the IOS file
contained in flash.
Finally, the all-important config
register value. The value shown,
0x2102, is the factory default. This
value forces the router to look in its
own Flash memory for a valid IOS
on startup.
The config register value requires a
reload for a changed value to take
effect. I’ll change this value to
0x2142 and run show version again,

cropping out all information except
the config register. (The register
setting 0x2142 forces the router to
bypass the startup configuration file
kept in NVRAM.)

Router1(config)#config-registe
Router1#show version

Configuration register is 0x21
next reload)

I don’t mean to scare you away
from this command, and the odds
are that you’re going to change
more than one configuration register
setting in your career. Like debugs,

the config-register command
should be used with caution.
Another common value used with
config-register is 0x2100, which
boots the router into ROM Monitor
mode.
To review these common
configuration register settings:
0x2102: The default. Router looks
for a startup configuration file in
NVRAM and for a valid IOS image
in Flash.
0x2142: NVRAM contents are
bypassed, startup configuration is
ignored.

0x2100: Router boots into ROM
Monitor mode.
A real-world reminder: When you
change the configuration register
value to perform password
recovery, don’t forget to change it
back and then reload the router!
Let’s move on and get an
introduction to IP addressing and
the fundamentals of the routing
process!

IP Addresses and the
Routing Process

For one host to successfully send
data to another, the sending host
needs two destination addresses:
Destination MAC address
(Layer 2)
Destination IP address (Layer
3)
And yes, you have heard that

before!
In this section, we’re going to
concentrate on Internet Protocol
(IP) addressing. IP addresses are
often referred to as “Network
addresses” or “Layer 3 addresses”,
since that is the OSI layer at which
these addresses are used.
The IP address format you’re
familiar with - addresses such as
“192.168.1.1” - are IP version 4
addresses. That address type is the
focus of this section. IP version 6
addresses are now in use, and
they’re radically different from
IPv4 addresses. I’ll introduce you

to IPv6 later in this course, but
unless I mention IPv6 specifically,
every address you’ll see in this
course is IPv4.
The routing process and IP both
operate at the Network layer of the
OSI model, and the routing process
uses IP addresses to move packets
across the network in the most
effective manner possible. In this
section, we’re going to first take a
look at IP addresses in general, and
then examine how routers make a
decision on how to ge packet from
source to destination.
The routing examples in this section

are not complex, but they illustrate
important fundamentals that you
must have a firm grasp on before
moving on to more complex
examples. To do any routing, we’ve
got to understand IP addressing, so
let’s start there!

IP Addressing and an
Introduction to Binary
Conversions
If you’ve worked as a network
admin for any length of time, you’re
already familiar with IP addresses.
Every PC on a network will have
one, as will other devices such as
printers. The term for a network
device with an IP address is host,
and I’ll try to use that term as often
as possible to get you used to it!
The PC…err, the host I’m creating
this document on has an IP address,
shown here with the Microsoft
command ipconfig.

C:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Co
IP Address: 192.168.1.100
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.1

All three values are important, but
we’re going to concentrate on the IP
address and subnet mask for now.
We’re going to compare those two
values, because that will allow us
to see what network this particular
host belongs to. To perform this
comparison, we’re going to convert
both the IP address and the subnet
mask to binary strings.
You’ll find this to be an easy

conversion with practice.
First we’ll convert the IP address
192.168.1.100 to a binary string.
The format that we’re used to
seeing IP addresses take, like the
192.168.1.100 shown here, is a
dotted decimal address.
Each one of those numbers in the
address are decimal representations
of a binary string, and a binary
string is simply a string of ones and
zeroes.
Remember - “it’s all ones and
zeroes”!
We’ll convert the decimal 192 to

binary first. All we need to do is
use the following series of numbers
and write the decimal that requires
conversion on the left side:
128

64

32

16

192

All you have to do now is work
from left to right and ask yourself
one question:
“Can I subtract this number from the
current remainder?”
Let’s walk through this example and
you’ll see how easy it is! Looking
at that chart, ask yourself “Can I

subtract 128 from 192?” Certainly
we can. That means we put a “1”
under “128”.
128
192

64

32

16

1

Subtract 128 from 192 and the
remainder is 64. Now we ask
ourselves “Can I subtract 64 from
64?” Certainly we can! Let’s put a
“1” under “64”.

192

128

64

1

1

32

16

Subtract 64 from 64, and you have

zero. You’re practically done with
your first binary conversion. Once
you reach zero, just put a zero under
every other remaining value, and
you have your binary string!

192

128

64

32

16

8

1

1

0

0

0

The resulting binary string for the
decimal 192 is 11000000.
That’s all there is to it!
If you know the basics of binary and
decimal conversions, AND practice
these skills diligently, you can
answer any subnetting question

Cisco asks you.
I’ll go ahead and show you the
entire binary string for
192.168.1.100, and the subnet mask
is expressed in binary directly
below it.

192.168.1.100 = 11000000 10101

255.255.255.0 = 11111111 11111

The subnet mask indicates where
the network bits and host bits are.
The network bits of the IP address
are indicated by a “1” in the subnet
mask, and the host bits are where
the subnet mask has a “0”. This
address has 24 network bits, and

the network portion of this address
is 192.168.1 in decimal.
Any IP addresses that have the exact
same network portion are on the
same subnet. If the network is
configured correctly, hosts on the
same subnet should be found on one
“side” of the router, as shown
below.

Assuming a subnet mask of
255.255.255.0 for all hosts, we
have two separate subnets,
192.168.1.x and 192.168.4.x. What
you don’t want is the following:

This could lead to a problem, since
hosts in the same subnet are
separated by a router. We’ll see

why this could be a problem when
we examine the routing process
later in this section, but for now
keep in mind that having hosts in the
same subnet separated by a router is
not a good idea!

The IP Address Classes
Way back in the ancient times of
technology - September 1981, to be
exact - IP address classes were
defined in RFC 791.
RFCs are Requests For Comments,
which are technical proposals
and/or documentation. Not always
the most exciting reading in the
world, but it’s well worth reading
the RFC that deals with the subject
you’re studying. Technical exams
occasionally refer to RFC numbers
for a particular protocol or network
service.
To earn your CCENT and CCNA

certifications, you must know these
address classes and be able to
quickly identify what class an IP
address belongs to. Here are the
three ranges of addresses that can
be assigned to hosts:
Class A: 1–126
Class B: 128–191
Class C: 192–223
The following classes are reserved
and cannot be assigned to hosts:
Class D: 224–239. Reserved
for multicasting, a topic not

covered on the CCENT or
CCNA exams, although you
will need to know a few
reserved addresses from that
range. You’ll find those
throughout the course.
Class E: 240–255. Reserved
for future use, also called
“experimental addresses”.
Any address with a first octet
of 127 is reserved for
loopback interfaces. This
range is *not* for Cisco

router loopback interfaces.
For your exams, I strongly
recommend that you know which
ranges can be assigned to hosts and
which ones cannot. Be able to
identify which class a given IP
address belongs to. It’s
straightforward, but I guarantee
those skills will serve you well on
exam day!
The rest of this section concentrates
on Class A, B, and C networks.
Each class has its own default
network mask, default number of
network bits, and default number of
host bits. We’ll manipulate these

bits in the subnetting section, and
you must know the following values
in order to answer subnetting
questions successfully - in the exam
room or on the job!
Class A:
Network mask: 255.0.0.0
Number of network bits: 8
Number of host bits: 24
Class B:
Network mask: 255.255.0.0

Number of network bits: 16
Number of host bits: 16
Class C:
Network mask:
255.255.255.0
Number of network bits: 24
Number of host bits: 8

The RFC 1918 Private Address
Classes
If you’ve worked on different
production networks, you may have
noticed that the hosts at different
sites use similar IP addresses.
That’s because certain IP address
ranges have been reserved for
internal networks - that is, networks
with hosts that do not need to
communicate with other hosts
outside their own internal network.
Address classes A, B, and C all
have their own reserved range of
addresses. You should be able to
recognize an address from any of

these ranges immediately.
Class A: 10.0.0.0 10.255.255.255
Class B: 172.16.0.0 172.31.255.255
Class C: 192.168.0.0 192.168.255.255
You should be ready to identify
those ranges in that format, with the
dotted decimal masks, or with
prefix notation. (More about prefix

notation later in this section.)
Class A: 10.0.0.0 255.0.0.0,
or 10.0.0.0 /8
Class B: 172.16.0.0
255.240.0.0, or 172.16.0.0
/12
Class C: 192.168.0.0
255.255.0.0, or 192.168.0.0
/16
You may already be thinking “Hey,
we use some of those addresses on

our network hosts and they get out
to the Internet with no problem at
all.” (It’s a rare network that bans
hosts from the Internet today – that
approach just isn’t practical.)
The network services NAT and PAT
(Network Address Translation and
Port Address Translation) make that
possible, but these are not default
behaviors. We have to configure
NAT and PAT manually. We’re
going to do just that later in this
course, but for now, make sure you
know those three address ranges
cold!

Introduction To The Routing
Process
Before we start working with
routing protocols, we need to
understand the very basics of the
routing process and how routers
decide where to send packets.
We’ll take a look at a basic network
and follow the decision-making
process from the point of view of
the host, then the router. We’ll then
examine the previous example in
this section to see why it’s a bad
idea to have hosts from the same
subnet separated by a router.
Let’s take another look at a PC’s

ipconfig output.

C:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Co
IP Address: 192.168.1.100
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.1

When this host is ready to send
packets, there are two and only two
possibilities regarding the
destination address:
It’s on the 192.168.1.0
255.255.255.0 network.

It’s not.
If the destination is on the same
subnet as the host, the packet’s
destination IP address will be that
of the destination host. In the
following example, this PC is
sending packets to 192.168.1.15, a
host on the same subnet, so there is
no need for the router to get
involved. In effect, those packets go
straight to 192.168.1.15.

192.168.1.100 now wants to send
packets to the host at 10.1.1.5, and
192.168.1.100 knows it’s not on the
same subnet as 10.1.1.5. In that
case, the host will send the packets
to its default gateway - in this case,
the router’s ethernet0 interface. The
transmitting host is basically saying

“I have no idea where this address
is, so I’ll send it to my default
gateway and let that device figure it
out. In Cisco Router I trust!”

When a router receives a packet,
there are three possibilities
regarding its destination:
Destined for a directly
connected network.
Destined for a non-directly
connected network that the
router has an entry for in its
routing table.
Destined for a non-directly
connected network that the
router does not have an entry

for.
In each of these possibilities, the
router will check the encapsulating
frame for errors via the CFC
(remember that?), and then go about
the business of routing the packet.
Let’s take an illustrated look at each
of these three possibilities.

How A Router Handles A Packet
Destined For A Directly
Connected Network
We’ll use the following network in
this section:

The router has two Ethernet
interfaces, referred to in the rest of
this example as “E0” and “E1”. The
switch ports will not have IP

addresses, but the router’s Ethernet
interfaces will – E0 is 10.1.1.2, E1
is 20.1.1.2.
Host A sends a packet destined for
Host B at 20.1.1.1. The router will
receive that packet on its E0
interface and see the destination IP
address of 20.1.1.1.

The router will then check its

routing table to see if there’s an
entry for the 20.0.0.0 255.0.0.0
network. Assuming no static routes
or dynamic routing protocols have
been configured, the router’s IP
routing table will look like this:

R1#show ip route
Codes: C - connected, S - stat
Gateway of last resort is not
C
C

20.0.0.0/8 is directly co
10.0.0.0/8 is directly co

See the “C” and the “S” next to the
word “codes”? You’ll see
anywhere from 15–20 different

types of routes listed there, and I’ve
removed those for clarity’s sake.
You don’t see the mask expressed
as “255.0.0.0” - you see it as “/8”.
This is prefix notation, and the
number simply represents the
number of 1s at the beginning of the
network mask when expressed in
binary. That “/8” is pronounced
“slash eight”.
255.0.0.0 = binary string 11111111
00000000 00000000 00000000 =
/8
The “C” indicates a directly
connected network, and there is an
entry for 20.0.0.0. The router will

then send the packet out the E1
interface and Host B will receive it.

Simple enough, right? Of course,
the destination network will not
always be directly connected.
We’re not getting off that easy!
It’s important to note that a router is
going to look through its entire
routing table for what we call the

“best match” – the entry that most
closely matches the destination IP
address of the packet. It’s for this
reason that we like to keep our
routing tables complete and
concise. Route summarization is a
great way to do that, and that’s a
skill we’ll hit later in this course.
Now back to our network!

How The Router Handles A
Packet Destined For A Remote
Network That Is Present - Or Not
- In The Routing Table
Here’s the topology for this
example:

If Host A wants to transmit packets
to Host B, there’s a problem. The
first router that packet hits will not

have an entry for the 30.0.0.0 /8
network, will have no idea how to
route the packets, and the packets
will be dropped.
There are no static routes or
dynamic routing protocols in action
on a Cisco router by default. Once
we apply those IP addresses and
then open the interfaces, there will
be a connected route entry for each
of those interfaces with IP
addresses, but that’s it.
When R1 receives the packet

destined for 30.1.1.2, R1 will
perform a routing table lookup to
see if there’s a route for 30.0.0.0.
The problem is that there is no such
route, since R1 only knows about
the directly connected networks
10.0.0.0 and 20.0.0.0.

R1#show ip route
Codes: C - connected, S - stat
Gateway of last resort is not
C
C

20.0.0.0/8 is directly con
10.0.0.0/8 is directly con

Without some kind of route to
30.0.0.0, the packet will simply be

dropped by R1.

We can use a static route or a
dynamic routing protocol to resolve
this. Let’s go with static routes,
which are created with the ip route
command. The interface named at
the end of the command is the local
router’s exit interface. (Plenty more

on this command coming in a later
section!)

R1(config)#ip route 30.0.0.0 2

The routing table now displays a
route for the 30.0.0.0 /8 network.
The letter “S” indicates a static
route.

R1#show ip route
Codes: C - connected, S - stat
C
C
S

20.0.0.0/8 is directly con
10.0.0.0/8 is directly con
30.0.0.0/8 is directly con

R1 now has an entry for the

30.0.0.0 network, and sends the
packet out its E1 interface. R2 will
have no problem forwarding the
packet destined for 30.1.1.2, since
R2 is directly connected to that
network.

If Host B wants to respond to Host
A’s packet, there would be a
problem at R2, since the incoming

destination address of the reply
packet would be 10.1.1.1, and R2
has no entry for that network. A
static route or dynamic routing
protocol would be needed to get
such a route into R2’s routing table.
The moral of the story: Just because
“Point A” can get packets to “Point
B”, it doesn’t mean B can get
packets back to A!

Why We Want To Keep Hosts In
One Subnet On One Side Of The
Router
Earlier in this section, the following
topology served as an example of
how not to configure a network.

Now that we’ve gone through some
routing process examples, we can

see why this is a bad setup. Let’s
say a packet destined for
192.168.1.17 is coming in on
another router interface.

The router receives that packet and
performs a routing table lookup for
192.168.1.0 255.255.255.0, and

sees that network is directly
connected via interface E0.
The router will then send the packet
out the E0 interface, even though the
destination IP address is actually
found off the E1 interface!

In future studies, you’ll learn ways
to get the packets to 192.168.1.17.
For your CCENT and CCNA
exams, keep in mind that it’s a good
practice to keep all members of a
given subnet on one side of a router.
It’s good practice for production
networks, too!

Secondary IP Addressing
The following info is going to
violate every rule of IP addressing
you know, and some you’ll learn in
the future, so have some duct tape
ready, because I’m about to blow
your mind and you’ll need
something to put it back together.
If absolutely necessary, you can
assign multiple IP addresses to a
router interface with the secondary
option, as shown here:

R1(config)#int fast 0/0
R1(config-if)#ip address 172.1
R1(config-if)#ip address 172.1
secondary Make this IP addre

<cr>
R1(config-if)#ip address 172.1

R1#show ip route
172.12.0.0/24 is subnette
C
172.12.13.0 is directl
FastEthernet0/0
C
172.12.14.0 is directl
FastEthernet0/0

Using secondary addressing is a lot
like applying a tourniquet to your
leg. It’ll really come in handy under
certain extreme situations, but it’s
not something you want to do unless
those situations arise.
Cisco’s website mentions the
following as three such situations:

You run out of addresses on a
given segment
When changing the IP
addressing scheme of your
network
Two separate subnets of the
same network are separated
by another network.
Remember our “keep your
subnets on one side of the
router” discussion!
Secondary addressing is both a
blessing and a curse. It can
definitely help in particular
situations like the ones discussed

here, but it can also bring up
unexpected routing issues. I
personally don’t use it unless I
absolutely have to, but it’s a good
tool to have in your mental toolbox!

The Administrative Distance
Earlier, I mentioned that our routing
process is looking for the best
match for the destination IP address
of the packet. There just might be a
tie for that honor, and in that case,
we’ll need a tiebreaker!
Let’s say we’re running both OSPF
and EIGRP on our router. If they
both give the router a route for
20.1.1.0 /24, how does the router
decide which one to put into the
table?
The route will use the
Administrative Distance of the
source of the route to make that

decision. The admin distance is a
measure of the source’s
believability, and the lower the AD,
the more believable the source.
Here’s a list of common route
sources and their Ads. The lower,
the better – the more believable,
that is!
Connected routes: 0
Static routes: 1
Internal EIGRP: 90
OSPF: 110
RIP: 120
External EIGRP: 170

An AD of 255 indicates an
unreliable source.
I know you haven’t hit these
dynamic routing protocols in your
study yet, but I wanted to introduce
you to this concept now. As we get
to these topics, I’ll remind you of
the AD and where to see it.

Inside The Router
The CCENT doesn’t go any real
detail about the processes going on
inside our routers. We really don’t
mind that, since we have enough to
learn as it is! However, there’s one
term I’d like you to be familiar
with.
Cisco Express Forwarding (CEF)
is highly advanced routing logic that
adds a great deal of speed over
other routing logic processes. It
does so by keeping tables beyond
the IP route table we’ll be looking
at through this course:

The Forwarding Information
Base (FIB), a version of the
route table
The Adjacency Table, which
contains L2 adjacency
information, which in turn
cuts down on the need for
ARP Requests
Now that we have a firm grasp on
IP addressing and the overall
routing process, let’s move forward
and work with some Cisco router
and switch commands!
Also, I’d like to invite you to join

my free and almost-free Video Boot
Camps on Udemy! Tens of
thousands of students are already
there, and this is a great time for
you to join us!
All of my Video Boot Camps are
fully downloadable and streamable,
so you can watch them whenever
you like, wherever you like!
Just visit this URL for a full list of
my courses, and I’ll see you on
Udemy!

https://www.udemy.com/u/chrisbryan

Config Modes And
Fundamental
Commands
An Overview Of Configuration
Modes
To put commands into action on a
Cisco router, we enter a
configuration mode before actually
configuring the command. You’ve
seen a few of these modes already,
so let’s take just a moment to
review them.
Global configuration mode is

entered with the configuration
terminal command. You have to go
into this mode to get to any other
configuration mode, as you’ll see in
just a moment. Note how the prompt
changes in the following
configuration when I enter global
config mode.
R1#configure terminal
Enter configuration commands,
CNTL/Z.
R1(config)#

Any command you enter in global
configuration mode takes effect
immediately. To illustrate, I’ll use
the hostname command to change

the router’s name from R1 to
Router1.
R1#configure terminal
Enter configuration commands,
CNTL/Z.
R1(config)#hostname Router1
Router1(config)#

The name changed immediately,
with no reload or reboot necessary.
It’s rare that you have to reboot a
Cisco router or switch to make a
change take effect, but it does
happen – and just might happen
later in this course!
You’ve seen two line configuration

modes, for the Console port and the
VTY lines. I have to go into global
configuration mode before entering
line configuration mode. If I try to
go straight to line config mode, I get
an error.

Router1#line vty 0 4
^
% Invalid input detected at '^

When I go from global
configuration mode to line config
mode, you see the prompt change
again.
Router1#conf t
Enter configuration commands,

CNTL/Z.
Router1(config)#line vty 0 4
Router1(config-line)#

To configure an interface, we enter
- you guessed it! - interface
configuration mode. We have to be
in global configuration mode first.

Router1#interface serial 0
^
% Invalid input detected at '^
in global mode)

Router1#conf t
Enter configuration commands,
CNTL/Z.
Router1(config)#interface seri
Router1(config-if)#

Watch the prompts on exam day
questions - they’re a tipoff as to
which configuration mode a router
or switch is in. You don’t have to
memorize every config mode, but
you should be comfortable with the
following prompts.
Global configuration mode:
Router1(config)
Interface configuration mode:
Router1(config-if)#
Line configuration mode:
Router1(config-line)
To get back to the Enable prompt
from any configuration mode, enter

<CTRL - Z> once or type EXIT to
go back one config mode.
<CTRL - Z> example:
Router1(config-if)#^Z
Router1#

Note we went straight from
interface configuration mode to the
Enable prompt.
Typing EXIT brings you back one
config mode. In the following
example, entering EXIT once took
us from interface configuration
mode to global config mode; typing
EXIT a second time took us back to

the enable prompt.
Router1(config-if)#exit
Router1(config)#exit
Router1#

There is no right or wrong choice
between EXIT and < CTRL - Z >,
but do keep in mind that EXIT takes
you back one mode while < CTRL Z> takes you back to the Enable
prompt.
If all of these keystrokes are a little
confusing at first, don’t worry about
it. It does take time to get
comfortable with them. You’ll find
that all of this becomes second

nature very quickly, and you’ll enter
the config mode you need without
even thinking about it.

Physical Connections And
Passwords
Note: All of the information
regarding passwords in this
section is true for both routers and
switches, even though I don’t
continually say “routers and
switches”.
Here’s a very small clip of a Cisco
switch configuration:
line con 0
line vty 0
4 login
line vty 5
15 login

A Cisco router has five VTY lines:
line vty 0 4

This small, seemingly insignificant
portion of the configuration actually
determines what passwords a user
must enter in order to connect
successfully. When you connect to a
Cisco router or switch, you’re
going to do so in one of two ways:
Physically connecting,
usually via a laptop
Logically connecting from a

remote location via Telnet or
SSH
We’re going to discuss the physical
connection first, including the
cables and adapters you may need,
as well as how to configure a
password for such a connection.
You may have already seen some of
this in an earlier section, and it will
only help you to see it again.
For a physical connection, you’re
going to need a rollover cable. This
is typically a blue cable with an RJ45 connector on one end and a DB9 connector on the other. The RJ-45
connector snaps into the Console

port of the switch or router, and the
DB-9 connector connects to your
laptop -- maybe!

The first “gotcha” you have to
watch out for is placing the rollover
cable’s RJ-45 connector into the
correct port. The Console port will
be labeled “CON”, but there are
quite a few ports on that switch that
will let you plug the rollover cable

into them - but the connection will
not work. Additionally, some Cisco
routers will have an Auxiliary port
right next to the Console port, and
the rollover cable will fit into the
AUX port.
It’ll fit, it just won’t work!
No modern laptops are going to
have a DB-9 port on them. Before
you visit a client site with a brandnew laptop and a rollover cable,
make sure to get the proper adapter
for your laptop. They’re generally
cheap and readily available on
eBay and from any cable dealer.
Real-world note: If you buy cables

on eBay, watch the shipping
charges. Some dealers put high
shipping charges on cables to make
up for their “low price”.
Now that we’ve got the cable and
the adapters that we need, it’s time
to connect to the switch! You’re
going to use a terminal emulator
program to do so, and you should
use the following settings with your
emulator:
9600 bits per second
8 data bits
No parity

1 stop bit
no flow control
Now that we’re connected, let’s get
back to the passwords.
You won’t be prompted for a
password when connecting through
the console port. That means anyone
with a laptop and a rollover cable
can connect successfully to this
switch, and that’s a default we’d
like to change.
Let’s take another look at the
password portion of our switch’s
configuration:

line con 0
line vty 0
4 login
line vty 5
15 login

To protect the switch’s console
port, it’s the “line con 0” we need
to be concerned with. If we’re
going to use a single password to
protect the console port, we’ll
actually need two commands:
the password command
the login command
I want to clear up one point of

contention right here. It does not
matter in which order you configure
these commands as long as you
configure them both! Here’s how
we set a password of CCENT for
console port access:

SW1#configure terminal
Enter configuration commands,
CNTL/Z.
SW1(config)#line console 0
SW1(config-line)#login
SW1(config-line)#password CCEN

Now when a user attempts to
connect to the switch via the
console port, they’ll be prompted
for that password, as shown here:

Router1 con0 is now
available Press RETURN to
get started.

User Access Verification

Password: <I entered CCENT her
on the screen >

Router1>

Done and done!
Now that we’ve secured our local
connection to the router, let’s secure

our remote connection tools –
Telnet and SSH!

Telnet And SSH Passwords
To review the methods available to
connect to a Cisco router:
Physically connecting a
laptop to the Console port
Connecting from a remote
location via Telnet (TCP port
23) or SSH (TCP port 22)
Typically you’re going to be outside
a network when you use Telnet, but
you can use Telnet inside a network
as well. If you’re working at a PC
in your local network and you need
to check something on a switch or

router in that same network, there’s
no need to physically visit the
switch or router - you can just
Telnet to it.
There is one major rule that holds
true for any Telnet configuration on
a Cisco router or switch: You must
configure a password on the VTY
lines. Without a password on the
VTY lines, no user will be able to
telnet to a Cisco router or switch!
In the following example, I’ve
attempted to telnet to a Cisco router
that has no VTY line password set.

R1#telnet 172.12.123.3
Trying 172.12.123.3 ... Open

Password required, but none se

[Connection to 172.12.123.3 cl

The console port didn’t require a
password, but there is a little basic
security in place when using that
port, since the user has to
physically be present in order to
access the router.
With Telnet connections, the user
doesn’t have to be physically
present -- that’s the reason we use it
in the first place! We certainly don’t
want just anyone connecting to our

network, so Cisco routers and
switches require a password to be
set for Telnet access. Failure to set
one results in a message like the
one we just saw.
Let’s set a Telnet password! On a
Cisco router, the password portion
of the router configuration will look
almost the same as it does on a
switch. A router has fewer VTY
lines than a switch does - a router
has five, most switches have 16.
The vty lines are the virtual
terminal lines, and it’s those lines
that are used for Telnet. To

configure a password on all five vty
lines at once, just use this
configuration:
R3(config)#line vty 0 4

R3(config-line)#password CCENT
R3(config-line)#login

Now what happens when we try to
telnet from R1 to R3 again?
R1#telnet 172.12.123.3
Trying 172.12.123.3 ... Open

User Access Verification
Password:

R3>

Success! We were prompted for the
password, and after we entered it,
we’re now in R3, as indicated by
the prompt.
Some vendors have asterisks
appear as you enter a password, but
Cisco routers and switches do not.
You will not see any characters
appear as you enter that password.
Take a look at the prompts in the
password entry example. Note that
R1 has a pound sign after “R1”, but
that R3 has a “greater than” symbol.

Before we continue our Telnet
discussion, we’re going to talk
about router modes, privilege
levels, and exactly what those
particular symbols indicate.

User, Enable, And Privilege
Modes
When you first connect to a Cisco
router or switch via Telnet or SSH,
by default you’re going to be placed
into user exec mode. This mode is
indicated by the “>” symbol after
the device name.
R1>

There’s not much you can do from
this mode except use some show
commands to have a look around. If
I attempt to use the configure
terminal command, the router will
not allow me to do so.

R1>configure terminal
^
% Invalid input detected at '^
R1>

That little carat shows you where
you went wrong. In this case, we
went wrong by trying to use this
command in user exec mode.
To configure the router, we need to
go to the next level, privileged
EXEC mode (generally called
“enable mode>). To get there, we
need to enter the enable command
in user exec mode. The prompt
should change slightly…

R1>enable
R1#

… and it does! I can now enter
configure terminal successfully to
enter global configuration mode,
and use the hostname command to
change the device’s name. (To get
you used to seeing the popular
abbreviation for configure
terminal, I’ll use it for the rest of
this course.)
R1#conf t
Enter configuration commands,
CNTL/Z.
R1(config)#hostname Router1
Router1(config)#

We have the option of setting a
password for enable mode.
Actually, we have two options, he
enable password and the enable
secret. You often see routers with
one or both of these set, so we
better know what the differences
are between the two as well as
what happens when you set both!

The “enable password” and
“enable secret” Commands
Using an enable mode password is
optional - unless you have users
connecting via Telnet. (Thought I
had forgotten about the Telnet
discussion, didn’t you? We’re
getting back to that in just a minute!)
We have two options for
configuring an enable mode
password, as shown below by IOS
Help.
Router1(config)#enable ?
password
password

Assign the privil

secret
secret

Assign the privil

I’ve edited a couple of non-CCENT
and non-CCNA-related options
from that IOS Help output so we
can concentrate on these two
options. Looking at the IOS Help
readout, it looks like they do pretty
much the same thing, and in reality,
they do, with one big difference. To
demonstrate, we’ll first use the
enable password command to set a
password of CCENT.

Router1(config)#enable passwor

Now we’ll go back to user exec
mode, and then try to get back to
enable mode.
Router1#logout
Router1 con0 is now
available Press RETURN to
get started.

Router1>enable
Password: < I entered CCENT he
appear on the screen >
Router1#

After entering the enable command
to get into enable mode, I was now
prompted for a password. I entered
CCENT (which was not shown on
the screen as I typed it in), and I am
now back in enable mode.
Let’s take a quick look at the current
router configuration with show
running-config. The console and
VTY line passwords will appear at
the bottom of the config, but the
enable passwords will appear near
the top, so I’ll show you only that
part of the config in this section.
Router1#show running-config
Building configuration...

hostname Router1
enable password
CCENT

The enable password worked fine,
but it’s appearing in clear text.
That’s not a very secure password.
Anyone looking over your shoulder
can see what the password is!
(That’s referred to as the “over-theshoulder network attack”.)
We have a method of encrypting that
password, along with the others in
the configuration. Before we do
that, let’s use the enable secret

command to set an enable password
of CCNA and see what happens
when we try to get back into enable
mode.
Router1(config)#enable secret

I’ll now enter a password of
CCENT, the enable password,
which worked just a few minutes
ago.

Router1>enable
Password:
< I entered CCENT
>
Password:

That isn’t a typo, and you’re not
seeing double. I’m being prompted
for a password a second time
because the first one I entered was
not correct. If CCENT wasn’t right,
will CCNA be?
Router1>enable
Password:
Router1#

Yes! When both the enable secret
and enable password commands
are in use, the password set with
the enable secret command will
always take precedence.
By the way, here’s what you see if

you wait too long to enter the
enable password:
Password:
% Password: timeout expired!
Password:

By default, you get three tries to
enter the correct enable password.
If all three attempts fail, you’ll get a
“bad enable” or “bad secrets”
message from the router, and you’re
placed back at the user exec
prompt.
Router1>enable
Password: <attempt 1>

Password: <attempt 2 times ou
% Password: timeout expired!
Password:
<attempt 3>
% Bad secrets
Router1>

To see the other major difference
between the two, let’s take a look at
the running configuration.
enable secret 5
1$oNGE$OYXryHhM7E3GIXcDdCAwF1
enable password CCENT

That’s not exactly “CCNA” behind
enable secret there, is it? The main

reason we use enable secret today
rather than the enable password
command is that passwords
configured with enable secret are
automatically encrypted. It’s easy to
see what the enable password is,
but I don’t think too many of us are
going to look at that enable secret
value and determine that it means
“CCNA”!

Enable Passwords And Telnet
Now you may well be asking why I
interrupted our Telnet discussion to
talk about router modes and enable
passwords. Good question, and
trust me, there’s a good reason!
Enable passwords are optional unless users will be connecting via
Telnet. Let’s go back to our original
example where I’m connecting from
R1 to R3:
Router1#telnet 172.12.123.3
Trying 172.12.123.3 ... Open

User Access Verification

Password:
R3>

We’ve successfully used Telnet to
connect to R3 from R1, and all is
well. Let’s use the enable command
on R3 to enter privileged exec
mode and get started configuring!
R3>enable
% No password set

Oops.
We have a major problem. No
enable password has been set on

R3, so we literally cannot enter
privileged exec mode though the
Telnet connection! To allow that
kind of connection, someone with
physical access to R3 is going to
have to set an enable password.
R3(config)#enable secret CCIE

After doing so, we’ll telnet from R1
to R3 again and see what happens.
Router1#telnet 172.12.123.3
Trying 172.12.123.3 ... Open

User Access Verification

Password:
R3>enable
Password:
password>
R3#

< I entered CCENT h

< I entered CCIE he

I’ve now successfully used Telnet
to open the connection by entering
the VTY password, and I’ve
entered privileged exec mode with
the enable password “CCIE”.
To recap:
No password is required for
connecting to the router via
the Console port, but it’s
recommended.

A password on the VTY lines
is required to allow Telnet or
SSH users to connect.
For Telnet and SSH users to
access enable mode, either an
enable password must be
configured OR the following
command must be configured
on the VTY lines.
This command, that is!

Using “privilege exec 15”
You may want incoming Telnet
users to be placed directly into
privileged exec mode without being
prompted for an enable password.
(An excellent idea for lab work.)
To do so, configure the privilege
level 15 command on the VTY lines
of the router allowing the
connections. We’ll do that now on
R3 and then telnet to that router
from R1.

R3(config)#line vty 0 4
R3(config-line)#privilege leve

Router1#telnet 172.12.123.3
Trying 172.12.123.3 ... Open

User Access Verification
Password:
R3#

<I entered CCENT he

As a result of the privilege level 15
command, I was placed directly
into enable mode and was not
prompted for an enable password.
In future studies, you’ll learn how
to configure custom privilege
levels. The only two you need to
know now are the two defaults.
User exec has a privilege level of 1

and privileged exec has a privilege
level of 15.

What’s So Secure About Secure
Shell?
Telnet’s a great way to
communicate remotely with routers
and switches, but there’s an obvious
problem. All Telnet-related 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 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 more
importantly, maybe some new
hardware. We’re certainly not
scared of work, but our current
hardware may not support SSH.
With SSH, we need to create a
username / password database
rather than using the singlepassword “login” setup we used
with Telnet.

The word “database” may send
shivers up ye spine, but worry not.
I’ll show you how to create one on
a Cisco switch in just a moment.
We could set up an AAA server
(Authentication, Authorization, and
Accounting) that would handle
authentication. Setting up an AAA
server is out of the scope of the
CCENT and CCNA exams, but you
should know the commands for
setting up a Cisco switch to perform
authentication via a local
username/password database.
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 local command
tells the switch to look to a
database on the local device for
valid username/password
combinations.
SW2(config)#line vty 0 4
SW2(config-line)#login local

You have the option of allowing
Telnet, SSH, or both with the
transport input command. We’ll
configure the switch to accept both.

SW2(config-line)#transport inp

Then we’ll create the
username/password database!

SW2(config)#username general p
SW2(config)#username captain p
SW2(config)#username major pas

When a user attempts to connect to
this switch, 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!
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 domainname command
A crypto key must be created
with the crypto key generate
rsa command, and when you
do, you’ll see this message
verifying that SSH is

enabled:
*Mar 3 02:01:01.406:
%SSH-5-ENABLED: SSH
1.99 has been enabled
You’ll learn much more about
crypto keys and their use in your
CCNP studies. That’s enough SSH
for now!

Assigning An IP Address And
Default Gateway To The Switch
In the switch configuration, there’s
a pre-created virtual interface that
can be found just below the last
physical interface and just above
the console lines:
interface
FastEthernet0/24 !
interface Vlan1
no ip address
no ip routecache shutdown
!
ip http server
!
line con 0

exec-timeout 0 0
logging
synchronous

For users to successfully Telnet or
SSH to the switch, there must be an
IP address for them to connect to,
and that is the IP address assigned
to the VLAN1 interface. We’ll
assign an IP address to that
interface now:

SW2(config)#int vlan1
SW2(config-if)#ip address 40.4
SW2(config-if)#
00:57:40: %LINK-3-UPDOWN: Inte
state to up
00:57:41: %LINEPROTO-5-UPDOWN:
Interface Vlan1, changed state

Verify with show interface vlan 1.
Note the hardware is listed as
“CPU interface”. This particular
interface is often referred to as the
switch management interface, or
just “management interface”.

SW2#show interface vlan 1
Vlan1 is up, line protocol is
Hardware is CPU Interface, add
(bia 000e.d7f5.a040) Internet

The switch operates at Layer 2 of
the OSI model, and is incapable of
routing. We need to assign this
switch a default gateway. This can
be done via DHCP, but it’s common
to statically assign this gateway

with the ip default-gateway
command.

SW2(config)#ip default-gateway

Changing The Speed And Duplex
Of A Switch Port - On Single And
Multiple Ports
SW2(config)#int fast 0/1
SW2(config-if)#speed ?
10

Force 10 Mbps operation

100

Force 100 Mbps operation

auto Enable AUTO speed
configuration
SW2(config-if)#duplex ?
auto Enable AUTO duplex
configuration
full Force full duplex
operation

half Force half-duplex
operation

Changing a single port from one
speed or duplex to another is
simple enough, but what if you had
to change 20 ports at one time?
Whether you’re on the job or in the
exam room, the interface range
command is a huge time-saver.
I’ll use the interface range
command to change the speed on the
first six ports to 10 Mbps. Before
changing the speed, I’ll use IOS
Help to illustrate that you can use
this command with any type of

interface on the switch, including
several that we haven’t seen.

SW2(config)#interface range ?
FastEthernet FastEthernet IE
Loopback
Loopback interf
Port-channel Ethernet Channe
Tunnel
Tunnel interfac
Vlan
Catalyst Vlans

SW2(config)#interface range fa
SW2(config-if-range)#speed 10

Just looking at the config, we can
see those first six ports were indeed
changed:
interface

FastEthernet0/1 speed
10
!
interface
FastEthernet0/2
speed 10
!
interface FastEthernet0/3
speed 10
!
interface
FastEthernet0/4
speed 10
!
interface
FastEthernet0/5
speed 10
!
interface
FastEthernet0/6 speed
10

We can change them to 100 Mbps in
the same fashion!

SW2(config)#interface range fa

SW2(config-if-range)#speed 100
interface
FastEthernet0/1 speed 100
!
interface
FastEthernet0/2
speed 100
!
interface
FastEthernet0/3
speed 100
!
interface
FastEthernet0/4
speed 100

!
interface
FastEthernet0/5
speed 100
!
interface
FastEthernet0/6
100

speed

If you needed to change the port
speed on 24 ports, do you want to
do them one at a time, or all with
one single command? With one
command, of course!

Creating Banners
For legal reasons, you need to warn
users that unauthorized access to the
router is prohibited. (In court, you
would need to prove the person
knew they were not supposed to go
into your network.) 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 commonly used
is the Message Of The Day
(MOTD) option.

SW2(config)#banner ?
LINE
c banner-tex
delimiting character
exec
process creation banner
incoming
Set incoming
login
Set login ban
motd
Set Message o
prompt-timeout
Set Message f
timeout
slip-ppp

Set Message f

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

SW2(config)#banner motd ?
LINE c banner-text c, where
character

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.

SW1(config)#banner motd $
Enter TEXT message. End with t
Network down for router IOS up
tonight! $

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, come back
in, and I’m presented with the
MOTD banner message.
SW1 con0 is now available
Press RETURN to get started.

Network down for router IOS up
tonight!
SW1>

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.

SW2(config)#banner login %
Enter TEXT message. End with t
%. Unauthorized Login Prohibit

I’ve added a console line password
of cisco as well:
line con 0
exec-timeout 0 0
password cisco
logging
synchronous
login

When I log out and then log back in,

I see the MOTD banner message
followed by the login banner
message.
SW1 con0 is now available
Press RETURN to get started.

Network down for router IOS up
tonight! Unauthorized Access P
But You Knew That.
User Access Verification
Password:
SW1>

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

banner login ^C
Unauthorized Access Prohibited
Knew That. ^C banner motd ^C
Network down for router IOS up
tonight! ^C

No matter what delimiting character
you use, you’ll see it represented as
^C in the config.
Let’s use IOS Help to look at our
other options:

SW2(config)#banner ?
LINE
c banner-text
delimiting character
exec
Set EXEC proc
incoming
Set incoming
login
Set login ban
motd
Set Message o

prompt-timeout
timeout

Set Message f

slip-ppp

Set Message f

To present a banner message to
users who have successfully
authenticated, use the banner exec
command.
You can use the ENTER key for
hard breaks in a banner message, as
shown below.

SW1(config)#banner exec *
Enter TEXT message. End with t
Welcome to our nice, clean net
pressed >
Please keep it that way. *

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

Network down for router IOS up
tonight! Unauthorized Access P
But You Knew That.

User Access Verification
Password:
Welcome to our nice, clean net
Please keep it that way.
SW1>

Those Odd Little Commands
You might have noticed these two
commands on the console line:
line con 0
exec-timeout 0 0
logging
synchronous

Here’s why I love these two
commands.
When the router wants you to know
something, it wants you to know
right now. If the router sends a
message to the console while

you’re entering a command, by
default the router will interrupt your
work to show you that message.
In the following example, I opened
a Serial interface, which will
always result in at least two
messages relating to the physical
and logical state of the interface. I
started typing a sentence
immediately after I opened the
interface to show you what
happens. I’ve bolded the sentence I
was entering.
R1(config)#int s0
R1(config-if)#no shut
R1(config-if)#^Z

R1#so here i am
4d04h: %SYS-5-CONFIG_I: Config
consoletyp
4d04h: %LINK-3-UPDOWN: Interfa
to uping and
4d04h: %LINEPROTO-5-UPDOWN: Li
Serial0, changed state to upi’
quite badly!
4d04h: %LINEPROTO-5-UPDOWN: Li
Serial0, changed state to down

This may seem trivial, but when you
have a long command entry
interrupted by a console message,
you’ll wonder how to prevent that
from happening. (After you stop
yelling at the router, that is.) By
configuring the logging
synchronous command on the

console port, you’re telling the
router to hold such messages until it
detects no input from the keyboard
and no other output from the router,
such as a show command’s output.
R1(config)#line console 0
R1(config-line)#logging ?
synchronous Synchronized
message output

The second command I always
enter on the console port of a home
lab router is exec-timeout 0 0. This
disables the console session default
inactivity timeout of 5 minutes and

0 seconds. If you want to change
that timer rather than disabling it,
the first number represents the
number of minutes in the inactivity
timer and the second number is the
number of seconds.

R1(config)#line con 0
R1(config-line)#exec-timeout ?
<0-35791> Timeout in minutes

R1(config-line)#exec-timeout 0
<0-2147483> Timeout in seconds
<cr>

R1(config-line)#exec-timeout 0

(disables the inactivity timer

This command can also be
configured on the VTY lines to set
or disable the inactivity timer for
Telnet and SSH users. Here, we’ll
set the VTY line inactivity timer to
10 minutes, double the default time.

R1(config)#line vty 0 4
R1(config-line)#exec-timeout ?
<0-35791> Timeout in minutes

R1(config-line)#exec-timeout 0
<0-2147483> Timeout in
seconds
<cr>

R1(config-line)#exec-timeout 1
<0-2147483> Timeout in
seconds <cr>

R1(config-line)#exec-timeout 1

I don’t like to disable a production
router’s Telnet and SSH inactivity
timers, as there are security risks
associated with doing so. They’re
great commands for your present or
future home lab, and I also
recommend you know them for your
CCENT and CCNA exams!

Keystroke Shortcuts
There are quite a few key
combinations that will make your
life easier, and I’m going to list the
most popular ones here. I want to
make it clear that you do not have to
use these in real life. I only use a
few myself!
One of my favorites is the up arrow,
which will show you the last
command you entered. If you
continue to hit the up arrow, you’ll
continue to go through the command
history. <CTRL-P> does the same
thing.
As you might expect, the down

arrow brings you one command
back in the command history. It’s a
good key to use when you use the up
arrow too fast. <CTRL - N> does
the same thing.
<CTRL - A> takes the cursor all the
way to the front of your current
command; <CTRL - E> takes the
cursor all the way to the end of your
current command.
Want to move around on a percharacter basis in your current
command without deleting
characters? Use the left arrow or
<CTRL - B> to move backward one
character, and use the right arrow or

<CTRL - F> to move forward one
character.
Some of the lesser-used shortcuts
include:
<CTRL - D> deletes one character.
You can do the same thing with the
BACKSPACE key.
<ESC - B> moves back one word
in the current command.
<ESC - F> moves forward one
word in the current command.
Again, you don’t have to use all or
any of these. I like the up and down
arrows to see the command history,
and <CTRL - A> is great when you

want to just put “no” in front of a
command to negate it. You can
certainly pick and choose the ones
you prefer, but it’s a good idea to
know what they all do for your
CCENT and CCNA exams.
And speaking of the command
history….

Manipulating And Changing
History (Buffers, That Is)
It may be forbidden for you to
interfere with human history, but
that doesn’t mean you can’t take a
look at it!
Using the up and down arrows to
see the commands recently run on
the router is really handy, but it’s
easy to miss the one you need. To
see the command history, run show
history.
R1#show history
show dialer
show ip ospf
neighbor

conf t
show ip ospf
neighbor
show
dialer
show ip ospf
neighbor
show
dialer
show run
show hsitory
show history

As you can see, I misspelled
“history” in the next-to-last
command!
If you’re in the middle of a large

configuration or a tough
troubleshooting situation, you can
change the size of the history buffer
from its default of 10. Note that you
do this at the Console port or VTY
line level. Changing the default for
the Console port doesn’t change the
default for the VTY line, and vice
versa.

R1(config)#line con 0
R1(config-line)#history size ?
<0-256> Size of history buffer

R1(config)#line vty 0 4
R1(config-line)#history size ?
<0-256> Size of history buffer

The number we specify with this
command is the number of
commands held in the history buffer.

A Word About The Password
Recovery Process
There’s no feeling like it in the
world… you reload a router,
attempt to enter Enable mode, get a
password prompt…. and no one at
the site knows what the password
is.
Sooner or later, you’re going to
have to perform a password
recovery process. This process
differs from one Cisco model to
another, but luckily for us there’s a
single page on Cisco’s website that
lists the procedures. I will not put
the URL here since those do change,

but if you simply put the phrase
“cisco password recovery” in
Google, you’ll find the page
quickly.
A word to the wise: Read the
recovery process for your
particular model at least twice
before starting it. The process
generally requires altering the
router or switch configuration
register, and changing the register
value incorrectly can cause
irreparable damage to the router.
Not trying to scare you, because you
will have to perform password
recovery sooner or later. You just

want to be careful when doing so!
Time for some more routing! Static
routing, that is – and it’s coming
right up in the next section!

Static Routing
(With A Side Of DistanceVector)
In the “Intro To Routing” section,
you were given a sneak peek at
static routing. In this section, we’ll
configure static routing on live
Cisco routers and use some new
commands to test IP connectivity.
There’s plenty of IP connectivity
troubleshooting built into this
section!
It’s important to understand static

routing for your CCENT and CCNA
exams, and you’ll find it helpful in
working with real-world networks
as well. Let’s jump right in!

Static Routes
Here’s the network we’ll use for the
static routing discussion and labs:

This is a hub-and-spoke network,
with R1 serving as the hub and R2

and R3 as the spokes. When one
spoke sends traffic to another
spoke, that traffic will go through
the hub. That’s a very important
concept to keep in mind!
I’m introducing you to loopback
interfaces in this section. Loopback
interfaces are logical interfaces they do not physically exist on the
router. You’re going to see more
and more real-world uses for
loopbacks as you progress in your
studies, and they’re great in lab
environments for adding extra
networks for extra practice!
For this lab and all others in this

course, the last octet of the IP
address for any physical interface
will be the router number. For
loopbacks, we’ll use the router
number for each octet.
The networks used in this section:
Hub-and-Spoke Network:
172.12.123.x /24
R2’s loopback interface:
2.2.2.2 /32
R3’s loopback interface:
3.3.3.3 /32

We’re going to use pings to test IP
connectivity throughout this section.
When you ping an IP address,
you’re sending five ICMP Echo
packets to the IP address you
specify. If you get five ICMP Echo
Replies in return, you’ll see five
exclamation points, and that means
you have IP connectivity to the
specified destination.
For example, right now R1 can ping
the serial interfaces on R2 and R3.
1#ping 172.12.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos

is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 68/68/72 ms
R1#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 68/68/68 ms

There are no routing protocols or
static routes on the routers, so how
can R1 successfully ping those two
destinations? Let’s use show ip
route to take a look at R1’s routing

table. (For clarity, I’ve removed all
route codes except the connected
and static codes.)
R1#show ip route

Codes: C - connected, S - stat
Gateway of last resort is not

172.12.0.0/24 is subnette
C

172.12.123.0 is direct

There’s only one route in R1’s
routing table, but that’s enough for
those two pings. It’s the
172.12.123.0 /24 network, and the
two destinations we pinged are on

that network.
That network appears as a
Connected network, meaning
there’s an interface on this router
that’s configured with an IP address
from that subnet. The entry also
tells you which interface that is.
Let’s see if our spokes can ping the
hub, and each other. Can R2 ping
both 172.12.123.1 and .3?
R2#ping 172.12.123.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos

seconds:
!!!!!

Success rate is 100 percent (5
68/68/68 ms
R2#ping 172.12.123.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
seconds:
!!!!!

Success rate is 100 percent (5
128/133/144 ms

R2 can ping both addresses. Here’s
the path the data took to get to R3:

The ping reply from R3 to R2 also
comes back through R1.

Can R3 ping 172.12.123.1 and .2?

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
seconds:
!!!!!

Success rate is 100 percent (5
68/68/68 ms
R3#ping 172.12.123.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
seconds:
!!!!!
Success rate is 100 percent (5
128/133/144 ms

Yes! Both the ping from R3 to R2
and the ping reply from R2 to R3
went through R1. Since every router
on the network has an entry for
172.12.123.0 /24 in its routing table
(the connected route), there’s no
problem.

So right now, everything’s great!
Let’s see if R3 can ping R2’s
loopback interface (2.2.2.2).
R3#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
.....

Success rate is 0 percent (0/5

Nope! When you see periods come
back from a ping, that’s not good.
That means that we do not have IP
connectivity to the remote address

we pinged.
Ping tells you that you don’t have
connectivity, but doesn’t really tell
you why. A command that’s very
helpful in diagnosing the “why” is
debug ip packet.
HUGE IMPORTANT STUDY TIP:
Debugs are also an outstanding
learning tool, one that many
CCENT and CCNA candidates
overlook. I urge you to use debugs
early and often in your lab or
simulator work, since this allows
you to see what goes on “behind the

command”. When you know what
things look like when they’re
working, it’s a lot easier to know
what’s wrong when you run debugs
when things aren’t working!
WARNING: Do NOT practice
debugs on a production network.
Some debugs, especially debug ip
packet, can overwhelm a router or
switch CPU and render the device
unable to route or switch.
Let’s run that debug on R3 and then
send a ping to 172.12.123.2, which
we already know we can ping
successfully. That will allow us to
see what the debug ip packet output

looks like when all is well.
R3#ping 172.12.123.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
seconds:
!!!!!

00:34:43: IP: s=172.12.123.3 (
len 100, sending

00:34:43: IP: s=172.12.123.2 (
(Serial0), len 100, rcvd 3

(The previous two lines will t
I’ve edited.)

Success rate is 100 percent (5

140/140/140 ms
R3#

The key words there are “sending”
and “rcvd” (short for received).
That’s what we want to see! Now
let’s see what we don’t want to see
by keeping that debug on and
pinging 2.2.2.2, an address we
know we do not have connectivity
to.
R3#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
seconds:

00:36:39: IP: s=3.3.3.3 (local
unroutable.

00:36:41: IP: s=3.3.3.3 (local
unroutable.

00:36:43: IP: s=3.3.3.3 (local
unroutable.

00:36:45: IP: s=3.3.3.3 (local
unroutable.

00:36:47: IP: s=3.3.3.3 (local
unroutable.

Success rate is 0 percent (0/5

The key word here is “unroutable”.
Here’s the reason for that message,

courtesy of show ip route:

R3#show ip route
Codes: C - connected, S - stat
Gateway of last resort is not
3.0.0.0/32 is subnetted,
C
3.3.3.3 is directly co
172.12.0.0/24 is subnette
C
172.12.123.0 is direct

There’s no entry for the 2.2.2.0
network in R3’s routing table, and
no “gateway of last resort” set, so
the packets destined for a host on
that network cannot be routed.
Literally, those packets aren’t
getting anywhere – they’re not even
leaving R3!

Before we proceed, we’ll turn the
debug off with undebug all, which
(naturally) turns off all debugs. If
you want to specify the debug to
turn off, use the no debug command
followed by the name of the debug
itself.

R3#undebug all
All possible debugging has bee

OR
R3#no debug ip packet
IP packet debugging is off

We have two choices to get a route
to 2.2.2.0 into that table:

Configure a static route.
Configure a dynamic routing
protocol throughout the
network.
Since we’re in the static routing
section of the course, let’s create a
static route! We use the ip route
command to create static routes,
and we actually have two choices
in the type of static route. We can
create…
A “regular” static route to a
given host or destination

network
A default static route, which
will be used when there is no
other match in the routing
table for a destination
network.
I would be very familiar with those
options for your exam, along with
the syntax of each, which we’ll see
throughout the rest of this section.
We’ll use IOS Help to illustrate the
choices with this command and
many others throughout the course.
Get plenty of practice with IOS

Help during your exam prep if at
all possible.
You can use IOS Help in two ways.
When you leave a space between
the question mark and the last word
in what you’ve typed, IOS Help
will display the available options
for the next word.

R3#debug ?
aaa
AAA
Authorization and Accounting
access-expression
Bool
adjacency
adja
all
Enab
arp
IP A
transactions

When you end a partial word with a
question mark, IOS Help displays
all acceptable entries that begin
with the letters you’ve entered.
R3#deb?
debug

Now back to the lab!
We’re going to configure the
destination IP prefix 2.2.2.0 here
for our static route (the loopback
network we want to ping).
R3(config)#ip route ?
A.B.C.D

Destination prefix

profile
vrf
instance

Enable IP routing t

Configure static ro

R3(config)#ip route 2.2.2.0

Now we specify the network mask,
255.255.255.0.

R3(config)#ip route 2.2.2.0 ?
A.B.C.D Destination prefix m
R3(config)#ip route 2.2.2.0 25

At this point in the ip route
command, you must specify one of
these two values:
The local router’s exit

interface (NOT an IP address
on the local router)
The IP address on the next
router we want to send the
packets to = the “next-hop
address”
I personally like to use the next-hop
IP address, but there’s nothing
wrong with using the local router’s
exit interface. Besides, you better
know them both for your CCENT
and CCNA exams! We’ll use the
next-hop IP address 172.12.123.1,
R1’s serial interface, since we

already have IP connectivity to that
address.

R3(config)#ip route 2.2.2.0 25
<1-255>
Distance metric for
name
Specify name of t
permanent permanent route
tag
Set tag for this
<cr>

When you see <cr> at the bottom of
IOS Help output, that means the
command is acceptable to enter as
it is. We’re going to save the
options here for future studies, and
go forward with this static route.
Let’s press the ENTER key to have
the route entered into the routing

table, use <ctrl-z> to go back to the
enable prompt, and then verify the
route entry with show ip route.
Always use a show command to
verify your latest configuration!

R3(config)#ip route 2.2.2.0 25
R3(config)#^Z
R3#show ip route
Codes: C - connected, S - stat
Gateway of last resort is not
2.0.0.0/24 is subnetted,
S
2.2.2.0 [1/0] via 172.
3.0.0.0/32 is subnetted,
C
3.3.3.3 is directly co
172.12.0.0/24 is subnette
C
172.12.123.0 is direct

And there’s our static route, as

indicated by the “S”! Nothing to it!
Also note the “1” in the brackets
after the network in that route. That
first number is the administrative
distance of the route. The AD is a
measure of the route source’s
believability, and the lower the AD,
the more reliable the source. It’s
used as a tiebreaker in case the
router hears about the route from
more than one source – two
different protocols, for example.
The second number is the metric for
the route, which in this case is zero.
Now we’ll send a ping to 2.2.2.2,
and let’s see what happens.

R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
U.U.U

Hmm. That’s one weird ping output.
Let’s run debug ip packet and send
the ping again and we’ll see what’s
going on. (I hope!)
R3#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
U

00:58:14: IP: s=172.12.123.3 (
100, sending

00:58:14: IP: s=172.12.123.1 (
(Serial0), len 56, rcvd 3

00:58:14: IP: s=172.12.123.3 (
100, sending. U

00:58:16: IP: s=172.12.123.3 (
100, sending

00:58:16: IP: s=172.12.123.1 (
(Serial0), len 56, rcvd 3

00:58:16: IP: s=172.12.123.3 (
100, sending. U

Success rate is 0 percent (0/5
R3#

00:58:18: IP: s=172.12.123.3 (
100, sending

00:58:18: IP: s=172.12.123.1 (
(Serial0), len 56, rcvd 3

Note the actual ping output of U.U.U
is still there, but it’s scrambled
amongst the debug ip packet output.
That’s why I ran the ping once
without the debug and then once
with.
Interestingly, the packets are being
sent - you can see the word
“sending” five times. The pings are
leaving R3, but aren’t getting to
2.2.2.2.

I showed you this to illustrate a
basic principle of pings and IP
connectivity that many network
admins forget. When you send
pings, it’s not enough for the local
router to have an entry in its routing
table for the remote network - the
downstream routers need an entry,
too!
Let’s walk through the ping process,
which is a short walk – there are
just two steps. The pings leave R3,
and where do they go? Let’s revisit
R3’s routing table for that answer:

R3#show ip route
Codes: C - connected, S - stat

2.0.0.0/24 is subnetted,
subnets S
2.2.2.0 [1/0]
172.12.123.1
3.0.0.0/24 is subnetted,
C
3.3.3.0 is directly co
172.12.0.0/24 is subnette
C
172.12.123.0 is direct

The next hop for those pings is R1’s
serial0 interface, 172.12.123.1.
Does R1 have a route to 2.2.2.2?
Let’s check R1’s routing table for
the answer.

R1#show ip route
Codes: C - connected, S - stat
Gateway of last resort is not

172.12.0.0/24 is subnette
C

172.12.123.0 is directl

R1 has no entry in its routing table
that will allow it to forward
packets to 2.2.2.2, and as a result

the packets are dropped at R1.

We need to get a route into R1’s
routing table to allow it to route
packets to 2.2.2.2. We’ll use this
opportunity to configure a default
static route on R1. A router only

uses a default route if there is no
other matching entry in the routing
table for a given destination.
The syntax for a default static route
looks a bit odd, so be ready to
identify it on the exam:
R1#conf t
Enter configuration commands,

R1(config)#ip route 0.0.0.0 0.

Both the destination network and
the mask are all zeroes in a default
static route. As with a “regular”
static route, we have the option of
configuring a next-hop IP address or

the local router’s exit interface. I’ve
configured a default static route
with the next-hop address of
172.12.123.2 (R2’s serial
interface), so R1 is basically saying
this:
“Any packets that need routing and
have no matching entry in my
routing table, send them to
172.12.123.2 and let THAT router
take care of it!”

Let’s verify the default static route
with show ip route on R1.

R1#show ip route
Codes: C - connected, S - stat
Gateway of last resort is 172.
172.12.0.0/24 is subnette

C
S*

172.12.123.0 is directl
0.0.0.0/0 [1/0] via 172.1

There’s an asterisk next to the “S”,
which indicates a default static
route. (Technically, it’s a candidate
default route, but since there’s only
one candidate…)
The gateway of last resort now lists
the next-hop address of the static
route.
Will this allow R3 to successfully
ping R2’s loopback interface?

R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos

!!!!!
Success rate is 100 percent (5
140/142/152 ms

Yes!
Default static routes serve two
major purposes, one of which
we’ve just seen in action -- we can
send data to networks that have no
specific entry in the routing table.
This also helps to keep routing
tables concise and complete, and
as you advance in your Cisco
studies, you’ll learn it’s important
to control the size of the routing
table while keeping it complete.
Static routes have their place, but

they’re not terribly scalable.
Scalability refers to a network
feature or protocol’s ability to
remain useful without a great deal
of manual intervention as the
network grows, and it’s a term
you’ll hear often in your Cisco
studies and your real-world job.
Static routes can help you cut
waaaaay back on unnecessary
overhead under certain
circumstances, such as the
following:

In this network, all roads lead back
to the hub. If any spoke wants to
communicate with any other spoke,
the next hop is ALWAYS the hub.
With this topology, the spokes don’t
need full routing tables containing
an entry for every network on every

other spoke - - they just need a
single route pointing to the hub. The
hub can take over the routing from
there.
This is a particularly helpful setup
under any of the following
circumstances:
Your spoke routers aren’t
exactly top-of-the-line.
The full routing tables on the
spokes are rather large.
Bandwidth over the spokehub circuits is at a premium.
Some of the spoke-hub links

are links that go up and down
on occasion (“flapping
links”), causing your routing
protocols to unnecessarily
recalculate routes.
Every routing protocol has
overhead, including some kind of
routing update or “hello” keepalive
packet. If you use a single default
route on these spokes instead of a
routing protocol, there is no such
overhead.

Distance Vector Routing IGPs
(For Comparison To Link-State
Protocols)
The main distance vector protocol
in use in today’s networks is the
Routing Information Protocol (RIP).
We used to have IGRP, but that’s
long gone from Cisco routers and
exams, so RIP is the last Distance
Vector Interior Gateway Protocol
we have.
You’re not responsible for
configuring RIP on your CCENT
exam, but you should know just a
little about it so you can fully
appreciate link state protocols (and

be fully prepared for the exam).
Let’s start with two distance vector
protocol behaviors you won’t find
in link-state protocols – split
horizon and route poisoning, both
designed to help prevent routing
loops.
A routing loop occurs when a
packet enters a “loop”, resulting in
the packet just bouncing around
between two or three routers in an
unending circle. Loops generally
occur due to router
misconfiguration or poor network
design.
I highly recommend you watch this

free video on my YouTube channel
so you can see what a routing loop
actually looks like on a live Cisco
router.
http://www.youtube.com/watch?
v=pKimoicJCFQ
(And if you’re wondering “Hey,
why don’t link state protocols have
loop prevention behaviors?” – stick
around, we’re getting to that in the
OSPF section!)

Split Horizon And Route
Poisoning
Split Horizon is a simple yet
powerful routing loop avoidance
feature. The rule of split horizon is
that a route cannot be advertised out
the same interface that same router
would use as an exit interface to
send packets to that network.
That sounds complicated, but it’s
not. For example, if R1 uses Serial0
as the exit interface for packets
destined for 100.1.1.0 /24, R1
cannot advertise that route via
Serial0.
Route Poisoning occurs when a

route becomes unavailable. You’d
think a distance vector routing
protocol would simply stop
advertising a route when it becomes
unavailable, but that’s not quite
what happens.
With route poisoning, the router
with the failed route continues to
advertise the route, but with a
metric indicating the route is
unreachable. With RIP, that means
advertising the route with a metric
of 16, which RIP considers an
unreachable route.
Upon receipt of the advertisement
containing the metric of

“unreachable”, the downstream
routers remove the network from
their routing tables, and will no
longer advertise that route.
This is a slow process at a time we
need speed. Distance vector
protocols do not converge quickly,
and that’s one reason you won’t see
much of them in today’s production
networks. (Convergence is the
process of our routers agreeing on a
change in the network.)
Here’s a look at the output of debug
ip rip when a route’s being
poisoned.

R3#deb ip rip
RIP: sending v2 update to 224.
172.12.123.0/24 -> 0.0.0.
1.1.1.1/32 -> 172.12.123.
2.2.2.2/32 -> 172.12.123.
3.3.3.3/32 -> 0.0.0.0, me

RIP uses the Bellman-Ford
algorithm, which results in RIP
using hop count as its sole metric.
RIP doesn’t consider bandwidth or
the speed of the paths, it just counts
hops. Not very scientific, and not
very accurate. RIP would consider
a 1-hop path over a 56k link
superior to that of a 2-hop link over
T1 lines.
Overall, RIP has some serious

issues…
Slow convergence.
Inaccurate metrics.
Two versions of RIP exist,
one of which doesn’t support
subnet masking and uses
broadcasts rather than
multicasts to send routing
updates.
RIP sends out a full routing
table every 30 seconds,
regardless of whether there’s
even been a change in the
network, which is a
WHOPPING waste of router

resources and bandwidth.
These are the main reasons you
won’t see RIP very often in
production networks, and this info
will help you understand OSPF and
EIGRP operations.
Speaking of OSPF… let’s head
there now, after a quick look at
wildcard masks!

The Wildcard Mask

You’ll find these masks in the
OSPF, EIGRP, and ACL sections.
It’s a good idea to review this short
section before studying any of those
areas.
ACLs use wildcard masks to
determine what part of a network
number should and should not be
examined for matches against the
ACL. Their use in EIGRP and
OSPF allows us to tie down which

interfaces should and should not be
enabled with the protocol in use.
Wildcard masks are required in
OSPF network statements. They’re
not required in EIGRP network
statements, but their use is highly
recommended.
Wildcard masks are written in
binary, and then converted to dotted
decimal for router configuration.
Zeroes indicate to the router that
this particular bit must match, and
ones are used as “I don’t care” bits
– the ACL does not care if there is a
match or not.
In this example, all packets that

have a source IP address on the
196.17.100.0 /24 network should
be allowed to enter the router’s
Ethernet0 interface. No other
packets should be allowed to do so.
We need to write an ACL that
allows packets in if the first 24 bits
match 196.17.100.0 exactly, and
does not allow any other packets
regardless of source IP address.
1st Octet – All 00000000
bits must match.
2nd Octet – All
00000000
bits must match.

3rd Octet – All 00000000
bits must match.
4th Octet – “I
11111111
don’t care”
00000000
Resulting
00000000
Wildcard Mask: 00000000
11111111

Use this binary math chart to
convert from binary to dotted
decimal:
128 64 32 16 8 4 2 1
1st

Octet: 0
2nd
0
Octet:
3rd
0
Octet:
4th
1
Octet:

0

0

0

0 0 0 0

0

0

0

0 0 0 0

0

0

0

0 0 0 0

1

1

1

1 1 1 1

Converted to dotted decimal, the
wildcard mask is 0.0.0.255. Watch
that on your exam. Don’t choose a
network mask of 255.0.0.0 for an
ACL when you mean to have a
wildcard mask of 0.0.0.255.

I grant you that this is an easy
wildcard mask to determine without
writing everything out. You’re going
to run into plenty of wildcard masks
that aren’t as obvious, so practice
this method until you’re totally
comfortable with this process.
We also use wildcard masks in
EIGRP and OSPF configurations.
Consider a router with the
following interfaces:
serial0: 172.12.12.12 /28 (or in
dotted decimal, 255.255.255.240)
serial1: 172.12.12.17 /28
The two interfaces are on different

subnets. Serial0 is on the
172.12.12.0 /28 subnet, where
Serial1 is on the 172.12.12.16 /28
subnet. If we wanted to run OSPF
on serial0 but not serial1, using a
wildcard mask makes this possible.
The wildcard mask will require the
first 28 bits to match 172.12.12.0;
the mask doesn’t care what the last
4 bits are.
1st Octet: All
00000000
bits must match.
2nd Octet: All
00000000
bits must match.

00000000
3rd Octet: All
bits must match.
4th Octet: First
00001111
four bits must
match.
00000000
Resulting
00000000
Wildcard Mask: 00000000
00001111

Converted to dotted decimal, the
wildcard mask is 0.0.0.15.
That’s all there is to it! As with
anything, practice makes perfect –
so practice, already!

OSPF coming right up!

OSPF In Particular,
Link-State Protocols In
General
Link-State Protocol Concepts
A major drawback of distance
vector protocols is that they not
only send routing updates at a
regularly scheduled time, but these
routing updates contain full routing
tables for that protocol. When a RIP
router sends a routing update
packet, that packet contains every

single RIP route that router has in
its routing table!
This takes up valuable bandwidth
and puts an unnecessary drain on
the receiving router’s CPU and
memory.
Sending full routing updates on a
regular basis is generally
unnecessary. You’ll see very few
networks that have a change in their
topology every 30 seconds, but
that’s how often a RIP-enabled
interface will send a full routing
update!
At the end of the Static Routing and
RIP section, a RIP debug showed us

that routes and metrics themselves
are in the RIP routing updates.
Link state protocols do not
exchange routes and metrics. Linkstate protocols exchange just that –
the state of their links, and the cost
associated with those links. (OSPF
refers to its metric as cost, a term
we’ll revisit later in this section.)
As these Link State Advertisements
(LSAs) arrive from OSPF
neighbors, the router performs a
series of computations on these
LSAs, giving the router a complete
picture of the network. This series
of computations is known as the

Shortest Path First (SPF) algorithm,
also referred to as the Dijkstra
algorithm.
You can see the actual database
with show ip ospf database. (This
is a VERY small OSPF database.)
R2#show ip ospf database

OSPF Router with ID (2.

Router Link St
Link ID
Link count

ADV Router

2.2.2.2
1

2.2.2.2

172.23.23.3
1

172.23.23.3

Net Link State
Link ID

ADV Router

172.23.23.3

172.23.23.3

Technically, what you see here is a
routing table, but I wouldn’t want to
be the one to figure out the routes.
Luckily, the SPF algorithm will do
the dirty work for us and leave us
with a routing table that’s much
easier on the eyes.
This exchange of LSAs between
neighbors helps bring about one

major advantage of link state
protocols - all routers in the
network will have a similar view of
the overall network.
In comparison to RIP updates
(every 30 seconds!), OSPF LSAs
aren’t sent out all that often –
they’re flooded when there’s an
actual change in the network, and
each LSA is refreshed every 30
minutes.
Before any LSA exchange can
begin, a neighbor relationship must
be formed. Neighbors must be
discovered and form an adjacency,
after which LSAs will be

exchanged.

The Designated Router And
Backup Designated Router

If all routers in an OSPF network
had to form adjacencies with every
other router, and continued to
exchange LSAs with every other
router, a large amount of bandwidth
would be used any time a router
flooded a network topology change.
In short, we’d end up with an
inefficient design and wasted
network resources.
Most OSPF segments will elect a
designated router and a backup

designated router to handle
adjacency changes.
The designated router is the router
that will receive the LSAs from the
other routers in the area, and then
flood the LSA indicating the
network change to all non-DR and
non-BDR routers. Routers that are
neither the DR nor the BDR for a
given network segment are
indicated in show ip ospf neighbor
as DROTHERS, as you’ll see
shortly.
Instead of having every router flood
the network with LSAs after a
network change, the change

notification is sent straight to the
DR, and the DR then floods the
network with the change.

If the DR fails, the backup
designated router (BDR) takes its

place. The BDR is promoted to DR
and another election is held, this
one to elect a new BDR. That’s why
the BDR listens for updates –
because it may have to quickly step
in and become the DR.
Hello Packets: The “Heartbeat”
Of OSPF
Hello packets perform two main
tasks in OSPF, both of them vital:
OSPF Hellos allow
neighbors to dynamically

discover each other
OSPF Hellos allow the
neighbors to remind each
other that they are still there,
which means they’re still
neighbors!
OSPF-enabled interfaces send hello
packets at regularly scheduled
intervals. The default intervals are
10 seconds on a broadcast segment
such as Ethernet and 30 seconds for
non-broadcast links such as Serial
links.
OSPF Hellos have a destination IP

address of 224.0.0.5, an address
from the reserved Class D range of
multicast addresses (224.0.0.0 239.255.255.255)

OSPF neighbor relationships are
just like neighbor relationships
between people in more than one
way. As human beings, we know
that just because someone moves in
next door and says “Hello!”, it

doesn’t mean that we’re going to be
true neighbors with that person.
Maybe they play their music too
loud, have noisy parties, or don’t
mow their lawn.
OSPF routers don’t care how loud
the potential neighbor is, but
potential OSPF neighbors must
agree on some important values
before they actually become
neighbors. Mismatches regarding
the following values between
potential neighbors are the #1
reason OSPF adjacencies do not
form as expected.
Troubleshooting OSPF adjacencies

is usually simple - you just have to
know where to look.
We’ll assume an Ethernet link
between the routers in question, but
the potential OSPF neighbors must
agree on the following values
regardless of the link type.
Ordinarily there will be a switch
between these two routers, but for
clarity’s sake I have left that device
out of the diagrams.

Neighbor Value #1 & 2: Subnet
Number And Mask

Simple enough –the routers must be
on the same subnet and using the
same mask in order to become
neighbors.
Let’s build our first OSPF network
with the following routers both in
Area 0. (More on Area 0 shortly.)
They’re both on the same Ethernet
segment.

Let’s get the config started…..
There’s no problem with these
routers pinging each other:
R2#ping 172.12.23.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
seconds:
!!!!!

Success rate is 100 percent (5
4/4/4 ms

R3#ping 172.12.23.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
seconds:
!!!!!

Success rate is 100 percent (5

But will they become OSPF
neighbors? We’ll examine the
network command in more detail
throughout this section, but here’s

what the network statements will
look like. OSPF network statements
use wildcard masks, not subnet or
network masks.

R2(config)#router ospf 1
R2(config-router)#network 172.

R3(config)#router ospf 1
R3(config-router)#network 172.

A few minutes after entering that
configuration, I ran show ip ospf
neighbor on R2 and saw… nothing.
When you run a show command and
you’re shown nothing, there’s
nothing to show you! That means

there’s no OSPF adjacency between
R2 and R3. To find out why, run
debug ip ospf adj.
R2#debug ip ospf adj

OSPF adjacency events debuggin
R2#

00:13:54: OSPF: Rcv hello from
172.12.23.3

00:13:54: OSPF: Mismatched hel

00:13:54: Dead R 40 C 40, Hell
255.255.255.128 C 255.255.255.
0

I love this debug! It shows us
immediately that the problem is
“mismatched hello parameters from
172.12.23.3”, and then lists the
parameters in question. “Dead” and
“Hello” match up, but the mask is
different. That’s the problem right
there. Since we’re on R2, we’ll
change the E0 mask here to
255.255.255.128, change the OSPF
network command, and see what
happens.

R2(config)#int e0
R2(config-if)#ip address 172.1
R2(config-if)#router ospf 1
R2(config-router)#no network 1
R2(config-router)#network 172.

Let’s run show ip ospf neighbor to
see if we have an adjacency:
R2#show ip ospf neighbor
Neighbor ID
Interface
172.12.23.3
Ethernet0

Pri
1

State
FULL/DR

And we do!
Let’s now switch focus to the other
two values you saw in that debug
command - the Hello and Dead
timers.
Neighbor Value #3 & 4: The Hello
And Dead Timers

These timers have vastly different
roles, but they are bound together in
one very important way.
The Hello timer defines how often
OSPF Hello packets will be
multicast to 224.0.0.5, while the
Dead timer is how long an OSPF
router will wait to hear a Hello
from an existing neighbor.
When the Dead timer expires, the
adjacency is dropped! Note in the
previous example that show ip ospf
neighbor shows the dead time for

each neighbor.
The default dead time for OSPF is
four times the hello time, which
makes it 40 seconds for Ethernet
links and 120 seconds for nonbroadcast links. The OSPF dead
time adjusts dynamically if the hello
time is changed. If you change the
hello time to 15 seconds on an
Ethernet interface, the dead time
will then be 60 seconds.
Let’s see that in action. The
command show ip ospf interface
will show us a wealth of
information, including the Hello and

Dead timer values for a given
interface. Given the defaults
mentioned earlier, what timers
should we expect to see on the
Ethernet interface?

R2#show ip ospf int
Ethernet0 is up, line protocol
Internet Address 172.12.23.2
Process ID 1, Router ID 103.
Transmit Delay is 1 sec, Sta
Designated Router (ID) 172.1
Backup Designated router (ID
Timer intervals configured,
Hello due in 00:00:04
Neighbor Count is 1, Adjacen
Adjacent with neighbor 172
Suppress hello for 0 neighbo

OSPF broadcast interfaces have
defaults of 10 seconds for the Hello
timer and 40 for the Dead timer
(four times the Hello timer). What
happens if we change the Hello
timer to 15 seconds with the
interface-level command ip ospf
hello?
R2(config)#int e0

R2(config-if)#ip ospf hello 15

R2#show ip ospf int

Ethernet0 is up, line protocol

Internet Address 172.12.23.2

Process ID 1, Router ID 103.
Cost: 10

Transmit Delay is 1 sec, Sta

Designated Router (ID) 103.1
172.12.23.2
No backup designated router
Timer intervals configured,
Retransmit 5
Hello due in 00:00:12
Neighbor Count is 0, Adjacent

Suppress hello for 0 neighbo

Two things have happened, one that
we knew about and another that we
should have suspected:
Both the Hello and Dead
timers changed (the Dead
timer changed to 4 times the
new Hello value)
We apparently lost the
adjacency to R3, since the
adjacent neighbor count fell
to zero
show ip ospf neighbor verifies that
we have no OSPF neighbors on R2.

R2#show ip ospf nei
R2#

I’m sure you already know what
caused this, but let’s run debug ip
ospf adj and find out for sure!
R2#debug ip ospf adj

OSPF adjacency events debuggin

00:21:34: OSPF: Rcv hello from
172.12.23.3

00:21:34: OSPF: Mismatched hel

00:21:34: Dead R 40 C 60, Hell

255.255.255.128 C 255.255.255.
128

We again have mismatched hello
parameters, but this time it’s the
Hello and Dead timer mismatch that
brought the adjacency down. We’ll
change the Hello timer on R2 back
to its default of 10 seconds by
negating the previous command, and
see if the adjacency comes back.
R2(config)#int e0

R2(config-if)#ip ospf hello 10

R2#show ip ospf neigh

Neighbor ID
Interface

Pri

172.12.23.3
Ethernet0

1

State

FULL/DR

Since the Hello and Dead timers
again match, the OSPF adjacency
comes back up. There’s no need to
reset an interface or the router.
I would know those Hello and Dead
timers like the back of my hand for
both the exam room and working
with production networks. And

when you’re done debugging, use
the undebug all command to turn
them all off!
R2#undebug all

All possible debugging has bee

A Value That DOESN’t Have To
Match Between Potential
Neighbors
The very first command you’ll ever
and always enter in an OSPF config
is the OSPF process number. A
router can run multiple OSPF

processes, and the routes learned by
one OSPF process are not
automatically known by the other
OSPF processes running on the
router.

Potential OSPF neighbors do not
have to agree on the OSPF process
number. The OSPF process number
is “locally significant only”, which
means it’s not advertised to other

routers and only has importance to
the local router.
I’ve removed the previous OSPF
config from R2 and R3 and put in
the network numbers you see in the
previous illustration.
R2(config)#router ospf 1

R2(config-router)#network 172.

R3(config)#router ospf 7

R3(config-router)#network 172.

00:05:15: %OSPF-5-ADJCHG: Proc
from LOADING to

FULL, Loading Done

R3#show ip ospf neighbor
Neighbor ID
Interface
103.1.1.1
Ethernet0

Pri

1

State

FULL/DR

The reason I’m really driving this
home with you is that another
popular routing protocol, EIGRP,
has a number in the exact same spot
in the config….
Router eigrp 1

…but that number’s not a process
number. It’s an Autonomous System
number, and it does have to match
between potential EIGRP
neighbors.
That’s all I’m going to say about
EIGRP right now, I promise! Just
remember that OSPF neighbors
don’t have to agree on the number
in the router ospf command, but
EIGRP neighbors do have to agree
on the number in the router eigrp
command.
OSPF Areas

With both OSPF and EIGRP, we’re
going to put our routers into logical
groups. In OSPF, those logical
groups are areas, and there are
some basic rules and terms
regarding areas that we must be
aware of:
OSPF’s backbone area is
Area 0, and every other area
we create must contain a
router that has a physical or
logical interface in Area 0.
Routers with interfaces in
more than one area are Area

Border Routers
OSPF areas allow us to build a
hierarchy into our network, where
we have a “backbone area” (Area
0), and expand the network from
there. This concept also allows us
to create stub areas, where the
routers in the stub areas will not
have full routing tables – they’ll
have a combination of individual
routes and default routes. We’ll get
a taste of those stub areas later in
this section, and we’ll really get
into them in your CCNA and CCNP
studies.

Configuring OSPF Hub-And-Spoke
Networks
(If You Dare!)
An OSPF hub-and-spoke network
configuration isn’t included in your
CCENT studies, but watching one
will definitely help to drive home
many of the concepts you’re reading
about in this section.
For these reasons, I haven’t put a
hub-and-spoke config in this course,
but I do have one on Udemy that you
should strongly consider watching.
And it’s free! Again, it’s not
required watching for the CCENT,

but I know it’ll help you absorb the
info in this section. Hop on over
and watch it – here’s the URL!
https://www.udemy.com/ccna-bootcamp/
Right now, let’s head back to our
Ethernet segment adjacency and
take a closer look at each value
from show ip ospf neighbor.
R3#show ip ospf neighbor
Neighbor ID
Interface
103.1.1.1

Pri

1

State

FULL/DR

Ethernet0

Neighbor ID: By default, a router’s
OSPF ID is the highest IP address
configured on a LOOPBACK
interface. This can also be manually
configured with the command
router-id in OSPF configuration
mode, and is usually set with that
command instead of leaving the
RID selection up to the router.
Pri: Short for “Priority”, this is the
OSPF priority of the interface on
the remote end of the adjacency.
The default is 1. This value is used
in the DR/BDR election – highest

priority of all interfaces in the
election wins.
State: FULL refers to the state of
the adjacency. The next value – DR,
BDR, or DROTHER – indicates
where the remote router ranks in the
scheme of things for this particular
network segment. DROTHER
means that particular router is
neither the DR nor the BDR.
Dead Time: A decrementing timer
that resets when a HELLO packet is
received from the neighbor.
Address: The IP address of the
interface on the neighbor through
which this adjacency is formed.

May or may not be the same value
seen under Neighbor ID.
Interface: The adjacency was
created via this local interface.
Speaking of that OSPF router ID….
Configuring the OSPF Router ID
By default, the OSPF Router ID
(RID) will be the numerically
highest IP address of all loopback
interfaces configured on the router,
even if that interface is not OSPFenabled.

Why use a loopback address for the
OSPF RID instead of the physical
interfaces?
A physical interface can become
unavailable in a number of ways the actual hardware can go bad, the
cable attached to the interface can
come loose, etc. - but the only way
for a loopback interface to be
unavailable is for it to be manually
deleted or for the entire router to go
down.
In turn, a loopback interface’s
higher level of stability and
availability results in fewer SPF

recalculations, which results in a
more stable network overall.
Oddly enough, an interface does not
have to be OSPF-enabled to have
its IP address used as the OSPF
RID – it just has to be “up” if it’s a
loopback, and physically “up” if
it’s a physical interface.
It’s rare to have a router running
OSPF that doesn’t have at least one
loopback interface, but if there is no
loopback, the highest IP address on
the router’s physical interfaces will
be the RID. Again, the interface
whose IP address is used as the
RID does not have to be OSPF-

enabled.
You can hardcode the RID with the
router-id command.
R2(config)#router ospf 1
R2(config-router)#router-id ?

A.B.C.D OSPF router-id in IP

R2(config-router)#router-id 22
<cr>

R2(config-router)#router-id 22

Reload or use “clear ip ospf p
effect

The good news: No options for this
command!
The bad news: We have to take our
adjacencies down to make this
command take effect.
Here’s a rarity, at least with Cisco.
For the new RID to take effect, you
must either reload the router or
clear the OSPF processes. That’s a
fancy way of saying “All existing
OSPF adjacencies will be torn
down.” The router will warn you of
this when you run that command.
R1#clear ip ospf process

Reset ALL OSPF processes? [no]

When the router’s prompt says
“no”, you should think twice before
saying yes! Once you reload
successfully, your adjacencies
should come right back as well – as
long as you didn’t change anything
else!
Here’s a video from my YouTube
channel that demos the OSPF RID!
http://www.youtube.com/watch?
v=Wk6KnMY35cA

Default-Information Originate
(Always?)

One of the benefits of running OSPF
is that all of our routers have a
similar view of the network. There
are times, though, that you may not
want all of your routers to have a
full routing table.
This involves the use of stub and
total stub areas, and while the
configuration of those areas is
beyond the scope of the CCENT
exam, I do want to show you an
example of when we might
configure such an area. This also

helps to illustrate a command that
you just might see on your exam!

There’s no reason for the three
routers completely in Area 100 to

have a full OSPF routing table. For
those routers, a default route will
do, since there is only one possible
next-hop IP address for any data
sent by those three routers.
If that central router has a default
route that it can advertise to the stub
routers, the default-information
originate command configured on
the central router will get the job
done.
That’s great, but what if the central
router doesn’t have a default route
to advertise?

Let’s use IOS Help to look at our
options for this command - there’s a
very important one here.

R2(config-router)#default-info
always
metric

Always advertis
OSPF default me

metric-type
route-map
<cr>

OSPF metric typ
Route-map refer

The always option allows the router
to advertise a default route without
actually having one in its routing
table. Without that option, the router
must have a default route in its table
in order to advertise one.
You’ll learn much more about the
different types of stub areas and
their restrictions and requirements
in your CCNA and CCNP studies.
For now, know the difference
between using default-information

originate with and without the
always option.
A Bonus Look At OSPF Routes
Cisco has basically cut OSPF in
half for your CCENT and CCNA
studies. You get plenty of important
concepts here in the ICND1 portion
of your studies, but you really don’t
see any live labs or many route
types until ICND2.
For those of you stopping after you
get your CCENT, I’ve posted some
bonus route info here. Those of you
going after your full CCNA will see

all of this and much more in my
ICND2 Study Guide.
Here’s our network…
.. and here are the OSPF routes on
R1.

R1# show ip route ospf
2.0.0.0/32 is subnetted, 1
O IA 2.2.2.2 [110/75] via 172.
172.12.0.0/16 is variably
O
172.23.23.0 [110/74] via

There are two types of OSPF routes
in this table, intra-area and interarea.
Intra-area routes are marked simply

with an “O”, and that’s a route in
one of the same areas the local
router is part of.
Inter-area routes are marked with
“O IA”, and that indicates a route to
an area the local router is not part
of. In this case, the route to R2’s
loopback (in OSPF Area 2) is
marked “ O IA” on R1, which is not
connected to Area 2.
There are other OSPF area types,
but we’ll save those for future
studies. Let’s tackle a vital Cisco
router and switch feature that also
uses wildcard masks, and a
protocol that makes it possible for

our routers and switches to keep the
right time!

Access Lists and the
Network Time Protocol
(“Your Network Better Know
What Time It Is”)
Introduction To Access Control
Lists
The basic purpose of Access
Control Lists (ACLs) is to allow a
router to permit or deny packets
based on a variety of criteria. The
ACL is configured in global mode,
but for filtering packets on a
permit/deny basis, it’s applied at

the interface level. An ACL does
not take effect until it is expressly
applied to an interface with the ip
access-group command. Packets
can be filtered as they enter or exit
an interface.
Throughout your Cisco studies,
you’re going to find more and more
uses for ACLs. You’re going to find
quite a few right here! We’ll block
traffic from entering an interface,
exiting an interface, prevent Telnet
access, allow Telnet access…. the
list of uses for ACLs goes on and
on. This is one skill you must
master in order to work with

today’s Cisco devices, and I
guarantee ACL usage will come up
more than once on your CCENT and
CCNA exams!
We’ll start our ACL discussion with
the most common usage - to deny or
allow traffic from entering or
exiting an interface. There are some
basic rules you must keep in mind
in order to master ACLs, and I’ll
make special note of those as we go
through some examples. I may get
repetitive on some of this –
actually, I will repeat several rules
several times -- but you’ll be glad I
did when these rules become

second nature and you earn your
CCENT and CCNA!

ACL Logic And The Implicit Deny
When a packet enters or exits an
interface with an ACL applied, the
packet is compared against the
criteria of the ACL. If the packet
matches the first line of the ACL,
the appropriate “permit” or “deny”
action is taken. If there is no match,
the second line’s criteria is
examined. The process repeats: If
there is a match, the appropriate
action is taken; if there is no match,
the next line of the ACL is
compared to the packet’s
addressing.

This process continues until a match
is found, at which time the ACL
stops running. If no match is found,
an implicit deny is applied to the
packet. If a packet is not expressly
permitted by a line in the ACL, it
will be subject to the implicit deny.
Take special note of the implicit
deny feature. Forgetting about this
deny is the #1 reason for ACLs not
giving you the desired results.
The behavior described above
concerning the line-by-line ACL
matching process, along with the
implicit deny, are default behaviors
of all ACL types discussed in this

section.

Comparing Standard And
Extended ACLs
A standard ACL is concerned with
only one factor -- the source IP
address of the packet. The
destination IP address is not
considered.
Extended ACLs consider both the
source and destination IP address of
the packet, and can consider the
port number as well. You’ll see
those options later in this section.
Standard and extended ACLs do not
use the same numeric ranges, and
you must watch out for these on the
exam and in the real world.

Standard ACLs use the ranges 1-99
and 1300-1999, where extended
lists use 100-199 and 2000 to 2699.
On that subject, let’s use IOS Help
to view a few additional ACL
numeric ranges.

R1(config)#access-list ?
<1-99>
IP standard
<100-199>
IP extended
<1100-1199>
Extended 48<1300-1999>
IP standard acc
<200-299>
Protocol typ
<2000-2699>
IP extended ac
<700-799>

48-bit MAC a

dynamic-extended
rate-limit

Extend the d
Simple rate-

The obvious questions: “Why are
the standard and extended list
ranges broken up? Why aren’t they
just one big range?”
When ACLs were first introduced,
it was thought we’d never need
more than 100 ACLs of any type on
a single router.
We also used to think we’d never
need a home data storage device
bigger than a floppy disk, and that
certainly changed! As the number of
different uses for ACLs expanded,
the range of available ACLs on
many routers began to shrink. That’s

when Cisco came up with the
expanded ranges, and I’m sure you
noticed the expanded ranges are
much larger in scope than the
originals!
You don’t really need to know
which ranges were original and
which are expanded, but I’d know
both of those ranges cold before
taking the exam.
ACLs use wildcard masks, not
network or subnet masks. Before
we hit ACLs hard, let’s review
wildcard mask logic.

The Wildcard Mask
ACLs use wildcard masks to
determine what part of a network
number should and should not be
examined for matches against the
ACL.
Wildcard masks are written in
binary, and then converted to dotted
decimal for router configuration.
Zeroes indicate to the router that a
particular bit must match, and ones
are used as “I don’t care” bits.
This becomes much clearer with an
example.
Here, all packets that have a source

IP address on the 196.17.100.0 /24
network should be allowed to enter
the router’s Ethernet0 interface. No
other packets should be allowed to
do so.
We need to write an ACL that
allows packets if the first 24 bits
match 196.17.100.0 exactly, and
does not allow any other packets
regardless of source IP address.
1st Octet – All 00000000
bits must match.
2nd Octet – All
00000000
bits must match.

3rd Octet – All 00000000
bits must match.
4th Octet – “I
11111111
don’t care”
00000000
Resulting
00000000
Wildcard Mask: 00000000
11111111

Use this binary math chart to
convert from binary to dotted
decimal:
128 64 32 16 8 4 2 1
1st

Octet: 0
2nd
0
Octet:
3rd
0
Octet:
4th
1
Octet:

0

0

0

0 0 0 0

0

0

0

0 0 0 0

0

0

0

0 0 0 0

1

1

1

1 1 1 1

Converted to dotted decimal, the
wildcard mask is 0.0.0.255. Watch
that on your exam. Don’t choose a
network mask of 255.0.0.0 for an
ACL when you mean to have a
wildcard mask of 0.0.0.255.

I grant you this is an easy wildcard
mask to determine without writing
anything out. You’re going to run
into plenty of wildcard masks that
aren’t as obvious, so practice this
method until you’re totally
comfortable with this process.
We also use wildcard masks in
EIGRP and OSPF configurations.
Consider a router with the
following interfaces:
serial0: 172.12.12.12 /28 (or in
dotted decimal,
255.255.255.240)
serial1: 172.12.12.17 /28

The two interfaces are on different
subnetworks. Serial0 is on the
172.12.12.0 /28 subnet, where
Serial1 is on the 172.12.12.16 /28
subnet. If we wanted to run OSPF
on serial0 but not serial1, using a
wildcard mask makes it possible.
The wildcard mask will require the
first 28 bits to match 172.12.12.0.
The mask doesn’t care what the last
4 bits are.
1st Octet: All
00000000
bits must match.
2ndOctet: All
00000000
bits must match.

3rdOctet: All
00000000
bits must match.
4thOctet: First
00001111
four bits must
match.
00000000
Resulting
00000000
Wildcard Mask: 00000000
00001111

Converted to dotted decimal, the
wildcard mask is 0.0.0.15.
Now on to standard ACLs!

Configuring Standard Access
Lists
Let’s review our ACL theory so far:
Standard ACLs consider only
the source IP address for
matches.
The ACL lines are run from
top to bottom. If there is no
match on the first line, the
second is run. No match on
the second, then the third line
is run, and so on until there is
a match or the end of the ACL
is reached. This top-tobottom process places

special importance on the
order of the lines. This theory
is true of all ACLs.
There is an implicit deny at
the end of every ACL. If
packets are not expressly
permitted, they are implicitly
denied.
If Router 3’s Ethernet interface
should only accept packets with a
source network of 172.12.12.0, the
ACL will be configured like this:

R3(config)#access-list 5 permi

That’s all we need to write out. The

implicit deny will deny all packets
not matching the first line.
The ACL is then applied to the
Ethernet0 interface with the ip
access-group command. I’ll use
IOS Help to show you one more
important option.
R3(config)#int e0
R3(config-if)#ip access-group
in inbound packets
out outbound packets
R3(config-if)#ip access-group

You must finish the ip access-group
command by indicating the
direction of packets to which the

ACL should be applied.
Overall, using an ACL to deny or
permit traffic at the interface level
is a two-step process:
Write the ACL with the
access-list command.
Apply the ACL with the ip
access-group command.
Using the ACL we just wrote,
traffic sourced from the 172.12.12.0
/24 network is accepted by the first
and only line of the ACL. All other
traffic is stopped by the implicit

deny.
A great rule of thumb when
determining the effect of an
ACL:
“If traffic isn’t explicitly
permitted, it’s implicitly
denied.”

Adding Remarks
Access lists can become quite large
and intricate. If one admin writes an
ACL and another admin comes in
six months later to troubleshoot an
issue, that second admin may have
no idea what the ACL was trying to
accomplish. When you see a
convoluted 70-line ACL that just
doesn’t make sense to you, you’ll
wish there was some kind of basic
explanation!
It’s professional courtesy to add a
remark line or two to describe what
an ACL was written for. To do so,
use the remark ACL command:

R3(config)#access-list 5 ?
deny
Specify packets to r
permit Specify packets to f
remark Access list entry comm
R3(config)#access-list 5 remar
LINE Comment up to 100 chara
<cr>
R3(config)#access-list 5 remar

Using “Host” and “Any” for
Wildcard Masks
There’s no problem with using a
wildcard mask of all ones or all
zeroes.
A wildcard mask of 0.0.0.0 means
the address specified in the ACL
line must be matched exactly. A
wildcard mask of 255.255.255.255
means all addresses will match the
line.
You have the option of using the
word host to represent a wildcard
mask of 0.0.0.0. Consider a
configuration where only packets
from IP source 10.1.1.1 should be

allowed and all other packets
denied. The following ACLs both
do that.

R3#conf t
R3(config)#access-list 6 permi

R3(config)#conf t
R3(config)#access-list 7 permi

The keyword any can be used to
represent a wildcard mask of
255.255.255.255. Both of the
following lines permit all traffic.

R3(config)#access-list 15 perm
R3(config)#access-list 15 perm

There’s no “right vs. wrong”
decision to make when you’re
configuring ACLs in the real world.
For your exam, I’d be comfortable
with the proper use of host and any.

The Order Of The ACL Lines Is
Vital
There’s definitely a “right vs.
wrong” decision to make when it
comes to the order of the ACL lines.
Getting just two lines in the wrong
order can wreck everything you’re
trying to do with the ACL. Here’s
an example of a short ACL where
the intent is to deny traffic from
172.18.18.0 /24, but allow traffic
sourced from any other subnet.

Which of the following ACLs
should we use?

R3(config)#access-list 15 deny
R3(config)#access-list 15 perm

R3(config)#access-list 15 perm
R3(config)#access-list 15 deny

R3(config)#access-list 15 deny
R3(config)#access-list 15 perm

R3(config)#access-list 15 perm
R3(config)#access-list 15 deny

We can eliminate the bottom two
choices, because they have
wildcard masks of 255.0.0.0. That
would match only on the 2nd, 3rd,
and 4th octets, which isn’t what we
need. We’re matching on the 1st,
2nd, and 3rd octets of 172.18.18.0,
so the proper wildcard mask is

0.0.0.255.
Here are the two remaining
possibilities:

R3(config)#access-list 15 deny
R3(config)#access-list 15 perm

R3(config)#access-list 15 perm
R3(config)#access-list 15 deny

The ACL is matched against packets
one line at a time, top to bottom.
The top choice will deny all
packets sourced from 172.18.18.0
first. Traffic that does not match that

line drops to the second line, which
permits all traffic. That’s what
we’re trying to do!
What about the second choice? The
very first line is permit any, so it’s
impossible for any traffic not to
match that line, including the traffic
we’re trying to block. The second
line will never be run, since the
first line matches all possible
traffic.
The permit any statement does
negate the implicit deny, but watch
where you put it in the ACL. If the
permit any statement is at the top of

any ACL, it doesn’t matter how
many deny statements follow it.
They’ll never be read.

Extended Access Control Lists
Extended ACLs allow both the IP
source and destination address to
be matched. Actually, they require
it. Even if you don’t want to use
either of those two criteria for
matching, you still have to put any
for the one you don’t want to use.
The source port, destination port,
and protocol type can also be
matched. These are truly optional
options - you don’t have to specify
a value for any of these options if
you’re not using them to match
traffic.
In the next example, packets

sourced from network 172.50.50.0
/24 should not be permitted if they
are destined for network
172.50.100.0 /24. All other packets
should be allowed.

Let’s use IOS Help to take a look at
the options in the access-list
command.

R3(config)#access-list 100 ?
deny
Specify packets to
dynamic Specify a DYNAMIC l
permit
Specify packets to
remark
Access list entry c

We can match by protocol name or
by number. We’ll keep it simple
here and select IP. If we planned to
use port numbers for matching,
we’d need to specify TCP or UDP.

R3(config)#access-list 100 den
<0-255> An IP protocol number
ahp
Authentication
eigrp
Cisco’s EIGRP
esp
Encapsulation
gre
Cisco’s GRE tu

icmp
igmp
igrp
ip
ipinip
nos
ospf
pcp
pim
tcp
udp

Internet Contr
Internet Gatew
Cisco’s IGRP r
Any Internet P
IP in IP tunne
KA9Q NOS compa
OSPF routing p
Payload Compre
Protocol Indep
Transmission Con
User Datagram

We’re going to specify the
172.50.50.0 /24 network as the
source.

R3(config)#access-list 100 den
A.B.C.D Source address
any
Any source host

host

A single source hos

R3(config)#access-list 100 den
A.B.C.D Source wildcard bit

R3(config)#access-list 100 den

Now we’ll define the destination
address.

R3(config)#access-list 100 deny ip 17
A.B.C.D Destination address
any
Any destination host
host
A single destination host

R3(config)#access-list 100 deny ip 17
A.B.C.D Destination wildcard bits
R3(config)#$ 100 deny ip 172.50.50.0

Notice the dollar sign next to the
pound sign prompt in that last line?
That’s what you see when your
command runs too long to be shown
in its entirety on the screen –
nothing more, nothing less. You can
still hit ENTER to enter the
command, which is just what I did.
The next and final line of the ACL
will negate the implicit deny. Since
this is an extended ACL, we have to
enter any twice – the first time for
the source and the second time for
the destination. This line allows all
traffic.

R3(config)#access-list 100 per

A.B.C.D
any
host

Source address
Any source host
A single source hos

R3(config)#access-list 100 per
A.B.C.D Destination address
any
Any destination host
host
A single destination

R3(config)#access-list 100 per

To verify your ACLs and the order
of the lines, run show access-list.

R3#show access-list 100
Extended IP access list 100
deny ip 172.50.50.0 0.0.0.
permit ip any any

Another rule of extended ACLs:
Both the source and destination
must match the line for the action to
be carried out. In this case, a packet
sourced from 172.50.50.0 /24 is
only denied IF the destination is on
the 172.50.100.0 /24 subnet. If
either the source or destination IP
address does not match the line,
there is no match.

Finally, the ACL is applied to the
interface with the ip access-group
command…..

R3(config)#int e0
R3(config-if)#ip access-group
in
inbound packets
out outbound packets
R3(config-if)#ip access-group

… making sure you indicate the
direction of packets to be filtered,
that is!
Another important ACL rule: A
single interface can have two ACLs
applied to it for each protocol - one
for outbound traffic and the other
for inbound traffic.
To illustrate what happens when
you configure two ACLs in the

same direction and for the same
protocol, I’ve created another
extended ACL that matches any TCP
traffic, regardless of source or
destination IP address, as long as
the destination port is port 80.

R1(config)#access-list 160 den
R1(config)#access-list 160 per

I’ll use the show ip interface
command to verify ACL 150 is
currently configured on Ethernet0,
both inbound and outbound.

R1#show ip interface eth0
Ethernet0 is up, line protocol
Internet address is 172.23.2

Broadcast address is 255.255
Address determined by setup
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwardin
disabled
Outgoing access list is 150
Inbound access list is 150
< output truncated for clarity

Just for shiggles, I’ll add ACL 160
to filter inbound traffic and see
what happens when we have two
ACLs applied to the same interface
and in the same direction filtering
the same protocol.
R1(config)#int e0
R1(config-if)#ip access-group

No warning from the router, but
what does show ip interface show?

R1#show ip interface ethernet0
Ethernet0 is up, line protocol
Internet address is 172.23.2
Broadcast address is
255.255.255.255
Address
determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwardin
Outgoing access list is 150
Inbound access list is 160

The latest ACL to be configured and
applied for inbound traffic, ACL
160, is the effective ACL for that
interface.

Now we know we’re limited to two
ACLs per protocol on an interface one inbound and one outbound - and
what happens when we break that
rule!
It’s very rare you’d want to apply
the same ACL to inbound and
outbound traffic, but you can.
R1(config)#int e0
R1(config-if)#ip access-group
R1(config-if)#ip access-group

Named Access Lists
Named ACLs are just that. Rather
than using a number to identify
them, names are used.
Consider a router with 75 ACLs. If
the ACLs are given intuitive names,
it can be much easier to see what
the author of the list was trying to
do (especially if they don’t leave
remarks with their numbered
ACLs).
The syntax of a named ACL is
slightly different than the numbered
type, but the operation is the same,

as is the use of host and any.
A router with a Serial interface that
should allow no traffic from
network 175.56.56.0 /24 to leave
that interface regardless of
destination, but should allow all
other traffic, would be configured
as follows. For named ACLs, the
command is ip access-list, not
access-list.

R3#conf t
R3#ip access-list extended NO_

R3(config-ext-nacl)#deny ip 17
R3(config-ext-nacl)#permit ip

A few details to note from that
configuration:
Use the ip access-list
command to create named
ACLs. (It’s so nice, I told ya
twice!)
The named ACL has to be
defined as standard or
extended.
I personally like to put underscores
in the named ACL’s name to make it
easier to read, but that’s certainly
optional.

All ACL rules we’ve discussed to
this point apply to named ACLs.
Named ACLs are applied to an
interface in the same fashion as
numbered ACLs, with the ip
access-group command. As always,
the direction of packets affected by
the ACL must be defined.
R3#conf t
R3(config)#interface serial0
R3(config-if)#ip access-group

Using An ACL To Limit Telnet
Access
Earlier, you learned how to
configure a password on a router or
switch’s VTY lines to control
access only to those who know the
password. That might not be
enough, as you may want to control
Telnet access according to the IP
address of the host attempting to
connect. We can do that with an
ACL and the access-class
command.
The ACL is used to indicate what
host or hosts can telnet to a router.
The syntax of the ACL is the same,

but it is applied in a slightly
different manner. The ACL is
applied to the vty lines with the
access-class command.
In this lab, we currently have two
hosts on our network that can telnet
into R3. One is 172.23.23.2 (R2),
and the other is 172.12.123.1 (R1).
R1’s telnet attempt:
R1#telnet 172.12.123.3
Trying 172.12.123.3 … Open
User Access Verification
Password:
R3>

R2’s telnet attempt:
R2#telnet 172.23.23.3
Trying 172.23.23.3 … Open
User Access Verification
Password:
R3>

We’ve decided to allow only the
connection from R2, while blocking
all others. We’re going to specify
the R2 IP address 172.23.23.2 as
the permitted address.

R3(config)#access-list 55 perm
R3(config)#access-list 55 deny

Use the access-class command to
apply an ACL to your VTY lines.
The direction of the connection
must be defined.
R3(config)#line vty 0 4

R3(config-line)#access-class 5
in

Filter incoming connect

out

Filter outgoing connect

R3(config-line)#access-class 5

When both hosts that could
previously telnet to R3 try it
again….

R1#telnet 172.12.123.3
Trying 172.12.123.3 …

% Connection refused by remote

R2#telnet 172.23.23.3
Trying 172.23.23.3 … Open
User Access Verification
Password:
R3>

… R2 can still telnet to R3
successfully, but R1 is now
blocked!

This is a great tool to limit Telnet
access to certain IP addresses in
your internal network while
blocking all others.

Where Should An ACL Be
Placed?
The #1 rule of placing ACLs in the
real world is to prevent traffic from
traveling across a WAN when that
traffic is going to be blocked from
getting to its final destination in the
first place.

If we want to prevent that PC from
accessing the server on the other
side of the WAN, logic dictates
we’d use an extended ACL and

place the ACL as close to that PC
as possible.
Using the extended ACL allows us
to specify a source AND
destination IP address for filtering,
as opposed to a standard ACL,
which only allows you to filter on
the source IP address.

Placing the ACL as close to the

source of the traffic prevents
unnecessary traffic from going
across the WAN. If the traffic is not
going to be allowed to reach the
email server, why let it go across
the WAN to begin with? Using an
extended ACL in this situation stops
the unwanted traffic from crossing
the WAN and unnecessarily using
bandwidth and the remote router’s
resources.
If you have to use a standard ACL,
put it on the interface closest to the
destination. We can’t put the
standard ACL at the same point at
which we would apply an extended

ACL, because that would block all
traffic sourced from that PC.

In the real world, there’s no way
you would ever use a standard ACL
here. If you were out of numbered
extended ACLs, which does
happen, you’d simply write a
named extended ACL. Since you
can only filter on source IP
addresses with a standard list,

you’d need to put it as close to the
destination as possible.
Placement can also be affected
when you consider how inbound
and outbound ACLs handle traffic.
Outbound ACLs are applied
after packets have already
been sent to the outbound
interface by the routing
engine, but before they’re put
in the transmission queue.
In contrast, inbound ACLs
are applied before the routing
engine handles them.

All things being equal, the router’s
better off by blocking traffic with an
inbound ACL as opposed to an
outbound ACL. Sometimes - like
when you’re stuck using a standard
ACL to block traffic - the ACL has
to go on the outbound interface.
Let’s do a lab involving ACL
placement that will give us
additional practice with standard
and extended ACLs. Here’s our
network:

The requirements for the first part
of this lab:
A standard ACL must be
used.
We want to prevent any host
on network 11.11.11.0 /24

from accessing our
moneybags server at
44.44.44.4, along with any
other hosts we may add to
that same network segment in
the future.
All other networks should be
allowed to access 44.44.44.0
/24.
Hosts on 11.11.11.0 /24
should be allowed to reach
hosts on 33.33.33.0 /24.
Since a standard ACL allows us to
filter only on the source IP address,
we can’t place the ACL on either

interface on R2, since this would
block all traffic from 11.11.11.0
/24.
The only answer is to put the ACL
on R3. But where?
We can’t put the ACL on the Serial
interface, because that would have
the same result as putting it on R2.
We’d block all traffic coming in
from 11.11.11.0 /24, and we were
specifically told hosts on 11.11.11.0
/24 should be able to reach
33.33.33.0 /24. The ACL would
have to go on the interface leading
directly to 44.44.44.0 /24.

The config on R3 (Ethernet0 is the
interface on 44.44.44.0 /24):
R3(config)#access-list 5 deny
R3(config)#access-list 5 perm
R3(config)#int e0
R3(config-if)#ip access-group

Pings from the host 11.11.11.11 to
the 33 network go through, but the
pings to network 44 are
successfully blocked. Note the ping
results for the blocked ping, as I’m
using a Cisco router for the host.
HOST#ping 33.33.33.33

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
second
!!!!!

Success rate is 100 percent (5
36/38

HOST#ping 44.44.44.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
second
U.U.U

Success rate is 0 percent (0/5

Done and done!
Or….. ARE we?
We met the requirements, but it’s
not a solid real-world config. This
config is inefficient at several

levels.
The host is sending packets
that have no chance of getting
to 44.44.44.0 = wasted effort.
Packets processed and
forwarded by R2 that have no
chance of getting to
44.44.44.0 = wasted effort.
WAN bandwidth is sucked up
by packets that will be
stopped on the other side of
the WAN = wasted
bandwidth.
R3 has to process incoming
packets it’ll dump before

forwarding them = wasted
effort again!
An extended ACL is a far superior
choice, since we can put that on R2,
and traffic that has no chance to get
to 44.44.44.0 /24 will be stopped
before it crosses the WAN.

Here’s the config on R2:

R2(config)#access-list 110 den
44.44.44.0 0.0.0.255

R2(config)#access-list 110 per
R2(config)#int e0
R2(config-if)#ip access-group

Done and done – and in a much
more efficient manner!
In a nutshell, unless a practice exam
(or real exam) question forces you
to use a standard ACL, you should
use an extended ACL. And if you
run out of numbers, use a named

one!

To Block Or Not To Block, That’s
The Pinging Question!
Blocking pings is simple enough.
Just write an ACL that blocks ICMP
echo packets and allows everything
else. Here, R2 and R3 are on the
same Ethernet segment, and R2 has
no problem pinging R3.
R2#ping 172.23.23.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
seconds: !!!!!
Success rate is 100 percent (5
ms

To block pings coming in on R3’s

ethernet interface, we simply write
an extended ACL specifying ICMP
as the protocol and specifying echo
at the end of the line. If we wanted
to block ping responses, we’d
configure echo-reply at the end of
this line.

R3(config)#access-list 101 deny icmp
<0-255>
ICMP message t
administratively-prohibited Administ
alternate-address
Alternat
conversion-error
Datagram
dod-host-prohibited
Host pro
dod-net-prohibited
Net proh
dscp
Match pa
echo
Echo (ping)
echo-reply

Echo reply

< readout truncated for clarity >

After applying the ACL to R3, R2
can no longer successfully ping R3.

R3(config)#access-list 101 den
R3(config)#access-list 101 per
R3(config)#int e0
R3(config-if)#ip access-group
R2#ping 172.23.23.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
seconds:
U.U.U

Success rate is 0 percent (0/5

The show access-list and show ip
access-list commands show you
how many matches each line of the
ACL has.

R3#show access-list
Extended IP access list 101
deny icmp any any echo (5 matc
permit ip any any
R3#show ip access-list
Extended IP access list 101

deny icmp any any echo (5 matc
permit ip any any

Why are we concerned about
blocking or allowing pings in the
first place? Many networks block
pings and / or ping replies on their
border router’s outside interface to
prevent network attacks. That
include reconnaissance attacks,
which are not designed to cause
damage. Rather, these are
information-gathering attacks, and
ping output is chock full o’ info!

Don’t go wild blocking pings on the
inside of your network, though.
Pings are the first thing we use
when network connectivity is
compromised, and if pings are
blocked that can lead to “false
negatives”. That is, we think a
device is down when it doesn’t
return pings, but it’s actually up and

the ACL is blocking the pings.

Advanced ACL Types
Standard and extended ACLs fit the
bill perfectly in many situations, but
when you come right down to it,
they’re hardcore when it comes to
permitting and denying. Either
you’re permitted to do something or
you’re not - there’s no grey area
with these ACL types.
In networking, we’re always going
to need some kind of exception to
the rule. The following are more
advanced ACLs than the standard
and extended ones we generally
use, and even if you don’t see them
on your exam, you’ll definitely see

them in production networks.
And if you do see them on your
exam, you’ll be happy you knew
about them!
Commonly referred to as “lockand-key”, dynamic ACLs are
dynamic extended access lists.
Certain Telnet users will be able to
authenticate as usual, but this access
to their intended destination is
strictly temporary. Once their
access time has elapsed, the access
is terminated. It’s much like a guest
knocking on your door – you may
choose to let them in for a certain
period of time, then remind them

when it’s time for them to go, and
then lock the door right behind them
when they leave.
Here are the basic steps for lockand-key:
The remote user telnets to the
router.

The router authenticates the user,
and then creates an entry in the
dynamic ACL that allows this

particular host access to networks
that we’ve previously defined.

The natural question is “How long
does the remote host have access to
the specified network?” That’s up
to us as the network admins, and
there are two different kinds of
timeouts we can set:
an absolute timeout, where
the remote host has “x”

minutes of access, and that’s
it
an idle timeout, where the
connection is terminated once
no data is exchanged for “x”
minutes
Time-based ACLs can be set to
deny or permit traffic on -- you
guessed it! - - the basis of time.
These babies really come in handy
on occasions where you need to
allow or deny access for a certain
period of time, or for certain days
of the week.
To write a time-based ACL, you

must first use the time-range
command to define the times that
certain lines of the ACL will be
applied. You can do this on a perday basis or choose daily,
weekdays, or weekend, as shown by
IOS Help.

R1(config)#time-range NOTELNET

R1(config-time-range)#periodic
Friday
Monday
Saturday
Sunday
Thursday
Tuesday
Wednesday

Friday
Monday
Saturday
Sunday
Thursday
Tuesday
Wednesday

daily
weekdays
weekend

Every day of the
Monday thru Frida
Saturday and Sund

We’ll choose weekend and then
define an hourly time range.

R1(config-time-range)#periodic
hh:mm Starting time

R1(config-time-range)#periodic
to ending day and time

R1(config-time-range)#periodic

hh:mm Ending time - stays va
minute

R1(config-time-range)#periodic

When you write the ACL, specify
the protocol and port number as you
normally would, and then add the
time-range option at the end of the
ACL line you want to be subject to
the time range values.

R1(config)#access-list 101 den
NOTELNET R1(config)#access-lis

R1#show access-list 101
Extended IP access list 101
10 deny tcp any any eq tel
20 permit ip any any

R1(config)#int s0/0
R1(config-if)#ip access-group

You’re all set!
Note (inactive) in the output of
show access-list. You’ll only see
that when you have a time range
defined, and that means that
particular line of the ACL is not
being applied because the present
time is not in the time range. I set
the lab router’s clock to a time
when the NOTELNET time range
would be valid, and here’s the
result:

R1#show ip access-list

Extended IP access list 101
deny tcp any any eq telnet
permit ip any any

ACL Sequence Numbers
I recommend when you’re writing
an ACL, you first write it out in
Notepad or your favorite word
processing software and then check
out the top-to-bottom logic. It’s
amazing how many headaches that
can save you.
Sooner or later, though, you’ll write
an ACL on the router and then
realize you forgot a line. I just
happen to have an example of that
right here:

R1(config)#access-list 45 deny
R1(config)#access-list 45 deny
R1(config)#access-list 45 deny

R1(config)#access-list 45 perm

After writing the ACL, you realize
you meant to deny the 172.12.13.0
/24 network as well. In the good
old days, you’d have to delete that
ACL and type it in all over again,
because any new lines would be
added at the bottom. I used an older
IOS to illustrate this old problem
below.
R1(config)#access-list
R1(config)#access-list
R1(config)#access-list
R1(config)#access-list

45
45
45
45

deny
deny
deny
perm

After saving the list, I add a line to
the ACL and run show access-list to
verify.

R1(config)#access-list 45 deny

R1#show access-list 45
Standard IP access list 45
deny 172.12.0.0, wildcard
deny 172.14.0.0, wildcard
deny 172.16.0.0, wildcard
permit any
deny 172.13.0.0, wildcard

That list wouldn’t give us the
desired result, so we’d have to
remove the ACL from any interfaces
it had been applied to, delete the

ACL, and then rewrite it.
A real pain in the butt – but no
longer!
The Cisco IOS now assigns a
sequence number to each line in an
ACL, and you can use those
sequence numbers to your
advantage. After configuring the
same list on a router with a more
recent IOS, I’ll run show ip accesslist 45.

R1#show ip access-list 45
Standard IP access list 45
10 deny 172.12.0.0, wildca
20 deny 172.14.0.0, wildca
30 deny 172.16.0.0, wildca

40 permit any

Note the sequence numbers at the
far left. We didn’t enter those
manually – those numbers were
assigned to each line by the IOS.
Now we want to enter a line into
this ACL that denies 172.13.0.0 /24,
and we want it to be the very first
line. We need to assign it a
sequence number between 1 and 9,
so we’ll take the middle ground and
assign it a sequence number of 5.
We enter ACL config mode with the
ip access-list command.

R1(config)#ip access-list stan

R1(config-std-nacl)#?

Standard Access List configura
<1-2147483647>
default

Sequence Numbe

Set a command to its

deny

Specify packet

exit

Exit from access-list c

no

Negate a command or set

permit

Specify packets to f

remark

Access list entry co

R1(config-std-nacl)#5 deny 172

The change is verified with show
access-list 45.

R1#show access-list 45
Standard IP access list 45
5 deny
172.13.0.0, wildcard
10 deny
172.12.0.0, wildcard
20 deny
172.14.0.0, wildcard
30 deny 172.16.0.0, wildcard b
40 permit any

You can remove a line in this mode
as well. If we decided not to block
access to 172.14.0.0 /16, we’d use
the no option to remove that
particular line.

R1(config)#ip access-list stan
R1(config-std-nacl)#no ?

<1-2147483647> Sequence Number
deny
permit

Specify packets to
Specify packets

R1(config-std-nacl)#no 20 ?
<cr>
R1(config-std-nacl)#no 20

R1#show access-list 45
Standard IP access list 45
5 deny
172.13.0.0, wildc
10 deny
172.12.0.0, wild

30 deny
172.16.0.0, wild
40 permit any

That really beats rewriting an entire
ACL! “no 20” seems like an odd
command, but that short command
packs a big punch!

A Quick Look At NTP
Our time-based ACLs aren’t going
to be much good to us if the routers
don’t have and keep accurate time!
It’s vital to have time synchronized
across your network, and the
Network Time Protocol helps make
that possible.
If your network devices have
different times configured,
problems from the annoying to the
critical can occur, including…
Timestamps on log entries
will be incorrect, making
troubleshooting more difficult

than it already is
Secure certificates will not
function correctly
Security services and tools
that rely on consistent time
across the network will not
function correctly
Time-based ACLs are going
to have a pretty hard time of
it, too!
The typical NTP configuration
begins with a network device or
devices getting their time from a
highly believable, secure source.

From there, those devices under our
control give the time to the other
devices in our network.

CCNA Security teaser ahead! You
have to be careful that other devices
outside your network aren’t using
this router as their NTP server.
That’s a lot of extra work on your
router, and it’s not a secure network
setup.
NTP servers are classified by

stratum. At the top of the NTP
hierarchy we’ll find HUGE NTP
master clocks, classified as
“Stratum Zero”. A Cisco router
can’t be configured as a Stratum
Zero device, as shown here by IOS
Help:
NTP_SERVER(config)#ntp master
<1-15> Stratum number
<cr>

In this example, we’ll configure R1
as a NTP time server, and configure
R3 to get its time from R1, verifying
the final config with show ntp
associations and show ntp status.

Note the NTP Client has the ntp
server command configured on it.
There is no “ntp client” command.
R3(config)#ntp ?
access-group
authenticate
authentication-key
time sources
broadcastdelay

Control

Authenti

Authenti

Estimate

clock-period

Length o

logging

Enable N

master

Act as N

max-associations
associations

Set maxi

peer

Configur

server

Configur

source
address

Configur

trusted-key
sources

Key numb

R3(config)#ntp server ?

Hostname or A.B.C.D IP addre
vrf
Information

VPN Rout

R3(config)#ntp server 20.1.1.1

R1(config)#ntp master ?
<1-15>

Stratum number

<cr>

R1(config)#ntp master 5 ?

<cr>
R1(config)#ntp master 5

On R3, I’ll run show ntp
associations. Note both symbols
next to “20.1.1.1”. The asterisk
means the local router is synced
with the NTP master; the other
means the entry was statically
configured. That synchronization
only took a few seconds in a lab,
but can take several minutes in a
real-world network, so be patient
with this command. (I’ve removed
some of the output for clarity.)

R3#show ntp associations

address
*~20.1.1.1

ref cloc

127.127.7.1

* master (synced), # master (
candidate, ~ configured

You also need to see the magic
words “clock is synchronized” in
the output of show ntp status.
R3#show ntp status

Clock is synchronized, stratum

nominal freq is 250.0000 Hz, a

Hz, precision is 2**18

reference time is D5A99118.19B
Mon Aug 5 2013)

clock offset is 0.3298 msec, r
root dispersion is 1.74 msec,
msec

That’s enough to get you started
with NTP! Let’s head to the next
section and spend some time with
one of the most handy Cisco skills
you’ll ever develop!

Route Summarization
This is a fantastic technique for
keeping your routing tables
complete and concise!
When our router looks for a given
destination in the routing table, it
will look at all possible routes in
search of the best match for the
destination in question. The larger
the table, the more time this takes.
Large routing tables are also a drain
on router memory.
EIGRP, and OSPF both use
different commands to perform

route summarization, but the
process of coming up with the
summarized route is the same.
R2 is sending a routing update to
R3 for the networks 100.4.0.0 /16,
100.5.0.0 /16, 100.6.0.0 /16, and
100.7.0.0 /16. Without route
summarization, R2 will send an
update containing the four
individual routes.

To configure a summary for these
networks, write the network
numbers out in binary. (For obvious
reasons, you don’t have to write out
the last two octets.)

100.4.0.0
100.5.0.0
100.6.0.0
100.7.0.0

1st Octet
01100100
01100100
01100100
01100100

2nd Octet
00000100
00000101
00000110
00000111

3
00
00
00
00

Moving left to right, determine what
bits the network numbers have in
common.

100.4.0.0
100.5.0.0
100.6.0.0
100.7.0.0

1st Octet
01100100
01100100
01100100
01100100

2nd Octet
00000100
00000101
00000110
00000111

The networks have the first 14 bits
in common. Just add the common
bits and you have the summary,
which in this case is 100.4.0.0.
Simple, right? Right!
BUT -- we’re not quite done!
We need a mask to go with that
summary, and most of that work is

3
00
00
00
00

already done. The mask is
determined by putting “1” in for
each of the common bits of the
summary network number, and “0”
for the “don’t care” bits. In this
example, the binary mask would be
11111111 11111100 00000000
00000000, resulting in a mask of
255.252.0.0.
The final summary address is
100.4.0.0 255.252.0.0, or 100.4.0.0
/14. Watch that on both the exam
and in network documentation those two summaries are the same,
just expressed in different formats.

The summary may include networks
that don’t exist (yet). The previous
example is a “clean” route
summarization; it includes only the
four specified networks and no
others. What if the routes to be
summarized were 100.1.0.0,
100.2.0.0, 100.3.0.0, and
100.4.0.0?
1st Octet

2nd Octet 3

100.1.0.0
100.2.0.0
100.3.0.0
100.4.0.0

01100100
01100100
01100100
01100100

00000001
00000010
00000011
00000100

The four networks have their first
13 bits in common. The resulting
network number 100.0.0.0 is the
summary for the networks. The
subnet mask is determined by
putting “1” in for each common bit
and “0” for the rest, resulting in a
mask of 255.248.0.0. The final
summary address is 100.0.0.0
255.248.0.0.

00
00
00
00

A routing issue could arise because
this summary also includes
networks 100.5.0.0, 100.6.0.0, and
100.7.0.0:

100.1.0.0
100.2.0.0
100.3.0.0
100.4.0.0
100.5.0.0
100.6.0.0
100.7.0.0

1st Octet
0110100
0110100
0110100
0110100
0110100
0110100
0110111

2nd Octet
00000001
00000010
00000011
00000100
00000101
00000110
00000111

This does not make the summary

3rd
000
000
000
000
000
000
000

address wrong, but it does make
routing problems a possibility if
those yet-to-be configured networks
are placed elsewhere in the
network.

Once the summary address and

mask have been determined, write
out the next consecutive network
number to see if the summary
address will also represent that
address. If so, be aware of the
potential routing issues of using that
network number in another section
of the network.
EIGRP is not a CCENT topic, but I
would like you to see some realworld examples of route
summarization, so I’m going to
include this EIGRP example. You
don’t have to know EIGRP from a
hole in the ground to benefit from

this demo. (We’ll take care of that
in your CCNA studies!)

Route Summarization With
EIGRP
R2 is advertising four routes to R3
via EIGRP: 100.0.0.0 /8, 101.0.0.0
/8, 102.0.0.0 /8, and 103.0.0.0 /8.

To summarize the networks, convert
them from dotted decimal to binary,
and determine how many incommon bits exist from left to right.

100.1.0.0
101.1.0.0
102.1.0.0
103.1.0.0

1st Octet
01100100
01100101
01100110
01100111

2nd Octet
00000001
00000001
00000001
00000001

3
00
00
00
00

The networks have six bits in
common, resulting in the network
number 100.0.0.0. The summary
mask is determined by placing 1s in
the mask for the in-common bits and
0s for the rest. The binary mask is
11111100 00000000 00000000
00000000, which in dotted decimal
is 252.0.0.0.

The summary address and mask is
100.0.0.0 252.0.0.0. The interfacelevel command ip summaryaddress eigrp is used to advertise
the summary.

R2#conf t
R2(config)#interface ethernet0

R2(config-if)#ip summary-addre

And when we’re done, the

summarized route appears on R3!

R3#show ip route eigrp
D
100.0.0.0/6 [90/2297856] v
Ethernet0

OSPF route summarization isn’t
quite as straightforward. The
process of arriving at the summary
and mask is the same, but the
advertising of the route is a lot
different, and it involves concepts
you haven’t hit in your studies.
We’ll leave examples of that for
your CCNP studies.
For the CCENT, be sure to practice

the math and processes in this short
section and you’ll be ready for
success on exam day.
Let’s head to the next section and
remove the dread from the dreaded
IP Version 6!

IP Version 6
IP Version 6 is all around us today,
and even if you’re not working
directly with it today, you will be
one day!
Well, you will be if you’ve taken
the initiative to learn IPv6. A lot of
network admins have put off
learning IPv6, which is a huge
mistake. Even if it doesn’t impact
your current career, you’re
definitely limiting your future
prospects if you aren’t strong with
IPv6 – and you’re strengthening

your prospects when you are!
By studying the material in this
section, you’ll have a strong
foundation in IPv6, and your future
success is all about the foundation
you build today.
The IPv6 addresses themselves are
the scariest part of IPv6 for many
admins, and we’ll dive right into
addresses – and you’re going to
master them!
The IPv6 Address Format

Typical IPv4 address:
129.14.12.200

Typical IPv6 address:
1029:9183:81AE:0000:0000:0AC1:2
As you can see, IPv6 isn’t exactly
just tacking two more octets onto an
IPv4 address!
I haven’t met too many networkers
who really like typing, particularly
numbers. You’ll be happy to know
there are some rules that will
shorten those addresses a bit, and
it’s a very good idea to be fluent
with these rules for your CCNA
exam.

You’ll also need the skill of reexpanding the addresses from their
compressed state to their full 128bit glory, and you’ll develop that
skill in this section as well. Be sure
to have something to write with and
on when studying this section.
Zero Compression And Leading
Zero Compression
When you have consecutive blocks
of zeroes in an IPv6 address, you
can represent all of them with a
single set of colons. It doesn’t

matter if you have two fields or
eight, you can simply type two
colons and that will represent all of
them. The key is that you can only
perform this zero compression once
in an IPv6 address. Here’s an
example:

Original format:
1234:1234:0000:0000:0000:0000:34
Using zero compression:
1234:1234::3456:3434
Since blocks of numbers are
separated by a single colon in the
first place, be careful when

scanning IPv6 addresses for
legality. If you see two sets of
colons in the same address, it’s an
illegal address – period, no
exceptions. (Hooray!)
We can also drop leading zeroes in
any block, but each block must have
at least one number remaining. You
can perform leading zero
compression in any address as
many times as you like.
By the way, I refer to each
individual set of numbers in an IPv6
address as “blocks” and
occasionally “fields”; you can call
them whatever you like, since

there’s no one official term.

Let’s look at an example of leading
zero compression. Taking the
address
1234:0000:1234:0000:1234:0000:12
we have four different blocks that
have leading zeroes. The address
could be written out as it is, or we
can drop the leading zeroes.

Original format:
1234:0000:1234:0000:1234:0000:01
With leading zero compression:
1234:0:1234:0:1234:0:123:1234
For your exam and for the real

world, both of those expressions
are correct. It’s just that one uses
leading zero compression and the
other does not. Watch that on your
exam!
Using zero compression and leading
zero compression in the same
address is perfectly legal:

Original format:
1111:0000:0000:1234:0011:0022:00
With zero and leading zero
compression:
1111::1234:11:22:33:44
Zero compression uses the double
colon to replace the second and

third block of numbers, which were
all zeroes. Leading zero
compression replaced the “00” at
the beginning of each of the last four
blocks. Just be careful and take
your time with both zero
compression and leading zero
compression and you’ll do well on
the exam and in the real world. T

Why Can’t You Use Zero
Compression More Than Once?
As soon as you tell me I can’t do
something, I want to know why –
and then I’ll probably try it anyway.
(Mom always said I was a strongwilled child.)
So when I was checking out IPv6
for the first time and ran into that
zero compression limitation, I
thought “Why can’t you use that
more than once?”
Let’s check out this example to see
why:

1111:0000:0000:2222:0000:0000:00

If we were able to use zero
compression more than once, we
could compress that address thusly:
1111::2222::3333
Great! But what happens when the
full address is needed? We know
there are eight blocks of numbers in
an IPv6 address, but how would we
know the number of blocks
represented each set of colons?
That full address could be this:

1111:0000:2222:0000:0000:0000:00
Or this:

1111:0000:0000:0000:0000:2222:00

Or this!

1111:0000:0000:0000:2222:0000:00
If multiple uses of zero
compression were legal, every one
of those addresses could be
represented by 1111::2222::3333 –
and none of them would actually be
the original address!
That’s why using zero compression
more than once in an IPv6 address
is illegal – there would be no way
to know exactly what the original
address was, which would kind of
defeat the purpose of compression!

“The Trailing Zero Kaboom”
Watch this one – it can explode
points right off your score.
When you’re working with zero
compression, at first it’s easy to
knock off some trailing zeroes along
with the full blocks of zeroes, like
this:

1111:2222:3300:0000:0000:0000:00
… does NOT compress to…
1111:2222:33::44:5555
The correct compression:
1111:2222:3300::44.5555

You can’t compress trailing zeroes.
That’s another way to identify
illegal IPv6 addresses -- if you see
multiple colon sets or zeroes at the
end of a block being compressed,
the address expression is illegal.

Decompressing While Avoiding
The Bends
Decompressing an IPv6 address is
pretty darn simple. Example:
2222:23:a::bbcc:dddd:342
First, insert zeroes at the beginning
of each block that has at least one
value in it. The result:
2222:0023:000a::bbcc:dddd:0342
Next, insert fields of zeroes where
you see the set of colons.
How many fields, you ask? Easy!
Just count how many blocks you see
now and subtract it from eight. In

this case, we see six blocks, so we
know we need two blocks of zeroes
to fill out the address.

2222:0023:000a:0000:0000:bbcc:dd
Done and done!
This is also an easy skill to practice
whenever you have a few minutes,
and you don’t even need a practice
exam to do so. Just take a piece of
paper, and without putting a lot of
thought into it, just write out some
compressed IPv6 addresses and
then practice decompressing them.
(You should put thought into that
part.)

The Global Routing Prefix: It’s
Not Exactly A Prefix
While the address formats of IPv4
and v6 are wildly different, the
purpose of many of the IPv6
addresses we’ll now discuss will
seem familiar to you – and they
should!
These v6 addresses have some huge
advantages over v4 addresses,
particularly when it comes to
subnetting and summarization. The
IPv4 address scheme really wasn’t
developed with subnetting or
summarization in mind, where IPv6
was developed with those helpful

features specifically in mind.
In short, v6 addresses were born to
be subnetted and summarized!
I mention that here because our first
address type was once often
referred to as “aggregateable global
unicast address”. Thankfully, that
first word’s been dropped, but the
global unicast address was
designed for easier summarization
and subnetting.
Basically, when your company gets
a block of IPv6 addresses from an
ISP, it’s already been subnetted a
bit. At the top of the “IPv6 address
subnet food chain” is the IANA, the

Internet Assigned Numbers
Authority (http://www.iana.org/).
The IANA has the largest
block of addresses, and
assigns subnets from those
blocks to Regional Internet
Registries (RIRs) in
accordance with very strict
rules.
In turn, the Registries assign
subnets of their address
blocks to ISPs. (The IANA
never assigns addresses
directly to ISPs!) These RIRs
are located in

The ISPs then subnet their
address blocks, and those
subnets go to their customers.
I strongly recommend you visit
http://www.iana.org/numbers for
more information on this process.
It’s beyond the scope of the CCENT
exam, but it’s cool to see where the
Registries are, along with charts
showing how the IANA keeps
highly detailed information on
where the IPv6 global unicast
addresses have been assigned.

Now here’s the weird part – these
blocks of addresses are actually
referred to as “global routing
prefixes”. When you think of a
“prefix” at this point, you likely
think of prefix notation (/24, for
example). It’s just one of those IPv6
things we have to get used to.
Here’s something else we need to
get used to – you and I are now the
network admins of Some Company

With No Name (SCWNN). And our
first task awaits!

“Now What Do I Do?”
We’ve requested a block of
addresses from our ISP (a “global
routing prefix”, in IPv6-speak), and
we’ve got ‘em. Now what do we
do?
We subnet them!
Hey, come back! It’s not that bad.
Personally, I believe you’ll find
IPv6 subnetting to be easier than
IPv4 subnetting – after you get some
practice in, of course!
When we get the global routing
prefix from our ISP, that comes with
a prefix length, and in our example

we’ll use a /48 prefix length. The
prefix length in IPv6 is similar to
the network mask in IPv4. (The /48
prefix length is so common that
prefixes with that length are
sometimes referred to as simply
“forty-eights”.)
You might think that leaves us a lot
of bits to subnet with, but there’s
also an Interface Identifier to work
with, and it’s almost always 64 bits
in length. This ID is found at the end
of an IPv6 address, and it identifies
the host. We’ll go with that length in
this exercise.

So far we have a 48-bit prefix and a
64-bit identifier. That’s 112 bits,
and since our addresses are 128
bits in length, that leaves us 16 bits
for --- subnetting!
Global Routing Prefix:
2001:1111:2222 (48 bits)
Subnet ID: 16-bit value found
right after the GRP
Interface ID: 64-bit value that
concludes the address
Can we really create as many
subnets as we’ll ever need in our

company with just 16 bits? Let’s
find out. We use the same formula
for calculating the number of valid
subnets here as we did with v4 –
it’s 2 to the Nth power, with “N”
being the number of subnet bits.
2 to the 16th power is 65,536. That
should cover us for a while!
Now we need to come up with the
subnet IDs themselves.

Determining The Subnet ID
Nothing to it, really. In our example
of 2001:1111:2222 as the global
routing prefix, we know that the
next block will represent the
subnets. You can just start writing
them out ( or entering them in a
spreadsheet – highly recommended)
and go from there.
Your first 11 subnets are 0001,
0002, 0003, 0004, 0005, 0006,
0007, 0008, 0009, 000A, and 000B.
I listed that many as a gentle
reminder that we’re dealing with
hex here!
Our first full subnet is

2001:1111:2222:0001::/64, the next
is 2001:1111:2222:0002 /64, and
so forth. That’s it! Just be sure to
keep careful records as to where
each of your subnets are placed in
your network, and I strongly
recommend you issue them
sequentially rather than just pulling
values at random.
Now we’re going to start assigning
IPv6 addresses to router interfaces.
We have options with IPv6 that are
similar to IPv4’s static assignment
and DHCP, but there are important
differences we must be aware of in
order to past the exams – and just as

importantly, to be ready to work
with IPv6 in the field. Let’s get to
work

First Things First: Enable IPv6
Routing – Twice?
We don’t think twice about using
IPv4 routing on a Cisco router,
since it’s on by default. However,
when using IPv6 routing, you need
to enable it twice:
Enable IPv6 routing globally
with the ipv6 unicast-routing
command
Enable IPv6 routing on an
interface level with ipv6
address, followed by the
IPv6 address itself.

V6ROUTER1(config)#ipv6 unicast

V6ROUTER1(config)#int fast 0/0

V6ROUTER1(config-if)#ipv6 addr
2001:1111:2222:0001:1::/64

You won’t get a message that IPv6
routing has been enabled after you
run ipv6 unicast-routing, nor will
pigeons be let loose, so you better
verify with show ipv6 interface and
show ipv6 interface brief.
Note: It’s really easy to leave the
“ipv6” part of those commands out,
since we’re used to running those
commands without it.

Another note: I’m going to truncate
the output of both of these
commands for now – you’ll see the
full output later.
V6ROUTER1#show ipv6 interface

FastEthernet0/0 is up, line pr

IPv6 is enabled, link-local ad
FE80::20C:31FF:FEEF:D240

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:1::, subn
2001:1111:2222:1::/64
Joined group address(es):

FF02::1
FF02::2
FF02::1:FF00:0
FF02::1:FFEF:D240

A little of this output is familiar,
particularly that first line. Just as
with IPv4, we need our IPv6
interface to show as “up” and “up”
– and if they’re not, we go through
the exact same troubleshooting
checklist as we would if this were
an IPv4 interface. Always start
troubleshooting at the physical

layer, no matter what version of IP
you’re running!
Since we’re good on the physical
and logical state of the interface,
we can look at the rest of the config
– and everything’s different here!
We see the global unicast address
we configured on the interface, and
the subnet is right next to that. After
that, we seem to have joined some
groups, and we’ve also got
something called a “link-local
address”. Before we delve into
those topics, let’s have a look at
show ipv6 interface brief.
V6ROUTER1#show ipv6 interface

FastEthernet0/0
[up
FE80::20C:31FF:FEEF:D240
2001:1111:2222:1:1::
Serial0/0
[ad
FastEthernet0/1
[ad
Serial0/1
[ad

Brief, eh? All we get here is the
state of each interface on the route,
and the IPv6 addresses on the IPv6enabled interfaces. Note the output
doesn’t even tell you what those
two addresses even are, so we
better know the top one is the linklocal address and the bottom one is
the global unicast address.
We know what the global unicast

address is, so let’s spend a little
time talking about that link-local
address – tis an important IPv6
concept!

The Link-Local Address
Another “name is the recipe” topic!
Packets sent to a link-local address
never leave the local link – they’re
intended only for hosts on the local
link, and routers will not forward
messages with a link-local address
as a destination. (Since these are
unicast messages, the only host that
will process it is the one it’s unicast
to.)
Fun fact: IPv4 actually has linklocal addresses, but they rarely
come into play. In IPv6, a link-local
address is assigned to any and
every IPv6-enabled interface. We

didn’t configure a link-local
address on our Fast 0/0 interface,
but when we ran our show ipv6
interface commands, we certainly
saw one!
V6ROUTER1#show ipv6 interface

FastEthernet0/0 is up, line pr

IPv6 is enabled, link-local ad
FE80::20C:31FF:FEEF:D240

Soooo… if we didn’t configure it,
where did it come from? Is our
router haunted by a g-g-gghoooooooost?
Nothing as fun as that. The router

simply created the link-local
address on its own, in accordance
with a few simple rules. I’m sure
you noticed that address was
expressed using zero and leading
zero compression, so let’s decompress it and examine the
address in all its 128-bit glory.
Compressed:
FE80::20C:31FF:FEEF:D240

Uncompressed:
FE80:0000:0000:0000:020C:31FF:F
According to the official IPv6
address standards, the link-local
reserved address block is
Fe80::/10. That means the first ten

bits have to match FE80, and
breaking that down into binary….
(8,4,2,1 for each block)
FE80 = 1111 1110 1000 0000
… we see that by setting the last
two bits in the third block to all
possible different values, we end
up with 1000, 1001, 1010, and
1011. That means link-local
addresses should be able to begin
with Fe8, Fe9, FeA, and FeB.
However, RFC 4291 states the last
54 bits of a link-local address
should all be set to zero, and the

only value that makes that possible
is Fe80. Following that standard –
which is exactly what you should
do on exam day and in the field –
link-local addresses should begin
with Fe80, followed by three
blocks of zeroes.
So far, our link-local address is
Fe80:0000:0000:0000. We’re 64
bits short, and the Cisco router’s
going to take care of that by creating
its own interface ID via EUI-64
rules. And while the router will
figure out its own interface
identifier in the field, you may just
be asked to determine a couple of

these on your exam or job
interview.
With that said, let’s take a close
look at the process and compare it
to what we’re seeing on our live
equipment!

How Cisco Routers Create Their
Own Interface Identifier
It’s easy, and I’d be ready to
perform this little operation on
exam day.
The router just takes the MAC
address on the interface, chops it in
half, sticks FFfe in the middle, and
then perfoms one little bit
inversion. Done!
In our example, we’ll use 11-2233-aa-bb-cc. Chop it in half and put
the FFfe in the middle…
1122:33FF:FEAA:BBCC
… and you’re almost done.

Write out the hex value for the first
two digits, “11” in this case, and
invert the 7th bit.
“Invert the bit” is a fancy way of
saying “If it’s a zero, make it a one,
and if it’s a one, make it a zero.”
11 = 0001 0001
Invert the 7th bit
0001 0011
result is 13
Replace the first two characters
with the ones you just calculated,

and you’re done! The interface
identifier is
1322:33FF:FEAA:BBCC.
Let’s practice this skill using the
MAC address of FastEthernet 0/0
on our live IPv6 router.
V6ROUTER1#show int fast 0/0

FastEthernet0/0 is up, line pr

Hardware is AmdFE, address i
000c.31ef.d240)

The MAC address is
000c.31ef.d240, so we’ll split that
right in half and put FFFE in the
middle:

000c:31FF:FEEF:D240
Now for that bit inversion! We
know 00 = 0000 0000, so invert the
7th bit to a 1, and we have 0000
0010, which equals 02. Put the “02”
in the address in place of the “00”
at the beginning of the identifier,
and we have….
020c:31FF:FEEF:D240
… and after a (very) little leading
zero compression, we’re left with
20c.31FF:FEEF:D240. Is that
correct? Let’s check out that linklocal address….
V6ROUTER1#show ipv6 interface

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20C:31FF:FEEF:D240

We’re right! The full link-local
address is shown, and after the zero
compression of the prefix
FE80:0000:0000:0000, the
interface identifier is listed – and it
matches our calculations exactly!
While this is an important process
to know about, you can also
configure an interface’s link-local
address with the ipv6 address
command:

V6ROUTER1(config-if)#ipv6 addr
WORD

General

X:X:X:X::X

IPv6 lin

X:X:X:X::X/<0-128>

IPv6 pre

autoconfig
autoconfiguration

Obtain a

Naturally, you have to abide by the
link-local address rules we talked
about earlier.

Using The EUI-64 Process With
The ipv6 Address Command
Earlier, we statically applied the
full IPv6 address to the
FastEthernet 0/0 interface, and
that’s one way to get that address on
the interface.
However, if you just want the
address to be unique and you don’t
need to assign a certain specific
address to the interface, you can use
the eui-64 option with the ipv6
address command to come up with
a unique address.
I’ll use that option on the live
equipment, after first removing the

full address we applied earlier.

V6ROUTER1(config)#int fast 0/0

V6ROUTER1(config-if)#no ipv6 a
2001:1111:2222:1:1::/64

Enter the prefix and prefix length,
followed by eui-64.

V6ROUTER1(config-if)#ipv6 addr
?
anycast

Configure as an any

eui-64

Use eui-64 interfac

<cr>

V6ROUTER1(config-if)#ipv6 addr

eui-64

Verify the global unicast address
creation with show ip6 interface.

V6ROUTER1#show ipv6 int fast 0

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20C:31FF:FEEF:D240

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:20C:3
2001:1111:2222:1::/64 [EUI]

Note the global unicast address is

now the prefix followed by the linklocal address. The result is a unique
address that was calculated in part
by the router, and not totally
configured by us.
Would you believe there’s a third
way for that interface to get its
address? Since the first two
methods have been static
configurations, I bet you think this
one’s dynamic. Let’s use IOS Help
to see that one…

V6ROUTER1(config)#int fast 0/0
V6ROUTER1(config-if)#ipv6 addr
WORD
General
X:X:X:X::X
IPv6 lin

X:X:X:X::X/<0-128>
IPv6 pr
autoconfig
Obtain ad
autoconfiguration

Sounds kinda dynamic! More about
autoconfiguration later – right now,
let’s talk about the IPv6 equivalent
of IPv4’s Address Resolution
Protocol!

The Neighbor Discovery Protocol
NDP allows an IPv6 host to
discover its neighbors – but you
already knew that just by reading
the protocol name. The “neighbors”
we’re talking about here are other
hosts and routers, and the processes
for discovering the routers
isdifferent than the host-discovery
process. Let’s start with finding our
routers!
To start the router discovery
process, the host sends a Router
Solicitation multicast onto its local
link. The destination is FF02::2, the
“All-IPv6-Routers” address. The

primary value the host wants is the
router’s link-local address.

Any router on the link that hears that
message will respond with a Router
Advertisement packet. That
advertisement can have one of two
destination addresses
If the querying host has an

IPv6 address that would have
been in the RS message, and
the router will unicast its RA
back to that address.
If the querying host does not
yet have an IPv6 address, the
source message of the RS
will be all zeroes, and in that
case the router will multicast
the RA to FF02::1, the “All
IPv6 Nodes” address.

IPv6 routers don’t just sit around
and wait to be asked for that info;
on occasion, they’ll multicast it
onto the link without receiving an
RS. By default, the RA is multicast
to FF02::1 every 200 seconds.

Now that we’re successfully
discovering routers, let’s start
discovering neighbors, with the
aptly-named Neighbor Solicitation

and Neighbor Advertisement
messages!
The Neighbor Solicitation message
is the rough equivalent of IPv4’s
ARP Request. The main difference
is that an ARP Request asked for
the MAC address of the device at a
particular IPv4 address….

… and a Neighbor Solicitation
message asks neighbors found in the
solicited-node multicast address

range of the destination IPv6
address to reply with their linklayer addresses.

This leads us to the musical
question “What the $&%*)%*)*$
is a solicited-node multicast
address?”
Welllll, this isn’t exactly one of
those “the name is the recipe”

protocols we’ve seen in this course,
so let’s take a few minutes to
examine this address and figure out
exactly what the “range” is.

The Solicited-Node Multicast
Address
“Dying is easy. Comedy is hard.”
-- Edmund Kean
“Determining the solicited-note
multicast address for a given IPv6
address is easy. Figuring out what
the heck a ’solicited-node multicast
address’ is – now THAT’S hard.”
-- Chris Bryant
I doubt my quote goes down in
posterity, but it really does apply to
this little section of our studies.
Here’s the deal with this address. It

is a multicast that goes to other
hosts on the local link, but not to all
hosts on the local link -- just the
ones that have the same last six hex
values as the destination IPv6
address of the message..
I kid you not – that’s what it is!
This wasn’t developed just to be
funny or to help create tricky exam
questions. There are IPv6 services
that rely on this address, and you’ll
see those in future studies. For right
now, we need to know what this
address is (covered) and how to
determine the solicited-node
multicast address for a given IPv6

address (coming right up!)
This address is actually in the
output of show ipv6 interface, but
we better know where and how it
was calculated, since neither is
very obvious. I’ve left in a little
more info in this command output
than I have in the past – there’s a
big hint as to where to find the
solicited-node multicast address.
V6ROUTER1#show ipv6 interface

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20C:31FF:FEEF:D240

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:20C:31FF:
2001:1111:2222:1::/64 [EUI]
Joined group address(es):
FF02::1
FF02::2
FF02::1:FFEF:D240

Under “joined group address(es)”,
you see three different addresses.
The first two, FF02::1 and FF02::2,
we saw earlier in this section. The
third, FF02::1:FFEF:D240, is the

solicited-node multicast address for
the local host.
Solicited note addresses always
begin with FF02::1:FF. To get the
rest, just grab the last six digits of
the global unicast address, and tack
it right on the end of the multicast
address.
V6ROUTER1#show ipv6 interface

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20C:31FF:FEEF:D240

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:20C:31FF:
2001:1111:2222:1::/64 [EUI]
Joined group address(es):
FF02::1
FF02::2
FF02::1:FFEF:D240

That’s it!
Now back to our Neighbor
Solicitations and Advertisements!
When last we left our IPv6 host,
now named “Host A”, it was
sending a Neighbor Solicitation to

the solicited-note multicast address
that corresponds with the IPv6
address of the destination host,
“Host B”.

You can see how this cuts down on
overhead when compared to IPv4’s
ARP. This initial request for
information is a multicast that’s
going to be processed by a very few
hosts on the link, where an IPv4

ARP Request was a broadcast that
every host on the link had to stop
and take a look at.
After all that, it’s time for a
Neighbor Advertisement! Host B
answers the NS with an NA, and
that NA contains Host B’s linklocal address. Host A pops that
address into its Neighbor
Discovery Protocol neighbor table
(the equivalent of IPv4’s ARP
cache), and we’re done!

DHCP In IPv6
DHCP is one of the most useful
protocols we’ll ever use, so IPv6
certainly wasn’t going to eliminate
it – but just as we can always get
better, so can protocols. Let’s jump
into DHCP for IPv6, starting with a
comparison of Stateful DHCP and
Stateless DHCP.
Stateless DHCP works a lot like the
DHCP we’ve come to know and
love in our IPv4 networks. See if
this story sounds familiar:
“A host sends a DHCP
message, hoping to hear back

from a DHCP server. The
server will give the host a
little initial information, and
after another exchange of
packets, the host is good to
go with its IP address it
accepted from the client. That
address is good for the
duration of the lease, as
defined by the server.
There are four overall
messages in the entire DHCP
process, two sent by the
client and two by the server.
The location of the DNS
servers is also given to the

client.
The server keeps a database
of information on clients that
accept the IP addresses that it
offers.
A problem comes in when
there’s a router in between
our host and DHCP server. In
that case, we need the router
to act as a relay agent. “
Those paragraphs describe both
DHCPv4 and Stateful DHCPv6.
There are some differences, of
course:

The DHCPv6 messages Solicit,
Advertise, Request, and Reply take
the place of DHCPv4’s Discovery,
Offer, Request, Acknowledgement
messages.
Note that while DHCPv6 lets the
client know where the DNS servers
are, just like DHCPv4 does,
DHCPv6 does not include default
router information as DHCPv4
does. The host will get that
information from NDP.
Overall, the DHCPv6 Relay Agent
operation is just like that of
DHCPv4. There are obviously
some different messages and

addresses involved, but this
illustration of a typical Relay Agent
operation will show you how
similar the two are.

That Solicit message is link-local in
scope, so if there’s a router
between the host and the DHCP
server, we have to configure the
router as a relay agent. We do that

by configuring the ipv6 dhcp relay
command on the interface that will
be receiving the DHCP packets that
need to be relayed.

V6ROUTER1(config)#int fast 0/0
V6ROUTER1(config-if)#ipv6 dhcp
client Act as an IPv6 DHCP
relay Act as an IPv6 DHCP
server Act as an IPv6 DHCP

V6ROUTER1(config-if)#ipv6 dhcp
destination Configure relay

V6ROUTER1(config-if)#ipv6 dhcp
X:X:X:X::X IPv6 address
V6ROUTER1(config-if)#$elay des
2001:1111:2222:1:20E:D7FF:FEA4

The dollar sign appears at the far
left of the input, since this command
is too long for the screen.
As a result of this command, the
router will relay the DHCP Solicit
to the destination we specify. When
the router sees return messages
from the DHCP server, the router
will relay those messages to Host
A.
Verify the router is a now a member
of the “All DHCP Servers and
Agents” multicast group with the
show ipv6 interface command. The
interface with the relay agent config
will show FF02::1:2 under “Joined

Group Address(es)”.

V6ROUTER1#show ipv6 int fast 0

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20C:31FF:FEEF:D240

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:20C:31FF:
2001:1111:2222:1::/64 [EUI]
Joined group address(es):
FF02::1
FF02::2

FF02::1:2
FF02::1:FFEF:D240

Now let’s have a look at Stateless
Autoconfiguration!
Where Stateful Autoconfiguration
has a lot in common with DHCPv4,
Stateless is a whole new world.
We have hosts that create their
own IPv6 addresses!
That process starts with some info
the host received from the router
way back during those Router
Solicitation and Router
Advertisement messages. We

discussed a little of that info at that
time, but here’s some more detail
on what the RA contains – and one
important value it does NOT
contain.

Among the information contained in
that RA sent to the host is the link’s
prefix and prefix length, and that

info allows the host to get started on
creating its own IP address. All the
host has to do is tack its 64-bit
interface identifier onto the back of
the 64-bit prefix, and voila …. A
128-bit IPv6 address!
There’s a very good chance this
address will be unique on the local
link, but we don’t want to leave that
kind of thing to chance. Instead, that
local host will perform the
Duplicate Address Detection
procedure before using this newly
created IPv6 address.

A True DAD Lecture
When I give a quick reminder about
acting responsibly in the field –
using the remark option with your
ACLs, running undebug all before
you leave a client site, that kind of
thing – I usually refer to it as a “dad
lecture”.
What follows here is a real DAD
lecture – the Duplicate Address
Detection procedure, that is!
It’s also a quick lecture, because
DAD is a very quick process.
Basically, DAD is the host
attempting to talk to itself, and if the
host succeeds in doing so, there’s a

duplicate address problem.
To perform DAD, the host just
sends a Neighbor Solicitation
message to its own address.

Then one of two things will happen:
The host that sent the NS
receives a Neighbor
Advertisement (NA), which
means another host on the

link is already using that
address, and the host that
wanted to use it can’t do so.
The host that sent the NS
doesn’t hear anything back,
so it’s okay for that host to
use its new address.
And that’s it! DAD is just a quick,
handy little check the interface runs
when it’s about to use an IPv6
unicast address for the first time, or
when an interface that already had
an IPv6 address in use is brought
down and then back up for any
reason. This little double-check can
spare you some big headaches!

So What About DNS?
In short, we’ve got to have a DHCP
server to get the DNS server info to
the hosts. Even though Stateless
Autoconfiguration doesn’t eliminate
the need for a DHCP server, it
comes very close, and there’s lot
less to configure, verify, and
maintain when the only thing our
DHCP servers are responsible for
is getting out the word about the
DNS server locations.
RFC 6106 lists RA options for
DNS information. That doc is
beyond the scope of the CCENT
and CCNA exams, but it is worth

noting that they’re working on ways
to get DNS information to the hosts
without using a DHCP server.
tools.ietf.org/html/rfc6106

Pining for Pinging
Pings and traceroutes work much
the same in IPv6 and IPv4. We just
have to be aware of a small
difference or two.
Here are the current addresses of
R1 and R3, along with a handy little
reminder of a handy little command:
R1:
V6ROUTER1#show ipv6 interface

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20C:31FF:FEEF:D240

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:20C:31FF:
2001:1111:2222:1::/64 [EUI]

R3:
V6ROUTER3#show ipv6 interface

FastEthernet0/0 is up, line pr
IPv6 is enabled, link-local
FE80::20E:D7FF:FEA4:F4A0

No Virtual link-local addres
Global unicast address(es):

2001:1111:2222:1:20E:D7FF

2001:1111:2222:1::/64 [EUI]

Let’s send a ping between R1 and
R3.
We can use the good ol’ fashioned
ping command….

V6ROUTER1#ping 2001:1111:2222:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
2001:1111:2222:1:20E:D7FF:FEA4
seconds:
!!!!!

Success rate is 100 percent (5

min/avg/max = 0/0/4 ms

… or the extended command, usi
V6ROUTER1#ping
Protocol [ip]: ipv6

Target IPv6 address:
2001:1111:2222:1:20e:d7ff:fea4
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands? [no]:
Sweep range of sizes? [no]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
2001:1111:2222:1:20E:D7FF:FEA4
seconds:
!!!!!

Success rate is 100 percent (5
min/avg/max = 0/0/4 ms

Traceroute works just as it did for
v4. Granted, there’s not much of a
path with this setup, but as your v6
networks grow, so will your
traceroute output. The escape
sequence is the same, too – the only
thing that changes is the format of
the address you enter.

Believe me, you’ll be using ping a
lot more than traceroute as you
learn IPv6!

V6ROUTER1#traceroute
2001:1111:2222:1:20e:d7ff:fea4

Type escape sequence to abort.

Tracing the route to
2001:1111:2222:1:20E:D7FF:FEA4

1 2001:1111:2222:1:20E:D7FF:F
msec

I don’t want to overwhelm you with
show ip v6 commands, since there
are quite a few in the IOS (about 40

of them when I looked today), but
there is one more I want to
introduce youto in this course –
show ipv6 neighbors.
You can look at all of your router’s
neighbors, or you can identify the
local router’s interface to filter the
output.
V6ROUTER1#show ipv6 neighbors
IPv6 Address
State Interface
FE80::20E:D7FF:FEA4:F4A0
000e.d7a4.f4a0 STALE Fa0/0

2001:1111:2222:1:20E:D7FF:FEA4

000e.d7a4.f4a0 STALE Fa0/0
Going from left to right---

The IPv6 address field is cert

Age refers to the last time in
was reachable. Static entries
hyphen.
Link-layer is the MAC address
State is way beyond the scope
exams, but if you want to dig
descriptions here:

http://www.cisco.com/en/US/docs/io
xml/ios/ipv6/command/ipv6s4.html#wp1680937550

Interface refers to the local
interface through which the
neighbor is reached.
Speaking of “local”, let’s spend a
little time with our IPv6 route types
and protocols.
With both IPv4 and v6, there are no
routes in the routing table by
default. With IPv4, after we put IP
addresses on the interfaces and then
open them, we expect to see only
connected routes. With IPv6, we’re
going to see connected routes and a
new route type, the local route.
For clarity, I’m going to delete the

route codes from the table unless
we’re actually talking about that
route type.
V6ROUTER1#show ipv6 route

IPv6 Routing Table - 3 entries

Codes: C - Connected, L - Loca
C

2001:1111:2222:1::/64 [0/0]
via ::, FastEthernet0/0

L

2001:1111:2222:1:20C:31FF:F
via ::, FastEthernet0/0

L

FF00::/8 [0/0]

via ::, Null0

We expect to see the connected
route, but that local route’s a new
one on us. The IPv6 router will not
only put a connected route into the
table in accordance with the subnet
configured on the local interfaces,
but will also put a host route into
the table for that route. In this case,
it’s R3’s interface on that same Fast
Ethernet segment.

Static and Default Routing
Just as with ping and traceroute,
both static and default static routing
work under the same basic
principles in IPv6 as they did in
IPv4. We just have to get used to a
slightly different syntax!
In this lab, we’ll set up connectivity
between R1 and a loopback on R3
with a regular static route, then with
a default static route.
It won’t surprise you to learn that
we create both of these route types
with the ipv6 route command,
followed by some old friends as
options!

V6ROUTER1(config)#ipv6 route 2
Dialer

Dialer interfa

FastEthernet
Loopback

FastEthernet I
Loopback inter

MFR

Multilink Fram

Multilink

Multilink-grou

Null

Null interface

Port-channel

Ethernet Chann

Serial

Serial

X:X:X:X::X

IPv6 address o

I removed some of the available

interface types for clarity, but yes,
we have much the same choices
with IPv6 as we did with IPv4 – the
local exit interface or the IP address
of the next hop!
I personally like to use the next-hop
address, since it’s easier to
troubleshoot in case of trouble, but
you can use either. Just as with
IPv4, make sure to choose the local
router exit interface or the next-hop
address.
Here, I used R3’s fastethernet0/0 IP
address as the next-hop address,
and that command is so long that it
brought up the dollar sign in the

prompt.
Hint: You can always run show ipv6
neighbors to grab the next-hop
address via copy and paste rather
than typing it in.
V6ROUTER1#show ipv6 neighbors
IPv6 Address
Addr State Interface

Ag

FE80::20E:D7FF:FEA4:F4A0
000e.d7a4.f4a0 STALE Fa0/0

5

2001:1111:2222:1:20E:D7FF:FEA4
000e.d7a4.f4a0

V6ROUTER1(config)#$2001:2222:3
2001:1111:2222:1:20E:D7FF:FEA4

Full command from config:

ipv6 route 2001:2222:3333:1::/64
2001:1111:2222:1:20E:D7FF:FEA4:
Let’s send a ping from R1 to R3’s
loopback….

V6ROUTER1#ping 2001:2222:3333:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
2001:2222:3333:1:20E:D7FF:FEA4
seconds:
!!!!!

Success rate is 100 percent (5
min/avg/max = 0/1/4 ms

Success, indeed!
Let’s run the exact same lab but
with a default static route. First,
we’ll remove the previous route by
using our up arrow and then ctrl-a
to go to front of the lonnnng
command, and enter the word “no”:

V6ROUTER1(config)#no ipv6 rout
2001:1111:2222:1:20E:D7F$

Then we’ll enter a default route,
IPv6 style:

V6ROUTER1(config)#ipv6 route :
2001:1111:2222:1:20E:D7FF:FEA4

That’s right -- ::/0 plus the local
router exit interface or next-hop
IPv6 address is all you need!
We’ll verify with ping:

V6ROUTER1#ping 2001:2222:3333:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
2001:2222:3333:1:20E:D7FF:FEA4
!!!!!

Success rate is 100 percent (5
min/avg/max = 0/1/4 ms

Ta da!

When checking your V6 routing
table, be sure to give it a twiceover – it’s really easy to scan right
past the routing table entry for the
default static route.
V6ROUTER1#show ipv6 route

IPv6 Routing Table - 4 entries

Codes: C - Connected, L - Loca
S

::/0 [1/0]

via 2001:1111:2222:1:20E:D7
C

2001:1111:2222:1::/64 [0/0]
via ::, FastEthernet0/0

L

2001:1111:2222:1:20C:31FF:F
via ::, FastEthernet0/0

L

FF00::/8 [0/0]
via ::, Null0

OSPF For IPv6 (AKA the
confusingly-named “OSPF
Version 3”
First things first: OSPF for IPv6 is
the same thing as “OSPF Version
3”. The OSPF for IPv4 we’ve all
come to know and love is “OSPF
Version 2”. You rarely see
“OSPFv2” used anywhere, so if you
see the simple letters “OSPF”,
we’re talking about the version for
IPv4.
Let’s take a look at some basic
OSPFv3 commands and compare
OSPF v3 to IPv4’s OSPF v2.
In IPv6, you’re not going to start an

OSPF configuration with router
ospf. One major difference between
the OSPF v2 and OSPF v3 is that
while OSPF v2 is enabled globally,
OSPF v3 is enabled on a perinterface basis. This will
automatically create a routing
process.

R1 (config-if) #ipv6 ospf area

One similarity between the two
versions is their use of the OSPF
RID. OSPF v3 is going to use the
exact same set of rules to determine
the local routers RID - and OSPF
v3 is going to use an IPv4 address

as the RID!
If there is no IPv4 address
configured on the router, you’ll
need to use our old friend router-id
to create the RID. The RID must be
entered in IPv4 format, even if
you’re only running IPv6 on the
router.
R1 (config-router) #router-id

Other similarities and differences
between OSPF v2 and v3:
They both use the same
overall terms and concepts
when it comes to areas,

LSAs, and the OSPF metric
cost.
Values such as the hello and
dead time must be agreed
upon for an adjacency to
form, and for that adjacency
to remain in place.
The SPF algorithm is used by
both versions, and dynamic
neighbor discovery is
supported by both.

One big difference – OSPFv3
routers do not have to agree
on the prefix length.
OSPF v3 point-to-point and
point-to-multipoint
configurations do not elect
DRs and BDRs, just like IP
v4.
OSPF v3 headers are smaller
than v2, since v3 headers
have no authentication fields.
The OSPF v2 reserved
address 224.0.0.5 is

represented in OSPF v3 by
FF02::5.
The OSPF v2 reserved
address 224.0.0.6 is
represented in OSPF v3 by
FF02::6.

A Sample OSPFv3 Configuration
As always, we need the ipv6
unicast-routing command to do
anything IPv6-related. We also need
the ipv6 router ospf 1 command
enabled globally.

V6ROUTER1 (config) #ipv6 unica

V6ROUTER1 (config) #ipv6 route

Eigrp Enhanced Interior Gate
(EIGRP)
Ospf

Open Shortest Path F

Rip

IPv6 Routing Informa

V6ROUTER1 (config) #ipv6 route
<1-65535> Process ID

V6ROUTER1 (config) #ipv6 route
V6ROUTER1 (config-rtr) #

*Nov 5 18:43:56.600: %OSPFv3-4
1 could not pick a router-id,

We never like to start a new config
with a notification from the router,
but this one’s easily resolved.
One oddity of OSPFv3 is that you
have to have an IPv4 dotted
decimal value for the router to use
as its OSPF RID – and if you have

no IPv4 addresses on the router, you
must set a RID with the router-id
command before you can even start
your config!
Crazy, I know, but true, as verified
by that console message! Let’s set a
RID of 1.1.1.1 on R1 and verify
with show ipv6 ospf.

V6ROUTER1 (config) #ipv6 route
V6ROUTER1 (config-rtr) #

*Nov 5 18:43:56.600: %OSPFv3-4
1 could not pick a router-id,

V6ROUTER1 (config-rtr) #router

V6ROUTER1#show ipv6 ospf

Routing Process “ospfv3 1” with
ID 1.1.1.1
Watch that “v6” in all of your
“show ospf” commands! Here’s the
R3 config:

V6ROUTER3 (config) #ipv6 route
V6ROUTER3 (config-rtr) #

*Nov 5 18:59:45.566: %OSPFv3-4
1 could not pick a router-id,

V6ROUTER3 (config-rtr) #router
V6ROUTER3#show ipv6 ospf

Routing Process “ospfv3 1” wi

Now we’ll put the Fast 0/0
interfaces on each router into Area
0. I’ll run IOS Help to show you
that quite a few options from
OSPFv2 are here in OSPFv3:

V6ROUTER1 (config) #int fast 0

V6ROUTER1 (config-if) #ipv6 os
<1-65535>

Process ID

Authentication

Enab

cost

Cost

database-filter
Filt
synchronization and flooding
dead-interval
is declared dead

Inter

demand-circuit

OSPF

encryption

Enabl

flood-reduction

OSPF

hello-interval

Time

mtu-ignore

Ignor

neighbor

OSPF

network

Netwo

priority

Route

retransmit-interval
link state

Time

adver

transmit-delay
Link
V6ROUTER1(config-if)#ipv6 ospf

area Set the OSPF area I

V6ROUTER1(config-if)#ipv6 ospf

<0-4294967295> OSPF area ID as
A.B.C.D

OSPF area ID in IP

V6ROUTER1(config-if)#ipv6 ospf

R3:
ROUTER3(config)#int fast 0/0

V6ROUTER3(config-if)#ipv6 ospf
V6ROUTER3(config-if)#^Z
V6ROUTER3#

*Nov 5 19:03:45.986: %OSPFv3-5
1.1.1.1 on FastEthernet0/0 fro
Loading Done

Seconds after finishing the config
on R3, our adjacency is in place!
We’ll verify with show ipv6 ospf
neighbor, and you’ll see that much
of the info from show ip ospf

neighbor in IPv4 made the cut to
IPv6!
V6ROUTER1#show

ipv6

Neighbor ID
Pri
Int ID
Interface
3.3.3.3
4

ospf

State

1 FULL/BDR
FastEthernet0

Now let’s add R3’s loopback
interface to the OSPF config by
putting it into Area 1, and then
check R1’s IPv6 routing table. I’ll
leave the OSPF routes in the routing
table this time.

V6ROUTER3(config)#int loopback
V6ROUTER3(config-if)#ipv6 ospf

V6ROUTER1#show ipv6 route

IPv6 Routing Table - 4 entries

Codes: C - Connected, L - Loca

O - OSPF intra, OI - O
1, OE2 - OSPF ext

ON1 - OSPF NSSA ext 1, O
C

2001:1111:2222:1::/64 [0/0
via ::, FastEthernet0/0

L

2001:1111:2222:1:20C:31FF:

via ::, FastEthernet0/0

OI 2001:2222:3333:1:20E:D7FF:F
via FE80::20E:D7FF:FEA4:F4A
L

FF00::/8 [0/0]
via ::, Null0

We have our first inter-area route,
and with a familiar pair of values in
the brackets for that route!
Let’s ping the loopback from R1….

V6ROUTER1#ping 2001:2222:3333:
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos
2001:2222:3333:1:20E:D7FF:FEA4

seconds:
!!!!!

Success rate is 100 percent (5
min/avg/max = 0/2/4 ms

… and we’re done!
When it comes to verifying and
troubleshooting your OSPFv3
configs, you can almost always just
put in “ipv6” for “ip” in your
OSPFv2 show ip ospf commands
and get the same information.
You’ve already seen a few of these,
and it can only help to see them
again:

show ipv6 route ospf will show you
only your OSPF-discovered routes,
just like show ip route did for
OSPFv2.

V6ROUTER1#show ipv6 route ospf

IPv6 Routing Table - 4 entries

Codes: C - Connected, L - Loca

U - Per-user Static rou

I1 - ISIS L1, I2 - ISIS
IS - ISIS summary

O - OSPF intra, OI - OS
1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1,

OI

D - EIGRP, EX - EIGRP e
2001:2222:3333:1:20E:D7F

via FE80::20E:D7FF:FEA4:

Here’s another look at show ipv6
ospf neighbor.

V6ROUTER1#show ipv6 ospf neigh
Neighbor ID
Pri
Int ID
Interface
3.3.3.3
Fast 0/0

1

State

FULL/BDR

One of my favorite troubleshooting

D

commands, show protocols, got
quite the overhaul with IPv6.
Here’s the output of that command
at the end of that last lab.

V6ROUTER1#show ipv6 protocols
IPv6 Routing Protocol is “conn
IPv6 Routing Protocol is “stat
IPv6 Routing Protocol is “ospf
Interfaces (Area 0):
FastEthernet0/0
Redistribution:
None

Let’s wrap up with your first
OSPFv3 debug!
To spot mismatch problems with

hello and dead timers, run debug
ipv6 ospf hello. I created one
before running this debug so you
could see the output when there’s a
problem – and after our earlier
OSPF section, this output should
look familiar!

V6ROUTER1#debug ipv6 ospf hell

OSPFv3 hello events debuggin
V6ROUTER1#

*Nov 5 19:37:09.454: OSPFv3: R
area 0 from FastEthernet0/0 FE
7FF:FEA4:F4A0 interface ID 4

*Nov 5 19:37:09.458: OSPFv3: M
parameters from FE80::20E:D7FF

*Nov 5 19:37:09.458: OSPFv3: D
11 C 25

We’re going to stop here with your
IPv6 studies – for now!
One final word on this subject…
Please make IP Version 6 part of
your future studies. Understanding
IPv6 is going to be a major boost to
your career and your future.
Notice that I didn’t say “might be a
major boost”.

Let’s move forward and visit a
couple of new friends that might
just feel ignored at this point in the
course!

NAT and PAT
NAT allows a network host with a
private IP address to have the
source IP address of their packets
“translated” into a routable address.
Otherwise, hosts with RFC 1918
private addresses could not access
the Internet, nor could they
communicate with remote hosts
across a WAN. Without NAT or
PAT, the host in the following
example cannot access any webbased hosts.

The private IP address ranges are
defined by RFC 1918, and they fall
into these ranges:
Class A: 10.0.0.0 /8
Class B: 172.16.0.0 /12
Class C: 192.168.0.0 /16

Note that the masks that accompany
these private address ranges are not
the network masks for the full
classes (/8, /16, /24).
There are four terms used to
describe these addresses at
different points in the entire NAT
process. They’re close to each
other in wording, but not in
meaning, so let’s take a close look
at these addresses.
Inside local addresses are used by
hosts on the inside network to
communicate with other hosts on
that same network. These are the
addresses that are actually

configured on the hosts. In the
earlier diagram, the inside local
address is 10.1.1.1 /16.
These inside local addresses are
translated into inside global
addresses. Inside global addresses
are routable addresses. In the
previous illustration, we haven’t
configured NAT yet, so there is no
inside global address.
Outside global addresses are the
addresses assigned by NAT on a
remote network.
Finally, outside local addresses are
the actual addresses of hosts on the
remote network. These are also

RFC 1918 private addresses.
The terms “inside” and “outside”
are relative - if they’re addresses
on your end of the WAN, they’re
inside. If they’re addresses on the
remote end of the WAN, they’re
outside.
In the following example, 10.1.1.1
is the inside local address and
150.1.1.1 is the inside global
address.

The destination host never sees the
private address, only the public
one.
From the destination’s point of
view, 10.1.1.1 is the outside local
address and 150.1.1.1 is the outside
global address. It’s all about the
vantage point when it comes to
these address types!
When the packet returns, the NAT
router will remove the public IP
address, replace it with the
appropriate private IP address, and

the packet is sent to the host. The
private address is never seen on the
Internet, and the originating host
doesn’t know that anything
happened. The only device in the
entire process that even knows
address translation occurred is the
NAT router.
We have two “flavors” of NAT static and dynamic. While you’re
much more likely to run into
dynamic NAT configuration in the
real world, there are static NAT
configs out there.

Static NAT
If a limited number of hosts on a
private network need Internet
access, static NAT may be the
appropriate choice. Static NAT
maps a private address directly to a
public, routable address. Static
NAT could be helpful in a network
such as the following:

We have three hosts on the Class A
RFC 1918 private address range.
The router’s Ethernet0 interface is
connected to this network, and the
Internet is reachable via the Serial0
interface. The IP address of the
Serial network is 210.1.1.1 /24,
with all other addresses on the
210.1.1.0/24 network available in
this example.
With Static NAT, we’ll need to
create three separate mappings.
That’s the easy part to remember.
You’ll hear me say this several
times before the end of this section,

but the #1 error made in NAT and
PAT configurations is forgetting to
use the ip nat inside and ip nat
outside commands on the
appropriate interfaces!
The ip nat inside command should
be configured on the interface(s)
that face the inside hosts, and the ip
nat outside command should be
configured on the interface facing
the Internet.

R3(config)#interface ethernet0
R3(config-if)#ip address 10.5.
R3(config-if)#ip nat inside
R3(config-if)#interface serial
R3(config-if)#ip address 210.1
R3(config-if)#ip nat outside

R3(config)#ip nat inside sourc
210.1.1.2
R3(config)#ip nat inside sourc
210.1.1.3
R3(config)#ip nat inside sourc
210.1.1.4

Earlier, you may have wondered
how the NAT router knew when
translations needed to be made for
incoming packets. The router
checks its NAT translation table for
that information.

R3#show ip nat translations
Inside global
Inside local
Outside global --210.1.1.2
10.5.5.5

-------

210.1.1.3
210.1.1.4

10.5.5.6
10.5.5.7

10.5.5.5 is mapped to the routable
address 210.1.1.2, just as we
configured it with the ip nat inside
source command. The other two
mappings are there exactly as we
configured them.
There is no pool of addresses
involved with static NAT, so the
same inside global address will be
mapped to the same inside local
address every time.
You can see the number of active
translations, along with the location

of the ip nat inside and ip nat
outside commands, with show ip
nat statistics. Note the active
translations are all static, as we’d
expect when using static NAT.

R3#show ip nat statistics
Total active translations: 3 (
extended)
Outside interfaces: Serial0
Inside interfaces: Ethernet0 H
Expired translations: 0

Dynamic NAT
The obvious problem with Static
NAT is a lack of scalability. If you
have only a few hosts that need
Internet access, it’s fine, but most
organizations have a LOT of hosts
that need that access. In today’s
world of web-based apps and The
Almighty Cloud, it’s not practical to
have just a few hosts on the ’Net.
Dynamic NAT allows a pool of
inside global addresses to be
created. The public IP addresses
are mapped to a private address on
an as-needed basis, and the
mapping is dropped when the

communication ends. There’s no
permanent one-to-one mapping as
we saw with Static NAT.
Like Static NAT, Dynamic NAT
requires the interfaces connected to
the Internet and the private
networks be configured with ip nat
outside and ip nat inside,
respectively.
Using the previous network
example, R3 is now configured to
assign an address from a NAT pool
to these three network hosts on an
as-needed basis.
R3#conf t

R3(config)#access-list 1 permi

R3#conf t
R3(config)#interface ethernet0
R3(config-if)#ip nat inside
R3(config-if)#interface serial
R3(config-if)#ip nat outside

R3#conf t
R3(config)#ip nat inside sourc
R3(config)#ip nat pool NATPOOL

Another use for ACLs! An accesslist is used to identify the hosts that
will have their addresses translated
by NAT. This ACL allows any host
using an IP address to use NAT if
the first three octets of the host’s IP

address are 10.5.5.
The nat inside source command
calls that list and then names the
NAT pool to be used.
The next line of the config defines
the pool, which I’ve named
NATPOOL.
The two addresses listed are the
first and last addresses of the pool,
meaning that 200.1.1.2, 200.1.1.3,
200.1.1.4, and 200.1.1.5 are in the
pool, all using a mask of
255.255.255.0.
Take care not to include the serial
address of the NAT router in the

pool.
The access list permits all hosts on
10.5.5.0/24, meaning that any host
on that subnet can grab an IP
address from the NAT pool.
Show ip nat statistics will display
the name and configuration of the
NAT pool.

R3#show ip nat statistics
Total active translations: 0 (
Outside interfaces: Serial0 In
Hits: 0 Misses: 0
Expired translations: 0
Dynamic mappings: -- Inside So
access-list 1 pool

NATPOOL refcount 0 pool NATPO
end 200.1.1.5 type generic, t
allocated 0 (0%), misses 0

We have four addresses in the NAT
pool, and only three hosts that need
translation. No problem, right?
Right -- for now, anyway. Let me
introduce you to a phrase you’ll run
into over and over in CiscoLand:
“planning for future growth”.
Let’s say you were called to the
client site that had the very topology
we’ve been working with. They’re
fine with just those three hosts
having access to the Internet, so you

write the above configuration and
leave the site, knowing all is well.
Three months later, three more hosts
are added to that subnet.

The config that served us to
beautifully before is now going to
bite us in the tuckus:

R3(config)#access-list 1 permi
R3(config)#int e0
R3(config-if)#ip nat inside
R3(config-if)#int s0
R3(config-if)#ip nat outside

R3(config)#ip nat inside sourc
R3(config)#ip nat pool NATPOOL
netmask 255.255.255.0

With this configuration, any host on
the 10.5.5.0 /24 network can have
its address translated to a routable
address from that pool. That was
fine when we had only three hosts,
but now we have six hosts and only
four addresses in the pool. That’s
an overcrowded pool area!

The eventual phone call from the
client will be something like this:
Everything was fine, but now some
people can get to the Internet and
some can’t. And we never know
who can and who can’t!”
The client is right, even if he
doesn’t know why. The first four
hosts to request a routable address
for that pool will get one, and the
others are out of luck. They’ll be
able to get one eventually when
another host’s NAT mapping ends,

but that’s still not going to make the
client happy.
If the client wants all of those hosts
to have Internet access, we have
two choices:
Add more routable addresses
to the pool
Configure Port Address
Translation
PAT is really the best solution,
since that will allow for even more
hosts to be added to that subnet in
the future without adding more

routable addresses to that pool. We
only need one routable address for
PAT - and it’s a routable address
already in use!
Let’s take a look at PAT, more
commonly referred to as
overloading.
The private address will be
translated to a single public address
and a random port number, allowing
the same IP address to support
multiple hosts. The router will keep
the connections separate by using a

different port number for each
translation, even though the same IP
address will be used.
Port Address Translation is simple
to configure. Instead of referring to
a NAT pool with the ip nat inside
source command, refer to the
outside interface name followed by
the word overload.
R2(config)#int ethernet0
R2(config-if)#ip nat inside
R2(config-if)#int serial0
R2(config-if)#ip nat outside

R2(config)#ip nat inside sourc

serial0 overload
R2(config)#access-list 1 permi

overload indicates the IP address of
the named interface will be the only
one used for NAT. A different port
number will be used for each
translation. That allows the router
to keep the different translations
separate while using only a single
IP address.
Each host that matches the ACL will
have its private IP address
translated to the same routable IP
address - in this case, the same IP

address the serial interface is
already using - but each host will
be assigned a random port number.

These ports will not be from the
well-known port number range. The
NAT translation table will keep
track of the port number mappings,

so as packets come in with
210.1.1.1 as the destination, the
router will translate the 210.1.1.1:
< port number> address back to the
appropriate host IP address. As
with both versions of NAT, the
entire process is transparent to the
hosts.

Static, Dynamic, and PAT Labs
Let’s do some quick labs and take a
look at the translation table along
the way. First, we’ll use Static NAT
to translate packets from R4’s
address of 10.1.1.4 to 172.12.123.4
on R3, our NAT router.
R3 config:

R3(config)#ip nat inside sourc
172.12.123.4
R3(config)#int s0
R3(config-if)#ip nat outside
R3(config-if)#int e0
R3(config-if)#ip nat inside

A default static route has been
configured on R4.
After sending a ping from R4 to R1,
let’s have a look at R3’s NAT
translation and statistics tables.

R3#show ip nat translations
Inside global
Inside loca
Outside global
--- 172.12.123.4
10.1.1.
---

R3#show ip nat stat
Total active translations: 1 (
Outside interfaces:
Serial0

Inside interfaces:
Ethernet0
Hits: 2 Misses: 0
Expired translations: 0
Dynamic mappings:

Nothing to it! I’ll remove the static
NAT statement, leave the interface
NAT commands on, and we’ll get a
dynamic NAT config rolling.

R3(config)#no ip nat inside so
172.12.123.4

The dynamic NAT config includes
an ACL that identifies the inside
hosts that will have their addresses
translated by NAT. I’ll use IOS

Help throughout the ip nat inside
source command to remind you of
the options.

R3(config)#access-list 5 permi
R3(config)#
R3(config)#ip nat inside sourc
list
Specify access li
addresses
route-map Specify route-map
static
Specify static lo

R3(config)#ip nat inside sourc
<1-199> Access list number fo
WORD
Access list name fo

R3(config)#ip nat inside sourc
interface Specify interface

pool

Name pool of glob

R3(config)#ip nat inside sourc
WORD Pool name for global a

R3(config)#ip nat inside sourc

Now to the pool!
R3(config)#ip nat pool ?
WORD Pool name

R3(config)#ip nat pool NATPOOL
A.B.C.D
Start IP addr
netmask
Specify the n
prefix-length Specify the p

R3(config)#ip nat pool NATPOOL
A.B.C.D End IP address

R3(config)#ip nat pool NATPOOL
172.12.123.10 ?
netmask
Specify the n
prefix-length Specify the p

R3(config)#ip nat pool NATPOOL
172.12.123.10 netmask ?
A.B.C.D Network mask

R3(config)#$NATPOOL 172.12.123
255.255.255.0

Here are those commands in all

their splendor:

access-list 5 permit 10.1.1.0
ip nat pool NATPOOL 172.12.123
255.255.255.0
ip nat inside source list 5 po

After sending some pings from R4
to translate, here’s the output of our
two show ip nat commands on R3:

R3#show ip nat stat
Total active translations: 1 (
extended)
Outside interfaces:
Serial0
Inside interfaces:
Ethernet0
Hits: 6 Misses: 0

Expired translations: 0
Dynamic mappings:
-- Inside Source
access-list 5 pool NATPOOL ref
pool NATPOOL: netmask 255.255
start 172.12.123.4 end
type generic, total ad
(14%), misses 0

R3#show ip nat trans
Inside global
Inside local
Outside global
--- 172.12.123.4
10.1.1.4
---

Finally, I’ll remove the ip nat
inside command from that lab and
add the line that enables PAT.

R3(config)#no ip nat inside so
R3(config)#ip nat inside sourc
serial0

Let’s see what happens when we
send a ping from R4 through PAT!
R3#show ip nat trans
Pro Inside global
icmp 172.12.123.3:6488
icmp 172.12.123.3:6489
icmp 172.12.123.3:6490
icmp 172.12.123.3:6491
icmp 172.12.123.3:6492

Inside local
10.1.1.4:6488
10.1.1.4:6489
10.1.1.4:6490
10.1.1.4:6491
10.1.1.4:6492

Five translations, each with a
different port number! Note the IP
addresses across the board are
exactly the same – it’s the ports that

are different.
Let’s leave NAT and PAT and head
for multilayer switching!

ROAS And L3
Switching
Waaaaaaaaay back in the Switching
section, I mentioned these two
methods of allowing inter-VLAN
communication, and I said we’d hit
’em after you’d been introduced to
routing.
You’ve had more than an
introduction by this time, so let’s
get to it!

We have two options for
configuring inter-VLAN
communication:
Using an L3 switch
Configuring “router on a
stick” (ROAS)
We’ll first go through an ROAS
configuration with the following
network, and then we’ll take a
detailed look at troubleshooting it.
This network’s IP addressing:
Host 2: 172.12.2.2, VLAN 2

Host 4: 172.12.4.4, VLAN 4
R6: 172.12.2.6 and
172.12.4.6 on Fast 0/0
subinterfaces 0/0.2 and 0/0.4,
respectively
We’ll use ISL as the trunking
protocol.
Once this config is up and running,
you can leave it alone for months or
years, but there are quite a few
details that we need to watch to get
it up and running!

Here’s the network:

A few important details to take note
of:
The switch ports connected
to the hosts are access ports.

The switch port connected to
the router must be trunking,
and the trunking protocol (ISL
or dot1q) must be the same
on the switch and the router
subinterfaces.
You have to hardcode the
trunking protocol on the
switch rather than leaving the
trunk port at “dynamic” or
“auto”, because Cisco routers
don’t negotiate trunking
protocols.

The router must use a
minimum of a Fast Ethernet
port for ROAS. A regular
Ethernet port will not get the
job done.
The Fast Ethernet interface on the
router will be using subinterfaces,
and we’ll use two commands on
each subinterface:
the encapsulation command,
matching the encap type set
on the connecting switch’s
trunk port

an appropriate IP address for
the VLAN indicated by the
encapsulation command
The IP address for a subinterface
must come from the address space
of the VLAN configured with the
encapsulation command on that
same subinterface. This interface
will be part of VLAN 2, so we have
to put an IP address from the
172.12.2.0 /24 subnet. Where did I
get that IP range? Check the IP
address of the host that’s already in
VLAN 2.
We’ll start with the IP address on
R6’s fast 0/0.2 subinterface.

R6(config)#int fast 0/0.2
R6(config-subif)#ip address 17

% Configuring IP routing on a
allowed if that subinterface i
part of an IEEE 802.10, IEEE 8

Then again, maybe we won’t start
with the IP address! This is one of
those rare situations where the
order of the commands does matter.
You have to enter the encapsulation
command before you apply the IP
address to the subinterface.

R6(config-subif)#encapsulation
R6(config-subif)#ip address 17

Done and done!

Now let’s configure a subinterface
to be part of VLAN 4. That
subinterface will need an IP
address from the 172.12.4.0 /24
subnet.

R6(config-subif)#int fast 0/0.
R6(config-subif)#encap isl 4
R6(config-subif)#ip address 17

When you’re done, don’t forget to
open the physical interface!

R6(config-subif)#int fast 0/0
R6(config-if)#no shut
%SYS-5-CONFIG_I: Configured fr
%LINK-3-UPDOWN: Interface Fast
state to up
%LINEPROTO-5-UPDOWN: Line prot
FastEthernet0/0, changed state

Verify with show interface.
R1#show interface fast 0/0.2

FastEthernet0/0.2 is up, line
Hardware is AmdFE, address i
000a.4164.31c1)
Internet address is 172.12.2
MTU 1500 bytes, BW 100000 Kb
usec,
reliability 255/255
1/255, rxload 1/255
Encapsulation ISL Virtual LA
ARP type: ARPA, ARP Timeout
Last clearing of “show inter

R1#show interface fast 0/0.4
FastEthernet0/0.4 is up, line
Hardware is AmdFE, address i
000a.4164.31c1)
Internet address is 172.12.4
MTU 1500 bytes, BW 100000
Kbit, DLY 100 usec,
reliability 255/255, txload
1/255, rxload 1/255

Encapsulation ISL Virtual
LAN, Color 4.
ARP type:
ARPA, ARP Timeout 04:00:00
Last clearing of “show inter

At this point, the default gateway on
the hosts must be set to the
appropriate subinterface IP address
on the router.
Do not use any IP address
configured on the switch. Always
use the appropriate IP address from
the router’s subinterfaces as the
default gateway for each host.

For our host in VLAN 2, that
address is the router subinterface’s
IP address in the VLAN 2 address
space, and for the VLAN 4 host it’s
the subinterface’s IP address in
VLAN 4.

From Host 4, let’s ping the
following addresses:
Host 4’s own default
gateway, 172.12.4.6
Host 2’s default gateway,
172.12.2.6
Host 2, 172.12.2.2
Host4#ping 172.12.4.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos

is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/3/4 ms
Host4#ping 172.12.2.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/2/4 ms
Host4#ping 172.12.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
is 2 seconds:
!!!!!
Success rate is 100 percent (5

min/avg/max = 1/3/4 ms

All three are successful! Let’s ping
the following three destinations
from Host 2:
Host 2’s own default
gateway, 172.12.2.6
Host 4’s default gateway,
172.12.4.6
Host 4, 172.12.4.4
Host2#ping 172.12.2.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/2/4 ms
Host2#ping 172.12.4.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/2/4 ms
Host2#ping 172.12.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos

is 2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/2/4 ms

If you have connectivity issues from
one host to another after configuring
ROAS, always ping your local
host’s default gateway first. If you
can’t ping that, there’s no way you
can ping the other two addresses!
That’s really all there is to ROAS.
Nail the details and you’re on your
way to exam and real-world
success!

Let’s review the ROAS details on
the router, switch, and hosts, and
we’ll follow that with some ROAS
troubleshooting tips.

The Router:

The port must be a Fast Ethernet
port at minimum. An Ethernet port
won’t do the job. You can create
Ethernet subinterfaces, but the
encapsulation command will not be
recognized.

R3(config)#interface e0.12
R3(config-subif)#encapsulation
% Unrecognized command

The trunking protocol configured on
the router’s subinterfaces must
match that of the trunk port
connected to that router. If we used

dot1q in this lab instead of ISL, the
commands used would have been
the same (except for the
encapsulation ISL command, of
course, which would be have been
encapsulation dot1q.)
The IP address configured on a
subinterface must be part of the
subnet used by the VLAN indicated
in the encapsulation command.

The Switch:

The switch port connected to the
router must be trunking.
The trunking protocol in use (ISL or
dot1q) must match the one on the
router’s subinterfaces.
The ports leading to the hosts must
be access ports.

The Hosts:

Each host should have its default
gateway set to the IP address on the
router subinterface that is part of
that VLAN’s address space.

ROAS FSuC (Frequently
Screwed-up Configurations)

I think you’ll agree with me that the
ROAS config is straightforward.
Since there’s not much to configure
in the first place, the
misconfiguration is pretty easy to
spot.
Since we perform most of the
ROAS config on the router, we tend
to concentrate on the router config
when we have a problem. What we
have to keep in mind with ROAS

troubleshooting is that the problem
might not be on the router - it might
be on the hosts, or even the switch!
Do you see a problem with the
following setup?

If you spotted that right away, nice
work! The default gateway settings
on the hosts are reversed. The
default gateway address must
always be in the same subnet as the
host’s IP address.
How about the following
configuration? See any problems
here?

R6 Config:
interface
FastEthernet0/0
no ip address
duplex auto
speed auto
!

interface FastEthernet0/0.2
encapsulation isl 4
ip address 172.12.2.6
255.255.255.0

!
interface FastEthernet0/0.4
encapsulation isl 2
ip address 172.12.4.6
255.255.255.0

An IP address from VLAN 2’s
subnet has been applied to the
subinterface with the VLAN 4 ID,
and vice versa. With that config,
neither host will even be able to

ping its own default gateway.
Use this structured approach to your
ROAS troubleshooting and you’ll tshoot it successfully every time:
Always check the default
gateway settings on the hosts
first.
Make sure the port leading to
the router is trunking, and
watch for trunking protocol
mismatches.

On the router, make sure the
IP address assigned to each
subinterface is from the
subnet assigned to the VLAN
that’s assigned to that
subinterface.
Follow those three tips and you’ll
configure and troubleshoot ROAS
successfully every time!

Multilayer Switching with L3
Switches
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.
Multilayer switches allow us to
create a logical interface, the

Switched Virtual Interface ( SVI),
as a representation of the VLAN.
An SVI exists for VLAN 1 by
default, but that’s the only VLAN
that has a “pre-created” SVI. BTW,
SVIs are informally referred to as
“VLAN Interfaces”, and here’s
why:
interface
vlan1
no ip
address
no ip routecache

shutdown

On a Layer 3 switch, such a logical
interface can be configured for any
VLAN, and you configure it just as
you would any other interface -just go into config mode, create the
interface and assign it an IP
address, and you’re on your way.
It’s very simple:
MLS(config)#interface vlan 10

MLS(config-if)#ip address 10.1

Let’s put SVIs to work with a basic
inter-VLAN routing configuration.

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.
HOST_1#ping 30.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
2 seconds:
.....
Success rate is 0 percent (0/5
HOST_3#ping 20.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
2 seconds:
.....
Success rate is 0 percent (0/5

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

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.

SW1(config)#int fast 0/1
SW1(config-if)#switchport mode
SW1(config-if)#switchport acce

SW1(config-if)#int fast 0/3
SW1(config-if)#switchport mode
SW1(config-if)#switchport acce

We’re going to create two SVIs on
the switch, one representing VLAN
11 and the other representing VLAN
33.

SW1(config)#int vlan11
01:30:04: %LINK-3-UPDOWN: Inte
state to up
01:30:05: %LINEPROTO-5-UPDOWN:
Interface Vlan11, changed stat
SW1(config-if)#ip address 20.1

SW1(config-if)#int vlan33
01:30:11: %LINK-3-UPDOWN: Inte
state to up
01:30:12: %LINEPROTO-5-UPDOWN:
Interface Vlan33, changed stat
SW1(config-if)#ip address 30.1

There’s a strict limit of one SVI per
VLAN.
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.

SW1#show int vlan11
Vlan11 is up, line protocol is
Hardware is EtherSVI, addres
0012.7f02.4b41)
Internet add

SW1#show int vlan33
Vlan33 is up, line protocol is
Hardware is EtherSVI, addres
0012.7f02.4b42)
Internet add

Now let’s check that routing table…
SW1# show ip route
Default gateway is not set
Host
Uses

Gateway
Interface

ICMP redirect cache is empty

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!

SW1(config)#ip routing
SW1(config)#^Z
SW1#show ip route
Codes: < removed for clarity >
Gateway of last resort is not

C
C

20.0.0.0/24
20.1.1.0
30.0.0.0/24
30.1.1.0

is
is
is
is

subnetted,
directly c
subnetted,
directly c

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 not, you ask? You recall that
when router-on-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.

HOST_1(config)#ip route 0.0.0.

HOST_3(config)#ip route 0.0.0.

Can the hosts now communicate,
even though they’re in different
VLANs?
HOST_1#ping 30.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/1/4 ms
HOST_3#ping 20.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
2 seconds:
!!!!!
Success rate is 100 percent (5
min/avg/max = 1/2/4 ms

Nothing beats a success rate of 100
percent!

A couple of final notes on L3
switching:
During the lab, we didn’t
have to do anything to the
SVIs to have them show as
up/up. On some Cisco switch
models, you may have to run
no shutdown on them to bring
them up.
On most L3 switches,
hardware support for routing
is already on, but you need to
use the ip routing command
to turn on software support.

On some L3 switches, you’ll
also need to manually enable
hardware support with the
sdm prefer lanbase-routing
command.
You’ll learn even more about L3
switch capabilities in your future
studies – a LOT more, but that’s it
for now.
PS – The following symbol is
sometimes used to represent an L3
switch. It might show up on your
exam or in documentation you’re

reading, so be ready to identify it!

Binary Math And
Subnetting Mastery
Get ready for total success with
binary math and subnetting practice
exam questions AND real-world
networking!
In the next few sections, every bit of
anxiety you may have about binary
or subnetting is going to totally
disappear, to be replaced with
confidence. You’re about to learn
how to solve tough binary and

subnetting questions quickly and
efficiently – and it all starts with the
fundamentals!

Converting Binary To Dotted
Decimal
It’s easy to overlook the importance
of this section, or just to say, “Hey,
I know how to do that, I’m going to
the next section.”
Don’t do that.
Success in networking is all about
mastering the fundamentals, and
that’s true more of subnetting than
any other single feature on the
CCENT and CCNA exams.

When you master the fundamentals
and then continually practice
applying them, you can answer any
question Cisco or a job interviewer
asks you.
That philosophy has worked for
thousands of CCENT and CCNA
candidates around the world, and
it’ll work for you.
Let’s jump right in to a typical
binary-to-decimal conversion.

Convert 01100010 00111100
11111100 01010101 to binary.
To answer this, we’ll use this
simple chart:
128 64 32 16 8 4 2 1
1st
2nd
3rd
4th
Just plug the binary values under the
128, 64, etc., add ’em up, and
you’re gold!

Filling it in from left to right, here’s
the first octet conversion.

1st

128 64 32 16 8 4 2 1
0 1 1 0 0 0 1 0

There are ones in the column for 64,
32, and 2. Just add them up, and that
is the decimal value for the first
octet -- 98. Repeat the process for
each octet, and you quickly have the
dotted decimal equivalent of the
binary string – in this case,
98.60.252.85.

128 64 32 16 8 4 2 1 To

1st
0
Octet

1 1 0 0 0 1 0 98

2nd
0
Octet

0 1 1 1 1 0 0 60

3rd
1
Octet

1 1 1 1 1 0 0 25

4th
0
Octet

1 0 1 0 1 0 1 85

You certainly don’t have to write
out “1st”, “2nd”, etc. I do
recommend you still write out
“128”, “64”, and so forth. It’s just
too easy to skip over a number
when you don’t write those out, and
we’re not here to give away exam

points – we’re here to take them!
Let’s get in some more practice
with binary-to-decimal, and then
we’ll move on to the next
fundamental conversion skill.

Binary-To-Decimal Practice
Questions
Convert each binary string to dotted
decimal.
The string: 11110000 00110101
00110011 11111110

128 64 32 16 8 4 2 1 Tota
1st 1

1 1 1 0 0 0 0 240

2nd 0
3rd 0

0 1 1 0 1 0 1 53

4th 1

1 1 1 1 1 1 0 254

0 1 1 0 0 1 1 51

Answer: 240.53.51.254.
The string: 00001111 01101111
00011100 00110001

1st

128 64 32 16 8 4 2 1 Tota
0 0 0 0 1 1 1 1 15

2nd 0
3rd 0

1 1 0 1 1 1 1 111

4th 0

0 1 1 0 0 0 1 49

0 0 1 1 1 0 0 28

Answer: 15.111.28.49.

The string: 11100010 00000001
11001010 01110110

1st

128 64 32 16 8 4 2 1 Tota
1 1 1 0 0 0 1 0 226

2nd 0
3rd 1

0 0 0 0 0 0 1 1

4th 0

1 1 1 0 1 1 0 118

1 0 0 1 0 1 0 202

Answer: 226.1.202.118.
The string: 01010101 11111101
11110010 00010101

1st

128 64 32 16 8 4 2 1 Tota
0 1 0 1 0 1 0 1 85

2nd 1
3rd 1

1 1 1 1 1 0 1 253

4th 0

0 0 1 0 1 0 1 21

1 1 1 0 0 1 0 242

Answer: 85.253.242.21.
The string: 00000010 11111001
00110111 00111111

1st

128 64 32 16 8 4 2 1 Tota
0 0 0 0 0 0 1 0 2

2nd 1
3rd 0

1 1 1 1 0 0 1 249

4th 0

0 1 1 1 1 1 1 63

0 1 1 0 1 1 1 55

Answer: 2.249.55.63.
The string: 11001001 01011111
01111111 11111110

1st

128 64 32 16 8 4 2 1 Tota
1 1 0 0 1 0 0 1 201

2nd 0

1 0 1 1 1 1 1 95

3rd 0

1 1 1 1 1 1 1 127

4th 1

1 1 1 1 1 1 0 254

Answer: 201.95.127.254
The string: 11111000 00000111
11111001 01100110

128 64 32 16 8 4 2 1 Tota
1st 1

1 1 1 1 0 0 0 248

2nd 0
3rd 1

0 0 0 0 1 1 1 7

4th 0

1 1 0 0 1 1 0 102

1 1 1 1 0 0 1 249

Answer: 248.7.249.102.
The string: 00111110 11111111
01011010 01111110

1st

128 64 32 16 8 4 2 1 Tota
0 0 1 1 1 1 1 0 62

2nd 1
3rd 0

1 1 1 1 1 1 1 255

4th 0

1 1 1 1 1 1 0 126

1 0 1 1 0 1 0 90

Answer: 62.255.90.126.

The string: 11001101 11110000
00001111 10111111

1st

128 64 32 16 8 4 2 1 Tota
1 1 0 0 1 1 0 1 205

2nd 1
3rd 0

1 1 1 0 0 0 0 240

4th 1

0 1 1 1 1 1 1 191

0 0 0 1 1 1 1 15

Answer: 205.240.15.191
The string: 10011001 11110000
01111111 00100101

1st

128 64 32 16 8 4 2 1 Tota
1 0 0 1 1 0 0 1 153

2nd 1
3rd 0

1 1 1 0 0 0 0 240

4th 0

0 1 0 0 1 0 1 37

1 1 1 1 1 1 1 127

Answer: 153.240.127.37
The string: 11011111 01110110
11000011 00111111

1st

128 64 32 16 8 4 2 1 Tota
1 1 0 1 1 1 1 1 223

2nd 0
3rd 1

1 1 1 0 1 1 0 118

4th 0

0 1 1 1 1 1 1 63

1 0 0 0 0 1 1 195

Answer: 223.118.195.63.
The string: 00000100 00000111
00001111 00000001

1st

128 64 32 16 8 4 2 1 Tota
0 0 0 0 0 1 0 0 4

2nd 0

0 0 0 0 1 1 1 7

3rd 0

0 0 0 1 1 1 1 15

4th 0

0 0 0 0 0 0 1 1

Answer: 4.7.15.1.
The string: 11000000 00000011
11011011 00100101

128 64 32 16 8 4 2 1 Tota
1st 1

1 0 0 0 0 0 0 192

2nd 0
3rd 1

0 0 0 0 0 1 1 3

4th 0

0 1 0 0 1 0 1 37

1 0 1 1 0 1 1 219

Answer: 192.3.219.37.
The string: 10000000 01111111
00110011 10000011

1st

128 64 32 16 8 4 2 1 Tota
1 0 0 0 0 0 0 0 128

2nd 0
3rd 0

1 1 1 1 1 1 1 127

4th 1

0 0 0 0 0 1 1 131

0 1 1 0 0 1 1 51

Answer: 128.127.51.131

The string: 11111011 11110111
11111100 11111000

1st

128 64 32 16 8 4 2 1 Tota
1 1 1 1 1 1 1 1 251

2nd 1
3rd 1

1 1 1 0 1 1 1 247

4th 1

1 1 1 1 0 0 0 248

1 1 1 1 1 0 0 252

Answer: 251.247.252.248
Great work!

Before we move on, let me share a
bonus exam prep tip with you.
The only thing you need to practice
this skill is a piece of paper and
something to write with, and you
don’t need to practice for
consecutive hours. When you have
10 minutes to yourself at work or
home, spend that time jotting down
strings of 1s and 0s and then
converting them to binary. That
little bit of time spent practicing
REALLY adds up in the end!

With that said, let’s move forward!

Converting Decimal To Binary
“Second verse, not quite the same
as the first….”
We’re pretty much doing the same
thing that we did in the first section,
just in reverse.
Makes sense, right? Well, it will
once we go through some examples.
This is definitely one of those skills
that seems REALLY complicated
when you read about it, but when
you do it, you realize how easy it
is!
Let’s practice with the decimal 217.

128 64 32 16 8 4 2 1
217

You must now determine whether
each column should have a “1” or a
“0”. Work from left to right, and ask
this question: “Can I subtract this
column’s value from the current
octet value with the result being a
positive number or zero?”
If so, perform the subtraction, put a
“1” in the column, and go to the next
column.
If not, place a “0” in the column,
and repeat the process for the next

column.
It takes much longer to explain than
to actually do. Let’s look at that
chart again:
128 64 32 16 8 4 2 1
217

Can 128 be subtracted from 217,
and result in zero or a positive
number? Sure, with the result being
89. Put a “1” in the 128 column and
go to the next column, repeating the
operation with the new result.

128 64 32 16 8 4 2 1
217 1

Can 64 be subtracted from the new
result, 89? Yes, with a remainder of
25. Put a “1” in the 64 column and
repeat the operation in the next
column, using the new result of 25.
128 64 32 16 8 4 2 1
217 1 1

Can 32 be subtracted from 25, with
the remainder being 0 or a positive

number? No. Place a “0” in the 32
column, and repeat the operation in
the next column with the value of
25.
128 64 32 16 8 4 2 1
217 1 1 0

Can 16 be subtracted from 25? Yes,
with a remainder of 9. Place a “1”
in the 16 column, and go to the next
column with the new value of 9.
128 64 32 16 8 4 2 1
217 1 1 0 1

Can 8 be subtracted from 9? Yes,
with a remainder of 1. Place a “1”
in the 8 column, and repeat the
operation in the next column with a
remainder of 1.
128 64 32 16 8 4 2 1
217 1 1 0 1 1

We can quickly see that neither of
the next two columns, 4 or 2, can be
subtracted from 1. Place a “0” in
both of those columns.
128 64 32 16 8 4 2 1

217 1

1 0 1 1 0 0

Subtracting 1 from 1 brings us to
zero, and also to the end of the
columns. Place a “1” in the 1
column, and you have the binary
equivalent of the decimal 217.
128 64 32 16 8 4 2 1
217 1 1 0 1 1 0 0 1

The binary equivalent of the
decimal 217 is 11011001.

Two points of note:
You can never have a value
greater than “1” in any bit.
You should never have a
remainder at the end of the
line. If you do, you need to go
back and do it again.
Let’s get in some more work with
this vital skill!

Converting Decimal To Binary
Questions
The address: 100.10.1.200
128
100 0
10 0
1 0
200 1

64
1
0
0
1

32
1
0
0
0

16
0
0
0
0

8
0
1
0
1

4
1
0
0
0

Answer: 01100100 00001010
00000001 11001000.

2
0
1
0
0

1
0
0
1
0

The address: 190.4.89.23
128
190 1
4 0
89 0
23 0

64
0
0
1
0

32
1
0
0
0

16
1
0
1
1

8
1
0
1
0

4
1
1
0
1

2
1
0
0
1

1
0
0
1
1

Answer: 10111110 00000100
01011001 00010111.
The address: 10.255.18.244
128 64 32 16 8 4 2 1

10
255
18
244

0
1
0
1

0
1
0
1

0
1
0
1

0
1
1
1

1
1
0
0

0
1
0
1

1
1
1
0

0
1
0
0

2
0
0
1

1
0
1
1

Answer: 00001010 11111111
00010010 11110100.
The address: 240.17.23.239
128
240 1
17 0
23 0

64
1
0
0

32
1
0
0

16
1
1
1

8
0
0
0

4
0
0
1

239 1

1 1 0 1 1 1 1

Answer: 11110000 00010001
00010111 11101111.
The address: 217.34.39.214

217
34
39
214

128
1
0
0
1

64
1
0
0
1

32
0
1
1
0

16
1
0
0
1

8
1
0
0
0

4
0
0
1
1

2
0
1
1
1

1
1
0
1
0

Answer: 11011001 00100010
00100111 11010110.
The address: 20.244.182.69

20
244
182
69

128
0
1
1
0

64
0
1
0
1

32
0
1
1
0

16
1
1
1
0

8
0
0
0
0

4
1
1
1
1

Answer: 00010100 11110100
10110110 01000101.

2
0
0
1
0

1
0
0
0
1

The address: 198.3.148.245
128
198 1
3 0
148 1
245 1

64
1
0
0
1

32
0
0
0
1

16
0
0
1
1

8
0
0
0
0

4
1
0
1
1

2
1
1
0
0

1
0
1
0
1

Answer: 11000110 00000011
10010100 11110101.
The address: 14.204.71.250
128 64 32 16 8 4 2 1

14
204
71
250

0
1
0
1

0
1
1
1

0
0
0
1

0
0
0
1

1
1
0
1

1
1
1
0

1
0
1
1

0
0
1
0

2
1
0
1
1

1
1
1
0
1

Answer: 00001110 11001100
01000111 11111010.
The address: 7.209.18.47

7
209
18
47

128
0
1
0
0

64
0
1
0
0

32
0
0
0
1

16
0
1
1
0

8
0
0
0
1

4
1
0
0
1

Answer: 00000111 11010001
00010010 00101111.
The address: 249.74.65.43

249
74
65
43

128
1
0
0
0

64
1
1
1
0

32
1
0
0
1

16
1
0
0
0

8
1
1
0
1

4
0
0
0
0

Answer: 11111001 01001010
01000001 00101011.

2
0
1
0
1

1
1
0
1
1

The address: 150.50.5.55

150
50
5
55

128
1
0
0
0

64
0
0
0
0

32
0
1
0
1

16
1
1
0
1

8
0
0
0
0

4
1
0
1
1

2
1
1
0
1

1
0
0
1
1

Answer: 10010110 00110010
00000101 00110111.
The address: 19.201.45.194

19

128 64 32 16 8 4 2 1
0 0 0 1 0 0 1 1

201
45
194

1
0
1

1 0 0 1 0 0 1
0 1 0 1 1 0 1
1 0 0 0 0 1 0

Answer: 00010011 11001001
00101101 11000010.
The address: 43.251.199.207

43
251
199
207

128
0
1
1
1

64
0
1
1
1

32
1
1
0
0

16
0
1
0
0

8
1
1
0
1

4
0
0
1
1

2
1
1
1
1

1
1
1
1
1

Answer: 00101011 11111011
11000111 11001111.
The address: 42.108.93.224

42
108
93
224

128
0
0
0
1

64
0
1
1
1

32
1
1
0
1

16
0
0
1
0

8
1
1
1
0

4
0
1
1
0

Answer: 00101010 01101100
01011101 11100000.

2
1
0
0
0

1
0
0
1
0

The address: 180.9.34.238

180
9
34
238

128
1
0
0
1

64
0
0
0
1

32
1
0
1
1

16
1
0
0
0

8
0
1
0
1

4
1
0
0
1

2
0
0
1
1

1
0
1
0
0

Answer: 10110100 00001001
00100010 11101110.
The address: 243.79.68.30

243

128 64 32 16 8 4 2 1
1 1 1 1 0 0 1 1

79
68
30

0
0
0

1 0 0 1 1 1 1
1 0 0 0 1 0 0
0 0 1 1 1 1 0

Answer: 11110011 01001111
01000100 00011110.
Great work! Now we’ll start
applying these fundamentals to
some real-world scenarios!

Determining The Number Of
Valid Subnets
Once the subnetting’s been done, it
would be a really good idea to
know how many subnets you have
to go around!
Actually, you should calculate that
number before you do the actual
subnetting. In this question type, the
subnetting’s already been
performed and we have to come up
with the number of valid subnets.
Here’s the best part – with enough
practice, you’ll be able to answer
these questions in less than a

minute, and without writing much
(if anything) down on your exam
board!
Here’s a typical “number of valid
subnets” question:
“How many valid subnets
exist on the 10.0.0.0 /12
network?”
“How many valid subnets
exist on the 10.0.0.0
255.240.0.0 network?”
These examples are actually asking
the same thing, just in different
formats. You’re familiar with the

standard dotted decimal mask, but
what about the number following
the slash in the first version of the
question? This is prefix notation,
and it’s the more common way of
expressing a subnet mask.
The number behind the slash
indicates how many consecutive
ones there are at the beginning of
this mask. The dotted decimal mask
255.240.0.0, converted to decimal,
is 11111111 11110000 00000000
00000000. (If you’re unsure how
this value is derived, review
Section Three.) There are twelve
ones at the beginning of the mask,

and that’s where the “/12” comes
from.
Why use this method of expressing
a mask? It’s easier to write and to
say. Try expressing a Class C
network mask out loud as “two fifty
five, two fifty five, two fifty five,
zero” a couple of times, then try
saying “slash twenty-four”. See
what I mean?
You’re going to hear the prefix
notation version of network masks
mentioned more often than someone
reading out the entire mask, so
familiarize yourself with expressing
masks in this fashion. You’re likely

to see both dotted decimal masks
and prefix notation on any Cisco
exam.
Now let’s get in some practice!In
print, this seems like a long
operation, but once you’re doing it,
it’s not.
Before you can determine the
number of valid subnets with a
given network number and subnet
mask, you must know the network
masks for Class A, B, and C
networks. They are listed here for
review:
Class A

Class B

C

1st
Octet
Range
Network
Mask
# of
Network
Bits
# of
Host
Bits

1–126

128–191

1

255.0.0.0 255.255.0.0 2
8

16

2

24

16

8

Subnetting always borrows bits
from the host bits – always.
To determine the number of valid
subnets, you first have to know how

many subnet bits there are. Let’s
look at the example question again:
How many valid subnets exist on
the 10.0.0.0 /12 network?
There are two ways to determine
the number of subnet bits. The first
method is longer, but it shows you
exactly what’s going on with the
subnets. The second method is much
shorter, and you should feel free to
use that one when you’re
comfortable with the first one.
By looking at the network number,
we see this is a Class A network.

By default, a Class A network mask
has 8 network bits and 24 host bits.
In this mask, 12 bits are set to 1.
This indicates that four host bits
have been borrowed for subnetting.
The subnet bits are shown below in
bold.
1st
Octet

2nd Octet 3rd O

Class
“A”
11111111 00000000 00000
NW
Mask:
SN
11111111 11110000 00000
Mask

Now that you know how many
subnet bits there are, place that
number into this formula:
The number of valid subnets =
(2 raised to the
power of the
number of subnet
bits)
We have four subnet bits, so we
need to raise 2 to the 4th power.
When you multiply 2 by itself four
times (2 × 2 × 2 × 2), you get 16,
and that’s how many valid subnets
we have. That’s all there is to it!
Let’s go through another example,

and we won’t draw a chart for this
one. All you need is your
knowledge of network masks and a
little math, and you’re done!
“How many valid subnets exist on
the 150.10.0.0 /21 network?”
This is a Class B network, so we
know the network mask is
255.255.0.0, or /16. The subnet
mask is /21.
Just subtract the number of “1”s in
the network mask from the number
of 1s in the subnet mask, and you
have the number of subnet bits.
21 − 16 = 5, and 2 to the 5th power

equals 32 valid subnets. It’s just
that simple!
Once you’re done with these
practice questions, practice writing
your own questions and solving
them – that’s the ultimate way to
practice this vital skill, and you
can’t beat the cost!
I’ll list the networks and masks
here, and you’ll find the answers
after this list. No peeking!
How many valid subnets exist on
each of the following networks?

15.0.0.0 /13
222.10.1.0 / 30
145.45.0.0 /25
20.0.0.0 255.192.0.0
130.30.0.0 255.255.224.0
128.10.0.0 /19

99.0.0.0 /17
222.10.8.0 /28
20.0.0.0 255.254.0.0
210.17.90.0 /29
130.45.0.0 /26
200.1.1.0 /26

45.0.0.0 255.240.0.0
222.33.44.0 255.255.255.248
23.0.0.0 255.255.224.0
“Number Of Valid Subnets”
Questions and Answers
Note: The NW mask and SN mask
are written out for each question.
You don’t have to write them out if
you’re comfortable with the quicker
method.
15.0.0.0 /13

Class A, 8 network bits. Subnet
mask listed is /13. 13 – 8 = 5, and 2
to the 5th power is 32 = 32 valid
subnets.

NW
11111111 00000000 000000
Mask
SN
11111111 11111000 000000
Mask

222.10.1.0/30
Class C, 24 network bits. 30 – 24 =
6, 2 to the 6th power = 64 valid
subnets.

NW
11111111 11111111 1111111
Mask
SN
11111111 11111111 1111111
Mask
145.45.0.0/25
Class B, 16 network bits. 25 – 16 =
9, 2 to the 9th power = 512 valid
subnets.

11111111 11111111
NW Mask
SN
11111111 11111111
Mask11111111

20.0.0.0 255.192.0.0
Class A, 8 network bits. Subnet
mask converts to /10 in prefix
notation. 10 – 8 = 2, 2 to the 2nd
power = 4 valid subnets.

NW
11111111 00000000 000000
Mask
SN
11111111 11000000 000000
Mask

130.30.0.0 255.255.224.0

Class B, 16 network bits. Subnet
mask converts to /19 in prefix
notation. 19 – 16 = 3, 2 to the 3rd
power = 8 valid subnets.

NW
11111111 11111111 000000
Mask
SN
11111111 11111111 1110000
Mask

128.10.0.0/19
Class B, 16 network bits. 19 – 16 =
3, 2 to the 3rd power = 8 valid
subnets.

NW
11111111 11111111 000000
Mask
SN
11111111 11111111 1110000
Mask

99.0.0.0/17
Class A, 8 network bits. 17 – 8 = 9.
2 to the 9th power = 512 valid
subnets.

NW
11111111 00000000 000000
Mask

11111111 11111111 100000
SN
Mask

222.10.8.0/28
Class C, 24 subnet bits. 28 – 24 =
4. 2 to the 4th power = 16 valid
subnets.

NW
11111111 11111111 1111111
Mask
SN
11111111 11111111 1111111
Mask

20.0.0.0 255.254.0.0
Class A, 8 network bits. Mask
converts to /15 in prefix notation.
15 – 8 = 7. 2 to the 7th power = 128
valid subnets.

NW
11111111 00000000 000000
Mask
SN
11111111 11111110 000000
Mask

210.17.90.0 /29
Class C, 24 network bits. 29 – 24 =

5. 2 to the 5th power = 32 valid
subnets.

NW
11111111 11111111 1111111
Mask
SN
11111111 11111111 1111111
Mask

130.45.0.0/26
Class B, 16 network bits. 26 – 16 =
10. 2 to the 10th power = 1024
valid subnets.

NW 11111111 11111111 000000
Mask
SN
11111111 11111111 1111111
Mask

200.1.1.0/26
Class C, 24 network bits. 26 – 24 =
2. 2 to the 2nd power = 4 valid
subnets.

NW
11111111 11111111 1111111
Mask
SN
11111111 11111111 1111111
Mask

45.0.0.0 255.240.0.0
Class A, 8 network bits. SN mask
converts to /12 in prefix notation.
12 – 8 = 4. 2 to the 4th power = 16
valid subnets.

NW
11111111 00000000 000000
Mask
SN
11111111 11110000 000000
Mask

222.33.44.0 255.255.255.248
Class C, 24 network bits. SN mask
converts to /29 in prefix notation.

29 – 24 = 5. 2 to the 5th power = 32
valid subnets.

NW
11111111 11111111 1111111
Mask
SN
11111111 11111111 1111111
Mask

23.0.0.0 255.255.224.0
Class A, 8 network bits. SN mask
converts to /19. 19 – 8 = 11. 2 to
the 11th power = 2048 valid
subnets.

NW
11111111 00000000 000000
Mask
SN
11111111 11111111 111000
Mask

And that’s it! Once you practice this
question type, you’ll nail the
questions accurately and quickly –
and you’ll see the same is true of
our next question type!

Determining The Number
Of Valid Hosts On A Subnet
As in the previous section, the
subnetting’s been done, and we’re
now being asked to come up with a
value regarding that subnetting. In
this case, we need to come up with
the number of valid hosts per
subnet.
We first need to know how many
host bits are in the subnet mask, and
there’s a lightning-fast way to figure
that out:
(32 – the number of 1s in the mask)
= # of host bits

That’s all there is to it!
Using 200.10.10.0/26 as an
example, all you do is subtract 26
from 32, which gives us 6 host bits.
Then plug that number into this
simple formula:
(2 raised to the power of the
number of host bits) – 2
2 to the 6th power is 64, and 64 – 2
= 62. That’s your number of valid
host addresses!
With practice, you’ll easily figure
this out for any subnet in well under
a minute.
A couple of things to watch out for:

Note this formula uses the
number of host bits, not the
number of subnet bits.
We subtract 2 from the
almost-final answer.
What’s going on with that “-2” at
the end? That accounts for the two
following unusable host addresses:
The first address in the range
is the subnet number itself.
The last address in the range
is the subnet’s broadcast
address.

Since neither of these addresses
should be assigned to hosts, we
need to subtract 2 when calculating
the number of valid hosts in a
subnet.
Since practice makes perfect
CCENTs and CCNAs, let’s get in
some practice with this question
type. I’ve broken the answers down
to the bit level, since you need both
the right answer and how we
arrived at that answer! Feel free not
to write the masks out on exam day.
To avoid the unbearable pressure of
not peeking at the answers, the
questions are listed together first,

followed by the answers and
explanations.
Let’s get started!
The Questions
Determine how many valid host
addresses exist in each of the
following subnets:
220.11.10.0 /26
129.15.0.0 /21
222.22.2.0 / 30
212.10.3.0 /28
14.0.0.0 /20
221.10.78.0 255.255.255.224

143.34.0.0 255.255.255.192
128.12.0.0 255.255.255.240
125.0.0.0 /24
221.10.89.0 255.255.25.248
134.45.0.0 /22
The answers….
220.11.10.0 /26
Nothing to this. Subtract the length
of the subnet mask from 32 and you
have your number of host bits. In
this case, that’s 6, and 2 to the 6th
power is 64. Subtract 2 and you

have 62 valid host addresses.
129.15.0.0 /21
Subtract the mask length from 32.
That gives us 11.
2 to the 11th power equals 2048.
Subtract 2 from that and 2046 valid
host addresses remain.
222.22.2.0 /30
Subtract the mask length from 32.
That gives us 2.
2 to the 2nd power equals 4.

Subtract 2 from that and 2 valid
host addresses remain.
212.10.3.0 /28
Subtract the mask length from 32.
That gives us 4.
2 to the 4th power equals 16.
Subtract 2 from that and 14 valid
host addresses remain.
14.0.0.0 /20
Subtract the mask length from 32,
and we have 12.

2 to the 12th power is 4096;
subtract 2 from that and 4094 valid
host addresses remain.
221.10.78.0 255.255.255.224
Subtract the mask length from 32.
That mask has its first 27 bits set to
1, so in prefix notation that’s /27.
32 – 27 = 5.
2 to the 5th power is 32; subtract 2
from that, and 30 valid host
addresses remain.
143.34.0.0 255.255.255.192

Subtract the mask length from 32.
This mask has its first 26 bits set to
1, so that’s 32 – 26 = 6. 2 to the 6th
power is 64; subtract 2 from that,
and 62 valid host addresses remain.
128.12.0.0 255.255.255.240
This mask converts to /28. 32 – 28
= 4.
2 to the 4th power is 16. Subtract 2
from that, and 14 valid host
addresses remain.
125.0.0.0 /24

32 – 24 = 8. 2 to the 8th power is
256. Subtract 2 from that, and 254
valid host addresses remain.
221.10.89.0 255.255.255.248
In prefix notation, that’s a /29 mask.
32 – 29 = 3.
2 to the 3rd power is 8; subtract 2
from that, and 6 valid host
addresses remain.
134.45.0.0 /22
32 – 22 = 10, so we have 10 host
bits.

2 to the 10th power is 1024;
subtract 2 from that and 1022 valid
host addresses remain.
All right! We’re now comfortable
with the fundamental conversions as
well as determining the number of
valid hosts and subnets – all
valuable skills to have for your
exam and your career!
In the next section, we’ll put all of
this together to determine three
important values with one single
math operation – and there’s a great
shortcut semi-hidden in the next

section, too.
Let’s get started!

Determining The Subnet Number
Of A Given IP Address
This skill is going to serve you well
in both the exam room and in
production networks – and I’m
going to teach you how to perform
this operation in minutes. (Or just
one minute, with practice on your
part!)
Being able to determine what
subnet an IP address is on is an
invaluable skill for troubleshooting
production networks and labs.
You’d be surprised how many
issues pop up just because an admin
thought a host was on “Subnet A”

and the host was actually on
“Subnet B”!
Let’s tackle an example:
“On what subnet is the IP address
10.17.2.14 255.255.192.0 found?”
All you have to do is break the IP
address down into binary, add up
the network and subnet bits ONLY,
and you’re done!

That address in binary is:

00001010 00010001 00000010
00001110
That subnet mask converts to /18 in
prefix notation, so add the first 18
bits, convert the value back to
binary, and you’re done….
…. and the subnet upon which that
address is found is 10.17.0.0
255.255.192.0!

Let’s hit some more practice
questions! I’ll give you the IP
addresses first, and following that
you’ll find the answers and
explanations. Let’s get it done!
For each IP address listed here,
determine its subnet.
217.17.23.200 /27
24.194.34.12 /10
190.17.69.175
111.11.126.5 255.255.128.0
210.12.23.45 255.255.255.248

222.22.11.199 /28
111.9.100.7 /17
122.240.19.23 /10
184.25.245.89 /20
99.140.23.140 /10
10.191.1.1 /10
222.17.32.244 /28

Answers and explanations:

210.17.23.200 /27

Convert the address to binary, add
up the first 27 bits, and you’re
done!
210.17.23.200 = 11010010
000100010001011111001000
Subnet: 210.17.23.192 /27.
24.194.34.12 /10
24.194.34.12 = 0001100011000010
00100010 00001100

Add up the first 10 bits =
24.192.0.0 /10.

190.17.69.175 /22
190.17.69.175 = 10111110
00010001 01000101 10101111
Add up the first 22 bits =
190.17.68.0 /22 is your subnet!

111.11.126.5 255.255.128.0

111.11.126.5 = 01101111 00001011
01111110 00000101
Add up the first 17 bits = 111.11.0.0
255.255.128.0 is your subnet!

210.12.23.45 255.255.255.248
210.12.23.45 = 11010010
00001100 00010111 00101101
Add up the first 29 bits =
210.12.23.40 255.255.255.248 is

your subnet!

222.22.11.199 /28
222.22.11.199 = 11011110
00010110 00001011 11000111
Add up the first 28 bits =
222.22.11.192 /28 is your subnet!

111.9.100.7 /17

111.9.100.7 = 01101111 00001001
01100100 00000111
Add up the first 17 bits = 111.9.0.0
/17 is your subnet!

122.240.19.23 /10
122.240.19.23 = 01111010
11110000 00010011 00010111
Add up the first 10 bits =
122.192.0.0 /10 is your subnet!

184.25.245.89 /20
184.25.245.89 = 10111000
00011001 11110101 01011001
Add up the first 20 bits =
184.25.240.0 /20 is your subnet!

99.140.23.143 /10
99.140.23.143 = 01100011
10001100 00010111 10001111

Add up the first 10 bits =
99.128.0.0 /10 is your subnet!

10.191.1.1 /10
10.191.1.1 = 00001010 10111111
00000001 00000001
Add up the first 10 bits =
10.128.0.0 /10 is your subnet!

222.17.32.244 /28

222.17.32.244 = 11011110
00010001 00100000 11110100
Add up the first 28 bits =
222.17.32.240 /28 is your subnet!

Onward!

Determining Broadcast Addresses
& Valid IP Address Ranges For A
Given Subnet
(With The Same Quick Operation!)
The operation we perform in this
section will answer two different
questions.
Need to determine the broadcast
address for a subnet? Got you
covered.
Need to determine the valid address
range for a subnet? Got it!
Best of all, it’s a quick operation.

Let’s go through a sample question
and you’ll see what I mean.
What is the range of valid IP
addresses for the subnet
210.210.210.0 /25?
We need to convert this address to
binary AND identify the host bits,
and we know how to do that.

Octet 1
Octet 2
210.210.210.0 11010010 1101001
/25
11111111 11111111

There are three basic rules to
remember when determining the
subnet address, broadcast address,
and range of valid addresses once
you’ve identified the host bits – and
these rules answer three different
questions.
1. The address with all 0s for
host bits is the subnet address,
also referred to as the “allzeroes” address. This is not a
valid host address.
2. The address with all 1s for

host bits is the broadcast
address, also referred to as
the “all-ones” address. This is
not a valid host address.
3. All addresses between the allzeroes and all-ones addresses
are valid host addresses.
The “all-zeroes” address is
210.210.210.0. That’s easy enough
– and so is the rest of this
operation.
When you change all the host bits to
1, the result is 210.210.210.127,
and that’s our broadcast address for

this subnet.
Every address in the middle of
those two addresses
(210.210.210.1 – 126) is a valid IP
address. That’s all there is to it!
Let’s tackle another example:
Octet 1 Octet 2
150.10.64.0 11010010 00001010
11111111 11111111
/18
What is the broadcast address of
the subnet 150.10.64.0 /18?

You don’t have to write out the
mask on exam day if you don’t want
to. I’m including it here so you see
exactly what we’re doing.
If all the host bits (bolded) are
zeroes, the address is 150.10.64.0,
the subnet address itself. This is not
a valid host address.
If all the host bits are ones, the
address is 150.10.127.255. That is
the broadcast address for this
subnet and is also not a valid host
address.
All bits between the subnet address
and broadcast address are
considered valid addresses. This

gives you the range 150.10.64.1 –
150.10.127.254.
Let’s get some more practice! First,
I’ll list the subnets, and it’s up to
you to determine the range of valid
host addresses and the broadcast
address for that subnet. After the
list, I’ll show you the answer and
explanation for each subnet.
222.23.48.64 /26
140.10.10.0 /23
10.200.0.0 /17
198.27.35.128 /27
132.12.224.0 /27

211.18.39.16 /28
10.1.2.20 /30
144.45.24.0 /21
10.10.128.0 255.255.192.0
221.18.248.224 /28
123.1.0.0 /17
203.12.17.32 /27
Time for answers and explanations!
222.23.48.64 /26
Octet 1

Octet

11011110 000101
222.23.48.64
255.255.255.192 11111111 111111

All-Zeroes (Subnet) Address:
222.23.48.64 /26
All-Ones (Broadcast) Address:
222.23.48.127 /26
Valid IP address range:
222.23.48.65 – 222.23.48.126
140.10.10.0 /23
Octet 1 Octet 2
140.10.10.0 10001100 00001010

/23

11111111 11111111

All-Zeroes (Subnet) Address:
140.10.10.0 /23
All-Ones (Broadcast) Address:
140.10.11.255 /23
Valid IP address range: 140.10.10.1
– 140.10.11.254
10.200.0.0 /17

Octet 1 Octet 2 O
10.200.0.0 00001010 11001000 0
11111111 11111111 1
/17

All-Zeroes (Subnet) Address:
10.200.0.0 /17
All-Ones (Broadcast) Address:
10.200.127.255 /17
Valid IP address range: 10.200.0.1
– 10.200.127.254
198.27.35.128 /27

Octet 1 Octet 2
198.27.35.128 11000110 00011011
11111111 11111111
/27

All-Zeroes (Subnet) Address:

198.27.35.128 /27
All-Ones (Broadcast) Address:
198.27.35.159 /27
Valid IP address range:
198.27.35.129 – 198.27.35.158
132.12.224.0 /27

Octet 1 Octet 2
132.12.224.0 10000100 00001100
11111111 11111111
/27

All-Zeroes (Subnet) Address:
132.12.224.0 /27

All-Ones (Broadcast) Address:
132.12.224.31 /27
Valid IP address range:
132.12.224.1 – 132.12.224.30
211.18.39.16 /28

Octet 1 Octet 2
211.18.39.16 11010011 00010010
11111111 11111111
/28

All-Zeroes (Subnet) Address:
211.18.39.16 /28
All-Ones (Broadcast) Address:

211.18.39.31 /28
Valid IP address range:
211.18.39.17 – 211.18.39.30
10.1.2.20 /30

Octet 1 Octet 2 Oc
10.1.2.20 00001010 00000001 00
11111111 11111111 11
/30

All-Zeroes (Subnet) Address:
10.1.2.20 /30
All-Ones (Broadcast) Address:
10.1.2.23 /30

Valid IP address range: 10.1.2.21 –
10.1.2.22 /30
144.45.24.0 /21
Octet 1 Octet 2
144.45.24.0 10010000 00101101
11111111 11111111
/21

All-Zeroes (Subnet) Address:
144.45.24.0 /21
All-Ones (Broadcast) Address:
144.45.31.255 /21
Valid IP address range: 144.45.24.1

– 144.45.31.254 /21
10.10.128.0 255.255.192.0

Octet 1 Octet 2
10.10.128.0 00001010 0000101
255.255.192.0 11111111 11111111

All-Zeroes (Subnet) Address:
10.10.128.0 255.255.192.0
All-Ones (Broadcast) Address:
10.10.191.255 255.255.192.0
Valid IP address range: 10.10.128.1
– 10.10.191.254

221.18.248.224 /28

Octet 1 Octet 2
221.18.248.224 11011101 000100
11111111 1111111
/28

All-Zeroes (Subnet) Address:
221.18.248.224 /28
All-Ones (Broadcast) Address:
221.18.248.239 /28
Valid IP address range:
221.18.248.225 – 238 /28
123.1.0.0 /17

Octet 1 Octet 2 Oc
123.1.0.0 01111011 00000001 000
11111111 11111111 100
/17

All-Zeroes (Subnet) Address:
123.1.0.0 /17
All-Ones (Broadcast) Address:
123.1.127.255 /17
Valid IP address range: 123.1.0.1 –
123.1.127.254 /17
203.12.17.32 /27
Octet 1

Octet 2

203.12.17.32 11001011 00001100
11111111 11111111
/27

All-Zeroes (Subnet) Address:
203.12.17.32 /27
All-Ones (Broadcast) Address:
203.12.17.63 /27
Valid IP address range:
203.12.17.33 – 203.12.17.62
Great work!
Now let’s put this ALL together and

tackle some real-world subnetting
situations that just might be CCENT
and CCNA subnetting situations as
well! On to the next section!

Meeting Stated Design
Requirements
(Or “Hey, We’re Subnetting!”)

Now we’re going to put our skills
together and answer questions that
are asked before the subnetting’s
done! Actually, we’re doing the
subnetting (at last!)
A typical subnetting question ….
“Using network 150.50.0.0, you
must design a subnetting scheme

that allows for at least 200 subnets,
but no more than 150 hosts per
subnet. Which of the following
subnet masks is best suited for this
task?”
(The question could also give you
no choices and ask you to come up
with the best possible mask, just
like my practice questions.)
We’re dealing with a Class B
network, which means we have 16
network bits and 16 host bits. We’ll
borrow subnet bits from the host
bits, so we’ll leave the host bits
area blank for now.

1st

2nd

3rd 4th

NW
11111111 11111111
Bits
Host
Bits

The formulas for determining the
number of bits needed for a given
number of subnets or hosts:
The number of valid subnets =
(2 raised to the power of
the number of subnet bits)
The number of valid hosts =
(2 raised to the

power of the number
of host bits) − 2
The key to this question is to come
up with the minimum number of bits
you’ll need for the required number
of subnets, and make sure the
remaining host bits give you enough
hosts, but not too many hosts.
We need eight subnet bits to give us
at least 200 subnets:
2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 = 256
subnets.
Proposed solution: 255.255.255.0

NW 11111111 11111111
Bits
SN
11111111
Bits
Host
Bits

This mask leaves eight host bits,
which would result in 254 hosts.
This violates the requirement that
we have no more than 150 hosts per
subnet.
What happens if you borrow one
more host bit for subnetting, giving
you 9 subnet bits and 7 host bits?

9 Subnet Bits: 2 × 2 × 2 × 2 × 2 × 2
× 2 × 2 × 2 = 512
7 Host Bits: 2 × 2 × 2 × 2 × 2 × 2 ×
2 = 128 − 2 = 126
This gives you 510 subnets and 126
hosts, meeting both requirements.
The great thing about this question
type is that it plays to your
strengths. You already know how to
work with subnet bits and host bits.
What you must watch out for are
answers that meet one requirement
but do not meet the other.
Let’s walk through another

example:
Using network 220.10.10.0, you
must develop a subnetting scheme
that allows for a minimum of six
hosts and a minimum of 25
subnets. What’s the best mask to
use?
Watch this question – it’s asking for
two minimums.
This is a Class C network, so 24 of
the bits are already used with the
network mask. You have only eight
bits to split between the subnet and
the host bits.
Before subnetting: Class C

network mask 255.255.255.0

NW
11111111 11111111 11111111
Bits
SN
Bits
Host
Bits

For at least 25 subnets, 5 subnet
bits are needed:
2 × 2 × 2 × 2 × 2 = 32 subnets

This would leave three host bits.
Does this meet the other
requirement?
2 × 2 × 2 = 8 − 2 = 6 hosts.
That meets the second requirement,
so a mask of 5 subnet bits and 3
host bits will get the job done.
1st

2nd

3rd

NW
11111111 11111111 11111111
Bits
SN
Bits

Host
Bits

The resulting mask is
255.255.255.248.
As you’ve seen, this question type
brings into play skills you’ve
already developed. Just be careful
when analyzing the question’s
requirements, and you’ll get the
correct answer every time.
Practice makes perfect, so let’s
practice!

“Meeting Design Requirements”
Questions:
Your network has been assigned
the address 140.10.0.0. Your
network manager requires that you
have at least 250 subnets, and that
any of these subnets will support
at least 250 hosts. What’s the best
mask to use?
This Class B network has 16
network bits, which we never
borrow for subnetting, and 16 host
bits, which we always borrow for

subnetting. (hint hint)
Before subnetting: Class B
network mask 255.255.0.0

NW
11111111 11111111
Bits
SN
Bits
Host
0000000
Bits

You must have at least 250 subnets,
and eight subnet bits would give us
that (256, to be exact). That leaves

eight host bits, giving us 254 hosts,
so the resulting mask of
255.255.255.0 meets both
requirements.
1st
Octet

2nd
Octet

3rd
Octet

NW
11111111 11111111
Bits
SN
Bits
Host
Bits

Your network has been assigned

the network number 200.10.10.0.
Your network manager has asked
you to come up with a subnet mask
that will allow for at least 15
subnets.
No subnet should ever contain
more than 12 hosts, but should
contain at least five. What’s the
best mask to use?
This Class C network’s mask has
24 network bits. There are only
eight host bits to borrow for
subnetting.
Before subnetting: Class C
network mask 255.255.255.0

NW
11111111 11111111 11111111
Bits
SN
Bits
Host
Bits

Four subnet bits would give you 16
subnets, meeting the first
requirement. The problem is that
this would leave 4 host bits,
resulting in 14 hosts, which violates
the second requirement.
The maximum number of host bits

you can have in this answer is three,
which would result in 6 hosts. You
can’t have less, because that would
allow only two hosts.
That would leave five subnet bits,
which meets the first requirement.
The only mask that meets both
requirements is /29.
1st
Octet

2nd
Octet

3rd
Octet

NW
11111111 11111111 11111111
Bits
SN
Bits

Host
Bits

Your network has been assigned
134.100.0.0. Your network
manager requests that you come
up with a subnet mask that allows
for at least 500 subnets, but no
subnet should be able to hold more
than 120 hosts per subnet. What is
the best subnet mask to use?
Network 134.100.0.0 is a Class B
network with a network mask of
255.255.0.0. Sixteen bits remain to
be split between the subnet bits and

host bits.
Before subnetting: Class B mask
255.255.0.0

NW
11111111 11111111
Bits
SN
Bits
Host
0000000
Bits

For 500 subnets, a minimum of nine
subnet bits will be needed (2 to the
9th power is 512).

That would leave 7 host bits. Does
this meet the second requirement?
No. 2 to the 7th power is 128.
Subtract 2 and 126 host addresses
remain, violating the second
requirement.
A mix of 10 subnet bits and 6 host
bits will work. 10 subnet bits result
in 1024 valid subnets, meeting the
first requirement. That would leave
6 host bits, which yields 62 valid
hosts. That meets the second
requirement.
1st
Octet

2nd
Octet

3rd
Octet

NW 11111111 11111111
Bits
SN
11111111
Bits
Host
Bits

The mask is 255.255.255.192.
This is the type of question you
really have to watch. It would be
easy to say “okay, 9 subnet bits
gives me 512 subnets, that’s the
right answer”, choose that answer,
and move on. You must ensure that
your answer meets both

requirements!

Your network has been assigned
202.10.40.0. Your network
manager requests that you come
up with a subnet mask that allows
at least 10 subnets, but no subnet
should allow more than 10 hosts.
What is the best subnet mask to
use?
Network 202.10.40.0 is a Class C
network with a mask of
255.255.255.0. Only eight bits

remain to be split between the
subnet bits and host bits.
Before subnetting: Class C
network mask 255.255.255.0

NW
11111111 11111111 11111111
Bits
SN
Bits
Host
Bits

For a minimum of 10 subnets, at
least four subnet bits would be

needed (2 to the 4th power = 16).
This would leave four host bits.
Does this meet the second
requirement? No. There would be
14 hosts.
Five subnet bits and three host bits
will meet the requirements. This
would yield 32 subnets and 6 hosts.
The resulting mask is
255.255.255.248.
1st
Octet

2nd
Octet

3rd
Octet

NW
11111111 11111111 11111111
Bits
SN

Bits
Host
Bits

You’re working with 37.0.0.0. Your
manager requests that you allow
for at least 500 hosts per subnet;
however, he wants as many subnets
as possible without exceeding
1000 subnets. What is the best
subnet mask to use?
Network 37.0.0.0 is a Class A
network, so we have 24 host bits to
work with.
Before subnetting: Class A

network mask 255.0.0.0

NW
11111111
Bits
SN
Bits
Host
00000000 000000
Bits

The requirement for 500 hosts is no
problem; we only need nine host
bits to have 510 valid host
addresses (2 to the 9th power − 2 =
510).

The problem comes in with the
requirement of not having more than
1000 subnets. If we only used nine
host bits, that would leave 15
subnet bits, which would result in
over 32,000 subnets!
How many subnet bits can we
borrow without going over 1000
subnets? Nine subnet bits would
give us 512 valid subnets; that’s as
close as we can come without going
over. Doing so would leave us with
15 host bits, which would certainly
meet the “minimum number of
hosts” requirement.

1st
Octet

2nd
Octet

3rd
Octet

NW
11111111
Bits
SN
11111111 1
Bits
Host
0000000
Bits

The best mask to use to meet both
requirements is 255.255.128.0.
Do not let the “minimum” part of
the requirement throw you off. If
you’re asked for a minimum of 500
hosts or 500 subnets, as long as

you’ve got more than that, it doesn’t
matter how many more you have.
The requirement is met. The key is
to meet both requirements.
You’re working with 157.200.0.0.
You must develop a subnetting
scheme where each subnet will
support at least 200 hosts, and
you’ll have between 100 and 150
subnets. What is the appropriate
subnet mask to use?
This network number is Class B, so
we have 16 host bits to work with.
Before subnetting: Class B
network mask 255.255.0.0

NW
11111111 11111111
Bits
SN
Bits
Host
0000000
Bits

Eight host bits would result in 254
hosts, enough for the first
requirement. However, this would
also result in 256 valid subnets,
violating the second requirement. (2
to the 8th power = 254).
The only number of subnet bits that

results in between 100 and 150
valid subnets is 7; this yields 128
valid subnets. (Six subnet bits
would yield 64 valid subnets.) This
means we would have nine host bits
left, more than meeting the “at least
200 hosts” requirement.

NW
11111111 11111111
Bits
SN
1111111
Bits
Host
Bits

The proper mask is 255.255.254.0.

Given network number
130.245.0.0, what subnet mask will
result in at least 250 valid hosts
per subnet, but between 60 and 70
valid subnets?
With this Class B network, there are
16 host bits. How many subnet bits
need to be borrowed to yield
between 60 and 70 subnets?
The only number of subnet bits that
yield this particular number is six,
which gives us 64 valid subnets.

Five subnet bits yield too few valid
subnets (32), while seven subnet
bits yield too many (128).
If you borrow six subnet bits, how
many hosts will be available per
subnet? The remaining ten host bits
will give you 1022 valid host
addresses, more than enough for the
first requirement. Therefore, the
appropriate mask is 255.255.252.0.
1st
Octet

2nd
Octet

3rd Octe

NW
11111111 11111111
Bits
SN
111111

Bits
Host
Bits

Time for our final exam! Let’s get
right to it – in the very next section!

0

Finals!

Let’s put it all together for one big
final exam! We’ll sharpen our skills
for exam success on these
questions, and they’re presented in
the same order in which they
appeared in this book. If you’re a
little hesitant on how to answer any
of these questions, be sure to go
back and get more practice!
Let’s get started!

Converting Binary To Dotted
Decimal
The string: 01010101 11100010
01101010 01001010

Answer: 85.226.106.74
The string: 11110000 00001111
01111111 10000000

Answer: 240.15.127.128.
The string: 11001101 00000011
11110010 00100101

Answer: 205.3.242.37.

The string: 00110010 00100011
11110011 00100111

Answer: 50.35.243.39.
The string: 10000111 00111111
01011111 00110010

Answer: 135.63.95.50
Converting Dotted Decimal
Addresses To Binary Strings
The address: 195.29.37.126

Answer: 11000011 00011101
00100101 01111110.
The address: 207.93.49.189

Answer: 11001111 01011101
00110001 10111101.
The address: 21.200.80.245

Answer: 00010101 11001000
01010000 11110101.
The address: 105.83.219.91

Answer: 01101001 01010011

11011011 01011011.
The address: 123.54.217.4

Answer: 01111011 00110110
11011001 00000100.
Determining The Number Of
Valid Subnets
How many valid subnets are on the

222.12.240.0 /27 network?
This is a Class C network, with a
network mask of /24. The subnet
mask is /27, indicating three subnet
bits.
2 to the 3rd power is 8 = 8 valid
subnets.
How many valid subnets are on the
10.1.0.0 /17 network?
This is a Class A network, with a
network mask of /8. The subnet
mask is /17, indicating nine subnet
bits. (17 − 8 = 9)

2 to the 9th power is 512 = 512
valid subnets.
How many valid subnets are on the
111.0.0.0 /14 network?
This is a Class A network, with a
network mask of /8. The subnet
mask is /14, indicating six subnet
bits. (14 − 8 = 6)
2 to the 6th power is 64 = 64 valid
subnets.
How many valid subnets are on the
172.12.0.0 /19 network?

This is a Class B network, with a
network mask of /16. The subnet
mask is /19, indicating three subnet
bits. (19 − 16 = 3)
2 to the 3rd power is 8 = 8 valid
subnets.
How many valid subnets are on the
182.100.0.0 /27 network?
This is a Class B network, with a
network mask of /16. The subnet
mask is /27, indicating 11 subnet
bits. (27 − 16 = 11)
2 to the 11th power is 2048 = 2048
valid subnets.

How many valid subnets exist on
the 221.23.19.0 /30 network?
This is a Class C network, with a
network mask of /24. The subnet
mask is /30, indicating six subnet
bits. (30 − 24 = 6)
2 to the 6th power is 64 = 64 valid
subnets.
How many valid subnets exist on
the 17.0.0.0 255.240.0.0 network?
This is a Class A network, with a
network mask of 255.0.0.0. The

subnet mask here is 255.240.0.0
(/12), indicating four subnet bits.
(12 − 8 = 4)
2 to the 4th power is 16 = 16 valid
subnets.
How many valid subnets exist on
the 214.12.200.0 255.255.255.248
network?
This is a Class C network, with a
network mask of 255.255.255.0.
The subnet mask here is
255.255.255.248 (/29), indicating
five subnet bits. (29 − 24 = 5)
2 to the 5th power is 32 = 32 valid

subnets.
How many valid subnets exist on
the 155.200.0.0 255.255.255.128
network?
This is a Class B network, with a
network mask of 255.255.0.0. The
subnet mask here is
255.255.255.128 (/25), indicating
nine subnet bits. (25 − 16 = 9)
2 to the 9th power is 512 = 512
valid subnets.
Determining The Number Of

Valid Hosts
How many valid host addresses
exist on the 211.24.12.0 /27
subnet?
To determine the number of host
bits, just subtract the subnet mask
length from 32. 32 – 27 = 5.
To then determine the number of
host addresses, bring 2 to that
result’s power and subtract 2. 2 to
the 5th power = 32, 32 − 2 = 30
valid host addresses.
How many valid host addresses
exist on the 178.34.0.0 /28 subnet?

To determine the number of host
bits, just subtract the subnet mask
length from 32. 32 − 28 = 4.
To then determine the number of
host addresses, bring 2 to that
result’s power and subtract 2. 2 to
the 4th power = 16, 16 − 2 = 14
valid host addresses.
How many valid host addresses
exist on the 211.12.45.0 /30
subnet?
Subtract the subnet mask length
from 32. 32 − 30 = 2 host bits.
Bring 2 to that result’s power and

subtract 2. 2 to the 2nd power = 4, 4
– 2 = 2 valid host addresses on that
subnet.
How many valid host addresses
exist on the 129.12.0.0 /20 subnet?
Subtract the subnet mask length
from 32. 32 – 20 = 12 host bits.
Bring 2 to that result’s power and
subtract 2. 2 to the 12th power =
4096, and 4096 − 2 = 4094 valid
host addresses on that subnet.
How many valid host addresses

exist on the 220.34.24.0
255.255.255.248 subnet?
Subtract the subnet mask length
from 32. 32 – 29 = 3 host bits.
Bring 2 to that result’s power and
subtract 2. 2 to the 3rd power = 8, 8
– 2 = 6 valid host addresses on this
subnet.
How many valid host addresses
exist on the 145.100.0.0
255.255.254.0 subnet?
Subtract the subnet mask length
from 32. 32 – 23 = 9 host bits.

Bring 2 to that result’s power and
subtract 2. 2 to the 9th power = 512,
and 512 – 2 = 510 valid host
addresses on that subnet.
How many valid host addresses
exist on the 23.0.0.0 255.255.240.0
subnet?
Subtract the subnet mask length
from 32. 32 − 20 = 12 host bits.
Bring 2 to that result’s power and
subtract 2. 2 to the 12th power =
4096, 4096 − 2 = 4094 valid host
addresses on that subnet.

Determining The Subnet Number
Of A Given IP Address
On what subnet can the IP address
142.12.38.189 /25 be found?
Start writing out the 142.12.38.189
address in binary, and stop once
you’ve converted 25 bits. That
result gives you the answer. (You
can also write out the entire address
for practice and then add up the first
25 bits.)
First 25 bits = 10001110 00001100
00100110 1xxxxxxx
Result = 142.12.38.128 /25.

On what subnet can the IP address
170.17.209.36 /19 be found?
Convert that IP address to binary
and stop once you get to 19 bits,
then convert right back to dotted
decimal.
First 19 bits = 10101010 00010001
110xxxxx xxxxxxxx
The answer: 170.17.192.0 /19.
On what subnet can the IP address
10.178.39.205 /29 be found?
Convert the address to binary and
stop at the 29-bit mark.

29 bits = 00001010 10110010
00100111 11001xxx =
10.178.39.200
Tack your /29 on the back and you
have the answer!
On what subnet can the IP address
190.34.9.173 /22 be found?
Convert the address to binary, stop
at 22 bits, and then convert the
address right back to decimal.
First 22 bits = 10111110 00100010
000010xx xxxxxxxx = 190.34.8.0
/22

On what subnet can the IP address
203.23.189.205 255.255.255.240
be found?
Write out the address in binary and
stop at the 28-bit mark, then convert
those 28 bits back to decimal.
Done!
1st 28 bits = 11001011 00010111
10111101 1100xxxx =
203.23.189.192 / 28
On what subnet can the IP address
49.210.83.201 255.255.255.248 be
found?
Convert the address to binary up to

the 29-bit mark, and convert those
29 bits right back to decimal.
00110001 11010010 01010011
11001xxx = 49.210.83.200 / 29.
On what subnet can the IP address
31.189.234.245 /17 be found?
Convert the address to binary up to
the 17-bit mark, then convert those
17 bits right back to decimal.
31.189.234.245 = 00011111
10111101 1xxxxxxx xxxxxxxx =
31.189.128.0 /17

On what subnet can the IP address
190.98.35.17 /27 be found?
Convert the address to binary up to
the 27-bit mark, then convert those
27 bits right back to decimal.
190.98.35.17 = 10111110
01100010 00100011 000xxxxx =
190.98.35.0 / 27
Determining Broadcast Addresses
and Valid IP Address Ranges
For each of the following, identify
the valid IP address range and the
broadcast address for that subnet.

100.100.45.32 /28
208.72.109.8 /29
190.89.192.0 255.255.240.0
101.45.210.52 /30
90.34.128.0 /18
205.186.34.64 /27
175.24.36.0 255.255.252.0
10.10.44.0 /25
120.20.240.0 /21
200.18.198.192 /26
Answer and explanations follow!

The subnet: 100.100.45.32 /28

We know that the last four bits are
the host bits. If these are all zeroes,
this is the subnet address itself. If
there are all ones, this is the
broadcast address for this subnet.
All addresses between the two are
valid.
“All-Zeroes” Subnet Address:
100.100.45.32 /28

“All-Ones” Broadcast Address:
100.100.45.47 /28
Valid IP Addresses: 100.100.45.33
– 46 /28
The subnet: 208.72.109.8 /29

“All-Zeroes” Subnet Address:
208.72.109.8 /29
“All-Ones” Broadcast Address:
208.72.109.15 /29

Valid IP Addresses: 208.72.109.9 –
208.72.109.14 /29
The subnet: 190.89.192.0
255.255.240.0

“All-Zeroes” Subnet Address:
190.89.192.0 /20
“All-Ones” Broadcast Address:
190.89.207.255 /20
Valid IP Addresses: 190.89.192.1 –

190.89.207.254 /20
The subnet: 101.45.210.52 /30

“All-Zeroes” Subnet Address:
101.45.210.52 /30
“All-Ones” Broadcast Address:
101.45.210.55 /30
Valid IP Addresses: 101.45.210.53,
101.45.210.54 /30

The subnet 90.34.128.0 /18

“All-Zeroes” Subnet Address:
90.34.128.0 /18
“All-Ones” Broadcast Address:
90.34.191.255 /18
Valid IP Addresses: 90.34.128.1 –
90.34.191.254 /18
The subnet: 205.186.34.64 /27

“All-Zeroes” Subnet Address:
205.186.34.64 /27
“All-Ones” Broadcast Address:
205.186.34.95 /27
Valid IP Addresses: 205.186.34.65
– 94 /27
The subnet: 175.24.36.0
255.255.252.0

“All-Zeroes” Subnet Address:
175.24.36.0 /22
“All-Ones” Broadcast Address:
175.24.39.255 /22
Valid IP Addresses: 175.24.36.1 –
175.24.39.254 /22
The subnet: 10.10.44.0 /25

“All-Zeroes” Subnet Address:
10.10.44.0 /25
“All-Ones” Broadcast Address:
10.10.44.127 /25
Valid IP Addresses: 10.10.44.1 –
10.10.44.126 /25
The subnet: 120.20.240.0 /21

“All-Zeroes” Subnet Address:
120.20.240.0 /21

“All-Ones” Broadcast Address:
120.20.247.255 /21
Valid IP Addresses: 120.20.240.1 –
120.20.247.254 /21
The subnet: 200.18.198.192 /26

“All-Zeroes” Subnet Address:
200.18.198.192 /26
“All-Ones” Broadcast Address:
200.18.198.255 /26

Valid IP Addresses:
200.18.198.193 – 200.18.198.254
/26
Now let’s put it all together for
some real-world design
requirement questions!
Meeting The Stated Design
Requirements
You’re working with network
135.13.0.0. You need at least 500
valid subnets, but no more than
100 hosts per subnet. What is the
best subnet mask to use?

This is a Class B network, with 16
network bits and 16 host bits.

The first requirement is that we
have at least 500 subnets. Nine
subnet bits would give us 512 valid
subnets:
2×2×2×2×2×2×2×2×2=
512
This would leave seven host bits,
resulting in 126 valid host

addresses, which violates the
second requirement. (2 to the 7th
power is 128; subtract two, and 126
valid host addresses remain.)
What about six host bits? That
would yield 62 valid host
addresses, which meets the second
requirement. A combination of ten
subnet bits and six host bits gives us
1024 valid subnets and 62 valid
host addresses, meeting both
requirements.

The resulting mask is
255.255.255.192 (/26).
You’re working with the network
223.12.23.0.
Your network manager has asked
you to develop a subnetting
scheme that allows at least 30
valid hosts per subnet, but yields
no more than five valid subnets.
What’s the best subnet mask to
use?
This Class C network’s mask is /24,
leaving eight host bits to borrow for
subnetting.

We know we need five host bits for
at least 30 hosts per subnet. (2 to
the 5th power, minus two, equals
exactly 30.) Does this meet the
second requirement?
No. That would leave three subnet
bits, which yields eight valid
subnets. To meet the second
requirement, you can have only two
subnet bits, which yields two valid
subnets.

This yields a mask of
255.255.255.192 (/26).
You’re working with the network
131.10.0.0. Your network manager
has requested that you develop a
subnetting scheme that allows at
least fifty subnets. No subnet
should contain more than 1000
hosts. What is the best subnet mask
to use?

This Class B network has 16
network bits, and 16 host bits that
can be borrowed for subnetting.

You quickly determine that for fifty
subnets, you only need six subnet
bits. That gives you 64 valid
subnets. Does this mask meet the
second requirement?
No. That would leave 10 host bits,
which yields 1022 valid host
addresses. (2 to the 10th power

equals 1024; subtract two, and
1022 remain.) By borrowing one
more bit for subnetting, giving us
seven subnet bits and nine host bits,
both requirements are met.
Seven subnet bits yield 128 valid
subnets, and nine host bits yield 510
valid host addresses. The
appropriate mask is 255.255.254.0.

Congratulations! You’ve completed

this final exam. If you had any
difficulty with the final section,
please review Section Eight. If you
nailed all five of the final questions
– great work!
To wrap things up, let’s hit Variable
Length Subnet Masking!

How To Develop A VLSM
Scheme
In the networks we’ve been
working with in the binary and
subnetting section, we’ve cut our IP
address space “pie” into nice, neat
slices of the same size.
We don’t always want to do that,
though. If we have a point-to-point
network, why assign a subnet
number to that network that gives
you 200+ addresses when you’ll
only need two?
That’s where Variable-Length
Subnet Masking comes in. VLSM is

the process of cutting our address
pie into uneven slices.
The best way to get used to VLSM
is to work with it, so let’s go
through a couple of drills where
VLSM will come in handy.
Our first drill will involve the
major network number 210.49.29.0.
We’ve been asked to create a
VLSM scheme for the following
five networks, and we’ve also been
told that there will be no further
hosts added to any of these
segments. The requirement is to use
no more IP addresses from this
range for any subnet that is

absolutely necessary.
The networks:
NW A: 20 hosts
NW B: 10 hosts
NW C: 7 hosts
NW D: 5 hosts
NW E: 3 hosts
We’ll need to use the formula for
determining how valid host
addresses are yielded by a given
number of host bits:
(2 to the nth power) - 2, with
n representing the number of

host bits
To create our VLSM scheme, we’ll
ask this simple question over and
over:
“What is the smallest subnet that
can be created with all host bits
set to zero?”
NW A requires 20 valid host
addresses. Using the above formula,
we determine that we will need 5
host bits (2 to the 5th power equals
32; 32 − 2 = 30). What is the
smallest subnet that can be created
with all host bits set to zero?
210.49.29.0 in binary: 11010010

00110001 00011101 00000000
/27 subnet mask:
11111111
11111111 11111111 11100000
We’ll use a subnet mask of /27 to
have five host bits remaining,
resulting in a subnet and subnet
mask of 210.49.29.0 /27, or
210.49.29.0 255.255.255.224.
It’s an excellent idea to keep a
running chart of your VLSM
scheme, so we’ll start one here. The
network number itself is the value
of that binary string with all host
bits set to zero; the broadcast
address for this subnet is the value
of that binary string with all host

bits set to one. These two particular
addresses cannot be assigned to
hosts, but every IP address between
the two are valid host IP addresses.
Network Number = 11010010
00110001 00011101 00000000
Broadcast Add. = 11010010
00110001 00011101 00011111
Network:
NW A

Subnet &
Network
Mask
Add.
210.49.29.0
210.49.29.0 210
/27

The next subnet will start with the

next number up from the broadcast
address. In this case, that’s
210.49.29.32. With a need for 10
valid host addresses, what will the
subnet mask be?
210.49.29.32 in binary: 11010010
00110001 00011101 00100000
/28 subnet mask:
11111111
11111111 11111111 11110000
Four host bits result in 14 valid IP
addresses, since 2 to the 4th power
is 16 and 16 − 2 = 14. We use a
subnet mask of /28 to have four host
bits remaining, resulting in a subnet
and mask of 210.49.29.32 /28, or

210.49.29.32 255.255.255.240.
Remember, the network number is
the value of the binary string with
all host bits set to zero and the
broadcast address is the value of
the binary string with all host bits
set to one.
Network Number = 11010010
00110001 00011101 00100000
Broadcast Add. = 11010010
00110001 00011101 00101111
Network:
NW A

Subnet &
Network
Mask
Add.
210.49.29.0
210.49.29.0
/27

NW B

210.49.29.32 210.49.29.32
/28

The next subnet is one value up
from that broadcast address, which
gives us 210.49.29.48. We need
seven valid host addresses. How
many host bits do we need?
210.49.29.48 in binary: 11010010
00110001 00011101 00110000
/28 subnet mask:
11111111
11111111 11111111 11110000
We still need four host bits - three
would give us only six valid IP
addresses. (Don’t forget to subtract
the two!) The subnet and mask are

210.49.29.48 255.255.255.240, or
210.49.29.48 /28. Calculate the
network number and broadcast
address as before.
Network Number = 11010010
00110001 00011101 00110000
Broadcast Add. = 11010010
00110001 00011101 00111111
Network:
NW A
NW B
NW C

Subnet &
Network
Mask
Add.
210.49.29.0
210.49.29.0
/27
210.49.29.32
210.49.29.32
/28
210.49.29.48
210.49.29.48
/28

The next value up from that
broadcast address is 210.49.29.64.
We need five valid IP addresses,
which three host bits will give us (2
to the 3rd power equals 8, 8 − 2 =
6).
210.49.29.64 in binary: 11010010
00110001 00011101 01000000
/29 subnet mask:
11111111
11111111 11111111 11111000
The subnet and mask are
210.49.29.64 255.255.255.248, or
210.49.29.64 /29. Calculate the
network number and broadcast
address as before, and bring the

VLSM table up to date.
Network Number = 11010010
00110001 00011101 01000000
Broadcast Add. = 11010010
00110001 00011101 01000111
Network:
NW A
NW B
NW C
NW D

Subnet &
Mask
210.49.29.0
/27
210.49.29.32
/28
210.49.29.48
/28
210.49.29.64
/29

Network
Add.
210.49.29.0
210.49.29.32
210.49.29.48
210.49.29.64

We’ve got one more subnet to
calculate, and that one needs only
three valid host addresses. What
will the network number and mask
be?
210.49.29.72 in binary: 11010010
00110001 00011101 01001000
/29 subnet mask:
11111111
11111111 11111111 11111000
We still need a /29 subnet mask,
because a /30 mask would yield
only two usable addresses. The
subnet and mask are 210.49.29.72
/29, or 210.49.29.72
255.255.255.248. Calculate the
network number and broadcast

address, and bring the VLSM table
up to date.
Network Number = 11010010
00110001 00011101 01001000
Broadcast Add. = 11010010
00110001 00011101 01001111
Network:
NW A
NW B
NW C
NW D

Subnet &
Mask
210.49.29.0
/27
210.49.29.32
/28
210.49.29.48
/28
210.49.29.64
/29

Network
Add.
210.49.29.0
210.49.29.32
210.49.29.48
210.49.29.64

NW E

210.49.29.72
210.49.29.72
/29

And now you’re done! The next
subnet would be 210.49.29.80, and
the mask would of course be
determined by the number of host
addresses needed on the segment.
A final binary word:
You either know how to determine
the number of valid subnets, valid
hosts, or perform the subnetting
from scratch, or you don’t - and
how do you learn how to do it?
Practice.

You don’t need expensive practice
exams - the only thing you need is a
piece of paper and a pencil. Just
come up with your own scenarios!
All you need to do is choose a
major network number, then just
write down five or six different
requirements for the number of
valid host addresses needed for
each subnet.
iI can tell you from firsthand
experience that this is the best way
to get really, really good with
VLSM - just pick a network
number, write down five or six
different requirements for the

number of valid addresses needed,
and get to work!
Thanks again for purchasing my
ICND1 Study Guide, be sure to take
advantage of the free resources
listed in the next section, and all the
best to you in your studies and
career!
Chris Bryant
“The Computer Certification
Bulldog”

Free Resources for your CCENT
and CCNA exam success – and
beyond!
You’ll find over 325 free videos on
my YouTube channel, covering
several Cisco certifications now
and expanding to cover IP Version
6, the new CCNA and CCENT
exams, Network+, Security+, and
more in 2014!

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

On my main Udemy page, you’ll
find descriptions and links for my
free and almost-free Video Boot
Camps on that site, including
courses for the CCNA, CCENT,
CCNP, CCNA Security, and more to
come in 2014!
All paid courses have a 60%
discount code on their main pages!

https://www.udemy.com/u/chrisbryan
Twitter:

https://twitter.com/ccie12933
Website:
http://www.thebryantadvantage.com
(That site’s getting a major overhaul
in Dec. 2013 and Jan 2014, bear
with us!)
Facebook: http://on.fb.me/nlT8SD
See you there! -- Chris B.