You are on page 1of 1413

Welcome to your Bulldog Study

Guide for the CCNP ROUTE exam!
I know you’re anxious to get
started, so I’ll keep this short…
Your CCNP ROUTE exam prep
requires you to tackle some
complex subjects, with BGP,
multiarea
OSPF,
and
route
redistribution among them. In this
guide, you’ll find clear and
comprehensive explanations for
each and every one of these topics,
along with hundreds of illustrations
and configs from live Cisco routers.

(I do not use simulators in my books
or videos.)
Speaking of videos, I’ve added a
special feature to this ebook that’s
guaranteed to help you master these
complex concepts.
And just as exciting, these features
don’t cost anything!
At the end of each section, you’ll
find links to videos on my YouTube
computer
certification
video
training channel that are related to
the topic you just studied.

You’ll find Video Practice Exams,
5-minute Video Boot Camps, and
other video types - all of which
will help you nail this difficult
exam.
You’ll also find links to my free
CCNP ROUTE Video Boot Camp
on route redistribution and OSPF
stub areas, and my full 22-hour
CCNP ROUTE Video Boot Camp,
available on both DVD and in
downloadable format.
That last one’s not quite free, but in
a world of $500 video courses,
you’ll find the price to be quite

refreshing.
I also invite you to join me on
Twitter, Facebook, LinkedIn, and
other social media sites. I’m there
live every day and happy to chat
with you there!
‘Nuff said! Let’s get started …
… and as always, thanks for making
TBA part of your CCNP success
story!
Chris Bryant
CCIE #12933
“The Computer Certification

Bulldog”
Chris Bryant
CCIE #12933
“The Computer Certification
Bulldog”
chris@thebryantadvantage.com
Website:
http://www.thebryantadvantage.com/
Twitter:
http://www.twitter.com/ccie12933
Facebook: http://on.fb.me/gPq52d

Blog:
http://thebryantadvantage.blogspot.co

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

Free Resources To Help You
Pass The CCNP ROUTE
Exam!

In addition to this informationpacked CCNP ROUTE Study
Guide, TBA has literally dozens of
additional practice exams, Video
Boot Camps, and illustrated
tutorials to help you destroy this
exam!
First, for some videos!
My

YouTube

Computer

Certification Channel has quite a
few videos on the CCNP ROUTE
exam:

http://www.youtube.com/user/ccie12
I hope you’ll click “subscribe”
while you’re out there - I’m adding
new videos AND certifications on a
regular basis, including Security+,
Network+, and a new CCNA
Security course in 2012!
You’ll also find links to individual
videos on that channel at the end of
most chapters of this ebook.

I have a separate Videos &
Tutorials page on my website for
each of the CCNP exams - here’s
the page dedicated to ROUTE:

http://www.thebryantadvantage.com/C
Be sure to scroll ALL the way
down that page - there are links to
practice exams, tutorials, and Video
Boot Camps!
For future reference, or for review,
here are my pages for the SWITCH
and TSHOOT exams:
SWITCH:

http://www.thebryantadvantage.com/C
TSHOOT:

http://www.thebryantadvantage.com/C
I also have a Video Boot Camp
hosted on Udemy.com -- well,
actually, two of them!
The first is 100% free and is a
tremendous lab and lecture on route
redistribution and multiarea OSPF.
This is must-see material, my
friends… and you can watch it
online, or you can download it - or
both!

http://www.udemy.com/ccnp-routeboot-camp-redistribution-and-ospfstub-areas/
There’s also a full hour-long
preview from my CCNP ROUTE
DVD on that site:
http://www.udemy.com/ccnp-routeon-demand-video-boot-camp/
And should you choose to enroll in
that course OR get the DVD, please
remember to use this link and save
yourself $10!

http://www.thebryantadvantage.com/C
When I post new videos or
tutorials, or whenever there’s
important news in the computer
certification world, I always post it
on our Facebook and Twitter feeds
as well as the Bulldog Blog.
I urge you to click these links and
join us!
We have some great conversations
and the occasional giveaway out
there -- and if you have a question
or comment, just send it via Twitter

or leave it on Facebook! I’m
always happy to hear from you!
Twitter:
http://www.twitter.com/ccie12933
Facebook: http://on.fb.me/gPq52d

Bulldog
Blog:
http://thebryantadvantage.blogspot.co
The CCNP ROUTE exam is a tough
one. Use all of these resources in
addition to this study guide - and
thanks for making TBA part of your
CCNP success story!

Chris Bryant
CCIE #12933
“The
Computer
Bulldog”

Certification

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

Dedication
For Suzy and Squeaky

Always loved, never forgotten.

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

There’s only one way
to get my crystal-clear
CCNP ROUTE Video
Boot Camp instruction
--- and that’s directly
from TBA.
All of my Video
Boot Camp DVDs give
you a full, free HOUR

of training to let you
“Try Before You Buy”!
It’s this sweet and simple:
My CCNP Bulldog Boot Camps
DVDs have helped network admins
around the world - from the UK to
Australia, from Russia to the US become CCNPs.
No other DVD offers my crystalclear and concise instruction - and I
never use simulators in my labs.
And I don’t charge you an arm and a

leg for a DVD.
Even better - you can save $10 on
any DVD or Bulldog DVD Bundle
by following this link:

http://www.thebryantadvantage.com/C
I know you’ll be happy with any
and all of my Video Boot Camp
DVDs.
You have my word and my name on
it.
Chris Bryant
CCIE #12933
“The
Computer

Certification

Bulldog”
http://www.thebryantadvantage.com/

Copyright Information:
Cisco®, Cisco® Systems, CCIE™,
CCNP, CCNA, Cisco Certified
Network Administrator, Cisco
Certified Network Professional,
and Cisco Certified Internetwork
Expert are registered trademarks of
Cisco® Systems, Inc., and/or its
affiliates in the U.S. and certain
countries.
All other products and company
names
are
the
trademarks,
registered trademarks, and service
marks of the respective owners.

Throughout this Study Guide, The
Bryant Advantage has used its best
efforts to distinguish proprietary
trademarks from descriptive names
by following the capitalization
styles used by the manufacturer.
Disclaimer:
This publication, The Bryant
Advantage CCNP ROUTE Study
Guide, is designed and intended to
assist candidates in preparation for
the CCNP ROUTE exam for the
Cisco
Certified
Network
Professional ® certification.

All efforts have been made by the
author to make this book as accurate
and complete as possible, but no
guarantee, warranty, or fitness are
implied, expressly or implicitly.
The enclosed material is presented
on an “as is” basis.
Neither the author, The Bryant
Advantage, Incorporated, or the
parent company assume any
liability or responsibility to any
person or entity with respect to loss
or damages incurred from the
information contained in this
workbook.

This Course Guide is an original
work by the Author. Any
similarities between materials
presented in this Study Guide and
actual CCNP® exam questions are
completely coincidental.
Copyright 2012 © The Bryant
Advantage

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

Table Of Contents

Introduction:
Free Resources For The
CCNP ROUTE Exam:
Dedication:
DVD Discount Offer:
Legal Notices:
IP Routing Fundamentals:

EIGRP Fundamentals:
EIGRP Intermediate and
Advanced Skills:
Link State Protocols And
Single-Area OSPF:
Multi-Area OSPF And
OSPF Route Redistribution:
BGP:
Remote Workplace: VPNs
and IPSec:
Remote Workplace, Part II
:

IP Version 6:
Route Redistribution:
Bonus Section: Creating A
VLSM Scheme:
More VLSM!:

IP Routing Fundamentals

Okay, I know what you’re thinking!
“I’m a CCNA already, I already
studied RIP, I know all the Distance
Vector stuff, I know my admin
distances. Let’s get to the new
stuff!”
Before we do that, we’re going to
take some time to review and
master some fundamental routing
skills …
… because without that mastery, we

can’t become truly great.
And while I know you’re familiar
with these protocols, this chapter is
going to be more than a review for
you - it’s going to sharpen your
skills with these critical protocols
to the point where the CCNP
ROUTE questions will be child’s
play for you.
There’s also more than a little
material in this section that will
help you big time on your CCNP
TSHOOT exam as well.
Sooooo…..

Let’s get started!
How and Where Distance Vector
Protocols Operate
Typically, distance vector protocols
are used on Local Area Networks
(LANs). While DV protocols work
well in smaller and more stable
environments, they have several
drawbacks that prevent them from
being used as Wide Area Network
(WAN) protocols.
One drawback is that RIP
broadcasts routing updates every 30
seconds, as illustrated by show ip

protocols:
R5#show ip protocols
Routing Protocol is “rip”
Sending updates every 30 seconds, next
due in 16 seconds Invalid after 180
seconds, hold down 180, flushed after 240

RIPv1 will broadcast full routing
tables as the update, regardless of
whether anything has actually
changed since the last update. This
is a waste of bandwidth and
resources, since your average
LAN’s subnets aren’t going to
change every minute. (We hope!)

RIPv2 multicasts updates to
224.0.0.9 rather than broadcasting
them, but the updates are still sent
out every 30 seconds.
In a larger network, another
problem arises. RIP routing updates
can hold a maximum of 25 routes,
so if there are 105 routes in your
network, five separate update
packets would be needed. Since
these updates would go out every
30 seconds, whether anything had
actually changed in the network,
RIP is generally a poor choice for a
WAN protocol.

Remember, everything we do on a
router has a cost to that router and
others - a cost in CPU, bandwidth,
and time. Those continual RIP
updates have a high cost and very
little value.
Drawback 2: RIPv1 is a classful
routing protocol, and therefore does
not support VLSM. The only masks
RIPv1 understands are the classful
masks for Class A (255.0.0.0),
Class B (255.255.0.0), and Class C
(255.255.255.0).
Drawback 3: Both versions of RIP
only understand hop count -

literally, how many “hops” there
are from Point A to Point B. On a
LAN, this really isn’t a problem,
but RIP’s limitations quickly
become a problem on a WAN.

There are two paths between A and
B. The path using the two T1 lines
is much faster than the 56 kbps path,

but RIP will see these paths as
equals. RIP’s routing algorithm, the
Bellman-Ford algorithm, considers
only hop count in computing its
metric.
In this example, RIP will then
perform equal-cost load balancing
over the two links. (DV protocols
perform equal-cost load balancing
over four paths by default.)
Default DV Protocol Behaviors
DV protocols do have some
drawbacks, but they also have some
default behaviors that help prevent

routing loops. You saw all of these
in your CCNA studies, but let’s do a
quick review.
Split Horizon simply means that a
routing protocol cannot advertise a
route via the same interface upon
which it was learned. Here, Router
3 cannot advertise the loopback
network 2.0.0.0 via its ethernet
interface, because that is the
interface upon which the router first
learned about the network.

Poison Reverse allows a router to
advertise a network with an metric
of “unreachable” when that network
becomes unavailable. This allows
the other routers to learn that the
network is unreachable much faster
than if it were left up to the normal
DV protocol behaviors -- and in
turn, that results in fewer misrouted
/ lost packets.

It’s obviously in our best interest to
have the quickest convergence time
possible. If some routers think
“network A” is available and others
think the network is unavailable,
routing for that network is going to
be substandard at best and routing
loops can easily form.

The Basics Of RIPv1, RIPv2, and
EIGRP
RIPv1:
Broadcasts updates every 30
seconds
Classful, does not recognize
VLSM, update carries entire
routing table
Uses Bellman-Ford algorithm
Equal-cost load shares by

default, max hop count is 15
No routing update
authentication available
Updates carry 25 routes max
RIPv2:
Multicasts updates every 30
seconds to 224.0.0.9
Classless, supports VLSM,
update carries entire routing

table
Uses Bellman-Ford and
default equal-cost load
sharing, max hop count is 15,
updates carry 25 routes max
Supports routing update
authentication (clear-text and
MD5)
EIGRP:
Multicasts to 224.0.0.10

Sends entire routing table only
when the adjacency is first
formed
Sends only routing update after
that when necessary, update
reflects only the changes
Uses DUAL routing algorithm
Equal-cost load sharing by
default, unequal-cost load
sharing configured with the
variance command

EIGRP is not a pure distance-vector
protocol, but I’ve put it here for
easy comparison to RIP. I also
didn’t go into a discussion of
EIGRP here, since we’ll be doing
plenty of that later in the course.
The Role
Distance

Of

Administrative

When a route lookup is performed
in a routing table, there may be
more than one path that meets the
criteria
for
being selected.
Basically, there is a four-step
process a router goes through when

looking for the best route to use:
1. If there are multiple routes
to a destination, the route with
the longest prefix length is
used.
2. If there are multiple routes
to a destination and they have
the same prefix length, the
route with the lowest
administrative distance is
used.
3. If there are multiple routes
with the same prefix length and

AD, the route with the lowest
metric is used.
4. If there are multiple routes
with the same prefix length,
AD, and metric, all of these
routes will be used in load
balancing as allowed by the
protocol.
Consider a router that is looking
through its routing table to decide
the next-hop IP address to use to
reach the destination 222.1.3.1.
I’m going to use IGRP in this

example, but please note that IGRP
is obsolete and is no longer tested
on Cisco certification exams.
In the unlikely but possible
circumstance that the router has one
path discovered by OSPF and
another by IGRP, the two paths
could look like this:
O: 222.1.3.0 /25 via 172.1.1.2, serial1
I: 222.1.3.0 /24 via 175.1.1.2, serial0

In this case, the OSPF route would
be chosen, because it is the longest
match; its mask is /25, a longer
match than IGRP’s classful mask of

/24. The administrative distance
(AD) does not come into use. But
what if the masks were the exact
same length?
O: 222.1.3.0 /24 via 172.1.1.2, serial1
I: 222.1.3.0 /24 via 175.1.1.2, serial0

A tiebreaker is needed, and that’s
where the AD comes in. The path
discovered by the protocol with the
lowest AD will be used. Since
IGRP’s AD is 100 and OSPF’s is
110, the IGRP path will actually be
used over the OSPF path.

AD values to know:
Directly connected route /
Static route using exit
interface: 0
Static route with next-hop IP
address: 1
EIGRP Summary: 5 (if you
know where to look -- more on
that later)
External BGP: 20

Internal EIGRP: 90
OSPF: 110
RIP: 120
External EIGRP: 170
Internal BGP: 200
Unknown network: 255
You may notice some differences

here from the ADs you learned in
earning your CCNA. There are now
two kinds of non-summary EIGRP
routes listed, internal and external.
Much more about those route types
in the EIGRP sessions.
Routing Table Operation
This entire operation is practically
transparent to you and I as network
admins, and that’s fine when things
go as we expect.
When things don’t go as we expect and when we’re studying for Cisco
exams! -- we better know the

“hows” and “whys” of the routing
table.
We love it when the router has
multiple paths to a given network!
That way, if we lose one path, we
have another - and we’ll take all the
redundancy we can get in today’s
delay-sensitive networks.
Now that we know how a routing
table is built, let’s take a closer
look at a small table and identify
the different values.
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF
external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS
level-2, ia - IS-IS inter area
* - candidate default, U - per-user static
route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
R
172.12.23.0/27 [120/1] via
172.12.123.2, 00:00:01, Serial0
[120/1] via
172.12.123.3, 00:00:04, Serial0
C
172.12.123.0/24 is directly
connected, Serial0

10.0.0.0/24 is subnetted, 1 subnets
C
10.1.1.0 is directly connected,
Ethernet0

There is one RIP route and two
directly connected routes. Since
we’re primarily interested in the
RIP route for this discussion, we’ll
run show ip route rip to see only
the routes that RIP has discovered.
R1#show ip route rip
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
R
R 172.12.23.0/27 [120/1] via
172.12.123.2, 00:00:04, Serial0
[120/1] via
172.12.123.3, 00:00:04, Serial0

The network 172.12.23.0/27 is the
destination. The numbers contained
in
the
brackets
are
the
administrative distance of the
protocol that discovered the route,
followed by the metric for that path.
Since this is a RIP route, the metric
shown is the number of hops to that
network.
The IP addresses following the
word “via” are the next-hop IP
addresses, followed by the time this
route was last refreshed. Since RIP
sends full routing updates every 30
seconds regardless of version, this
value will not exceed 30 seconds

for a valid RIP route unless the
holddown timers are in use.
Finally, each line ends by naming an
interface. This is the local interface
that data sent to this destination will
use to exit the router. It has nothing
to do with the downstream router.
In this example, we have two
separate paths listed for a single
destination. Remember the process
a router uses to determine the best
path? It’s worth repeating….
The route with the longest
prefix length will be selected.

The term “longest prefix
match” refers to the length of
the subnet mask.
If there are multiple routes
with the same prefix length, the
route with the lowest
administrative distance will be
used. Generally referred to as
“AD”, this is a measurement of
a protocol’s believability. The
lower the AD, the more
believable the protocol.
If there are multiple routes

with the same prefix length and
AD, the route with the lowest
metric will be preferred.
Finally, if the preceding three
values are all equal, equalcost load sharing will be put
into action.
The prefix length, administrative
distance, and metrics are all the
same. Therefore, RIP will use both
paths via equal-cost load sharing.
You can verify that load sharing is
in operation (and a lot of other

things!) by
protocols.

running

show

ip

In this example, we can also see
when the next routing update is
expected, what version of RIP
you’re running, whether routing
updates are being authenticated
(you would see a value under “Keychain” if authentication was in use),
and whether autosummarization is
on or off.
R1#show ip protocols
Routing Protocol is “rip”
Sending updates every 30 seconds, next
due in 7 seconds
Invalid after 180 seconds, hold down 180,
flushed after 240

Outgoing update filter list for all interfaces is
not set
Incoming update filter list for all interfaces is
not set
Redistributing: rip
Default version control: send version 2,
receive version 2

Interface

Send

R

Serial0

2

2

Automatic network summarization is not
in effect (autosummarization has been turned
off)
Maximum path: 4
Routing for Networks:
172.12.0.0
Routing Information Sources:

Gateway

Distance

172.12.123.3 120

172.12.123.2 120
Distance: (default is 120)

As great as dynamic routing
protocols are, I can guarantee you
that the time will come when you
need to use a routing method that
has less overhead. Maybe you’re
working with a router with very
limited resources; maybe you want
to have more personal control about
routing operations. There are
several methods you can use in
these scenarios, and the most
common are static routes and
default static routes.

Static Routing
Routing protocols are much more
effective in keeping an accurate
routing table, and adapt to network
changes much more quickly than
static routing - and it takes a lot less
of our time, too.
So why use static routing at all?
If a route has one IP address as the
next-hop address for every single
route in its table, why keep a full
dynamic routing table when a single
static default route will do?

As we’ll see in the Advanced
EIGRP and especially the multiarea
OSPF sections, this strategy is
actually built in to these dynamic
routing protocols.
Static routes can also serve as a
tourniquet of sorts for your network.
If something goes wrong with your
dynamic protocol and you need to
give your users a quick path to a
gateway that can get them where
they need to go, a quick static route
can give you (some) peace and
quiet while you fix the problem.
A static route can also serve as a

backup to a dynamic routing
protocols - a floating static route,
that is.
A floating static route is assigned an
administrative distance higher than
that of any dynamic protocol
running on the router, ensuring that
the only way the static route can be
used is if all dynamic routes leave
the table.
A default static route serves as a
router’s gateway of last resort.
Remember that a default static route
isn’t the path packets will take first,
it’s the path they’ll take if there is

no other match in the routing table
at all.
You learned how to configure a
static route in your CCNA studies,
but let’s quickly review the syntax:
R1(config)#ip route 3.3.3.3 255.255.255.255
172.12.123.3

R1(config)#ip route 3.3.3.3 255.255.255.255
serial0

These two static routes are both
host routes; that is, they are valid
for only one destination, in this case
3.3.3.3 /32. Note that the mask is a
subnet mask, not a wildcard mask.

In the first example, the IP address
at the end of the static route is the
next-hop IP address for the route. In
the second, the interface named at
the end of the static route is the
local exit interface.
You will never configure a static
route that uses a local IP address or
a remote interface name.
You’ll use the ip route command for
a default static route, but the IP
address and mask look rather odd:
R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.3
R1#show ip route

< code table removed for clarity >
Gateway of last resort is 172.12.123.3 to
network 0.0.0.0
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
R
172.12.23.0/27 [120/1] via
172.12.123.2, 00:00:14, Serial0
[120/1] via
172.12.123.3, 00:00:26, Serial0
C
172.12.123.0/24 is directly
connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C
10.1.1.0 is directly connected, Ethernet0
S*
0.0.0.0/0 [1/0] via 172.12.123.3

The ip route statement contains all
zeroes for both the destination and
mask. The gateway of last resort is
now set, and any data that does not

have a match in the routing table
will be sent to the next-hop address
172.12.123.3. The asterisk next to
the S indicates that this is a default
route.
The ip route statement for a default
route can also end with the local
exit interface:
R1(config)#ip route 0.0.0.0 0.0.0.0 serial0
R1#show ip route
< code table removed for clarity >
Gateway of last resort is 0.0.0.0 to network
0.0.0.0
172.12.0.0/16 is variably subnetted, 2

subnets, 2 masks
R
172.12.23.0/27 [120/1] via
172.12.123.2, 00:00:26, Serial0
[120/1] via
172.12.123.3, 00:00:08, Serial0
C
172.12.123.0/24 is directly
connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C
10.1.1.0 is directly connected, Ethernet0
S*
0.0.0.0/0 is directly connected, Serial0
R1#

While the gateway is now set to
0.0.0.0 rather than 172.12.123.3,
the net effect is the same. I
personally like to configure a
default static route with a specified
next-hop address, but it’s up to the
individual.

Floating Static Routes In Action
In this lab and all others in the
course, all IP addresses end with
the router’s number. For example,
R1’s Serial0 interface on the
172.12.123.0 /24 network has an IP
address of 172.12.123.1.
Note that RIP is not running over the
entire network -- it’s not running
over the serial link connecting R1
and R3’s serial1 interfaces.
R1/R2/R3

Frame

Network:

172.12.123.0 /24
R1 / R3 Serial
210.1.1.0 /24
R2 / R3 Ethernet
172.12.23.0 /27

Connection:
Network:

You might be wondering if there
will ever actually be a situation
where you wouldn’t run a dynamic
protocol over that link. If you’re

like me, you’re thinking “Why
wouldn’t I just run RIP over the link
and let the protocol figure all of this
out?”
Ordinarily we’d be happy to do
that, but in this case we’re being
asked not to use the S1 link unless
the S0 link goes down. That
happens more often than you might
think, for these reasons…
Bandwidth availability through
the S0 link is much higher than
that of the S1 link, but RIP will
see them as equal

Perhaps the S1 link flaps on
occasion and the S0 link is
considered to be much more
stable
Perhaps the client just doesn’t
want to listen to reason and
just doesn’t want to use that
link and just doesn’t want to
hear anything about it (this
happens on occasion, too)
Now let’s hit this lab!
R1 has two next-hop addresses for
the 172.12.23.0 /27 network:

R1#show ip route rip
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
R
172.12.23.0/27 [120/1] via
172.12.123.2, 00:00:04, Serial0
[120/1] via
172.12.123.3, 00:00:04, Serial0

We need a static route that will
appear in the routing table only if
those RIP links are gone, but we
also know the AD of a static route
is much lower than that of a RIPdiscovered route.
Here’s how we fix that:
R1(config)#ip
route
255.255.255.224 210.1.1.3 ?

172.12.23.0

<1-255>

name
permanent
tag

R1(config)#ip
route
255.255.255.224 210.1.1.3 200

Distance
metric for th
route
Specify
name of the
next hop
permane
route
Set tag fo
this route
172.12.23.0

Using the option to change the static
route’s administrative distance
(that’s what “distance metric for

this route” refers to) creates the
static route with an AD of 200. In
this case, anything higher than 120
will do.
We hope. Let’s check it out….
R1#show ip route
< code table removed for clarity >
172.12.0.0/16 is variably subnetted, 3
subnets, 2 masks
C
172.12.13.0/24 is directly connected,
Serial1
R
172.12.23.0/27 [120/1] via
172.12.123.2, 00:00:21, Serial0
[120/1] via
172.12.123.3, 00:00:05, Serial0
C
172.12.123.0/24 is directly
connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets

C
Ethernet0

10.1.1.0 is directly connected,

Now we need to test the config, and
since we’re in a lab environment,
we’ll close S0 and cut off the RIP
updates. The result:
R1#show ip route
< code table removed for clarity >
172.12.0.0/27 is subnetted, 1 subnets
172.12.23.0 [200/0] via 210.1.1.3
10.0.0.0/24 is subnetted, 1 subnets
C
10.1.1.0 is directly connected,
Ethernet0
C
210.1.1.0/24 is directly connected, Serial1
S

R1#ping 172.12.23.3
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.12.23.3,
timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 36/36/36 ms

When we reopen R1’s S0 interface,
the RIP updates will again be
received by R1 and the floating
static route will be removed from
the table due to its higher AD.
R1(config)#int s0
R1(config-if)#no shutdown

R1#show ip route
< code table removed for clarity >
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
R
172.12.23.0/27 [120/1] via

172.12.123.2, 00:00:17, Serial0
[120/1] via
172.12.123.3, 00:00:00, Serial0
C
172.12.123.0/24 is directly
connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C
10.1.1.0 is directly connected,
Ethernet0
C
210.1.1.0/24 is directly connected, Serial1

On-Demand Routing (ODR)
In today’s world, the phrase “OnDemand” brings to mind the latest
in technology, where you can watch
anything
from
my
Cisco
certification video training to the
latest episode of Pawn Stars or
Parking Wars anytime you like with

the push of a button or the click of a
mouse.
The latest and
technology, right?

greatest

in

Right! Except for “On-Demand
Routing” (ODR). ODR can come in
handy for one major reason:
Everything we do on a Cisco
router or switch has a cost, in
the form of CPU, bandwidth,
and / or time.
This is especially true of dynamic
routing protocols, so in small

networks with routers that don’t
have resources to spare, static
routing can be beneficial.
In a larger network, though, there is
the need for a middle ground
between static routing and running a
dynamic routing protocol. In Cisco,
this is ODR.
Why just Cisco? Because ODR uses
our old friend Cisco Discovery
Protocol (CDP). As you well know,
CDP is Cisco-proprietary, so if we
have a multivendor environment,
ODR is not a viable solution.

Make sure your ODR routers are
running CDP with show cdp.
On top of that, ODR is designed for
use only in a hub-and-spoke
network. If you have such a network
and the bandwidth is limited, ODR
may be an appropriate solution.
ODR also supports VLSM.
The spokes are going to use ODR to
send directly connected network
prefixes to the hub. The spoke will
use the IP address of the hub on the
common link as its default gateway.
By using only a single default route,
the spoke routers conserve their

resources.
Propagating A Default Route
With RIP, IGRP, And No IP
Routing
When it comes to default routing,
you’ve got three choices:
Use the ip route command
with all zeroes for the
destination address and subnet
mask
Use the ip default-network
command
Use the ip default-gateway

command
You’ve got the ip route command
down cold at this point, so let’s take
a closer look at ip default-network.
We’ll use the following network.
The common subnet is 172.12.123.0
/24. We want R1 to advertise its
directly
connected
network
100.1.1.0 /24 to R2 and R3 as a
default route.

The ip default-network command is
used to flag a network as a
candidate default route. The routers
are already running RIP over the

common subnet. R1 will now
introduce 100.1.1.0 /24 as the
default network.
R1(config)#ip default-network 100.1.1.0

R2 and R3 will see this route as a
default route discovered by RIP:
R2#show ip route
Codes: C - connected, S - static, I - IGRP, R RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2
- OSPF NSSA external type 2
E1 - OSPF external type 1, E2 OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS
level-2, ia - IS-IS inter area
* - candidate default, U - per-user

static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 172.12.123.1 to
network 0.0.0.0
2.0.0.0/32 is subnetted, 1 subnets
C
2.2.2.2 is directly connected,
Loopback0
172.12.0.0/24 is subnetted, 1 subnets
C
172.12.123.0 is directly connected,
Serial0
R*
0.0.0.0/0 [120/1] via 172.12.123.1,
00:02:20, Serial0

The default route named by ip
default-network didn’t have to be
manually redistributed into RIP. It’s
placed there automatically by the

router when this command is used.
Speaking of redistribution, we
could have created a default static
route on R1 and then redistributed it
into RIP. We’ll remove the ip
default-network command and do
just that.
R1(config)#no ip default-network 100.0.0.0
R1(config)#ip route 0.0.0.0 0.0.0.0 ethernet0
R1(config)#router rip
R1(config-router)#redistribute static metric 1

R2 and R3 will both see the default
route.
R2#show ip route rip
R*
0.0.0.0/0 [120/1] via 172.12.123.1,

00:00:12, Serial0
R3#show ip route rip
R*
0.0.0.0/0 [120/1] via 172.12.123.1,
00:00:02, Serial0

Much more redistribution to come!
IP Helper Addresses
While routers accept and generate
broadcasts, they do not forward
them. That can present quite a
problem with DHCP requests when
a router is between the requesting
host and the DHCP server. The
initial step in the DHCP process has
the
host
generating
a

DHCPDiscover packet - and that
packet is a broadcast.

If this PC attempts to locate a
DHCP server with a broadcast, the
broadcast will be stopped by the
router and will never get to the
DHCP server. By configuring the ip

helper-address command on the
router, UDP broadcasts such as this
will be translated into a unicast by
the
router,
making
the
communication possible.
The
command
should
be
configured on the interface that
will be receiving the broadcasts -not the interface closest to the
destination device.
R1(config)#int e0
R1(config-if)#ip helper-address ?
A.B.C.D IP destination address
R1(config-if)#ip helper-address 100.1.12

DHCP messages are not the only
broadcasts being relayed to the
correct destination with this
command -- there are nine of them.
TIME, port 37
TACACS, port 49
DNS, port 53
BOOTP/DHCP Server, port 67
BOOTP/DHCP Client, port 68

TFTP, port 69
NetBIOS name service, port
137
NetBIOS datagram service,
port 138
IEN-116 name service, port 42
That’s going to cover most
scenarios where the ip helper-

address command will be useful,
but what about those situations
where the broadcast you need
forwarded is not on this list? You
can use the ip forward-protocol
command to add any UDP port
number to the list.
To remove protocols from the list,
use the no ip forward-protocol
command. In the
following
example, we’ll add the Network
Time Protocol port to the
forwarding list while removing the
NetBIOS ports. Remember, you can
use IOS Help to get a list of
commonly filtered ports!

forward-protocol
udp ?
<0-65535> Port number
Biff (mail
biff
notification, comsat,
512)
Bootstrap
bootpc
Protocol (BOOTP)
client (68)
Bootstrap
bootps
Protocol (BOOTP)
server (67)

R1(config)#ip

discard

Discard (9)
DNSIX security

dnsix

protocol auditing
(195)
Domain Name
domain
Service (DNS, 53)
echo
Echo (7)
Internet Security
isakmp
Association and
(500)
Key Management
Protocol
Mobile IP
mobile-ip registration (434)
IEN116 name
nameserver service (obsolete,
42)
netbiosNetBios datagram
dgm
service (138)

NetBios name
service (137)
NetBios session
netbios-ss
service (139)
Network Time
ntp
Protocol (123)
pim-autoPIM Auto-RP
rp
(496)
Routing
Information
rip
Protocol (router,
in.routed, 520)
netbios-ns

snmp

Simple Network
Management
Protocol (161)
SNMP Traps

snmptrap

sunrpc

tacacs
talk
tftp
time
who

(162)
Sun Remote
Procedure Call
(111) syslog System
Logger (514)
TAC Access
Control System (49)
Talk (517)
Trivial File
Transfer Protocol
(69)
Time (37)
Who service
(rwho, 513)
X Display

xdmcp

Manager Control
Protocol (177)

<cr>
R1(config)#ip forward-protocol udp 123
R1(config)#no ip forward-protocol udp 137
R1(config)#no ip forward-protocol udp 138

Recommended Video Viewing:
Three-part Video Boot Camp on
Floating Static Routes on TBA
website:
http://bit.ly/bxNIBh
Three-part Video Boot Camp series

on Static Routes on TBA Website:
http://bit.ly/dourQ2
Free CCNP ROUTE Video Boot
Camp on route redistribution:
http://bit.ly/Arnhjq
My CCNP ROUTE Video Boot
Camp - Exclusive Discount Link
For My Ebook Readers Only!

Just click this link for a free hourlong preview AND $10 off the
already low price!
http://bit.ly/A7pLBu
Available for immediate download

and on DVD!

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

EIGRP Fundamentals

Introduction To EIGRP
Link state protocols (OSPF) and
distance vector protocols (RIP)
have clear-cut differences in the
way the best routes are determined
and what is actually exchanged
between routers. Just as a hybrid
plant has characteristics of more
than one plant, a hybrid routing
protocol has characteristics of both
link state and distance vector
protocols. The hybrid protocol is

Enhanced
Interior
Gateway
Routing Protocol – EIGRP.
EIGRP has a lot going for it:
Rapid convergence upon a
change in the network, because
backup routes (“Feasible
Successors”) are calculated
before they’re actually needed
due to the loss of a primary
route (“Successor”)
Offers multiprotocol support
(supports IP, IPX, and
AppleTalk)

Supports Variable-Length
Subnet Masking (VLSM) and
Classless Inter-Domain
Routing (CIDR)
The one little problem with EIGRP
is that it’s Cisco-proprietary,
making it unsuitable for a
multivendor environment.
EIGRP is the enhanced version of
the original Interior Gateway
Routing Protocol (IGRP), which is
no longer supported by new Cisco
IOSes and is no longer a part of

Cisco certification exams. I’ll
mention it occasionally in the
EIGRP sections for comparison’s
sake.
EIGRP acts like a distance vector
protocol in that EIGRP neighbors
initially exchange full routing
tables. Just about every other
EIGRP behavior is more like a link
state protocol.
Hello Packets and RTP: The
Heartbeat Of EIGRP
EIGRP uses
(multicast to

Hello packets
224.0.0.10) to

establish and maintain neighbor
relationships.
The
Reliable
Transport Protocol (RTP) is used
to handle the transport of messages
between EIGRP-enabled routers.
EIGRP also acts like a link state
protocol in that when network
topology changes occur, updates
containing only the change are sent,
rather than another full routing
table.
EIGRP uses autonomous systems to
identify routers that will belong to
the same logical group. EIGRP
routers that exist in separate
autonomous systems will not

exchange routes. They won’t even
become neighbors in the first place!
For an EIGRP neighbor relationship
to be established, the routers must
receive Hello packets from the
neighbor, the Autonomous System
number must match, and the metric
weights must match.
The metric weights refer to the
level of importance EIGRP gives to
the bandwidth, delay, load, and
reliability metrics. By default,
EIGRP considers bandwidth and
delay when calculating metrics, and
does not consider the other metric

weights.
Changing the metric weights is
covered in the Advanced EIGRP
section; for now, know that these
metric weights must be the same on
each router or the neighbor
relationship will not be established.
As with OSPF, once the neighbor
relationship is present, it is the
Hello packets that keep it alive. If
the Hellos are no longer received
by a router, the neighbor
relationship will eventually be
terminated.

The Successor
Successor

and

Feasible

EIGRP keeps three tables - the
route table, where the best route to
each destination is kept; the
topology table, where all feasible
routes are kept; and the neighbor
table, where the EIGRP neighbors
and information about them are
kept.
As an EIGRP-enabled router learns
about the network, the router will
put the best route to a given
destination in its routing table.
EIGRP keeps the best routes along

with less-desirable but still valid
routes in the topology table. EIGRP
actually calculates these backup
routes before a failure occurs,
making convergence after a failure
much faster than RIP.
The EIGRP term for the best route
is Successor. Any valid alternate
route is referred to as the Feasible
Successor. The decision process
for whether a route can become a
Feasible Successor can be summed
up in one question….
The EIGRP Feasible Successor
Question:

The router asks itself, “Is the
neighboring router’s metric for this
route lower than my metric?”
If so, no loop is present, and
that route is a Feasible
Successor.
If not, a loop may be present,
and that route cannot be a
Feasible Successor.
That’s all well and good - but what
if there is no Feasible Successor?
EIGRP uses the Diffusing Update
Algorithm (DUAL) to issue queries

to neighbors for a loop-free route to
the destination. If the routers
receiving the DUAL queries do not
have a route, those routers will also
send DUAL queries to their
neighbors. This process continues
until a route is found and the
original router is informed of the
route, or no valid route is found.
More about those queries later in
the two EIGRP sections.
EIGRP’s Major Advantage Over
RIP
EIGRP is Cisco-proprietary, and

RIPv2 is not. Both support VLSM,
so why not use RIPv2 over EIGRP?
Consider the following:

If you or I were asked what the
optimal path(s) are between R1 and

R2, we wouldn’t hesitate - T1 lines
run at 1544 kbps, almost thirty
times faster than a 56 kbps line, so
the extra “hop” over the R1 paths
will hardly matter.
EIGRP would agree with us, but
RIPv2 would not. RIPv2 does have
its uses, but it only considers hop
count as a metric. Therefore, RIPv2
would consider the path from R1R5-R2 the best path - and it’s
nowhere near the best path!
Since both EIGRP and OSPF
consider the speed of a link in its
calculations, we’re almost always

better off to use those two protocols
for our WANs. OSPF is not Ciscoproprietary, so if we do have some
non-Cisco routers (booooo!) in the
WAN, we could still use that
instead of RIPv2.
Configuring EIGRP
EIGRP uses Autonomous Systems
to put EIGRP-enabled routers into
logical groups. For two routers to
become EIGRP neighbors, they
must agree on the AS number. To
enable EIGRP on a particular
interface, we’ll use the network
command. The use of wildcard

masks is optional, but you’ll see
them in 99% of real-world EIGRP
deployments. Just watch that on the
exam - EIGRP and OSPF both use
wildcard masks in their network
statements, not subnet masks.

R1#conf t
R1(config)#router eigrp 100
R1(config-router)#no auto-summary
R1(config-router)#network
172.12.123.0
0.0.0.255
R2#conf t
R2(config)#router eigrp
router)#no auto-summary
R2(config-router)#network
0.0.0.255

100

R3(config)#router eigrp 100
R3(config-router)#network
0.0.255.255
R3(config-router)#no auto-summ

R2(config172.12.123.0

172.12.0.0

Note that I disabled autosummarization on all three routers.
EIGRP has autosummarization
running by default, and usually
you’re going to disable it even
before you enter your network
statements! You’ll see why - and
what can happen if you don’t
disable auto-summarization - later
in this chapter. You can also enter
the no auto-summary command
after your network statements, as
shown on R3.
Wildcard masks are used when
configuring network numbers in
EIGRP. This mask type allows the

configuration to be more specific in
what interfaces will be running
EIGRP. With the above wildcard
masks, any interfaces in the network
172.12.123.0 /24 will run EIGRP.
Wildcard Masks
Wildcard masks do look a little odd
at first, but since we use them in
access lists, EIGRP, and OSPF, we
better know how to configure them!
They’re really just “reverse subnet
masks”. For instance, the network
172.12.123.0 255.255.255.0 means

that all hosts that begin with
172.12.123 are part of that network.
When you write out the network
number and the mask in binary and
compare the two, the ones in the
subnet mask are “care” bits and the
zeroes are “don’t care” bits.
172.12.123.0
=
10101100
00001100 01111011 00000000
255.255.255.0
=
11111111
11111111 11111111 00000000
What do I mean by “care” and
“don’t care”? For a host to be on

the 172.12.123.0 /24 network, the
host’s address must match every bit
where there is a 1 in the network
mask. After that, I don’t care!
Wildcard masks take the opposite
approach. The zeroes are “I care”,
and the ones are “I don’t care”. In
this example, we want to enable
EIGRP on all interfaces whose first
three octets are 172.12.123, and
after that, we don’t care!
10101100 00001100 01111011
00000000 = 172.12.123.0
00000000

00000000

00000000

11111111 = 0.0.0.255
Using wildcard masks takes some
getting used to, and just make sure
to be careful on your exam:
Subnet masks begin with
strings of consecutive 1s
Wildcard masks begin with
strings of consecutive 0s and
are required in OSPF network
statements, but not EIGRP
network statements
Now let’s get back to our EIGRP
deployment!

A few seconds after configuring the
three routers with EIGRP, this
console message appears on R1:

The Diffusing Update Algorithm
(DUAL) has run and two new
neighbors,
172.12.123.2
and
172.12.123.3,
have
formed
adjacencies with R1. Show ip eigrp
neighbors gives the details:

The key values are the IP addresses
of the EIGRP AS 100 neighbors, the
interface on which they were
discovered, and the Uptime,
indicating how long the neighbor
relationship has existed.
The loopbacks on each router will
now be added to EIGRP 100, as
well as the Ethernet segment
between R2 and R3. The ethernet
segment’s network number is
172.23.23.0 /27, so we get a little
more practice with our wildcard
masks! The loopbacks all have their
router number for each octet, and
each loopback has been configured

with a host mask (255.255.255.255
or /32).

The additional configurations:

R1(config)#router eigrp 100
R1(config-router)#network 1.1.1.1 0.0.0.0
R2(config)#router eigrp 100
R2(config-router)#network 172.23.23.0 0.0.0.31
R2(config-router)#network 2.2.2.2 0.0.0.0
R3(config)#router eigrp 100
R3(config-router)#network 172.23.23.0 0.0.0.31
R3(config-router)#network 3.3.3.3 0.0.0.0

show ip route eigrp 100 is then run
at each router to ensure each router
is seeing the other routers’
loopbacks, and that R1 is seeing the
Ethernet segment via EIGRP. R2
and R3 are both directly connected
to the 172.23.23.0 /27 network, so

there will be no EIGRP route to that
network in their EIGRP tables.
The Successor routes appear in two
of our three EIGRP tables. The
EIGRP Route table, seen with show
ip route eigrp, contains only the
Successor routes. R1 has two
Successor routes for 172.23.23.0
/27.
R1#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D
2.2.2.2 [90/2297856] via
172.12.123.2, 00:01:01, Serial0
3.0.0.0/32 is subnetted, 1 subnets
D
3.3.3.3 [90/2297856] via
172.12.123.3, 00:00:58, Serial0
172.23.0.0/27 is subnetted, 1 subnets

D
172.23.23.0 [90/2195456] via
172.12.123.2, 00:01:01, Serial0
[90/2195456] via
172.12.123.3, 00:01:01, Serial0
R2#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D
1.1.1.1 [90/2297856] via
172.12.123.1, 00:01:33, Serial0
3.0.0.0/32 is subnetted, 1 subnets
D
3.3.3.3 [90/409600] via 172.23.23.3,
00:01:35, Ethernet0
R3#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D
1.1.1.1 [90/2297856] via
172.12.123.1, 00:01:46, Serial0
2.0.0.0/32 is subnetted, 1 subnets
D
2.2.2.2 [90/409600] via 172.23.23.2,
00:01:49, Ethernet0

As always, the first number in the
brackets
is
the
protocol’s
Administrative
Distance.
The
second number is the EIGRP metric
for that route.
Each router sees the other routers’
loopbacks, and can ping them (ping
results not shown). R1 can not only
ping the Ethernet interfaces of R2
and R3, but has two routes to that
subnet in its routing table. EIGRP is
performing
equal-cost
load
balancing.
The metric for the route is 2195456
for both routes, so data flows going

from R1 to the 172.23.23.0 /27
network will be balanced over the
two Frame Relay cloud links.
To see the Successor and Feasible
Successor routes in EIGRP, run
show ip eigrp topology. On R1,
two successors for the route
172.23.23.0/27 exist, so both are
placed into the routing table as seen
previously. There are also two
routes for destinations 2.2.2.2/32
and 3.3.3.3/32, but those have not
been placed into the EIGRP routing
table. Why?
R1#show ip eigrp topology
IP-EIGRP
Topology

Table

for

AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q Query, R - Reply,
r - reply Status, s - sia Status
P 3.3.3.3/32, 1 successors, FD is 2297856
via 172.12.123.3 (2297856/128256),
Serial0
via 172.12.123.2 (2323456/409600),
Serial0
P 2.2.2.2/32, 1 successors, FD is 2297856
via 172.12.123.2 (2297856/128256),
Serial0
via 172.12.123.3 (2323456/409600),
Serial0
P 1.1.1.1/32, 1 successors, FD is 128256
via Connected, Loopback0
P 172.23.23.0/27, 2 successors, FD is 2195456
via 172.12.123.3 (2195456/281600),
Serial0
via 172.12.123.2 (2195456/281600),
Serial0
P 172.12.123.0/24, 1 successors, FD is 2169856
via Connected, Serial0

R1 has two valid, loop-free routes
to 2.2.2.2/32 and 3.3.3.3/32 in its
Topology table…
P 3.3.3.3/32, 1 successors, FD is 2297856
via 172.12.123.3 (2297856/128256),
Serial0
via 172.12.123.2 (2323456/409600),
Serial0
P 2.2.2.2/32, 1 successors, FD is 2297856
via 172.12.123.2 (2297856/128256),
Serial0
via 172.12.123.3 (2323456/409600),
Serial0

…. but the metrics are unequal, so
only the best path (the Successor) is
placed into the EIGRP Route table.

R1#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D
2.2.2.2 [90/2297856]
172.12.123.2, 00:12:54, Serial0
3.0.0.0/32 is subnetted, 1 subnets
D
3.3.3.3 [90/2297856]
172.12.123.3, 00:12:51, Serial0
172.23.0.0/27 is subnetted, 1 subnets
D
172.23.23.0 [90/2195456]
172.12.123.2, 00:12:54, Serial0
[90/2195456]
172.12.123.3, 00:12:54, Serial0

via

via

via
via

The metrics for those routes are
very close, so close that it’s a good
idea for us to use both of them for
load balancing. We can use the
variance
command here
to
configure
unequal-cost
load
balancing.

The variance Command
The variance command is simply a
multiplier. The router will multiply
the Feasible Distance by this value.
Any feasible successor with a
metric less than that new value will
be entered into the routing table.
In print, that sounds a little
confusing. In reality, it’s simple, as
you’re about to see!
Consider the path from R1 to R2’s
loopback in the previous tables.
The primary route has a metric of
2297856; the other route has a

metric of 2323456. By default, the
second route will serve only as a
backup and will not carry packets
unless the primary goes down.
By configuring variance 2 in R1’s
EIGRP process, the process
multiplies the metric of the best
route (2297856) by the variance
value:
2297856 x 2 = 4595712
Any feasible successor with a
metric less than 4595712 will now
participate in unequal-cost load
sharing.

R1’s feasible successor to 2.2.2.2
has a metric of 2323456, so it
qualifies! After changing the
variance value to 2 (by default, it’s
1) and clearing the routing table,
show ip route eigrp 100 verifies
that two valid routes to both R2’s
and R3’s loopbacks appear in the
EIGRP routing table.
R1(config)#router eigrp 100
R1(config-router)#variance ?
<1-128> Metric variance multiplier
R1(config-router)#variance 2
R1#clear ip route * (clears the routing table of
all dynamically learned routes)

R1#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D
2.2.2.2 [90/2297856] via
172.12.123.2, 00:00:26, Serial0
[90/2323456] via
172.12.123.3, 00:00:26, Serial0 3.0.0.0/32 is
subnetted, 1 subnets
3.3.3.3 [90/2297856] via 172.12.123.3,
00:00:26, Serial0
[90/2323456] via
172.12.123.2, 00:00:26, Serial0
172.23.0.0/27 is subnetted, 1 subnets
D
172.23.23.0 [90/2195456] via
172.12.123.2, 00:00:26, Serial0
[90/2195456] via
172.12.123.3, 00:00:26, Serial0

The variance command does not
actually change the metrics; it
makes a higher metric acceptable

for load sharing.
Autosummarization - One Default
You’ll Want To Change
EIGRP and RIP version 2 perform
autosummarization by default,
which is the act of summarizing
network routes when those routes
are sent across a network boundary;
that is, when they are advertised via
an interface that is not part of the
network being summarized.
In the earlier lab, I disabled
autosummarization immediately, but

I will not do so here.
To illustrate, we’ll use a hub-andspoke network where both spokes
have subnets of 20.0.0.0/8. The
Serial interfaces are all on the
172.12.123.0 /24 network, with the
router number serving as the final
octet. All interfaces will be placed
into EIGRP AS 100.

Here are the current configurations.
I did not configure the autosummary command -- it’s on by
default and will appear in the router
configuration.
R1:
router eigrp 100
network 172.12.123.0 0.0.0.255
auto-summary

R2:
router eigrp 100
network 20.1.0.0 0.0.255.255

network 20.2.0.0 0.0.255.255
network 172.12.0.0
auto-summary

R3:
router eigrp 100
network 20.3.0.0 0.0.255.255
network 20.4.0.0 0.0.255.255
network 172.12.0.0
auto-summary

Network 20.0.0.0 is discontiguous
– there is no single path to all
subnets of the major network
number. That’s a problem for
routing protocols such as RIPv1 that
do not carry subnet mask

information.
EIGRP and RIPv2 do carry subnet
mask information, but the default
autosummarization causes trouble
with this network. R1 is now
receiving the exact same update
from both R2 and R3, and it’s for
the classful network 20.0.0.0 /8.

Here’s R1’s EIGRP route table.
None of the subnets are present in
the routing table.
R1#show ip route eigrp
D
20.0.0.0/8 [90/2297856] via
172.12.123.3, 00:11:19, Serial0
[90/2297856] via
172.12.123.2, 00:11:19, Serial0

Since the metrics for both paths are
exactly the same, equal-cost load
balancing for the classful network
20.0.0.0 will be performed,
ensuring that at least half of the
packets destined for any particular
subnet of 20.0.0.0 will be going to

the wrong router.
If the metric were unequal, a single
route for the classful network
20.0.0.0 would be placed into the
routing table. All packets for the
four subnets will go to the same
router, and two of the four subnets
will never receive any packets that
were originally intended for them.
I’ll ping each loopback IP address
from R1 - as you’d guess from that
routing table, we’re going to get
some really interesting results.
R1#ping 20.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.1.1.1,
timeout is 2 seconds:
!U!.!
Success rate is 60 percent (3/5), round-trip
min/avg/max = 68/68/68 ms
R1#ping 20.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.2,
timeout is 2 seconds:
U!.!U
Success rate is 40 percent (2/5), round-trip
min/avg/max = 68/68/68 ms
R1#ping 20.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.3.3.3,
timeout is 2 seconds:
U!.!U
Success rate is 40 percent (2/5), round-trip

min/avg/max = 68/68/68 ms
R1#ping 20.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.4.4.4,
timeout is 2 seconds:
!U!.!
Success rate is 60 percent (3/5), round-trip
min/avg/max = 68/68/68 ms

That is one ugly combination of
successful pings, timeouts, and
Unreachables - and an ugly success
rate as well.
This default behavior is easily
removed with the no auto-summary
command. When both of the routers
sending updates add this command

to their EIGRP configuration, the
routes will no longer be
summarized at the
network
boundary.
One often-ignored side effect of
adding no auto-summary to an
existing EIGRP configuration - the
adjacencies will drop.
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#^Z
R3#wr
00:26:09: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.12.123.1 (Serial0) is
down: summary configured

After configuring no auto-summary
on both R2 and R3 and waiting for
the adjacencies to reform, R1 now
has a much more accurate routing
table.
R1#show ip route eigrp
20.0.0.0/16 is subnetted, 4 subnets
D
20.4.0.0 [90/2297856]
172.12.123.3, 00:00:11, Serial0
D
20.1.0.0 [90/2297856]
172.12.123.2, 00:03:47, Serial0
D
20.2.0.0 [90/2297856]
172.12.123.2, 00:03:47, Serial0
D
20.3.0.0 [90/2297856]
172.12.123.3, 00:00:20, Serial0

via
via
via
via

Bottom line: If you’re running
EIGRP and you’re not seeing the
subnets or routes you expect, the
first thing I’d check is to see if the
no auto-summary command is in
the configuration. If it’s not, I’d put
it there.

router eigrp 100
network 20.3.0.0 0.0.255.255
network 20.4.0.0 0.0.255.255
network 172.12.0.0
auto-summary <<<< BEWARE!

Load
Sharing
And
maximum-paths command

:)

The

You’ve probably noticed that we
didn’t have to enter any commands
to perform equal-cost load
balancing with EIGRP. EIGRP will
enter four equal-cost routes to the
same destination into the routing
table by default, and this value can
be changed with the maximumpaths command to a minimum of

one and a maximum of 16.
R1(config)#router eigrp 100
R1(config-router)#maximum-paths ?
<1-16> Number of paths

Setting maximum-paths
disables load balancing.
DUAL
Queries
And
“Passive” Is A Good Thing

to

1

Why

EIGRP uses the Diffusing Update
Algorithm (DUAL) to calculate
routes, and there’s one other
important role DUAL plays in an
EIGRP deployment.

If a Successor route is lost and
there is no Feasible Successor,
we’ve got a problem! DUAL
doesn’t give up easily, though.
DUAL will mark the route as
Active, indicating that the route is
being calculated and cannot be used
to route data, and will send out a
Query message to all of that
router’s EIGRP neighbors.
A DUAL Query is basically one
neighbor asking another, “Hey, do
you know how to get to this network
I just lost my route to?” If that
neighbor has a route, the query will

be answered with that route. If the
neighbor doesn’t have such a route,
that neighbor will ask its neighbors.
The process continues until a
downstream router replies with the
desired route, or the EIGRP
downstream routers run out of
neighbors to ask.
Routes in the EIGRP Topology table
marked as Active are considered
unusable, since Active indicates
that the route is currently being
calculated by DUAL. Hopefully the
route comes out of Active very
quickly and becomes Passive, as

indicated by the “P” in the
following Topology table. When it
comes to EIGRP routes, Passive is
good and Active is bad!
R1#show ip eigrp topology
IP-EIGRP
Topology
Table
for
AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update,
Q - Query, R - Reply,
r - reply Status, s - sia Status
P 3.3.3.3/32, 1 successors, FD is 2297856
via 172.12.123.3 (2297856/128256),
Serial0
via 172.12.123.2 (2323456/409600),
Serial0
P 2.2.2.2/32, 1 successors, FD is 2297856
via 172.12.123.2 (2297856/128256),
Serial0
via 172.12.123.3 (2323456/409600),
Serial0

Back To Index
Recommended Video Viewing:
EIGRP Tables and Commands:
http://www.youtube.com/watch?
v=ZndBgShoxl4
Advanced EIGRP Concepts:
http://www.youtube.com/watch?
v=LPuXmiKznEI
Video Practice Exam on Route
Redistribution:

http://www.youtube.com/watch?
v=eY2yyRd0lvM
The Mystery Of The AD 5:
http://www.youtube.com/watch?
v=X9AzQCt7rCM
Free CCNP ROUTE Video Boot
Camp on route redistribution:
http://bit.ly/Arnhjq
Enjoy! -- Chris B.

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

Intermediate And Advanced
EIGRP Concepts And
Configuration

EIGRP Fundamentals
Let’s take a few minutes to review
EIGRP fundamentals and add to
those mentioned in the Basic EIGRP
section.
EIGRP is a Cisco-proprietary
protocol that improves greatly on
the original version of this protocol,

the Interior Gateway Routing
Protocol (IGRP). (The “E” in
EIGRP stands for enhanced.)
The benefits
include:

of using EIGRP

Support for Appletalk, IP, and
IPX (Novell Netware) via
protocol-dependent modules
(PDMs)
Support for variable-length
subnet masking (VLSM)
Dynamic neighbor discovery

via packets multicast to
224.0.0.10
Fast convergence after
network topology changes backup routes are actually
calculated and placed into a
table in advance of their
actually being needed. (Note:
This table is NOT the IP
routing table.)
Where RIP sends routing
updates every 30 seconds,
even if nothing has changed,

EIGRP will send routing
updates only when a network
topology change actually
occurs.
EIGRP updates do not contain
the entire routing table, but
reflect only the routes that
have been changed.
The scope of these updates is
limited to the routers that
actually need them - they’re
not flooded.

Those last two points might not
sound like much, but everything we
do on a Cisco router has a cost in
CPU and time. If your routing table
has 105 routes and only 1 has
changed, why take the time to create
an update for every single route
when an update reflecting only the
change will serve our purpose?
EIGRP’s routing algorithm is the
Diffusing
Update
Algorithm
(DUAL). DUAL not only calculates
routes that ensure a loop-free
network, but also calculates backup
routes before they’re needed.

These backup routes, the feasible
successors, are kept in the EIGRP
topology table. The primary routes,
the successors, are kept in both the
EIGRP topology and route tables.
EIGRP’s third table is the neighbor
table, which contains just what you
would think it does - information
about EIGRP neighbors.
EIGRP is a classless routing
protocol, which means it supports
Variable Length Subnet Masking
(VLSM). EIGRP routing update
packets contain a prefix length for
each individual network, making
VLSM support possible.

EIGRP uses metric weights to
determine how important certain
values are in route calculation. By
default, bandwidth and delay are
the only metric values used in route
calculation. The other metric
weights, or “k-weights”, are load,
reliability, and MTU.
You can change the bandwidth and
delay values to alter EIGRP path
selection. If you’re changing any
EIGRP values to fine-tune your
routing table, I’d go with bandwidth
as it’s simply easier to get the
desired results.

The bandwidth command is entered
in kbps and should be set to the
minimum bandwidth of the path.
The delay command is configured
in tens of microseconds. As you’d
guess, the bandwidth command is
easier to use for fine-tuning routes.
R1(config)#int s0
R1(config-if)#bandwidth ?
<1-10000000> Bandwidth in kilobits
R1(config-if)#bandwidth 64
R1(config-if)#delay ?
<1-16777215> Throughput delay (tens of
microseconds)

Since DUAL actually calculates

backup routes before they’re even
needed, EIGRP responds to
topology changes faster than RIP
(which isn’t saying much) and
OSPF (which is saying a lot). With
EIGRP, routing loops have literally
no time to form.
EIGRP will perform equal-cost
load-sharing over four paths by
default, with a maximum of 16
paths. That value is configurable
with the maximum-paths command.
R1(config)#router eigrp 100
R1(config-router)#maximum-paths ?
<1-16> Number of paths

We can also perform unequal-cost
load balancing with EIGRP, and
we’ll practice that skill later in this
section.
Almost all EIGRP packets are
multicast to 224.0.0.10, and use IP
protocol number 88. Let’s take a
look at the different EIGRP packet
types… and see if we can spot that
exception to the multicast rule.
EIGRP Packet Types And RTP
EIGRP uses the Reliable Transport
Protocol (RTP) to handle the
guaranteed and reliable delivery of

EIGRP packets to neighbors.
“Guaranteed and reliable” sounds a
lot like TCP, but the two are quite
different in how they operate. Not
all EIGRP packets are going to be
sent reliably.
Hello packets are used for
neighbor discovery and to
keep existing neighbor
relationships alive; these are
multicast to 224.0.0.10.
Acknowledgement packets
themselves are simply hello
packets that contain no data.

Neither Acks nor Hellos use
RTP, and are therefore
considered unreliable.
Update packets are sent to
new neighbors to allow the
neighbor to build an accurate
routing and topology table, and
are also sent when a change in
the network occurs. Update
packets are generally multicast
packets, but there’s one
important exception that you’ll
read about later in this section.

Query packets are sent when a
router loses a successor route
and has no feasible successor.
Reply packets are sent in
response to query packets, and
a reply packet indicates that a
new route to the destination
has been found. Update, query,
and reply packets all use RTP
and are considered reliable.

To see how many of these packets
have passed through a router, run
show ip eigrp traffic.

R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100
Hellos sent/received: 2/2
Updates sent/received: 13/4
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 0/2
Input queue high water mark 1, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0

To review: Hello and ACK packets
are unreliable. Reply, Query, and
Update packets are reliable.
That’s a handy troubleshooting
command, too. If the Query, Reply,
and Update values remain the same
over a period of time, your network
is stable.

If they’re constantly incrementing,
there’s a problem. The Query and
Reply values will increment only if
a successor route is lost. If you see
those incrementing regularly, you
have yourself a flapping link
(believe me, I’ve been there). If the
SIA values are incrementing along
with them, that’s not good - more on
that later in this part of the course.

How EIGRP Routers Become
Neighbors
EIGRP

routers

form

neighbor

relationships, and after the initial
exchange of routing updates
between neighbors, EIGRP routers
will then only send routing updates
when there is a change in the
network topology. These neighbor
relationships, or adjacencies, begin
when a router first has EIGRP
enabled on some or all of its
interfaces with the router eigrp
command.
In the following example, R1 is
running EIGRP on a Serial
interface. R1 will multicast an
EIGRP Hello packet to 224.0.0.10
out that interface in an attempt to

find potential neighbors.

A downstream router, R2, receives
this Hello. If certain values are
agreed upon between the two, R2
will respond with an EIGRP Update
packet, which contains all the
EIGRP-derived routes that R2
knows.

Did you notice that the EIGRP
Update packet going back to R1
was a unicast? Generally, EIGRP
Update packets are multicast to
224.0.0.10, just as EIGRP Hello
packets are.
There’s almost always an exception
in networking, and that’s true here
as well. Update packets are unicast
in this particular situation, but

otherwise they’re multicast.
R1 will
send an EIGRP
Acknowledgement packet, or ack,
to let R2 know the routes in the
Update packet were received. R1
will also send an Update packet of
its own, unicast to R2, containing
all EIGRP routes R1 has. R2 will
respond with an ack of its own.

Other EIGRP Adjacency Issues
(And Non-Issues)
Unlike OSPF, EIGRP does not
require neighbors to agree on hello
and dead times. The EIGRP hold
time has the same function as OSPF
dead time - they’re both the
duration of time in which a hello
must be received in order to retain
the neighbor relationship. The
default EIGRP hold time is three
times the hello time.
In the following example, an
adjacency has been formed between
R2 and R3 using the default values

for hello and hold times as well as
the metric weights. The router
eigrp command indicates that both
routers are in EIGRP Autonomous
System (AS) 100. The AS is a
logical group of EIGRP-speaking
routers, and this value must match
between potential neighbors.
Routers must agree on the EIGRP
AS number in order to become
neighbors, and the interfaces
through which the adjacency is to
form must be on the same IP subnet.
In the following example, both
routers will be placed into EIGRP
100 via the following interfaces:

R2: Ethernet0, 172.12.23.2 /24
R3: Ethernet0, 172.12.23.3 /24
R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network
172.12.23.0
0.0.0.255
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network
172.12.23.0
0.0.0.255

show ip eigrp neighbor verifies
that R3 is a neighbor of R2.

Let’s change the hello timers on
R2’s Ethernet 0 interface and see
what happens to the adjacency. I’ve
disabled EIGRP event logging for
the following example.

Note the uptime of 12 seconds. That
indicates that the EIGRP adjacency
did drop, but it came right back up.
The mismatched Hello timers didn’t
prevent the adjacency from forming
again, but what about a change in

the metric weights?
R2(config)#router eigrp 100
R2(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0
supported)
R2(config-router)#metric weights 0 1 1 1 1 1
R2#show ip eigrp neighbor
IP-EIGRP neighbors for process 100
R2#

show ip eigrp neighbor shows us
nothing because there’s no neighbor
to show! We can wait a long, long
time for that adjacency to come
back, but it’s not going to. Potential
EIGRP neighbors must agree on the

AS number and all metric weight
settings in order to become
neighbors.
A great command to begin
troubleshooting adjacencies with is
debug eigrp packets, and if there’s
a metric weights mismatch, you’ll
see the following:
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY,
REPLY, HELLO, IPXSAP, PROBE, ACK,
STUB, SIAQUERY, SIAREPLY)
R2#
01:10:00: EIGRP: Received HELLO on
Ethernet0 nbr 172.23.23.3
01:10:00: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0
01:10:00: K-value mismatch

The K-value mismatch message
indicates a problem with the metric
weight setting.
In short, EIGRP neighbors must….
… reside in the same
EIGRP AS
… be on the same subnet
… have matching metric
weights
A quick note on that ip hello eigrp
command - unlike OSPF, changing
the EIGRP hello time does not

dynamically change the hold time
(dead time).
EIGRP Hello Packets
Hello packets find potential
neighbors and also keep neighbor
relationships alive. On a high-speed
link, EIGRP Hello packets are sent
every 5 seconds; on slower links,
Hellos are sent every 60 seconds.
High-speed links include broadcast
technologies such as Ethernet,
FDDI, and our old friend Token
Ring; high bandwidth (over T1
speed) multipoint circuits, including

ISDN Primary Rate Interface and
Frame Relay; both Frame Relay and
ATM point-to-point subinterfaces;
and finally, point-to-point serial
links, such as PPP and HDLC
circuits.
After that list, you might think there
aren’t any interface types left, but
there are!
Low-speed links include multipoint
circuits running at less than T1
speed, such as ATM switched
virtual circuits and multipoint
interfaces, Frame Relay multipoint
interfaces, and ISDN Basic Rate

Interface.
An EIGRP neighbor relationship is
declared dead when three hello
packets are missed, meaning the
EIGRP dead time on an ethernet
segment is 15 seconds and 180
seconds on an NBMA interface
such as a Serial interface. If you
change the hello transmission time,
Cisco recommends you change the
hold time as well to keep it to three
times the hello value.
To
verify
EIGRP
neighbor
relationships, run show ip eigrp
neighbors.

From left to right, let’s examine the
meaning of these categories:
IP-EIGRP neighbors for process
100 - The AS these neighbors are
contained in.
H - The order in which the
neighbors were discovered.
Address - The IP address of the
neighbor.
Interface - The interface upon
which the router is receiving hellos.

Hold - Short for holdtime, the
number of seconds the router will
wait until it declares this particular
adjacency dead.
Uptime - The amount of time since
this neighbor was first heard from.
SRTT - Smooth Round-Trip Time.
This is the number of milliseconds
it takes for an EIGRP packet to be
sent to that neighbor and the amount
of time it takes to get an ACK from
that neighbor.
RTO - Retransmission TimeOut.
The amount of time the software

will wait until it retransmits a
packet to a neighbor.
Q Cnt - Queue Count. The number
of EIGRP packets waiting to be
sent.
Seq Num - Sequence Number. This
is the sequence number of the last
update, reply, or query packet that
was received from this particular
neighbor.
To debug EIGRP adjacencies,
you’ve got two options. You can run
debug eigrp neighbors, or debug ip
eigrp neighbor
<AS> <IP

ADDRESS>. Personally, I use
debug eigrp neighbors first, and if
I don’t get the information I need,
I’ll use debug ip eigrp neighbor.
The output of debug eigrp
neighbors looks like this during an
adjacency:
6d00h: EIGRP: Neighbor(172.12.123.3) not yet
found
6d00h: EIGRP: Neighbor(172.12.123.2) not yet
found
6d00h:
found
6d00h:
found
6d00h:
found
6d00h:

EIGRP: Neighbor(172.12.123.3) not yet
EIGRP: Neighbor(172.12.123.2) not yet
EIGRP: Neighbor(172.12.123.3) not yet
EIGRP: Neighbor(172.12.123.2) not yet

found
6d00h: EIGRP: New peer 172.12.123.2
6d00h: EIGRP: New peer 172.12.123.3

EIGRP
Adjacencies
Secondary Addresses

And

Technically, EIGRP will not form
adjacencies
using
secondary
addresses.
Even though it looks like it will.
Let’s take a look at R2 and R3,
which will be using secondary
addresses to form an EIGRP
adjacency over an ethernet segment.

R2(config)#interface ethernet0
R2(config-if)#ip
address
255.255.255.0
R2(config-if)#ip
address
255.255.255.0 secondary

172.12.23.2
23.23.23.2

R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network 23.23.23.0 0.0.0.255

R3(config)#interface ethernet0
R3(config-if)#ip
address
255.255.255.0
R3(config-if)#ip
address
255.255.255.0 secondary

172.12.23.3
23.23.23.3

R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network 23.23.23.0 0.0.0.255

Here’s the partial output of show ip
eigrp neighbor on R3:
R3#show ip eigrp neighbor
IP-EIGRP neighbors for process 100
H Address
Interface
0

172.12.23.2

Et0

The adjacency has formed!
However, the secondary addresses
were not used to form the
adjacency. Note the address is
actually the primary IP address on
the interface, even though we used
the secondary network number in
the EIGRP network command.

How EIGRP Routers Determine
Successors
And
Feasible
Successors
Once
the
EIGRP
neighbor
relationships form, DUAL will
begin sending a series of queries
and responses, and these responses
are used to build the EIGRP
topology table.
These queries and responses are
sent by the Reliable Transport
Protocol (RTP). As mentioned
earlier, show ip eigrp traffic will
display the number of queries and
replies that have been sent and

received.
R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100
Hellos sent/received: 110457/115367
Updates sent/received: 43/17
Queries sent/received: 4/0
Replies sent/received: 0/4
Acks sent/received: 14/21
Input queue high water mark 2, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0

Let’s take a look at a typical EIGRP
topology table.
R1#show ip eigrp topology
IP-EIGRP
Topology
AS(100)/ID(11.1.1.1)

Table

for

Codes: P - Passive, A - Active, U - Update, Q Query, R - Reply,
r - reply Status, s - sia Status
P 1.1.1.1/32, 1 successors, FD is 128256
via Connected, Loopback0
P 2.0.0.0/8, 1 successors, FD is 2297856
via
172.12.123.2
(2297856/128256), Serial0
via
172.12.123.3
(2323456/409600), Serial0
P 3.0.0.0/8, 1 successors, FD is 2297856
via
172.12.123.3
(2297856/128256), Serial0
via
172.12.123.2
(2323456/409600), Serial0
P 172.23.0.0/16, 2 successors, FD is
2195456
via
172.12.123.3
(2195456/281600), Serial0
via
172.12.123.2
(2195456/281600), Serial0

P 172.12.123.0/24, 1 successors, FD is 2169856
via Connected, Serial0

EIGRP will keep up to six valid
routes for any given destination.
Those six routes don’t have to be
made up of one successor and five
feasible successors, either - when
equal-cost load sharing is in effect
as it is for the 172.23.0.0 /16 route
in the above topology table, there
will be multiple successor routes.
“SIA” -- Stuck In Active
Regarding those codes, notice that
all the routes in this table have a

“P” next to them, indicating that
these routes are passive. Another
code shown is “A”, for Active.
While an “active route” sounds like
a good thing, we want to avoid them
in EIGRP.
If a route shows as Active in the
EIGRP topology table, that means
the successor for that route has been
lost and that no feasible successor
was immediately available in the
topology table.
When a route is Passive, that means
it’s not being recalculated and it’s a
usable route.

Generally, an Active route will be
that way for a very short time; by
the time you repeat show ip eigrp
topology, it’s likely that Active
route has gone Passive. That
cutover from Active to Passive is
so fast that you can work with
EIGRP for a long time without even
seeing an Active route.
Sometimes that cutover doesn’t
happen at all, and the route
becomes SIA - Stuck In Active.
SIA routes begin innocently enough.
When an EIGRP router loses a
Successor route, it looks in its

topology table for a Feasible
Successor. If there is no Feasible
Successor, that router will send
DUAL Query packets to its
neighbors, asking them if they have
a valid route to the nowunreachable destination.

If the router receiving the query
doesn’t have a valid, loop-free
route to the destination in question,

that router will in turn ask all of its
neighbors for such a route - and
they’ll ask two friends, and they’ll
ask two friends, until a route is
discovered or it’s determined that
no queried router has a route.
That default time is three minutes
and can be changed with the timers
active-time command in your
EIGRP configuration.
R1(config)#router eigrp 100
R1(config-router)#timers ?
active-time EIGRP time limit for active state
R1(config-router)#timers active-time ?
<1-4294967295> EIGRP active-state time
limit in minutes

disabled
limit for active state
<cr>

disable EIGRP time

R1(config-router)#timers active-time 5

Two things to note in this command:
IOS Help shows us the
numeric value is minutes.
Always use IOS Help to verify
the value of any time-based or
unit-based (MB, GB, etc)
command.
With many Cisco commands,
setting a numeric value to zero
disables that particular feature

- but you can’t set this one to
zero. To disable the time limit,
use the disabled option.
If R8 doesn’t answer that query
within the timers active-time value,
the route is Stuck In Active - SIA.
From experience, I can tell you that
troubleshooting SIA routes is more
of an art form than a science, but
there are four main reasons a route
becomes SIA:
The link is unidirectional, so
the query can’t possibly be

answered.
The queried router’s resources
are unavailable, generally due
to high CPU utilization.
The queried router’s memory
is corrupt or otherwise unable
to allow the router to answer
the query.
The link between the two
routers is of low quality,
allowing just enough packets
through to keep the neighbor

relationship intact, but not
good enough to allow the
replies through.
To sum it up, routes generally
become SIA when a neighbor either
doesn’t answer a query, or either
the query or reply took a wrong turn
somewhere.
Glad I could narrow that down for
you. : )
In real-world networking, resolving
SIA routes is much more of an art
form than a science. A little

Googling will show you just what I
mean.
In my experience, the most common
real-world causes of SIA are
problems with the neighboring
router - either that it’s just too busy
to answer and it has no CPU to
spare, or that it doesn’t have the
memory to handle the query in the
first place.
What SIA Routes Look Like
If you have eigrp log-neighborchanges running, the message you
get to indicate a route is SIA looks

like this:
Route 100.1.4.0/24 stuck-in-active state in IPEIGRP-100

With the same log command
running, a neighbor that does not
respond to a query will result in
this log entry:
neighbor 90.1.1.1 (Serial0) is down: stuck in
active

Another method of spotting SIA
issues is in the EIGRP topology
table. If you see a lower-case “r”
next to an IP address where the
Active route is shown, that means a

query packet has been sent to that IP
address and it has not yet been
answered. This code is shown at
the top of the EIGRP topology table.
Codes: P - Passive, A - Active, U - Update, Q Query, R - Reply,
r - reply Status, s - sia Status

The Variance Command And
Unequal-Cost Load Sharing
Often, we’ll have two or more
quality paths that we want EIGRP to
use. If the metrics aren’t exactly the
same, by default EIGRP will use
only the successor, as shown here:

R1#show ip eigrp topology
IP-EIGRP
Topology
AS(100)/ID(11.1.1.1)

Table

for

P 3.0.0.0/8, 1 successors, FD is 2297856
via
172.12.123.3
(2297856/128256), Serial0
via
172.12.123.2
(2323456/409600), Serial0
R1#show ip route eigrp 100
D
3.0.0.0/8 [90/2297856] via 172.12.123.3,
01:16:16, Serial0

We have two options for using that
second path, which has been
marked as a feasible successor by
EIGRP. One is practical, and the

other, well, isn’t.
We could try to change the metric to
exactly 2297856, but this is almost
impossible. Take a look at the
formula EIGRP uses to calculate
routes:
EIGRP metric calculation:
[(10*6 / smallest BW in kbps)
+ delay] * 256
This would be the impractical
method.
The best way to handle this
situation is to use unequal-cost

load balancing via the variance
command.
Using the variance command is
easy; it’s coming up with the value
of this command that causes a little
confusion. With practice, you’ll find
this to be easy points on the
ROUTE exam.
We just need the answer to this
question: ‘What is the smallest
number, when multiplied by the
metric of the successor, that is
greater than the metric of the
feasible successor?”

To put it a little more
formally….what is “x” in the
following?
(x * [successor metric]) >
feasible successor metric
I know some of you are looking at
that last paragraph and that formula
and thinking, “This is the practical
method?”
It really is, and you’ll see that in
just a moment. This is one of those
concepts that looks ridiculously
complicated in theory but is simple
in execution.

Let’s use the same table we looked
at earlier for an example.
Question: What is the smallest
number, multiplied by
2297856, that is greater than
2323456?
Answer: Two.
Easy!
By using the variance 2 command,
any route with a metric less than (2
* 2297856) will be placed into the
routing table.

This doesn’t make the route with the
higher metric a successor, but the
route is placed into the routing table
and will be used for unequal-cost
load-balancing.
R1#conf t
R1(config)#router eigrp 100
R1(config-router)#variance 2
R1#show ip eigrp topology
IP-EIGRP
Topology
AS(100)/ID(11.1.1.1)

Table

for

P 3.0.0.0/8, 1 successors, FD is 2297856
(There is still just one successor….)
via
172.12.123.3
(2297856/128256), Serial0
via
172.12.123.2
(2323456/409600), Serial0

R1#show ip route eigrp 100
D
3.0.0.0/8 [90/2297856] via
172.12.123.3, 00:01:52, Serial0
[90/2323456] via
172.12.123.2, 00:01:53, Serial0
(… but now there
are two routes in use to reach this
network.)

When unequal-cost load balancing
is in effect, the load each link
carries is proportional to their
metric. If one path’s metric
indicates that it is twice as good as
another, that path will carry roughly
twice as much data.
If you want only the best path(s) to

carry the traffic, use the trafficshare command with the min
option. The default is balanced.
R1(config)#router eigrp 100
R1(config-router)#traffic-share ?
balanced Share inversely proportional to
metric
min
All traffic shared among min metric
paths
R1(config-router)#traffic-share min ?
across-interfaces Use different interfaces
for equal-cost paths
R1(config-router)#traffic-share min acrossinterfaces ?
<cr>
R1(config-router)#traffic-share min acrossinterfaces

Now I know what some of you are
thinking….

“Why don’t I just put
variance 25 in there or
something like that, and then
I’ll be using all of my
available paths!”
Good question. Here’s a good
answer.
Let’s say we have three valid paths
to the same network with the
following metrics:
Path 1: 5000
Path 2: 7000

Path 3: 55000
Sounds like we have two pretty fast
links and one sloooow one. Do you
really want to load balance over
that third path? Probably not. It’s
better than having no third link at
all, but I wouldn’t include it in load
balancing.
variance is an “all-or-nothing”
command -- you can’t apply it to
just a selected route in the topology
table. In my experience, it’s a good
idea to keep the variance command
at the lowest value possible to
avoid load balancing over paths

that may be loop free but aren’t
exactly optimal.
And note the values available with
variance…
R1(config-router)#variance ?
<1-128> Metric variance multiplier

Setting variance to 1 is effectively
disabling
unequal-cost
load
balancing while retaining equalcost load balancing. You can’t set it
to zero.
Planning Your Load Balancing
Enabling

both

equal-cost

and

unequal-cost load balancing is
simple enough in EIGRP - the
former is on by default, the latter is
enabled with one simple command but you’ve got to do some planning
and verification, too.
I strongly recommend you create a
network baseline before using the
variance command. Besides, if you
don’t know how much traffic your
network is carrying, it’s hard to
determine if your load balancing is
working as desired!
After you run the variance, we need
to make sure of two things…

The load balancing is going as
expected and desired
Only the paths you wanted to
use are being used
When it comes to our old friends
ping and traceroute, we tend to
ping first and trace second… but
when you’re testing your load
balancing, you can leave the pings
alone. Pings will show you that you
do have connectivity to a given
destination, but they don’t show you
how we got there. Traceroutes do.

(And just in case - remember the
ping and traceroute
escape
sequence, <CTRL- Shift - 6> twice
in rapid succession.)
Once you’ve compared the new
config’s baseline to the old, and
you’re happy with the result document your changes. I know it’s
no fun. I know you’d rather be
doing something else.
Do it anyway. : )
And one more thing - when testing
and creating baselines for your
EIGRP
load
balancing

configuration, remember that load
balancing is only put into action for
traffic that both enters and leaves
that router - traffic actually
generated by the local router is not
subject to load balancing.
DUAL Queries
Let’s review the purpose of these
packets…
It is possible for an EIGRPspeaking router to have only a
single path to a given network,
which means we have one

successor and zero feasible
successors. If that successor route
is lost, that router will send DUAL
Queries to all its neighbors.
A DUAL Query is basically one
neighbor asking another, “Hey, do
you know how to get to this network
I just lost my route to?” There’s no
grey area here - either the
downstream router has such a route,
or it doesn’t. Here are the potential
actions the downstream router can
take:
If that neighbor has a route, the
query will be answered with

that route. Simple enough!
If the neighbor doesn’t have
such a route, that neighbor will
ask its neighbors. The process
continues until a downstream
router replies with the desired
route, or the EIGRP
downstream routers run out of
neighbors to ask.
Just as it’s wise to limit the scope
of broadcasts in our network, it’s a
great idea to limit the scope of these
Query packets as well. We have

two main weapons at our disposal
for limiting the scope of Query
packets:
Manual route summarization
EIGRP stub routing
We’ll look at both later in this
section.
Feasible Distance and Advertised
Distance
From all these views of the
topology table, you’ve probably

noticed that there are two numbers
in parenthesis following each nexthop IP address.
P 172.23.0.0/16, 2 successors, FD is 2195456
via
172.12.123.2
(2195456/281600), Serial0
via
172.12.123.3
(2195456/281600), Serial0

The first number, 2195456, is the
route’s feasible distance. This is
the full metric of the route to the
destination network.
The second number, 281600, is the
route’s advertised distance. This is
simply the metric from the next-hop
router to the destination network.

For the path to be considered valid,
the advertised distance must be less
than the feasible distance. This
ensures that the next-hop router is
indeed closer to the destination and
acts as a routing loop prevention
mechanism.
These distances are also used by
EIGRP to determine what routes
can be feasible successors. Let’s
look at our two routes to 3.0.0.0 /8
again.
P 3.0.0.0/8, 1 successors, FD is 2297856
via
172.12.123.3
(2297856/128256), Serial0

via

172.12.123.2

(2323456/409600), Serial0

The second route can’t be a
successor,
because
its
FD
(2323456) is higher than the FD of
the successor (2297856).
Can it be a feasible successor? Yes,
because the advertised distance of
that route (409600) is lower than
the feasible distance of the
successor (2297856).
This is the Feasibility Condition.
That route is then entered into the
topology table as a feasible
successor, and should the successor

go down, the feasible successor
will become the successor.
Let’s use some slightly smaller
numbers to walk through an
example without using show ip
eigrp topology. We’ll assume a
successor route and three possible
feasible successors.
Successor: FD 5, AD 4
Possible Feasible Successor #1:
FD 9, AD 7
Possible Feasible Successor #2:
FD 8, AD 6

Possible Feasible Successor #3:
FD 6, AD 4
To decide if any of these three
routes could be a feasible
successor, just compare the AD of
the route to the FD of the successor.
Routes #1 and #2 could not be
feasible successors, because their
ADs are larger than the FD of the
successor.
Route #3’s AD of 4 is less than the
successor’s FD of 5. As a result,
Route #3 will be placed into the
EIGRP topology table and marked

as a feasible successor. If the
successor route goes down, Route
#3 will then be named the
successor.
If the successor is lost and there is
no feasible successor, the router
takes two actions:
The route is put into Active
state, making the route
unusable.
The router sends DUAL Query
packets to EIGRP neighbors,
asking them if they have a

loop-free path to the
destination in question.

Either the neighbors will answer
this query with an alternate path
(with a reply packet), or those
neighbors will ask their neighbors
if they have a path to the network.
This query process continues until a
router returns a path to that network,
or no router can do so and the query
process finally ends.
We discussed SIA routes earlier,
and another reason that routes

become Stuck In Active is the
length of this query process. The
query process can be limited with
proper route summarization. (It
bears repeating that the most
common reason a route becomes
SIA is the failure of a router to
answer the query, whether that be a
problem with the router or the link
itself.)
Let’s take another look at feasible
distance, advertised distance, and
the feasibility condition in action.
You really have to watch these
values, or what you think should
happen with your network when a

successor goes down might not
actually be what will happen.
The Feasibility
Action

Condition

In

R1 has three potential paths to R3.
The
feasible
distances
and

advertised distances for the paths
from R1’s point of view are:
R1 - R4 - R3: FD 40, AD 20
R1 - R2 - R3: FD 70, AD 20
R1 - R5 - R3: FD 115, AD 75
R1 will place the path through R4
into its routing table; since that
route has the lowest FD, it is the
successor. The successor is also
placed into the topology table.
R1 will consider the other two
routes as potential feasible
successors.
The
Feasibility
Condition states that if a potential

feasible successor’s AD is less than
the successor’s FD, the route is an
FS.
The AD of the path through R2 is
20; the FD of the successor is 40.
The path through R2 is a feasible
successor and will be placed into
the EIGRP topology table.
What about the third path? The AD
of the path through R5 is 75, while
the FD of the successor is 40. This
indicates to EIGRP that the
potential for a routing loop exists,
so this route will not be made a
feasible successor.

If the path through R4 went down,
the router would immediately begin
using the path through R2, which
has already been tagged as a
feasible successor.
The path through R2 would then be
named the successor route, but the
path through R5 still would not be a
feasible successor, as the path
through R5 has an AD of 75 and the
path through R2 has a FD of 70.
The Feasibility Condition And
The variance Command

The Feasibility Condition also
impacts the use of the variance
command. The value expressed
with the variance command is
essentially a multiplier that enables
unequal-cost load balancing, but
there’s more to it than that.
You already know how to use the
variance command, but it’s
important to keep in mind that if a
route doesn’t meet the Feasibility
Condition, it can’t possibly be used
in unequal-cost load balancing.
Consider the network metrics from
the last example:

R1 - R4 - R3: FD 40, AD 20
R1 - R2 - R3: FD 70, AD 20
R1 - R5 - R3: FD 115, AD 75
It’s very tempting to look at these
metrics and think that we could use
variance to use all three paths for
unequal-cost load balancing. The
problem is that you can’t use a path
that doesn’t meet the Feasibility
Condition.
In the exam room and in the real
world, make sure any routes you
want to use in unequal-cost load
balancing meet the Feasiblity

Condition, because if they don’t,
you cannot use them no matter what
the value of the variance command
is.
You should always write out the FD
and AD of all routes in a network
diagram before deciding whether
the variance command will allow
you to use all the paths. Let’s look
at another example. How would you
go about configuring unequal-cost
load balancing in the following
network?

The quick and obvious answer
would be to just add up the metrics
for each path, then figure out what
variance value to use. The metric
for the best path is 40; the metric
for the lesser path is 115; therefore,
we just run the command variance
3 (40 x 3 = 120, which will allow
all valid routes with a metric of

less than 120 to be put into the
routing table), and we’re all set,
right?
Wrong. The problem is not with our
math, but with the Feasiblity
Condition. Let’s look at the FD and
AD for each path, using the values
shown.
R1-R2-R3: FD 40, AD 20
R1-R4-R5: FD 55, AD 35
R1-R6-R7: FD 115, AD 75
The successor will be R1-R2-R3;
that route will be in both the route

and topology tables. R1-R4-R5
meets the Feasiblity Condition,
since its AD of 35 is less than the
FD of the successor, which is 40.
That route is eligible for unequalcost load balancing and will be
placed in the topology table.
There’s a problem with R1-R6-R7,
though. The AD of that path is 75,
which is larger than the FD of the
current successor; even if R1-R4R5 became the successor, R1-R6R7 still couldn’t meet the Feasiblity
Condition. Therefore, the best
solution is to run the command
variance 2 to perform load sharing

over the single feasible successor.
No matter the variance value, the
third path cannot participate in
unequal-cost load balancing.
EIGRP Administrative Distances
The EIGRP routes you saw in the
routing table earlier in this chapter
were the EIGRP route type you
learned about in your CCNA
studies. These are EIGRP internal
routes, and they have an
administrative distance of 90.
There are two other EIGRP route
types, and they have different

administrative distances. Routes
learned by EIGRP via route
redistribution are external EIGRP
routes and have an AD of 170.
These routes are preceded in the
routing table with the letters “D
EX”.
Keep in mind that redistributed
routes don’t have to come from
other routing protocols -- they can
be connected or static routes as
well. I’ve run into situations that
had people scratching their heads
over an AD value, so let’s take a
look at one such configuration.

Both routers are in AS 100, and are
connected via the Ethernet segment.
One day, someone decides to
advertise the loopback interface on
R2 (2.2.2.2 /32) to the rest of the
EIGRP domain.
You’ll generally use the network
command for this.
R2(config)#router eigrp 100
R2(config-router)#network 2.2.2.2 0.0.0.0

R3#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D
2.2.2.2 [90/409600] via 172.23.23.2,
00:00:06, Ethernet0

That’s what we would expect to
see, and that’s how R3 would then
advertise
this
network
to
downstream routers - as an internal
route.
What if redistribution were used on
R2 instead of the network
command? Let’s remove the
network command on R2 and use
redistribute connected instead.
R2(config)#router eigrp 100
R2(config-router)#no network 2.2.2.2 0.0.0.0

R2(config-router)#redistribute connected
R3#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D EX
2.2.2.2 [170/409600] via 172.23.23.2,
00:00:05, Ethernet0

The difference is significant! R3
now sees the same network as an
external network, which means its
AD is 170 instead of 90. R3 would
then advertise this network to
downstream EIGRP routers as an
external route. Even though there is
no other AS or no other routing
protocol involved, routes can still
show up as external routes when
you use route redistribution with

connected or static routes.
To change the AD of external or
internal EIGRP routes on a single
router, use the distance eigrp
command. Even if you’re only
changing the distance of one route
type, you still have to specify them
both.
R1(config)#router eigrp 100
R1(config-router)#distance ?
<1-255> Administrative distance
eigrp IP-EIGRP distance
R1(config-router)#distance eigrp ?
<1-255> Distance for internal routes
R1(config-router)#distance eigrp 45 ?
<1-255> Distance for external routes
R1(config-router)#distance eigrp 45 100

The third type of EIGRP route is an
EIGRP summary route. The result of
manual route summarization, these
routes have an AD of 5 when
viewed on the router actually
performing the summarization.
If you know where to look, that is.
Stay tuned.
EIGRP Route Summarization Automatic And Manual
EIGRP has a default behavior
involving route summarization that
is almost always turned off at the
very beginning of an EIGRP

deployment,
and
autosummarization.

that

is

EIGRP and RIPv2 automatically
summarize routes when they are
advertised across classful network
boundaries. When you have
discontiguous networks (subnets of
the same major network number that
are separated by another major
network number), this behavior can
result in suboptimal routing at its
worst.
Consider this network where
subnets of the major network
number 20.0.0.0 are separated by

another major network number,
172.16.0.0.

If
EIGRP’s
default
autosummarization is left on, the
hub router is going to get two
advertisements for the major

network number 20.0.0.0 /8.
Combined with another EIGRP
default behavior, equal-cost load
sharing, there is an excellent chance
that half of the packets destined for
any of the subnets of 20.0.0.0 are
going to end up at the wrong spoke
router.
It’s easy enough to turn this
behavior off:
R1(config)#router eigrp 100
R1(config-router)#no auto-summary

Many
real-world
EIGRP
deployments have no autosummary configured on every

router in the network. This doesn’t
really hurt anything, but now that
you’re training to be a CCNP, you
need to know where the command
is needed - and where it’s
unnecessary.
Disabling autosummarization on the
spoke routers in this network will
give the hub router a much more
accurate picture of the network.
Remember, it’s not enough to know
the command - you need to know
where to configure the command.
The no auto-summary command
would have no effect on incoming
updates if configured on the hub. In

this network, the command needs to
be placed on each spoke.

Configuring any kind of manual
summarization does NOT enable or
disable auto-summarization -they’re two separate operations.

Route summarization isn’t always a
bad thing -- configured at the right
points in your network, it can be a
great thing. Here are just a few
reasons why…
The routing tables are smaller,
making the entire routing
process faster.
Since the tables are smaller,
the load on the CPU from the
routing process is lessened.
The more-specific network
numbers are hidden.

Routing updates are smaller.
The impact of flapping routes
on the rest of the network is
lessened, and correct
summarization helps to limit
the number of EIGRP queries.

The key to success with real-world
route summarization is that you,
the network administrator, should
decide
where
summarization
should take place -- not the router,

not the protocol. You.
In this example, R1 has seven
subnets of the major network
number
100.0.0.0
that
it’s
advertising to R3:

R3’s EIGRP table shows all seven
routes:
R3#show ip route eigrp
100.0.0.0/16 is subnetted, 7 subnets

D
100.4.0.0 [90/2297856] via
00:00:00, Serial0
D
100.5.0.0 [90/2297856] via
00:00:00, Serial0
D
100.6.0.0 [90/2297856] via
00:00:00, Serial0
D
100.7.0.0 [90/2297856] via
00:00:00, Serial0
D
100.1.0.0 [90/2297856] via
00:00:00, Serial0
D
100.2.0.0 [90/2297856] via
00:00:00, Serial0
D
100.3.0.0 [90/2297856] via
00:00:00, Serial0

172.12.123.1,
172.12.123.1,
172.12.123.1,
172.12.123.1,
172.12.123.1,
172.12.123.1,
172.12.123.1,

With the help of manual route
summarization, we can knock this
table down to one line. First, we
use our old friend binary math to
convert the subnet numbers to

binary strings.

Believe it or not, that’s the hard part
of summarizing routes.
The
next
step
in
route
summarization is to work from left
to right and identify the common
bits. From there, it’s easy:
The decimal value of these
bits is the summary route.

The number of common bits
yields the summary mask.
Here, the value of the common bits
(bolded above) is 100.0.0.0. There
are 13 common bits, expressed as
/13 in prefix notation and
255.248.0.0 in dotted decimal.
Now that we have the summary
route and mask, this route and mask
will be configured on the ethernet
interface…. the physical interface
that will be advertising the
summary.
R1(config)#interface ethernet0

R1(config-if)#ip summary-address eigrp 100
100.0.0.0 255.248.0.0
2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP
100: Neighbor 172.12.123.3 (Serial0) is
down: summary configured
2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP
100: Neighbor 172.12.123.2 (Serial0) is
down: summary configured

It’s important to keep in mind that
when you configure EIGRP
summary addresses, your neighbor
relationships will be lost. When
they come back up, R3 will have a
single summary route instead of the
seven more-specific routes it
previously had.

R3#show ip route eigrp 100
100.0.0.0/13 is subnetted, 1 subnets
D
100.0.0.0 [90/2297856] via
172.12.123.1, 00:03:33, Ethernet0

We saw the impact on R3 after
route summarization, but there’s
something of interest on R1 you
should note.
R1#show ip route
< code table removed for clarity >
100.0.0.0/8 is variably subnetted, 8
subnets, 2 masks
C
100.4.0.0/16 is directly connected,
Loopback4
C
100.5.0.0/16 is directly connected,
Loopback5
C
100.6.0.0/16 is directly connected,
Loopback6
C
100.7.0.0/16 is directly connected,

Loopback7
D
100.0.0.0/13 is a
00:07:32, Null0
C
100.1.0.0/16 is directly
Loopback0
C
100.2.0.0/16 is directly
Loopback2
C
100.3.0.0/16 is directly
Loopback3

summary,
connected,
connected,
connected,

On R1, the summary route is seen as
a route to Null0, which is basically
a route to the trash can. If a packet
comes into this router that doesn’t
match one of the seven morespecific routes, it will be “blackholed” -dropped by the router. This
default behavior of EIGRP route
summarization helps to prevent

routing loops. This null route will
only be seen on the router
performing
the
manual
summarization.
The Mystery Of The AD5
One of the jumps from CCNA to
CCNP in your EIGRP studies
involves these three administrative
distances:
Internal: 90
External: 170
Summary: 5

We’ve seen that AD of 90 for
internal EIGRP routes since the
beginning of our studies; the AD of
170 has been seen in this section as
well as the Redistribution section
of the course.
So what about that AD of 5 for
EIGRP summary routes?
When we looked at the summary
route on the downstream router R3,
we saw…
R3#show ip route eigrp 100
100.0.0.0/13 is subnetted, 1 subnets
D
100.0.0.0 [90/2297856] via
172.12.123.1, 00:03:33, Ethernet0

.. an AD of 90. Actually, that’s the
value we should expect, since the
summary route will have an AD of
5 only on the router that originates
the summary.
Great! Let’s take another look at
R1’s routing table and that line for
the summary route, and I’m sure
we’ll see…
D
Null0

100.0.0.0/13 is a summary, 02:11:48,

… no AD at all. So where is it?
After some information mining (a
fancy way to say “I looked it up

again”), I found that you need to run
the show ip route command
followed by the network number.
R1#show ip route 100.0.0.0
Routing entry for 100.0.0.0/8, 8 known subnets
Attached (7 connections)
Variably subnetted with 2 masks
C
100.4.0.0/16 is directly connected,
Loopback3
C
100.5.0.0/16 is directly connected,
Loopback4
C
100.6.0.0/16 is directly connected,
Loopback5
C
100.7.0.0/16 is directly connected,
Loopback6
D
100.0.0.0/13 is a summary, 00:19:54,
Null0
C
100.1.0.0/16 is directly connected,
Loopback0
C
100.2.0.0/16 is directly connected,

Loopback1
C
Loopback2

100.3.0.0/16 is directly connected,

Hmm. I still don’t see an AD. Do
you?
When all else fails, ask for
directions from Mr. IOS Help:
R1#show ip route 100.0.0.0 ?
A.B.C.D
Network mask
longer-prefixes Show route matching the
specified Network/Mask pair only
|
Output modifiers
<cr>

Let’s try it with the mask:

R1#show ip route 100.0.0.0 255.248.0.0
Routing entry for 100.0.0.0/13
Known via “eigrp 100”, distance 5, metric
128256, type internal
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 128256, traffic share
count is 1
Total delay is 5000 microseconds,
minimum bandwidth is 10000000 Kbit
Reliability 255/255, minimum MTU 1514
bytes
Loading 1/255, Hops 0

Ta da!
Where Should Manual Route
Summarization Be Performed?

Part of configuring anything Cisco,
from manual route summarization to
access lists, is figuring out the best
point in your network to actually
perform the operation. As you well
know by this point in your Cisco
studies, there’s rarely a “one-sizefits-all” solution to this question!
When it comes to EIGRP route
summarization, I’ve found the most
efficient point to perform this
operation is at the ASBR. We
generally associate the term ASBR
with OSPF, but an EIGRP router
that performs route redistribution is
also considered an ASBR. Just as

with OSPF, route summarization is
more efficient when it’s configured
on the ASBR.
EIGRP Design Recommendations
With networks growing and
changing all the time, it’s
impossible for anyone to give you a
hard-and-fast set of design rules
that will fit any network. Having
said that, there are some solid
general guidelines when it comes
to EIGRP.
Make sure you spend some

time and set up a solid address
allocation scheme before you
deploy your network. This
pointer is the EIGRP
equivalent of “measure twice,
cut once”.
Ensure that you’ll be able to
perform manual route
summarization where desired.
Avoid discontiguous networks
whenever possible.
Make sure your routers have

sufficient memory and CPU to
do their jobs. Your hub routers
in any hub-and-spoke
deployments will be the
workhorses of your network.

Cisco has a few recommendations
when it comes to EIGRP bandwidth
allocations over the NBMA cloud.
Your EIGRP traffic on each
Virtual Circuit (VC) shouldn’t
exceed the Committed
Information Rate (CIR). (The
CIR is the amount of

bandwidth the service
provider guarantees to be
available to us.)
The total EIGRP traffic
crossing all of your VCs
should not be greater than the
total capacity of the line.
The bandwidth allocated to
EIGRP on each VC should be
the same on each interface.
There are also some details to
attend to when it comes to

allocating bandwidth over an
NBMA network. The typical Serial
interface is going to have multiple
Virtual Circuits, so you have to
know how EIGRP will run in that
situation. The calculation for the
bandwidth
command
varies
according to two factors:
the type of interface in use on
the hub
the CIR assigned to each
circuit
Just looking at these guidelines give

you an idea of some good questions
to ask before you start configuring:
What IS the current CIR?
What are the current
bandwidth values of the
interfaces?
Does the client have any
special requests or policies
that need to be taken into
consideration - bandwidth
maximums / minimums, stub
routers, non-transient routers,
etc.?

Let’s take a look at several different
scenarios, beginning with a
physical interface on the hub and
three circuits all assigned the same
CIR.

When there are no subinterfaces in

use and the CIR is the same for
every VC, just add up the CIRs and
you’ve got your bandwidth value.
Doing this ensures that none of the
circuits are overloaded, which
could happen if we leave the
bandwidth setting at the default.
R1(config)#int serial0
R1(config-if)#bandwidth 768

Cisco has stated you can take the
lowest CIR value and multiply it by
the number of VCs. This isn’t the
recommended solution, but it is
valid. Using this solution, the
bandwidth setting on R5’s Serial0
interface would be (3 x 56), or 168.
R1(config)#int s0
R1(config-if)#bandwidth 168

This would prevent R7 from being
overrun with packets, but it doesn’t
allow R6 or R4 to work to capacity.
A more viable solution involves

configuring point-to-point interfaces
and assigning individual bandwidth
values, having those match the
individual CIR of each VC. This is
Cisco’s recommendation for this
situation, and this allows each
router to work more closely to
capacity!

R1(config)#int serial0.1 point-to-point
R1(config-subif)#ip
address
255.255.255.0
R1(config-subif)#bandwidth 512

20.1.1.1

R1(config-subif)#int s0.2 point-to-point
R1(config-subif)#ip
address
40.1.1.1
255.255.255.0
R1(config-subif)#bandwidth 256
R1(config-subif)#int s0.3 point-to-point
R1(config-subif)#ip
address
50.1.1.1
255.255.255.0
R1(config-subif)#bandwidth 56

Multipoint Subinterfaces, VCs
Using Different CIRs

Of course, you may have a
multipoint subinterface on the hub
router! In that case, simply add the
CIR values for each circuit using
that multipoint subinterface to
arrive at the correct bandwidth
setting.
In the following example, there are

three circuits using the same
multipoint interface. The CIRs are
512, 256, and 56 kbps; the
bandwidth
setting on R5’s
multipoint interface should be set to
824 kbps.
R1(config)#interface s0.467 multipoint
R1(config-subif)#bandwidth 824

By default, EIGRP uses up to 50
percent of a given interface’s
bandwidth as set by the bandwidth
command. If you wish to change this
default, it can be done with the
interface-level
command
ip
bandwidth-percent eigrp.

R1(config)#int s0
R1(config-if)#ip bandwidth-percent eigrp ?
<1-65535> Autonomous system number
R1(config-if)#ip bandwidth-percent eigrp 100 ?
<1-999999> Maximum bandwidth
percentage that EIGRP may use
R1(config-if)#ip bandwidth-percent eigrp 100
300

In this command, the values look
really strange. According to IOS
Help, we can set the interface
bandwidth usage to more than 100
percent!
I set it to 300% here and didn’t get
an error message of any kind.
How in the world can I set EIGRP

100 to use 300% of an interface’s
available bandwidth?
There is always the chance that the
actual physical speed of the
interface exceeds the logical
setting. You could take an interface
with a 512
kbps capacity and give it a logical
setting of 56 kbps. If you then
wanted the line to allow EIGRP to
use 168 kbps of the physical
bandwidth,
you’d
set
the
bandwidth-percent value to 300,
which allocates 300% of 56kbps to
EIGRP traffic - which is 3 x 56, or

168.
I know it sounds crazy, so here’s the
proof that you can actually do this:
R3(config)#interface serial0
R3(config-if)#bandwidth 56
R3(config-if)#ip bandwidth-percent eigrp ?
<1-65535> Autonomous system number
R3(config-if)#ip bandwidth-percent eigrp 100 ?
<1-999999> Maximum bandwidth
percentage that EIGRP may use
R3(config-if)#ip bandwidth-percent eigrp
100 300

Watch that syntax - the first number
is the EIGRP AS; the second
number
is
the
bandwidth
percentage.

EIGRP Stub Routers
Here’s a great method of limiting
the size of some routing tables in
your EIGRP deployment and the
scope of DUAL Query packets.
While EIGRP does not have the
stub area options that OSPF does,
EIGRP does allow a router to be
configured as stub. This is
commonly done with a hub-andspoke configuration where the
spoke routers do not have the
resources or the need to keep a full
routing table.

Since the spoke’s next hop will
always be the hub, all the spoke
really needs is a default route. For
this reason, the only neighbor an
EIGRP stub router can have is the
hub router -- two EIGRP stub
routers cannot become neighbors.
Configuring EIGRP stub routers
also combats the SIA problem.
EIGRP stub routers are not queried
for routes when the hub does not
have a feasible successor for a
successor route that has gone down.
This limits the scope of EIGRP
Query packets and is a popular
reason for configuring EIGRP stub

routing.
By default, EIGRP stub routers
advertise information about two
types of routes back to the hub directly connected networks and
summary routes.
Configuring an EIGRP router as
stub is very simple:
R1(config)#router eigrp 100
R1(config-router)#eigrp stub

To change this default, use the eigrp
stub command followed by the
types of routes you want the stub to
advertise back to the hub.

R1(config)#router eigrp 100
R1(config-router)#eigrp stub ?
connected
Do advertise connected
routes
receive-only Set IP-EIGRP as receive only
neighbor
static
Do advertise static routes
summary
Do advertise summary routes
<cr>

The network we looked at earlier in

this section has several excellent
candidates for EIGRP stub routers.
As long as R4, R6, and R7 are each
only neighbors with the hub, R5,
they can be configured as stub
routers.
Those stub routers will then
advertise their directly connected
networks and summary routes back
to the hub and will receive only a
default route back from the hub. If
R5 loses a successor and has no
feasible successor, it will not send
a query packet to any of the stub
routers.

Basically, what we’re doing is
preventing R5 from asking a
question of those other routers that
they can’t possibly have an answer
to in the first place.
An EIGRP stub deployment can
have more than one hub, as the
following illustration shows. The
important thing is that the spoke
routers are not interconnected. The
hub routers R5 and R8 are
interconnected, but not the spokes
R4, R6, and R7.

Just A Reminder…
I know you remember this from
your CCNA studies, but I’m going
to tell you anyway - EIGRP
assumes that a serial interface is
connected to a T1 line, which runs
at 1544 kbps (or 1.544 mbps). If
this isn’t the case in your network,

the bandwidth command can be
used to give EIGRP a more accurate
reflection of the line speed.
For example, if you have a serial
interface connected to a 56 kbps
line, it’s a good idea to tell EIGRP
to reflect that in its routing
calculations with the bandwidth
command.
R1(config)#int s0
R1(config-if)#bandwidth 56

Always use IOS Help to verify the
unit of measurement for any value.
There’s a big difference between
entering bandwidth 56 and

bandwidth 56000 on that line!
And Just Another Reminder…
There’s some confusion out there as
to whether the use of wildcard
masks with EIGRP is required. I
personally recommend you use
wildcard masks every time you can,
but it’s not required.
R1(config)#router eigrp 100
R1(config-router)#network 10.0.0.0 ?
A.B.C.D EIGRP wild card bits
<cr>
R1(config-router)#network 10.0.0.0

This IOS Help readout shows that
you can configure wildcard bits

with this network command, and the
<cr> indicates that it’s a legal
command just the way it is. Pre12.0 IOS versions don’t support
EIGRP wildcard masks, so you
should also be prepared for that
possibility.
I’ve seen one or two routers running
at least 12.0 that didn’t seem to like
wildcard masks either - that seems
to have been an anomaly - the
important point here is that their use
is
not
required,
but
is
recommended.
What’s

So

Passive

About

A

Passive Interface?
On occasion - say, maybe your
CCIE lab date :) - you may want to
advertise a network via EIGRP, but
not want to send EIGRP-related
traffic out the interface you’re
advertising.
For example, let’s say you want to
advertise our Ethernet segment of
172.23.23.0 /24 to R1, but you
don’t want any EIGRP traffic,
Hellos or otherwise, to be sent out
the interfaces on that segment.
Configuring the Ethernet0 interfaces
on R2 and R3 as passive will make

that happen.
When you configure an EIGRPenabled interface as passive, that
interface will not transmit Hello
packets. Since the absence of Hello
packets means no adjacencies, no
other EIGRP packets will go out
those interfaces.
There are two approaches to
configuring passive interfaces:
Option 1: Use the passive-interface
default command to make every
EIGRP-enabled interface on the
router passive, and then use the no

passive-interface command to
indicate the interfaces that should
not be passive.
The following configuration will
first enable EIGRP passive
interface as the default, and the next
command disables that same feature
on Serial0.
R1(config)#router eigrp 100
R1(config-router)#passive-interface ?
BRI
ISDN Basic Rate Interface
Ethernet IEEE 802.3
Loopback Loopback interface
Null
Null interface Serial Serial
default
Suppress routing updates on all
interfaces
<cr>
R1(config-router)#passive-interface default

R1(config-router)#no passive-interface ?
BRI
ISDN Basic Rate Interface
Ethernet IEEE 802.3
Loopback Loopback interface
Null
Null interface
Serial
Serial
default
Suppress routing updates on all
interfaces
<cr>
R1(config-router)#no
passive-interface
serial0

Option 2: Use the no passiveinterface default command to
disable this feature globally, and
then use the passive-interface
command to indicate interfaces that
should be passive.

Naturally, as a result of making
Serial0 passive, any existing
adjacencies formed through that
interface are lost - and the DUAL
message tells you why.
R2(config)#router eigrp 100
R2(config-router)#no passive-interface default
R2(config-router)#passive-interface serial 0
R2(config-router)#
00:48:36: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.12.123.1 (Serial0) is
down: interface passive

When you realize you made the
wrong interface passive, just use
the no passive-interface command
to make things right and the

adjacency should quickly reappear.
R2(config-router)#no passive-interface serial 0
R2(config-router)#
00:50:08: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.12.123.1 (Serial0) is
up: new adjacency

Note that all commands discussed
above are run in the EIGRP
configuration, not at the interface
level.
Propagating A Default Route Via
EIGRP
First, the bad news: We don’t have
OSPF’s
default
informationoriginate option in EIGRP

(“always” or otherwise).
The good news: We can redistribute
a static default route into EIGRP, or
we can indicate a default network
with the ip default-network
command.
To go with the static default option,
just create a static default route
with the ip route command and
follow that with the redistribute
command.
R1(config)#ip route 0.0.0.0 0.0.0.0 ethernet0
R1(config)#router eigrp 100
R1(config-router)#redistribute static ?
metric
Metric for redistributed routes
route-map Route map reference

<cr>
R1(config-router)#redistribute static metric ?
<1-4294967295> Bandwidth metric in Kbits
per second
R1(config-router)#redistribute static metric 1544
?
<0-4294967295> IGRP delay metric, in 10
microsecond units
R1(config-router)#redistribute static metric 1544
10 ?
<0-255> IGRP reliability metric where 255 is
100% reliable
R1(config-router)#redistribute static metric 1544
10 255 ?
<1-255> IGRP Effective bandwidth metric
(Loading) where 255 is 100% loaded
R1(config-router)#redistribute static metric 1544
10 255 1 ?
<1-4294967295> IGRP MTU of the path
R1(config-router)#redistribute static metric 1544
10 255 1 1500

Downstream routers will see this
route as follows:
R2#show ip route eigrp
100.0.0.0/13 is subnetted, 1 subnets
D*EX 0.0.0.0/0 [170/2172416] via 172.12.123.1,
00:01:15, Serial0

You can use the network 0.0.0.0
command in the EIGRP config in
lieu of the redistribute command.
R2 will still see the default route,
but it will have an AD of 90 rather
than 170 since redistribution is not
involved.
R1(config)#router eigrp 100
R1(config-router)#network 0.0.0.0 ?

A.B.C.D EIGRP wild card bits
<cr>
R2#show ip route eigrp
100.0.0.0/13 is subnetted, 1 subnets
D*
0.0.0.0/0 [90/2195456] via 172.12.123.1,
00:00:05, Serial0

Just one more option for
redistribution (for now). Remember
the route to null0 that was placed in
our routing table as a result of route
summarization? That route can also
be redistributed, but it can lead to
some routing issues depending on
your network topology. I’m
personally not big on redistributing
a route to null0, but it’s an

important option to keep in mind.
Using The IP Default-Network
Command
You can advertise a non-zero
network number as the default route
with the ip default-network
command, but there’s just one thing
to watch out for ….
The router that originates this
advertisement MUST have that
network number in its IP routing
table.
The reason I’m making such a big

deal of that is with OSPF, we had
the option of advertising a default
route even when the router didn’t
have such a default route in its
routing table (“default informationoriginate always”). We have no
such option with EIGRP.
After removing the above default
static route and the redistribute
command, I’ll configure 20.0.0.0 as
the default network for EIGRP…
R1(config)#router eigrp 100
R1(config-router)#ip default-network ?
% Unrecognized command

… or will I?
Don’t try to use the ip defaultnetwork command in the EIGRP
config itself - it’s a globally
configured command.
R1(config)#ip default-network 20.0.0.0

But on R2, no such network appears
and there is no gateway of last
resort.
R2#show ip rout
Gateway of last resort is not set
100.0.0.0/13 is subnetted, 1 subnets
D
100.0.0.0 [90/2297856] via
172.12.123.1, 00:02:30, Serial0

172.12.0.0/24 is subnetted, 1 subnets
C
172.12.123.0 is directly connected,
Serial0

Let’s go back to R1, remove the
20.0.0.0 network, and add the
10.0.0.0 network that does have an
entry in the routing table:
R1(config)#no ip default-network 20.0.0.0
R1(config)#ip default-network 10.0.0.0

The route is flagged as a candidate
default in R1’s routing table..
C*
Ethernet0

10.0.0.0/8 is directly connected,

… and is advertised via EIGRP to

downstream routers.
R2#show ip route eigrp
100.0.0.0/13 is subnetted, 1 subnets
D
100.0.0.0 [90/2297856] via
172.12.123.1, 00:02:46, Serial0
D*
10.0.0.0/8 [90/2195456] via 172.12.123.1,
00:01:37, Serial0

Authenticating
Neighbors

Our

EIGRP

In today’s world, it’s not always a
good idea to assume that all
neighbors dynamically discovered
by EIGRP are actually desirable
neighbors. They could be rogue

routers that will have the ability to
inject a malicious routing update
into our network - and the resulting
IP routing table could end up
sending all of our network’s data to
a rogue router.
EIGRP neighbor authentication isn’t
the most intuitive feature you’ll
ever configure, and there are quite a
few command options. Before you
even get that far, though, you have to
decide whether you’re going to use
clear-text passwords or use MD5
authentication to encrypt those
passwords….

… and while I’ll show you how to
do both, in the real world that
shouldn’t be much of a decision. If
you’re going to the trouble to
configure
EIGRP
neighbor
authentication in the first place, go
all the way and use MD5
authentication.
Note that MD5 only encrypts the
password used for our neighbor
authentication - it does not protect
the payload of the packets.
Since you’re much more likely to
work
with
MD5
EIGRP
authentication, let’s configure that

right now!
First, define the password and any
other options such as start-time and
end-time with the key chain
command. Before setting any
options, though, configure the actual
password with the key-string
command.
R3(config)#key chain ?
WORD Key-chain name
R3(config)#key chain EIGRPNEIGHBOR ?
<cr>
R3(config)#key chain EIGRPNEIGHBOR
R3(config-keychain)#key ?
<0-2147483647> Key identifier
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string ?
<0-7> Encryption type (0 to disable

encryption, 7 for proprietary)
LINE The key
R3(config-keychain-key)#key-string KINISKI

You can define how long a
particular password should be sent
and accepted with the send-lifetime
and accept-lifetime commands. For
your intro to this command, we’ll
use the infinite option for the
expiration date - which means that
it never expires!
R3(config-keychain-key)#?
Key-chain key configuration commands:
accept-lifetime Set accept lifetime of key
default
Set a command to its
defaults
exit
Exit from key-chain key
configuration mode

key-string
Set key string
no
Negate a command or set
its defaults
send-lifetime
Set send lifetime of key
R3(config-keychain-key)#accept-lifetime ?
hh:mm:ss Time to start
local
Specify time in local timezone
R3(config-keychain-key)#accept-lifetime
10:00:00 ?
<1-31> Day of the month to start
MONTH Month of the year to start
R3(config-keychain-key)#accept-lifetime
10:00:00 Jan 1 ?
<1993-2035> Year to start
R3(config-keychain-key)#accept-lifetime
10:00:00 Jan 1 2010 ?
duration Set key lifetime duration
hh:mm:ss Time to stop
infinite
Never expires
R3(config-keychain-key)#accept-lifetime
10:00:00 Jan 1 2010 infinite
R3(config-keychain-key)#send-lifetime 10:00:00
Jan 1 2010 infinite

You might expect that we would
have lost our EIGRP adjacencies
from R3, but that’s not the case yet we’ve just created the key, but we
haven’t applied the key to the
interface(s).
In essence, we’ve forged the key
but haven’t locked the door. That’s
about to change. Let’s apply this
authentication to the Ethernet
segment over which R2 and R3 are
exchanging EIGRP traffic.
This
actually requires
two
commands on each interface. On

R3, we’ll begin by configuring the
MD5 authentication mode on that
Ethernet interface, taking a look at
the options along the way:
R3(config)#int e0
R3(config-if)#ip authentication ?
key-chain key-chain
mode
mode
R3(config-if)#ip authentication mode ?
eigrp Enhanced Interior Gateway Routing
Protocol (EIGRP)
R3(config-if)#ip authentication mode eigrp ?
<1-65535> Autonomous system number
R3(config-if)#ip authentication mode eigrp 100 ?
md5 Keyed message digest
R3(config-if)#ip authentication mode eigrp 100
md5 ?
<cr>
R3(config-if)#ip authentication mode eigrp 100
md5

R3(config-if)#
04:01:46: %DUAL-5-NBRCHANGE:
EIGRP 100: Neighbor 172.23.23.2
(Ethernet0) is down: Auth failure

IP-

Almost immediately, the adjacency
to R2 is dropped - “Auth failure”.
Let’s finish the config with the ip
authentication key-chain command
and see if it comes back up!
R3(config-if)#ip authentication ?
key-chain key-chain
mode
mode
R3(config-if)#ip authentication key-chain ?
eigrp Enhanced Interior Gateway Routing
Protocol (EIGRP)
R3(config-if)#ip authentication key-chain eigrp ?
<1-65535> Autonomous system number
R3(config-if)#ip authentication key-chain eigrp

100 ?
WORD name of key-chain
R3(config-if)#ip authentication key-chain eigrp
100 EIGRPNEIGHBOR ?
<cr>
R3(config-if)#ip authentication key-chain eigrp
100 EIGRPNEIGHBOR

We have no chance of getting the
adjacency back until we configure
R2 with the same config, so I’ve
done that as well - here’s the
resulting configuration:
key chain EIGRPNEIGHBOR
key 1
key-string KINISKI
accept-lifetime 10:00:00 Jan 1 2010 infinite
send-lifetime 10:00:00 Jan 1 2010 infinite
!
!

!
interface Ethernet0
ip address 172.23.23.2 255.255.255.0
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100
EIGRPNEIGHBOR

And in just a few seconds….
04:09:18: %DUAL-5-NBRCHANGE: IPEIGRP 100: Neighbor 172.23.23.2 (Ethernet0) is
up: new adjacency

.. the adjacency is back! (Of course,
trust but verify - I’d send a few
pings to that neighbor.)
There is a show verification
command for the key chain that

gives you a very important piece of
information at the very far right of
the output:
R2#show key chain
Key-chain EIGRPNEIGHBOR:
key 1 -- text “EIGRP”
accept lifetime (10:00:00 UTC Jan 1
2010) - (infinite) [valid now]
send lifetime (10:00:00 UTC Jan 1
2010) - (infinite) [valid now]

The key “KINISKI” is shown to be
“valid now”. What if it wasn’t
valid? Let’s create a key chain with
the same name where I mistyped a
single number:

R2(config)#key chain EIGRPNEIGHBOR
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string SPIDERS
R2(config-keychain-key)#accept-lifetime
00:00:00 Jan 1 2020 infinite
R2(config-keychain-key)#send-lifetime 00:00:00
Jan 1 2010 infinite

When you’re typing this many
numbers, it’s easy to hit just one
wrong key - so always verify with
show key chain.
If you’re expecting this key chain to
be valid now, but you don’t see that
phrase next to each line of the
output…
R2#show key chain
Key-chain EIGRPNEIGHBOR:

key 1 -- text “SPIDERS”
accept lifetime (00:00:00 UTC Jan 1
2020) - (infinite)
send lifetime (00:00:00 UTC Jan 1
2010) - (infinite) [valid now]

.. you know you mistyped
something. To fix this, don’t delete
the entire key chain - just reenter the
config mode and use the no option
to remove the unwanted part of the
config. Then enter what you meant
to enter! :)
Before you head to the advanced
EIGRP section, watch these
recommended videos from my

YouTube channel and my website!
Video Practice Exam on EIGRP:
http://www.youtube.com/watch?
v=LPuXmiKznEI
Administrative Distance Lab And
EIGRP:
http://www.youtube.com/watch?
v=yNgZwD8kXP0
Don’t miss this one - “The Mystery
Of The AD 5”

http://www.youtube.com/watch?
v=X9AzQCt7rCM
Video Exam & Boot Camp Includes EIGRP:
http://www.youtube.com/watch?
v=f5_i2yEXj3s
Free CCNP ROUTE Video Boot
Camp on route redistribution:
http://bit.ly/Arnhjq
Enjoy! -- Chris B.

Copyright © 2012 by The Bryant
Advantage. All Rights Reserved.

Link State Protocols &
Single-Area OSPF

Link State Protocol Basics
You’re familiar with link state
protocol behaviors from your
CCNA studies, but we’re going to
review the important points here in
just a moment.
Avoid the temptation to skip the
review.
While quite a bit of it will be

familiar to you, there are many
additional details you must master
at the CCNP level. Those of you
with your eyes on the CCIE will
need
to
truly master
the
fundamentals of OSPF.
When RIP sends routing updates,
these updates contain the full
routing table. By running debug ip
rip, you can actually see the routes
contained in the update, along with
the route metrics.
Link state protocols don’t work that
way. Link state routers that have
formed adjacencies exchange Link

State Updates (LSUs), which
contain Link State Advertisements
(LSAs). It’s these LSAs that carry
subnet masking information and
allow OSPF to support VLSM.
These LSAs are placed into a link
state database. The Dijkstra
algorithm (also known as the
Shortest Path First algorithm, or
simply SPF) is run against the
contents of this database to create
the OSPF routing table. Routers
should have synchronized link state
databases.
To see the contents of the database,

run show ip ospf database. This
command shows the links and link
types, sequence numbers, and how
long it’s been since a particular
LSA was received. This value is in
seconds and is seen under the “age”
column.
The Dijkstra algorithm runs
against the contents of the OSPF
database…
R1#show ip ospf database

… calculates the routes, and these
routes are placed into the OSPF
routing table.
R1#show ip route ospf
6.0.0.0/32 is subnetted, 1 subnets
O
6.6.6.6 [110/11] via 10.1.1.5,
02:32:53, Ethernet0
7.0.0.0/32 is subnetted, 1 subnets
O
7.7.7.7 [110/11] via 10.1.1.5,
02:32:53, Ethernet0

The SPF algorithm actually
calculates a shortest path tree, and

that tree is used to create the routing
table. We don’t have to think much
more about the SPF algorithm since
it does a great job without our
interference, but we have plenty of
other details to attend to!
LSA Sequence Numbers
To ensure that OSPF routers receive
the most recent information, these
LSAs are assigned sequence
numbers. When an OSPF-enabled
router receives an LSA, that router
checks its OSPF database to see if
there is already an entry for that

link.
If there is no entry for that link, the
receiving router will make one
*and* flood that LSA out every
OSPF-enabled interface on the
router except the one it came in on.
If there is an entry, one of three
situations exists. Either the
incoming LSA has a sequence
number that is the same, lower, or
higher than the entry already in the
database.
If the sequence number is the
same, the LSA is ignored and

no additional action is taken.
If the sequence number is
lower, the router will ignore
the update and will then
transmit an LSU containing that
LSA back to the original
sender. In this situation, the
router with the more-recent
information is telling the
original sender, “The
information you’re sending is
outdated. Here’s what you
should be sending.”

If the sequence number is
higher, the router will add that
LSA to its database and send
an LSAcknowledgment. The
router will then flood that LSA
and will run the SPF algorithm
in order to update its own
routing table.
When Are LSAs Exchanged?
Distance vector protocols send
updates at a regularly scheduled
interval, regardless of whether
there has actually been a change in
the network topology. In a stable

network, this is a waste of network
resources. Once the initial exchange
of LSAs takes place between two
OSPF neighbors, there will not be
another exchange until there is a
change in the network topology.
An OSPF-speaking router will also
send out a summary LSA every 30
minutes.
Before this LSA exchange begins,
routers must become neighbors by
forming an adjacency. To form an
adjacency, routers must agree on the
area number, the hello and dead
timer settings, and whether the area

is a stub area. If link authentication
has been configured, it must be
configured on both sides of the link.
The OSPF process number itself is
locally significant and does not
affect the adjacency process.
To check your router’s adjacencies,
run show ip ospf neighbor or the
less-common show ip ospf
interface. That last command tends
to be forgotten, but there’s a lot of
great information there.
Note that both of these commands
tell you what neighbor relationships

currently exist, and only show ip
ospf neighbor shows you the status
of the database loading (FULL,
2WAY, etc)

R3#show ip ospf interface serial0
Serial0 is up, line protocol is up
Internet Address 172.12.123.3/24, Area 0
Process ID 1, Router ID 3.3.3.3, Network
Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DROTHER,
Priority 0
Designated Router (ID) 1.1.1.1, Interface
address 172.12.123.1
No backup designated router on this network
Timer intervals configured, Hello 30, Dead
120, Wait 120, Retransmit 5

Hello due in 00:00:16
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 3
Last flood scan time is 0 msec, maximum is
4 msec
Neighbor Count is 1, Adjacent neighbor
count is 1
Adjacent with neighbor 1.1.1.1
(Designated Router)
Suppress hello for 0 neighbor(s)

show ip ospf interface gives you
the local router’s OSPF RID, its
role on that segment (DR, BDR,
DROther), the RID of the DR and
BDR for that segment, how many
adjacencies the local router has
formed on that segment, and a lot
more. It’s an excellent starting point

for OSPF troubleshooting.
The Role Of The DR and BDR
A major drawback of distance
vector
protocol
is
slow
convergence.
Convergence refers to a network
state where every router has a
similar and accurate view of the
network, particularly after a
topology change such as a downed
route. Distance vector protocols
don’t converge quickly at all, which
can lead to suboptimal routing and
routing loops.

Link state protocols converge
almost immediately upon a topology
change. OSPF uses designated
routers and backup designated
routers
to
make
network
convergence a fast and orderly
process.
How
DRs
Changes

Flood

Network

When a router on an OSPF segment
with a DR and BDR detects a
change in the network, that router
will not notify all neighbors.
Instead, the detecting router will
send a multicast to 224.0.0.6, the

address to which both the DR and
BDR listen to learn about such
changes.
The DR will then send a multicast
to 224.0.0.5 to notify all non-DR
and non-BDR routers of the change.
(Routers that are neither the DR or
BDR for a network segment are
called DROthers, as shown in the
output of the command show ip ospf
neighbor.) The DROthers will send
an LSAcknowledgment, or LSAck,
back to the DR to indicate receipt
of the update.
Two notes here:

Only the DR and BDR listen to
224.0.0.6.
Only the DR will actually send
the multicast to 224.0.0.5 to
notify the DROTHERS of the
network change. The BDR
receives the original change
notification, but does not notify
other routers of that change.
Listening to 224.0.0.6 allows
the BDR to have the most
recent database entries
possible - and that’s important
in case it has to quickly
become the DR.

The DR/BDR Election Process
Almost every OSPF network
segment is going to contain a DR
and BDR. As always, there are
exceptions, and we’ll take a
detailed look at those situations
later in this section. For now, let’s
take a close look at the rules
regarding DR and BDR selection.
Consider the following network
diagram. (I could have put a switch
in the middle of this particular
diagram rather than a segment

labeled “ethernet”; be prepared to
see
either
in
network
documentation.)

Four routers have interfaces on the
Ethernet segment. One will become
the DR, one will become the BDR,
and the others will be DROthers.
Before we look at how Cisco
routers decide which routers will
fill these roles, let’s take an
overview of the OSPF DR/BDR
election process.
1. All routers with an OSPF
interface priority of 1 or higher are
eligible for the election. (That
priority of 1 is the default.) Setting
the interface priority to 0 will
eliminate that router from the
election on that segment.

2. The router with highest priority
is elected DR.
3. If there is a tie, the OSPF Router
ID (RID) value will be the
tiebreaker. The router with the
highest RID wins.
4. This process is repeated to elect
a new BDR. A single router cannot
be the DR and BDR for the same
segment.
There will be some interesting
behavior concerning DROthers on
an ethernet segment, which we’ll
discuss later in this section. For

now, the focus will remain on the
DR / BDR election process with an
examination of the OSPF RID.
The OSPF RID Selection Process
Obviously, the OSPF RID plays a
huge part in the selection of the DR
and BDR - but how is the RID
value determined? By this set of
rules:
The OSPF RID of a router will
be the highest IP address
assigned to a loopback
interface on that router,
regardless of whether that

loopback interface is OSPFenabled. A loopback interface
that is the OSPF RID is
*NOT* automatically
advertised by OSPF.
If no loopback exists, the
OSPF RID of a router will be
the highest IP address assigned
to a physical interface on that
router, regardless of whether
that interface is OSPFenabled.
These rules can both be

overridden by setting the
OSPF RID manually with the
router-id command, but the
router must be reloaded or the
OSPF processes cleared
before the command will take
effect.
It seems a little strange that a router
can have a loopback address that
isn’t being advertised by OSPF
actually serve as the RID, doesn’t
it?
Let’s see this in action. R1 and R5
have formed an OSPF adjacency

over an Ethernet segment on
network 10.1.1.0 /24. R5 has
multiple loopbacks, and is only
advertising two of them via OSPF:
hostname R5
!
interface Loopback6
ip address 6.6.6.6 255.255.255.255
!
interface Loopback7
ip address 7.7.7.7 255.255.255.255
!
interface Loopback8
ip address 8.8.8.8 255.255.255.255
!
interface Ethernet0
ip address 10.1.1.5 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0

network 7.7.7.7 0.0.0.0 area 0
network 10.1.1.0 0.0.0.255 area 0

Knowing what you know about
OSPF RIDs, what will R1 show as
the RID for R5? Take a moment to
look at the above configuration and
figure that out.
If you said 8.8.8.8, you’re right. To
see the OSPF RID of a neighbor,
run show ip ospf neighbor:
R1#show ip ospf neighbor

The value shown under Neighbor
ID is that neighbor’s RID.

To illustrate another important point
regarding DRs and BDRs, let’s go
back to our four-router example.
The routers have the following
addresses:
RouterA: Loopback 1.1.1.1, ethernet0 172.1.1.1
RouterB: Loopback 2.2.2.2, ethernet0 172.1.1.2
RouterC: No loopback, ethernet0 172.1.1.3
RouterD: No loopback, ethernet0 172.1.1.4

The RIDs would be as follows:
RouterA: 1.1.1.1
RouterB: 2.2.2.2

RouterC: 172.1.1.3
RouterD: 172.1.1.4

The RID process will always
prefer a loopback interface IP
address over a physical interface’s
IP address.
Summing up, we have three options
when it comes to manipulating the
DR selection:
Changing the OSPF priority
with ip ospf priority

Setting the OSPF Router ID
manually with router-id
Setting the OSPF Router ID to
an appropriate value by
configuring a loopback
interface
None of these choices are “wrong”
or “right” - so know all three, and
know that some reloading of routers
or clearing of OSPF processes will
be necessary in order to change the
results of a DR election.
What If The DR Goes Offline And

Then Back Online?
If all four of those routers came up
simultaneously and we have a fourway router election for DR and
BDR, we would expect to see
Router D become the DR and
Router C become the BDR. But
what happens if RouterD goes
down and then comes back up?
In RouterD’s absence, Router C
becomes the DR. Router B would
then become the BDR. And when
Router D comes back up, those
routers keep their roles.

This isn’t like Spanning-Tree
Protocol (STP), where a new
switch with a lower BID would
become the root bridge. With OSPF,
a DR/BDR election is not held
when a new router comes online or
when a router that was previously a
DR or BDR comes back online.
Let’s take an example where three
routers are on an Ethernet segment.
Router A has a priority of 100,
Router B a priority of 50, and R3 a
priority of 10. Router A has been
elected DR and Router B the BDR.

All is well until Router A goes
down. Router B will then become
the DR, and Router C will be
elected BDR.

Router A coming back on line is not
a reason for a DR/BDR election to
be held, even though Router A’s
priority is higher than the DR and
the BDR. When Router A comes
back up, it will be a DROther.

For Router A to become the DR
again, both the current DR and BDR
have to go down! What will happen
when Router B goes down?

Router C is promoted to DR and
Router A is elected BDR. When
Router B comes back up, it will
become a DROther.

For Router A to finally become the
DR again, now Router C will have
to go down. Router A will then be
promoted from BDR to DR, and
Router B will become the BDR.

When Router C comes back up, it
will be a DROther, and the network
is finally the way it was before!

The OSPF Network Types
Why OSPF Network Types Matter
The default OSPF network type
depends on the network segment

type. Different OSPF network types
have different default hello and
dead timers, and that’s one of the
factors that must match between two
routers for an adjacency to form. In
addition, some of these networks do
not have DRs and BDRs, and others
that do have special considerations
that must be observed.
Other than that, they’re all the same,
right? :)
No worries, we’re going to build
and cover each OSPF network type
you need to master to pass the
CCNP ROUTE exam right now!

Unless otherwise noted, each
segment is being placed into Area 0
- the backbone area.
The broadcast network’s subnet is
10.1.1.0 /24. The final octet of
every IP address will be that
router’s number. Every router has a
loopback interface with its router
number as each octet. (R1’s
loopback is 1.1.1.1 /32, and so
forth.)
The OSPF Broadcast Network

An OSPF configuration on an
Ethernet segment will default to an
OSPF broadcast network, and a DR
and BDR will be elected. If we
wanted one particular router to
become the DR or BDR, we could
use the ip ospf priority command to
rig the election.
On a large segment, it’s a good idea
to have your more powerful routers
fill these roles - being the DR or
BDR for a segment or segments
does increase the load on the CPU.
As always, everything we do on a
Cisco router has a cost.

The output of show ip ospf
interface ethernet0 on R1 displays
the network type, as well as a great
deal of other important information.
Note the default hello and dead
timers for a broadcast segment - 10
and 40 seconds, respectively. By
default, the dead time will be four
times the hello time.
R1# show ip ospf interface ethernet0
Ethernet0 is up, line protocol is up
Internet Address 10.1.1.1/24, Area 0
Process ID 1, Router ID 1.1.1.1,
Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State BDR, Priority
1
Designated Router (ID) 8.8.8.8, Interface
address 10.1.1.5

Backup Designated router (ID) 1.1.1.1,
Interface address 10.1.1.1
Timer intervals configured, Hello 10,
Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:04
Index 1/1, flood queue length 0

Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 4
msec
Neighbor Count is 1, Adjacent neighbor
count is 1
Adjacent with neighbor 8.8.8.8
(Designated Router)
Suppress hello for 0 neighbor(s)

It’s not a requirement to have a
certain router become the DR or

BDR on a broadcast segment, but
that’s not true of our next network
segment.
The OSPF NBMA Network
We’ll now add another network
segment to the existing adjacency,
this one running over a frame relay
cloud. The new segment will use
172.12.123.0 /24. R1 has a frame
relay PVC to both R2 and R3; there
is no PVC between the spokes. All
routers have their Serial0 interface
in Area 0.

The serial interfaces in this new
segment will default to the OSPF
network
type
non-broadcast
multiaccess, or NBMA. Since there
is no full mesh through the frame
cloud (no PVC between R2 and
R3), the hub router R1 has to be the
DR and there can be no BDR.
Why? Because the DR or any
potential BDR must be able to get a
multicast through to all other
routers on that network. With a huband-spoke topology, a spoke router
will not be able to get a multicast or

broadcast to the other spoke, since
all spoke-to-spoke traffic will go
through the hub - and routers do not
forward broadcasts or multicasts!
Before configuring any OSPF
configuration over frame relay,
make sure your frame map
statements have the broadcast
option enabled!
Otherwise, OSPF packets will not
be sent across the frame.
R1(config-if)#frame map ip 172.12.123.2 122
broadcast
R1(config-if)#frame map ip 172.12.123.3 123
broadcast

R1#show frame map
Serial0
(up):
ip
172.12.123.2
dlci
122(0x7A,0x1CA0), static,
broadcast,
CISCO, status defined, active
Serial0
(up):
ip
172.12.123.3
dlci
123(0x7B,0x1CB0), static,
broadcast,
CISCO, status defined, active

It’s not enough to make sure R1
wins the DR election - we’ve got to
prevent the spoke routers R2 and
R3 from having a chance to win! To
prevent R2 and R3 from
participating in the DR/BDR
election, change the OSPF priority
from its default of 1 to zero.

R2(config)#int s0
R2(config-if)#ip ospf priority 0
R3(config)#int s0
R3(config-if)#ip ospf priority 0

The router with the highest priority
set on an OSPF-enabled interface
will become the DR. If there is a
tie, the router with the highest OSPF
Router ID (RID) wins the election.
Basically, we’re rigging the DR
election so there’s no chance the
spokes can possibly win, even if the
hub disappears! Setting the spoke
priorities to zero prevents one of

the spokes from becoming the DR in
case the hub router reloads.
The “NB” in NBMA stands for
non-broadcast, so the hub router
must be configured with manual
neighbor statements, as shown
below. No neighbor statements are
needed on the spokes.
R1#conf t
Enter configuration commands, one per line. End
with CNTL/Z. R1(config)#router ospf 1
R1(config-router)#network
172.12.123.0
0.0.0.255 area 0
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3
R1#show ip ospf interface serial0

Serial0 is up, line protocol is up
Internet Address 172.12.123.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network
Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1, Interface
address 172.12.123.1
No backup designated router on this
network
Timer intervals configured, Hello 30, Dead
120, Wait 120, Retransmit 5
Hello due in 00:00:11
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 4 msec, maximum is
4 msec
Neighbor Count is 2, Adjacent neighbor
count is 2
Adjacent with neighbor 3.3.3.3
Adjacent with neighbor 2.2.2.2
Suppress hello for 0 neighbor(s)

You can have an NBMA network
where there is both a DR and BDR,
but they still both have to be hub
routers. A network with two hubs
could have one as the DR and the
other as the BDR. Every DR or
BDR in an NBMA network must
have static neighbor statements;
they are not needed on the other
routers. (If you have multiple hub
routers, you can have one of them
become the BDR.)
Note the default hello and dead
timers for an NBMA network - 30
and 120 seconds, respectively. The
dead timer is again four times the

hello timer by default.
Serial interfaces default to NBMA,
but you can also change an
interface’s OSPF network type to
NBMA with the ip ospf network
command.
R1(config-if)#ip ospf network ?
broadcast
Specify OSPF
broadcast multi-access network
non-broadcast
Specify OSPF NBMA
network
point-to-multipoint Specify OSPF point-tomultipoint network
point-to-point
Specify OSPF point-topoint network

The OSPF Point-To-Point And

Point-To-Multipoint
Types

Network

We’ll now add a direct connection
between R1 and R3, but put it into
Area 13. The network number is
172.12.13.0 /27. Both routers are
placing their interface Serial1 into
Area 13.

All non-backbone areas must
contain a router that has a physical
or logical interface in Area 0. Area
13 has two such routers, so the
configuration is legal.
show ip ospf interface serial1
shows this OSPF segment defaulted
to the OSPF network type point-topoint. This output also shows the
default hello and dead timers for
this network type - 10 and 40
seconds, respectively.
R3#show ip ospf interface serial1

Serial1 is up, line protocol is up
Internet Address 172.12.13.3/27, Area 13
Process ID 1, Router ID 3.3.3.3, Network
Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State
POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead
40, Wait 40, Retransmit 5
Hello due in 00:00:08
Index 1/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is
0 msec
Neighbor Count is 1, Adjacent neighbor
count is 1
Adjacent with neighbor 1.1.1.1
Suppress hello for 0 neighbor(s)

Note that no DR or BDR is listed.
On a point-to-point link, there are

only two routers on the link.
Therefore, there’s no reason to even
have a DR or BDR, and none will
be elected.
show ip ospf neighbor displays a
dash where the role of the neighbor
would usually be seen. The entire
DR/BDR election process is
bypassed with point-to-point and
point-to-multipoint networks. No
neighbor statements are necessary
with these network types. Below,
R3 sees R1 as the DR on the
NBMA segment while not seeing
R1 in any role on the point-to-point
network.

The dash next to FULL/ for that
adjacency indicates the neighbor is
neither a DR, BDR, or DROther,
which means there was no DR/BDR
election in the first place. You
would see the same situation on a
point-to-multipoint OSPF network,
which OSPF considers to be a
collection of point-to-point links.
For example, we could go back and
configure the frame relay OSPF
network as a point-to-multipoint
network by running the ip ospf

network
point-to-multipoint
command on R1’s serial interface.
There would be no DR or BDR
elected, and no neighbor statements
would be necessary.
The OSPF network type point-tomultipoint now offers both a
broadcast
and
nonbroadcast
option. We’ll now configure the
frame relay network as point-topoint broadcast and then point-topoint nonbroadcast.
Point-to-Multipoint
Broadcast
Network Configuration

This network type doesn’t require
use of the neighbor statement, but
you can use it to define a cost for a
given neighbor.
R1(config-if)#ip ospf network point-to-multipoint
?
non-broadcast Specify non-broadcast pointto-mpoint network
<cr>

Note that there is no option for
“broadcast” here; that’s because
broadcast is the default for point-tomultipoint.
R1(config-if)#router ospf 1
R1(config-router)#neighbor 172.12.123.2 ?

OSPF cost

cost

databasefilter

pollinterval

priority

point-tomultipoint
neighbor
Filter OSPF
LSA during
synchroniza
and floodin
for point-to
multipoint
neighbor

OSPF dead
router polli
interval
OSPF prior
of nonbroadcast

neighbor
<cr>
R1(config-router)#neighbor 172.12.123.2 cost ?
<1-65535> metric
R1(config-router)#neighbor 172.12.123.2 cost
20

Point-to-Multipoint
Nonbroadcast
Configuration

Network

On the other hand, use of the pointto-multipoint nonbroadcast network
type does require the neighbor
statement. You can assign costs to

neighbors if you choose, but the
neighbors must be statically defined
with this network type.
R1(config-if)#ip ospf network point-to-multipoint
non-broadcast
R1(config-router)#neighbor 172.12.123.2 cost
15
R1(config-router)#neighbor 172.12.123.3 cost
25

Running
OSPF
Networks
Over
Topologies:

Broadcast
NBMA

Just Because You Can Do
Something Doesn’t Mean You

Should!
We could have used the ip ospf
network broadcast command on all
the routers connected to the frame
network, and as long as there’s a
full mesh, technically the network
should work and the routers would
act as though they were actually
communicating through a LAN.
In the real world, using the OSPF
broadcast network type on an
NBMA segment can lead to
unpredictable results, and I
personally wouldn’t do it. Why
spend your time troubleshooting

when you can just stick with the
default?
The OSPF Virtual Link
The OSPF network running over the
frame cloud has been restored to the
default NBMA and it will remain
that type for the remainder of this
section.
We’ll now add R4 to the network.
R4 and R3 will have an adjacency
through Area 34, and R4 will have
its loopback placed into Area 4.
The network segment between R3

and R4 is 172.12.34.0 /24 and runs
over an ethernet segment.

This configuration will result in
incomplete routing tables, and that
brings us to our final OSPF network
type. There is no problem with
Area 34, since one router with an
interface in that area also has a
physical interface in Area 0 (R3).
However, no router with an
interface in Area 4 has a physical
interface in Area 0. This means a
logical connection to Area 0, a
virtual link, must be built.
Since R3 has a physical interface in

Area 0, building a virtual link
between R3 and R4 will allow full
IP connectivity throughout the
network. One problem with the
current topology is that R1 has no
route for R4’s loopback, even
though that interface has been
placed into the OSPF configuration.
R4: router ospf 1
network 4.4.4.4 0.0.0.0 area 4
network 172.23.23.0 0.0.0.31 area 34
R1#show ip route ospf
6.0.0.0/32 is subnetted, 1 subnets
O
6.6.6.6 [110/11] via 10.1.1.5,
01:05:45, Ethernet0
172.23.0.0/27 is subnetted, 1 subnets
O IA
172.23.23.0 [110/74] via
172.12.123.3, 00:04:14, Serial0

7.0.0.0/32 is subnetted, 1 subnets
O
7.7.7.7 [110/11] via 10.1.1.5,
01:05:45, Ethernet0

The area through which the virtual
link is built, the transit area, cannot
be a stub area of any kind - stub,
total stub, or not-so-stubby stub. (If
you’re rusty on those, don’t worry there’s a lot of information on these
areas coming later in the course!)
Here’s the command to create a
virtual link:
R4(config)#router ospf 1
R4(config-router)#area 34 virtual-link 3.3.3.3

A virtual link must be configured on
both ends of the transit area. We’ll
go over to R3 now and finish the
config.
R3(config)#router ospf 1
2d07h: %OSPF-4-ERRRCV: Received invalid
packet: mismatch area ID, from backbone
area must be virtual-link but not found from
172.23.23.4, Ethernet0
R3(config)#router ospf 1
R3(config-router)#area 34 virtual-link 4.4.4.4
R3(config-router)#^Z
2d07h: %OSPF-5-ADJCHG: Process 1, Nbr
4.4.4.4 on OSPF_VL0 from LOADING to
FULL, Loading Done

A few details worth noting…
The virtual link command uses

the remote device’s OSPF
RID, not necessarily the IP
address on the interface that’s
in the transit area. Watch that it’s a very common error.
Check that RID!
Also, don’t worry about that
error message you see in the
output from R3. That’s normal
and you’ll see it on R3 until
you finish building the virtual
link. If you see it after you’ve
completed the virtual link, you
do have a problem.

Always confirm the virtual link
with show ip ospf virtual-link. If
you’ve configured it correctly, the
VL should come up in a matter of
seconds.
R3#show ip ospf virtual-link
Virtual Link OSPF_VL0 to router 4.4.4.4 is
up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 34, via interface Ethernet0, Cost
of using 10
Transmit Delay is 1 sec, State
POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead
40, Wait 40, Retransmit 5
Hello due in 00:00:00
Adjacency State FULL (Hello
suppressed)
Index 2/4, retransmission queue length 1,

number of retransmission 1
First 0x2C8F8E(15)/0x0(0) Next
0x2C8F8E(15)/0x0(0)
Last retransmission scan length is 1,
maximum is 1
Last retransmission scan time is 0 msec,
maximum is 0 msec
Link State retransmission due in 3044
msec

Virtual links are actually simple to
configure, but for some reason they
seem to intimidate people. It’s my
experience that the error message
highlighted in R3’s output causes a
lot of panic, but the only thing that
message means is that you’re not
finished configuring the virtual link

yet.
Knowledge destroys fear and panic.
There
are
three
main
misconfigurations that cause 99% of
virtual link configuration issues:
Using the wrong OSPF RID
value
Trying to use a stub area as the
transit area
Failure to configure
authentication on the virtual

link when Area 0 is using
authentication
I put that third cause in bold for a
good reason. That last one is the
one that gets forgotten! A virtual
link is really an extension of Area
0, and if Area 0 is running
authentication, the virtual link must
be configured for it as well.
We’ve looked at a lot of OSPFcentric commands in this section,
but don’t forget our old friend show
ip protocols. Regardless of the
network type, that command will

show you the networks being
routed,
link
authentication
information, and much more. This is
a great command to start with when
you’re t-shooting any routing
protocol.

Why Not Just Use One Big Area 0
?

After you hear about the importance
of Area 0 for the 10,000th time, you
might start thinking, “Why not just
put all the routers into one big Area
0? That way, you wouldn’t have to
worry about design issues, virtual
links, or anything! After all, RIP
doesn’t use areas.”
That’s true, and it’s also one reason
you don’t see RIP in use on many
WANs. The use of OSPF areas
allows the creation of a hierarchy.
Now that sounds great, and Cisco
exams
love
the
word
“hierarchical”…. but what does it

mean? Here’s the definition of
“hierarchical”:
adj : classified according to
various criteria into successive
levels or layers
The Benefits
OSPF

Of

Multi-Area

That’s what OSPF areas allow you
to do - build a layered network.
This does help reduce the wear on
router resources such as CPU and
memory. Thanks to this layered
approach, sometimes a router
doesn’t need a huge routing table.

An unnecessarily large routing table
can be quite a drain on router
resources -- and if there’s only one
way for packets to get from a router
to multiple destinations, why have a
full routing table when a default
route will do?
A single-area OSPF deployment has
other
drawbacks.
Logically
dividing an OSPF network into
areas helps in limiting LSU and
LSA traffic, since notification of
changes in a multi-area OSPF
network can be limited to that area
only. This limiting of LSAs helps to
limit route table recalculations by

the Dijkstra algorithm as well.
Summing up, OSPF areas bring us
these benefits:
More efficient routing via
“complete yet concise” routing
tables
Fewer overall SPF
recalculations
Less LSU / LSA traffic and
associated overhead

Speaking of SPF recalculations, you
can see how many times this
algorithm has run with the show ip
ospf command. If you continually
see this number rising, there is an
unstable segment in that OSPF area.
(There is a lot of output with this
command, and it’s worth knowing.)
R3#show ip ospf
Routing Process “ospf 1” with ID 3.3.3.3
Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border router
SPF schedule delay 5 secs, Hold time between
two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA
arrival 1 secs
Number of external LSA 0. Checksum Sum
0x000000

Number of opaque AS LSA 0. Checksum Sum
0x000000
Number of DCbitless external and opaque AS
LSA 0
Number of DoNotAge external and opaque AS
LSA 0
Number of areas in this router is 3. 3 normal 0
stub 0 nssa
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area
is 2
Area has no authentication
SPF algorithm executed 10 times
Area ranges are
Number of LSA 12. Checksum Sum
0x06DBEB
Number of opaque link LSA 0.
Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 3

Flood list length 0
Area 13
Number of interfaces in this area
is 1
Area has no authentication
SPF algorithm executed 4 times
Area ranges are
Number of LSA 14. Checksum Sum
0x0822C6
Number of opaque link LSA 0.
Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 34
Number of interfaces in this area
is 1
Area has no authentication
SPF algorithm executed 6 times
Area ranges are
Number of LSA 15. Checksum Sum

0x06BDFB
Number of opaque link LSA 0.
Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

We’ll take an in-depth look at multiarea OSPF in the next section.
OSPF Path Cost Determination
When you look at an OSPF routing
table, you’ll see two numbers
contained in brackets. The first is
the administrative distance of
OSPF, which is 110. The second

number is the metric used by OSPF,
the cost of the path.
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d03h, Serial0
33.0.0.0/32 is subnetted, 1 subnets
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d02h, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d03h, Serial0
15.0.0.0/24 is subnetted, 1 subnets

OSPF assigns a cost to every
OSPF-enabled
interface.
The
interface cost is based on the port’s
speed. The default formula OSPF
uses to calculate the interface cost

is:
100,000,000 / Bandwidth in bps
(NOT kbps!)
You’ll see some documentation that
lists the first part of that formula as
10 to the 8th power, but I feel it’s
easier to remember 100,000,000
(one hundred million). If you have
reason to perform this calculation
manually, remember that the
expression for bandwidth here is
bits per second (bps), not thousands
of bits per second (kbps).
Here are some default OSPF

interface costs
interface speeds:

for

common

56 kbps = 1785
T1 line = 64
Ethernet = 10
16 MBPS Token Ring = 6
FDDI and 100 MBPS Ethernet
=1
In your CCNA studies, you learned
that the interface-level bandwidth
command can be used to give
EIGRP a more accurate picture of
the bandwidth of a serial link. This
command can also be used with

OSPF.
For example, if serial1 on a router
was running at 512 kbps rather than
the assumed serial link speed of
1544 kbps, the bandwidth command
can be used to give OSPF a truer
picture of the link speed. OSPF will
recalculate the path cost almost
immediately after using this
command.
The cost of an interface can be seen
with the show ip ospf interface
command. Note that this serial port
is shown with an OSPF cost of 64,
meaning that OSPF is assuming the

interface is connected to a T1 line.
If it were actually connected to a
512 kbps line, the bandwidth
command can be used on the
interface to reflect this, after which
OSPF will recalculate the cost.
R1#show ip ospf interface serial0
Serial0 is up, line protocol is up
Internet Address 172.12.123.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network
Type NON_BROADCAST, Cost: 64
R1#conf t
Enter configuration commands, one per line. End
with CNTL/Z.
R1(config)#interface serial0
R1(config-if)#bandwidth 512
R1#show ip ospf interface serial0

Serial0 is up, line protocol is up
Internet Address 172.12.123.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network
Type NON_BROADCAST, Cost: 195

The new bandwidth setting is about
one-third of the T1 speed OSPF
was assuming, so the new cost is
roughly three times the original
cost.
The OSPF path with the lowest cost
is preferred. Like RIP, OSPF will
load-balance over four equal-cost
paths by default.
You can actually change the value
that OSPF uses to base its path cost

calculation on. If you have a very
good reason to change it from
100,000,000, you can use the ospf
auto-cost
reference-bandwidth
command to do so. To add to the
fun, note that this command asks you
to enter the new bandwidth
reference value in MBPS:
R2#conf t
Enter configuration commands, one per line. End
with CNTL/Z.
R2(config)#router ospf 1
R2(config-router)#auto-cost
referencebandwidth ?
<1-4294967> The reference bandwidth in
terms of Mbits per second

One very good reason can be the

addition of Fast and GigEthernet
interfaces to your network. Since
those interfaces weren’t even
around when the costs we spoke of
earlier were developed, you may
(very) occasionally need to adjust
this
reference
bandwidth especially
with
GigEthernet
interfaces.
Comparing OSPF To RIP
OSPF is generally considered
superior to RIP. Here are just a few
of the reasons.

OSPF’s metric is a better
measurement of the actual
distance to a remote network.
OSPF uses a composite
metric, cost, where RIP uses
the sole metric of hop count.
OSPF does not impose a limit
on when networks are
“reachable” or “unreachable”,
where RIP has a maximum hop
count of 15 to combat the
counting to infinity issue.
OSPF supports VLSM, where
RIPv1 does not. RIPv2 does,

though. VLSM support allows
a protocol to have more
efficient utilization of IP
addresses than a protocol that
does not.
OSPF
utilizes
network
bandwidth
much
more
efficiently than RIP.
OSPF multicasts updates only
upon initial adjacency, a
network change, or expiration
of a 30-minute period where
there have been no network
changes. RIPv1 broadcasts full
routing tables every 30

seconds. RIPv2 does use
multicasting, but still sends
full routing tables every 30
seconds. (A single RIP update
can contain a maximum of only
25 routes, so a larger network
would require multiple update
packets.)
OSPF converges much more
quickly than either version of
RIP.
OSPF allows you to create a
hierarchical scheme by using
multiple areas. Neither version
of RIP offers this capability.

The main drawback of OSPF,
especially in comparison to RIP, is
that OSPF can be a lot harder on
router resources. OSPF operations
requires more CPU and memory
than RIP does.
Troubleshooting
Adjacencies

OSPF

You know from your CCNA studies
that OSPF adjacencies go through
the following states: Down,
Attempt, Init, 2-Way, Exstart,
Exchange, Loading, and Full.

Here’s a quick review of what’s
going on in each state:
Down - No hellos received from
that neighbor
Attempt - Unicast hello packets are
being sent to the neighbor. You’ll
only see this in OSPF NBMA
networks, since they’re configured
with neighbor commands.
Init - First Hello packet has been
received from this neighbor.
2-Way - Each router has received a
Hello packet containing its own

RID, meaning that bidirectional
communication is in place. When a
router receives a Hello packet
containing its own RID, that’s the
remote router’s way of saying “I
received the Hello packet you sent
me earlier.”
Exstart - Following DR / BDR
election, the exchange of link state
database information can begin. The
router with the highest OSPF RID
will begin the exchange and
increment the initial sequence
number, which is determined during
this stage.

Exchange - Database descriptor
(DBD) packets are exchanged;
these packets contain a description
of the link state database.
Loading - Routers now send Link
State Request (LSR) packets to
their potential neighbor.
Full - Router databases are
synchronized and the adjacency has
been formed.
Always use the show ip
neighbor and show ip
interface commands to ensure
OSPF adjacencies reach the

ospf
ospf
your
Full

stage. You can see neighbor
adjacencies with either command.
Show ip ospf neighbor gives you
the basic information regarding the
adjacency, while the interface
command gives you more detailed
information.

R1#show ip ospf interface ethernet 0
Ethernet0 is up, line protocol is up
Internet Address 100.1.1.1/24, Area 0
Process ID 1, Router ID 10.1.1.1,
Network Type BROADCAST,Cost: 10
Transmit Delay is 1 sec, State BDR,
Priority 1

Designated Router (ID) 19.1.1.1, Interface
address 100.1.1.5
Backup Designated router (ID) 10.1.1.1,
Interface address 100.1.1.1
Timer intervals configured, Hello 10, Dead
40, Wait 40, Retransmit 5
Hello due in 00:00:06
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is
0 msec
Neighbor Count is 1, Adjacent neighbor
count is 1
Adjacent with neighbor 19.1.1.1
(Designated Router)
Suppress hello for 0 neighbor(s)

Show ip ospf interface is excellent
for spotting issues related to hello

and dead timers. If you don’t see the
problem with the show command,
you can run debug ip ospf adj to
see the adjacencies form - or not
form! Here is just part of the output
from this command, and you can see
the different OSPF states the
adjacency goes through on the way
to Full.
4d22h: OSPF: Rcv DBD from 10.1.1.1 on
Serial1 seq 0x5DD opt 0x42 flag 0x7
len 32
mtu 1500 state INIT
4d22h: OSPF: 2 Way Communication to 10.1.1.1
on Serial1, state 2WAY
4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1
seq 0x14EC opt 0x42 flag 0x7
len 32

4d22h: OSPF: First DBD and we are not
SLAVE
4d22h: OSPF: Rcv DBD from 10.1.1.1 on
Serial1 seq 0x14EC opt 0x42 flag 0x2
len 9
2 mtu 1500 state EXSTART
4d22h: OSPF: NBR Negotiation Done. We are
the MASTER
4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1
seq 0x14ED opt 0x42 flag 0x3
len 92
4d22h: OSPF: Database request to 10.1.1.1
4d22h: OSPF: sent LS REQ packet to
13.13.13.1, length 12
4d22h: OSPF: Rcv DBD from 10.1.1.1 on
Serial1 seq 0x14ED opt 0x42 flag 0x0
len 3
2 mtu 1500 state EXCHANGE
4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1
seq 0x14EE opt 0x42 flag 0x1
len 32
4d22h: OSPF: Rcv DBD from 10.1.1.1 on

Serial1 seq 0x14EE opt 0x42 flag 0x0
len 3
2 mtu 1500 state EXCHANGE
4d22h: OSPF: Exchange Done with 10.1.1.1 on
Serial1
R22h: OSPF: Synchronized with 10.1.1.1 on
Serial1, state FULL
4d22h: %OSPF-5-ADJCHG: Process 1, Nbr
10.1.1.1 on Serial1 from LOADING to FULL,
Loading Done
4d22h: OSPF: Build router LSA for area 0,
router ID 172.12.123.3, seq 0x80000005

In short, for OSPF adjacencies to
form, the following must be agreed
upon by the potential neighbors:
Hello and dead timers

The Area ID
Stub area flag setting (on or
off)
Link authentication password
(use is optional, but if used,
both neighbors must agree on
the password)
The process number does not have
to be agreed upon - that value is
locally significant only. (Yeah, I
know I said that before. I’m saying
it again. :) )
Adjacency
Behavior
With
Multiple OSPF Routers On A
Broadcast Segment

When you have more than two
OSPF routers on a broadcast
segment, you’ll get some interesting
adjacency results. I get asked about
this one often in Facebook and
Twitter (@ccie12933, by the way),
so I thought I’d include it here.

The election has already taken

place, with R1 as the DR, R2 as the
BDR, and R3 and R4 as the
DROTHERS. The OSPF neighbor
tables on R1 and 2 look like you
would expect, but the DROthers’
tables look a little odd.

You’ll
hear
about
OSPF
adjacencies “stuck in 2-way”, and
many people think that’s what is
happening here, but it’s not. The

DROTHERS are never going to
finish forming that adjacency. We
could come back tomorrow and
they would still be in 2-way!
This is actually a default behavior
of OSPF that helps to cut down on
the number of LSAs being
transmitted on a broadcast segment
with more than 2 routers.
The only routers that will have an
adjacency to all other routers on the
segment are the DR and BDR. Each
DROther will have a full adjacency
with both the DR and BDR, but
never with another DROther.

For this reason, any router that
detects a change in the network will
multicast news of this change to the
DR and BDR only - the remaining
DROthers will then learn about it
from the DR.
Now
that
fundamentals
cold…

we
have
the
of OSPF down

… let’s tackle multiarea OSPF!
Recommended
Videos:

OSPF

YouTube

OSPF Router Types:
http://www.youtube.com/watch?
v=QNQCy-LQLFY
OSPF Hub-And-Spoke Checklist
http://www.youtube.com/watch?
v=46x--GIiKZk
OSPF Total Stub Areas:
http://www.youtube.com/watch?
v=DwZIRMfTaE4

OSPF Stub Areas In Action:
http://www.youtube.com/watch?
v=rHNXyNJpfpM
OSPF ASBRs:
http://www.youtube.com/watch?
v=hGrbyb6p4MI
My YouTube Channel Page:

http://www.youtube.com/user/ccie12
Free CCNP ROUTE Video Boot

Camp on OSPF stub areas and route
redistribution:
http://www.udemy.com/ccnp-routeboot-camp-redistribution-and-ospfstub-areas/

Copyright © 2012, The Bryant Advantage.
All Rights Reserved.

Multi-Area OSPF And
Route Summarization

OSPF Design Guidelines
Just
about
every
OSPF
configuration you work with in the
real world is going to be a multiarea setup, for reasons we touched
on in the previous section and that
we’ll add to here.
Cisco exam success lies in knowing
the details, and that applies

especially to OSPF, because there
are a lot of details to learn with
multi-area OSPF. As with all things
Cisco, learning it “piece by piece”
instead of looking at this section as
a whole will help you master those
details for your exam and your
career. Those of you with an eye on
the CCIE
will truly have to master the details
of OSPF!
Before we begin to build our multiarea OSPF configuration, there are
some design rules that Cisco would
like you to keep in mind. Design

rules are generally subjective, but
these OSPF design rules are
particularly important since they are
designed to keep the demand on the
router’s
CPU
and
memory
resources to a reasonable level.
(The term “reasonable level” is
subjective as well - generally, your
more powerful routers will be at
the core of your network while the
lesser routers will be at the
outskirts.)
No router should be in more
than three areas.

No area should contain more
than 50 routers.
No router should have more
than 60 neighbors.
A router can be a DR or BDR
for more than one network
segment, but be careful that the
router is not overworked by
doing so.
Do not run more than one
OSPF process on an Area
Border Router.

Of all the OSPF design rules, it’s
my experience that you really have
to watch the one regarding having
too many routers in a single area.
This ends up causing more LSA
traffic than you really need, which
in turn means you’ve got more
routers having to recalculate their
routing tables more and more often,
which in turn puts an unnecessary
load on the CPU of the routers.
Why Build Multiple Areas?
Using a hierarchical, multi-area

approach to OSPF delivers these
benefits:
Route summarization is made
possible (and simpler) through
a layered approach to address
allocation.
In turn, route summarization
helps keep routing tables
concise yet complete, which
lessens the load on a router’s
CPU during the routing
process. Smaller routing tables
are better than larger routing
tables, but they still have to be

complete! Using multiple
OSPF areas helps us
accomplish that.
By creating multiple areas,
LSA flooding upon a change in
the network is localized. For
example, LSA Types 1 and 2
don’t leave the local area.
This results in fewer Link
State Updates traveling across
the OSPF network as a whole.
(If you’re rusty on LSA types,
don’t worry, we’ll go over
those in this section!)

As a result, fewer Shortest
Path First (SPF) recalculations
are needed.
Let’s look at how the creation of
OSPF stub and total stub areas help
to deliver these benefits.
Stub And Total Stub Areas
Area 0 is the backbone area of an
OSPF configuration. When creating
a multi-area OSPF network, every
non-backbone area must contain a
router that has a physical or logical
connection (virtual link) to Area 0.

Traffic going from one nonbackbone area to another nonbackbone area must cross Area 0.
For that reason, Area 0 is generally
going to be found at the center, or
core, of the network. The network
we will build in this section will
have Area 0 at the very center.
We’ll start by placing the serial0
interface on R1, R2, and R3 into
Area 0. The network 172.12.123.0
/24 is running over the frame, with
each router using its router number
as the 4th octet. The loopback of
each router will be placed into an

area numbered using the router
number; that is, R1’s loopback,
1.1.1.1, will be placed into Area 1,
and so forth.
This is a hub-and-spoke network,
so the special considerations you
learned for this topology in the “LS
Protocols And Single-Area OSPF”
sections must be put into action:
The hub will need neighbor
statements
The hub must become the DR

The spokes must not take part
in the DR/BDR election
If you’re running this lab, be sure to
check your connectivity across the
frame network before applying the
OSPF config - that can save you a
lot of unnecessary troubleshooting.

R1(config)#router ospf 1
R1(config-router)#network
172.12.123.0
0.0.0.255 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area
1
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3

R2(config)#interface serial0
R2(config-if)#ip ospf priority 0

R2(config-if)#router ospf 1
R2(config-router)#network
172.12.123.0
0.0.0.255 area 0
R2(config-router)#network 2.2.2.2 0.0.0.0 area
2

R3(config)#interface serial0
R3(config-if)#ip ospf priority 0

R3(config-if)#router ospf 1
R3(config-router)#network
172.12.123.0
0.0.0.255 area 0
R3(config-router)#network 3.3.3.3 0.0.0.0 area
3

Verify with show ip ospf neighbor.

Both R2 and R3 see R1 as the DR,
and R1 sees both R2 and R3 as
“DROTHER”, indicating those two
routers are neither the DR nor the

BDR. Also note that the neighbor
IDs are the neighbor’s RIDs, and as
we would expect at this point, the
RID for each router is the router’s
single loopback address.
Since our three non-backbone areas
all have a router physically
connected to Area 0, the
configuration is valid and each
router has a route to both remote
loopback addresses.
R1#show ip route ospf
2.0.0.0/32 is subnetted, 1 subnets
O AI
2.2.2.2 [110/65] via 172.12.123.2,
00:00:00, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O AI
3.3.3.3 [110/65] via 172.12.123.3,

00:00:00, Serial0
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O AI
1.1.1.1 [110/65] via 172.12.123.1,
00:00:23, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O AI
3.3.3.3 [110/65] via 172.12.123.3,
00:00:23, Serial0
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O AI
1.1.1.1 [110/65] via 172.12.123.1,
00:01:59, Serial0
2.0.0.0/32 is subnetted, 1 subnets
O AI
2.2.2.2 [110/65] via 172.12.123.2,
00:00:07, Serial0

The routes to the remote loopbacks
are all marked “O IA”. The “O”
refers to OSPF, and the “IA” refers

to an inter-area route - a route to a
destination located in another OSPF
area. Since each router borders
Area 0 and connects another area to
Area 0, each router in the current
network is an ABR - an Area
Border Router.
This is confirmed in this
abbreviated output of show ip ospf :
R1#show ip ospf
Routing Process “ospf 1” with ID 1.1.1.1
Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border router

R2#show ip ospf
Routing Process “ospf 1” with ID 2.2.2.2

Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border router

R3#show ip ospf
Routing Process “ospf 1” with ID 3.3.3.3
Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border router

Now we’ll bring in another router
and another area. R4 is connected
to R3 via the segment 172.34.34.0
/24, and both will have their
Ethernet interfaces placed into Area
34.

R3(config)#router ospf 1
R3(config-router)#network
0.0.0.255 area 34

R4(config)#router ospf 1
R4(config-router)#network

172.34.34.0

172.34.34.0

0.0.0.255 area 34

Always verify new adjacencies!

R4 now has an adjacency with R3.
Let’s take a look at R4’s OSPF
routing table:
R4#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
3.0.0.0/32 is subnetted, 1 subnets

O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:01:03, Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
O IA
172.12.123.0 [110/74] via
172.34.34.3, 00:01:03, Ethernet0

All the OSPF routes on R4 are
OSPF
inter-area
routes,
as
indicated by O IA. We can also see
that the next-hop IP address is the
same for all four routes. It would
have to be, since there’s only one
exit point for any data R4 sends to
any of these destinations. It seems
like a bit of a waste of time to have
all of these specific routes in the
routing table when they’ve all got

the same next-hop IP address,
doesn’t it?
Let’s keep that in mind.
We’re also going to bring some
more routes into this OSPF
configuration
via
route
redistribution. Route redistribution
is the process of taking routes
known by another method -whether that be another routing
protocol, another instance of the
same protocol, or a connected /
static route - and placing them into
another protocol.

Routes that are being redistributed
into another protocol are sometimes
referred to as being injected into
that domain.
R5 will now be added to our
network. R5 and R1 are both on the
15.0.0.0 /8 network, and are both
running RIP version 2. R5 has three
loopback addresses - 5.1.1.1 /8,
6.1.1.1 /8, and 7.1.1.1. /8. R5 will
advertise all its loopback addresses
via RIPv2. R1 will run RIP only on
the 15.0.0.0/8 network.

R5(config)#router rip
R5(config-router)#version 2
R5(config-router)#no auto-summary

R5(config-router)#network 5.0.0.0
R5(config-router)#network 6.0.0.0
R5(config-router)#network 7.0.0.0
R5(config-router)#network 15.0.0.0
R1(config)#router rip
R1(config-router)#version
2
R1(configrouter)#no auto
R1(config-router)#network 15.0.0.0

R1 will see all of R5’s loopbacks
in its RIP routing table. R1 also has
a route to R2’s loopback, R3’s
loopback, and the 172.34.34.0 /24
network in its OSPF table.
R1#show ip route rip
R
5.0.0.0/8 [120/1] via 15.1.1.5, 00:00:03,
Serial1
R
6.0.0.0/8 [120/1] via 15.1.1.5, 00:00:03,
Serial1
R
7.0.0.0/8 [120/1] via 15.1.1.5, 00:00:03,

Serial1

R1#show ip route ospf
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/65] via 172.12.123.2,
00:04:17, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
00:04:17, Serial0
172.34.0.0/24 is subnetted, 1 subnets
O IA
172.34.34.0 [110/74] via
172.12.123.3, 00:04:17, Serial0

On R1, the RIP routes and
15.0.0.0/8 (a directly connected
network) will be redistributed into
OSPF, and the OSPF routes along
with 172.12.123.0 /24 (a directly
connected network) will be

redistributed into RIP. The directly
connected routes have to be
redistributed along with the
dynamically learned routes, or hosts
in the RIP domain could not ping
host addresses in the OSPF domain.
Forgetting to redistribute the
connected networks is a common
error in route redistribution. The
remote protocol’s routes will be
seen, but pings won’t go through.
R1(config)#router ospf 1
R1(config-router)#redistribute connected
% Only classful networks will be
redistributed
R1(config-router)#redistribute
connected

subnets
R1(config-router)#redistribute rip subnets
R1(config-router)#router rip
R1(config-router)#redistribute connected metric
1
R1(config-router)#redistribute ospf 1 metric 1

Note that when the connected
networks and RIP routes were
redistributed into OSPF, the subnets
option had to be used to allow
subnet redistribution. Also, when
redistributing connected networks
and OSPF routes into RIP, a seed
metric had to be supplied.
The seed metric is a “starting
metric” for the paths being

redistributed and is required for
routes being redistributed into RIP
and EIGRP. OSPF uses a default
seed metric of 20, so no metric has
to be set for the connected and RIP
subnets redistributed into OSPF.
The OSPF router that redistributes
routes into the OSPF domain is the
Autonomous System Border Router
(ASBR). If a router is an ABR and /
or ASBR, you’ll see that in the
output of show ip ospf. You’ll also
see the source of the routes being
redistributed. Note that a router can
be both an ABR and ASBR, as R1
is here.

R1#show ip ospf
Routing Process “ospf 1” with ID 1.1.1.1
Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border and autonomous
system boundary router
Redistributing External Routes from,
connected, includes subnets in
redistribution
rip, includes subnets in redistribution

To see all the ABRs and ASBRs,
run show ip ospf border-routers.
Running this command on R3
verifies that R2 is an ABR and R1
is an ABR/ASBR:
R3#show ip ospf border-routers
OSPF Process 1 internal Routing Table

Codes: i - Intra-area route, I - Inter-area route
i 1.1.1.1 [64] via 172.12.123.1, Serial0,
ABR/ASBR, Area 0, SPF 38
i 2.2.2.2 [64] via 172.12.123.2, Serial0, ABR,
Area 0, SPF 38

At this point, R5 should have all the
OSPF routes in its routing table,
and should be able to ping any
address in the OSPF configuration.
Here is R5’s RIP routing table,
followed by pings of all remote
loopback interfaces and R4’s
Ethernet0 interface.
Note there is no special code for
routes being introduced into RIP via
route redistribution. “R” is “R”.

R5#show ip route rip
1.0.0.0/32 is subnetted, 1 subnets
R
1.1.1.1 [120/1] via 15.1.1.1, 00:00:20,
Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
R
2.2.2.2 [120/1] via 15.1.1.1, 00:00:20,
Ethernet0
3.0.0.0/32 is subnetted, 1 subnets
R
3.3.3.3 [120/1] via 15.1.1.1, 00:00:20,
Ethernet0
172.34.0.0/24 is subnetted, 1 subnets
R
172.34.34.0 [120/1] via 15.1.1.1,
00:00:20, Ethernet0
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
R
172.12.123.0/24 [120/1] via 15.1.1.1,
00:00:20, Ethernet0

R5# ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 4/5/8 ms

R5#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/68/72 ms

R5#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3,

timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/70/72 ms

R5#ping 172.34.34.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.34.34.4,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 96/100/108 ms

R5 can indeed see the OSPF routes
and can ping all three remote
loopbacks. Notice that there’s no
special code next to a RIP route that

was
originally learned
via
redistribution - the only RIP route
code is “R”.
Let’s take a look at R4’s OSPF
routing table, and see if R4 can ping
R5’s loopbacks.
R4#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:33:33, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:33:33, Ethernet0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:33:33, Ethernet0
5.0.0.0/32 is subnetted, 1 subnets
O E2
5.1.1.1 [110/20] via 172.34.34.3,

00:33:21, Ethernet0
6.0.0.0/32 is subnetted, 1 subnets
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
O IA
172.12.123.0/24 [110/74] via
172.34.34.3, 00:33:33, Ethernet0
7.0.0.0/32 is subnetted, 1 subnets
O E2
7.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
15.0.0.0/24 is subnetted, 1 subnets
O E2
15.1.1.0 [110/20] via 172.34.34.3,
00:33:32, Ethernet0

R4#ping 5.1.1.1
Type escape sequence to abort.

(Ever notice the router doesn’t tell

you the ping escape sequence? It’s
<ctrl-shift-6> TWICE, in rapid
succession.)
Sending 5, 100-byte ICMP Echos to 5.1.1.1,
timeout is 2 seconds: !!!!! Success rate is 100
percent (5/5), round-trip min/avg/max = 68/68/72
ms

R4#ping 6.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.1.1.1,
timeout is 2 seconds:!!!!! Success rate is 100
percent (5/5), round-trip min/avg/max = 68/69/76
ms

R4#ping 7.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.1.1.1,
timeout is 2 seconds:!!!!! Success rate is 100
percent (5/5), round-trip min/avg/max = 68/70/76
ms

In addition to the O IA routes, we
now see some O E2 routes as well.
O E2 routes are OSPF External
Type 2 routes, and these are routes
that were originally learned via
redistribution.
We’ll concentrate on the size of this
routing table, what impact that
could have, and how we can
possibly shrink this table a bit
without sacrificing connectivity.

Examining R4’s OSPF routing
table, we see that every single one
of the external routes has one thing
in common -- the next-hop IP
address.
O E2
5.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
6.0.0.0/32 is subnetted, 1 subnets
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
O E2
7.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
15.0.0.0/24 is subnetted, 1 subnets
O E2
15.1.1.0 [110/20] via 172.34.34.3,
00:33:32, Ethernet0

It’s a waste of time and resources

for R4 to look through all these
routes for packets with a destination
external to OSPF, because the next
hop is going to be the same -172.34.34.3.
OSPF allows us to substitute a
single default route for all external
destinations by making Area 34 a
stub area. Configuring an area as
stub prevents LSA Type 5s from
flooding the stub area.
It’s not enough to configure Area 34
as a stub on R4 or R3. Every router
in the area must agree that this is a
stub area, or adjacencies will drop.

Configuring an area as stub is
referred to as “setting the stub flag”
or “setting the stub bit”. Watch what
happens when an area is configured
as stub on R3, but not R4:
R3#conf t
Enter configuration commands, one per line. End
with CNTL/Z.
R3(config)#router ospf 1
R3(config-router)#area 34 stub
4d06h: %OSPF-5-ADJCHG: Process 1, Nbr
4.4.4.4 on Ethernet0 from FULL to DOWN,
Neighbor Down: Dead timer expired

Configuring the area as stub on R4
will bring the adjacency back up:
R4#conf t
Enter configuration commands, one per line. End

with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#area 34 stub

Area 34 is now a stub area. Look at
R4’s OSPF routing table:
R4#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:01:07, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:01:07, Ethernet0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:01:07, Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
O IA
172.12.123.0 [110/74] via

172.34.34.3, 00:01:07, Ethernet0
O*IA 0.0.0.0/0 [110/11] via
00:01:07, Ethernet0

172.34.34.3,

With that simple config, the size of
the routing table has been cut in
half. The E2 routes have been
replaced with a single default route,
as indicated by the asterisk. R5’s
loopback addresses can still be
pinged:
R4#ping 5.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.1.1.1,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/71/80 ms

R4#ping 6.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.1.1.1,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/69/72 ms

R4#ping 7.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.1.1.1,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/70/72 ms

The cost for the default route can be
adjusted with the default-cost
command. On R3, we’ll change the

OSPF metric for the default route to
20, which should give it a total cost
of 30 on R4:
R3(config)#router ospf 1
R3(config-router)#area 34 default-cost 20

R4#show ip route ospf
O*IA 0.0.0.0/0 [110/30] via 30.1.1.3, 00:00:09,
Ethernet0

The routing table is half its
previous size while still allowing
full connectivity. We can take this
one step further, since the four nondefault inter-area routes all have the
same next-hop IP address as well.
OSPF allows the configuration of a

total stub area, where all external
and inter-area routes are replaced
with a single default route.
One single addition to R3 will do
this. The no-summary option added
to the ABR of the stub area will
make this a total stub area. Making
an area a total stub prevents LSA
types 3, 4, and 5 from flooding into
the area.
The ABR is the only router that
needs the no-summary option
enabled. no-summary doesn’t have
to be added to the other routers in
the area, but they still have to be

configured as stub.
R3(config)#router ospf 1
R3(config-router)#area 34 stub no-summary

A little “theory vs. real-world”
discussion is merited here. In the
real world, you’ll often see OSPF
total stub areas that have every
router in the total stub configured
with no-summary. That doesn’t hurt
anything, but only the ABR needs
that option enabled.
Personally, on the exam and in real
life, I would only configure nosummary on the ABR.

Where R4 had nine OSPF inter-area
and external routes, it now has a
single default route for all those
destinations:
R4#show ip route ospf
O*IA 0.0.0.0/0 [110/30]
00:07:26, Ethernet0

via

172.34.34.3,

Now we’ve seen that with an OSPF
stub area, you can have routes to
other destinations in the area (O),
inter-area routes (O IA), and a
default inter-area route to reach the
external destinations (O *IA).
With a total stub area, you’ll see
only routes to other networks in the

total stub area (O) and a single
default route used to reach all other
destinations (O *IA). If we add a
loopback to R3 in this configuration
and place it in Area 34, R4 will see
it as an intra-area route and it will
have a specific entry in the OSPF
table.
R3(config)#int loopback33
R3(config-if)#ip
address
33.33.33.33
255.255.255.255
R3(config-if)#router ospf 1
R3(config-router)#network 33.33.33.33 0.0.0.0
area 34
R4#show ip route ospf
33.0.0.0/32 is subnetted, 1 subnets
O
33.33.33.33 [110/11] via 172.34.34.3,
00:00:03, Ethernet0

O*IA 0.0.0.0/0 [110/30]
00:00:03, Ethernet0

via

172.34.34.3,

You can take a good idea too far,
though. If stub areas are so great,
let’s make Area 0 a stub! After all,
R2 and R3 only have one possible
next
hop
to
the
external
destinations, and that’s through R1.
So let’s try that…
R1#conf t
Enter configuration commands, one per line. End
with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#area 0 stub
OSPF: Backbone can not be configured as
stub area

Whoops.

One of the things I like most about
Cisco equipment is that nine out of
ten times, the router or switch is
going to stop you from doing
something you really shouldn’t do.
Or at the very least, you’ll be
warned!
Here, the router won’t let you make
Area 0 a stub area, because Area 0
is prohibited from being a stub or
total stub. The CCNP ROUTE exam
probably won’t be so kind as to tell
you that.
“Not So Stubby Stub Areas”

The final OSPF area type is an
NSSA, short for “not-so-stubby stub
area”. An NSSA is a stub area that
contains a limited number of
external routes. An NSSA is the
only area that will use a Type 7
LSA, which you’ll read more about
in the LSA review later in this
section.
This is a highly specialized OSPF
area type, and it’s not common, but
they are out there. Let’s take a look
at the commands to configure a stub
NSSA and total stub NSSA.
We’ll now add another loopback to

R3 and inject it into the OSPF
domain with the redistribute
connected subnets command.
R3(config)#int loopback14
R3(config-if)#ip
address
255.255.255.255

14.14.14.14

R3(config)#router ospf 1
R3(config-router)#redistribute
subnets

connected

R1 will see the route as an E2
route…
R1#show ip route ospf
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/65] via 172.12.123.2,
00:03:11, Serial0
33.0.0.0/32 is subnetted, 1 subnets

O IA
33.33.33.33 [110/65] via
172.12.123.3, 00:03:11, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
00:03:11, Serial0
172.34.0.0/24 is subnetted, 1 subnets
O IA
172.34.34.0 [110/74] via
172.12.123.3, 00:03:12, Serial0
14.0.0.0/32 is subnetted, 1 subnets
O E2
14.14.14.14 [110/20] via
172.12.123.3, 00:01:48, Serial0

…but R4 will not, since R4 is in a
total stub area.
R4#show ip route ospf
33.0.0.0/32 is subnetted, 1 subnets
O
33.33.33.33 [110/11] via
172.34.34.3, 01:02:10, Ethernet0
O*IA 0.0.0.0/0 [110/30] via 172.34.34.3,
01:02:10, Ethernet0

We’ll remove the total stub
statement from R3 and the stub
statement from R4, and replace both
statements with area 34 nssa,
which will make Area 34 a not-sostubby stub area. Note that the
adjacencies reset during this
process.
R3(config-router)#no area 34 stub no-summary
01:40:26: %OSPF-5-ADJCHG: Process 1, Nbr
4.4.4.4 on Ethernet0 from FULL to DOWN,
Neighbor Down: Adjacency forced to reset
R3(config-router)#area 34 nssa
R4(config)#router ospf 1
R4(config-router)#no area 34 stub

R4(config-router)#area 34 nssa
01:41:20: %OSPF-5-ADJCHG: Process 1, Nbr
4.4.4.4 on Ethernet0 from LOADING to FULL,
Loading Done

R4 now sees the route as N2, which
is an NSSA External route.
R4#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:00:14, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:00:14, Ethernet0
33.0.0.0/32 is subnetted, 1 subnets
O
33.33.33.33 [110/11] via
172.34.34.3, 00:00:14, Ethernet0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:00:14, Ethernet0

172.12.0.0/24 is subnetted, 1 subnets
O IA
172.12.123.0 [110/74] via
172.34.34.3, 00:00:14, Ethernet0
14.0.0.0/32 is subnetted, 1 subnets
O N2
14.14.14.14 [110/20] via 172.34.34.3,
00:00:14, Ethernet0

We can configure Area 34 as a
“not-so-stubby total stub” area by
adding the no-summary command
to R3’s NSSA statement. Note that
the adjacency again goes down.
R3(config)#router ospf 1
R3(config-router)#area 34 nssa ?

defaultinformationoriginate

Origina
Type 7
default
NSSA a

noredistribution

no-summary

No
redistri
into this
NSSA a
Do not
summar
LSA int
NSSA

<cr>
R3(config-router)#area 34 nssa no-summary
01:43:51: %OSPF-5-ADJCHG: Process 1, Nbr
4.4.4.4 on Ethernet0 from FULL to DOWN,
Neighbor Down: Adjacency forced to reset
01:43:53: %OSPF-5-ADJCHG: Process 1, Nbr
4.4.4.4 on Ethernet0 from LOADING to FULL,
Loading Done

R4 now has a default route in
addition to the N2 route.
R4#show ip route ospf
33.0.0.0/32 is subnetted, 1 subnets
O
33.33.33.33 [110/11] via
172.34.34.3, 00:00:25, Ethernet0
14.0.0.0/32 is subnetted, 1 subnets
O N2
14.14.14.14 [110/20] via 172.34.34.3,
00:00:25, Ethernet0
O*IA 0.0.0.0/0 [110/30] via 172.34.34.3,
00:00:25, Ethernet0

OSPF Route Types
You saw several different OSPF
route types in the previous section.
Taking a look at the following
partial output of show ip route, let’s

go over the meaning of each type.
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2
- OSPF NSSA external type 2
E1 - OSPF external type 1, E2 OSPF external type 2, E - EGP

O - A route to a destination in the
same area. A loopback with IP
address 33.33.33.33 has been
added to Area 34, and R4 sees it as
an “O” route.
R4#show ip route ospf
33.0.0.0/32 is subnetted, 1 subnets
O
33.33.33.33 [110/11] via

172.34.34.3, 00:00:03, Ethernet0

O IA - A route to a destination in
another OSPF area. Before making
Area 34 a total stub area, R4 had a
few of these:
R4#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:01:03, Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
O IA
172.12.123.0 [110/74] via
172.34.34.3, 00:01:03, Ethernet0

O E2 AND O E1: Both codes
indicate external routes. OSPF
external routes are routes learned
via redistribution. Before making
Area 34 a stub area, R4 had these
E2 routes:
O E2
5.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
6.0.0.0/32 is subnetted, 1 subnets
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
172.12.0.0/16 is variably subnetted, 2
subnets, 2 masks
O E2
172.12.21.0/30 [110/20] via
172.34.34.3, 00:33:32, Ethernet0
O E2
7.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
15.0.0.0/24 is subnetted, 1 subnets
O E2
15.1.1.0 [110/20] via 172.34.34.3,

00:33:32, Ethernet0

The difference between E2 and E1
routes is that the metric of an E2
route only reflects the cost of the
path between the ASBR and the
final destination. The cost between
R4 and the ASBR (R1) is not
considered in the metric.
The metric of an E1 route reflects
the OSPF cost of the entire path
from the local router to the final
destination.
To see the difference, we’ll look at
two of the original external routes

in R4’s routing table. E2 is the
default:
O E2
5.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0 O
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0

The metric is 20. This is the cost
from the ASBR to the destination.
The cost of the path from R4 to the
ASBR, R1, is not included in this
metric.
To redistribute routes into OSPF as
E1 routes, use the metric-type
option:
R1(config)#router ospf 1

R1(config-router)#redistribute
rip
subnets
metric-type ?
1 Set OSPF External Type 1 metrics
2 Set OSPF External Type 2 metrics
R1(config-router)#redistribute
metric-type 1

rip

subnets

Look at the same two routes in R4’s
routing table, which are now
displayed as E1 routes:
O E1
5.1.1.1 [110/94] via 172.34.34.3,
00:04:13, Ethernet0
6.0.0.0/32 is subnetted, 1 subnets
O E1
6.1.1.1 [110/94] via 172.34.34.3,
00:04:14, Ethernet0

The routes now show a larger
metric - 94. That’s because this is

the OSPF cost for the entire path
from R4 to each of the destination
networks.
There are two other route types in
that OSPF table that merit
discussion:
N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2
These route types will obviously be
found only in NSSAs. It can be a
little confusing to keep up with the
different route types that can be
found in stub, total stub, and not-sostubby areas, so here’s a summary:

Stub areas can contain O, O IA, and
O* IA routes.
Total stub areas can contain O and
O* IA routes only.
NSSAs can contain O, O IA, O N2,
O* N2, O N1, and O* N1 routes.
OSPF Router Types
We’ve mentioned the ABR and
ASBR, but there are several other
OSPF router types you must know
and be able to identify by sight.
Commands such as show ip ospf

help us identify ABRs and ASBRs
on a working network, but since you
can’t carry a router into the CCNP
ROUTE exam room, we better
know these router types by sight.
You must be able to look at a
network diagram and determine the
OSPF router type(s) - and notice the
(s). An OSPF router can fill more
than one role. Using our current
OSPF network, let’s take a look at
each OSPF router type.

Internal Routers and Backbone

Routers
These two definitions are simple,
but similar. An OSPF internal
router is a router that has all its
interfaces in a single area. That
area does not have to be Area 0. In
this network, R4 is an internal
router. If we configure a loopback
on R4 and place it in any area other
than Area 4, R4 would no longer be
an internal router.
Backbone routers have at least one
interface in Area 0. That’s the only
requirement. Our OSPF network
contains three backbone routers;

R1, R2, and R3.
It’s important to remember that
routers can fill both of these roles.
Here is an example of a network
where both routers are internal
routers and backbone routers:

Both routers have all their
interfaces in a single area, so
they’re both internal routers. They
also have at least one interface in
Area 0, so they’re both backbone
routers.
Area Border Routers
An ABR is a router that has one
interface in Area 0 and another in a
non-backbone area. In our OSPF
network, R1, R2, and R3 are all
ABRs. All ABRs are backbones,
but not all backbones are ABRs. Be
careful when identifying OSPF
router types!

Autonomous
Routers

System

Border

An ASBR is an OSPF router that
takes routes learned via another
source and places those routes into
the OSPF domain. In our OSPF
network, R1 is an ASBR.
Any route redistribution involving
OSPF must be configured manually.
You can see the ABRs and ASBRs
of any given OSPF area by running
show ip ospf border-routers.
OSPF LSA Types

With all the different OSPF
configurations and area types, it
won’t surprise you to find that there
are different LSA types being sent
around an OSPF network. The
contents of a router’s OSPF
database are displayed with show
ip ospf database and are sorted by
area and LSA type.
The OSPF database contents shown
in this section are from the previous
lab.
R3#show ip ospf database

OSPF LSA Type 1:

These router link advertisements
are generated by each router for
every area the router has a link in.
These are flooded to a single area
only. The name is the recipe - LSA
Type 1s contain the “router link
states” for this particular router.
OSPF LSA Type 2:

Type 2 LSAs are sent out by the DR

only. You can see that the only Type
2 R3 has is from Advertising
Router 1.1.1.1, the OSPF RID of
R1.
Since LSA types 1 and 2 are
confined to a single area, this is
another way in which multiple-area
OSPF helps to reduce the load on
router resources. If you have one
large OSPF area, every router in the
area would receive every single
Type 1 and Type 2 LSA.
OSPF LSA Type 3:

These summary link advertisements
are generated by ABRs and
describe inter-area routes (notice
that none of these links are in Area
0). They summarize the networks
from one area to another. Type 3
LSAs are not flooded into a total
stub area.
OSPF LSA Type 4:

Type 4 LSAs are generated by
ABRs only and describe the path to
the ASBR. Type 4 LSAs are not
flooded into a total stub area.
OSPF LSA Type 5:

Type 5 LSAs describe links
external to the OSPF domain.
Notice that these four links are the
links in the RIP domain and the
advertising router is the ASBR, R1.
A Type 5 LSA is generated by an

ASBR and is flooded to all areas
except stub and total stub areas. If
we look at the entire OSPF
database of R4, which is in a total
stub area, there are no Type 5
LSAs:

This is really a small OSPF
database, but it still allows R4 to
reach every destination in our
OSPF network. Not only does
configuring Area 34 as a total stub

make the OSPF routing table
smaller, it also keeps the database
smaller. That’s another way multiarea OSPF lessens the load on a
router’s memory and CPU.
LSA Type 6s are a “specialty” kind
of LSA that are generated only by
routers using Multicast Extensions
To OSPF (MOSPF). MOSPF isn’t
in widespread use, but it doesn’t
hurt to know about LSA Type 6
while we’re learning all the other
ones!
Type 7 LSAs are generated only by
an ASBR into a not-so-stubby area.

NSSAs act as stub areas, but have
some of the more-specific routes
rather than just a default route.
These Type 7 LSAs are flooded
throughout the NSSA, but don’t
leave that area; they are actually
converted into Type 5 LSAs and are
then sent out of the NSSA.
Here’s a summary of what router
types send the different LSA types:
LSA Type 1: All routers
LSA Type 2: All DRs
LSA Type 3, 4: All ABRs
LSA Type 5, 7: ASBRs only

LSA Type 6: Reserved for
MOSPF
OSPF Route Summarization
It’s a great idea to keep your routing
table complete and concise. OSPF
stub and total stub areas help us do
that by replacing external and interarea routes with default routes, but
it’s not always possible to
configure stub and total stub areas.
Area 0 can never be a stub or total
stub, and if an area is serving as a
transit area for a virtual link, that
area can’t be a stub or total stub.

The routing table can still be made
smaller via route summarization.
In your CCNA studies, you learned
how to summarize routes in RIP and
EIGRP with the interface-level
summary-address command. There
are actually two ways to summarize
routes in OSPF, and the method to
use is dependent on the OSPF
router type in use.
(OSPF does not perform autosummarization when routes are sent
across classful network boundaries,
as RIPv2 and EIGRP do.)
We’ll

now

configure

route

summarization with the area range
command. This is configured only
on an ABR. We’ll use the following
network:

Four loopback addresses have been
added to R1; they have all been
placed into Area 1.

interface Loopback8
ip address 8.1.1.1 255.0.0.0
!
interface Loopback9
ip address 9.1.1.1 255.0.0.0
!
interface Loopback10
ip address 10.1.1.1 255.0.0.0
!
interface Loopback11
ip address 11.1.1.1 255.0.0.0
R1(config)#router ospf 1
R1(config-router)#network
0.255.255.255 area 1
R1(config-router)#network
0.255.255.255 area 1
R1(config-router)#network
0.255.255.255 area 1
R1(config-router)#network
0.255.255.255 area 1

8.0.0.0
9.0.0.0
10.0.0.0
11.0.0.0

All four of the new routes appear
on R2 and R3, as shown here on
R2:
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d01h, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d01h, Serial0
8.0.0.0/32 is subnetted, 1 subnets
O IA
8.1.1.1 [110/65] via 172.12.123.1,
00:02:44, Serial0
9.0.0.0/32 is subnetted, 1 subnets
O IA
9.1.1.1 [110/65] via 172.12.123.1,
00:02:34, Serial0
10.0.0.0/32 is subnetted, 1 subnets
O IA
10.1.1.1 [110/65] via 172.12.123.1,
00:02:34, Serial0
11.0.0.0/32 is subnetted, 1 subnets

O IA
11.1.1.1 [110/65] via 172.12.123.1,
00:02:24, Serial0

R2 and R3 are both adjacent with
R1 through Area 0, so using a stub
or total stub to condense this routing
table is out of the question. Route
summarization will allow us to
replace those four routes with a
single route. First, we have to
convert those four subnets to binary
strings -and for a CCNA and future
CCNP, that is no problem.
8.0.0.0
00001000
00000000 00000000

00000000

9.0.0.0

00000000

00001001

00000000 00000000
10.0.0.0 00001010
00000000 00000000

00000000

11.0.0.0
00001011
00000000 00000000

00000000

To come up with the summary route,
work from left to right and draw a
line where the four addresses no
longer have a bit in common. Here,
that is between the 6th and 7th bit in
the first octet. (The common bits are
highlighted in the above example.)
Then just determine the value of the
bits to the left of that line, with all

bits to the right of the line set to 0:
00001000 00000000 00000000
00000000
Converted back to decimal, that is
8.0.0.0. Since the first six bits were
the same in all four addresses, those
bits will be set to “1” in the
accompanying summary mask, with
all other bits set to “0”:
11111100 00000000 00000000
00000000
The mask is 252.0.0.0.

Now we can apply this summary
route on R1. Using IOS Help, we
see this command can only be used
on area border routers.
I would not depend on the CCNP
ROUTE exam telling you that.

R2 now has a single summary route
in place of the four individual
entries in its routing table, and R2

can still ping all four of the
loopbacks by using that summary
route.
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d02h, Serial0
33.0.0.0/32 is subnetted, 1 subnets
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d01h, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d02h, Serial0
O IA 8.0.0.0/6 [110/65] via 172.12.123.1,
00:00:15, Serial0

R2#ping 8.1.1.1
Sending 5, 100-byte ICMP Echos to 8.1.1.1,

timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/68/68 ms

R2#ping 9.1.1.1
Sending 5, 100-byte ICMP Echos to 9.1.1.1,
timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/69/72 ms

R2#ping 10.1.1.1
Sending 5, 100-byte ICMP Echos to 10.1.1.1,
timeout is 2 seconds:!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/69/72 ms

R2#ping 11.1.1.1

Sending 5, 100-byte ICMP Echos to 11.1.1.1,
timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/68/72 ms

Note that the number between area
and range is the number of the area
containing the routes to be
summarized, not the area to which
the summary is being sent.
The other type of OSPF route
summarization is performed by an
ASBR to summarize routes as
they’re redistributed into OSPF. In
the following network, R5 has four
loopbacks it is advertising via RIP:

4.1.1.1, 5.1.1.1, 6.1.1.1, and
7.1.1.1, all with a 32-bit mask.
Those routes are being redistributed
into the OSPF domain by the
ASBR, R1.

R2 and R3 will see these external
routes as four separate routes.
These routes are being redistributed
into OSPF as E1 routes; remember
that the default is E2. The metrictype 1 option has been configured
with the redistribute rip command
to inject these routes into the OSPF
domain as E1 routes.
R1:
router ospf 1
log-adjacency-changes
area 1 range 8.0.0.0 252.0.0.0
redistribute connected subnets
redistribute rip metric-type 1 subnets

network 1.1.1.1 0.0.0.0 area 1
network 8.0.0.0 0.255.255.255 area 1
network 9.0.0.0 0.255.255.255 area 1
network 10.0.0.0 0.255.255.255 area 1
network 11.0.0.0 0.255.255.255 area 1
network 172.12.123.0 0.0.0.255 area 0
neighbor 172.12.123.2
neighbor 172.12.123.3

R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d02h, Serial0
33.0.0.0/32 is subnetted, 1 subnets
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d01h, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d02h, Serial0
4.0.0.0/32 is subnetted, 1 subnets
O E1
4.1.1.1 [110/84] via

172.12.123.1, 00:06:31, Serial0
5.0.0.0/32 is subnetted, 1 subnets
O E1
5.1.1.1 [110/84] via
172.12.123.1, 00:08:33, Serial0
6.0.0.0/32 is subnetted, 1 subnets
O E1
6.1.1.1 [110/84] via
172.12.123.1, 00:08:33, Serial0
7.0.0.0/32 is subnetted, 1 subnets
O E1
7.1.1.1 [110/84] via
172.12.123.1, 00:08:33, Serial0
15.0.0.0/24 is subnetted, 1 subnets
O E2
15.1.1.0 [110/20] via 172.12.123.1,
00:08:33, Serial0 (The segment connecting
R1 and R5. We left the connected routes at
the default of E2.)
O IA
8.0.0.0/6 [110/65] via 172.12.123.1,
00:16:48, Serial0

Again, the addresses to summarize
will be broken down into binary
strings:

4.0.0.0
00000100
00000000 00000000

00000000

5.0.0.0
00000101
00000000 00000000

00000000

6.0.0.0
00000110
00000000 00000000

00000000

7.0.0.0
00000111
00000000 00000000

00000000

Working from left to right, draw a
line where the four addresses no
longer have a bit in common. In this
example, this occurs between the
sixth and seventh bits, where the top

two addresses have a “0” and the
bottom two have a “1”. Then
determine the value of the resulting
string, setting all bits to the right of
the line to “0”:
00000100 00000000 00000000
00000000
This binary string converts to the
dotted decimal value 4.0.0.0. Since
the first six bits were the same in
all four addresses, those bits will
be set to “1” in the accompanying
summary mask, with all other bits
set to “0”:

11111100 00000000 00000000
00000000
The resulting summary mask is
252.0.0.0. Now we’ve got the
summary address and mask; these
values are applied to the ASBR
with
the
summary-address
command.
R1(config)#router ospf 1
R1(config-router)#summary-address
252.0.0.0

4.0.0.0

R2 and R3 will now have this
summary in their routing table,
rather than the four individual
routes. R2 can ping all four of the

loopbacks on R5.
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d03h, Serial0
33.0.0.0/32 is subnetted, 1 subnets
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d01h, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d03h, Serial0
15.0.0.0/24 is subnetted, 1 subnets
O E2
15.1.1.0 [110/20] via 172.12.123.1,
00:16:07, Serial0
O E1 4.0.0.0/6 [110/84] via 172.12.123.1,
00:00:07, Serial0
O IA 8.0.0.0/6 [110/65] via 172.12.123.1,
00:24:22, Serial0
R2#ping 4.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.1.1.1,
timeout is 2 seconds:!!!!!
R2#ping 5.1.1.1
Sending 5, 100-byte ICMP Echos to 5.1.1.1,
timeout is 2 seconds:!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/69/72 ms
R2#ping 6.1.1.1
Sending 5, 100-byte ICMP Echos to 6.1.1.1,
timeout is 2 seconds:!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/69/72 ms
R2#ping 7.1.1.1
Sending 5, 100-byte ICMP Echos to 7.1.1.1,
timeout is 2 seconds:!!!!!

Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/68/72 ms

When summarizing OSPF routes,
the router will help you out by not
allowing you to misuse the
summary-address and area range
commands. The CCNP ROUTE
exam questions won’t be that kind,
so make sure you know when these
commands can and cannot be used.
summary-address: Use on
ASBR to summarize routes
being redistributed into OSPF.
area range: Use on ABR to

summarize routes advertised
from one area to another. Area
number used in the command
is the area the routes are being
advertised from.
And Don’t Forget…
You’ve got a lot of new and
detailed commands to learn with
OSPF, but don’t forget our old
friend show ip protocols. Here is
the command output on R1:

Information regarding the ACLs
configured on this router, the OSPF
RID, whether the router is an ABR
and/or
ASBR,
redistribution
information, the number of areas,
the current maximum-paths setting

for equal-cost load balancing, the
networks being routed and their
areas, and the sources of routing
information are all found here. Be
very familiar with this command for
the exam and for your job.
Configuring OSPF
Authentication

Neighbor

OSPF
adjacencies
can
be
authenticated using either clear-text
(“simple”) or MD5 (MessageDigest 5). I personally never use
clear-text anything unless an exam
makes me do so, but it’s a great

idea to be familiar with the
commands for both neighbor
authentication methods and to know
how
to
troubleshoot
both
authentication types.
Clear-text password protection for
OSPF adjacencies is configured
with the ip ospf authentication-key
and ip ospf
authentication
commands. These two commands
are very similar, so it’s a good idea
to know exactly how they’re used.
We’ll use them both to authenticate
an adjacency between R1, R2, and
R3 in Area 0. R1 is the hub router

of an OSPF NBMA network running
over a frame relay cloud. R1 has an
adjacency with both R2 and R3, the
spoke routers of this configuration.
The
command
ip
ospf
authentication-key defines the
actual password. Obviously, this
has to be the same on all routers
involved. There’s a classic
“gotcha” with this command that
you should be familiar with. I’ll
configure
a
password
of
ccnptestexam on the serial interface
and then look at the router’s
configuration to make sure I typed it
correctly.

R1(config-if)#ip ospf authentication-key ?
<0-7> Encryption type (0 for not yet
encrypted, 7 for proprietary)
LINE The OSPF password (key)
R1(config-if)#ip
ccnptestexam

ospf

authentication-key

R1#show config
interface Serial0
ip address 172.12.123.1 255.255.255.0
encapsulation frame-relay
ip ospf authentication-key ccnptest

The password was cut off after
eight characters. That’s because this
command has a limit of eight
characters, and for some reason the
IOS doesn’t tell us that when we

enter a longer one! This behavior
changed with IOS 12.4 (the router
now gives a warning regarding
password length), but since there
are routers out there not running
12.4 or later, you should be
prepared to see a password in the
config that may be shorter than the
one you typed in!
Once the password is defined,
clear-text authentication must be
enabled. As always, we can use
IOS Help to see our options… but
there’s no specific listing for cleartext authentication.

R1(config)#int serial0
R1(config-if)#ip ospf authentication ?
message-digest Use message-digest
authentication
null
Use no authentication
<cr>

For clear-text authentication, use
the basic command with no options.
R1(config-if)#ip ospf authentication

We’ll now configure the same
commands on R2 and R3, because
we have to in order to get the
adjacencies to form again! Here are
the messages I received on R1
shortly after configuring that router
for neighbor authentication:

R1#
00:25:38: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.123.2 on Serial0 from FULL to DOWN,
Neighbor Down: Dead timer expired
R1#
00:25:58: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.123.3 on Serial0 from FULL to DOWN,
Neighbor Down: Dead timer expired
R1#

If you remember the dead time for
OSPF NBMA networks, you know
about how long that took! When
OSPF neighbor authentication is
configured on an interface, it must
be configured on all neighbors
reached through that interface or the
adjacencies will drop when the
dead timer expires.

R2(config)#interface serial0
R2(config-if)#ip
ospf
authentication-key
ccnptest
R2(config-if)#ip ospf authentication
R3(config)#interface serial0
R3(config-if)#ip
ospf
authentication-key
ccnptest
R3(config-if)#ip ospf authentication

We go back to R1 to check the
adjacencies just in time to get a
message that the adjacency to R3 is
back up. show ip ospf neighbor
verifies that both adjacencies are
back.
00:31:58: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.123.3 on Serial0 from LOADING to
FULL, Loading Done

MD5 neighbor authentication is
configured with the ip ospf
message-digest-key and ip ospf
authentication
message-digest
commands. Again, the commands
sound a great deal alike, and we
need to know exactly what each
command does. To demonstrate,
we’ll configure MD5 neighbor
authentication over the ethernet
segment connecting R2 and R3.
A good first step is to verify the
adjacency exists before trying to
configure neighbor authentication!

The adjacency to R3 via Ethernet0
is present. We’ll authenticate that
adjacency with the password CCIE.
The ip ospf message-digest-key
command is rather long, so we’ll
use IOS Help to see the options as
we go along.
R2(config)#int e0
R2(config-if)#ip ospf authentication messagedigest R2(config-if)#ip ospf message-digest-key
?
<1-255> Key ID
R2(config-if)#ip ospf message-digest-key 1 ?
md5 Use MD5 algorithm

R2(config-if)#ip ospf message-digest-key 1 md5
?
<0-7> Encryption type (0 for not yet
encrypted, 7 for proprietary)
LINE The OSPF password (key)
R2(config-if)#ip ospf message-digest-key 1 md5
CCIE

Note that you have to specify a key
number, MD5 authentication, and
then finally the password itself!
Since the default dead time of this
link is only 40 seconds, the
adjacency should come down pretty
quickly. By the time I saved this
config and got over to R3, the
adjacency was already gone.

The adjacency will come back
quickly
after
configuring
authentication on R3’s ethernet0
interface.
R3(config)#int e0
R3(config-if)#ip ospf authentication messagedigest
R3(config-if)#ip ospf message-digest-key 1
MD5 CCIE
00:24:09: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.123.2 on Ethernet0 from LOADING to
FULL, Loading Done

And there it is!
Troubleshooting OSPF Neighbor

Authentication
The two main reasons
authentication fails:

OSPF

Authentication is configured
on only one neighbor
Password is misspelled
Luckily, these problems are both
easy to spot with debug ip ospf adj.
“adj” is obviously short for
“adjacency”, but if I had a nickel
for
every time
I entered
“adjacency” with this command…
I’d have a lot of nickels. You have

to use “adj”, because the full word
doesn’t work with this debug!

R3#debug ip ospf adj
OSPF adjacency events debugging is on

For the first debug example, I’ve
removed
message-digest
authentication from R3’s ethernet
interface and replaced it with cleartext authentication. As expected, the
adjacency goes down quickly.
R3(config)#int e0
R3(config-if)#ip ospf authentication

R3(config-if)#
00:52:44: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.23.2 on Ethernet0 from FULL to
DOWN, Neighbor Down: Dead timer expired

But if you didn’t know the reason,
how would you find the reason for
the downed adjacency? By running
debug ip ospf adj.
R3#debug ip ospf adj
OSPF adjacency events debugging is on
R3#
00:54:04: OSPF: Rcv pkt from 172.12.23.2,
Ethernet0 : Mismatch Authentication type. Input
packet specified type 2, we use type 1
R3#undebug all
All possible debugging has been turned off

The debug pays off right away, as
we get a message that there’s a
mismatch in the authentication type.
The incoming Hello is using “type
2” authentication (MD5). Since
R3’s ethernet0 interface is running
“type 1” (clear-text), we have a
mismatch. By changing R3’s type
back to MD5, the adjacency will
form again. And once you see what
the problem is, always turn your
debugs off with undebug all!
R3(config)#interface e0
R3(config-if)#ip ospf authentication messagedigest
R3(config-if)#^Z
R3#

00:56:50: %SYS-5-CONFIG_I: Configured from
console by console
R3#
00:56:54: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.23.2 on Ethernet0 from LOADING to
FULL, Loading Done

If the authentication type matches
but the password does not, the
debug will give a different result.
I’ll remove the initial key from R3’s
E0 interface and replace it with a
different password.
R3(config)#int e0
R3(config-if)#no ip ospf message-digest-key 1
MD5 CCIE
R3(config-if)#ip ospf message-digest-key 1
MD5 CCIEE

00:27:59: %OSPF-5-ADJCHG: Process 1, Nbr
172.12.23.2 on Ethernet0 from FULL to
DOWN, Neighbor Down: Dead timer expired

What does a debug reveal?
R3#
00:28:49: OSPF: Rcv pkt from 172.12.23.2,
Ethernet0 : Mismatch Authentication Key Message Digest Key 1

That’s about as self-explanatory as
a debug gets! Knowing your debugs
truly means the difference between
just “trying something” and knowing
what to do. With OSPF, debug ip
ospf adj is the king of debugs and
the first command to use to

diagnose most OSPF issues.
Default-Information
(Always?)

Originate

This section will be repeated in the
Route Redistribution section, since
we’re redistributing a default route
here - I want you to see it now as
well since it ties in so closely to the
topics in this section.
You know that default routes are
generated in OSPF when stub and
total stub areas are involved.
You also know that you can’t make

Area 0 a stub area.
What we can do is run the OSPF
command
default-information
originate with the always option to
send a default route to all other
OSPF routers -- and that includes
routers in Area 0.
The always option allows the router
to propagate 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. If

there is no default route to
advertise, neighbors will not
receive a default route!
Here, both R2 and R3 will have the
same next-hop address for every
remote destination - R1’s serial0
interface, 172.12.123.1.

That fact would simply scream at us
to configure this as a stub or total
stub area, but there’s just one
problem …
R1(config)#router ospf 1
R1(config-router)#area 0 stub
OSPF: Backbone can not be configured as stub
area
R1(config-router)#area 0 stub ?
no-summary Do not send summary LSA into
stub area
<cr>
R1(config-router)#area 0 stub no-summary
OSPF: Backbone can not be configured as stub
area

…. all three routers are in Area 0,
and we can’t config A0 as any kind

of stub.
We can use the default-information
originate command to send a
default route from R1 to the spoke
routers. Assuming R1 does not have
a default route in its own table,
we’ll need to use the always option.
Here’s what happens if we don’t do
so:
R1(config-router)#default-information ?
originate Distribute a default route
R1(config-router)#default-information originate
?
always
Always advertise default route
metric
OSPF default metric
metric-type OSPF metric type for default

routes
route-map
<cr>

Route-map reference

R1(config-router)#default-information originate
R2#show ip route ospf
R2#

Nothing on R2 or R3. We’ll go back
to R1, remove the first version of
the command, and replace it with
the same command and the always
option.
R1(config-router)#no
default-information
originate
R1(config-router)#default-information originate
always

And now to R2 and R3 ….
R2#show ip route ospf
O*E2 0.0.0.0/0 [110/1]
00:00:10, Serial0

via

172.12.123.1,

R3#show ip route ospf
O*E2 0.0.0.0/0 [110/1]
00:00:15, Serial0

via

172.12.123.1,

Both routers have the route, marked
as both a candidate default route
and an E2 route.
Recommended
From TBA:

YouTube

Videos

OSPF ASBR 3-Minute Boot Camp:

http://www.youtube.com/watch?
v=hGrbyb6p4MI
OSPF ABR 3-Minute Boot Camp:
http://www.youtube.com/watch?
v=cZityXoLmgI
Video Practice Exam: Link State
Protocols
http://www.youtube.com/watch?
v=yTBYdICOHGM
OSPF Over Frame Relay: Practice

Exam and Tutorial:
http://www.youtube.com/watch?
v=VfILkf9s5OE
OSPF Video Practice Exam:
http://www.youtube.com/watch?
v=jQAQFk3Xseo
OSPF Stub Areas and Route
Redistribution Video Boot Camp
http://www.udemy.com/ccnp-routeboot-camp-redistribution-and-ospfstub-areas/

Copyright © 2012 by The Bryant
Advantage. All Rights Reserved.

BGP

Introduction To BGP
BGP is like nothing you’ve studied
to this point. BGP is an external
routing protocol used primarily by
Internet Service Providers (ISPs).
Unless you work for an ISP today or
in the future, you may have little or
no prior exposure to BGP.
Understanding BGP is a great
addition to your skill set – and you
have to know the basics well to

pass the CCNP ROUTE exam.
Note that I said “the basics”. BGP
is a very complex protocol, and
when you pursue your CCIE, you’ll
see what I’m talking about. As with
all things Cisco, though, when
broken down into smaller pieces,
BGP becomes quite understandable.
BGP defined:
An Internet protocol that enables
groups
of
routers
(called
autonomous systems) to share
routing information so that
efficient, loop-free routes can be

established. BGP is commonly
used within and between Internet
Service Providers (ISPs).
There are a couple of terms in there
that apply to the protocols you’ve
mastered so far in your studies. The
term “autonomous system” applies
to EIGRP as well as BGP -- you’ll
be indicating a BGP AS in your
configurations just as you did with
EIGRP.
And just like EIGRP, “autonomous
system” simply refers to a group of
routers that is managed by a single
administrative body.

An AS will use Exterior Gateway
Protocols (EGP) to exchange
updates with other ASes. As you’ll
soon see, BGP is one such EGP!

Interior Gateway Protocols such as
OSPF and EIGRP have their place
as well, and that place is inside an
AS. Routes learned via BGP can be
redistributed into an IGP, and vice
versa - but you have to be extremely
careful in doing so.

Extremely careful. More on that
later.
BGP shares some characteristics
with some routing protocols you’ve
already studied:
BGP supports VLSM and
summarization.
BGP will send full updates
when two routers initially
become neighbors and will
send only partial updates after
that.

BGP does create and maintain
neighbor relationships before
exchanging routes, and
keepalives are sent to keep
this relationship alive.
You’ll hear BGP referred to as a
path-vector protocol. As opposed
to distance-vector protocols that
exchange
relatively
simple
information about available routes,
BGP routers will exchange
extensive
information
about
networks to allow the routers to
make more intelligent routing
decisions.

This
additional
BGP
path
information comes in the form of
attributes, and these path attributes
are contained in the updates sent by
BGP routers. Attributes themselves
are broken up into two classes,
well-known and optional.
BGP also keeps a routing table
separate from the IP routing table.
As with any set of design
requirements,
it’s
almost
impossible to come up with a strict
set of rules as to when to use and
not to use BGP. Having said that,
here are some general Cisco best

practices with BGP.
When Should BGP Be Used?
Some circumstances under which
BGP should be used:
If your company is connecting
to more than one AS or ISP,
decisions on which links to
use can be made by using BGP
path attributes.
If the routing policy of your
organization and your ISP are
different, path attributes can
again be helpful.

If your company is an ISP to
begin with, traffic from other
autonomous systems will use
your AS as a transit domain,
so BGP will be needed.
The first and third reasons listed
are the major reasons organizations
run BGP. In short, if your AS has
more than one connection to other
ASes, or other ASes are using your
AS as a transit area, BGP is
practically a necessity.
When Should BGP Not Be Used?

Some general guidelines on when
not to use BGP:
When there is a single
connection to the Internet or to
another autonomous system.
No redundant link to the
internet is present.
Situations where you don’t
really care which path is used
to reach a route in another AS.
When router resources are a

concern (memory and CPU).
When there is a lowbandwidth connection between
multiple autonomous systems.
In this situation, static and
default routing may be a better
choice if any of these
circumstances exist.
The BGP Peering Process
Like TCP, BGP is connectionoriented (“reliable”). An underlying
connection between two BGP
speakers is established before any

routing information is exchanged.
This connection takes place on TCP
port 179. As with EIGRP and
OSPF, keepalive messages are sent
out by the BGP speakers in order to
keep this relationship alive.
Hint: TCP port 179 is a good port
to leave unblocked by ACLs.
Once the connection is established,
the BGP speakers exchange routes
and synchronize their tables. After
this initial exchange, a BGP speaker
will only send further updates upon
a change in the network topology.

The IGP protocols that use
Autonomous Systems, IGRP and
EIGRP,
require
prospective
neighbors to be in the same AS.
This is not true with BGP. Routers
can be in different Autonomous
Systems and still exchange routes.
A BGP peer that is in the same AS
as the local router is an Internal
BGP (iBGP) peer, where a BGP
peer in another AS is an External
BGP (eBGP) peer. That little “i” or
“e” makes a big difference when it
comes to advertising routes and
other BGP behaviors - so watch that
letter!

A sample iBGP configuration (same
AS):
Router bgp 100
Neighbor 10.1.1.2 remote-as 100

A sample eBGP
(different AS):

configuration

Router bgp 100
Neighbor 10.1.1.2 remote-as 200

Cisco recommends that eBGP peers
be directly connected. iBGP peers
are not required to be directly
connected and generally aren’t.
Before we get too deep into BGP
theory, let’s get a configuration

started. You’ll use the router bgp
command to configure a router as a
BGP speaker. Right after that, the
neighbor command will be used to
identify this BGP speaker’s
potential neighbors.
(The terms “peer” and “neighbor”
are interchangeable in BGP, but it’s
the neighbor statement that is used
to statically define neighbors. BGP
is not capable of discovering
neighbors dynamically.)
Remember what I mentioned about
BGP being a complex protocol?
Take a look at all the possible

options for the neighbor command:
R1(config)#router bgp 100
R1(config-router)#neighbor 172.12.123.3 ?

activate

advertise-map

advertisementinterval

Enabl
Addre
for thi
Neigh
specif
map fo
condit
adver
Minim
interv
sendin
routin
Accep

allowas-in
defaultoriginate
description
disableconnectedcheck

distribute-list

with m
presen
Origin
route
neighb
Neigh
specif
descri
One-h
EBGP
using
addre

Filter
to/from
neighb
Allow

ebgp-multihop

filter-list
local-as
maximumprefix

next-hop-self

neighb
direct
conne
netwo
Establ
filters
Speci
as num
Maxim
numbe
accep
peer

Disab
hop ca
for thi

Propa

next-hopunchanged
password
peer-group
prefix-list
remote-as

removeprivate-AS

iBGP
next h
uncha
this ne
Set a p
Memb
peer-g
Filter
to/from
neighb
Speci
neighb

Remo
AS nu
outbou
update

route-map
routereflector-client
sendcommunity
shutdown
softreconfiguration
timers

Apply
to neig
Config
neighb
Route
client
Send C
attribu
neighb
Admin
shut d
neighb
Per ne
soft
reconf

BGP p

translateupdate

unsuppressmap

update-source
version

neighb
Transl
Updat
MBGP
Route
select
unsup
suppre
routes
Sourc
routin
Set the
versio
a neig

Set de
weigh

weight

routes
neighb

Do not panic! You don’t have to
know every single one of these to
pass the CCNP ROUTE exam. I’m
just showing them to you to
reinforce the fact that BGP is a
whole new world!
And the key to learning what every
one of those commands do?
Mastering one at a time.
Let’s start with the basics and
configure R1 and R3 as eBGP

peers. We’ll place R1 into AS 100
and R3 into AS 200. The routers
are on the 172.12.123.0 /24
network.

R1(config-router)#neighbor 172.12.123.3
% Incomplete command.
R1(config-router)#neighbor
remote-as 200

172.12.123.3

While almost all of the neighbor
options are just that -- optional -you do have to specify the BGP AS
of the remote router. BGP has no
mechanism to dynamically discover
neighbors.
Remember,
BGP
speakers do not have to be in the
same AS to become peers.
To verify that the remote BGP
speaker has become a peer, run
show ip bgp neighbor.
R1#show ip bgp neighbor
BGP neighbor is 172.12.123.3, remote AS
200, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:01:39, hold time is 180,

keepalive interval is 60 seconds
Received 0 messages, 0 notifications, 0 in
queue
Sent 0 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Default minimum time between
advertisement runs is 30 seconds

The output here can be a little
misleading the first time you read it.
The first highlighted line shows
172.12.123.3 is a BGP neighbor, is
located in AS 200, and is an
external link, indicating that the
neighbor is in another AS entirely.
The second highlighted line shows
the BGP state as Active. This
sounds great, but it actually means

that a BGP peer connection does
not yet exist with the prospective
neighbor. Before we continue with
this example, let’s look at the
different BGP states:
Idle is the initial state of a BGP
connection. The BGP speaker is
waiting for a start event, generally
either the establishment of a TCP
connection or the re-establishment
of a previous connection. Once the
connection is established, BGP
moves to the next state.
There’s nothing wrong with this
state, but we don’t want to stay

there. If you note a connection has
gone to idle and stayed there, check
two things:
The IP address in the neighbor
statement (this is usually the
issue).
While we’re at it, make sure
you have a neighbor statement
for that remote router.
Make sure your local router
knows how to get to that same
address.

Connect is the next state. In this
state, a TCP connection request has
been sent but a response has not yet
been received. If the TCP
connection completes, BGP will
move to the OpenSent stage; if the
connection does not complete, BGP
goes to Active.
Active indicates that the BGP
speaker is continuing to create a
peer relationship with the remote
router - basically, this is the
halfway point of the connection.
The local router has successfully
sent a BGP Open packet to the
address in the neighbor statement,

but it hasn’t heard anything back
yet.
As with Idle, there’s nothing wrong
with this state - unless your
connection stays there. If the
connection goes Active and stays
there, it’s really a mirror image of
the Idle issue we spoke of earlier,
so…
Check the remote router’s
neighbor statement
Be sure the remote router
knows how to get the

OpenConfirm packet back to
the local router (OpenConfirm
is BGP’s ACK)
And my personal favorite make sure your AS numbers
are correct, especially if the
connection is flapping between
Idle and Active.
OpenSent indicates that the BGP
speaker has received an Open
message from the peer. BGP will
determine whether the peer is in the
same AS (iBGP) or a different AS

(eBGP) in this state.
In OpenConfirm state, the BGP
speaker is waiting for a keepalive
message. If one is received, the
state moves to Established, and the
neighbor relationship is complete. It
is in the Established state that
update packets are actually
exchanged.
So even though the show ip bgp
neighbor output indicated that this
is an Active neighbor relationship,
that’s not as good as it sounds. Of
course, the reason the peer
relationship hasn’t been established

is that we haven’t configured R3
yet!
R3(config)#router bgp 200
R3(config-router)#neighbor
remote-as 100

172.12.123.1

Verify the peer establishment with
show ip bgp neighbor:
R3#show ip bgp neighbor
BGP neighbor is 172.12.123.1, remote AS
BGP version 4, remote router ID 172.12
BGP state = Established, up for
00:01:18
Last read 00:00:17, hold time is 180,
keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old
& new)
Address family IPv4 Unicast: advertised

and received
Received 5 messages, 0 notifications, 0 in
queue
Sent 5 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Default minimum time between
advertisement runs is 30 seconds
Local host: 172.12.123.3, Local port: 179

(BGP uses TCP Port 179)
Foreign host: 172.12.123.1, Foreign port: 110077

The peer relationship between R1
and R3
Another handy command to view
BGP peer information is show ip
bgp summary. While most of the
information in this command deals
with the local router, a BGP peer

summary table is shown at the very
end of the command output. If you
just want to see if peer
relationships are in place and how
long they’ve been up, I find this
command to be more helpful than
the show ip bgp neighbor
command.
R1#show ip bgp summary
BGP router identifier 172.12.123.1, local AS
number 100
BGP table version is 2, main routing table
version 2
1 network entries and 1 paths using 133 bytes of
memory
1 BGP path attribute entries using 60 bytes of
memory
1 BGP AS-PATH entries using 24 bytes of
memory

0 BGP route-map cache entries using 0 bytes of
memory
0 BGP filter-list cache entries using 0 bytes of
memory
BGP activity 1/1 prefixes, 1/0 paths, scan
interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ
OutQ Up/Down State/PfxRcd
172.12.123.2 4 100 83 84 2 0 0 01:19:03 0
172.12.123.3 4 200 104 103 2 0 0 01:39:24 1

BGP peers do not have to be in the
same AS, and whether they are in
the same or a different AS
determines whether they become
iBGP or eBGP peers.
That may not sound like a big deal,
but it is.

In the following configuration, R1
has two peers, one sharing AS 100
and the other in AS 200. (Also note
what happens if you use the local
router’s own IP address as a BGP
peer address!)

R1(config)#router bgp 100
R1(config-router)#neighbor
172.12.123.3
remote-as 200
R1(config-router)#neighbor
172.12.123.1
remote-as 100
% Cannot configure the local system as
neighbor
R1(config-router)#neighbor
172.12.123.2
remote-as 100

R1#show ip bgp neighbor
BGP neighbor is 172.12.123.2, remote AS 100,
internal link
BGP version 4, remote router ID
172.12.123.2
BGP neighbor is 172.12.123.3, remote AS 200,
external link
BGP version 4, remote router ID
172.12.123.3

Using Loopback Addresses To
Create eBGP Adjacencies
When you were introduced to
loopback interfaces in your CCNA
studies, your first question was
likely “Why do we create imaginary
interfaces on Cisco routers?”

The frustrating thing for both
teacher and student in the CCNA is
that you’re shown how to create
those interfaces, but not really given
many reasons why. Here’s one
excellent reason why - and a classic
BGP “gotcha” you must be aware
of.
Using loopback addresses for BGP
adjacencies allows us to keep those
adjacencies even if physical
interfaces go down for any reason.
Sounds good, right? Now here’s
that “gotcha”:

Loopback interfaces are not
considered directly connected
even if they share a common
subnet.
The ebgp-multihop command is
necessary to configure eBGP
peering relationships where the
addresses used to form the
adjacency are not on the same
segment. You’ll also need the
update-source loopback command
when loopbacks are used to create
eBGP adjacencies.
Static routes can also play a role in

eBGP adjacencies. If you use
loopback addresses for eBGP
adjacencies, you may also need to
configure a static route on each
router that points to the remote
router’s loopback. After all, for this
config to work, the router needs to
know how to get to the address used
in the neighbor command.
Let’s drive all of these concepts
home by creating an adjacency
between R1 and R3 using their
respective loopback addresses as
shown in the following config.

R1(config)#int loopback1
R1(config-if)#ip
address
1.1.1.1
255.255.255.255
R1(config-if)#router bgp 100
R1(config-router)#no auto
R1(config-router)#no synch
R1(config-router)#neighbor 3.3.3.3 remote-as
200
R1(config-router)#neighbor
3.3.3.3
ebgpmultihop 2
R1(config-router)#neighbor 3.3.3.3 updatesource loopback1
R3(config)#int loopback1
R3(config-if)#ip
address
255.255.255.255

3.3.3.3

R3(config-if)#router bgp 200
R3(config-router)#no auto R3(config-router)#no
synch
R3(config-router)#neighbor 1.1.1.1 remote-as
100
R3(config-router)#neighbor
1.1.1.1
ebgpmultihop 2
R3(config-router)#neighbor 1.1.1.1 updatesource loopback1

The neighbor statements look good,
the ebgp-multihop command is in
place, and the update-source
command is as well. But is the
adjacency in place?

Both routers show an adjacency
state of Active, and we could wait a
long, long time and they’d still be
shown as Active. Just as with
EIGRP, Active is not good when it
lasts.
The issue is that neither router has a
route to the loopback address the
remote router is using to form the
adjacency.

Or in this case, not forming it.
By configuring static routes on each
router that point to the remote
router’s loopback address, the BGP
adjacency will form. We’ll use two
host static routes here to get the job
done.
R3(config)#ip route 1.1.1.1 255.255.255.255
serial1
R1(config)#ip route 3.3.3.3 255.255.255.255
serial1

The adjacencies come up just a few
seconds after these static routes are
configured. Note that though the

desired state of each neighbor
relationship is Established, that
word doesn’t actually appear where
we saw Active just a few minutes
ago - at the utmost right of the show
ip bgp summary output.

No route to the address in the
neighbor statement = no neighbor!
If the address is on a directly
connected subnet, that works, and

we can get the route from an IGP but don’t forget about a simple
default route.
Naturally, those static routes have
to stay there; if they’re removed,
the adjacencies will time out. To
demonstrate, I removed the static
route from R3:
R3(config)#no ip route 1.1.1.1 255.255.255.255
serial1

A few minutes later, the result is a
lost adjacency.
R3#
00:22:24: %BGP-5-ADJCHANGE: neighbor

1.1.1.1 Down BGP Notification sent
R3#
00:22:24: %BGP-3-NOTIFICATION: sent to
neighbor 1.1.1.1 4/0 (hold time expired)0 bytes

In short, there are three main
reasons why BGP peerings fail to
form or are torn down after they’re
built.
The AS number is incorrectly
identified in the config. If you
do this, trust me, you’re not the
first and you won’t be the last!
:)
A peering has been configured

for an eBGP router that is not
directly connected, and the
ebgp-multihop option has
been omitted.
An ACL is blocking TCP port
179. Opening that port right
back up will allow the
adjacencies to reform, but you
will have some anxious
moments in the meantime!

Advertising Routes In BGP
We use the network command in

BGP, but not quite the same way we
did with RIP, EIGRP, and OSPF. It
will look the same, but the BGP
network command identifies the
networks that will be advertised by
BGP, where the network command
with IGPs identifies the interfaces
that will be enabled with that
protocol.
The network specified in the BGP
network command must be an exact
match for a network contained in
the IP routing table, and that
includes the mask.
A real-world note here (and it

couldn’t hurt on the exam) -- using
the mask in the network statement is
not required, but I highly
recommend you use it. If you’re
called on to troubleshoot a BGP
configuration and it’s missing the
masks on the network statements,
that could well be the issue. Use the
masks or you’ll end up only with
the classful networks.

Here, we’ll advertise R3’s
loopback (3.3.3.3 /32) in BGP.
R3(config)#router bgp 200
R3(config-router)#network
255.255.255.255

3.3.3.3

mask

R1 quickly sees the route:

For the route to be usable, you must
see that asterisk. The best route is
indicated with a combination of an
asterisk and the “>” symbol -- that
means “valid and best”.

Let’s use another network to
illustrate what happens if the mask
is just a bit off…
R3(config)#int loopback33
R3(config-if)#ip
address
255.255.255.0

33.33.33.33

R3(config)#router bgp 200
R3(config-router)#network 33.33.33.33 mask
255.255.255.255

Does R1 see the route?

Nope! Due to the mismatched mask,
R3 doesn’t even see the route in its

own BGP table!

The BGP network mask must match
the IP routing table’s mask exactly
in order for the route to be
successfully advertised via BGP.
The loopback was configured with
a /24 mask, but the BGP network
command specified a /32 mask.
Here’s how the route looks in the IP
routing table:
33.0.0.0/24 is subnetted, 1 subnets
C
33.33.33.0 is directly connected,
Loopback33

Once we change the BGP network
statement to reflect a /24 mask, the
route will appear in R3’s BGP table
and be successfully advertised to
R1 via BGP. We’ll first remove the
erroneous network statement and
then enter the correct one.
R3(config)#router bgp 200
R3(config-router)#no network 33.33.33.33 mask
255.255.255.255
R3(config-router)#network 33.33.33.0 mask
255.255.255.0

All is well!
BGP Path Attributes
There are two classes of BGP Path
Attributes,
well-known
and
optional. To truly understand BGP,
you need to know exactly what
these attributes are and how they
affect BGP.

You must master the application and
use of these attributes to pass the
CCNP ROUTE exam.
Using the network we’ve built to
this point, we will now examine
these attributes, how to view them,
and their impact on BGP path
selection.
Here are the two categories of
well-known
attributes,
both
mandatory and discretionary:
Well-known mandatory:
AS_PATH, origin, next-hop

Well-known discretionary:
local preference, atomic
aggregate
There are also optional attributes,
both transitive and non-transitive.
Optional transitive:
aggregator, community
Optional non-transitive: MED
(multi-exit discriminator)
Those three mandatory attributes –
AS_PATH, origin, and next-hop –

will appear in all BGP update
messages sent to neighbors. These
are the only three attributes that all
BGP speakers must understand.
The optional attributes can be a bit
of a pain for BGP operation, since
not every BGP speaker is going to
understand all optional attributes.
The difference between “optional
transitive” and “optional nontransitive” comes into play here.
A BGP path carrying an
unrecognized transitive optional
attribute will be accepted; if this
path is advertised to other routers,

the Partial bit will be set and the
attribute
advertised
to
the
neighboring router.
Basically, marking an attribute as
partial is the equivalent of the
advertising router saying “I didn’t
understand this attribute, but here is
it anyway.”
An unrecognized non-transitive
optional attribute will not be
passed on to other BGP speakers.
The Origin Attribute
The source of the routing update

itself can be viewed with show ip
bgp.

There are three possibilities for the
Origin code:
“i” -- path originated from an IGP
via the network command
“e” -- path originated from an
Exterior Gateway Protocol (EGP)
“?” -- Actual origin unclear;
learned via route redistribution.

Those are shown in order of most
preferred to least preferred, from
top to bottom.
The AS_PATH Attribute
This
attribute
shows
the
autonomous systems along the path
to
the
destination network,
including the AS the destination
network resides in. The shortest AS
path is the preferred path.
The AS_PATH attribute helps to
prevent routing loops; if a router
receives an update and sees its own
AS number in the path to a

destination, that route will be
discarded.
In this example, the only AS shown
in the path is the AS the network
resides in, AS 200.

To see a longer AS_PATH attribute,
we’ll add a few extra routers and
some
additional
autonomous
systems. Every router will be
advertising its loopback address
into BGP, and every router’s
loopback is its own number in each

octet (R1’s loopback is 1.1.1.1,
etc.) Just for fun, we’ll build some
multiple BGP peerings between two
routers; in production networks, we
most likely would not do that.

The BGP configurations of the
routers:
R1(config)#router bgp 100
R1(config-router)#neighbor 10.1.1.5 remote-as

500
R1(config-router)#neighbor
remote-as 100
R1(config-router)#neighbor
remote-as 300
R1(config-router)#network
255.255.255.255
R2(config)#router bgp 100
R2(config-router)#neighbor
remote-as 100
R2(config-router)#neighbor
remote-as 300
R2(config-router)#neighbor
remote-as 300
R2(config-router)#neighbor
remote-as 400
R2(config-router)#network
255.255.255.255
R3(config)#router bgp 300

172.12.123.2
172.12.123.3
1.1.1.1

mask

172.12.123.1

172.12.123.3
172.12.234.3
172.12.234.4
2.2.2.2

mask

R3(config-router)#neighbor
172.12.123.1
remote-as 100
R3(config-router)#neighbor
172.12.123.2
remote-as 100
R3(config-router)#neighbor
172.12.234.2
remote-as 100
R3(config-router)#neighbor
172.12.234.4
remote-as 400
R3(config-router)#neighbor 172.12.34.4 remoteas 400
R3(config-router)#network
3.3.3.3
mask
255.255.255.255
R4(config)#router bgp 400
R4(config-router)#neighbor
172.12.234.3
remote-as 300
R4(config-router)#neighbor
172.12.234.2
remote-as 100
R4(config-router)#neighbor 172.12.34.3 remoteas 300
R4(config-router)#network
4.4.4.4
mask
255.255.255.255

R5(config)#router bgp 500
R5(config-router)#neighbor 10.1.1.1 remote-as
100
R5(config-router)#network
5.5.5.5
mask
255.255.255.255

Here are the peerings:
R1: eBGP to R5, iBGP to R2,
eBGP to R3.
R2: eBGP to R4, eBGP to R3,
iBGP to R1
R3: eBGP to R1, eBGP to R2
via the Serial network, eBGP
to R2 via the Ethernet segment,

eBGP to R4 via the Ethernet
segment, eBGP to R4 via the
Serial interface
R4: eBGP to R3 via the
Ethernet segment, eBGP to R3
via the Serial connection,
eBGP to R2 via the Ethernet
segment.
R5: eBGP to R1 via the
Ethernet segment.
R1’s BGP table has at least one
entry for every loopback in the
network, and multiple paths for

most of them.

The “>” symbol indicates the best
path, and therefore the path that will
be used. From top to bottom, here’s
how BGP selects a best path
between multiple valid paths:
Highest weight (Ciscoproprietary attribute)
Highest local preference (1st

if non-Cisco routers are
involved)
Locally originated path
preferred
Shortest AS_PATH
Best origin code ( i, then e,
then ?)
Lowest MED

eBGP over iBGP path
lowest IGP metric to BGP
next-hop
oldest path
path from BGP router with
lowest BGP RID
You really need to know this order
to master BGP for the workplace
and for your CCNP ROUTE and
CCIE exams.

Let’s look at the BGP table from R1
again.

Again, the “>” indicates the path
that will be used to reach that
particular network. For more
detailed information on any
particular path, use the show ip bgp
command
followed
by
the
destination.
Before we use that command,
though, did you notice that there

seems to be something odd with
R1’s path selection for the network
3.3.3.3 and 4.4.4.4? Let’s take a
look at the paths to 3.3.3.3 first.

BGP has identified both paths as
being valid and loop-free, as
indicated by the asterisk. The “>”
indicating the best path is next to the
path with the next-hop of
172.12.123.3. The first criteria for
BGP best path selection is weight,
and both paths have a weight of 0.
The next criteria is local
preference. If the path with the next-

hop of 172.12.234.3 has a local
preference of 100, and the other
path a local preference of zero, why
is the path with the lowest local
preference being selected by BGP?
Before we answer that, let’s look at
R1’s paths for 4.4.4.4:

There are two valid loop-free paths
to 4.4.4.4, so BGP must choose the
best path. The weights are the same,
but again the local preferences
seem to favor the next-hop of
172.12.234.4. Even if the local
prefs were the same, the AS_PATH

of the path with the next-hop of
172.12.234.4 is shorter than the
other path. Then why is the path
with the next-hop of 172.12.123.3
being selected?
Learn the following command – it
will serve you well in the exam
room and on the job!
R1#show ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 3
Paths: (2 available, best #1, table Default-IPRouting-Table)
Advertised to non peer-group peers:
10.1.1.5 172.12.123.2
300
172.12.123.3 from 172.12.123.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid,
external, best

300
172.12.234.3 (inaccessible) from
172.12.123.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid,
internal
R1#show ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 7
Paths: (2 available, best #1, table Default-IPRouting-Table)
Advertised to non peer-group peers:
10.1.1.5 172.12.123.2
300 400
172.12.123.3 from 172.12.123.3 (3.3.3.3)
Origin IGP, localpref 100, valid, external,
best
400
172.12.234.4 (inaccessible) from
172.12.123.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid,
internal

The
show
ip
bgp
<network_number>
command
shows us that the paths with a nexthop IP address on the 172.12.234.0
network are shown as valid, and all
paths involved have a local pref of
100.
Never trust the local prefs you see
in the basic show ip bgp command
if something looks strange – run this
more network-specific version of
the command.
Two of the routes can’t be used,
though, because R1 has no IP
connectivity to any host on the

172.12.234.0 segment.
R1#ping 172.12.234.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
172.12.234.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

to

R1#ping 172.12.234.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos
172.12.234.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

to

If a router cannot reach the address
listed as the BGP next-hop, the path

cannot be used.
To get around this rule, we can use
the bgp next-hop-self command on
R2. This will force R2 to announce
itself as the next hop of all paths
advertised
to
the
specified
neighbor, in this case R1.
R2(config)#router bgp 100
R2(config-router)#neighbor 172.12.123.1 nexthop-self

R1’s BGP table now shows
172.12.123.2 as the next hop for all
paths
that
formerly
had
172.12.234.3 or .4 for that value.

Since R1 can reach 172.12.123.2,
these paths can now be used by
BGP. The route to 4.4.4.4 now has a
next-hop of 172.12.123.2.
The best route to 3.3.3.3 still has a
next-hop of 172.12.123.3, but the
next-hop address for the other route
to 3.3.3.3 is now 172.12.123.2.
Note in the show ip bgp x.x.x.x
command output below that there is
no inaccessible comment and the
next-hop IP addresses have changed
there as well.

R1#show ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 3
Paths: (2 available, best #1, table Default-IPRouting-Table)
Advertised to non peer-group peers:
10.1.1.5 172.12.123.2
300
172.12.123.3 from 172.12.123.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid,
external, best
300
172.12.123.2 from 172.12.123.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid,
internal
R1#show ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 8

Paths: (2 available, best #2, table Default-IPRouting-Table)
Advertised to non peer-group peers:
10.1.1.5 172.12.123.3
300 400
172.12.123.3 from 172.12.123.3 (3.3.3.3)
Origin IGP, localpref 100, valid, external
400
172.12.123.2 from 172.12.123.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid,
internal, best

For the network 4.4.4.4, the path
now in use is the one with the next
hop of 172.12.123.2, since its
AS_PATH is shorter than the other
valid path. The path for the
destination 3.3.3.3 is still the path
with the next hop of 172.12.123.3.

Since the weights and local prefs
are the same, none of the routes
originated on R1, the AS_PATH
length is the same, the origin code
is the same (IGP), and the MED is
the same, the next criteria in line is
eBGP routes being used over iBGP
routes. The path with the next hop
of 172.12.123.3 is an eBGP route
where the path with the next hop of
172.12.123.2 is an iBGP route.
I know that list of BGP best-path
selection criteria is long, but
sometimes it really does come
down to the eighth or ninth
tiebreaker. It’s important to know

this list for any real-world job
involving BGP - but it won’t hurt on
exam day, either.
The Next-Hop Attribute
We just spent quite a bit of time
examining this attribute, but let’s
look at the rules for determining the
default next-hop.
When a BGP speaker sends a route
to an eBGP neighbor, the next-hop
address is set to the transmitting
interface of the router that
originated the route. In this
example, with R3 advertising its

loopback address to its eBGP
neighbor R1, the next-hop will be
the IP address of R3’s serial
interface.

Makes sense, right? Right!
Now here’s the interesting part….
Regarding iBGP routes, for routes
originated outside the AS, the next-

hop address will still be the source
address of the router in the remote
AS that originally sent the route
advertisement.
When the BGP route arrives at R2,
the next-hop address is still that of
R3 -- and when there’s no full mesh
involved, that can lead to trouble.
If R2 does not have an entry in its
routing table for the R1-R3 serial
network, R1 should announce itself
to R2 as the BGP next hop.
Otherwise, as you saw in the
previous example, the route won’t
be entered into the BGP table.

The Multi-Exit
(MED)

Discriminator

The MED is an optional attribute
that comes in handy when there are
multiple entrance paths to an AS.
The remote AS sets MED values to
tell the other AS which path to use.

The MED is passed between the
two autonomous systems, but the
value is not passed to any other
ASes. The path with the lowest
MED is the preferred path.
Here, R3 has two possible entry
points into AS 100, and therefore
two paths to R4. For varying
reasons (one of the paths has
greater bandwidth available, one of
the paths involves a particularly
slow or fast router), you may want
to influence R3’s path selection
from R1 and R2.
By sending a MED of 100 from R2

and a MED of 200 from R1, you are
actually telling R3 that the path into
AS 100 via R2 is more desirable
than the path via R1.
When you write route-maps to set
the MED, there is no “set MED”
option. Instead, you are setting the
metric value.
R1(config)#route-map SET_MED permit 10
R1(config-route-map)#match ip address 1
R1(config-route-map)#set metric 200

To change the MED for all routes
sent by that router, use the defaultmetric command in the BGP config.

R1(config)#router bgp 100
R1(config-router)#?
Router configuration commands:
address-family
Enter Address Family
command mode
aggregate-address Configure BGP
aggregate entries
auto-summary
Enable automatic
network number summarizati
bgp
BGP specific
commands
default
Set a command to its
defaults
default-information Control distribution of
default information
default-metric
Set metric of
redistributed routes

To enable the comparison of the
MEDs of routes received from

multiple autonomous systems, use
the
bgp always-compare-med
command.
R3(config)#router bgp 200
R3(config-router)#bgp ?
always-compare-med
Allow comparing
MED from different neighbors

The Local Preference Attribute
(LOCAL_PREF)
LOCAL_PREF is a well-known
attribute that is also used when
multiple paths between autonomous
systems exist. The LOCAL_PREF
attribute is just that… local.

Routers within the local AS are told
what path to use to exit that AS.
The local preference value is
passed only among iBGP peers, and
this value never leaves the local
AS. In the following network, there
are two exit paths for routers in AS
100 to reach AS 200. The
LOCAL_PREF attribute will be set
in AS 100, and it will not leave that
AS. The LOCAL_PREF attribute
indicates to the routers in AS 100
what path should be taken to AS
200. The path with the highest
LOCAL_PREF is chosen.

Changing The Local Preference
Attribute

Both R1 and R2 have two paths to
the
172.12.34.0/24
network.
Examining their BGP tables reveals
that R1 will use R3 as a next-hop to
reach this network, and R2 will use
R4 to reach it.

If we wanted R2 to use R3 as a
next-hop instead, the most efficient
way to do so is to change the local
preference value, shown as
“LocPrf” in the BGP table.
When the local preference of a path
is changed, all routers in the AS
will learn about it. Always run
show ip bgp followed by the
network number when you want to
examine local preferences:

R2#show ip bgp 172.12.34.0
BGP routing table entry for 172.12.34.0/24,
version 4
Paths: (2 available, best #1, table Default-IPRouting-Table)
Advertised to non peer-group peers:
10.1.1.1
34
10.1.1.4 from 10.1.1.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100,
valid, external, best
34
10.1.1.3 from 10.1.1.1 (172.12.123.1)
Origin IGP, metric 0, localpref 100,
valid, internal

Since both routes have a local
preference of 100, the local
preference for the path with the
next-hop of 10.1.1.3 will have to be

changed to a higher value. There
are two approaches for this.
The first is to change the default
local preference for a router as a
whole, which means that every
update the router sends out to other
devices in the same AS will carry
this new local preference value.
Here, we’ll double the default local
preference on R1.
R1(config)#router bgp 12
R1(config-router)#bgp default ?
ipv4-unicast
Activate ipv4-unicast for a
peer by default
local-preference local preference
(higher=more preferred)
route-target
Control behavior based on

Route-Target attributes
R1(config-router)#bgp default local-preference
200

Keep using IOS Help, you never
know what you may learn! The
router is even reminding us that a
higher
local
preference
is
preferred. (I wouldn’t expect the
exam to remind you, though.)
Let’s take a look at R2’s BGP table
now:

Now the path with the next-hop of
10.1.1.3 is preferred, due to the
higher local preference.
R2#show ip bgp 172.12.34.0
BGP routing table entry for 172.12.34.0/24,
version 5
Paths: (2 available, best #1, table Default-IPRouting-Table)
Advertised to non peer-group peers:
10.1.1.4
34
10.1.1.3 from 10.1.1.1 (172.12.123.1)
Origin IGP, metric 0, localpref 200,
valid, internal, best
34
10.1.1.4 from 10.1.1.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100,
valid, external

You can also assign new local

preferences to individual prefixes
with a route map. Route maps
allow you to change attribute
values, or assign attributes in the
first place, on a route-by-route
basis rather than the “all-ornothing” approach other methods
offer.
For the CCNP ROUTE exam and
especially for real-world BGP
routers that can contain hundreds of
routes,
I’d
become
very
comfortable with route maps.
We will now remove the bgp
default local-preference command

from R1, and add another segment
connecting R3 and R4. This
segment, 210.1.1.0 /24, will also be
advertised into BGP on R3 and R4.

R1(config)#router bgp 12
R1(config-router)#no bgp
preference 200

default

local-

R3(config)#router bgp 34
R3(config-router)#network
255.255.255.0

210.1.1.0

mask

R4(config)#router bgp 34
R4(config-router)#network
255.255.255.0

210.1.1.0

mask

Let’s take a look at the BGP tables
of R1 and R2 and see what next-hop
address each router is preferring for
each of our two BGP paths.

If we use the bgp default localpreference command here, it will
affect both paths. What if we
needed R2 to use 10.1.1.3 as the
next hop for data traveling to
172.12.34.0/24, but to continue
using 10.1.1.4 as the next hop for
210.1.1.0/24?
You see the weakness of the
“default” approach. Setting a
default local preference somewhere
in AS 12 won’t give us what we
need, but configuring a route map
will.
The prefixes that need the higher

local preference first need to be
identified by an access-list. I know
you know this – but don’t forget
that access lists use wildcard
masks!
R1(config)#access-list 18 permit 172.12.34.0
0.0.0.255

This ACL will match only this
particular prefix, with all others
being denied by the implicit deny.
We’re not denying traffic with this
config, though - we’re identifying
traffic that should have its local
preference doubled.
The following route map will

assign a local preference of 200 to
all routes matching access-list 18,
with all other routes unaffected.
R1(config)#route-map PREFER_R3_FOR_172
permit 10
R1(config-route-map)#match ip address 18
R1(config-route-map)#set local-pref 200
R1(config-route-map)#route-map
PREFER_R3_FOR_172 permit 20
R1(config-route-map)#set local-pref 100

The route map will be applied to
all routes coming in from R3 via the
neighbor command.
The word “in” at the end of the
command indicates the direction of
the updates that will be affected by

the route map.
R1(config)#router bgp 12
R1(config-router)#neighbor 10.1.1.3 route-map
PREFER_R3_FOR_172 ?
in Apply map to incoming routes
out Apply map to outbound routes
R1(config-router)#neighbor 10.1.1.3 route-map
PREFER_R3_FOR_172 in

After
clearing
R1’s
TCP
connections, R2 now has this BGP
table:

R2 still uses the next hop 10.1.1.4
to reach 210.1.1.0/24, but now uses

10.1.1.3 for the next hop to reach
172.12.34.0/24 due to the higher
local preference.
IOS Help shows us that route maps
can be used to set almost any BGP
attribute:
R1(config-route-map)#set ?

as-path

automatic-tag

Prepend
string fo
BGP AS
attribute
Automa
comput
value
set BGP

comm-list

community

dampening

default

extcommunity

commun
list (for
deletion
BGP
commun
attribute
Set BG
route fl
dampen
parame
Set defa
informa
BGP
extende
commun
attribute
Output

interface
ip
level
localpreference

metric

metric-type

interfac

IP spec
informa
Where
import
BGP lo
prefere
path att
Metric
for
destinat
routing
protoco
Type of
metric f
destinat

origin

tag

weight

routing
protoco
BGP or
code
Tag val
destinat
routing
protoco
BGP w
for rout
table

Whatever value you need to change
in BGP, a route map is most likely
the best way to do it, both on the
exam and in real life.

Third-Party Next-Hop
On occasion, you may see a nexthop address that you don’t expect,
particularly in a situation like the
next diagram.

R1, R2, and R3 share a broadcast
segment. R1 has an eBGP peering
with R2, and R2 has an iBGP
peering with R3. (Always doublecheck your network documentation
or exam exhibit; never assume a full
mesh.)
R3 will advertise its loopback
network, 3.3.3.3/32, to R2 via
iBGP. R2 will then advertise the
route to R1.
R1:
router bgp 1500
neighbor 100.1.1.2 remote-as 2000
interface Ethernet0
ip address 100.1.1.1 255.255.255.0

R2:
router bgp 2000
neighbor 100.1.1.1 remote-as 1500
neighbor 100.1.1.3 remote-as 2000
interface Ethernet0
ip address 100.1.1.2 255.255.255.0
R3:
router bgp 2000
network 3.3.3.3 mask 255.255.255.255
neighbor 100.1.1.2 remote-as 2000
interface Ethernet0
ip address 100.1.1.3 255.255.255.0

As expected, R2’s BGP table shows

100.1.1.3 as the next-hop address to
reach 3.3.3.3 /32.

There is no peering between R1 and
R3, but R1 should get this route
from R2. Since this is an eBGP
peering, the route is expected to
have a next-hop address of
100.1.1.2….. right?

Wrong! :)

The next-hop is 100.1.1.3. This is
due to third-party next-hop, and
outside of RFCs, you don’t hear
much about this rule. A BGP
speaker is allowed to advertise the
IP address of an internal peer as the
next-hop address IF the external
peer receiving the route has a
subnet in common with the internal
peer.
Howzat for an “if”?
Since R1 and R3 share a subnet, R2
is allowed to send the IP address of
the internal peer, 100.1.1.3, as the
next-hop address.

This built-in feature is designed to
bring about the most accurate
routing possible, and in this
example it does just that. R2 is
advertising the route to an external
peer, but R2 also knows that the
external peer (R1) shares a subnet
with the internal peer (R3). R2 then
advertises the route with a next-hop
of 100.1.1.3, resulting in R1 having
the most direct path to 3.3.3.3/32.
The Weight Attribute
Weight is the first value considered
in BGP path selection among
multiple paths.

There are three other major points
to remember about this BGP
attribute:
Cisco-proprietary value
locally significant to a router
is never advertised to other
routers
The path with the largest weight is
preferred. The default weight for a
route originated on the local router
is 32768, and it’s zero for all other

routes.
Adjusting The Weight Attribute
The
R1-R2-R3
network
is
172.12.123.0 /24, and the R2-R3R4 segment is 10.1.1.0 /24. All
final octets are the router’s number.
There is no iBGP peering between
R2 and R3. R4 is advertising its
loopback address of 4.4.4.4/32 into
BGP.
All peerings, both iBGP and eBGP,
are shown with dotted lines.

R1(config)#router bgp 123
R1(config-router)#neighbor
remote-as 123
R1(config-router)#neighbor
remote-as 123

172.12.123.2
172.12.123.3

R2(config)#router bgp 123
R2(config-router)#neighbor
172.12.123.1
remote-as 123
R2(config-router)#neighbor 10.1.1.4 remote-as
4
R2(config-router)#neighbor 172.12.123.1 next-

hop-self
R3(config)#router bgp 123
R3(config-router)#neighbor
172.12.123.1
remote-as 123
R3(config-router)#neighbor 10.1.1.4 remote-as
4
R3(config-router)#neighbor 172.12.123.1 nexthop-self
R4(config)#router bgp 4
R4(config-router)#neighbor 10.1.1.2 remote-as
123
R4(config-router)#neighbor 10.1.1.3 remote-as
123
R4(config-router)#network
4.4.4.4
mask
255.255.255.255

R1 has two paths to 4.4.4.4/32. The
path with the next hop 172.12.123.2

is in use, as indicated by the “>”
symbol indicating the best route.

That particular path was chosen by
the BGP route selection process,
and just to review, here’s that
process again:
Highest weight
Highest local pref
Locally originated path (next

hop of 0.0.0.0 in show ip bgp)
Shortest AS_PATH
Lowest origin code ( i, e, ?)
Lowest MED (if remote AS is
same for all routes)
External BGP over Internal
BGP
Lowest IGP metric to next-hop

address
Oldest route
Lowest BGP RID
Lowest neighbor IP address (if
there’s a tie here, you have a
problem!)
We went all the way down to the
final tiebreaker in this scenario,
because all of the preceding criteria
were the same. If you’re in an all-

Cisco environment, it makes sense
to change the weight of a route to
make it the preferred route, since
that is the first criteria checked.
The weight for both routes is 0, so
we’ll use the neighbor command to
set the weight for all routes learned
from 172.12.123.3 to 200.

The weight for the route with a
next-hop of 172.12.123.3 is now
200, making it the preferred path.

The weight attribute is Ciscoproprietary, so in a multi-vendor
environment we’d change the local
pref to get a similar result.
This change to a route’s weight is
locally significant only -- R1 will
not advertise this route with a
weight of 200.
The Atomic Aggregate Attribute
You should get 20 exam points just
for saying that fast.
But you won’t, so let’s take a quick
look…

When BGP paths are aggregated,
this well-known attribute indicates
the router that performed the
aggregation. This attribute gives
notice to downstream routers that
more-specific
BGP
routing
information was lost at the point of
aggregation.
That’s all fine - but what’s
“aggregation”? It’s just another term
for summarization. You’ll perform
this summarization the same way
you did for EIGRP and OSPF routes
- but BGP has an interesting default
that those two protocols do not
have. Stay tuned.

The Aggregator Attribute
This optional attribute gives the
BGP Router ID and AS number of
the router that performed the
aggregation.
The
aggregator
attribute will also include a list of
all the AS numbers that these
aggregated routes passed through.
The Community Attribute
This attribute allows us to logically
group routers that have a common
configuration,
making
them
members of a community. Creating
BGP communities can save you a

lot of work, as you’ll see later in
this section.
And who doesn’t like less work?
The Originator ID and Cluster ID
Attributes
Both these optional attributes can
be put into effect when route
reflectors are used. We’ll examine
these attributes during the route
reflector discussion.
BGP Route Aggregation (Not
AggreVation)
In your CCNA studies, you learned

how to perform manual route
summarization in both RIPv2 and
EIGRP. BGP Route Aggregation
works much the same way – the
routes to be summarized, or
aggregated, should be written out
in binary and the common bits
identified. These common bits yield
both the aggregate route and the
subnet mask, and we need both of
those to get the desired result.
BGP route aggregation gives us
choices that RIPv2 and EIGRP did
not. You’ll remember that when
manual
summarization
was
configured
with
those
two

protocols, the interface would send
out only the summary route and
mask. With BGP, we can send out
only the aggregate route and mask,
or the aggregate route along with
the more-specific routes.
The following network will be used
to illustrate route aggregation.

On R5, additional loopback
addresses have been configured:
16.1.1.1, 17.1.1.1, 18.1.1.1, and
19.1.1.1, all with /8 masks. They
will now be advertised via BGP.
R5(config-if)#router bgp 500
R5(config-router)#network
255.0.0.0
R5(config-router)#network
255.0.0.0
R5(config-router)#network
255.0.0.0
R5(config-router)#network
255.0.0.0

16.0.0.0

mask

17.0.0.0

mask

18.0.0.0

mask

19.0.0.0

mask

The downstream router, R1, has all

four of these routes in its BGP
table.

This is fine, but we know it’s a
good idea to keep all routing tables
as concise as possible while also
keeping them complete. We can
aggregate these four routes and
advertise them as one aggregate
route.
First, it’s time for our old friend
binary math! Since these networks
all have “0” for the last three octets,

we’ll only convert the first octet
here.
Common bits are highlighted.
16
17
18
19

00010000
00010001
00010010
00010011

Working from left to right, we see
that the four networks have the first
six bits in common. The value of the
first six bits is 16, and the first six
bits will be the bits that are set to
“1” in the aggregate mask. This

binary string of 11111100 yields a
mask of 252.0.0.0.
We’ll inject the aggregate route into
BGP via the aggregate-address
command.

R1 sees the aggregate and places it
into its BGP table. Note that by
default, the more-specific routes are
not removed from the BGP table.
With EIGRP, RIP, and OSPF
summarization, those routes were
gone.

To suppress the advertisement of
the more-specific routes, use the
summary-only option with the
aggregate-address command.
It’s common to have an “oh, yeah,
now I remember that” moment
(OYNIRTM) at that point in your
config. If that happens to you, I
recommend you remove the first
aggregate-address
command
before writing the one with the
summary-only option.

There’s one more option with the
aggregate-address command you
should know about.
Actually, there are several other
options, but one more big one for
the CCNP ROUTE exam. You can
learn the others when you go after
your CCIE!
R5(config-router)#aggregate-address
252.0.0.0 summary-only ?

advertise-

16.0.0.0

Set conditi

map

as-set
attributemap

route-map

summaryonly

to advertise
attribute
Generate A
set path
information
Set attribut
of aggregat

Set
parameters
aggregate
Filter more
specific
routes from
updates
Conditiona
filter more

suppressmap

specific
routes from
updates

If you use the as-set option, the path
advertised for this route will be an
AS_PATH that was traveled by all
of the more-specific paths being
aggregated. Cisco recommends that
you do not use this option when a
great number of paths are being
aggregated, since the aggregate may
be removed, updated, and replaced
as AS-path reachability changes.
Why aggregate routes in the first
place? For the same reason we did

so with other protocols – route
aggregation lessens the load on
router resources by making the
routing tables smaller while still
being complete and accurate.
T-shooting hint: If your aggregate
route isn’t being advertised, be sure
your BGP table actually has the
routes being summarized.
Resetting and Clearing The BGP
Peer Connections
Sometimes you’ll find it necessary
to reset the TCP session between

BGP speakers. Not all changes
require this. For example, the route
aggregation we just performed
required no such reset.
There is a “hard reset” and a “soft
reset” -- The clear ip bgp *
command performs a hard reset
where the TCP session itself is
reset:
R1#clear ip bgp *
R1#
09:18:36: %BGP-5-ADJCHANGE: neighbor
10.1.1.5 Down User reset
09:18:36: %BGP-5-ADJCHANGE: neighbor
172.12.123.2 Down User reset
09:18:36: %BGP-5-ADJCHANGE: neighbor

172.12.123.3 Down User reset

With this command, the BGP
sessions themselves are reset and
the neighbor adjacencies are lost.
The adjacencies you see here came
back within 20 – 40 seconds, but
BGP reachability was lost during
that time.
To clear the sessions without
resetting the sessions, use the soft
option, as shown here:
R1#clear ip bgp * soft

Internal BGP: Synchronization,

Full
Meshes,
Reflectors

and

Route

We know all about eBGP and iBGP
at this point.
Now we need to learn the important
operational differences between the
two. These are vital to success on
the ROUTE exam and working with
BGP in real-world networks. Here
are some basic rules and guidelines
in working with iBGP networks…
iBGP neighbors do not have to
be directly connected. The
connection between iBGP

routers is on TCP port 179.
It’s common practice to use a
remote router’s loopback
address in the neighbor
statement, rather than the
closest physical address. This
allows us to keep our BGP
adjacencies in situations
where losing the physical
address would result in losing
that adjacency.
iBGP routers do not send
updates to every single

neighbor. The only way an
iBGP router will advertise a
route to its neighbors is if the
route was created by the
transmitting router via the
network command, by static
route redistribution, IGP route
redistribution, or if the
advertised route is a connected
route in the first place.
This means that when a iBGP
speaker learns about a route from
an iBGP peer, the only kind of BGP
router that route can then be
advertised to is an eBGP router.

iBGP routers do not advertise
routes received from one iBGP
neighbor to other iBGP neighbors.
In theory, this would mean that
every AS would have to be fully
meshed in order for routes to be
properly advertised. In the real
world, this would create a great
deal of overhead.
Thankfully, this is unnecessary
overhead, because BGP gives us a
way around having to create such a
logical nightmare. Before we take a
look at this solution, let’s examine
BGP’s rule of synchronization.

The BGP rule of synchronization
only matters when an AS is going to
serve as a transit area, and if there
are non-BGP speakers in the transit
area.

In the illustration, AS 200 is
serving as a transit area between
AS 100 and AS 500. The issue is
that the only iBGP neighbor

relationship is between R2 and R4.
This is a logical relationship only;
when R4 wants to send data to
200.20.0.0, it has to physically go
through R3. Since R3 is not running
BGP, it can’t possibly know about
this network, so R3 will drop
packets destined for 200.20.0.0.
Without the synchronization rule,
R4 would advertise a path to
200.20.0.0
over
its
eBGP
connection to R5. Of course, R5’s
packets destined for this network
would be dropped at R3 as well.

The BGP Rule Of Synchronization
states that a transit AS will not
advertise a route until every router
in the transit AS has the route in its
IGP routing table.
R4 will not send an advertisement
for network 200.20.0.0 to R5 until
R4 hears an advertisement for that
network from R3 via an IGP; that
indicates that the non-BGP speaking
R3 has a route for that network.
BGP Synchronization’s
major
benefit is that packets that can’t
possibly reach the desired remote
network will not even be sent,

reducing both the amount of
unnecessary traffic
and
the
unnecessary strain on router
resources. After all, why send those
packets if they can’t reach the
destination?
BGP Synchronization is turned off
in many deployments, though, and
as of IOS version 12.2(8) it’s
turned off by default. There are
three scenarios under which it’s
safe to turn synchronization off:
1. If all the routers in the AS
are running BGP.
2. If a full mesh exists in the

AS.
3. If the AS is not a transit AS
to begin with.
To do so, simply run the BGP
command no synchronization.
R1(config)#router bgp 100
R1(config-router)#no synchronization

The Problem With BGP Full
Mesh Deployments
BGP’s rule of Split Horizon is
much different than the Split
Horizon rules you learned in your
CCNA studies.

BGP Split Horizon states that one
iBGP peer can’t learn about a path
from one iBGP peer and then
advertise it to another iBGP peer.
Therefore, we would need a logical
full mesh among all iBGP speakers
in an autonomous system.
You know how we see very few full
meshes in Frame Relay? There’s a
reason - and it’s the same reason
we don’t see many BGP full
meshes.
Any full-mesh deployment of BGP
is going to have a large cost on the
router’s resources (memory, CPU).

A full mesh is going to require a
large number of TCP connections,
and the more routers you have, the
more connections you’ll need.
Take an AS with 20 routers. The
formula for determining the number
of connections needed for a full
mesh is:
X (x – 1) / 2, with “x” being
the number of routers
This formula for 20 routers: 20 (20
– 1) / 2. That’s 20 x 19, which is
380, divided by 2, which is 190.
BGP requires 190 separate TCP

connections for a 20-router AS!
Add this to the administrative
nightmare you’ll have in creating
this full mesh, along with the
additional configurations that will
be needed when routers are added
or removed from the AS, and
you’ve got quite a labor-intensive
situation.
Three good reasons to avoid fullmesh iBGP deployments:
An unnecessarily large number
of TCP sessions are created.

These sessions use a lot of
bandwidth.
You’re going to spend a lot of
time configuring all these peer
connections, and sooner or
later, you’re going to miss one
(especially in a large AS).
Then you get to spend even
more time troubleshooting
your network!
Luckily, there’s a way around the
BGP Split Horizon rule – route
reflectors.

Route Reflectors
BGP route reflectors are the
exception to the BGP Split Horizon
rule. A router configured as a BGP
route reflector can take a route
learned from one iBGP peer and
advertise it to another iBGP peer.
The iBGP peers that will be
sending routes to the route reflector
are referred to as clients. When one
client sends a route to the route
reflector, the RR does just that – it
reflects the route to the other
clients.

To the clients, this is a totally
transparent process. The clients
don’t even know they are clients,
and they require no additional
configuration.
All clients must peer with the RR.
Clients will not have a peer
relationship with other clients. This
allows us to have BGP work with a
partial mesh rather than a full mesh.
Remember how we would need 190
separate TCP connections in a 20router AS? If you have a single
router act as an RR in the same 20router AS, we’d need the RR to

have a peering with each of the
clients, and each of the other 19
BGP speakers (clients) would have
a single BGP peer relationship back
to the RR. This would result in only
38 total TCP connections being
needed.
That’s a huge reduction in the
overhead caused by all those TCP
connections, not to mention the
hours
of
configuration
and
troubleshooting you’ll save.
A BGP speaker that has a peer
relationship to an RR does not have
to be a client; these speakers are

called nonclients. Nonclients do
have to have a TCP connection to
every other router in the AS.
Let’s take a look at how route
reflectors impact a network. The
following BGP peer relationships
are in place and are indicated with
dotted lines. Synchronization has
been disabled. All interface IP
addresses end with the router’s
number.
R1 / R2 / R3 are on a frame
network, 172.12.123.0 /24.
R2 / R3 / R4 are on an ethernet

segment, 10.1.1.0 /24.
Each router has a loopback
with its own number for each
octet (1.1.1.1, etc.).
Peers:
R1: Peering with R2 and R3.
R2: Peering with R1.
R3: Peering with R1 and R4.
R4: Peering with R3.

R4 is in AS 4, and will advertise its
loopback (4.4.4.4 /32) into BGP.
R3 has R4’s loopback in its BGP
table:

What about the other routers in AS

1235? Will they have this route in
their BGP tables? Let’s first look at
R3’s iBGP peer, R1:

The route is there… but there is no
“>” next to the route, so this is not a
“valid and best” route.
Here’s a good three-step t-shooting
process for BGP - and for just about
anything else in Ciscoworld:
What is the problem?

If we don’t immediately know
what the issue is, what
command will show us what
the problem is?
Once we’ve identified the
issue, how can we solve it?
The problem: The next-hop address
for this route, 10.1.1.4, is
unreachable from R1. Never
assume IP connectivity!
The command that verifies this:
show ip bgp 4.4.4.4.

The solutions: Use dynamic or
static routing to get a route to
4.4.4.4 in R1’s IP routing table, or
configure next-hop-self on R3.
Let’s get some practice with nexthop-self:
R3(config)#router bgp 1235
R3(config-router)#neighbor 172.12.123.1 nexthop-self
R3#clear ip bgp * soft

The result is a next-hop address that
R1 can reach, so the BGP route is

now valid and best.

What about R1’s iBGP peer, R2?
R2#show ip bgp
R2#

When you run a show command on
a Cisco router and are immediately
back at the enable prompt, that
means there is nothing to show you.
R2 does not have the route in its
BGP table due to BGP’s Split
Horizon rule. R1 learned about the

route from an iBGP peer, and
therefore cannot advertise that route
to other iBGP peers.
The same thing happens if R2
advertises its loopback to R1. R1
can put the route in its BGP table,
but cannot advertise the routes to its
other iBGP peer, R3.
R2(config)#router bgp 1235
R2(config-router)#network
255.255.255.255

2.2.2.2

mask

R1 will see the new route as valid
and best….

… but will be unable to advertise it
to R3.

R3 doesn’t have the route to R2’s
network, since it was learned by R1
via an iBGP peer (R2) and can’t be
advertised to another iBGP peer
(R3).
There are two solutions to this
issue. The first is to create a full
mesh in AS 1235. Using the formula

mentioned earlier, this solution
would require 4 x (4-1) /2
connections, or 6 separate TCP
connections.
This solution requires more of a
router’s resources, and will take
additional time to configure and
possibly troubleshoot -- and it’s a
horribly non-scalable solution.
We always have to plan for future
growth, and the more growth we
have with a full mesh, the more
administrative and logical overhead
we have.

A much more scalable solution is to
configure R1 as a route reflector.
R2 and R3 will be the route
reflector clients. These routers will
require
no
additional
configuration.
R1 will identify these two
neighbors as route reflector clients,
allowing R1 to advertise routes
learned via iBGP peers to other
iBGP peers.
R1(config)#router bgp 1235
R1(config-router)#neighbor 172.12.123.2 routereflector-client

00:34:00: %BGP-5-ADJCHANGE: neighbor
172.12.123.2 Down RR client config change
R1(config-router)#neighbor 172.12.123.3 routereflector-client
00:34:12: %BGP-5-ADJCHANGE: neighbor
172.12.123.3 Down RR client config change
00:34:27: %BGP-5-ADJCHANGE: neighbor
172.12.123.2 Up
00:34:38: %BGP-5-ADJCHANGE: neighbor
172.12.123.3 Up

The results here may be different
than those you’ve seen elsewhere.
Configuring a BGP peer as a route
reflector client will bring down the
peer connection. As you can see
from the timestamps, they were only
down for 25 to 30 seconds, but it’s

an important point to remember.
Especially on production networks!
:)
Let’s look at the BGP tables of the
route reflector clients after the
adjacency reforms.

The route reflector is working
perfectly.
Route reflectors serve two major

purposes. First, they reduce the
number of TCP connections needed
in an iBGP deployment. Just as
importantly, route reflectors allow
us to get around the rule of BGP
Split Horizon – because unlike
other protocols you studied to get
your CCNA, you can’t turn BGP
Split Horizon off at the interface
level.
So if BGP Split Horizon is there to
prevent routing loops, why don’t
we have routing loops form when
using
route
reflectors
and
effectively disabling Split Horizon?
We’re going to answer that in just a

moment. First, let’s do a little
verification.
To verify that a router is seen as a
route reflector client, run show ip
bgp neighbor x.x.x.x. This is an
excellent command for overall BGP
troubleshooting. This is a verbose
command to say the least, but
there’s some great information here.
Below
you can see
that
172.12.123.2 is seen as a route
reflector client. I’m only showing
you about half of this command’s
output since the second half is more
for
Cisco
TAC
(Technical

Assistance Center) calls, but at the
bottom of this output you can see the
number of adjacency resets and the
reason for the last one. Pretty cool!
R1#show ip bgp neighbor 172.12.123.2
BGP neighbor is 172.12.123.2, remote AS 123,
internal link
BGP version 4, remote router ID 2.2.2.2
BGP state = Established, up for 00:00:41
Last read 00:00:41, hold time is 180,
keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised
Address family IPv4 Unicast: advertised
and received
Received 881 messages, 0 notifications, 0 in
queue
Sent 890 messages, 0 notifications, 0 in
queue
Route refresh request: received 0, sent 0

Default minimum time between
advertisement runs is 5 seconds
For address family: IPv4 Unicast
BGP table version 6, neighbor version 6
Index 1, Offset 0, Mask 0x2
Route-Reflector Client
NEXT_HOP is always this router
Outgoing update prefix filter list is
NO16THROUGH19
0 accepted prefixes consume 0 bytes
Prefix advertised 17, suppressed 0,
withdrawn 0
Number of NLRIs in the update sent: max 5,
min 0
Connections established 4; dropped 3
Last reset 00:01:09, due to RR client
config change

Clusters And The Originator-ID

Attribute
BGP Clusters are a combination of
route reflectors and clients that are
sharing information. Note that I said
“reflectors”, not “reflector”. There
can be more than one route reflector
in a cluster. When deciding on the
routers that will be the route
reflectors in a cluster, you should
consider
both
the
peering
relationships in place (and the ones
that would need to be added to
make the route reflector work) and
the impact on router resources that
being an RR creates.

Make sure the routers that will
serve as the route reflectors in your
network possess the resources to
get the job done.
If BGP Split Horizon is intended to
stop routing loops, why is Split
Horizon not an issue with clusters?
Because
the
Originator-ID
identifies the router that originated
the path. This attribute is set by the
route reflector and effectively
eliminates the chance of a routing
loop. If the router that originated the
route receives the route in an
update, the update will be
discarded.

Where Do Route Reflectors Send
Routes?
Route reflectors have three possible
types of peers – clients, nonclients,
and eBGP peers. How a route
reflector handles the update
depends on the device that sent the
update:
Updates from RR clients are
sent to all client and nonclient
peers.
Updates from eBGP peers are
sent to all client and nonclient

peers.
Updates from nonclient peers
are sent to all clients in the
cluster.

Prefix Lists
Once you’ve got the basic BGP
configuration up and running, it’s
time to fine-tune the routes being
advertised…
… or maybe the routes you don’t
want advertised.

BGP gives us several tools with
which to control the flow of
network advertisements, and the
first of these is the prefix list.
Cisco states several reasons for the
use of prefix lists….
support for incremental
updates
their high flexibility
writing BGP prefix lists is
much easier than writing
access-lists that filter BGP

updates. (Trust me, they’re
right.)
The major reason for using BGP
prefix lists is that filtering BGP
with prefix lists is much faster and
efficient than other methods.
Why? BGP tables can be huge, and
since prefix lists are going to match
only on the prefix of the address,
the entire process is much faster
than using ACLs.
It’s also easy to go back and insert
lines in the middle of a pre-existing

prefix list, which is great when
you’ve written a 20-line list and
suddenly have the need to put a line
at position 12.
Before we look at the actual
configuration, let’s look at the
theory of how a BGP prefix-list
operates. It’s quite similar to an
ACL. First, if a route is expressly
permitted, it’s used; if it’s denied,
it’s not used. (Makes sense!)
Also lurking at the bottom of every
prefix list is our old friend, the
implicit deny. The implicit deny
here works the same as it does in an

ACL. Remember that if a prefix is
not expressly permitted, it’s
implicitly denied, and any explicit
deny statements do NOT override
the implicit deny.
Prefix lists work from top to
bottom, just like ACLs, and when a
match is found, the list stops
running. Prefix list statements are
all numbered, with the lowest
numbers at the top, so the line with
the smallest sequence number that
matches the prefix will be the one
that matches.
Even if you don’t actually number

the statements as you write the
prefix list, they’re numbered by
default – each line you write is
numbered with the sequence number
incrementing by 5 for every line you
write. This makes it easy for you to
go back and add lines that you might
have forgotten to put in, or when the
need arises later to add lines.
To see prefix lists in action, we’ll
use this network:

The R1/R2/R3 network is our old
friend 172.12.123.0/24, and the R1R5 segment is 15.1.1.0/24. Dotted
lines indicate BGP peers.
In this example, R5 has four
additional loopbacks that will be
advertised into BGP in addition to

5.5.5.5/32.
interface Loopback16
ip address 16.1.1.1 255.0.0.0
!
interface Loopback17
ip address 17.1.1.1 255.0.0.0
!
interface Loopback18
ip address 18.1.1.1 255.0.0.0
!
interface Loopback19
ip address 19.1.1.1 255.0.0.0
!
R5(config)#router bgp 5
R5(config-router)#network
255.255.255.255
R5(config-router)#network
255.0.0.0
R5(config-router)#network

5.5.5.5

mask

16.0.0.0

mask

17.0.0.0

mask

255.0.0.0
R5(config-router)#network
255.0.0.0
R5(config-router)#network
255.0.0.0

18.0.0.0

mask

19.0.0.0

mask

The downstream routers R1, R2,
and R3 all see the routes. Will they
be valid and best on all routers?

The unreachable next-hop address
rears its ugly head again, as neither
R2 nor R3 have a route for
15.1.1.5. We’ll remedy that with the
appropriate
next-hop-self
commands on R1.
R1(config)#router bgp 123
R1(config-router)#neighbor 172.12.123.2 nexthop-self
R1(config-router)#neighbor 172.12.123.3 nexthop-self

Let’s verify that command’s effect
by checking the BGP tables on R2

and R3.

Now both R2 and R3 have all five
routes in their BGP tables, and they
are “valid and best”.
Sometimes, though, you don’t want
every router in a network to have
every available route.

Let’s say that you want R1 to know
about all five networks, but R2 and
R3 should not. We do want R2 and
R3 to keep the route to 5.5.5.5/32,
though. A prefix list written on R1
and applied to neighbors R2 and R3
will do this. Let’s write and
examine the prefix list first:
R1(config)#ip prefix-list
deny 16.0.0.0/8
R1(config)#ip prefix-list
deny 17.0.0.0/8
R1(config)#ip prefix-list
deny 18.0.0.0/8
R1(config)#ip prefix-list
deny 19.0.0.0/8
R1(config)#ip prefix-list
permit 0.0.0.0/0 le 32

NO16THROUGH19
NO16THROUGH19
NO16THROUGH19
NO16THROUGH19
NO16THROUGH19

Don’t forget your up arrow when
writing prefix lists. That will save
you a lot of typing. Also, give your
prefix list an intuitive name where
those who follow behind you can
tell what the purpose of the prefix
list is in the first place.
that also helps you remember why
you wrote it in the first place!
That last line looks a little strange,
doesn’t it? This is the prefix list
equivalent of an ACL’s “permit
any” statement. Remember, the four
explicit deny statements do NOT
override the unseen implicit deny.

The only way to avoid the implicit
deny is to write an explicit
statement that permits all prefixes.
Before we apply the prefix list,
let’s use IOS Help to illustrate what
“le” means.
R3(config)#ip prefix-list NO16THROUGH19
permit 0.0.0.0/0 ?
ge Minimum prefix length to be matched
le Maximum prefix length to be matched
<cr>
R3(config)#ip prefix-list NO16THROUGH19
permit 0.0.0.0/0 le 32

“le” means “less than or equal to”;
“ge” means “greater than or equal

to”.
Now to apply this prefix list to the
neighbors R2 and R3.
R1(config)#router bgp 123
R1(config-router)#neighbor 172.12.123.2 prefixlist NO16THROUGH19 out
R1(config-router)#neighbor 172.12.123.3 prefixlist NO16THROUGH19 out

After resetting the connections to
R2 and R3, those two routers no
longer see the networks 16 –
19.0.0.0/8, but still see the route for
5.5.5.5 /32.

As with ACLs, you’ve got a few
options when it comes to viewing
prefix lists and their contents. The
basic command is show ip prefixlist.
R1#show ip prefix-list
ip prefix-list NO16THROUGH19: 5 entries
seq 5 deny 16.0.0.0/8
seq 10 deny 17.0.0.0/8
seq 15 deny 18.0.0.0/8
seq 20 deny 19.0.0.0/8
seq 25 permit 0.0.0.0/0 le 32

Notice that the first line of the

prefix list was numbered “5”, and
each line increments by five, even
though we entered no sequence
numbers while writing the list.
These numbers do make it very easy
to go back and add lines exactly
where you want them.
Let’s say that after writing this list
and applying it, you realize you
want the network 16.1.0.0 /16 to be
allowed while denying all other
networks with the prefix 16.0.0.0/8.
Using the sequence numbers, we
can add such a line so that it is read
before the line that denies all
networks with the prefix 16.0.0.0/8.

R1(config)#ip prefix-list NO16THROUGH19 ?
deny
Specify packets to reject
description Prefix-list specific descriptin
permit
Specify packets to forward
seq
sequence number of an entry
R1(config)#ip prefix-list NO16THROUGH19
seq 2 permit 16.1.0.0/16

R1#show ip prefix-list
ip prefix-list NO16THROUGH19: 6 entries
seq 2 permit 16.1.0.0/16
seq 5 deny 16.0.0.0/8
seq 10 deny 17.0.0.0/8
seq 15 deny 18.0.0.0/8
seq 20 deny 19.0.0.0/8
seq 25 permit 0.0.0.0/0 le 32

The line we added with the
sequence number “2” was put just

where we wanted it – at the top of
the prefix list. In this order, an
update for the network 16.1.0.0/16
would be permitted while all other
networks matching 16.0.0.0/8 will
be denied.
Peer Groups
BGP Peer Groups help to lower the
impact of routing on the router’s
resources, as well as lowering the
amount of actual configuration
needed for multiple peerings in
BGP.

Anything that lessens both our
workload and the CPU workload is
fine with me! This is a very
powerful concept and you’ll
definitely see this anywhere you
work with BGP.
Peer group members inherit the
settings applied to the peer group,
which is really the whole point of
creating peer groups.

R1 will peer with R2, R3, and R5.
R1 will have the same outbound
policy for all three routers. This
allows the configuration of a BGP
Peer Group. (Peer group members
can have separate inbound
policies.)
In the config below, the second line
names the peer group, the third line
identifies the AS number, and the
fourth line applies the same routemap to all members of this peer
group. Finally, the members of the

peer group are identified with
neighbor statements.
R1(config)#router bgp 1235
R1(config-router)#neighbor
AS1235GROUP
peer-group
R1(config-router)#neighbor
AS1235GROUP
remote-as 1235
R1(config-router)#neighbor
AS1235GROUP
route-map AS_POLICY out
R1(config-router)#neighbor 2.2.2.2 peer-group
AS1235GROUP
R1(config-router)#neighbor 3.3.3.3 peer-group
AS1235GROUP
R1(config-router)#neighbor 5.5.5.5 peer-group
AS1235GROUP

As you add neighbors in AS1235,
you only have to type one line per
new neighbor - the neighbor

command followed by the IP
address of the neighbor used for the
peer relationship and the name of
the peer group.
Note the direction of the route-map
shown above - it’s outbound. To
repeat, peer group members are
required to share the same outbound
policies. They can share the same
inbound policies, but they don’t
have to.
Peer group names are locally
significant only - the name of the
group isn’t passed to other routers.
This means you can reuse the name

throughout the network, but I’d be
careful about that - it can get a little
confusing to the network admins.
Peer groups take a little getting used
to, but they’re a very efficient way
of configuring routers.
Not to mention saving you a lot of
typing! :)
BGP Confederations
BGP Confederations are a logical
grouping of autonomous systems
that appear to outside BGP speakers
as a totally separate AS.

In
other
words,
a
BGP
Confederation is a logical grouping
of logical groups.
Yeah, I know. It makes more sense
when you see a picture…
The internal AS numbers are not
known to any BGP speaker outside
the Confederation. Using BGP
Confederations also limits the
number of iBGP peer connections just as with route reflectors, a full
mesh is not needed. In the following
example, R9 is totally unaware that
there is a confederation, and knows
only of the existence of AS 321. R9

has no idea that AS 321 actually
contains three other autonomous
systems.

R1’s configuration will look like
this:
R1(config)#router bgp 123
R1(config-router)#bgp confederation identifier

321 (assigns number 321 to the
confederation; this will be the AS number
seen by R9)
R1(config-router)#bgp confederation peers 7
671 (identifies the other AS numbers that
are part of the confederation)
R1(config-router)#neighbor 9.9.9.9 remote-as 9
R1(config-router)#neighbor 2.2.2.2 remote-as
123
R1(config-router)#neighbor 3.3.3.3 remote-as
123
R1(config-router)#neighbor 5.5.5.5 remote-as 7
R1(config-router)#neighbor 6.6.6.6 remote-as
671
R9’s neighbor statement for R1 will refer to AS
321, the confederation number.
R9(config)#router bgp 9
R9(config-router)#neighbor 1.1.1.1 remote-as
321

Communities
BGP communities allow us to tag a
route or group of routes with a
common value that will follow it
throughout the rest of the network.
(A good way to remember this is
the simple phrase “Communities
equal consistency.”) Communities
are transitive optional attributes.
Some common community values:
NO-EXPORT: Marking a route with
this community attribute prevents it
from being advertised to an eBGP
peer.

NO-ADVERTISE:
Taking
the
previous community one step
further, this community attribute
prevents the route from being
advertised to ANY other router.
The available communities change
often, with new ones added, so I
recommend you check Cisco’s
website
for
the
available
communities for your IOS. You’ll
have to master them to become a
CCIE.
Internet Connections And BGP

Four little words, so much potential
for trouble. Working with BGP can
become quite a complex endeavor,
and trying to tell you everything
about BGP and internet connectivity
here is, well, impossible. We’re
going to take a few minutes here
and look at some basic design
guidelines and some introductory
terminology.
The first term is multihoming. This
is a BGP configuration where
multiple connections to the internet
exist. This allows for load
balancing as well as redundancy –
you don’t want to have internet

connectivity cut off if one path goes
down. Single points of failure are
never good, but can be positively
crippling with BGP.
From the ISP’s point of view, there
are three ways to handle sending
routes to the BGP AS:
Send default routes only into
the AS. (Low resource usage uses the least memory of these
three options.)
Send default routes and
selected more-specific routes

into the AS.
Send all routes into the AS.
(High resource usage - uses
the most memory of these three
options.)
If the ISP sends only default routes
into the AS, the non-BGP speakers
in the AS will naturally use the path
with the best metric to reach
external destinations. With the other
two choices, BGP will generally
use the AS_PATH value to decide
how routers in the AS should reach

external destinations. The ISP has to
walk a line between having morespecific
routing tables
and
overtaxing router resources.
Communications Between Your
Router And ISP

Having more than one connection to
an ISP, or having connections to
multiple ISPs, is great for
redundancy but can be tough on the
router. Hopefully you’ve got a
brand-new top-of-the-line router for
R6 here, but that isn’t always the
case. The amount of CPU and
memory on this router is especially
critical, and can impact the type of
routes you should be receiving from
your ISP.
If R6 has plenty of memory and
CPU (and yes, “plenty” is an

arbitrary term), you should be okay
getting specific routes from the
ISPs. If memory and CPU are a
concern, you should consider
receiving only a default route from
the ISPs. Receiving only default
routes causes the least stress on
your router resources.
You can opt for a combination of
default and more-specific routes,
but in the real world, you’ve
usually got a router that can handle
the load of specific routes or a
router that can only handle default
routes.

IGP < > BGP Redistribution
Warning: Don’t ever, ever, ever
perform redistribution between IGP
and BGP unless you really know
what you’re doing. And I mean
really know what you’re doing.
That’s what practice labs are for!
Route redistribution isn’t always
bidirectional. You can redistribute
RIP routes into an EIGRP AS
without taking the EIGRP routes and
placing them into RIP.
What’s all this got to do with BGP,
you ask? At times, it may be

necessary for you to place IGP
routes into the BGP routing table.
There are three ways to do this: the
network command, redistribution of
static routes, and redistribution of
dynamically learned IGP routes.
Cisco recommends you avoid the
last choice whenever possible, and
so do I. That form of redistribution
can easily lead to routing loops.
The network command is generally
your best bet.
We have the ability to redistribute
BGP routes into an IGP, but there is
rarely good reason to do so. The

basic reason this is usually a bad
idea is simple; the Internet has a
LOT of routes, many more routes
than your network is going to be
equipped to handle. A full BGP
routing table can have over 90,000
routes.
Another danger to avoid – routes
learned via an IGP in one AS
should never be redistributed to
other autonomous systems via BGP.
You’re begging for a routing loop.
Private AS Numbers

BGP allows you quite a bit of range
when it comes to selecting an AS
number:
R1(config)#router bgp ?
<1-65535> Autonomous system number

Just as there are private IP
addresses, there are private AS
numbers. The AS numbers 64512 65535 are considered “private”
AS, and just as private IP addresses
should not be advertised to external
networks, neither should private AS
numbers.
Public or private, you can’t assign
AS number zero with BGP, just as

you couldn’t with EIGRP.
show ip bgp neighbor vs. show ip
bgp summary
For OSPF and EIGRP, the show ip
ospf neighbor and show ip eigrp
neighbor commands are the way to
check on adjacencies.
For BGP, while show ip bgp
neighbor will certainly give you
information on the router’s BGP
neighbors, it may well be too much
information. Here’s the output of
show ip bgp neighbor on a BGP

speaker that has only one neighbor!
R3#show ip bgp neighbor
BGP neighbor is 172.12.23.2, remote AS 23,
internal link
BGP version 4, remote router ID 172.12.23.2
BGP state = Established, up for 00:01:24
Last read 00:00:23, hold time is 180,
keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and
received(new)
Address family IPv4 Unicast: advertised
and received
Received 5 messages, 0 notifications, 0 in
queue
Sent 5 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Default minimum time between
advertisement runs is 5 seconds
For address family: IPv4 Unicast

BGP table version 1, neighbor version 1
Index 1, Offset 0, Mask 0x2
0 accepted prefixes consume 0 bytes
Prefix advertised 0, suppressed 0, withdrawn
0
Number of NLRIs in the update sent: max 0,
min 0
Connections established 1; dropped 0
Last reset never
Connection state is ESTAB, I/O status: 1,
unread input bytes: 0
Local host: 172.12.23.3, Local port: 11000
Foreign host: 172.12.23.2, Foreign port: 179
Enqueued packets for retransmit: 0, input: 0 misordered: 0 (0 bytes)

SRTT: 165 ms, RTTO: 1172 ms, RTV: 1007 ms,
KRTT: 0 ms
minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200
ms
Flags: higher precedence, nagle
Datagrams (max data segment is 1460 bytes):
Rcvd: 8 (out of order: 0), with data: 5, total data
bytes: 121
Sent: 8 (retransmit: 0), with data: 5, total data
bytes: 121

That’s a lot of information! To get a
brief summary of BGP neighbor
status, use… you guessed it …
show ip bgp summary!

R3#show ip bgp summary
BGP router identifier 5.5.5.5, local AS number
23
BGP table version is 1, main routing table
version 1

There’s no “right” or “wrong” way
to view BGP neighbors.. it all
depends on how much or how little
information you need!
A Little Of This ‘n’ That
BGP Message Types, The Peering
Process, And The BGP RID
Once

the

TCP

connection

is

complete, the Open packet is the
first one to go out. If the values in
that packet sent by “Router A” are
acceptable to “Router B”, then a
keepalive is returned by “B” and
the BGP connection can then be
built.
The Open message contains the
BGP RID that we’ve seen in a
couple of show commands, and the
rules for the BGP RID are
(thankfully) the same as they are for
the OSPF RID.
You can hardcode the BGP RID as
well, with the bgp router-id

command.
R1(config)#router bgp 1235
R1(config-router)#bgp ?

alwayscompare-med

bestpath

client-toclient

Allow
compar
MED fr
differen
neighbo
Change
default
bestpat
selectio

Configu
client to
client r
reflecti

cluster-id

confederation

dampening
default

deterministicmed

Configu
RouteReflect
Cluster
AS
confede
parame
Enable
flap
dampen
Configu
BGP de
Pick the
MED p
among
adverti
the

fast-externalfallover

log-neighborchanges

redistributeinternal

neighbo
AS
Immedi
reset se
if a link
direct
connec
externa
goes do
Log nei
up/dow
reset re
Allow
redistri
of iBGP
IGPs
(danger

router-id

scan-time

Overri
configu
router
identifi
Configu
backgro
scanner
interva

R1(config-router)#bgp router-id ?
A.B.C.D Manually configured router
identifier
R1(config-router)#bgp router-id 11.11.11.11
R1(config-router)#^Z
R1#show ipbgp
19:50:28: %BGP-5-ADJCHANGE: neighbor
15.1.1.5 Down Router ID changed
19:50:28: %BGP-5-ADJCHANGE: neighbor

172.12.123.2 Down Router ID changed
19:50:28: %BGP-5-ADJCHANGE: neighbor
172.12.123.3 Down Router ID changed
19:50:28: %SYS-5-CONFIG_I: Configured from
console by console

Oh, yeah -- your adjacencies will
come down when you do that.
show ip bgp verifies the change
(table removed from output)
R1#show ip bgp
BGP table version is 6, local router ID is
11.11.11.1

Back to the packet types…
The BGP Update packet is unique in
that unlike RIP and EIGRP updates

that contain multiple routes, a BGP
Update packet will contain info on
one route and one route only.
Having seen BGP in action, you
know there can be much more
information to carry about a BGP
route than a RIP or EIGRP route.
A couple of times during the course,
we saw a BGP Notification
message - that’s going to be sent any
time a connection goes down.
BGP keepalives are sent every 60
seconds by default; the BGP default
hold time is 180 seconds.

Watch your iBGP vs. eBGP
neighbors. If you’re looking at a
potential eBGP neighbor and that
neighbor isn’t directly connected,
you need a static route pointing to
that neighbor and the ebgpmultihop command.
In some cases with synchronization
on, you can use a static route to
null0 - the “bit bucket” - to allow a
BGP route to be used. It’s doubtful
that’ll appear on the CCNP ROUTE
exam, but I mention it to let you
know that a static route to null0
does not help with eBGP neighbor
relationships.

With iBGP neighbors, since they’re
in the same autonomous system, it’s
likely that the route to the neighbor
exists via an IGP. If not, you can use
a static route there as well. The key
is that an IGP will not be running
between ASes, so with eBGP
neighbors we have only the static
route - not dynamically learned
routes.
We saw the result of clear ip bgp *
-- that’s a hard BGP reset and it
brings the adjacencies down. We go
to a lot of trouble to build those
suckers, so let’s not do that unless

absolutely necessary.
R1#clear ip bgp * ?

in
ipv4
out
soft
vpnv4

Soft reconfig
inbound
update
Address
family
Soft reconfig
outbound
update
Soft reconfig
Address
family

<cr>
Running the soft option shown

above is the same as running out -both result in a soft outbound reset.
Now if you’re like me - and I mean
no insult by that - you’d wonder
why the “soft” option by itself
doesn’t perform both an inbound
and outbound update.
Simply put, the outbound update is
easy on the router memory, and the
inbound update is a memory hog.
The soft inbound reset is fine for
updating the BGP tables without
tearing the adjacencies down, but
it’s still a bit of a memory hog.

We have a relatively new method of
performing this reset that’s even
easier on everyone involved - and
you may have seen it mentioned in
the rather verbose output of show ip
bgp neighbor:
R1#show ip bgp neighbors
BGP neighbor is 15.1.1.5, remote AS 1235,
internal link
Member of peer-group POLICYOUT for
session parameters
BGP version 4, remote router ID 19.1.1.1
BGP state = Established, up for 00:01:26
Last read 00:00:25, hold time is 180,
keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and
received(new)

If you need to run a route refresh to
make a BGP command take effect,
you can run it with the clear ip bgp
in command. The actual words
“route refresh” aren’t mentioned in
the command.
R1#clear ip bgp * ?

in
ipv4
out
soft

Soft reconfig
inbound
update
Address
family
Soft reconfig
outbound
update
Soft reconfig

vpnv4

Address
family

<cr>
R1#clear ip bgp * in ?
<cr>

We’ve run a lot of show commands
in this section, but not much
debugging. Let me show you a few
basic debugs…
R1#debug ip bgp ?

A.B.C.D

BGP
neighbor
address
BGP

dampening
events
in
keepalives
out
updates

vpnv4

dampening

BGP
events
BGP
Inbound
informatio
BGP
keepalives
BGP
Outbound
informatio
BGP
updates
VPNv4
NLRI

informatio
<cr>
R1#debug ip bgp keepalives
BGP keepalives debugging is on
R1#
20:30:48:
BGP:
172.12.123.3
sending
KEEPALIVE (io)
20:30:48: BGP: 172.12.123.3 KEEPALIVE rcvd
20:30:49:
BGP:
172.12.123.2
sending
KEEPALIVE (io)
R1#debug ip bgp events
BGP events debugging is on

R1#clear ip bgp * soft
R1#
20:32:12: BGP(0): 1 updates (average = 56,
maximum = 56)
20:32:12: BGP(0): 15.1.1.5 updates replicated

for neighbors: 172.12.123.2 172.12.123.3
20:32:12: BGP: Import timer expired. Walking
from 1 to 1
R1#
R1#clear ip bgp * in
R1#
20:32:27: BGP: Import timer expired. Walking
from 1 to 1
R1#
R1#
R1#clear ip bgp *
R1#
20:32:34: BGP: reset all neighbors due to User
reset
20:32:34: BGP: 15.1.1.5 reset due to User reset
20:32:34: %BGP-5-ADJCHANGE: neighbor
15.1.1.5 Down User reset
20:32:34: BGP: 172.12.123.2 reset due to User
reset
20:32:34: %BGP-5-ADJCHANGE: neighbor
172.12.123.2 Down User reset
20:32:34: BGP: 172.12.123.3 reset due to User
reset

R1#
20:32:34: %BGP-5-ADJCHANGE: neighbor
172.12.123.3 Down User reset
R1#
20:32:42: BGP: Import timer expired. Walking
from 1 to 1
R1#u all
All possible debugging has been turned off

Recommended Video Viewing:
Troubleshooting
advertisements:

BGP

route

http://www.youtube.com/watch?
v=6d1P3GWLo_w
Configuring and

troubleshooting

BGP route summarization:
http://www.youtube.com/watch?
v=qKrJ14Hbdts
More BGP route aggregation:
http://www.youtube.com/watch?
v=80fGaebifHo
Video Practice Exam on BGP
attributes:
http://www.youtube.com/watch?
v=gMApy_pVctU

Video Practice Exam on BGP
fundamentals:
http://www.youtube.com/watch?
v=hkG2ZOvos8c
Free CCNP ROUTE Video Boot
Camp on route redistribution:
http://bit.ly/Arnhjq
My CCNP ROUTE Video Boot
Camp - Exclusive Discount Link
For My Ebook Readers Only!

Just click this link for a free hourlong preview AND $10 off the
already low price!
http://bit.ly/A7pLBu
Available for immediate download
and on DVD!

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

The Remote Workplace,
Part I: VPNs And IPSec

These days, it’s not enough to have
communication - we need secure
communication. Virtual Private
Networks (VPNs) are a great way
to secure these transmissions.
It’s the “private” part of VPNs that
brings us that security. Configuring
VPNs gives us the opportunity to
apply security to a connection that
is using a shared technology such as
Frame Relay - in other words, to

treat this connection as though it
were on a private network.
What’s A VPN?
VPNs are often referred to as
tunnels. We can apply security
rules and policies to this tunnel
without applying them to other
WAN communications.
For example, when we configure
commands directly on the Serial0
interface, all communications using
that interface are subject to those
commands.

When we create a VPN, it’s
actually seen as a separate interface
- you’ll see this when we configure
one - and we can apply rules to the
VPN that are not applied to other
communications using Serial0.
In the following exhibit, a VPN has
been created between two routers.
Security policies can be enforced
on the VPN between those two
routers without affecting any WAN
communications
involving the
bottom router.

There are some VPN terms that are
sometimes used interchangeably,
but they don’t refer to the same
feature. Let’s take a close look at
these terms.
VPNs offer three vital functions.
Note that two of these occur at the

receiver, and one at the sender.
Data origin authentication allows
the receiver to guarantee the source
of the packet.

Encryption is just that - the sender
encrypts the packets before sending
them. If an intruder picks them off
the wire, they will have no
meaning.

Integrity is the receiver’s ability to
ensure that the data was not affected
or altered in any fashion as it
traveled across the VPN.

There are three different protocols
we can use to create this tunnel.
Originally defined in RFC 1701,
Generic Routing Encapsulation
enables a Cisco router to
encapsulate a packet in an IP
header. When the packet reaches the
remote router, the header is stripped
off. GRE’s drawback is that there’s
no encryption scheme, and that’s a
pretty big drawback.
Defined in RFC 2661, The Layer 2
Tunneling Protocol (L2TP) is

actually a hybrid of Microsoft’s
Point-to-Point Tunneling Protocol
(PPTP) and Cisco’s own Layer 2
Forwarding (L2F). Again, the major
drawback is that L2TP doesn’t have
an encryption scheme.
This giant flaw is corrected by IP
Security, generally referred to as
IPSec. IPSec does offer encryption
along with authentication, and that’s
why you’ll see more IPSec in
today’s networks than L2TP or
GRE. That’s also why we’re going
to spend the majority of this section
working with IPSec.

VPN Terminology
Before we get to a more specific
discussion of VPNs, there are some
general terms you should know.
We’ll review the terms from the
beginning of this section as well.
Data Confidentiality means that
only the devices that should see the
data in an unencrypted form will
see the data that way. Generally,
this is achieved by one endpoint
encrypting the data and sending it
across the link in that fashion, with
the second endpoint unencrypting
the data.

Data Integrity means that the
recipient of the data can guarantee
that the received data is the same as
the transmitted data - in short, that
the data was not altered during
transport.
Data
Origin
Authentication
guarantees that the data originated
from a specific endpoint.
Anti-replay protection (sometimes
just called “replay protection”)
protects against replay attacks, a
malicious repeat and/or delay of a
valid transmission.

Replay attacks can begin innocently
enough. In this example, Router C
requests proof of identity from
Router A. Router A responds with
proof of identity.

The problem is, an Intruder is
listening to the conversation and
copies Router A’s proof of identity.

After A and C are done with their
conversation, the Intruder starts a
conversation with C, pretending to
be A. When C asks for proof of
identity, the Intruder submits A’s ID,
and C will accept it.

Anti-replay protection can use
several different methods of
defeating such an attack, including
the one-time use of tokens for the
proof of identity or by using
sequence numbers; a repeated
sequence number will be rejected.
Data Encryption Technologies
For data to be encrypted, it follows

that something’s got to perform this
encryption! One such encryption
tool is the Data Encryption
Standard (DES). DES was
developed in 1976, and just a few
security issues with networking
have popped up since then!
The main issue is that the key used
by DES to encrypt data is only 56
bits in size. (A key is a random
string of binary digits.) Thirty years
ago, that was fine, but then again
floppy disks used to be the largest
storage unit any of us needed!
Depending on which documentation
you read, DES keys can be broken

in any time frame from 24 hours to
ten minutes.
Triple DES (3DES) is just what it
sounds like - the DES encryption
procedure is run three times, with
three different 56-bit DES keys.
That’s a total of 168 bits, but the
effective security provided is
considered to be only 112 bits.
The
Advanced
Encryption
Standard (AES) is being rapidly
adopted by governments and
organizations around the world.
AES can run on any Cisco router
that
has
IPSec
DES/3DES

capability. The actual function of
AES is far beyond the scope of this
exam, but it really is quite
fascinating.
To me, anyway. If you’d like to take
a peek at how it works ….

http://en.wikipedia.org/wiki/Advance
Key Encryption Schemes
Symmetric encryption is an
algorithm where the key that is used
for encryption is also used for
decryption. Symmetric encryption is
sometimes called secret key

encryption.
Variations of symmetric encryption
include stream algorithms, where
one
bit
or
byte
is
encrypted/decrypted at a time, and
block algorithms, where blocks of
data are encrypted/decrypted as a
whole. These data blocks are
usually 64 bits in size. Both DES
and
3DES
use
symmetric
encryption.
The drawback to symmetric
encryption is that the key is used for
two purposes, making it that much
easier for an intruder to discover

the key.
In contrast, asymmetric encryption
involves two keys for both the
sender and receiver. This public
key encryption scheme involves a
public and private key for each
user. Before starting the actual
encryption process, the public key
should be certified by a third party
called a Certificate Authority (CA).
If “Dan” has a public key, the CA
will make sure Dan is who he says
he is, and the CA will then issue a
digital certificate saying just that.
The digital certificate is a

combination of Dan’s public key
and the CA’s private root key.
The CA may be global, such as
www.verisign.com, or it may be a
CA in your very own organization.
The key here (no pun intended) is
that you better trust your CA,
because the entire public key
encryption process is built around
the CA verifying users and their
public keys.

Now that the CA has verified Dan
and Bob, public key encryption can
be put into use. In this example, Dan
will send an email to Bob using
PKE. Dan will actually use Bob’s
public key to encrypt the message.
The email is then sent to Bob, who
will use his private key to deencrypt the email.

Exchanging Secret Keys Over A
Non-Secure Connection
It seems like quite a Catch-22; to
create the VPN, we need the
endpoints to exchange secret keys,
but since the VPN doesn’t exist yet,
the secret keys must be exchanged
over a non-secure connection! The
Diffie-Hellman algorithm allows
the exchange of secret keys over a
non-secure
communications
channel.
Referred to in some documentation
as exponential key agreement, this
protocol was also designed in 1976

- but it’s still in use today in
networks around the world.
The IPSec Architecture
IPSec is a combination of three
protocols:
Authentication Header (AH),
which defines a method for
authentication and securing
data
Encapsulating Security
Payload (ESP), which defines
a method for authenticating,
securing, and encrypting data

Internet Key Exchange (IKE),
which negotiates the security
parameters and authentication
keys

Defined
in
RFC
2402,
Authentication Header (AH) offers
solid security -- it provides data
origin authentication as well as
offering
optional
anti-replay

protection. The drawback with AH
is that the authentication it provides
for the IP Header is not complete.
That’s because some of the IP fields
can’t be correctly predicted by the
receiver - these are mutable fields
which
may
change
during
transmission. AH will successfully
protect the IP packet’s payload,
though, which is really what we’re
interested in.
To sum it up, AH does offer:
data origin authentication

data integrity
anti-replay
(optional)
AH
does
not
confidentiality.

protection
offer

data

The
Encapsulating
Security
Payload (ESP) does just that - as
you can see from the IPSec packet
illustration, there is an ESP Header
and ESP Trailer surrounding, or
encapsulating, the data. ESP offers
all of the following:
data origin authentication

anti-replay protection
data confidentiality
Comparing AH and ESP, you might
be wondering why you’d ever
choose AH over ESP. Here are a
few things to consider:
ESP is more processorintensive than AH. If your data
does not require data
confidentiality, AH may meet
all your requirements.
ESP requires strong
cryptography, which isn’t

available and/or allowed
everywhere. AH has no such
requirement.
Both ESP and AH can be run in one
of two modes - Tunnel Mode and
Transport Mode. In Tunnel mode,
the entire IPSec process is
transparent to the end hosts;
specialized IPSec gateway devices
handle the IPSec workload.
The tunnel mode process encrypts
the entire IP packet, and then that
encrypted packet is placed into
another
IP
packet.
That

encapsulating packet will have the
IP addresses configured on the
tunnel endpoints, and it’s those
tunnel IP addresses that will be
used to route the packet.
Transport mode encrypts the IP
payload, but the IPSec header is
inserted directly after the IP header
in the packet. As a result:
There is no protection for the
original IP address
The original IP address will
be used for routing
Only data from the Transport

layer up is protected by IPSec
(easy enough to remember!)
Configuring Site-to-Site IPSec
VPNs
Configuring a site-to-site VPN is
basically a five-step process.
Process Initialization via
“interesting
traffic”
(as
opposed
to
the
usual,
uninteresting kind)
IKE Phase 1 (IKE SA
negotiation)
IKE Phase 2 (IPSec SA

negotiation)
Data Transfer
Tunnel Termination
IPSec doesn’t just start working by
itself - it requires interesting
traffic to be sent by a host. This
interesting traffic initializes the
IPSec process. A crypto access-list
will define interesting traffic for
our VPN. We’ll configure one later
in this section.

The routers will now enter IKE
Phase I. Assuming we’re running
Main mode, there will be six
messages overall. The initiator will
first transmit proposals for the
encryption
and
authentication
schemes to be used. At this point,
IKE’s looking for an ISAKMP
policy that’s a match at both
endpoints.

In the second exchange of IKE
Phase I, the devices will exchange
Diffie-Hellman public keys; from
this point on, the rest of the
negotiation is encrypted.

The
initiator
and
recipient
authenticate each other in the third
exchange of Phase I, using an
encrypted form of their IP
addresses. The IKE SA is then
established and Phase II can begin.

(If we had chosen to run IKE in
Aggressive Mode, this would have
been a three-message process. )
The initiator packages everything
needed for the SA negotiation in the
first message, including its DiffieHellman public key.

The recipient responds with the
acceptable
parameters
and
authentication information, and its
Diffie-Hellman public key.
The initiator then sends a
confirmation that it received that
information, and we’re done!

IKE Phase 2 has one mode, Quick
mode. This is also a three-message
process. The initiator proposes
parameters for the IPSec SA, the
recipient responds with a list of
acceptable parameters, and the

initiator then transmits a message
that lets the responder know that
message 2 was received and
processed. This message is called
proof of liveness.

With the IPSec SA in place, the
hosts can now exchange data.

Once the data exchange is complete,
the tunnel can be torn down. This
tunnel
termination
can
be
configured to occur after a certain
number of bytes have passed
through the tunnel, or perhaps after
the tunnel has been up for a certain

number of seconds.
But what if traffic is flowing
through the tunnel at the same time
the tunnel’s supposed to be torn
down? No fear - a new Security
Association can be agreed upon
while the existing one is still in
place.
Creating An IKE Policy
Before configuring the IKE policy,
make sure ISAKMP is enabled with
the
crypto
isakmp
enable
command. It’s supposed to be on by

default, but we all know how that
is!
R1(config)#crypto isakmp enable

To display the current IKE policies,
run show crypto isakmp policy.
R1#show crypto isakmp policy

Global IKE
policy
Default
protection
suite
encryption
algorithm:
DES -

Data Encryption
Standard (56 bit
keys).

hash
algorithm:
authentication
method:
DiffieHellman
group:
lifetime:

Secure Hash
Standard
Rivest-ShamirAdleman Signature
#1 (768 bit)
86400 seconds, no
volume limit

We’re not going to use the default,
however. We’ll create a custom
policy with the crypto isakmp
policy command. Policies can be
assigned priorities, as shown below
by IOS Help. The lower the
number, the higher the priority, with

1 being the highest priority. There is
no default and this value cannot be
set to zero.
R1(config)#crypto isakmp policy ?
<1-10000> Priority of protection suite
R1(config)#crypto isakmp policy 100

IOS Help shows the options for the
IKE policy.

The options for authentication are
preshared keys, RSA Signature, and

RSA Encryption. The default is
RSA Signature. We’ll configure the
policy to use preshared keys.
R1(config-isakmp)#authentication ?

preshare
rsaencr

rsasig

Pre-Shared
Key
RivestShamirAdleman
Encryption
RivestShamirAdleman
Signature

R1(config-isakmp)#authentication pre-share

The options for encryption are
DES, AES, and 3DES (TDES). The
default is DES. We’ll use 3DES.
R1(config-isakmp)#encryption ?

3des

aes

des

Three key
triple DES
AES Advanced
Encryption
Standard.
ES - Data
Encryption
Standard (56
bit keys).

R1(config-isakmp)#encryption 3des

We do have options for the DiffieHellman group, so we’ll use group
5. The default is group 1.
R1(config-isakmp)#group ?

1
2
5

Diffie-Hellman
group 1
Diffie-Hellman
group 2
Diffie-Hellman
group 5

R1(config-isakmp)#group

The hash algorithm will be either
MD5 or SHA. The default is SHA,
so we’ll set the policy to MD5.

R1(config-isakmp)#hash ?
md5 Message Digest 5
sha Secure Hash Standard
R1(config-isakmp)#hash md5

Finally, we need to set the SA
lifetime. The default is the
maximum number of seconds,
86,400, which equals 24 hours.
We’ll set that to 42,400 seconds.
R1(config-isakmp)#lifetime ?
<60-86400> lifetime in seconds
R1(config-isakmp)#lifetime 42400

show crypto isakmp policy
displays both policies on the router

- the default and the one we just
wrote.

The exact same policy has been
configured on R3. R1 and R3 are on
the
same
Serial
segment,
172.12.12.0 /24, with their router
number as the last octet.
R3(config)#crypto isakmp policy 100
R3(config-isakmp)#hash md5
R3(config-isakmp)#lifetime 42400
R3(config-isakmp)#group 5

R3(config-isakmp)#authentication pre-share
R3(config-isakmp)#encryption 3des

When IKE Phase 1 negotiation
begins, the initiator sends its
policies to the receiver. The
receiver will then attempt to find a
match for that policy among its own
policies, and the receiver starts this
search with its lowest numbered
policy.
If that policy doesn’t match, the
receiver checks its next lowest
numbered policy. It’s vital to
remember that just because the first
policy comparison doesn’t result in
a match, the recipient will continue

to search for a match.
In the following example, R2
checks its own policies for a match
with the policy sent by the initiator,
R1. R2 begins with its lowestnumbered policy, 100. That policy
requires SHA and the incoming
policy names MD5, so there’s no
match.
R2 then checks its Policy 200,
which requires DES, and that does
not match the incoming policy.
Policy 300 matches all the
requirements, so the negotiation is
successful.

You’d think that all five values
would have to match for the
negotiation to be successful, but
that’s not quite true. Here’s a list of
the parameters and what has to
happen for successful negotiation.
Hash: exact match

Encryption: exact match
Authentication: exact match
DH Group number: exact
match
Lifetime: Remote peer policy
must have lifetime equal to or
less than initiator. If less, the
lower value is used.
Since our policies referred to
preshared keys, we better create
them! The crypto isakmp key
command does this. Along with the
key itself, the IP address of the
remote peer must be configured.
Watch

the

syntax

with

this

command, as it differs between IOS
versions. Not all versions have the
0 / 6 option you’ll see below on
R1. IOS Help shows that the
options are slightly different
between the IOS versions we’re
using. As a CCNP and world-class
Cisco engineer, this is something
you need to get used to. Trust me.

If Phase I is successful, an ISAKMP
SA will be created. We can verify
this with show crypto isakmp sa.

R3#

As always, if the output of a show
command shows nothing, there’s
nothing to show! The ISAKMP SA
doesn’t exist until the entire IPSec

configuration is in place and
interesting traffic has started the
process. That’s one frustrating thing
about IPSec - there’s a good deal of
configuration, but you really can’t
test it until the entire thing is done.
Configuring
Transform Sets

The

IPSec

An IPSec Transform Set is simply a
group of individual parameters that
will enforce a security policy. The
endpoints must agree exactly on
which encryption and algorithms
will be used to create the IPSec SA.
If there’s an exact match, the IPSec

process continues; if there’s no
match, the process is terminated and
the session torn down.
As with ISAKMP policies, multiple
transform sets can be configured
and sent to a remote peer. The
remote peer will compare each set
received against its own transform
sets, and when a match is found, the
IPSec SA will be built.
A transform set is built with the
crypto
ipsec
transform-set
command, as shown here on R3.
Options are shown with IOS Help,
and then the exact same transform

set is configured on R1.

IPSec SA Lifetimes
The default lifetime of an IPSec SA
is 1 hour, but IOS Help reveals that
the command that changes this value
on a global basis sets the IPSec SA

lifetime in seconds. Always use IOS
Help
to
double-check
the
measuring unit in use by any given
command. The below command
sets this value to 30 minutes (1800
seconds). The SA lifetime can also
be based on volume.

Crypto Access Lists
Remember way back when I
mentioned that interesting traffic
triggers the IPSec process? We’re
finally getting to the part of IPSec
that identifies this interesting traffic

- crypto access lists.
Crypto ACLs are used to define the
traffic that is protected by IPSec.
While most of the Crypto ACLs you
write will be configured to affect
outbound traffic, they can also be
configured to affect inbound traffic.
Outbound crypto ACLs identify the
traffic to be secured by IPSec, and
traffic not named by the crypto ACL
will be sent in clear text.

Inbound crypto ACLs identify
traffic that should have been
protected by IPSec, but wasn’t.
Such traffic will be discarded.

Extended ACLs can serve as Crypto
ACLs, but there’s a major
difference in operation between the
two.
With
traffic
traffic
deny).
traffic
traffic

Extended ACLs, matched
is permitted and unmatched
denied (by the implicit
With Crypto ACLs, matched
is encrypted and unmatched
is unencrypted but still

transmitted.
If inbound Crypto ACLs are
configured, unprotected traffic that
matches the ACL is dropped simply because it’s unprotected.
The trickiest part of writing Crypto
ACLs for IPSec peers is making
sure they’re symmetrical rather than
identical.
Let’s use the following network to
show you what I mean.

To have traffic on R1’s ethernet
segment protected by IPSec if it’s
destined for the ethernet segment on
R2, R1’s ACL will look like this:
access-list 123 permit ip 172.10.1.0 0.0.0.255
172.10.5.0 0.0.0.255

For traffic on R2’s ethernet segment
to be protected by IPSec if it’s
destined for the ethernet segment on
R1, R2’s ACL will look like this:

access-list 123 permit ip 172.10.5.0 0.0.0.255
172.10.1.0 0.0.0.255

When you’re configuring IPSec and
concentrating on the many details
we’ve discussed in this chapter, it’s
really easy to think “Hey, I’ll just
write the ACL on one router and
then copy and paste it to the other.”
Always double-check your ACLs if they’re identical, there is a
problem.
We don’t want the two ACLs to be
an exact copy of each other - rather,
we need them to be mirror images,
exact reverses of each other.

Once the Crypto ACLs are written,
it’s time to apply them to the
appropriate interfaces. That’s just
one purpose of a Crypto Map. Let’s
look at the basic command to write
a Crypto Map along with some
options, courtesy of IOS Help.
R3(config)#crypto map CCNP ?

<165535>

client

Sequence to
insert into
crypto map
entry
Specify
client
configuration
settings

isakmp

isakmpprofile

localaddress

Specify
isakmp
configuration
settings
Specify
isakmp
profile to
use
Interface to
use for local
address for
this crypto
map

R3(config)#crypto map CCNP 100 ?

ipsecisakmp

IPSEC
w/ISAKMP

ipsecmanual

IPSEC
w/manual
keying

<cr>
R3(config)#crypto map CCNP 100 ipsec-isakmp
?

dynamic

profile

<cr>

Enable
dynamic
crypto map
support
Enable
crypto map
as a
cryptoprofile

R3(config)#crypto map CCNP 100 ipsec-isakmp
R3(config-crypto-map)#

We’ve successfully created a crypto
map named CCNP, sequence
number 100, that will use ISAKMP
to establish the IPSec Security
Associations. We’re now in crypto
map configuration mode, where the
ACL, peers, transform sets, and
security association lifetime for this
particular crypto map can be set.
Any SA lifetime value configured
here overrides the globally
configured value, but we’ll leave
that value alone for now.

R1(config)#crypto map CCNP 100 ipsec-isakmp

This new crypto map will
remain disabled until a
%
peer and a valid access
NOTE: list have been
configured.
R1(config-crypto-map)#match address 123
R1(config-crypto-map)#set peer 172.12.123.2
R1(config-crypto-map)#set
transform-set
R1_TRANSFORM_SET

R1(config-crypto-map)#interface serial 0/1
R1(config-if)#crypto map CCNP
R1(config-if)#
*Apr
1
17:27:04.807:
%CRYPTO-6ISAKMP_ON_OFF: ISAKMP is ON

R3(config)#crypto map CCNP 100 ipsec-isakmp
R3(config-crypto-map)#match address 123
R3(config-crypto-map)#set peer 172.12.12.1
R3(config-crypto-map)#set
transform-set
R3_TRANSFORM_SET
R3(config-crypto-map)#set security-association
lifetime ?
kilobytes Volume-based key duration
seconds Time-based key duration
R3(config)#int s0/1
R3(config-if)#crypto map CCNP
R3(config-if)#
*Mar
1
04:10:12.260:
%CRYPTO-6ISAKMP_ON_OFF: ISAKMP is ON

Before sending interesting traffic to
start the entire process, we’ll
enable debug crypto ipsec on R3 to
allow us to see the details of the SA
negotiations. Near the bottom of the

debug output, you can see that two
separate unidirectional SAs have
been built.
R3#debug crypto ipsec
Crypto IPSEC debugging is on
R3#ping 172.12.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.12.1,
timeout is 2 seconds:
*Jun 6 23:51:14.999: IPSEC(sa_request):,
(key eng. msg.) OUTBOUND local=
172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac
(Tunnel),
lifedur= 1800s and 4608000kb,
spi= 0x91791CF(152539599), conn_id= 0,
keysize= 0, flags= 0x400A.
*Jun
6
23:51:17.579:

IPSEC(validate_proposal_request):
proposal part #1,
(key eng. msg.) INBOUND local=
172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac
(Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0,
flags= 0x2
*Jun 6 23:51:17.583: Crypto mapdb :
proxy_match
src addr : 172.12.12.3
dst addr : 172.12.12.1
protocol : 0
src port
: 0
dst port
: 0
*Jun 6 23:51:17.591: IPSEC(key_engine): got a
queue event with 2 kei messages
*Jun 6 23:51:17.591: IPSEC(initialize_sas):,
(key eng. msg.) INBOUND local=
172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac
(Tunnel),

lifedur= 1800s and 4608000kb,
spi= 0x91791CF(152539599).!!!
Success rate is 60 percent (3/5), round-trip
min/avg/max = 48/49/52 ms
R2#, conn_id= 0, keysize= 0, flags= 0x2
*Jun 6 23:51:17.591: IPSEC(initialize_sas):,
(key eng. msg.) OUTBOUND local=
172.12.12.3, remote= 172.12.12.1,
protocol= AH, transform= ah-md5-hmac
(Tunnel),
lifedur= 1800s and 4608000kb,
spi= 0x945FCBB6(2489306038), conn_id=
0, keysize= 0, flags= 0xA
*Jun 6 23:51:17.595: Crypto mapdb :
proxy_match
src addr : 172.12.12.3
dst addr : 172.12.12.1
protocol : 0
src port : 0
dst port : 0
*Jun
6
23:51:17.595:
IPSEC(crypto_ipsec_sa_find_ident_head):
reconnecting with the same proxies and

172.12.12.1
*Jun 6 23:51:17.595: IPSec: Flow_switching
Allocated flow for sibling 80000002
*Jun
6
23:51:17.595:
IPSEC(policy_db_add_ident): src 172.12.12.3,
dest 172.12.
12.1, dest_port 0
*Jun 6 23:51:17.599: IPSEC(create_sa): sa
created,
(sa) sa_dest= 172.12.12.3, sa_proto= 51,
sa_sp
i= 0x91791CF(152539599),
sa_trans= ah-md5-hmac, sa_conn_id=
2001
*Jun 6 23:51:17.599: IPSEC(create_sa): sa
created,
(sa) sa_dest= 172.12.12.1, sa_proto= 51,
sa_spi= 0x945FCBB6(2489306038),
sa_trans= ah-md5-hmac, sa_conn_id=
2002

By running show crypto isakmp sa,
we can see that the SA is in place
and is active… and at last, active is
what we want to see!

QM_IDLE is what we do want to
see; here are a few other potential
messages we don’t want to see,
along with a quick explanation of
each courtesy of Cisco’s website.
A common error message is
MM_NO_STATE, and if you think
that sounds bad, you’re right! This
indicates a fundamental problem

with Phase I, most likely a
mismatch of attributes between
peers.
MM_KEY_EXCH can indicate a
misconfiguration of the peer’s IP
address, and this message can also
be generated by a misconfigured
pre-shared key.
Two
other
excellent
IPSec
troubleshooting commands are
show crypto map and show crypto
ipsec transform-set.

Transform set R2_TRANSFORM_SET: { ahmd5-hmac }
will negotiate = { Tunnel, },

To let you see what the IPSec
process looks like when the SA
expires, I left the debug running
until the one we built in this chapter
expired.
*Jun 7 00:48:18.270: IPSEC(lifetime_expiry): SA
lifetime threshold reached, exp
iring in 111 seconds

*Jun 7 00:50:10.074: IPSEC(key_engine): got a
queue event with 1 kei messages
*Jun
7
00:50:10.074:
IPSEC(key_engine_delete_sas):
rec’d
delete notify from ISA
KMP
*Jun
7
00:50:10.078:
IPSEC(key_engine_delete_sas): delete SA
with spi 0x877193D
*Jun 7 00:50:10.086: IPSEC(delete_sa):
deleting SA,
sa_spi= 0xF8BA8F2(260810994),
sa_trans= ah-md5-hmac, sa_conn_id=
2003,
*Jun 7 00:50:10.086: IPSEC(delete_sa): deleting
SA
sa_spi= 0x877193DD(2272367581),
sa_trans= ah-md5-hmac,
sa_conn_id= 2004,
(identity) local= 172.12.123.2, remote=

172.12.123.1,
*Jun 7 00:50:10.090: IPSec: Flow_switching
Deallocated flow for sibling 8000000

A Warning About ACLs And
IPSec
As you work with more complex
combinations
of
Cisco
technologies, you’re going to have
to be very careful with your access
lists. You should especially be
careful with port ranges in ACLs,
because you can always block ports
that are needed by network services
or applications.
This is particularly true with IPSec,

because three primary IPSec
protocols use ports that must not be
blocked by ACLs:
ESP, protocol number 50
AH, protocol number 51
IKE, UDP port 500
Make sure your network’s ACLs
are not inadvertently blocking these
ports and protocol numbers
anywhere you have IPSec running.
To review, here’s the process we
used to create this site-to-site IPSec
VPN:

Created the ISAKMP policy
Created the IPSec transform
set
Defined interesting traffic with
the crypto access-list
Created the crypto map - AND
applied it to the proper
interface
Made sure our ACLs allowed
the appropriate port numbers
The Return Of GRE
The
Generic
Routing
Encapsulation (GRE) tunneling has

actually made a comeback, since
GRE can do things that IPSec can’t
do, and vice versa.
We
used
to
love
GRE’s
multiprotocol capabilities, but
that’s not as important to us in
today’s networks as it once was.
Combined with a lack of strong
security features, GRE was pretty
much dead for quite a while.
IPSec is very secure, but it does
have drawbacks. Originally, IPSec
couldn’t carry multicast traffic, and
you may still run into some trouble
with that in the field - the first IOS

release that allowed IPSec to carry
multicast traffic was 12.2(4)T, and
there are plenty of routers out there
running an earlier IOS.
The latest IOS versions can’t
handle all multicast traffic,
however.
Multicast
traffic
generated by OSPF and EIGRP
can’t be carried by basic IPSec we’ve got to run a combination of
IPSec and GRE, commonly called
GRE over IPSec.
By combining GRE and IPSec, each
protocol helps to compensate for
the other’s limitation:

IPSec adds data integrity and
confidentiality that GRE does
not offer
GRE offers the ability to carry
routing protocol traffic, which
IPSec does not offer
Why call it “GRE over IPSec”
rather than “IPSec over GRE”?
Because the GRE encapsulation
happens first, and then that
encapsulation is
encapsulated
again, by IPSec. In effect, we have
a GRE tunnel inside an IPSec
tunnel.

Our old friends tunnel mode and
transport mode are still around as
well. Interestingly enough, Cisco’s
website recommends the use of
transport mode over tunnel mode
with GRE over IPSec. Using
transport mode results in less total
overhead, and we’re all in favor of
that!
To review Just as with a site-to-site VPN,
the crypto ACL indicates the
traffic to be encrypted

GRE over IPSec allows the
transmission
of
dynamic
routing protocol multicast
traffic
Whether you use the CLI or
SDM, always make sure to
apply the crypto map to the
interface!
Hey, that’s enough talking about
GRE over IPSec. Let’s configure it
with SDM - the Security Device
Manager.
NOTE: SDM has actually been
phased out by Cisco, but since many
CCNP candidates haven’t seen a

Cisco GUI, I want you to see one
here.
Configuring A GRE Tunnel Over
IPSec Via SDM (PDQ)
As always, we’ll start by clicking
the Configure button, and from
there choose VPN.

From the main VPN window, we’ll
select Site-to-Site VPN. The Siteto-Site VPN window gives us two
main choices:

When I choose the GRE over IPSec
option, this illustration is shown.

After clicking Launch the selected
task, we’re given some reminders
of why we’re using GRE - good
review material for your exam, too!

The next screen asks us for some
required
GRE-over-IPSec
information, namely the tunnel
source and destination and the

address of the tunnel itself. Note
that for the source, we can specify
either the interface or the IP
address, where the only option for
destination is the IP address.

Did you notice the Details button in
the previous screen? Clicking that
gives you quite a bit of information
regarding that interface. We don’t
have any of these features on this
interface, but if we did, it’s good

information to have in mind for the
tunnel config.

Now back to the config! We’re not
going to create a backup tunnel, but
the next screen gives us the option
to do so.

The next window prompts us for the
pre-shared key or to indicate the
use of digital certificates.

The next window is the IKE
Proposal selection area, and we’ll
accept the default IKE policy.

The next window is the Transform
Set selection area, and we’ll accept
the default there as well.

We’re then prompted to identify the
routing protocol that will run over
the tunnel.

Earlier in this section, we had the
opportunity to create a backup
tunnel. If you’re running a routing
protocol over the tunnels, you may
need to alter some metrics so that
one tunnel is preferred over the
other.
For EIGRP, for example, I’d
suggest working with the delay

option rather than the other metrics
as it’s easier to get the result you
want. With static routing, you could
alter the AD of the routes with the
distance option.
We now have the option of
tunneling all traffic, or using Split
Tunneling to send select traffic
through the tunnel. We’ll enable ST
here and configure traffic destined
for 10.0.0.0 /8 to use the tunnel.

Real-world note: By default, using
Split Tunneling with NAT and PAT
on the same router can cause
problems. Cisco’s website offers
several solutions to this issue,
should you run into that problem in
the real world.
As always, we’re presented with a
Summary of the configuration

we’ve chosen.

At this point, the VPN is down,
since we haven’t configured the
other side of it!

We need an exact reverse of this
configuration - a mirror image - to
place on the downstream router.
SDM has a great tool to create this
mirror at the verrrrrry bottom of the
screen - the Generate Mirror
button!
Real-world note: If you can’t find
something in SDM, always look at
the very bottom of the screen.

After clicking Generate Mirror, we
get that mirror configuration, along
with warnings about how this
config should be used only as a
guide and should not be pasted into
the remote router.

Since we’re in a lab environment,
I’m going to do just what they told
me not to do, and save this config
and then paste it into the
downstream router.
Here’s the mirror configuration:

crypto isakmp policy 1
authentication pre-share
encr 3des
hash sha
group 2
lifetime 86400 exit
crypto isakmp key secretkey address 172.31.1.1
crypto ipsec transform-set ESP-3DES-SHA
esp-sha-hmac esp-3des
mode tunnel
exit
ip access-list extended SDM_1
remark SDM_ACL Category=4
permit gre host 10.2.1.2 host 172.31.1.1
exit
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Apply the crypto map on the peer
router’s interface having IP
address 10.2.1.2 that connects to this router.
set transform-set ESP-3DES-SHA
set peer 172.31.1.1

match address SDM_1
set security-association lifetime seconds 3600
set security-association lifetime kilobytes
4608000 exit

After copying that config to the
downstream router, I applied that
crypto map to the physical interface
and created a tunnel interface
manually:
interface Tunnel0
ip address 10.1.1.2 255.255.255.0 ip mtu 1420
tunnel source FastEthernet0/1
tunnel destination 10.2.1.1

Going back to the original router,
the Edit Site-to-Site VPN screen
shows the VPN is now up.

What’s So “Easy” About Easy
VPN?
Easy VPN
following:

consists

of

the

Easy VPN Server
Easy VPN Remote
Sounds easy enough! Seriously, the
real benefit of Easy VPN is that
security policies written at the

Server level can then be pushed out
to Clients. As a result, the Clients
have the most up-to-date policies
without the network admins - that’s
you and me - having to visit them
individually.
Quite a few different Cisco devices
can act as Easy VPN Servers. I will
not list each here, but here are the
more common ones:

VPN 3000 concentrators
Cisco
7500,7200,7100,3600,2600,170
routers w/ 12.2(8)T IOS

Many Cisco 800 series routers
running 12.2(8)T or later
The Easy VPN Remote device can
be a Cisco router, PIX, or VPN
concentrator as well. “Easy VPN
Remote” devices are often referred
to as “Easy VPN Clients”, and
that’s how I’ll refer to them for the
rest of this video. For your exam
and
when
reading
Cisco
documentation, remember that
“Remote” and “Client” refer to the
same device.
The basics of the VPN construction
will look familiar at this point!

First, the Client will send ISAKMP
proposals to the Server, and the
Server
responds
with
the
acceptance of a matching proposal.
After the policy acceptance, the
ISAKMP SA is in place.

The next step is a little different
from what we’ve seen in other
VPNs. The Server will now send a
challenge to the Client, prompting

the Client to send a username and
password to the Server.

We can use several methods to set
up this authentication:
Local
(using
the
username/password command)
RADIUS
TACACS

Xauth
Authentication)

(Extended

We’ll take a closer look at RADIUS
and TACACS in another section,
but keep in mind that we can use
these security protocols in addition
to local authentication.
Once the Client has successfully
authenticated, the process enters
Mode configuration. At this stage,
the Client requests the necessary
configuration details from the
Server.

This information can include:
IP
address
information
(required)
internal DNS and WINS
server addresses
split tunneling configuration
information

Split tunneling allows the Client to
have a secure tunnel to the Server
and
simultaneous
non-secure
connections to other networks.
Once Mode configuration is
completed, the Reverse Route
Injection stage begins. According
to Cisco’s website, “Reverse route
injection (RRI) is the ability for
static routes to be automatically
inserted into the routing process
for those networks and hosts
protected by a remote tunnel
endpoint”.
After RRI, we’re almost there!

IPSec Quick Mode then negotiates
the IPSec SA, and we’re all set.
Configuring Easy VPN Server In
SDM
We’ll start our Easy VPN server
config by clicking the VPN button in
the Configure section of SDM.

You’ll see a list of topics under
“VPN”, and we’ll select Easy VPN
Server.

The description screen shows the
following. Note the prerequisite
task.

There’s a link to enable AAA on
that screen, so I’ll click that. Note
that the Enable Easy VPN button is
grayed out since AAA is not yet
enabled.

After clicking the enable AAA link,
we’re presented with this message:

We do want to enable AAA, so
we’ll click Yes and move on.

Once the AAA commands are
delivered, we can enable Easy VPN
Server.

Welcome to the Easy VPN Server
Wizard! Good exam review
material on this screen as well!

Here’s the next window:

The interface facing the workstation
is Fast 0/0, so I’ll choose that in the
drop-down box. We’ll use preshared keys as well, but you see
that we can use keys, digital
certificates, or both. After making
those selections, the next window

asks us for the IKE proposal. We
could create custom policies by
clicking Add, but here we’ll use the
default.

The Transform Set selection
window is next, and we’ll accept
the default there as well.

The next window prompts us for the
group authorization method, and
we’ll use local authentication only.

I like the summary description here.
Actually, if you don’t have a
RADIUS or TACACS server in
your network, the local database is
the only option you have!

In the next window, we’ll indicate
local authentication for users.

In the next window, we’ll click Add
since a group has not yet been
created.

The Add Group Policy window
opens to the following tab, and you
can see the information I entered for
yourself. Note the pre-shared key
appears as a series of asterisks.

We’ll enable Split Tunneling, which
is disabled by default. When I
clicked that check box, the Enter
the protected subnets selection
window enabled. I’ll click Add and

enter the 10.0.0.0 network with a
wildcard mask of 0.255.255.255.

The policy has been added.

At the bottom of this screen, note

that you can specify an idle timer
for the tunnel.

Finally, we’re presented with the
Summary window.

After clicking Finish at the bottom
of that screen, the commands are
delivered to the router, and the Easy
VPN
Server
side
of the
configuration is complete!
Configuring The Easy VPN Client

Now to the workstation! I’ll launch
the Cisco VPN Client and click
New.

I’ll enter the IP address of the Easy
VPN Server, along with the group
name and password (which again
appears only as a series of
asterisks).
Group Authentication is selected

by default. We’re not going to
configure
Mutual
Group
Authentication, but if we chose that
option, we’d need to import a valid
root certificate.

Now the HQ connection appears
under Connection Entry. I’ll click
Connect, and we’ll be prompted for
a username / password combination
that I configured before the lab

began.

The connection is then completed!
Note that a lock now appears next
to the HQ connection, the message
Connected to HQ appears in the
bottom left of the window, and the
overall connection time appears in
the bottom right of the window.

You can also test the connection
from the Server side. Go to the Edit
Easy VPN Server screen….

.. and at the very bottom of the

screen, select Test Easy VPN
Server.

Click Start in the Troubleshooting
VPN screen, and you’ll get check
marks when all is well. If
something isn’t well, you’ll get
some great information on the issue
here. This is the first place I check
when a VPN configuration isn’t
working correctly.

You’ll also receive the following
confirmation that all is well.

Let’s look at an SDM screen we

haven’t visited yet - the Monitor
screen. Just click the Monitor
button at the top of SDM, and
you’re there.

This screen has buttons on the lefthand side as well. Naturally, we’ll
select VPN Status.

The IPSec Tunnels tab verifies that
the tunnel is up.

The Easy VPN Server tab verifies it
as well, along with the number of
encrypted and decrypted packets.

The IKE SA tab shows the SA is in
QM_IDLE mode, which is just what
we want!

Other Easy VPN Options

In the Easy VPN Client software,
you’ll see an option for transparent
tunneling. When you have a router
serving as a firewall that also
happens to be between the Easy
VPN Client and Server, you’ll want
to enable this option.
Why? That gateway is likely
running NAT and/or PAT, and that
can be a problem for Easy VPN.
Enabling transparent tunneling
enables us to work around potential
issues with NAT and PAT.
On the same tab in SDM, you’ll see
an option to Allow Local LAN

Access. If this is enabled on both
the Server and Client, access to
local network files, printers, and
other resources is allowed without
going through the tunnel.
A Note About NAT
Easy VPN Client does support NAT
and PAT, but with a twist.
According to Cisco documentation,
Client will autoconfigure the
necessary NAT and PAT commands
and access-lists; the admin only
needs to configure our old friends
ip nat inside and ip nat outside.

So what’s the catch? Actually, there
are two of them:
The autoconfigured NAT, PAT,
and access-list commands will
not appear in the starting and
running
configurations.
Thankfully, you can see them
with the show access-list and
show ip nat
statistics
commands.
You must remove any preexisting NAT and PAT
configuration
before
configuring Easy VPN Remote.

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

The Remote Workplace,
Part II

Whether they’re working from a
“spoke office” or “branch office”,
or from non-fixed locations on the
road, the ever-increasing number of
mobile workers poses a real
challenge for today’s network
admins.
And that’s us!
A few of those challenges….

Providing enough bandwidth
for the workers to get their
jobs done in an efficient
manner
Security, security, security
(addressed in Part 1)
Integrating the mobile users’
operating systems and
applications with those used at
HQ
Let’s take a look at that first
challenge - and at broadband.

Dialup connections are pretty much
a thing of the past for today’s
mobile
workers,
thanks
to
broadband.
We know that broadband brings us a
lot more speed than the dialup
connections used to, and if you’ve
ever paid a hotel bill where the
dialup connection has been used
even a little - well, suffice to say
that broadband helps bring our
overall costs down as well.
Upstream, Downstream
For terms of our discussion and

your Cisco exams, upstream traffic
is traffic going from a host device
to the cable company and/or ISP,
and downstream traffic is traffic
going from the ISP to the host
device.
Broadband Delivery Options
The most common broadband
delivery method in use today is the
good old cable modem. The end
user’s connection is carried through
a preexisting cable TV connection,
enabling many cable companies to
offer “do-it-yourself” broadband
connectivity kits. (I notice those

aren’t as popular as they used to
be.)
Ever notice how the lights on the
front of a typical cable modem flash
quite a bit on startup, but some of
them become solid green (we hope)
? That’s because when a cable
modem is powered on or reloaded,
it begins to look for a signal from
the service provider as it boots up.
When that signal is found, the cable
modem synchronizes its timing with
the downstream provider device,
and the connection procedure
continues from there.

The potential drawback is that the
end user is sharing bandwidth with
a lot of other users, which can be a
problem if the provider doesn’t
have enough bandwidth to go
around.
The end user can simultaneously
access the Internet while watching
cable television due to the Data
Over Cable Service Interface
Specification (DOCSIS) standards.
Courtesy of wikipedia, here’s what
DOCSIS is all about:
“Data Over Cable Service
Interface Specification is an

international
telecommunications standard
that permits the addition of
high-speed data transfer to an
existing Cable TV (CATV)
system. It is employed by many
cable television operators to
provide Internet access over
their existing hybrid fiber
coaxial (HFC) infrastructure.
By using the specific bandwidths
outlined by DOCSIS, the same
cable can be used to deliver cable
television service, transmit data to
the client, and receive data from the

client simultaneously.
Our friends at the cable company
use one of three sets of modulation
standards:
National Television Standards
Committee (NTSC) is used in
primarily in North American
and Japan.
Phase Alternating Line (PAL)
is
used,
well,
almost
everywhere else.
Sequential Color Memory
(SECAM) is used primarily in
France, Africa, and Eastern

Europe.
One step up from the cable modem,
we have Digital Subscriber Line,
or DSL. DSL uses a preexisting
phone line for broadband delivery.
There are several different kinds of
DSL, though…
Asymmetrical DSL (ADSL) works
under the assumption that the user
will download more information
than they send, and for the average
Internet user, that’s a safe
assumption. The connection speed
from the provider to the user is
going to be 3 - 4 times faster than

the speed from the user to the
provider.
For example, an ADSL connection
of 512 kbps will give the user 384
KBPS download capabilities, but
only 128 kbps uploading capability.
ADSL actually offers download
speeds of up to 8 mbps and upload
speeds of up to 1 mbps or 1.5 mbps
depending
on
whose
sales
propaganda you’re reading.
Regardless of the sales department,
though, ADSL is susceptible to that
18,000-feet distance limitation.

The Original High Data-Rate
DSL (HDSL) has the capability to
deliver T1 (1.544 MBPS) or E1
(2.048 MBPS) speed over copper,
and this service is symmetrical - the
download and upload capabilities
are the same. Unlike ADSL, you
cannot use the phone while you’re
using the HDSL connection.
Second-generation HDSL (HDSL2)
does allow for Voice Over IP
(VOIP) and video to be carried
along with data.
Rate-Adaptive DSL (RADSL) is
just what it sounds like - the

software calculates the maximum
download and upload speeds on the
customer’s preexisting phone line
and dynamically adjusts those rates.
G.SHDSL provides symmetric
tranmission for upstream and
downstream data rates of anywhere
from 192 kbps to 2.3 MBPS.
Estimates of G.SHDSL’s maximum
distance range from 20,000 feet to
28,000 feet, depending on whose
documentation you’re reading.
Anyone who lives or has lived in a
rural area knows the challenge of
trying to get a broadband

connection. Satellite Broadband
certainly sounds like a technology
that could meet that challenge, and
theoretically it does just that.
Satellite broadband is more
reliable than it used to be - much
more reliable - but your
connectivity can still be affected by
the weather.
DSL Drawbacks
As mentioned earlier, there is an
18,000-foot limitation on DSL
services. However, attenuation the gradual weakening of a signal -

occurs before the actual distance
limitation is reached.
A bad splice or overall corrosion
can lead to an impedance mismatch.
As with attenuation, the signal isn’t
totally lost, but it is degraded.
Those impedance mismatches can
be introduced by using wires with
different
wire
gauges.
The
American wire gauge (sometimes
called the Brown & Sharp wire
gauge, according to Wikipedia)
refers to a standardized system of
measuring wire and cable thickness.
Signal interference can come from

“inside” and “outside” our network
as well. The “inside” interference
can result from crosstalk, the result
of a signal “crossing over” and
interfering with another signal.
The “outside” source, I kid you not,
is AM radio. Certain AM
frequencies can interfere with the
DSL signals.
Data Transport Over ATM
There’s an unusual type of
Asynchronous
Transfer
Mode
(ATM) switch as use in this type of
network, a DSLAM. DSLAMs are

just ATM switches with DSL cards
in them.
Nothing to it, right? :) It’s not as
complex as it seems.
When it comes to transporting data
over this setup, we’ve got three
choices:
PPP over Ethernet (PPPoE)
PPP over ATM (PPPoA)
RFC 1483/2684 Bridging
RFC 1483 Bridging has some
advantages and some serious
drawbacks.

Advantages:
Easy to set up, install, and
configure
Offers multiprotocol support
Excellent for
single-user
environments
Disadvantages:
Uses a lot of broadcasts,
which can quickly use most or
all available bandwidth.
Not a scalable solution.
Wide open to intruder attacks,
including ARP spoofing, IP

address
hijacking,
broadcast attacks

and

Other than that, Mrs. Lincoln, how
did you enjoy the play?
More likely, you’ll use Point-toPoint Protocol over Ethernet
(PPPoE). Defined in RFC 2516,
this process involves bridging an
Ethernet frame from the host PC to
an aggregation router such as the
Cisco 6400 series.
However, the Ethernet frame will
actually contain a PPP frame,
enabling a PPP session to be built

between the host device and the
aggregation router. While the PAP /
CHAP PPP option is there, CHAP
will typically be used due to its
encryption options.
There
are
actually
two
encapsulations taking place. First,
the host data is placed into a PPP
frame, and then that PPP frame is
placed into an Ethernet frame.
Finally, the “frame inside a frame”
is ready to transmit.

At the very beginning of the PPPoE
process, the host device will
perform Discovery - and what the
host needs to discover is the MAC

address of the PPPoE server. That
server will be the aggregation
router. This establishes the clientserver relationship, identified by a
PPPoE SESSION_ID value. Once
Discovery has concluded, the PPP
process can continue as it normally
would over an ISDN link.
Configuring PPPoE
Here’s the network we’ll be
working with in the following
section. We’ll assume the interface
closest to the PCs is Ethernet1, and
the interface facing the DSLAM is
Ethernet0.

Cisco 800 Router:
Ethernet interface facing the hosts
(Ethernet1)
int e1
ip address 172.1.1.1 255.255.255.0

Ethernet interface
DSLAM (Ethernet 0)

facing

the

int e0
no ip address
pppoe enable
pppoe-client dial-pool-number 1

For you ISDN fans (and non-fans),
the dial-pool-number command
sounds like it links to a dialer
profile. The pppoe-client dialpool-number statement binds the
physical interface - in this case, the
Ethernet0 interface - to the dialer
interface.
Here’s a typical dialer profile,
along with the necessary access-list

and dialer-list statements.
access-list 1 permit 172.1.1.0 0.0.0.255
dialer-list 1 protocol ip permit
interface Dialer1
ip address negotiated
ip mtu 1492 (required for PPPoE
configuration; must be placed on dialer
interface)
dialer pool 1
encapsulation ppp
ppp authentication pap
ppp pap sent-username CCNP password
ISCW

I configured PAP here, but
remember
that
PAP
sends
passwords in clear text. I
personally prefer to use CHAP,
which sends a hash result rather
than a clear-text password.
Those first two commands may be
new to you:
ip address negotiated - This allows
this interface to obtain its address
during PPP address negotiation.
Another command you may see
there is ip address dhcp command
allows an interface to acquire an

address via DHCP.
ip mtu 1492 - Due to the additional
overhead associated with PPPoE,
the MTU should be reduced to
1492. The overhead results from the
PPPoE header (6 octets) and the
PPP Protocol ID (2 octets).
Why A Static Route?
We spend time in both the OSPF
and EIGRP sections talking about
stub areas, and how they really just
need a single default route in many
cases.

A home worker is the ultimate stub
area - when the router receives the
data from the subscriber, there’s
only one possible exit interface for
it to use, and that’s the dialer
profile on the way back to HQ.
There’s no need to run a routing
protocol, since the exit interface
will remain the same and we’ll
have the additional overhead
associated with a dynamic protocol.
Instead, just write a default static
route using the dialer profile
interface as the local exit interface.
ip route 0.0.0.0 0.0.0.0 interface dialer0

You also learned all about NAT and
PAT during your CCNA studies, and
we’re going to configure PAT here
as well. The commands are the
same as the ones you learned during
your NA studies, but watch where
you put the ip nat inside and ip nat
outside commands!
ip nat inside source list 1 interface dialer 1
overload
int e1
ip nat inside
int dialer0
ip nat outside

As you know, the overload option
enables PAT, allowing us to use a
single routable IP address for
multiple inside hosts. Also note that
while the ip nat inside command is
configured where we’d expect it, on
the inside physical interface, the ip
nat outside command is applied on
the dialer profile.
If you like, you can also configure
DHCP on this router, and allow it to
serve as the DHCP server for the
inside hosts. Configuring a Cisco
router as a DHCP server offers too
many options to see them all here,
but let’s assume we want to assign

addresses from the network
172.1.1.0 /24, but no addresses
with the last octet of 1 - 100. Also,
we’ll assign a 30-day lease.
ip dhcp excluded-address 172.1.1.1 172.1.1.100
ip dhcp pool 1
network 172.1.1.0 255.255.255.0
lease 30

To reiterate, you’ll have many
options with DHCP on Cisco
routers, so just do your homework
on Cisco’s website before jumping
in and configuring!

Network Address Translation
NAT will be a thing of the past one
day.
Today is not that day.
Network
Address
Translation
(NAT) allows a network host with a
private IP address to have the
source IP address of their packets
“translated” into a routable address.
Port Address Translation (PAT)
allows a single routable IP address
to be used by multiple inside
private IP hosts. The private IP

addresses are translated to the same
public IP, but each host will use a
different port number. PAT is
commonly
referred
to
as
“overloading”.
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 classes
(/8, /16, /24).
There are four terms used to
describe these addresses at
different points in the entire NAT
process.
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.
These inside local addresses are
translated into inside global

addresses. Inside global addresses
are routable addresses.
Outside global addresses are the
addresses that are configured on the
outside hosts. These are fully
routable addresses used by Internetbased hosts.
Finally, outside local addresses are
the actual addresses of remote
hosts. This can be, and probably is,
an RFC 1918 address as well.

From the 10.1.1.1 host’s point of

view, these are the NAT addresses:
Inside Local: 10.1.1.1 /8
Inside Global: 210.1.1.1 /24
Outside Global: IP Address of web
server.
Outside Local: If web server is
using an RFC 1918 address and the
remote router is also using NAT,
that 1918 address would be the
outside local address.
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 to a public
one.
There are three internal PCs on an
RFC 1918 private network, using
addresses 10.5.5.5, 10.5.5.6, and
10.5.5.7. 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
network available.

210.1.1.0/24

Three static mappings are needed to
use Static NAT. The interfaces must
be configured for NAT as well.
R3(config)#interface ethernet0
R3(config-if)#ip address 10.5.5.100 255.0.0.0
R3(config-if)#ip nat inside
R3(config-if)#interface serial0
R3(config-if)#ip
address
210.1.1.1
255.255.255.0
R3(config-if)#ip nat outside
R3#conf t
R3(config)#ip nat inside source static 10.5.5.5
210.1.1.2
R3(config)#ip nat inside source static 10.5.5.6
210.1.1.3
R3(config)#ip nat inside source static 10.5.5.7

210.1.1.4

R3#show ip nat statistics
Total active translations: 3 (3 static, 0 dynamic; 0
extended)
Outside interfaces: Serial0
Inside interfaces: Ethernet0
Hits: 0 Misses: 0
Expired translations: 0

Dynamic NAT
Static NAT is fine for a few hosts,
but consider a private network with
150 hosts. It would be an
administrative
nightmare
to

configure 150 static NAT statements
on your router.
Dynamic NAT allows a pool of
public IP addresses to be created.
The public IP addresses are
mapped to a private address as
needed, and the mapping is dropped
when the communication ends.
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 as
needed:
R3#conf t
R3(config)#access-list
0.0.0.255

1

permit

10.5.5.0

R3#conf t
R3(config)#interface ethernet0
R3(config-if)#ip nat inside
R3(config-if)#interface serial0
R3(config-if)#ip nat outside

R3#conf t
R3(config)#ip nat inside source list 1 pool
NATPOOL

R3(config)#ip nat pool NATPOOL 200.1.1.2
200.1.1.5 netmask 255.255.255.0

An access-list is used to identify the
hosts that will have their addresses
translated by NAT. 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, 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 use an address
from the NAT pool to communicate
with Internet-based hosts.
Show ip nat statistics will display
the name and configuration of the
NAT pool.
R3#show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0
extended)
Outside interfaces: Serial0
Inside interfaces: Ethernet0 Hits: 0 Misses: 0
Expired translations: 0 Dynamic mappings:

-- Inside Source
access-list 1 pool NATPOOL refcount 0
pool NATPOOL: netmask 255.255.255.0
start 200.1.1.2 end 200.1.1.5
type generic, total addresses
allocated 0 (0%), misses 0

4,

Four addresses are available in the
NAT pool. What if the network has
50 hosts and ten of them want to
connect to an Internet host
simultaneously?
NAT allows multiple hosts to use
the same public IP address via Port
Address
Translation
(PAT).
Generally
referred
to
as

“overloading”, the private address
will be translated to a public
address and port number, allowing
the same IP address to support
multiple hosts. The router will
differentiate the connections 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, identify the
outside interface followed by the
word overload.

“overload” indicates that the IP
address of the named interface will
be the only one used for NAT, but
that a different port number will be
used for each translation, allowing
the router to keep the different
translations separate while using
only a single IP address.
R3(config)#interface ethernet0
R3(config-if)#ip nat inside
R3(config-if)#interface serial0
R3(config-if)#ip nat outside
R3(config-if)#ip nat inside source list 1 interface
serial0 overload
R3(config)#access-list 1 permit 10.5.5.0
0.0.0.255

Each host that matches the ACL will
have its IP address translated to the
same IP address - in this case, the
same IP address that 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 router keeps a translation table
with the port numbers to allow
translation when reply packets for
these transmissions is received.

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.

IP Version 6

Why Do We Need A Version 6 Of
IP, Anyway?
The main reason - we’re running
out of IPv4 addresses!
That isn’t the only drawback to
IPv4 addresses as compared to
IPv6, but frankly, it’s the main one.
The good news with IPv6 is that the
128-bit addresses give us a
tremendous number of addresses,

and is designed to make route
summarization easier and more
efficient.
The bad news: IPv6 uses 128-bit
addresses.
If this is the first time you’ve really
looked at IPv6 - and you’re not
alone if it is -- that’s the major
shock factor. Once you get used to
the address format, though, it’s
really not that bad.
Before we start comparing the
version, let’s look at some
additional improvements brought to

us by IPv6:
Those dreaded broadcasts
we’re always trying to limit
are a thing of the past - IPv6
doesn’t use them.
NAT was developed to help
with the IPv4 address
shortage, and since that will
also be a thing of the past, so
will NAT. (NAT is not a thing
of the past when it comes to
your CCNP ROUTE exam.)
IPv6 was specifically

designed with route
aggregation in mind, making
that aggregation easier and
more effective, which in turn
keeps our routing tables - say
it with me - complete and
concise.
The security capabilities of
IPv6 are much greater than that
of IPv4. That’s particularly
true when it comes to Mobile
IP. IPv4 can run that with
additional config (boo!), but
IPv6 doesn’t need any extra
config (yay!)

DHCP is still available, but
IPv6 nodes can assign
themselves an address without
the help of a DHCP server via
autoconfiguration.
Quality of Service (QoS)
capabilities are greater with
the IPv6 header values than
with IPv4 - more about that in
just a moment.
Of course, moving your entire
network from IPv4 to IPv6 might be

a little tricky - any migration is.
Knowing the fundamentals of IPv6
makes that migration a lot easier,
and we’ll jump into that right now
with a comparison of the actual
IPv4 and v6 headers.
IPv6 Header Fields
You’re familiar with the IPv4
headers, but there are quite a few
changes in the move to IPv6.
Here’s a link to an illustration on
Cisco’s website comparing the v4
and v6 headers:

http://www.cisco.com/web/about/ac1
3/93_ipv6_fig1_lg.jpg
There are eight header fields in
IPv6:
version - This is set to “6” in
IPv6. But you knew that. :)
traffic class - In IPv4, this
was the Type Of Service
(TOS) field. The “traffic
class” name comes from this
field’s ability to allow us to
assign levels of importance to
a packet via QoS.

flow label - No equivalent in
IPv4, this field allows a
packet to be labeled as part of
a particular flow. This also
helps with QoS, allowing us to
prioritize traffic flows rather
than individual packets.
payload length - IPv4’s
equivalent is the Total Length
field
hop limit - Roughly equivalent
to IPv4’s Time To Live (TTL)

field. Every hop decrements
this counter by one, and when
that counter hits zero -- the
“time to live” becomes the
time to be discarded.
next header - Equivalent to
IPv4’s Protocol field
source address, destination
address - they’re now 128
bits!
There are some IPv4 fields that are
not represented in IPv6:

Header Length
Identification
Flags
Fragment Offset
Header Checksum
The IPv6 Address Format
Typical
IPv4
129.14.12.200

address:

Typical
IPv6
address:
1029:9183:81AE:0000:0000:0AC1:2
IPv6 isn’t exactly just tacking two
more octets onto an IPv4 address!
With IPv6, our non-compressed
address has eight sections of four
hex values, separated by a total of
seven colons.
Luckily for us, there are easy ways
to compress these addresses so we
don’t have to enter so many
numbers -- and I have a feeling your
ability
to
perform
these
compressions will be a highly

valuable skill on your way to
passing the CCNP ROUTE exam.
You remember from your CCNA
studies that there’s no difference
between an upper-case letter or
lower-case letter in hexadecimal.
That’s the first rule. The other rules
deal with all the zeroes you’ll run
into in IPv6 addresses.
If you’re not comfortable and/or
rusty with your hexadecimal
conversions, I strongly recommend
you work with the hex conversions
workbook included with this course
before proceeding. Hex is easy

when you know how, and once you
work with that material just a bit,
you’ll know how.
Please take my word for this: Even
if you think you’re comfortable with
hex, spend a little time practicing
your conversions anyway.
Zero Compression And Leading
Zero Compression
If you have consecutive fields of
zeroes, they can be expressed with
two colons. It doesn’t matter if you
have two fields or eight, you can
simply type two colons and that

represents all of them.
The key rule: you can only do 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
Leading zeroes in any 16-bit field
can be dropped, but each block you
do this with must have at least one
number remaining. If the block is all
zeroes, you have to leave one zero.

This is leading zero compression.
Zero compression: Allowed only
once per address.
Leading zero compression: Perform
as often as you like in an address.
Let’s look at an example of leading
zero compression with this address:

1234:0000:1234:0000:1234:0000
We have four different fields with
leading zeroes, making this address
a prime candidate for leading zero
compression.

Original format:

1234:0000:1234:0000:1234:0000
With leading zero compression:

1234:0:1234:0:1234:0:123:1234
We’re allowed to use both zero
compression and leading zero
compression in a single address,
and the frequency rules discussed
earlier apply. Using both methods,
we can take this address….

1111:0000:0000:1234:0011:0022
.. and compress it to this:

1111::1234:11:22:33:44
Zero compression uses the doublecolon 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. The key to success
here is remembering that you can
only use zero compression once in a

single address.
Tipoffs that you’re looking at an
invalid IPv6 address include seeing
four colons in a row…
1111::::2222:3333:4444:5555
… or spotting consecutive colons at
multiple points in that same
address.
1111::2222::4444:5555
The key to success with IPv6
compression: practice.
Identifying An Interface In IPv6

Every interface on a given IPv6 link
has to have a unique identifier, and
once again the name is the recipe
with these interface identifiers.
This value will always be 64 bits in
length, and in the case of an
Ethernet interface, the identifier is
dynamically created from the MAC
address of the interface.
The 48-bit MAC address.
Hmm.
Sounds like we need to add
something there… and that’s just

what IPv6 does. The hex value
“FFFE” is inserted directly in the
middle of the MAC address, right
between the OUI and the vendor
code.
(Confess: Never thought you’d hear
the term “OUI” again, right?)
In the MAC address 00-01-02-aabb-cc, the OUI is 00-01-02 and the
vendor code is aa-bb-cc.
It’s simple enough, then, to come up
with the interface identifier here…
00-01-02-FF-FE-aa-bb-cc.

This is networking, though, so you
know there’s got to be one more
detail here. That detail is the
seventh bit of the first octet, and
right now that first octet is…
00000000
The 7th bit is the Universal/Local
bit, and that’s just what this bit does
-it tells us whether this address is
universally unique or just locally
unique (unique only to this link). It’s
assumed a MAC address is
universally unique, so that U/L bit is
set to 1…

00000010
… giving us a final interface
identifier of 02-01-02-FF-FE-AABB-CC.
The 8th bit is generally called the g
bit, “g” standing for “group, but
you’ll occasionally see it called the
i/g bit for “individual/group”. If this
bit is set to zero, it’s a unicast
address; if set to one, it’s a
multicast address.
IPv6 Address Types
You know the drill with IPv4

address types:
Unicast - represents a single
host
Multicast - represents a group
of hosts
Broadcasts - represents all
hosts
We still have unicasts and
multicasts with IPv6, but broadcasts
are gone and now we have anycasts
- an address that represents multiple

interfaces.
Additionally, we have different
types of unicast addresses.
The official name of the first IPv6
unicast address we’ll discuss is
aggregateable global unicast
address.
Quite
a
bit
of
documentation on IPv6 leaves the
“aggregateable” off, so we’ll refer
to these addresses simply as global
unicast addresses.
This address is equivalent to the
public IPv4 address classes. These
addresses are fully routable and can

be used for Internet access. The
word “aggregateable” refers to the
ability to aggregate, or summarize,
these addresses to make routing
more efficient.
Unlike IPv4, IPv6 is specifically
designed to be fully hierarchical,
allowing for easier and more
efficient route aggregation.
The range of IPv6 global unicast
addresses is 2000::/3 (any address
that begins with 001).
The IPv6 link-local address is our
“the name is the recipe” address of

the day - it’s an address that is kept
on the local link. They’ll have an
prefix of Fe80::/10, followed by
that interface identifier we spoke of
earlier.
Much more on these later.
Site-local
addresses
were
originally created as IPv6’s
equivalent to IPv4’s private address
classes. You’re likely reading that
and thinking “If we don’t need NAT
any more and we have sooooo many
addresses with IPv6, why do we
need private address classes?”

Great question! It’s such a great
question that site-local addresses
are no longer used by IPv6. I’m
mentioning it here just in case
you’ve read some of my older IPv6
materials (or someone else’s!) that
mentioned them.
You can identify several classes of
IPv6 addresses by their initial bits:
001 - Global address
1111 1111 - Multicast (FF)
1111 1110 10 - Link Local

(FE80)
::x.x.x.x or
0:0:0:0:0:0:x.x.x.x - IPv4compatible address. Any IPv6
address with the first 96 bits
set to zero is an IPv4compatible address. I used
zero compression in the first
representation of that range,
and leading zero compression
for the second.
Reserved IPv6 Addresses
IPv4 has the reserved address

127.0.0.1 to allow for testing; IPv6
has a loopback address reserved
for the same purpose.

IP
v6
Loopback:
0000:0000:0000:0000:0000:0000:0
Using Leading Zero Compression
Only: 0:0:0:0:0:0:0:1
Combining Leading Zero and Zero
Compression: ::1
Zero compression looks pretty good
now, doesn’t it?
Unique to IPv6 is the unspecified
address. You may be thinking “if

it’s unspecified, how do we know
what it is?” Another great question!
This address is used to represent an
unknown address.

IPv6
Unspecified
Address:
0000:0000:0000:0000:0000:0000:00
Using
Zero
Compression:
0:0:0:0:0:0:0:0, or just ::/128.
Since the unspecified address is
::/128, it follows that the default
route for IPv6 is ::/0.
IPv4 - IPv6 Compatible Addresses

If you see an address with a great
many zeroes -- 96 of them, to be
exact -- at the beginning, it may
well be an IPv4-compatible IPv6
address. Such an address is going to
have zeroes for the first 96 bits,
which makes zero compression
even better!
The rest of the bits are simply a
hexadecimal expression of the IPv4
address. For example….
IPv6
Address
::D190:4E71
The

To

double-colon

Convert:
is

zero

compression in action, so now we
need to convert the lower 32 bits
into decimal.
Hex D1 = Decimal 209
Hex 90 = Decimal 144
Hex 4E = Decimal 78
Hex 71 = Decimal 113
The IPv4 address that was
embedded into the IPv6 address is
209.144.78.113. Just another good
reason to know your hex
conversions!

Multicasts And Anycasts
You know what a multicast is, and
that IPv4 multicast addresses are
Class D addresses with a first octet
value of 224 - 239. The IPv6
multicast range is much larger, but
just as easy to remember. Any
address that begins with “1111
1111”, or “FF” in hex, is a multicast
address -- the full prefix being
FF00::/8.
There are some local-link-only
addresses in that range worth
noting:

FF02::1 -- All nodes on the
local link
FF02::2 -- All routers ““
FF02::9 -- All RIP routers ““
FF02::A -- All EIGRP routers
““
FF02::1:FFzz:zzzz/104 -Solicited-node address. These
are used in Neighbor
Solicitation messages - more

about these very soon. The
“z”s are the rightmost 24 bits
of the unicast/address of the
node.
Here’s a link to a regularly-updated
IANA document with plenty of
additional reserved addresses and
links to related RFCs. It’s not
required reading for the CCNP
ROUTE, but an excellent document
for present and future reference.

http://www.iana.org/assignments/ipv
multicast-addresses/ipv6-multicastaddresses.xml

The Anycast Address
IPv6 introduces the anycast
address, an interesting combination
of unicast and multicast
An anycast address is a unicast
address assigned to multiple
interfaces. (Something we really
couldn’t get away with in v4.) A
sender transmits an anycast packet
in the same manner it would a
unicast packet…
… and when the router receives the
anycast packet, the router then sends

that packet to the closest device
with that anycast address.
Sounds simple, right? It is - but we
also know the word “closest” is a
big red flag.
“You said I’m closest. How am I
closest? What is so closest about
me?”
Sorry. But we really do need to
know how IPv6 defines “closest”
here…
It’s the first learned directly
connected neighbor - if there

are directly connected
neighbors.
If that’s not the case, it’s
simply the closest neighbor as
determined by the routing
protocol metric.
That’s how I’m closest, Henry.
The
IPv6
Process

Autoconfiguration

IPv4 has DHCP; IPv6’s equivalent
is autoconfiguration. There are
two main types of autoconfiguration

- stateless and stateful.
Stateful autoconfiguration is used
when the host obtains an IPv6
address and other information from
a server. If that sounds kinda like
DHCP, that’s because it is DHCPv6, actually! You hear the
term stateful autoconfiguration
more often than “DHCPv6”, though,
but you should know they’re one
and the same.
The key phrase there is “from a
server”. If the DHCPv6 server goes
down, we’re out of luck. With
stateless autoconfiguration, there’s

no such dependency, and the entire
process starts with the IPv6 host
configuring its own link-local
address.
An IPv6 address is 128 bits, and
here’s where they come from in this
instance:
The first 64 bits of this selfgenerated address will be
1111 1110 10 (FE80) followed
by 54 zeroes.
The last 64 bits are the
interface identifier.

Technically, that address is
tentative at this point. It’s been
successfully calculated, but now we
must make sure that no other host is
using the same address. That’s a
remote possibility, but still a
possibility, and that’s where DAD
comes in - the Duplicate Address
Detection feature.
At this point, the host will send a
Neighbor
Solicitation
(NS)
message to see if any other host on
the link is using that same link-local
address.

Basically, the host is asking all
other hosts on the link, “Is anyone
else using the address I just
generated for myself?”

If another host on the link is using
that address, that host will respond
with a Neighbor Advertisement

(NA). When the host that sent the
NS receives the NA, it will disable
its link-local address.
If no response to the NS is
received, the local host is satisfied
that it has a unique link-local
address.
At this point, that host will send a
Router Solicitation (RS) onto the
segment. The destination for the RS
will be FF02::2, the “all-routers”
multicast address.
What’s the host soliciting? It needs
additional configuration information

from a router in the form of a
Router Advertisement (RA).
Routers generally send these RAs
periodically without an express
request from a host, but even though
the host would only have to wait 10
seconds or so, polling the router
now with an RS does speed up the
overall process.
(If the router is running the usual
ipv6 unicast-routing command,
you’ll see those RAs. If the router is
running the ipv6 address autoconfig command but not unicastrouting, those RAs are not sent.)

Information in the RA includes…
Flags indicating whether the
host should use DHCP for
addressing information
If DHCP is in use, the RA tells
the host where the DHCP serer
is
If not, the RA contains the
prefix and prefix lifetime
information
If DHCP is not in use, the router

attaches the network prefix to the
host’s link-local address, which
results in the host’s full IPv6
address complete with network
prefix.

IPv6 Routing On Cisco Routers
To go along with the new address

types, we have new variations of
RIP for IPv6 - the actual name
is RIPng (new generation)
EIGRP for IPv6
ISIS for IPv6
OSPF v3 (Version 3, defined
in RFC 2740.)
Static routes are still available
with IPv6

Multiprotocol BGP V4
(MPBGPVer4 or simply
MPBGP)
Before we start with any of these,
we need to enable a Cisco router’s
IPv6 routing capabilities with ipv6
unicast-routing.
R1(config)#ipv6 unicast-routing

OSPF For IPv6 (OSPF Version 3)
Of the IPv6-compatible protocols
listed earlier, OSPF v3 is probably

the one in the most widespread use
today. Let’s take a look at some
basic OSPFv3 commands and
compare OSPF v3 to IPv4’s OSPF
v2.
During your migration between the
two, you may run both v2 and v3 on
the same router. There’s no rule
against that, and the two instances
are kept as separate as they would
be if you ran two v2 instances on
the same router.
In IPv6, you’re not going to start an
OSPF configuration with router
ospf. One major difference between

v2 and v3 is that v2 is enabled in
router config mode and v3 is
enabled on a per-interface basis.
This will automatically create a
routing process.
R1(config-if)#ipv6 ospf 1 area 0

One similarity between the two
versions is their use of the OSPF
RID. v3 is going to use the exact
same set of rules to determine the
local router’s RID - and 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 12.1.1.1

Other similarities and differences
between v2 and v3:
The basic operational theory
of v3 is very similar to that of
v2. The Hello packet is still
around, as are the LSAs and
LSAcks.

Stub, total stub, and NSSAs
are still around, and the Area 0
rule still exists (as do virtual
links).
The general rules for neighbor
discovery and adjacencies are
the same.
And speaking of discovery…
v3 NBMA configurations
require neighbor statements,
just like v2.

One major difference between
the two is that v3 allows a link
to be part of multiple OSPF
instances, where v2 would
allow a link to be part of only
one.
v3 point-to-point and point-tomultipoint configurations do
not elect DRs and BDRs, just
like v2.
v3 headers are smaller than
v2, since v3 headers have no
authentication fields.

The v2 reserved address
224.0.0.5 is represented in v3
by FF02::5.
The v2 reserved address
224.0.0.6 is represented in v3
by FF02::6.
We can still use the area range
command, and IPv6 does make
summarization more effective but when you use the area
range command in v3, the
OSPF cost of that summary is

simply the highest of the
individual route costs.
So while we have new addresses
and commands to get used to, the
theory remains much the same.
A Sample OSPFv3 Configuration
Before we begin the configuration,
we need to enable IPv6 packet
forwarding with ipv6 unicastrouting, the IPv6 version of Cisco
Express Forwarding (CEF) with
ipv6 cef, and the OSPF v3 process
with ipv6 router ospf.

R1(config)#ipv6 unicast-routing
R1(config)#ipv6 cef
R1(config)#ipv6 router ospf 1
R1(config-rtr)#
R2(config)#ipv6 unicast-routing
R2(config)#ipv6 cef
R2(config)#ipv6 router ospf 1
R2(config-rtr)#

If you don’t have any IPv4
addresses configured on the router,
you must configure an OSPF RID
with the router-id command.
R1(config)#ipv6 router ospf 1
R1(config-rtr)#router-id 1.1.1.1
R2(config)#ipv6 router ospf 1
R2(config-rtr)#router-id 2.2.2.2

OSPF v3 interfaces are placed into
areas at the interface level.
R1(config-rtr)#int fast 0/1
R1(config-if)#ipv6 ospf 1 ?
area Set the OSPF area ID
R1(config-if)#ipv6 ospf 1 area 0
R2(config-rtr)#int fast 0/1
R2(config-if)#ipv6 ospf 1 area 0

Here, IOS Help shows us that quite
a few OSPF v3 options look just
like their v2 counterparts!
R2(config-if)#ipv6 ospf ?

<1-65535>

Process
Enable

authentication

authenti

cost

Interfac
Filter O
LSA du
synchro
and floo
Interval
which a
neighbo
declare
OSPF d
circuit
OSPF F
Reducti
Time be
HELLO

databasefilter

dead-interval
demandcircuit
floodreduction
hello-interval

mtu-ignore
neighbor
network
priority
retransmitinterval
transmitdelay

packets
Ignores
MTU in
packets

OSPF n
Networ
Router
Time be
retransm
lost link
adverti
Link sta
transmi

One thing we still like to see in

OSPF v3 are adjacencies! Here, the
router console lets us know that an
adjacency has just been formed.
Note the message indicates that
OSPF v3 is in use.
*Mar 4 16:13:48.623: %OSPFv3-5-ADJCHG:
Process 1, Nbr 1.1.1.1 on FastEthernet0/
1 from LOADING to FULL, Loading Done

Verify OSPF v3 adjacencies with
show ipv6 ospf neighbor.

To see more details about the
neighbor, run show ipv6 ospf
neighbor detail. The output is just a

little different than OSPF v2.
R2#show ipv6 ospf neighbor detail
Neighbor 1.1.1.1
In the area 0 via interface FastEthernet0/1
Neighbor: interface-id 10, link-local
address FE80::20A:41FF:FE64:31C2
Neighbor priority is 1, State is FULL, 6
state changes
DR is 2.2.2.2 BDR is 1.1.1.1
Options is 0x84EFB26D
Dead timer due in 00:00:34
Neighbor is up for 00:06:52
Index 1/1/1, retransmission queue length 0,
number of retransmission 0
First 0x0(0)/0x0(0)/0x0(0) Next
0x0(0)/0x0(0)/0x0(0)
Last retransmission scan length is 0,
maximum is 0
Last retransmission scan time is 0 msec,
maximum is 0 msec

Here are two other important OSPF
v3 commands, show ipv6 ospf
interface and show ipv6 ospf
database. The first command shows
the link-local address of both the
local router and the BDR (R1). The
second command indicates the use
of OSPF v3 in the output almost
immediately.
R2#show ipv6 ospf interface fast 0/1
FastEthernet0/1 is up, line protocol is up
Link Local Address
FE80::20F:F7FF:FE69:8D21, Interface ID 5
Area 0, Process ID 1, Instance ID 0, Router
ID 2.2.2.2
Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 2.2.2.2, local

address FE80::20F:F7FF:FE69:8D21
Backup Designated router (ID) 1.1.1.1,
local address
FE80::20A:41FF:FE64:31C2
Timer intervals configured, Hello 10, Dead
40, Wait 40, Retransmit 5
Hello due in 00:00:08
Index 1/1/1, flood queue length 0 Next
0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 4
Last flood scan time is 0 msec, maximum is
0 msec
Neighbor Count is 1, Adjacent neighbor
count is 1
Adjacent with neighbor 1.1.1.1 (Backup
Designated Router)
Suppress hello for 0 neighbor(s)
R2#show ipv6 ospf database
OSPFv3 Router with ID (2.2.2.2)
(Process ID 1)

Router Link States (Area 0)

The IPv6 equivalent of OSPF
IPv4’s show ip ospf is show ipv6
ospf. This command also indicates
the use of OSPF v3.
R2#show ipv6 ospf
Routing Process “ospfv3 1” with ID 2.2.2.2
SPF schedule delay 5 secs, Hold time between
two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA
arrival 1 secs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum
0x000000

Number of areas in this router is 1. 1 normal 0
stub 0 nssa
Reference bandwidth unit is 100 mbps
Area BACKBONE(0)
Number of interfaces in this area is 1
SPF algorithm executed 3 times
Number of LSA 6. Checksum Sum
0x0293F7
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

The IPv6 equivalent of OSPF
IPv4’s clear ip ospf process is
clear ipv6 ospf process. Just as
with OSPF v2, the OSPF database
is cleared out and then rebuilt with
this command. Note that first I tried
to use the OSPF v2 command clear

ip ospf process, but that did nothing
since we’re not running OSPF v2.
OSPF v3 still asks us if we’re
really sure we want to do this - the
prompted answer to the question
“Reset ALL OSPF processes?” is
“no”!
R1#clear ip ospf process
R1#
R1#
R1#clear ipv6 ospf process
Reset ALL OSPF processes? [no]: y
R1#
*Jan
22
02:46:33.535: %OSPFv3-5ADJCHG: Process 1, Nbr 2.2.2.2 on
FastEthernet0/1 from FULL to DOWN,
Neighbor Down: Interface down or detached
R1#
*Jan
22
02:46:41.879: %OSPFv3-5-

ADJCHG: Process 1, Nbr 2.2.2.2 on
FastEthernet0/1 from LOADING to FULL,
Loading Done

Here are some general IPv6
commands and their output you
should be familiar with:
R2#show ipv6 route
IPv6 Routing Table - 5 entries
Codes: C - Connected, L - Local, S - Static, R RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS
interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1
- OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 OSPF NSSA ext 2
O 4DDE:EEEE:1::/64 [110/1]

via ::, FastEthernet0/1
C 5DDE:EEEE:1::/64 [0/0]
via ::, FastEthernet0/1
L 5DDE:EEEE:1::1/128 [0/0]
via ::, FastEthernet0/1
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R2#show ipv6 interface
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is
FE80::20F:F7FF:FE69:8D21
Global unicast address(es):
5DDE:EEEE:1::1, subnet is
5DDE:EEEE:1::/64
R2#show ipv6 interface brief
FastEthernet0/0
down/down]
unassigned

[administratively

Serial0/0
[administratively
down/down]
unassigned
FastEthernet0/1
[up/up]
FE80::20F:F7FF:FE69:8D21
5DDE:EEEE:1::1
Serial0/1
[administratively
down/down]
unassigned

Transitioning From IPv4 To IPv6
This is the part that’s going to be
really interesting for all of us in the
years ahead. Any migration is
challenging, and migrating a
network from IPv4 to IPv6 is no
exception.

Theory holds that to roll out IPv6,
you start at the network edge and
work your way toward the core.
This means we have to think of
some ways for IPv6 and IPv4 to
work together while we make the
transition to an all-IPv6 network.
To get this job done, you’re either
translating or encapsulating.
There are three primary methods of
accomplishing this.
The first is the dual stack. A host
runs dual stack when it runs both
IPv4 and IPv6. Dual stack helps
meet the migration challenge we

face when end users want to keep
using their favorite IPv4-based
apps while the network moves
forward to IPv6-based apps.
Another solution is the 6-to-4
tunnel. Cisco documentation states
that setting up a 6-to-4 tunnel is
very simple on the host ends of the
tunnel. A 6-to-4 tunnel is also
automatic, is torn down when the
session ends, and is a scalable
solution.
6-to-4 tunneling is accomplished by
taking an IPv6 packet and
encapsulating it into an IPv4 packet

(protocol type 41) for transport
across the IPv4 section of the
network, then de-encapsulating it
when the remote edge router is
ready to route it across the IPv6
network. The IPv6 networks shown
in this method are sometimes
referred to as IPv6 islands.
6to4 tunnels also have a reserved
IPv6 address prefix for edge routers
such as the ones shown below.
These prefixes begin with 2002 and
are followed by the router’s IPv4
address expressed in hex. These
prefixes carry a /48 prefix, such as
2002:1234:83cd::/48.

The IPv4 address of the interface
involved in the tunneling is vital in
determining the correct IPv6
address for the tunnel. Let’s say the
IPv4 address of the router on the
left is 220.200.18.42. We know the
address for the corresponding
tunnel interface begins with 2002 but what’s the rest of it? Breaking
down each octet into hex, we get:
220 = 13 units of 16, 12 units of 1 =

hex value is DC
200 = 12 units of 16, 8 units of 1 =
hex value is C8
18 = 1 unit of 16, 2 units of 1 = hex
value is 12
42 = 2 units of 16, 10 units of 1 =
hex value is 2A
The IPv6 address for the tunnel
interface is 2002:DCC8:122A::/48.
R1(config)#int fast 0/1
R1(config-if)#ip
address
255.255.255.0
R1(config-if)#int tunnel0

220.200.18.42

R1(config-if)#ipv6
2002:DCC8:122A::/48

address

Another method of cutting over
from one version to the other is
Network Address Translation Protocol Translation. NAT-PT
works much like plain old NAT. If
you have IPv6 hosts that need to
intercommunicate with IPv4 hosts
on another segment, NAT-PT may
be the perfect solution.
NAT routers translate private IPv4
addresses to public IPv4 addresses,
and back again; NAT-PT routers
translate IPv6 addresses to IPv4
addresses, and back again.

A Final Word On IPv6
As I mentioned earlier, I admit my
first reaction to IPv6 was “what do
we need that for?” The key is not
why it’s here, but that it is here. We
can either resist it or embrace it,
and we might as well start
embracing it -because it is here!
What you must not do is take the
approach of “well, we use IPv4 at
my job, so I don’t need to know
IPv6.” I heard the same thing when
Windows 2000 Server came along “We use NT4 and we’ll use that
forever.” That didn’t work out for

too many people.
My point here is that you don’t want
to fall into that trap. Few of us are
going to work in one place forever
in this field, and to get ahead, we
have to know things that other
people don’t. Like IPv6.
Those who know IPv6 are going to
have a huge advantage over those
who don’t. I’ve only given you an
introduction to IPv6 here. There is a
lot of solid information available
readily through your favorite search
engine, some of it from Cisco and
some not. Take the incentive now

and learn IPv6. You’ll be glad you
did!

Copyright © 2012 The Bryant Advantage..
All Rights Reserved.

Route Redistribution

What Is Route Redistribution?
Route redistribution is simply the
process of taking routes from one
source and placing them into
another routing domain. That source
doesn’t have to be a dynamic
routing protocol - we can
redistribute directly connected
networks and static routes.
Sounds simple, right? Maybe even
fun?

Actually, you’ll find the basic
configs of route redistribution to be
just that - simple - with two
caveats:
The more route redistribution
you perform in a given
network, the greater the chance
of routing loops. That’s
especially true when you’re
redistributing between
networks with multiple
entrance / exit points.
We’re in the business of
details, but with route

redistribution, you really have
to watch the details. Some
protocols require seed
metrics; others don’t. Some
require you to configure a
default metric; some don’t.
The rules aren’t complex, but
they are vital.
Route redistribution is much like
route summarization in that they’re
both helpful in the right situation,
and it should be you and I as the
network admins who decide where
route redistribution takes place not the routing protocol.

In real-world networks and your
CCNP ROUTE exam, you’re going
to find very few scenarios where
route redistribution takes place
automatically. It’s a good idea to
know where that might happen,
though…

Here’s a network where the nowobsolete IGRP is the LAN protocol,
and OSPF is used as the
organization’s WAN protocol. The

central router is the only router that
knows that two protocols are being
used. The OSPF-only router has no
idea of the IGRP routes, and the
IGRP-only router doesn’t have any
of the OSPF routes.
That’s likely the way we want it,
for two major reasons:
There’s no reason for the LAN
to have individual routes for
any destinations across the
WAN, since the next-hop
address would always be R1.

There’s really no reason for
the WAN routers to have paths
to the LAN networks, and it
could pose a security issue for
outside routers to know
exactly what network numbers
we’re using on our LAN -that
makes attacking our WAN that
much easier.
If for some reason we did want the
WAN to know about some or all of
our LAN routes, or vice versa,
we’d need to configure route
redistribution.

So if IGRP is obsolete, why did I
mention it? Because IGRP is
involved in an auto-redistribution
scenario. If IGRP and EIGRP are
running on the same router and are
using the exact same AS number,
each protocol will automatically
redistribute their routes to the other.
There are other scenarios where
route
redistribution
happens
automatically, all of them involving
EIGRP.
Automatic Route Redistribution
Scenarios

IGRP automatically
redistributes with EIGRP
when both run the same AS
number.
EIGRP for AppleTalk
automatically redistributes
between EIGRP and RTMP
(Routing Table Management
Protocol, an AppleTalk routing
protocol).
EIGRP for IPX will
automatically redistribute
between IPX for RIP

(Internetwork Packet
Exchange, a networking
protocol used by Novell
NetWare).
Let’s look at a much more common
scenario - where we have multiple
EIGRP instances running on a single
router (a “border router”).
In the following lab, R1 is running
two EIGRP instances with the AS
numbers 50 and 100. R2 is the
neighbor in AS 100, R3 in AS 50.
Both routers are advertising their
loopback via EIGRP.

R1 sees both routes …
R1#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D
2.2.2.2 [90/2297856] via
172.12.123.2, 00:09:33, Serial0
3.0.0.0/32 is subnetted, 1 subnets
D
3.3.3.3 [90/2297856] via 172.12.13.3,
00:00:29, Serial1

.. but neither R2 nor R3 sees the
other’s loopback.

R2#show ip route eigrp
R2#
R3#show ip route eigrp
R3#

The same rule holds for routes
redistributed into an EIGRP AS -they will not be redistributed into
any other EIGRP ASes running on
that router.
Note that all EIGRP routes here are
internal and have an AD of 90; we
haven’t
done
any
route
redistribution, so we have no
external routes. We’ll revisit this

lab in the EIGRP-specific portion
of this session.
OSPF processes running on the
same router do not automatically
exchange routes.

Just as with EIGRP, R1 will see
both loopbacks but neither R2 nor
R3 will see the other’s loopback.

R1#show ip route ospf
2.0.0.0/32 is subnetted, 1 subnets
O
2.2.2.2 [110/65] via 172.12.123.2,
00:00:35, Serial0
3.0.0.0/32 is subnetted, 1 subnets
O
3.3.3.3 [110/65] via 172.12.13.3,
00:00:07, Serial1
R2#show ip route ospf
R2#
R3#show ip route ospf
R3#

Now that we’ve covered nonredistribution in detail, let’s get to
some redistribution!
RIP And The Seed Metric

RIP’s configuration is pretty simple
- so maybe redistributing routes into
RIP is simple, too.
Maybe.
Let’s take a look at the redistribute
command in a RIP config with IOS
Help.
R1(config)#router rip
R1(config-router)#redistribute static ?
metric
Metric for redistributed routes
route-map Route map reference
<cr>

The <cr> is a little misleading

here.
While
the
command
redistribute static is a complete
command, it’s not enough to do the
job when redistributing routes into
RIP - we need to plant a seed.
Seed metric, that is.
RIP’s sole metric is hop count. If
we redistribute an OSPF route into
RIP that has a cost of 74 - a
common OSPF metric - RIP doesn’t
want anything to do with that route,
since RIP considers a metric of 16
to be “unreachable”.

We have to tell RIP “here’s a value
for the route that you understand.”,
and that value is the seed metric.

The seed metric will increment as
the route travels through the new
domain, just as any other route
would.
In the following network, we will
redistribute one OSPF route into a
RIP domain. First, we’ll try to
redistribute the route without
specifying the seed metric.

R1#show ip route
< code table removed for clarity >
20.0.0.0/24 is subnetted, 1 subnets
C
20.1.1.0 is directly connected, Serial0
172.12.0.0/24 is subnetted, 2 subnets
O
172.12.34.0 [110/74] via 172.12.13.3,
00:00:12, Serial1
C
172.12.13.0 is directly connected,
Serial1
R1(config)#router rip
R1(config-router)#redistribute ospf 1
R1(config-router)#redistribute connected

First, we did what we should
always do in this situation - make
sure that the border router has the
routes we want to redistribute in the
first place.

T-Shoot Checkpoint #1: If
you’ve redistributed routes
into any routing protocol OSPF, RIP, EIGRP - and you
see some of the routes but not
all of them, the first thing you
should do is make sure your
border router has the routes in
the first place.

If you don’t see any of the
routes, there’s likely another
issue. We’ll get to that later.
We want R2 to see both the
172.12.13.0 /24 and 172.12.34.0
/24 networks, so both OSPF and
connected routes have to be
redistributed into RIP on R1.
(172.12.13.0/24 is a connected
route to R1.)
T-Shoot Checkpoint #2: If
you’ve successfully performed
route redistribution and find
some pings don’t go through

during your testing, it’s likely
you need to redistribute your
connected networks.
In this example, redistributing
OSPF routes into RIP isn’t
enough, because
172.12.13.0/24 is not an OSPF
route on the router performing
the redistribution.
Now on with the lab…
R2#clear ip route *
R2#show ip route rip
R2#

When a show command returns
nothing, there’s nothing to show.
The OSPF route has not been
successfully redistributed into RIP.
Since RIP converges slowly, I ran
clear ip route * to force updates to
be sent and to be requested by R2.
We do not see the route to
172.12.34.0/24 or 172.12.13.0 /24,
and a quick debug ip rip shows that
it’s not contained in any update
from R1.
R2#debug ip rip
RIP protocol debugging is on
R2#clear ip route *

R2#
00:13:39: RIP: sending request on Serial0 to
224.0.0.9
00:13:39: RIP: received v2 update from 20.1.1.1
on Serial0
00:13:39:
20.1.1.0/24 via 0.0.0.0 in 1 hops

Even though it’s R2 that isn’t getting
the routes, the trouble’s at the
border router.
We didn’t configure a seed metric
for the route, and even though R1
allowed us to enter redistribute
ospf 1 as a valid command, the
route was not redistributed. Let’s go
back to R1 and run the command
again, but use a seed metric this
time.

R1(config)#router rip
R1(config-router)#no redistribute ospf 1
R1(config-router)#no redistribute connected
R1(config-router)#redistribute
ospf
1
metric 2
R1(config-router)#redistribute connected
metric 2

I removed the original redistribute
commands. When you configure a
redistribute statement, that does not
remove any previously configured
ones. (It’s common to have multiple
redistribute commands in a
protocol config.)
Let’s go to R2, clear the routing
table, and see what the situation is
now with 172.12.34.0 /24.

R2#clear ip route *
R2#show ip route rip
172.12.0.0/24 is subnetted, 2 subnets
R
172.12.34.0 [120/2] via 20.1.1.1,
00:00:02, Serial0
R
172.12.13.0 [120/2] via 20.1.1.1,
00:00:02, Serial0
R2#ping 172.12.34.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.3,
timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

R2 now has both the OSPF route
and connected route that were
redistributed into RIP at R1. Putting
the seed metric in the redistribution
command
allowed
us
to

successfully redistribute routes.
However, the pings didn’t go
through!
Pings show us that there is an IP
connectivity issue, but they don’t
tell us where the problem is. To
begin pinpointing an IP connectivity
issue, run traceroute.
R2#traceroute 172.12.34.3
Type escape sequence to abort.
Tracing the route to 172.12.34.3
1 20.1.1.1 36 msec 36 msec 32 msec
2***
3 * <Ctrl-shift-6> <Ctrl-shift-6> entered
here, otherwise 30 rows will appear>

R2#

The problem seems to be on R1.
Let’s try pinging 172.12.34.3 from
there.
R1#ping 172.12.34.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.3,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 36/36/36 ms

Interesting, eh? The real problem
here is that the pings can get from
R2 to R3, but R3 can’t get them
back to R2. R3 is strictly an OSPF

router, and it has no route to R2.
T-Shooting Checkpoint #3:
Just because A sees B, it
doesn’t mean that B sees A.
We have two options to give R3 a
route to R2:
Write a static route
Perform two-way route
redistribution
We’re in the redistribution business

right now, so let’s stay there.
R1(config)#router ospf 1
R1(config-router)#redistribute connected
% Only classful networks will be redistributed
R1(config-router)#redistribute
connected
subnets

We didn’t put a seed metric for
redistribution into OSPF. OSPF has
a default seed metric of 20, so none
has to be specified with the
redistribute command.
What OSPF does require is the
subnets option to be enabled -- if
you want subnets to be redistributed
into OSPF, that is.

And it’s likely you do.
Let’s look at R3’s routing table
now:
R3#show ip route ospf
20.0.0.0/24 is subnetted, 1 subnets
O E2
20.1.1.0 [110/20] via 172.12.13.1,
00:01:51, Serial1

We see two important OSPF
defaults in action here:
The route has a metric of 20,
OSPF’s default seed metric
The route is marked as “E2”,
short for External-Type 2. This

is the default routing code for
a route redistributed into
OSPF. An E2 metric reflects
only the cost from the ASBR
(R1) to the external destination
(R2).
Let’s see if R3 and R2 can exchange
pings…
R3#ping 20.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.1.1.2,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 100/101/108 ms

R2#ping 172.12.34.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.3,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 96/99/100 ms

R2 can now ping R3’s Ethernet0
interface, and R3 can ping R2’s
Serial0 interface.
This is about as simple as a route
redistribution scenario can get, and
you saw that it could go wrong
easily. That’s why we’re going to
spend some serious time here on
redistribution theory as well as

looking at
examples.

several

hands-on

Speaking of theory, here are those
default seed metrics I mentioned…
RIP and EIGRP have a seed
metric of “infinity”, and you
know no routes with a metric
of “infinity” are ever going to
be placed into a routing table.
Both RIP and EIGRP require a
default seed metric to be
defined during the
redistribution process.

OSPF has a default seed
metric of 20, as well as
defaulting to a route type of
E2. There’s always an
exception, and the exception
here is that BGP routes are
given a metric of 1 by OSPF.
And as you’ll see, you better
be really careful when
redistributing BGP into OSPF.
Another link-state protocol,
ISIS, has a default seed metric
of zero, and it does allow
routes to be redistributed
without a specified seed

metric. (ISIS is not tested on
the CCNP ROUTE exam.)
OSPF’s default seed metric can be
changed in the redistribute
command itself. Here, we’ll double
the OSPF default seed metric of 20
for
EIGRP
routes
being
redistributed into OSPF.
R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 100 ?

metric

Metric for
redistributed
routes
OSPF/IS-IS
exterior

metrictype

routemap
subnets

tag

metric type
for
redistributed
routes
Route map
reference
Consider
subnets for
redistribution
into OSPF
Set tag for
routes
redistributed
into OSPF

<cr>
R2(config-router)#redistribute eigrp 100 metric

?
<0-16777214> OSPF default metric
R2(config-router)#redistribute eigrp 100 metric
40
% Only classful networks will be
redistributed
R2(config-router)#redistribute eigrp 100 metric
40 subnets

There’s one more reminder to
include the subnets option if you
want subnets to be redistributed.
Call me crazy, but I think that’s an
important detail to remember,
because the CCNP ROUTE exam
won’t remind you of it.

Suboptimal Routing And Routing
Loops
When route redistribution works
well, it’s quite a rush, both in
production networks and the exam
room.
When it doesn’t work well, it can
become your worst nightmare. The
larger your network, the harder it is
to see all the potential issues. You
can think you’ve got all the bases
covered, and then you put your
carefully
thought-out
route
redistribution plan into action -and a problem quickly occurs that

you never saw coming.
This is particularly true of two-way
route redistribution.
Most of the problems you have with
redistributed routes fall into two
categories -- suboptimal routing
(bad) and routing loops (very bad).
Suboptimal routing generally occurs
because of a miscalculation in
coming up with the right seed
metric value. The packets will
eventually get where they are
supposed to go.

Keyword: “eventually”

R2 has two paths to send data to
172.12.34.0/24. The data could
follow the path R1-R4-R3, or the
more direct R1-R3.
Quick aside: Never assume
the physically shortest path is

the logically shortest path,
whether you’re routing or
switching.
All values being equal, the best
path is the more direct path. If route
redistribution metrics are incorrect,
R2 could end up using the longer
path. Data would still reach the
desired destination, but would take
longer to arrive and would put an
unnecessary strain on R4’s
resources.
That’s
suboptimal
routing at its best / worst.
A far worse effect of improperly

configured route redistribution is a
routing loop. Packets that enter a
routing loop will be sent back and
forth between the same group of
routers over and over. Packets that
enter a routing loop will keep
looping and will never reach the
intended destination.
Traceroute is an excellent tool to
detect a routing loop. If you see the
same IP addresses appearing in the
command output over and over,
you’ve got a routing loop…. as
you’re about to see.
This lab’s networks:

Frame Relay: 172.12.123.0 /24
Ethernet: 172.23.23.0 /24
R3 / R4 Link: 172.34.34.0 /24
R4’s Loopback: 4.4.4.4
advertised into OSPF

/32,

We want the routers in the RIP
domain to have connectivity to R4’s

loopback - and as always, before
beginning
to
configure
redistribution, we’ll check the
border router and make sure it has
that route to begin with!
R3#show ip route ospf
4.0.0.0/32 is subnetted, 1 subnets
O
4.4.4.4 [110/65] via 172.34.34.4,
00:00:03, Serial1
R3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 36/36/36 ms

The

BR

has

the

route

and

connectivity to that network, so now
we’ll config redistribution. This
time we’ll use the default-metric
command to define RIP’s seed
metric.
R3(config)#router rip
R3(config-router)#redistribute ospf 1
R3(config-router)#redistribute connected
R3(config-router)#redistribute static
R3(config-router)#default-metric 2

Note that even though we had no
static
routes
that
needed
redistribution - actually, there were
no static routes on R3 - I included
the redistribute static command in
the config.

More than once I’ve seen admins
enter the redistribute connected
and redistribute static commands
when they weren’t really necessary.
You might want to avoid this “blind
configuration”, since someone may
add a static route to the config later
that you don’t want redistributed.
Someone who writes an incorrect
static route, like this:
R3(config)#ip route 4.4.4.4 255.255.255.255
172.12.123.1

That static route to 4.4.4.4 is
pointing to R1’s serial interface, not
R4’s.

Let’s see the result on R2:
R2#show ip route rip
4.0.0.0/32 is subnetted, 1 subnets
R
4.4.4.4 [120/2] via 172.23.23.3,
00:00:07, Ethernet0
172.34.0.0/24 is subnetted, 1 subnets
R
172.34.34.0 [120/1] via 172.23.23.3,
00:00:07, Ethernet0

No big deal, right? The routes are
still there. Let’s ping 4.4.4.4 now:
R2#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4,
timeout is 2 seconds:
…..

We had connectivity a few minutes

ago, and lost it when that static
route was redistributed -- and that’s
because the result of that
redistribution is a routing loop, as
shown by traceroute.
R2#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
1
2
3
4
5
6
7
8
9
10

172.23.23.3 4 msec 4 msec 4 msec
172.12.123.1 36 msec 36 msec 32 msec
172.12.123.2 28 msec 28 msec 28 msec
172.23.23.3 32 msec 24 msec 28 msec
172.12.123.1 60 msec 60 msec 60 msec
172.12.123.2 52 msec 52 msec 52 msec
172.23.23.3 52 msec 52 msec 52 msec
172.12.123.1 84 msec 84 msec 80 msec
172.12.123.2 72 msec 72 msec 72 msec
172.23.23.3 72 msec 72 msec 72 msec

11
msec
12
msec
13
14
msec
15
msec
16
msec
17
msec
18
msec
19
msec
20
msec
21
msec
22
msec

172.12.123.1 104 msec 104 msec 104
172.12.123.2 96 msec 124 msec 92
172.23.23.3 96 msec 96 msec 96 msec
172.12.123.1 128 msec 124 msec 128
172.12.123.2 120 msec 116 msec 120
172.23.23.3 120 msec 120 msec 116
172.12.123.1 148 msec 148 msec 148
172.12.123.2 140 msec 140 msec 144
172.23.23.3 140 msec 140 msec 140
172.12.123.1 172 msec 176 msec 172
172.12.123.2 160 msec 164 msec 160
172.23.23.3 164 msec 164 msec 164

23
msec
24
msec
25
msec
26
msec
27
msec
28
msec
29
msec
30
msec

172.12.123.1 192 msec 196 msec 196
172.12.123.2 184 msec 188 msec 188
172.23.23.3 188 msec 184 msec 184
172.12.123.1 216 msec 220 msec 220
172.12.123.2 212 msec 212 msec 208
172.23.23.3 208 msec 212 msec 212
172.12.123.1 256 msec 240 msec 240
172.12.123.2 232 msec 232 msec 232

Anytime you see the same few (or
two) IP addresses in traceroute, you
have a routing loop. Basically,
here’s what’s happening:

Line 1: R2 pings 4.4.4.4.
According to R2’s routing
table, the next-hop IP address
is 172.23.23.3, and the packet
is sent there.
Line 2: R3 looks up 4.4.4.4 in
its routing table, and as a
result of that static route, the
next-hop IP is 172.12.123.1 -R1’s serial interface. (The
static route went into the
routing table since its AD is
less than that of the other
source for that exact same
network, OSPF.)

Line 3: R1 gets the packet,
looks in its routing table, and
sees the next-hop for 4.4.4.4 is
172.12.123.2 -- R2’s serial
interface.
At that point, R2 gets the
packet back, and the entire
process begins again - and we
have ourselves a routing loop.

Preventing Routing Loops .. And
Fixing Them

There is no “one-size-fits-all”
solution
for
routing
loop
prevention. The solution you use
depends on your network topology,
where the routing loop is taking
place,
and
the
preexisting
configuration.
Having said that, we’re going to
take a look at some routing loop
prevention mechanisms that not only
will Cisco expect you to know to
become a CCNP, but you should
know about each of them in order to
use the proper strategy for your
particular network.

The first solution is having a solid
network design in the first place,
which is why it’s more than worth
your time to carefully analyze your
network topology and identify
potential trouble spots.
If you’re lucky, you’ll see a network
like the one illustrated below where
the
routing
domains’
only
interconnection is at the point of
redistribution itself.
The importance of planning before
implementing redistribution cannot
be overstated. Examine both the
logical and physical topology of

your network, the routing domains,
the traffic flows - everything.

This network topology lowers the
possibility of routing loops,
because the only interconnectivity

between the RIP and OSPF domains
is at the point of route
redistribution. You need to decide
in advance where your protocol
border routers are - that is, the
routers where both protocols
involved in redistribution are
configured.
Naturally, it’s not always that easy many networks have multiple
connectivity points between routing
domains for redundancy’s sake.
This is a great idea - until you have
to configure redistribution. Then
you’re going to hate redundancy.
(It’s okay, I won’t tell anybody.)

This topology is a dream for
network fault tolerance, and a
nightmare when it comes to route

redistribution. There are four points
at which the two protocols will
interact; R1-R2, R1-R3, R2-R3,
and R4-R5. R1 is still the best
location for redistribution to be
configured. What you’d have to
concern yourself with here are
routes being sent back and forth
between the other routers.
I’ve worked with both network
configurations shown here and the
first example is a lot easier to work
with, but the second example is
more common. You’ve got to be
prepared to work with both.

Speaking from personal experience,
if you can use one-way route
redistribution in situations with
multiple boundary routers, you
should. Cisco recommends that as
well - avoid two-way route
redistribution whenever possible.
Monitoring
Protocol’s
Distance

And

Adjusting A
Administrative

You know what the AD is and you
know the common and not-socommon AD values - and now
we’re going to put that knowledge

to use.
ADs are used only when there is no
“longest match” in the routing table.
If a router has two routes to the
same destination that have exactly
the same prefix length, there’s got to
be a tiebreaker, and AD is that
tiebreaker.
AD is much like split horizon most of the time it does just what
you want it to do, but under certain
circumstances, you’ve got to make
some changes.
You can’t disable AD the way you

can disable split horizon, but you
can make some (careful) changes in
AD values to fine-tune your
network after route redistribution.

The RIP domain includes:
The 172.12.123.0 /24 frame
cloud connecting R1, R2, and
R3

The 10.1.1.0 /24 network on
R1
The OSPF Area 0 network:
The 30.1.1.0 /24 network
connecting R2, R3, R4, and R5
The objective:
All routers in the OSPF
domain have the network
10.1.1.0 /24 network in their
tables.

Process:
Miniaturization!
(Okay, we’ll use route
redistribution instead.)
As always, our first step is to make
sure our border router has the
routes to be redistributed:
The first step is to make sure R3
sees the RIP route ….
R3#show ip route rip

10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:19, Serial0
R2#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0

R3 sees the route, and we’ll now
redistribute that route into the OSPF
domain. I put R2’s table there as
well, because it’s a very good idea
to keep an eye on the other routing
tables in your routing domain as
well
when
performing
redistribution.
R3(config)#router ospf 1

R3(config-router)#redistribute rip subnets
R3(config-router)#redistribute
connected
subnets
R3(config-router)#router rip
R3(config-router)#redistribute
metric 1

connected

R4 now sees both 172.12.123.0 and
10.1.1.0 /24. As we expect, both
routes are marked E2 and have a
cost of 20, and the next hop for both
routes is the IP address of R3’s E0
interface.
R5 shows the exact same OSPF
routing table:
R4#show ip route ospf

172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via 30.1.1.3,
00:00:15, Ethernet0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 30.1.1.3,
00:00:15, Ethernet0
R5#show ip route ospf
172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via 30.1.1.3,
00:02:25, Ethernet0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 30.1.1.3,
00:02:25, Ethernet0

When you have multiple border
routers and you’re configuring one
of them for redistribution, be sure to
watch the others for ill effects of
redistribution.

R2’s
routing
redistribution:

table

before

R2#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
R2#show ip route ospf
R2# (No OSPF routes to show)

R2’s
routing
redistribution:

table

R2#show ip route rip
R2# (No RIP routes to show)
R2#show ip route ospf

after

10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 30.1.1.3,
00:04:14, Ethernet0

We don’t expect 172.12.123.0/24 to
show up in R2’s RIP or OSPF
routing table, because it’s a directly
connected network. However, the
route to 10.1.1.0 /24 is now using
R3’s Ethernet0 as a next-hop
address, and it’s now an OSPF
route.
Packets from R2 destined for the
10.1.1.0 /24 network will now take
a longer path than they would have
before
redistribution
was
configured on R3. Previously, such

packets would have gone straight to
R1; now, those packets will go to
R3, then R1. Hello, suboptimal
routing!

Why did R2 choose the longer path?
After redistribution is configured on
R3, R2 is receiving two routes for
the network 10.1.1.0/24. One is

from R1 via RIP; the other is from
R3 via OSPF. (The OSPF update is
shown with a two-headed arrow to
indicate that every router on the
broadcast segment will receive the
update sent by R3.)
The prefix length of /24 is
contained with both updates, so
there has to be a tiebreaker, and that
tiebreaker is AD. OSPF has an AD
of 110, where RIP’s is 120, so the
OSPF route is chosen.
You would have noticed this by
looking at the table, but it’s a good
idea to check all routes on a border

router that is not performing
redistribution - and you can perform
that checking with the traceroute
command.
This command shows you the exact
path data is taking to reach the
destination, which gives you an
idea of whether suboptimal routing
has occurred.
R2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1,
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip
min/avg/max = 68/68/72 ms

R2#traceroute 10.1.1.1
Type escape sequence to abort.
Tracing the route to 10.1.1.1
1 30.1.1.3 8 msec 4 msec 20 msec
2 172.12.123.1 36 msec * 36 msec

Our basic IP connectivity test, ping,
shows that we still have
connectivity to 10.1.1.0/24. The
problem is that this data is taking
the long way to get there, with a
next-hop of 30.1.1.3.
With suboptimal routing, we
basically have three different
approaches to resolving the issue:

Changing the administrative
distance
Changing the route’s metrics
Filtering routes with
distribute-lists (covered in a
later section)
Let’s apply the first option….
To change the AD of a protocol on a
router, use the distance command
under the appropriate routing
process. We’ll use this command to

change the AD of OSPF on R2 to
200.
R2(config)#router ospf 1
R2(config-router)#distance ?
<1-255> Administrative distance
ospf
OSPF distance
R2(config-router)#distance 200
R2#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:02, Serial0

R2#show ip route ospf
< No OSPF routes to show >
R2#traceroute 10.1.1.1

Type escape sequence to abort.
Tracing the route to 10.1.1.1
1 172.12.123.1 36 msec * 36 msec

The RIP route is now preferred
because all OSPF routes on R2
have an AD of 200. The next-hop IP
address is now 172.12.123.1, the
direct path to 10.1.1.0 /24.
If we shut down the RIP-enabled
interface on R2, the OSPF routes
will be put into the routing table.
You can see the OSPF route’s AD
has been successfully changed to
200.
R2#show ip route ospf

172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [200/20] via 30.1.1.3,
00:00:04, Ethernet0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [200/20] via 30.1.1.3,
00:00:05, Ethernet0

In effect, we turned the OSPF routes
into something similar to a floating
static route - the higher AD
guarantees the OSPF routes will
appear in the table only if the RIP
routes disappear.
You have to be truly careful using
any “all-or-nothing” command
when it comes to your routing table,
and the distance command does just
that -it changes the AD of all the

routes acquired by that particular
protocol.
More likely, you’ll want to change
the AD of some routes rather than
all of them. To do so, you can write
an ACL identifying the routes
whose AD you want to affect and
tie that ACL in with the distance
command.
To illustrate, let’s take a routing
table from another lab. R2 has three
routes in its EIGRP routing table,
all with an AD of 90.
R2#show ip route eigrp
3.0.0.0/32 is subnetted, 1 subnets

D
3.3.3.3 [90/409600] via 172.12.23.3,
00:00:28, Ethernet0
4.0.0.0/32 is subnetted, 1 subnets
D
4.4.4.4 [90/409600] via 172.12.23.3,
00:00:28, Ethernet0
5.0.0.0/32 is subnetted, 1 subnets
D
5.5.5.5 [90/409600] via 172.12.23.3,
00:00:28, Ethernet0

Let’s double the AD of the route for
4.4.4.4 while leaving the other
routes alone. ACL 5 identifies that
route and that route only, and then
we just use that ACL number at the
end of the distance command.
R2(config)#access-list 5 permit 4.4.4.4 0.0.0.0
R2(config)#router eigrp 100
R2(config-router)#distance

180

0.0.0.0

255.255.255.255 ?

<1-99>

<13001999>

WORD

R2(config-router)#distance
255.255.255.255 5

IP Standard
access list
number
IP Standard
expanded
access list
number
Standard
access-list
name
180

0.0.0.0

After clearing the route table, the
route to 4.4.4.4 now has an AD of
180, while the other distances

remain the same.
R2#show ip route eigrp
3.0.0.0/32 is subnetted, 1 subnets
D
3.3.3.3 [90/409600] via 172.12.23.3,
00:00:27, Ethernet0
4.0.0.0/32 is subnetted, 1 subnets
D
4.4.4.4 [180/409600] via 172.12.23.3,
00:00:27, Ethernet0
5.0.0.0/32 is subnetted, 1 subnets
D
5.5.5.5 [90/409600] via 172.12.23.3,
00:00:27, Ethernet0

Anytime you have two dynamic
routing protocols operating in the
same network and redistribution is
involved, you may find it helpful to
fine-tune a route or two in this
fashion.

For example, if a network is
running OSPF and RIPv2, the OSPF
route will always be selected if AD
is the determining factor. You may
have some RIP routes that are
actually optimal, but won’t be used.
Now you know how to selectively
change the AD of those particular
RIP routes.
Default-Information
(Always?)

Originate

You’ll see the following discussion
in the Multi-Area OSPF section as
well.
Since
this
command
redistributes a default route, I’m

putting it here as well.
It’s worth seeing again.
You know that default routes are
generated in OSPF when stub and
total stub areas are involved.
You also know that you can’t make
Area 0 a stub area.
What we can do is run the OSPF
command
default-information
originate with the always option to
send a default route to all other
OSPF routers -- and that includes
routers in Area 0.

The always option allows the router
to propagate 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. If
there is no default route to
advertise, neighbors will not
receive a default route!
Here, both R2 and R3 will have the
same next-hop address for every
remote destination - R1’s serial0
interface, 172.12.123.1.

That fact would simply scream at us
to configure this as a stub or total
stub area, but there’s just one
problem …
R1(config)#router ospf 1
R1(config-router)#area 0 stub
OSPF: Backbone can not be configured as stub
area
R1(config-router)#area 0 stub ?

no-summary Do not send summary LSA into
stub area
<cr>
R1(config-router)#area 0 stub no-summary
OSPF: Backbone can not be configured as stub
area

…. all three routers are in Area 0,
and we can’t config A0 as any kind
of stub.
We can use the default-information
originate command to send a
default route from R1 to the spoke
routers. Assuming R1 does not have
a default route in its own table,
we’ll need to use the always option.
Here’s what happens if we don’t:

R1(config-router)#default-information ?
originate Distribute a default route
R1(config-router)#default-information originate
?

always

metric

metrictype
route-

Always
advertise
default
route
OSPF
default
metric
OSPF
metric type
for default
routes
Route-map

map
<cr>

reference

R1(config-router)#default-information originate
R2#show ip route ospf
R2#

Nothing on R2 or R3. We’ll go back
to R1, remove the first version of
the command, and replace it with
the same command and the always
option.
R1(config-router)#no
default-information
originate
R1(config-router)#default-information originate
always

And now to R2 and R3 ….
R2#show ip route ospf
O*E2 0.0.0.0/0 [110/1]
00:00:10, Serial0

via

172.12.123.1,

R3#show ip route ospf
O*E2 0.0.0.0/0 [110/1]
00:00:15, Serial0

via

172.12.123.1,

Both routers have the route, marked
as both a candidate default route
and an E2 route. Unlike stub areas,
this route does not automatically
replace any routes already present
in the receivers’ route tables. You’ll
have to filter those some other way
- shortly, we’ll do just that.

ip default-gateway vs. ip defaultnetwork
The ip default-network command
can be used to inject a default route
into your routing process, too.
Maybe.
If the router has an interface
directly connected to the network
specified with this command, the
router will generate a default route
and send that route to its neighbor
routers.
This command can be a little tricky

to use, and it works differently with
different protocols. Here, R1 and
R2 are both running RIPv2. When a
gateway of last resort is configured
using ip default-network on R1,
RIP will advertise a default route of
0.0.0.0 to R2.
Additionally, RIP does not need to
know about the network configured
as the default. R1 will name the
network 13.0.0.0 /8 as the default
network. This route is not being
advertised by RIP, but R2 still has
the default route.
R1(config)#ip default-network 13.0.0.0

R2#show ip route
< code table deleted for clarity >
Gateway of last resort is 172.12.123.1 to
network 0.0.0.0
172.12.0.0/24 is subnetted, 1 subnets
C
172.12.123.0 is directly connected,
Serial0
30.0.0.0/24 is subnetted, 1 subnets
C
30.1.1.0 is directly connected,
Ethernet0
R* 0.0.0.0/0 [120/1] via 172.12.123.1,
00:00:25, Serial0

In contrast, EIGRP has to know
about the default network via either
a network command or a static
route redistribution.

It’s easy to get ip default-network
and ip default-gateway mixed up.
They’re both used to generate a
default route. The key difference is
that ip default-gateway is used
when IP routing is off, while ip
default-network is used when IP
routing is on.
And after all the redistribution
we’ve done here, redistributing a
static route is simple enough - just
watch the seed metric requirements
of the protocol receiving that route.
R1(config)#router rip
R1(config-router)#redistribute ?

Border

bgp
connected
egp

eigrp

igrp

Gateway
Protocol
(BGP)
Connected
Exterior
Gateway
Protocol
(EGP)
Enhanced
Interior
Gateway
Routing
Protocol
(EIGRP)
Interior
Gateway
Routing

isis
iso-igrp

metric
mobile
odr

ospf

Protocol
(IGRP)
ISO IS-IS
IGRP for
OSI
networks
Metric for
redistribute
routes
Mobile
routes
On Demand
stub Routes
Open
Shortest
Path First

rip
routemap
static

(OSPF)
Routing
Information
Protocol
(RIP)
Route map
reference
Static
routes

<cr>
R1(config-router)#redistribute static metric 1

EIGRP Redistribution
We’ll keep RIP for the protocol

running between R1, R2, and R3.
10.1.1.0 /24 is still advertised by
RIP. The protocol running over the
ethernet segment is now EIGRP.

EIGRP has a default seed metric of
“infinity”, and we need to define a
seed metric when we perform the
redistribution. With EIGRP, that

means defining
settings.

five

different

There are two ways to set the seed
metric with EIGRP:
Set the metric for the
redistributed routes learned
from a specific source at the
end of the redistribute
command.
Use the default-metric
command to set the default
metric for all routes being
redistributed.

We’ll use the first method in this
example. Note that the redistribute
command is incomplete until all
five metrics have been defined.
Unlike RIP, EIGRP will not allow
you to redistribute routes into an AS
without specifying the seed metric.
Ignore the mention of “IGRP” in
IOS Help - that’s just an IOS quirk.
R3(config)#router eigrp 100
R3(config-router)#redistribute rip metric ?
<1-4294967295> Bandwidth metric in
Kbits per second
R3(config-router)#redistribute rip metric 1544 ?

<0-4294967295> IGRP delay metric, in 10
microsecond units
R3(config-router)#redistribute rip metric 1544
10 ?
<0-255> IGRP reliability metric where
255 is 100% reliable
R3(config-router)#redistribute rip metric 1544
10 255 ?
<1-255> IGRP Effective bandwidth
metric (Loading) where 255 is 100%
loaded
R3(config-router)#redistribute rip metric 1544
10 255 1 ?
<1-4294967295> IGRP MTU of the path
R3(config-router)#redistribute rip metric 1544
10 255 1 1500
R3(config-router)#redistribute connected metric

1544 10 255 1 1500

The values I put in are typical
EIGRP redistribution values. For
your CCNP ROUTE exam, it’s an
excellent idea to have the order of
those values down cold. On a
production router, you can always
use IOS Help to remind you of the
order.
Let’s check R4 and R5 to see if
their EIGRP tables show the
redistributed routes.
R4#show ip route eigrp 100
172.12.0.0/24 is subnetted, 1 subnets
D EX
172.12.123.0 [170/1686016] via
30.1.1.3, 00:02:04, Ethernet0

10.0.0.0/24 is subnetted, 1 subnets
D EX
10.1.1.0 [170/1686016] via 30.1.1.3,
00:02:04, Ethernet0
R5#show ip route eigrp
172.12.0.0/24 is subnetted, 1 subnets
D EX
172.12.123.0 [170/1686016] via
30.1.1.3, 00:02:29, Ethernet0
10.0.0.0/24 is subnetted, 1 subnets
D EX
10.1.1.0 [170/1686016] via 30.1.1.3,
00:02:29, Ethernet0

The routes have been redistributed
successfully into EIGRP. The
redistributed route is marked with
“D EX”, indicating that it is an
EIGRP External route. As seen in
the brackets, the AD of these routes
is 170 by default, as opposed to the
AD of 90 for EIGRP internal routes

and 5 for EIGRP Summary routes.
We can also use the default-metric
command to set the seed metric.
This will set the seed metric for all
routes redistributed into EIGRP.
R2(config)#router eigrp 100
R2(config-router)#default-metric 1544 10 255 1
1500

Let’s now look at R2’s RIP and
EIGRP routing tables, before and
after redistribution.
Before redistribution:
R2#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets

R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
R2#show ip route eigrp
R2# (No EIGRP routes to show)

After redistribution:
R2#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
R2#show ip route eigrp
R2# (No EIGRP routes to show)

The tables on R2 are exactly the
same after redistribution.

Why is R2 choosing to put the RIP
route into its table rather than the
EIGRP route?

R2 is receiving a RIP update
containing the route with an AD of
120, where the external EIGRP
update coming in on its ethernet

interface has an AD of 170. The
lowest AD is preferred, so the RIP
route is still considered the best
route.
If we wanted the EIGRP path to be
preferred, we could change its AD
on R2. We’ll change the default AD
of EIGRP External routes on R2 to
119, just one less than the AD of
120. The command is a little
different for EIGRP (like every
other EIGRP command, right?)
R2(config)#router eigrp 100
R2(config-router)#distance ?
<1-255> Administrative distance
eigrp IP-EIGRP distance

R2(config-router)#distance eigrp ?
<1-255> Distance for internal routes
R2(config-router)#distance eigrp 90 ?
<1-255> Distance for external routes
R2(config-router)#distance eigrp 90 119

Note that when you want to change
only one EIGRP AD, you still need
to specify the value of each with
this command.
The result on R2’s routing tables:
R2#show ip route rip
R2#show ip route eigrp
10.0.0.0/24 is subnetted, 1 subnets
D EX
10.1.1.0 [119/1686016] via

30.1.1.3, 00:01:45, Ethernet0

This skill becomes even more
valuable when you’re configuring
two-way route redistribution, since
changing the AD of one of your
routing protocols can help prevent
routing loops.
Verifying Redistribution
“Show IP Protocols”

With

When
configuring
route
redistribution or changing default
values, you need to run show ip
protocols to make sure you are
getting the results you thought
you’d be getting.

Here is the command output on R3:

You can see that connected routes
are being redistributed into RIP, that
autosummarization is turned off,
version 2 has been hard-coded, and
RIP updates are being received
from 172.12.123.1.

The rest of the output:

The EIGRP portion of the command
from top to bottom shows…
The metric weights have not
been changed
Unequal-cost load balancing is
in effect (variance is set to 1)

RIP and connected routes are
being redistributed into EIGRP
No EIGRP updates are coming
in from other routers
Default ADs have not been
changed
Controlling Redistributed Routes
Not only can you use the distance
command to alter route selection

after redistribution, but you can also
control which routers will receive
the redistributed routes in the first
place. Even better, many of the
tools at our disposal are features
you’re already familiar with.
Certain
routing
protocols,
particularly OSPF, will generate
default routes under certain
circumstances. They can be helpful
in
avoiding
routing
loops,
especially if a default route is
configured instead of performing
two-way redistribution. We’re
always trying to avoid two-way
redistribution!

If you want each router in this
network to be able to reach every
other network, a default route could
be sent into one routing domain
while one-way redistribution is
performed with the other. For

instance, a default route could be
generated by the ASBR (R1) for R3
and R4 to use. The OSPF routes
could then be redistributed into the
RIP domain.
We could use one of two techniques
with OSPF to make this happen,
depending on whether we’re
dealing with Area 0:
If we are, default-information
originate (always) would
come in handy.
If we’re not, making the area a

stub or total stub route would
be the direction to go in.

Passive Interfaces
Passive interfaces can be a big help
in controlling routing updates and
or/
routing
control
traffic,
depending on which protocol
you’re dealing with:
RIP: Passive interfaces do not send
routing updates, but will accept
them. RIP adjacencies aren’t
affected by passive interfaces since
RIP doesn’t have adjacencies in the

first place.
In the following example, R1’s
Ethernet0 interface has been
configured as passive. R1’s
loopback 10.1.1.1 /24 is advertised
into RIP. The R1-R2-R3 network is
our usual Frame Relay network,
172.12.123.0 /24.

R1’s config:
router rip
version 2
passive-interface Ethernet0
network 10.0.0.0
network 30.0.0.0
network 172.12.0.0
no auto-summary

Both R2 and R3 see the loopback
and the 30.1.1.0 subnet.
R2#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:15, Serial0
30.0.0.0/24 is subnetted, 1 subnets
R
30.1.1.0 [120/1] via 172.12.123.1,
00:00:15, Serial0

R3#show ip route rip
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:21, Serial0
30.0.0.0/24 is subnetted, 1 subnets
R
30.1.1.0 [120/1] via 172.12.123.1,
00:00:21, Serial0

R5 does not see R1’s loopback - the
passive interface is not sending
routing updates to R5.
R5#show ip route rip
R5#

Let’s add the loopback on R5 to the
RIP process and see if R1 sees it:
R5(config)#router rip
R5(config-router)#network 5.0.0.0

R1#show ip route rip
5.0.0.0/24 is subnetted, 1 subnets
R
5.1.1.0 [120/1] via 30.1.1.5, 00:00:14,
Ethernet0

R1 does see the route. A RIP
passive interface will not send
routing updates, but it will accept
them. This partial output of debug
ip rip proves that R1 is multicasting
updates via Serial0, but not E0, and
is receiving updates from all other
routers in the domain.
EIGRP: Hellos aren’t sent, so no
adjacency can be formed via a
passive interface. If an adjacency
exists on an interface that is then

made passive, the adjacency is
dropped. A subnet running a
passive interface can be advertised.
We’ll use the exact same topology
from the previous lab in this
example and enable EIGRP on the
Frame Relay and Ethernet segments.

R1 has adjacencies to all of the

other routers in the AS, R2 and R3
see the 30.1.1.0 /24 network, and
R5 sees the 172.12.123.0 /24
network.

What will the impact be when we
make e0 passive? Let’s find out!

The first impact is the lost
adjacency between R1 and R5.
EIGRP passive interfaces do not
send Hellos, and we know what
happens when that doesn’t happen.
As a result, R5 loses the EIGRP
route for the Frame Relay network.
R5#show ip route eigrp
R5#

What about R2 and R3? Will they
still see the 30.1.1.0 /24 network?

R2#show ip route eigrp
30.0.0.0/24 is subnetted, 1 subnets
D
30.1.1.0 [90/2195456] via
172.12.123.1, 00:08:47, Serial0
R3#show ip route eigrp
30.0.0.0/24 is subnetted, 1 subnets
D
30.1.1.0 [90/2195456] via
172.12.123.1, 00:08:52, Serial0

Yes, they do! EIGRP passive
interfaces do not send Hellos, but
the subnet running on that passive
interface can still be advertised via
the network command.
OSPF: Passive interfaces do not
send OSPF Hellos, so no adjacency

can be formed, and existing
adjacencies are lost on interfaces
that are then configured as passive.
Additionally, the subnet running on
the passive interface will be
advertised as a stub network.
We’ll use the same topology as the
previous two labs for this example.

R1 has an OSPF neighbor
relationship with all other routers in
the network:

The other routers see 1 OSPF route.
R2#show ip route ospf
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.12.123.1,
00:02:52, Serial0
R3#show ip route ospf
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.12.123.1,
00:02:57, Serial0
R5#show ip route ospf

172.12.0.0/24 is subnetted, 1 subnets
O
172.12.123.0 [110/74] via 30.1.1.1,
00:03:02, Ethernet0

Let’s make E0 passive and watch
the results.
We know what the first result is
going to be…
R1(config)#router ospf 1
R1(config-router)#passive-int ethernet0
00:40:56: %OSPF-5-ADJCHG: Process 1, Nbr
5.1.1.1 on Ethernet0 from FULL to
DOWN,
Neighbor Down: Interface down or detached

The R1 - R5 adjacency is lost
immediately, and we know R5 lost

its OSPF route as a result. But is the
30.1.1.0
/24
network
still
advertised into OSPF?
R2#show ip route ospf
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.12.123.1,
00:01:47, Serial0
R3#show ip route ospf
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.12.123.1,
00:01:54, Serial0

Yes, it is! Just as with EIGRP, the
adjacency through the now passive
interface is lost, but the subnet is
still advertised via the network
command.

You can set all interfaces on a
router as passive for a given
protocol with the passive-interface
default command.
R3(config)#router ospf 1
R3(config-router)#passive-interface default

To set the interfaces back to their
default, just use the no passiveinterface default command.
R3(config-router)#no passive-interface default

Using Distribute-Lists To Control
Redistribution
Once

you

perform

route

redistribution, you’ll often find that
you need to fine-tune the process by
allowing some routes to be
redistributed while preventing
redistribution of other routes. We
can do that with distribute-lists.
A distribute-list uses an ACL to
define the routes to be redistributed
-and explicitly or implicitly
prohibited from redistribution.
Here’s the network for the first
example:

R1 is receiving RIP updates from
R5 for six networks:
R1#show ip route rip
5.0.0.0/24 is subnetted, 1 subnets
R
5.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
6.0.0.0/24 is subnetted, 1 subnets
R
6.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
7.0.0.0/24 is subnetted, 1 subnets
R
7.1.1.0 [120/1] via 30.1.1.5, 00:00:09,

Ethernet0
8.0.0.0/24 is subnetted, 1 subnets
R
8.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
9.0.0.0/24 is subnetted, 1 subnets
R
9.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 30.1.1.5,
00:00:09, Ethernet0

If we perform redistribution as we
have throughout this section, the
OSPF routers would see all of
those routes - as shown here.
R1(config)#router ospf 1
R1(config-router)#redistribute rip subnets
R1(config-router)#redistribute
connected
subnets

R2#show ip route ospf
5.0.0.0/24 is subnetted, 1 subnets
O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
6.0.0.0/24 is subnetted, 1 subnets
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
7.0.0.0/24 is subnetted, 1 subnets
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
8.0.0.0/24 is subnetted, 1 subnets
O E2
8.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
9.0.0.0/24 is subnetted, 1 subnets
O E2
9.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
30.0.0.0/24 is subnetted, 1 subnets
O E2
30.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0

R3#show ip route ospf
5.0.0.0/24 is subnetted, 1 subnets
O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
6.0.0.0/24 is subnetted, 1 subnets
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
7.0.0.0/24 is subnetted, 1 subnets
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
8.0.0.0/24 is subnetted, 1 subnets
O E2
8.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
9.0.0.0/24 is subnetted, 1 subnets
O E2
9.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
30.0.0.0/24 is subnetted, 1 subnets
O E2
30.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0

What if we don’t want those routers
to know about the existence of the
8.1.1.0 and 9.1.1.0 networks? We
can write an ACL identifying those
networks as networks to be denied,
and then apply that ACL to the
redistribution process via the
distribute-list command.
R1(config)#access-list 17 deny 8.1.1.0 0.0.0.255
R1(config)#access-list 17 deny 9.1.1.0 0.0.0.255
R1(config)#access-list 17 permit any

Remember when you thought
writing an ACL was hard? Now it’s
second nature to you. All we need
to do is apply the command to the
Serial0 interface in the OSPF

config…
R1(config-router)#distribute-list 17 out serial0
% Interface not allowed with OUT for OSPF

D’oh!
Filtering routes with OSPF is just a
little tricky, since we’re not
filtering routes per se as we would
with RIP or EIGRP. We deal with
LSAs in link state protocols, and
we can’t start filtering LSAs or our
OSPF databases in an area won’t
be synched.
Let’s try specifying a protocol there
instead of an interface.

R1(config-router)#distribute-list 17 out rip

We didn’t get an error message, so
let’s check the OSPF tables on R2
and R3…
R2#show ip route ospf
5.0.0.0/24 is subnetted, 1 subnets
O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
6.0.0.0/24 is subnetted, 1 subnets
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
7.0.0.0/24 is subnetted, 1 subnets
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
30.0.0.0/24 is subnetted, 1 subnets
O E2
30.1.1.0 [110/20] via 172.12.123.1,

00:02:04, Serial0
R3#show ip route ospf
5.0.0.0/24 is subnetted, 1 subnets
O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
6.0.0.0/24 is subnetted, 1 subnets
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
7.0.0.0/24 is subnetted, 1 subnets
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
10.0.0.0/24 is subnetted, 1 subnets
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
30.0.0.0/24 is subnetted, 1 subnets
O E2
30.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0

Success!

If I wanted to go one step further
and stop those two routes from
being put into R1’s routing table, I
could have put the distribute-list in
the RIP process.
R1(config)#router rip
R1(config-router)#distribute-list 17 ?

in
out

Filter incoming
routing updates
Filter outgoing
routing updates

R1(config-router)#distribute-list 17 in ?

BRI

ISDN
Basic
Rate
Interface

Ethernet
Loopback
Null
Serial
<cr>

IEEE
802.3
Loopback
interface
Null
interface
Serial

R1(config-router)#distribute-list 17 in ethernet0

The resulting RIP table on R1:
R1#show ip route rip
5.0.0.0/24 is subnetted, 1 subnets

R
5.1.1.0 [120/1] via 30.1.1.5, 00:00:00,
Ethernet0
6.0.0.0/24 is subnetted, 1 subnets
R
6.1.1.0 [120/1] via 30.1.1.5, 00:00:00,
Ethernet0
7.0.0.0/24 is subnetted, 1 subnets
R
7.1.1.0 [120/1] via 30.1.1.5, 00:00:00,
Ethernet0
10.0.0.0/24 is subnetted, 1 subnets
R
10.1.1.0 [120/1] via 30.1.1.5,
00:00:00, Ethernet0

Distribute-lists can also be used to
filter all routes from being
advertised via a certain interface without making that interface
passive and losing the adjacency.
Let’s use an EIGRP topology that
we used earlier in this section, but

we’ll advertise routes from R2 in
this lab.

Here are those routes on R1:
R1#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D
2.2.2.0 [90/2297856] via
172.12.123.2, 00:00:09, Serial0
22.0.0.0/24 is subnetted, 1 subnets
D
22.2.2.0 [90/2297856] via
172.12.123.2, 00:00:04, Serial0

And on R5:
R5#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D
2.2.2.0 [90/2323456] via 30.1.1.1,
00:00:15, Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
D
172.12.123.0 [90/2195456] via
30.1.1.1, 00:01:29, Ethernet0
22.0.0.0/24 is subnetted, 1 subnets
D
22.2.2.0 [90/2323456] via 30.1.1.1,
00:00:10, Ethernet0

What if we don’t want R5 to see
any of those routes - but we need to
keep the adjacency? That means we
can’t make E0 passive, but we can
filter all routes coming in from R1.
A one-line ACL denies all traffic

explicitly:
R1(config)#access-list 25 deny any
We apply it to the EIGRP process:
R1(config)#router eigrp 100
R1(config-router)#distribute-list 25 ?

in
out

Filter incoming
routing updates
Filter outgoing
routing updates

R1(config-router)#distribute-list 25 out ?

BRI

ISDN
Basic Rate
Interface
IEEE

Ethernet
Loopback
Null
Serial
bgp
connected
egp

802.3
Loopback
interface
Null
interface
Serial
Border
Gateway
Protocol
(BGP)
Connected
Exterior
Gateway
Protocol
(EGP)
Enhanced

eigrp

igrp

ospf

rip

Interior
Gateway
Routing
Protocol
(EIGRP)
Interior
Gateway
Routing
Protocol
(IGRP)
Open
Shortest
Path First
(OSPF)

Routing
Information
Protocol

static

(RIP)
Static
routes

<cr>
R1(config-router)#distribute-list 25 out ethernet0

And we go to R5…
R5#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D
2.2.2.0 [90/2323456] via 30.1.1.1,
00:11:36, Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
D
172.12.123.0 [90/2195456] via
30.1.1.1, 00:12:50, Ethernet0
22.0.0.0/24 is subnetted, 1 subnets
D
22.2.2.0 [90/2323456] via 30.1.1.1,
00:11:31, Ethernet0

… and the routes are still there.
Been there for over 11 minutes, too.
Why?
EIGRP only sends routing updates
when there’s a change in the
network - and a distribute-list being
applied is not considered such a
change.
We need to force a routing update
with clear ip route *, after which
we’ll check the EIGRP table on R5
immediately.
R5#clear ip route *
R5#

R5#show ip route eigrp
< nothing to show >

R5#

Sometimes a little route clearing is
all it takes!
You can verify your distribute-list
operation with debug ip eigrp…
R1#debug ip eigrp
IP-EIGRP Route Events debugging is on
02:11:27: %LINK-3-UPDOWN: Interface
Serial0, changed state to down
02:11:27: IP-EIGRP: 172.12.123.0/24 - denied by
distribute list
02:11:27: IP-EIGRP: Int 172.12.123.0/24 metric
4294967295 - 0 4294967295

02:11:27: IP-EIGRP: 2.2.2.0/24 - denied by
distribute list
02:11:27: IP-EIGRP: Int 2.2.2.0/24 metric
4294967295 - 1657856 4294967295
02:11:27: IP-EIGRP: 22.2.2.0/24 - denied by
distribute list

… as well as our old buddy show
ip protocols.
R1#show ip protocols
Routing Protocol is “eigrp 100”
Outgoing update filter list for all interfaces is
not set
Redistributed eigrp 100 filtered by 25
Incoming update filter list for all interfaces is
not set

We can use the distribute-list
command to filter EIGRP routing
updates when redistribution is

involved, too. For this lab we’ll use
a slightly different topology.
R1 - R2 link: 172.12.123.0 / 24
R1 - R3 link: 172.13.13.0 /24
R1 - R5 link: 30.1.1.0 /24

R1 is learning two routes via RIP

from R2.
R1#show ip route rip
2.0.0.0/24 is subnetted, 1 subnets
R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:52, Serial0
22.0.0.0/24 is subnetted, 1 subnets
R
22.2.2.0 [120/1] via 172.12.123.2,
00:00:52, Serial0

After performing redistribution of
both RIP and connected routes into
EIGRP 100 …
R1(config)#router eigrp 100
R1(config-router)#default-metric 1500 10 255 1
1500
R1(config-router)#redistribute connected
R1(config-router)#redistribute rip

… both R3 and R5 see the two RIP
routes and the 172.12.123.0 /24
network as EIGRP external routes.
R5#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D EX
2.2.2.0 [170/1734656] via 30.1.1.1,
00:00:16, Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
D EX
172.12.123.0 [170/2195456] via
30.1.1.1, 00:00:11, Ethernet0
172.13.0.0/24 is subnetted, 1 subnets
D
172.13.13.0 [90/2195456] via
30.1.1.1, 00:06:28, Ethernet0
22.0.0.0/24 is subnetted, 1 subnets
D EX
22.2.2.0 [170/1734656] via 30.1.1.1,
00:00:16, Ethernet0
R3#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D EX
2.2.2.0 [170/2221056] via

172.13.13.1, 00:00:31, Serial1
172.12.0.0/24 is subnetted, 1 subnets
D EX
172.12.123.0 [170/2681856] via
172.13.13.1, 00:00:26, Serial1
22.0.0.0/24 is subnetted, 1 subnets
D EX
22.2.2.0 [170/2221056] via
172.13.13.1, 00:00:31, Serial1
30.0.0.0/24 is subnetted, 1 subnets
D
30.1.1.0 [90/2195456] via
172.13.13.1, 00:06:25, Serial1

What if we didn’t want R5 to see
any of those routes, but for R3 to
continue to see all of them?
First, write a one-line ACL denying
all traffic…
R1(config)#access-list 47 deny any

… and apply that in the EIGRP
config with the distribute-list
command, referencing the interface
leading to R5.
R1(config)#router eigrp 100
R1(config-router)#distribute-list 47 out ethernet0

The result: R5 has none of the
routes….
R5#show ip route eigrp
R5#

… and R3 still sees them all.
R3#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D EX
2.2.2.0 [170/2221056] via
172.13.13.1, 00:05:56, Serial1

172.12.0.0/24 is subnetted, 1 subnets
D EX
172.12.123.0 [170/2681856] via
172.13.13.1, 00:05:51, Serial1
22.0.0.0/24 is subnetted, 1 subnets
D EX
22.2.2.0 [170/2221056] via
172.13.13.1, 00:05:56, Serial1
30.0.0.0/24 is subnetted, 1 subnets
D
30.1.1.0 [90/2195456] via
172.13.13.1, 00:11:50, Serial1

We filtered all of the routes going to
R5, but kept the adjacency.
But -- and you knew that was
coming -- what if we now want to
filter a route from reaching R3, but
we need to use a different
distribute-list?
That new requirement brings up

three new questions..
Can we even use more than
one distribute-list on the same
router?
If so, can we use them in the
same routing protocol config?
If we can, what’s the net effect
to all of our routing tables?
Let’s find out. The new requirement
is that R3 should not see the
30.1.1.0 /24 network, but continue

to see the external routes. We’ll
write an ACL identifying the route
to be denied…
R1(config)#access-list 33 deny
0.0.0.255
R1(config)#access-list 33 permit any

30.1.1.0

…. and write another distribute-list
in the EIGRP config,but we will not
specify an interface or protocol.
R1(config)#router eigrp 100
R1(config-router)#distribute-list 33 ?

in
out

Filter incoming
routing updates
Filter outgoing
routing updates

R1(config-router)#distribute-list 33 out ?

BRI
Ethernet
Null
Serial
bgp
connected
egp

ISDN
Basic Rate
Interface
IEEE
802.3
Null
interface
Serial
Border
Gateway
Protocol
(BGP)
Connected
Exterior
Gateway

eigrp

igrp

ospf

Protocol
(EGP)
Enhanced
Interior
Gateway
Routing
Protocol
(EIGRP)
Interior
Gateway
Routing
Protocol
(IGRP)
Open
Shortest
Path First

rip

static

(OSPF)
Routing
Information
Protocol
(RIP)
Static
routes

<cr>
R1(config-router)#distribute-list 33 out

The routing table on R3:
R3#show ip route eigrp
2.0.0.0/24 is subnetted, 1 subnets
D EX
2.2.2.0 [170/2221056] via
172.13.13.1, 00:00:17, Serial1

172.12.0.0/24 is subnetted, 1 subnets
D EX
172.12.123.0 [170/2681856] via
172.13.13.1, 00:00:17, Serial1
22.0.0.0/24 is subnetted, 1 subnets
D EX
22.2.2.0 [170/2221056] via
172.13.13.1, 00:00:17, Serial1

The 30.1.1.0 /24 route has been
successfully filtered -- but what
about the previous distribute-list
and its effect on R5’s routing table?
R5#show ip route eigrp
R5#

The previous distribute-list is still
in effect, since it was specifically
written to filter route updates
leaving e0. “General” distribute-

lists --lists that do not indicate a
specific interface -- do not
overwrite
distribute-lists
that
specifically mention an interface.
Let’s review the current EIGRP
config on R1:
router eigrp 100
redistribute connected
redistribute rip
network 30.1.1.0 0.0.0.255
network 172.13.13.0 0.0.0.255
default-metric 1500 10 255 1 1500
distribute-list 47 out Ethernet0
distribute-list 33 out
no auto-summary
no eigrp log-neighbor-changes

We have a specific distribute-list

and then a general one where an
interface was not specified. In this
case, the specific distribute-list is
applied to the e0 interface, and the
general distribute-list will be
applied to all other interfaces - and in this lab, that includes S1
leading to R3.
Using Route Maps To Change
Route Values And Attributes
Distribute-lists are a powerful tool
in our route redistribution toolbox but sometimes we’ll want to do
more than simply permit or deny
routes to be advertised and

redistributed.
Sometimes we’ll want to set
different metrics for different
routes, and maybe even change an
OSPF external route type or two and we’ll do that with route maps.
Let’s take a look at the mechanics of
route map operation, and then we’ll
apply route maps to our
redistribution labs.
Route maps are somewhat similar
to access-lists. They both come to a
basic decision of “permit” or
“deny”. Route lists give us

additional power over the data
beyond just a simple “transmit” or
“don’t transmit”. With route maps,
we can actually change route
attributes.
Here’s an example of how an ACL
and a route-map work together we’ll use BGP in the example.
R2(config)#access-list 17 permit host 20.1.1.1
R2(config)#route-map ?
WORD Route map tag
R2(config)#route-map CHANGE_NEXT_HOP
?

Sequence
to insert

<065535>

deny

permit

to/delete
from
existing
route-map
entry
Route map
denies set
operations
Route map
permits set
operations

<cr>
R2(config)#route-map CHANGE_NEXT_HOP
permit ?
<0-65535> Sequence to insert to/delete
from existing route-map entry
<cr>

R2(config)#route-map CHANGE_NEXT_HOP
permit 10
R2(config-route-map)#match ip address 17
R2(config-route-map)#set ip next-hop 10.1.1.1
R2(config-route-map)#set ?

as-path

automatic-tag

comm-list

Prepend
string fo
BGP AS
attribute

Automa
comput
value
set BGP
commun
list (for
deletion
BGP

community

dampening

default

extcommunity

interface
ip

commun
attribute
Set BG
route fl
dampen
parame
Set defa
informa

BGP
extende
commun
attribute
Output
interfac
IP spec
informa

level
localpreference

metric

metric-type

Where
import
BGP lo
prefere
path att
Metric
for
destinat
routing
protoco

Type of
metric f
destinat
routing
protoco
BGP or

origin

tag

weight

code

Tag val
destinat
routing
protoco
BGP w
for rout
table

First, we wrote a standard ACL
specifying the source IP address
20.1.1.1. (Remember, the only
factor that a standard ACL can
match is the source IP address.)
Then we began writing the routemap. We’ll now take a line-by-line

look at how this route map was
written.
R2(config)#route-map ?
WORD Route map tag

A route map has to be named, and
it’s a good idea to give it an
intuitive name. Since we’re going to
change the next-hop IP address of
matching traffic, we’ll call the route
map CHANGE_NEXT_HOP.
R2(config)#route-map CHANGE_NEXT_HOP
?

<0-

Sequence
to insert
to/delete

65535>

deny

permit

from
existing
route-map
entry
Route map
denies set
operations
Route map
permits set
operations

<cr>
Route map statements can be given
a sequence number, and this is a
great help when you want to go
back to an existing route map and

add statements. You do not have to
assign a sequence number, and if
you don’t, the first statement you
enter will be numbered “10” and
each statement after that will have a
sequence number that increments by
10 from the previous statement.
The <cr> indicates that this
command could be entered just as it
is, without a permit or deny
statement. If you do not specify
permit or deny, a route map
statement will default to “permit”.
We’ll use the following topology to
demo route maps and how they

work with route redistribution.
R1 - R2 Link: 172.12.123.0 /24
R1 - R3 Link: 172.13.13.0 /24
R1 - R5 Link: 30.1.1.0 /24

R2 is advertising three networks 2.2.2.0 /24, 22.2.0.0 /24, and

222.2.0.0 /24. R1 sees them in its
RIP routing table:
R1#show ip route rip
R
222.2.2.0/24 [120/1] via
172.12.123.2, 00:00:16, Serial0
2.0.0.0/24 is subnetted, 1 subnets
R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:16, Serial0
22.0.0.0/24 is subnetted, 1 subnets
R
22.2.2.0 [120/1] via 172.12.123.2,
00:00:16, Serial0

For this lab, we have the following
requirements:
2.2.2.0 -- Double the default
seed metric and set the route to
OSPF external type 1.

22.2.0.0 - Keep the default
seed metric, set the route to
OSPF external type 1.
222.2.2.0 -- Do not
redistribute this route at all.
All future redistributed routes
-- allow redistribution with the
default seed metric and OSPF
route type.
That should keep us busy! And the
first step, as always -- identify each
route or group of routes with an

ACL.
R1(config)#access-list
2 permit
2.2.2.0
0.0.0.255
R1(config)#
R1(config)#access-list 22 permit 22.2.2.0
0.0.0.255
R1(config)#
R1(config)#access-list 44 permit 222.2.2.0

Now we’ll start on the route map.
Route maps are named, not
numbered, and I again recommend
you give yours an intuitive name:
R1(config)#route-map RIP2OSPF permit 10
R1(config-route-map)#match ?

as-path

Match B
AS path
list

community

extcommunity

interface

ip
length

Match B
commun
list
Match
BGP/V
extende
commun
list
Match f
hop
interfac
route
IP spec
informa
Packet
length

Match
metric o
route
Match
route-ty
of route
Match t
of route

metric

route-type
tag
R1(config-route-map)#match ip ?

address

next-

Match
address of
route or
match
packet
Match nexthop

hop

routesource

address of
route
Match
advertising
source
address of
route

R1(config-route-map)#match ip address ?

<1199>
<13002699>
WORD

IP accesslist number
IP accesslist number
(expanded
range)
IP accesslist name

prefixlist

Match
entries of
prefix-lists

<cr>
R1(config-route-map)#match ip address 2 ?

<1199>
<13002699>
WORD

IP accesslist number
IP accesslist number
(expanded
range)
IP accesslist name

<cr>
R1(config-route-map)#match ip address 2

All IP addresses matching ACL 2
will match this route-map clause.
Note that you can specify more than
one ACL for a single route map
clause.
What attributes can we set with a
route map?
R1(config-route-map)#set ?

as-path

automatic-tag

Prepend
string fo
BGP AS
attribute
Automa
comput
value

comm-list

community

dampening

default

extcommunity

set BGP
commun
list (for
deletion
BGP
commun
attribute
Set BG
route fl
dampen
parame
Set defa
informa
BGP
extende
commun
attribute

interface
ip
level
localpreference

metric

Output
interfac

IP spec
informa
Where
import
BGP lo
prefere
path att
Metric
for
destinat
routing
protoco
Type of
metric f

metric-type

origin

tag

weight

destinat
routing
protoco

BGP or
code
Tag val
destinat
routing
protoco
BGP w
for rout
table

Plenty of them. Quite a few are
BGP-specific, but here we’ll set
both the metric and metric type for

this route being redistributed into
OSPF.
R1(config-route-map)#set metric ?

+/-<metric>

<04294967295>

Add or
subtrac
metric
Metric
value o
Bandw
in Kbit
per sec

<cr>
R1(config-route-map)#set metric 40
R1(config-route-map)#set metric-type ?

external

IS-IS
external

internal

type-1

type-2

metric
Use IGP
metric as
the MED
for BGP
OSPF
external
type 1
metric
OSPF
external
type 2
metric

<cr>
R1(config-route-map)#set metric-type type-1

We can set more than one attribute
in a route-map clause. Here we’re
doubling the OSPF seed metric of
20 and setting the route type to
OSPF E1 from the default of E2.
The next clause will match ACL 22
and will leave the seed metric at the
default, but will change the OSPF
route type to E1.
R1(config)#route-map RIP2OSPF permit 20
R1(config-route-map)#match ip add 22
R1(config-route-map)#set metric-type type-1

The third clause will match ACL 44
and will deny the route from being
redistributed. Note the deny in the

route-map clause and that no
attribute is actually set - since
we’re denying it in the first place.
R1(config)#route-map RIP2OSPF deny 30
R1(config-route-map)#match ip address 44

That matches all of our three current
routes, but we were also asked to
allow future routes to be
redistributed with the default seed
metric and OSPF route type.
For that, we’ll write what I call a
“catch-all” clause - a clause that
matches any route that wasn’t
specifically matched earlier. This
clause has no match rule, and since

we’re not changing any attributes, it
won’t have any set rules either.
R1(config)#route-map RIP2OSPF perm 40
R1(config-route-map)#

As you’ve now seen, these can get
pretty involved!
Let’s take a look at the route-map as
a whole with show route-map.
R1#show route-map
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 2
Set clauses:
metric 40
metric-type type-1
Policy routing matches: 0 packets, 0 bytes

route-map RIP2OSPF, permit, sequence 20
Match clauses:
ip address (access-lists): 22
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 30
Match clauses:
ip address (access-lists): 44
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 40
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Now after all that, we get to apply
it!
Let’s see the results of the
redistribution without the route-

map.
R1(config)#router ospf 1
R1(config-router)#redis rip subnets
R3#show ip route ospf
O E2
222.2.2.0/24 [110/20] via 172.13.13.1,
00:00:03, Serial1
2.0.0.0/24 is subnetted, 1 subnets
O E2
2.2.2.0 [110/20] via 172.13.13.1,
00:00:03, Serial1
172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:00:03, Serial1
22.0.0.0/24 is subnetted, 1 subnets
O E2
22.2.2.0 [110/20] via 172.13.13.1,
00:00:03, Serial1
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.13.13.1,
00:00:03, Serial1
R5#show ip route ospf

O E2
222.2.2.0/24 [110/20] via 30.1.1.1,
00:00:15, Ethernet0
2.0.0.0/24 is subnetted, 1 subnets
O E2
2.2.2.0 [110/20] via 30.1.1.1, 00:00:15,
Ethernet0
172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via 30.1.1.1,
00:00:15, Ethernet0
172.13.0.0/24 is subnetted, 1 subnets
O
172.13.13.0 [110/74] via 30.1.1.1,
00:00:15, Ethernet0
22.0.0.0/24 is subnetted, 1 subnets
O E2
22.2.2.0 [110/20] via 30.1.1.1,
00:00:15, Ethernet0

Just what we expected. Now let’s
remove that redis statement and
replace it with one that calls the
route-map. We’ll put a “regular”
redistribute connected in there,

too.
R1(config)#router ospf 1
R1(config-router)#redis rip subnets route-map
RIP2OSPF
R1(config-router)#redis conne subnets

The result on R3:
R3#show ip route ospf
2.0.0.0/24 is subnetted, 1 subnets
O
E1 2.2.2.0 [110/104] via 172.13.13.1,
00:01:56, Serial1
172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:01:56, Serial1
22.0.0.0/24 is subnetted, 1 subnets
O
E1 22.2.2.0 [110/84] via 172.13.13.1,
00:01:56, Serial1
30.0.0.0/24 is subnetted, 1 subnets

O
30.1.1.0 [110/74] via 172.13.13.1,
00:01:56, Serial1

Let’s review the route-map on R1
and check the impact on R3:
R1#show route-map
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 2
Set clauses:
metric 40
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 20
Match clauses:
ip address (access-lists): 22
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 30
Match clauses:

ip address (access-lists): 44
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 40
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Clause 10: 2.2.2.0 had its seed
metric doubled and is marked
as an E1 route. Since E1
routes reflect the entire path to
the destination, the cost is not
the doubled seed metric of 40,
but 104.
Clause 20: 22.2.2.0 did not
have its seed metric doubled

and is marked as an E1 route so again the cost is higher than
the default seed of 20.
Clause 30: 222.2.2.0 does not
appear in the routing table at
all, having been successfully
filtered from redistribution.
172.12.123.0 was redistributed via
the
redistribute
connected
command, which did not have a
route-map applied, and so we see
the usual defaults there - the route is
an E2 route and has the default seed

metric of 20.
Great stuff! Route maps are a very
powerful tool in controlling
redistribution
and
changing
attributes when needed - they’re not
just for BGP configs.
Hey, there’s one more thing we
need to test - remember the last
requirement?
All future redistributed routes
-- allow redistribution with
the default seed metric and
OSPF route type.

Let’s add a RIP route to the network
on R2 and see if it’s redistributed
into OSPF at R1 with the defaults.
The route is created and added to
RIP…
R2(config)#int loopback 55
R2(config-if)#ip address 55.5.5.5 255.255.255.0
R2(config-if)#router rip
R2(config-router)#network 55.0.0.0

…. the route is seen in R1’s RIP
routing table…
R1#show ip route rip
R
222.2.2.0/24 [120/1] via
172.12.123.2, 00:00:02, Serial0
2.0.0.0/24 is subnetted, 1 subnets
R
2.2.2.0 [120/1] via 172.12.123.2,

00:00:02, Serial0
55.0.0.0/24 is subnetted, 1 subnets
R
55.5.5.0 [120/1] via 172.12.123.2,
00:00:02, Serial0
22.0.0.0/24 is subnetted, 1 subnets
R
22.2.2.0 [120/1] via 172.12.123.2,
00:00:02, Serial0

… and it’s seen at R3 with the
default seed metrics, having
matched clause 40 of the route-map.
R3#show ip route ospf
2.0.0.0/24 is subnetted, 1 subnets
O
E1 2.2.2.0 [110/104] via 172.13.13.1,
00:08:56, Serial1
55.0.0.0/24 is subnetted, 1 subnets
O E2
55.5.5.0 [110/20] via 172.13.13.1,
00:00:24, Serial1
172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via

172.13.13.1, 00:08:56, Serial1
22.0.0.0/24 is subnetted, 1 subnets
O
E1 22.2.2.0 [110/84] via 172.13.13.1,
00:08:56, Serial1
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.13.13.1,
00:08:56, Serial1

Bingo, baby!
Clause 20 of the route-map had two
set statements - you can also have
multiple match statements in a
clause. If so, both match statements
must match in order for that clause
to be, well, a match.
I’ve added a clause 50 to this routemap. For this clause to match, the

route would have to match ACL 5
*and* be an OSPF E2 route to have
its metric set to the specified value.
R1(config)#route-map RIP2OSPF permit 50
R1(config-route-map)#match ip address 5
R1(config-route-map)#match route-type ?

external

internal

external
route
(BGP,
EIGRP and
OSPF type
1/2)
internal
route
(including
OSPF
intra/inter

level-1

level-2

local

nssaexternal
<cr>

area)
IS-IS
level-1
route
IS-IS
level-2
route
locally
generated
route
nssaexternal
route
(OSPF type
1/2)

R1(config-route-map)#match
external ?

external

internal

level-1

route-type

external
route
(BGP,
EIGRP and
OSPF type
1/2)
internal
route
(including
OSPF
intra/inter
area)
IS-IS
level-1
route

level-2

local

nssaexternal

type-1

IS-IS
level-2
route
locally
generated
route
nssaexternal
route
(OSPF type
1/2)
OSPF
external
type 1
route
OSPF
external

type-2

type 2
route

<cr>
R1(config-route-map)#match
route-type
external type-2
R1(config-route-map)#set metric 100

There’s just one more set value I
want to introduce you to…
tag
protocol

Tag value for destination routing

This innocent little value can help
you prevent some big nasty routing
loops, especially with 2-way
redistribution. You can tag routes

with a numeric value as they’re
redistributed, and then prohibit
routes with that same value from
being “re-redistributed” back into
the original routing protocol.
Let’s use the previous lab topology
for a demo.

Let’s say we’re configuring 2-way

redistribution here, and we want to
make absolutely sure that routes
redistributed into OSPF cannot be
“re-redistributed” back to the RIP
domain, and vice versa -- and that
includes
the
possibility
of
additional border routers being
added to our network in the future.
We can tag the routes redistributed
into OSPF with a value of 10, and
deny routes with that same value
from being redistributed back into
RIP.
I’ve removed the previous lab’s
configuration and we’ll start by

checking for RIP routes on R1.
R1#show ip route rip
2.0.0.0/24 is subnetted, 1 subnets
R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:20, Serial0
22.0.0.0/24 is subnetted, 1 subnets
R
22.2.2.0 [120/1] via 172.12.123.2,
00:00:20, Serial0

We want to redistribute them into
OSPF and tag them with a value of
10. If that’s all we need to do, we
don’t need an ACL or any match
statements - just this route-map:
R1(config)#route-map RIP2OSPF permit 10
R1(config-route-map)#set tag 10

The redistribution config:
R1(config)#router ospf 1
R1(config-router)#redistribute rip route-map
RIP2OSPF subnets
R1(config-router)#redistribute connected
% Only classful networks will be redistributed
R1(config-router)#redistribute
connected
subnets

Don’t forget the subnets option. :)
Also note that in the RIP redis
statement, you can put subnets at the
end of the command or immediately
after redistribute rip -- it doesn’t
matter, just make sure you put it
somewhere.
The OSPF table on R3:

R3#show ip route ospf
2.0.0.0/24 is subnetted, 1 subnets
O E2
2.2.2.0 [110/20] via 172.13.13.1,
00:00:24, Serial1
172.12.0.0/24 is subnetted, 1 subnets
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:00:06, Serial1
22.0.0.0/24 is subnetted, 1 subnets
O E2
22.2.2.0 [110/20] via 172.13.13.1,
00:00:25, Serial1
30.0.0.0/24 is subnetted, 1 subnets
O
30.1.1.0 [110/74] via 172.13.13.1,
00:00:25, Serial1

Three routes are learned via
redistribution. You won’t see tag
values in the routing table, but you
will see them in the extended show
ip route command. Let’s run that
command for one of the external

routes and for the internal 30.1.1.0
network.
R3#show ip route 2.2.2.0
Routing entry for 2.2.2.0/24
Known via “ospf 1”, distance 110, metric 20
Tag 10, type extern 2, forward metric 64
Last update from 172.13.13.1 on Serial1,
00:00:43 ago
Routing Descriptor Blocks:
* 172.13.13.1, from 172.13.13.1, 00:00:43
ago, via Serial1
Route metric is 20, traffic share count is
1
R3#show ip route 30.1.1.0
Routing entry for 30.1.1.0/24
Known via “ospf 1”, distance 110, metric 74,
type intra area
Last update from 172.13.13.1 on Serial1,
00:00:52 ago

Routing Descriptor Blocks:
* 172.13.13.1, from 172.13.13.1, 00:00:52
ago, via Serial1
Route metric is 74, traffic share count is
1

The external route has a tag of 10,
and that tag is present with that
route everywhere that route is seen
throughout the network.
The internal route has no tag since it
wasn’t learned via redistribution,
and therefore wasn’t subject to
tagging by the route map.
The following config will prevent
any routes with the tag 10 from
being redistributed from OSPF back

into RIP, while allowing any
untagged routes to be redistributed
and tagged with 20.
R1(config)#route-map OSPF2RIP deny 10
R1(config-route-map)#match tag 10
R1(config-route-map)#route-map OSPF2RIP
perm 20
R1(config-route-map)#set tag 20

Now what if we want to go back to
the RIP2OSPF route map and use
that tag to prevent routes with that
tag of 20 from being advertised
back to OSPF? Here’s what that
route-map looks like now:
R1#show route-map RIP2OSPF
route-map RIP2OSPF, permit, sequence 10

Match clauses:
Set clauses:
tag 10

We need the new clause to have a
sequence number of less than 10,
since we need the deny clause in
front of this clause, which allows
all routes and tags them with 10.
Here’s how we make that happen,
along with verification.
R1(config)#route-map RIP2OSPF deny 5
R1(config-route-map)#match tag 20
R1#show route-map RIP2OSPF
route-map RIP2OSPF, deny, sequence 5
Match clauses:
tag 20
Set clauses:

Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 10
Match clauses:
Set clauses:
tag 10
Policy routing matches: 0 packets, 0 bytes

The joy of sequence numbers!
If we had the permit clause run
first, everything would be permitted
and tagged with 10 -- even the
routes we’re trying to deny.
By putting the deny statement first,
we deny the routes that are tagged
20 and then allow all other routes to
be redistributed. That’s why I put a
“5” in the first line of this new

config - that’s the sequence number.
Policy Routing
Policy-based routing, generally
referred to as “policy routing”, is
the use of route maps to determine
the path a packet will take to get to
its final destination. As you
progress through your CCNP
studies and go on to the CCIE (or to
a Cisco Quality Of Service
certification), you’ll find that traffic
can be “marked” by policy routing
in order to give different levels of
service to various classes of traffic.

This is done by marking the traffic
and placing the different classes of
traffic in different queues in the
router, allowing the administrator to
give some traffic higher priority for
transmission.
Some basic policy routing rules:
Policy routing doesn’t affect
the destination of the packet,
but does affect the path that is
taken to get there.
Policy routing can forward
traffic based on the source IP

address or the destination IP
address (with the use of an
extended ACL).
Policy routing can be
configured globally or on a
per-interface level.
Applying policy routing on an
interface affects only packets
arriving on that interface - in this
case, Serial0.
R2(config)#int s0
R2(config-if)#ip
policy
CHANGE_NEXT_HOP

route-map

Applying the policy globally
applies the route map to packets
generated on the router, not on all
packets received on all interfaces.
R2(config)#ip
local
CHANGE_NEXT_HOP

policy

route-map

Verify either - or both! - with show
ip policy.
R2#show ip policy

Interface
local
Serial0
And here’s
remember….

the

Route map
CHANGE_
CHANGE_
big

rule

to

If a packet doesn’t match any
of the specific criteria in a
route map, or does match a
line that has an explicit deny
statement, the data is sent to
the routing process and will
be processed normally.
If you don’t want to route packets
that don’t match a route-map
clause, the set command must
used to send those packets to
null0 interface. Naturally, this
command should be the final
command in the route map.

be
the
set
set

There are four possibilities for an
incoming packet when route maps
are in use. The following example
illustrates all of them.
R2(config)#access-list 29 permit host 20.1.1.1
R2(config)#access-list 30 permit host 20.2.2.2
R2(config)#access-list 31 permit host 20.3.3.3
R2(config)#access-list 32 permit host 20.4.4.4
R2(config)#route-map EXAMPLE permit 10
R2(config-route-map)#match ip address 29
R2(config-route-map)#set ip next-hop 40.1.1.1
R2(config-route-map)#route-map EXAMPLE
deny 20
R2(config-route-map)#match ip address 30

Assuming the route map has been
applied to the router’s ethernet0

interface, a packet sourced from
20.1.1.1 would match the first line
of the route map and have its nexthop IP address set to 40.1.1.1.
A packet sourced from 20.2.2.2
would match the deny statement
(sequence number 20). Since there
is no action listed, this packet
would return to the routing engine to
undergo the normal
routing
procedure. All traffic that did not
match these two addresses would
also be routed normally - there
would be no action taken by the
route map.

Perhaps we want to specifically
block traffic sourced from 20.3.3.3
or 20.4.4.4. We can use multiple
match statements in one single route
map, and have packets matching
those two addresses sent to the bit
bucket - the interface null0.
R2(config)#route-map EXAMPLE permit 30
R2(config-route-map)#match ip address 31
R2(config-route-map)#match ip address 32
R2(config-route-map)#set ?

as-path

automatic-tag

Prepend
string fo
BGP AS
attribute
Automa
comput

comm-list

community

dampening

default

extcommunity

value
set BGP
commun
list (for
deletion

BGP
commun
attribute
Set BG
route fl
dampen
parame
Set defa
informa
BGP
extende

interface
ip
level
localpreference

metric

commun
attribute
Output
interfac
IP spec
informa

Where
import
BGP lo
prefere
path att
Metric
for
destinat
routing
protoco

metric-type

origin

tag

weight

Type of
metric f
destinat
routing
protoco

BGP or
code

Tag val
destinat
routing
protoco
BGP w
for rout
table

R2(config-route-map)#set interface null0

Any traffic matching ACLs 31 or 32
will be sent to null0, resulting in its
being discarded by the router. Any
traffic that didn’t match any of the
route map statements will be
returned to the routing engine for
normal processing.
You can verify your policy-map
effectiveness and monitor the
number of matches with show
access-list.
Whew! We use a lot of route maps
in our CCNP ROUTE studies, and
you’ll use them often in production
networks as well - they’re not just

for BGP, it just seems that way!
Speaking of that, since we’ve used
these maps in different sections of
the course, here’s a summary of the
various uses:
Packet destination set values:
Next-hop IP address, including
a default next-hop
Interfaces that can route
packets, including a default
interface

IP PREC values (IP
Precedence), Don’t Fragment
bit value, and IP Type of
Service (ToS)

Routing protocol set values:
metric
metric type
tag values

BGP set values:

AS-Path
Community
Local Preference
Weight
Bonus Material - Not Covered On
DVD, But Good Reading Anyway!
“ip default next-hop” vs. “ip nexthop”
These are two values that can be set

with a route map that are very
similar, and I want to point out to
you that while many CCNP
candidates think they’re the same
thing, they are not.
If you set an “ip default next-hop”
with a route map, that next-hop will
be used ONLY if an explicit path to
the destination network is not
present in the routing table. An
extended ACL must be used here,
since a source and destination must
be defined.
R2(config)#access-list 150 permit
172.1.1.1 210.1.1.0 0.0.0.255

ip host

R2(config)#route-map DEFAULT_NEXT_HOP
permit
R2(config-route-map)#match ip address 150
R2(config-route-map)#set ip default next-hop
100.1.1.3
R2(config)#interface e0
R2(config-if)#ip
policy
DEFAULT_NEXT_HOP

route-map

When a packet comes into ethernet0
with a source IP of 172.1.1.1 and is
destined for any host on the
210.1.1.0/24 network, the next-hop
address will be set to 100.1.1.3 IF
there is no entry in the routing table
for that network.
The Null0 Interface And BGP

Redistribution
Null interfaces are seen in the
routing table after manual route
summarization has been configured,
but you can also create a static
route with Null0 as the “exit
interface”.
Configuring Null0 as the exit
interface means that matching data
will be dropped. You configure
such a route just as you would any
other static route with a specific
exit interface.
R2(config)#ip route 172.12.1.0 255.255.255.0
null0

You may be wondering why we’d
do that in the first place. The main
purpose of a static route to null0 is
to allow BGP - IGP route
redistribution.
BGP
route
redistribution is a complex subject
that you’ll master during your CCIE
studies, but here are a couple of
basics for you.
Instead of redistributing specific
routes from an IGP into BGP, you
can create this null0 statement and
then just redistribute this static
route into BGP. Basically, what
you’re doing is aggregating the
routes before injecting them into

BGP.
The null0 statement will not impact
your IGP routing, since the morespecific statements in the IGP table
will be used before this null0 route
due to the longest match rule.
Let’s work through an example. You
have the IGP routes 150.100.1.0,
150.100.2.0, and 150.100.3.0, all
with a /24 mask. You have a need to
redistribute these routes into BGP.
Instead of redistributing the three
individual routes into BGP, you
summarize them. The result is

150.100.0.0 /22. You create a route
for that network and mask that leads
to the null0 interface like this….
R2(config)#ip route 150.100.0.0 255.255.252.0
null0

… and then redistribute that route
into BGP. The presence of this null
router in your IGP table will not
matter, since traffic destined for the
150.100.1.0, 2.0, and 3.0 networks
will have a longer match in the
table.
There’s one more use for such a
null route, and that’s to trick BGP
into thinking that there is an IGP

route for this destination in the first
place. If you faced a situation
where you needed to redistribute a
network into BGP from your IGP
table, and that network didn’t
actually exist in your IGP table, you
could create a route to null0 with
the ip route command and then
redistribute it into BGP.
Potential Issues Regarding BGP
Redistribution
We just covered one major issue
regarding BGP redistribution, and
discussed how to solve that with a
static route to null0. There’s another

major factor we have to consider,
though, and that is the sheer size of
BGP routing tables.
A full BGP table can hold well over
100,000 routes. You read that right over 100,000 routes. You should
carefully consider this fact before
attempting
any
redistribution
involving BGP. A lot of damage can
be done very quickly to your
network and worldwide internet
connectivity as a whole if BGP
redistribution
is
performed
incorrectly.
There’s

another

problem

with

redistributing routes from an IGP
into BGP. If the IGP routes were
dynamically learned, they may
actually have been learned from
BGP in the first place. Putting them
back into BGP can quickly lead to a
routing loop. “routing instability”
doesn’t begin to describe what can
happen here.

Here, R1 is redistributing a BGPlearned route into OSPF. That’s fine
until R4 advertises it back to R5
because route redistribution has
been
incorrectly
configured.
Placing a filter at R4 to prevent it

from possibly advertising that route
and prefix to R5 can prevent a
routing loop possibility.
You also have to be careful when
redistributing
BGP
aggregate
routes. If one of the more-specific
routes being aggregated goes down,
the data is said to have entered a
black hole -- that is, the router’s
going to discard the data.
By the
always
actually
security
applied.

way, black holes aren’t
a bad thing - they’re
an effective network
technique when properly
(Note the emphasis on

properly applied!) That’s beyond
the scope of the CCNP ROUTE
exam, but if you enter “routing
black hole” into your favorite
search engine, you’ll quickly find a
few documents on using black holes
for network security purposes.
Whether BGP is involved or not,
you’ve got to be very careful when
configuring route redistribution in a
network with multiple paths
between the routing domains.
You can use default routes and
static routes to avoid two-way
redistribution. If you just can’t

avoid two-way, make sure to use
your skills to change administrative
distances, default metrics, or some
kind of route filtering to prevent
loops from occurring. Route
filtering becomes very important
when working with two-way
redistribution.
Redistributing External
Routes Into BGP

OSPF

Since I’ve warned you about 2000
times not to redistribute anything to
and from BGP unless absolutely
necessary, I won’t make it 2001.

But should you have to redistribute
external OSPF routes, there are
some options you need to know
about.
IOS Help reveals quite a few
options for OSPF > BGP
redistribution:
R1(config)#router bgp 100
R1(config-router)#redistribute ospf 1 ?

metric

Redistribution
OSPF routes
Metric for
redistributed ro

routemap

Route map
reference

match

vrf

VPN
Routing/Forwa
Instance

<cr>
R1(config-router)#redistribute ospf 1 match ?

external

internal

nssa-

Redistribute
OSPF
external
routes
Redistribute
OSPF
internal
routes
Redistribute
OSPF
NSSA

external

external
routes

R1(config-router)#redistribute ospf 1 match
external ?

1

2

external

Redistribute
external type
1 routes
Redistribute
external type
2 routes
Redistribute
OSPF
external
routes

internal

match

metric

nssaexternal
routemap
<cr>

Redistribute
OSPF interna
routes
Redistributio
of OSPF
routes
Metric for
redistributed
routes
Redistribute
OSPF NSSA
external
routes
Route map
reference

R1(config-router)#redistribute ospf 1 match
external 1 ?

external

internal

match

metric

Redistribute
OSPF
external
routes
Redistribute
OSPF interna
routes
Redistributio
of OSPF
routes
Metric for
redistributed
routes
Redistribute

nssaexternal
routemap
<cr>

OSPF NSSA
external
routes
Route map
reference

R1(config-router)#redistribute ospf 1 match
external 1 external 2

OSPF has two external route types,
E1 and E2, E2 being the default. If
external OSPF routes must be
redistributed into BGP, the full
command to put both E1 and E2
routes into BGP is shown above.

Changing A Protocol’s Default
Metric (Review)
Here’s a quick review on using the
default-metric command with RIP,
EIGRP, and OSPF.
RIP’s metric is simple - hop count and so is the command.
R2(config)#router rip
R2(config-router)#default-metric 2

EIGRP requires five values to be
set:
R2(config)#router eigrp 100
R2(config-router)#default-metric ?
<1-4294967295> Bandwidth in Kbits per

second
R2(config-router)#default-metric 1544 ?
<0-4294967295> Delay metric, in 10
microsecond units
R2(config-router)#default-metric 1544 10 ?
<0-255> Reliability metric where 255 is
100% reliable
R2(config-router)#default-metric 1544 10 255 ?
<1-255> Effective bandwidth metric
(Loading) where 255 is 100% loaded
R2(config-router)#default-metric 1544 10 255 1
?
<1-4294967295> Maximum Transmission
Unit metric of the path
R2(config-router)#default-metric 1544 10 255 1
1500

OSPF has a default seed metric
already set (and you know what that
is by now!), and it can be changed
as follows:
R2(config)#router ospf 1
R2(config-router)#default-metric ?
<1-16777214> OSPF default metric
R2(config-router)#default-metric 25

Recommended Video Viewing
From My YouTube Channel:
Troubleshooting
Redistribution:

Route

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

v=ol1boiYUtEk
Video Practice Exam on route
redistribution:
http://www.youtube.com/watch?
v=eY2yyRd0lvM
“The Good, The Bad, and The
Redistributed”
http://www.youtube.com/watch?
v=GdJOle54whI
Configuring and Troubleshooting

RIP Redistribution:
http://www.youtube.com/watch?
v=pRtZgfLxlbQ
Routing Loops In The Wild:
http://www.youtube.com/watch?
v=pKimoicJCFQ
Free CCNP ROUTE Video Boot
Camp on route redistribution:
http://bit.ly/Arnhjq

My CCNP ROUTE Video Boot
Camp - Exclusive Discount Link
For My Ebook Readers Only!

Just click this link for a free hourlong preview AND $10 off the
already low price!

http://bit.ly/A7pLBu
Available for immediate download
and on DVD!

Copyright ©2012 The Bryant Advantage.
All Rights Reserved.

Bonus Section:
Creating A VLSM Scheme

Working with VLSM isn’t a topic
on the CCNP ROUTE exam, and
isn’t covered in the Cisco study
guides on this topic - but it’s a
valuable skill to have.
For that reason, I’ve included this
section on creating a VLSM
scheme.
Let’s get started!

Subnetting is simply the process of
taking a major network number and
dividing that major network number
into smaller, more manageable
networks. This is done through
borrowing host bits. (You never,
ever, ever borrow network bits for
subnetting.)
Subnetting is much like taking a pie
and cutting it into slices. For your
CCNA studies, the slices were the
same size; the stakes will be raised
in your CCNP studies and the
“network slices” will not be the
same size.

These are the major network
classes and their network masks:

Class D and E addresses cannot be
assigned to public users, so we’re
not going to be subnetting those.
Also, keep in mind that while it’s
common knowledge that the
127.0.0.0 network is reserved for
loopback addressing, that means
loopback addressing for hosts, not

Cisco router loopback interfaces.
If you try to assign an address from
the 127.0.0.0 range to a Cisco
loopback interface, you’ll get a
message informing you that this is
not a valid host address.
R1(config)#int loopback 100
R1(config-if)#ip address 127.1.1.1 255.0.0.0
Not a valid host address - 127.1.1.1
R1(config-if)#ip
address
127.244.244.244
255.0.0.0
Not a valid host address - 127.244.244.244

You also learned that there is
another way to express a mask
rather than using dotted decimal.
You can use prefix notation, where

the number behind the slash is the
number of consecutive bits set to
“1” in the mask. Therefore, since
the mask 255.0.0.0 is equivalent to
the
binary
string
11111111
00000000 00000000 00000000,
this mask can also be expressed as
/8, or “slash eight”.
Determining The Number Of
Valid Hosts And Valid Subnets
To even start subnetting, you’ve got
to know those network classes and
network masks. This is the starting
point for answering any subnetting

question, whether it’s a Cisco
question or a real-world scenario.
During your CCNA studies, the
subnets were all the same size. You
would see a question such as “How
many valid hosts exist on the subnet
172.12.12.0 /24?” You would then
use this formula to answer the
question:
Number of valid hosts = (2 to
the nth power) - 2, where n = the
number of host bits
You know this is a Class B
network, with a network mask of

255.255.0.0, or /16. You also know
that the subnet mask is /24, or
255.255.255.0 in dotted decimal.
Placing the two masks next to each
other reveals where the subnet bits
are:

The bits where the network mask
has a 0 and the subnet mask has a 1
are the subnet bits. The bits where
both the network mask and subnet
mask have a 0 are the host bits.
Placing “8” into the formula for
“n”, you see the number of valid
hosts is (2 to the 8th power) - 2,

which is 254.
The formula for determining the
number of valid subnets looks
similar, but be careful - there are
two major differences.
Number of valid subnets = (2
to the nth power), where n = the
number of subnet bits
In this formula, “n” equals the
number of subnet bits, not host bits.
Also, you no longer subtract 2 to
determine the number of valid
subnets. Cisco’s formula for their
exams used to hold that you should

subtract 2, feeling that the “allzeroes” subnet and the “all-ones”
subnet were not valid. The problem
was that the use of the “all-zeroes”
subnet, more commonly referred to
as “subnet zero”, is actually
enabled by default on almost all
Cisco routers:
R1#show config
Using 872 out of 32762 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!

hostname “R1”
!
!
ip subnet-zero
Cisco’s networking theory now
holds that both of these subnets are
valid, so the “2” is no longer
subtracted. Using the previous
masks, you can see there are eight
subnet bits as well as eight host
bits:

Since there are eight subnet bits, the
number of valid subnets is 2 to the

8th power, or 256.
While this question type proves to
Cisco
that
you
understand
subnetting theory, it’s not a good
real-world situation. This particular
subnet mask took the major network
number 172.12.0.0 and divided it
into 256 valid subnets that each
contain 254 valid IP addresses.
It’s much more likely that your
network will have segments that
need a lot of host addresses, and
other segments that may require
only two. That’s the kind of
subnetting CCNPs need to know

how to do, and this is VLSM variable-length subnet masking. You
will still be taking a major network
number and logically dividing it,
but now you will be tailoring the
subnetting to your particular
network requirements.
Of course, if you’re going to use
VLSM, you better be using a routing
protocol that supports it! RIPv2,
OSPF, EIGRP, and BGP all support
VLSM. RIPv1 does not.
Creating A VLSM Scheme
In the following example, we’ll be

using the major network number
150.50.0.0. We have five network
segments, each requiring a different
number of valid host addresses. In
accordance with the change in
Cisco’s approach to subnet zero,
we will be using that subnet.
Network A: 200 host addresses
needed
Network B: 50 host addresses
needed
Network C: 25 host addresses
needed

Network D: 5 host addresses
needed
Network E: 2 host addresses
needed
When you’re designing a VLSM
scheme in the real world, you
should keep two things in mind.
First, design it before you put it into
action; putting a VLSM scheme into
action requires advance planning to
avoid problems after you start
putting it into action. Second, keep
future growth in mind. You may not
want to make your masks too
restrictive regarding the number of

valid hosts - what if you need to put
20 more hosts on a subnet a year
from now, but you only left yourself
10 valid addresses?
You may not have to come up with
any full-blown VLSM scheme
during the BSCI exam, but as a
CCNP, you should certainly be able
to. A method that has worked for me
and my students all over the world
has been to ask yourself this simple
question when designing VLSM:
“What is the smallest subnet
that can be created with all host
bits set to zero?”

Network A requires 200 valid host
addresses. Using the formula we
reviewed earlier in this chapter, we
determine that we will need eight
host bits (2 to the 8th power equals
256; 256 - 2 equals 254). What is
the smallest subnet that can be
created with all host bits set to
zero?

We use a subnet mask of /24 to have
eight host bits remaining, resulting
in a subnet and subnet mask of
150.50.0.0 /24, or 150.50.0.0

255.255.0.0. It’s a good 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 the host
bits set to zero; the broadcast
address for this subnet is the value
of that binary string with all the host
bits set to one. These addresses
cannot be assigned to hosts; every
value between the network number
and broadcast address is a valid IP
address.

The next subnet will start with the

next number up from the broadcast
address. Since 255 is a full octet,
the next sequential number after
150.50.0.255 is 150.50.1.0.
Now we need to determine the
subnet mask for the subnet
150.50.1.0. Network B requires 50
valid host addresses. Using the
valid hosts formula, we determine
that six host bits are necessary (2 to
the 6th power equals 64; 64 minus 2
equals 62). What is the smallest
subnet that can be created with all
host bits set to zero?

We use a subnet mask of /26 to have
six host bits remaining, resulting in
a subnet and subnet mask of
150.50.1.0 /26, or 150.50.1.0
255.255.255.192. We’ll add that to
our chart. Remember, the network
number is the value of that binary
string when all host bits are set to
zero, and the broadcast address for
that subnet is the value with all host
bits set to one. Those addresses are
not valid host addresses, but every
address between them is.

The next subnet is one value up
from that broadcast address. In this
case, it’s 150.50.1.64. Now we
need to determine how many host
bits Network C needs. Since we
need 25 valid addresses, we need
five host bits, which will yield 30
valid host addresses. (2 to the 5th
power is 32, subtract the two
invalid host addresses and you’ve
got 30 left.) That gives us a subnet
mask of /27.

The next subnet is one value up
from that broadcast address, which
makes it 150.50.1.96. Network D
needs 5 host addresses, so we have
to have at least three subnet bits.
(You know the formula by now;
what we’d be looking out for in the
real world is that there are only 6
valid addresses on this subnet.)
We’ll use a subnet mask of /29 to
leave three host bits:

If all three host bits are set to zero,
the result is 150.50.1.96; that’s the
network number. If the host bits are
all set to one, the result is
150.50.1.103.
Everything
in
between is a valid IP address.

Finally, Network E needs only two
valid host addresses. The next
value up is 150.50.1.104, so that

will be the subnet; a mask of /30
leaves us two valid host addresses.

You know the network number is
150.50.1.104, and the broadcast
address is 150.50.1.107. There are
exactly two valid host addresses on
this subnet, 150.50.1.105 and 106.
This completes our VLSM scheme.

You don’t need a practice exam to
practice this skill - just a few
minutes and something to write
with. That’s it.
And this I guarantee you: those few
minutes of extra practice here and
there add up big time. -- Chris B.

Copyright © 2012 by The Bryant
Advantage. All Rights Reserved.

Bonus Section:
How To Develop A VLSM
Scheme

Here’s a little more practice with
VLSM!
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?

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.

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?

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.

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?

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.

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

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.

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?

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

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.
This particular exercise didn’t ask
us to consider any future growth,
but some of your exam questions
might do so. Just as important, any

VLSM scheme you originate or add
to should take future growth of the
subnet into account.
A more realistic scenario is one
such as this:
We’re going to work with the major
network number 140.10.0.0. There
will be four subnets, with a varying
number of valid IP addresses
needed
for
each
segment.
Management has indicated that no
subnet will grow by more than 5
hosts per year for the next five
years. Develop a VLSM scheme
that will accommodate current and

future needs.
Network A: 110 hosts
Network B: 90 hosts
Network C: 65 hosts
Network D: 34 hosts
If we will need up to five hosts per
year for the next five years on each
of these subnets, we need to add 25
to the above values.
Network A: 135 hosts
Network B: 115 hosts

Network C: 90 hosts
Network D: 59 hosts
Now that we’ve allowed for the
network’s future growth, we’re
going to follow the exact same
procedure as we did for the
previous example. That procedure
starts with the question…
“What is the smallest subnet that
can be created with all host bits
set to zero?”
NW A requires 135 valid host
addresses. Using the above formula,

we determine that we will need 8
host bits (2 to the 8th power equals
256; 256 - 2 = 30). What is the
smallest subnet that can be created
with all host bits set to zero?

We’ll use a subnet mask of /24 to
have eight host bits remaining,
resulting in a subnet and subnet
mask of 140.10.0.0 /24, or
140.10.0.0 255.255.255.0.
Calculate the network number and
broadcast address, and begin your
VLSM table.

The next subnet will start with the
next number up from the broadcast
address. In this case, that’s
140.10.1.0. With a need for 115
valid host addresses, what will the
subnet mask be?

Seven host bits will yield 126
usable host addresses. The resulting
network number and broadcast
address are shown below, and NW
B is added to the VLSM table.

The next subnet will start with the
next number up from the broadcast
address. In this case, that’s
140.10.1.128. With a need for 90
valid host addresses, what will the
subnet mask be?

Again, a /25 mask is needed. This
leaves seven host bits, the minimum
number required for 90 valid hosts.

The resulting network number and
broadcast address are shown
below, and NW C is added to the
VLSM table.

To finish our VLSM scheme, we’ll
use the subnet 140.10.2.0 (one
address up from the broadcast
address 140.10.1.255). With 59
hosts required, how many host bits
will be needed?

Six host bits will give us 62 usable
host addresses. You know the drill calculate the network number and
broadcast address for this subnet,
list the valid host addresses, and
update the VLSM table!

I told you learning binary math
instead of memorizing charts would

pay off one day! This is just one of
the real-world uses of binary math,
and no chart memorization is going
to help design a VLSM scheme. You
either know how to do it 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.
it! I 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!
To your success,
Chris Bryant

CCIE #12933
“The
Computer
Bulldog”

Certification

Copyright © 2012 The Bryant Advantage.
All Rights Reserved.