CCNP Route Guide

Welcome to your Bulldog Study
Guide for the CCNP ROUTE exam!

I know youre anxious to get
started, so Ill 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, youll 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, Ive added a
special feature to this ebook thats
guaranteed to help you master these
complex concepts.
And just as exciting, these features
dont cost anything!
At the end of each section, youll
find links to videos on my YouTube
computer
certification
video
training channel that are related to
the topic you just studied.
Youll find Video Practice Exams,

5-minute Video Boot Camps, and
other video types - all of which
will help you nail this difficult
exam.
Youll 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 ones not quite free, but in
a world of $500 video courses,
youll find the price to be quite
refreshing.
I also invite you to join me on
Twitter, Facebook, LinkedIn, and
other social media sites. Im there
live every day and happy to chat
with you there!
Nuff said! Lets 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:
I hope youll click subscribe
while youre out there - Im adding
new videos AND certifications on a
regular basis, including Security+,
Network+, and a new CCNA
Security course in 2012!
Youll 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 - heres
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:
TSHOOT:
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/
Theres 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!
When I post new videos or
tutorials, or whenever theres
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! Im
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.

Theres only one way

to get my crystal-clear
CCNP ROUTE Video
Boot Camp instruction
--- and thats 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!
Its 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 dont 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:
I know youll 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

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 youre thinking!

Im a CCNA already, I already
studied RIP, I know all the Distance
Vector stuff, I know my admin
distances. Lets get to the new
stuff!
Before we do that, were going to
take some time to review and
master some fundamental routing
skills
because without that mastery, we
cant become truly great.

And while I know youre familiar
with these protocols, this chapter is
going to be more than a review for
you - its going to sharpen your
skills with these critical protocols
to the point where the CCNP
ROUTE questions will be childs
play for you.
Theres also more than a little
material in this section that will
help you big time on your CCNP
TSHOOT exam as well.
Sooooo..
Lets 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
LANs subnets arent 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 isnt a problem,
but RIPs 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. RIPs 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 lets 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.
Its 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 Ive put it here for
easy comparison to RIP. I also
didnt go into a discussion of
EIGRP here, since well 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.
to a destination and they have
the same prefix length, the
route with the lowest
administrative distance is
used.
with the same prefix length and
AD, the route with the lowest

metric is used.
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.
Im 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 IGRPs 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 thats

where the AD comes in. The path
discovered by the protocol with the
lowest AD will be used. Since
IGRPs AD is 100 and OSPFs 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 thats fine when things
go as we expect.
When things dont go as we expect and when were 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 well take all the
redundancy we can get in todays
delay-sensitive networks.
Now that we know how a routing
table is built, lets 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
were primarily interested in the
RIP route for this discussion, well
run show ip route rip to see only
the routes that RIP has discovered.
R1#show ip route rip
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? Its 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 protocols 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
youre 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.
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
Serial0
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 youre
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 well 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
routers gateway of last resort.
Remember that a default static route
isnt the path packets will take first,
its the path theyll 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 lets 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.
Youll 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
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
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
Gateway of last resort is 0.0.0.0 to network
0.0.0.0
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
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 its up to the
individual.
Floating Static Routes In Action

In this lab and all others in the
course, all IP addresses end with
the routers number. For example,
R1s 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 -- its not running
over the serial link connecting R1
and R3s 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 wouldnt run a dynamic
protocol over that link. If youre
like me, youre thinking Why

wouldnt I just run RIP over the link
and let the protocol figure all of this
out?
Ordinarily wed be happy to do
that, but in this case were 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 doesnt
want to listen to reason and
just doesnt want to use that
link and just doesnt want to
hear anything about it (this
happens on occasion, too)
Now lets hit this lab!
R1 has two next-hop addresses for
the 172.12.23.0 /27 network:

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

routes administrative distance
(thats 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. Lets check it out.
R1#show ip route
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
C
Ethernet0
Now we need to test the config, and

since were in a lab environment,
well close S0 and cut off the RIP
updates. The result:
R1#show ip route
172.12.23.0 [200/0] via 210.1.1.3
C
Ethernet0
C
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 R1s 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
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
C
Ethernet0
C
On-Demand Routing (ODR)

In todays 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 dont

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,
youve 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
Youve got the ip route command
down cold at this point, so lets take
a closer look at ip default-network.
Well 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
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
network 0.0.0.0
C
Loopback0
C
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 didnt have to be
manually redistributed into RIP. Its
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. Well 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.
R*
0.0.0.0/0 [120/1] via 172.12.123.1,
00:00:12, Serial0
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
Thats 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, well 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!

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 theyre 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 its 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. Ill

mention it occasionally in the
EIGRP sections for comparisons
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 wont 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 routers 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.
Thats 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.
EIGRPs 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 wouldnt 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 its
nowhere near the best path!
Since both EIGRP and OSPF
consider the speed of a link in its
calculations, were 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, well use the network
command. The use of wildcard
masks is optional, but youll 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
0.0.0.255
100

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
youre going to disable it even
before you enter your network
statements! Youll see why - and
what can happen if you dont
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!
Theyre 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 dont 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
dont care? For a host to be on
the 172.12.123.0 /24 network, the

hosts address must match every bit
where there is a 1 in the network
mask. After that, I dont care!
Wildcard masks take the opposite
approach. The zeroes are I care,
and the ones are I dont care. In
this example, we want to enable
EIGRP on all interfaces whose first
three octets are 172.12.123, and
after that, we dont 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 lets 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
segments 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)#network 1.1.1.1 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
D
2.2.2.2 [90/2297856] via
172.12.123.2, 00:01:01, Serial0
D
3.3.3.3 [90/2297856] via
172.12.123.3, 00:00:58, Serial0
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
D
1.1.1.1 [90/2297856] via
172.12.123.1, 00:01:33, Serial0
D
3.3.3.3 [90/409600] via 172.23.23.3,
00:01:35, Ethernet0
D
1.1.1.1 [90/2297856] via
172.12.123.1, 00:01:46, Serial0
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
protocols
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
via 172.12.123.2 (2297856/128256),
Serial0
via 172.12.123.3 (2323456/409600),
Serial0
via Connected, Loopback0
via 172.12.123.3 (2195456/281600),
Serial0
via 172.12.123.2 (2195456/281600),
Serial0
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
via 172.12.123.3 (2297856/128256),
Serial0
via 172.12.123.2 (2323456/409600),
Serial0
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.

D
2.2.2.2 [90/2297856]
172.12.123.2, 00:12:54, Serial0
D
3.3.3.3 [90/2297856]
172.12.123.3, 00:12:51, Serial0
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 its 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, its simple, as
youre about to see!
Consider the path from R1 to R2s
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 R1s
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.
R1s feasible successor to 2.2.2.2

has a metric of 2323456, so it
qualifies! After changing the
variance value to 2 (by default, its
1) and clearing the routing table,
show ip route eigrp 100 verifies
that two valid routes to both R2s
and R3s loopbacks appear in the
EIGRP routing table.
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)

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
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
Youll 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, well 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 -- its 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. Thats 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 its for
the classful network 20.0.0.0 /8.
Heres R1s EIGRP route table.

None of the subnets are present in
the routing table.
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.
Ill ping each loopback IP address
from R1 - as youd guess from that
routing table, were going to get
some really interesting results.
R1#ping 20.1.1.1

timeout is 2 seconds:
!U!.!
R1#ping 20.2.2.2
U!.!U
R1#ping 20.3.3.3
U!.!U
R1#ping 20.4.4.4
!U!.!
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)#^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.
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 youre running

EIGRP and youre not seeing the
subnets or routes you expect, the
first thing Id check is to see if the
no auto-summary command is in
the configuration. If its not, Id 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
Youve probably noticed that we

didnt 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)#maximum-paths ?
<1-16> Number of paths
Setting maximum-paths
disables load balancing.
DUAL
Queries
And
Passive Is A Good Thing
to
Why
EIGRP uses the Diffusing Update

Algorithm (DUAL) to calculate
routes, and theres one other
important role DUAL plays in an
EIGRP deployment.
If a Successor route is lost and

there is no Feasible Successor,
weve got a problem! DUAL
doesnt 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
routers 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 doesnt 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!
IP-EIGRP
Topology
Table
for
AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update,
Q - Query, R - Reply,
via 172.12.123.3 (2297856/128256),
Serial0
via 172.12.123.2 (2323456/409600),
Serial0
via 172.12.123.2 (2297856/128256),
Serial0
via 172.12.123.3 (2323456/409600),
Serial0
Back To Index
EIGRP Tables and Commands:
http://www.youtube.com/watch?
v=ZndBgShoxl4
Advanced EIGRP Concepts:
v=LPuXmiKznEI
Video Practice Exam on Route
Redistribution:
v=eY2yyRd0lvM
The Mystery Of The AD 5:
v=X9AzQCt7rCM
Enjoy! -- Chris B.

Intermediate And Advanced

EIGRP Concepts And
Configuration
EIGRP Fundamentals
Lets 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 - theyre
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?
EIGRPs 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 theyre 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.
EIGRPs 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 youre changing any
EIGRP values to fine-tune your
routing table, Id go with bandwidth
as its 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 youd
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 theyre even

needed, EIGRP responds to
topology changes faster than RIP
(which isnt 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)#maximum-paths ?
<1-16> Number of paths
We can also perform unequal-cost

load balancing with EIGRP, and
well practice that skill later in this
section.
Almost all EIGRP packets are
multicast to 224.0.0.10, and use IP
protocol number 88. Lets 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 theres one
important exception that youll
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.
Thats 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 theyre constantly incrementing,

theres 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, Ive been there). If the
SIA values are incrementing along
with them, thats 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.
Theres almost always an exception
in networking, and thats true here
as well. Update packets are unicast
in this particular situation, but
otherwise theyre 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 - theyre 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
172.12.23.0
0.0.0.255
172.12.23.0
0.0.0.255
show ip eigrp neighbor verifies

that R3 is a neighbor of R2.
Lets change the hello timers on

R2s Ethernet 0 interface and see
what happens to the adjacency. Ive
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 didnt
prevent the adjacency from forming
again, but what about a change in
the metric weights?

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 theres no neighbor
to show! We can wait a long, long
time for that adjacency to come
back, but its 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 theres
a metric weights mismatch, youll
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
arent 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, lets 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,
youve 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 dont get the information I need,
Ill 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

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

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

Heres 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
Lets take a look at a typical EIGRP

topology table.
IP-EIGRP
Topology
AS(100)/ID(11.1.1.1)
Table
for

via Connected, Loopback0
via
172.12.123.2
(2297856/128256), Serial0
via
172.12.123.3
(2323456/409600), Serial0
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

via Connected, Serial0
EIGRP will keep up to six valid

routes for any given destination.
Those six routes dont 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
its not being recalculated and its 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, its 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 doesnt
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

doesnt 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
theyll ask two friends, and theyll
ask two friends, until a route is
discovered or its 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)#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 cant set this one to

zero. To disable the time limit,
use the disabled option.
If R8 doesnt 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 cant possibly be
answered.
The queried routers resources
are unavailable, generally due
to high CPU utilization.
The queried routers 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
doesnt 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 its just too busy
to answer and it has no CPU to
spare, or that it doesnt 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.
The Variance Command And

Unequal-Cost Load Sharing
Often, well have two or more
quality paths that we want EIGRP to
use. If the metrics arent exactly the
same, by default EIGRP will use
only the successor, as shown here:

IP-EIGRP
Topology
AS(100)/ID(11.1.1.1)
Table
for

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, isnt.

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; its coming up with the value
of this command that causes a little
confusion. With practice, youll 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 youll see that in
just a moment. This is one of those
concepts that looks ridiculously
complicated in theory but is simple
in execution.
Lets 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 doesnt 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)#variance 2
IP-EIGRP
Topology
AS(100)/ID(11.1.1.1)
Table
for

(There is still just one successor.)
via
172.12.123.3
(2297856/128256), Serial0
via
172.12.123.2
(2323456/409600), Serial0

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 paths 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)#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 dont I just put

variance 25 in there or
something like that, and then
Ill be using all of my
available paths!
Good question. Heres a good
answer.
Lets 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. Its
better than having no third link at
all, but I wouldnt include it in load
balancing.
variance is an all-or-nothing
command -- you cant apply it to
just a selected route in the topology
table. In my experience, its 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 arent

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 cant 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 youve got to do some planning
and verification, too.
I strongly recommend you create a
network baseline before using the
variance command. Besides, if you
dont know how much traffic your
network is carrying, its 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 youre 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 dont 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 youve compared the new
configs baseline to the old, and
youre happy with the result document your changes. I know its
no fun. I know youd 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
Lets 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? Theres no
grey area here - either the
downstream router has such a route,
or it doesnt. 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 doesnt 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 its wise to limit the scope
of broadcasts in our network, its 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
Well look at both later in this
section.
Feasible Distance and Advertised
Distance
From all these views of the
topology table, youve probably
noticed that there are two numbers

in parenthesis following each nexthop IP address.
via
172.12.123.2
(2195456/281600), Serial0
via
172.12.123.3
(2195456/281600), Serial0
The first number, 2195456, is the

routes feasible distance. This is
the full metric of the route to the
destination network.
The second number, 281600, is the
routes 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. Lets
look at our two routes to 3.0.0.0 /8
again.
via
172.12.123.3
(2297856/128256), Serial0
via
172.12.123.2
(2323456/409600), Serial0
The second route cant 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.
Lets use some slightly smaller
numbers to walk through an
example without using show ip
eigrp topology. Well assume a
successor route and three possible
feasible successors.
Successor: FD 5, AD 4
Possible Feasible Successor #1:
FD 9, AD 7
FD 8, AD 6

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 #3s AD of 4 is less than the
successors 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.)
Lets 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 R1s 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 successors AD is less than

the successors 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
theres more to it than that.
You already know how to use the
variance command, but its
important to keep in mind that if a
route doesnt meet the Feasibility
Condition, it cant 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
Its 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 cant use a path
that doesnt 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 dont,

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. Lets 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 were all set,
right?
Wrong. The problem is not with our
math, but with the Feasiblity
Condition. Lets 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.
Theres 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 couldnt 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 dont have to come from
other routing protocols -- they can
be connected or static routes as
well. Ive run into situations that
had people scratching their heads
over an AD value, so lets 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.
Youll generally use the network
command for this.

D
2.2.2.2 [90/409600] via 172.23.23.2,
00:00:06, Ethernet0
Thats what we would expect to

see, and thats 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? Lets remove the
network command on R2 and use
redistribute connected instead.
R2(config-router)#no network 2.2.2.2 0.0.0.0
R2(config-router)#redistribute connected
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 youre only
changing the distance of one route
type, you still have to specify them
both.
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
number 20.0.0.0 are separated by
another major network number,

172.16.0.0.
If
EIGRPs
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.
Its easy enough to turn this
behavior off:
Many
real-world
EIGRP
deployments have no autosummary configured on every
router in the network. This doesnt

really hurt anything, but now that
youre training to be a CCNP, you
need to know where the command
is needed - and where its
unnecessary.
Disabling autosummarization on the
spoke routers in this network will
give the hub router a much more
accurate picture of the network.
Remember, its 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 -theyre two separate operations.
Route summarization isnt 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
number
100.0.0.0
that
its
advertising to R3:
R3s EIGRP table shows all seven

routes:
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, thats 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, its 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-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
2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP
100: Neighbor 172.12.123.2 (Serial0) is
Its 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.

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 theres
something of interest on R1 you
should note.
R1#show ip route
subnets, 2 masks
C
Loopback4
C
Loopback5
C
Loopback6
C
Loopback7
D
100.0.0.0/13 is a
00:07:32, Null0
C
100.1.0.0/16 is directly
Loopback0
C
Loopback2
C
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 doesnt
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
Weve 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
D
100.0.0.0 [90/2297856] via
172.12.123.1, 00:03:33, Ethernet0
.. an AD of 90. Actually, thats the

value we should expect, since the
summary route will have an AD of
5 only on the router that originates
the summary.
Great! Lets take another look at
R1s routing table and that line for
the summary route, and Im sure
well 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
Loopback3
C
Loopback4
C
Loopback5
C
Loopback6
D
100.0.0.0/13 is a summary, 00:19:54,
Null0
C
Loopback0
C
Loopback1
C
Loopback2
Hmm. I still dont 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>
Lets 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, theres rarely a one-sizefits-all solution to this question!
When it comes to EIGRP route
summarization, Ive 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 its configured
on the ASBR.
EIGRP Design Recommendations
With networks growing and
changing all the time, its
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 youll 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) shouldnt
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.?
Lets 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
youve 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
Cisco has stated you can take the

lowest CIR value and multiply it by
the number of VCs. This isnt the
recommended solution, but it is
valid. Using this solution, the
bandwidth setting on R5s Serial0
interface would be (3 x 56), or 168.
R1(config)#int s0
This would prevent R7 from being

overrun with packets, but it doesnt
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
Ciscos 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)#int s0.3 point-to-point
R1(config-subif)#ip
address
50.1.1.1
255.255.255.0
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 R5s
multipoint interface should be set to
824 kbps.
R1(config)#interface s0.467 multipoint
By default, EIGRP uses up to 50

percent of a given interfaces
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 didnt get
an error message of any kind.
How in the world can I set EIGRP
100 to use 300% of an interfaces

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,
youd
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 heres the
proof that you can actually do this:
R3(config)#interface serial0
R3(config-if)#ip bandwidth-percent eigrp ?
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

Heres 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 spokes 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 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 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 were doing is

preventing R5 from asking a
question of those other routers that
they cant 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 Im 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 isnt 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, its a good idea to tell EIGRP
to reflect that in its routing
calculations with the bandwidth
command.
R1(config)#int s0
Always use IOS Help to verify the

unit of measurement for any value.
Theres a big difference between
entering bandwidth 56 and
bandwidth 56000 on that line!

And Just Another Reminder
Theres 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 its not required.
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 its a legal
command just the way it is. Pre12.0 IOS versions dont support
EIGRP wildcard masks, so you
should also be prepared for that
possibility.
Ive seen one or two routers running
at least 12.0 that didnt 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.
Whats
So
Passive
About
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 youre
advertising.
For example, lets say you want to
advertise our Ethernet segment of
172.23.23.0 /24 to R1, but you
dont 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)#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)#no passive-interface default
R2(config-router)#passive-interface serial 0
R2(config-router)#
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)#
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 dont have
OSPFs
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)#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
?
<0-4294967295> IGRP delay metric, in 10
microsecond units
10 ?
<0-255> IGRP reliability metric where 255 is
100% reliable
10 255 ?
<1-255> IGRP Effective bandwidth metric
(Loading) where 255 is 100% loaded
10 255 1 ?
<1-4294967295> IGRP MTU of the path
10 255 1 1500
Downstream routers will see this

route as follows:
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)#network 0.0.0.0 ?
A.B.C.D EIGRP wild card bits

<cr>
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. Im
personally not big on redistributing
a route to null0, but its 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 theres 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 Im making such a big
deal of that is with OSPF, we had

the option of advertising a default
route even when the router didnt
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, Ill configure 20.0.0.0 as
the default network for EIGRP
R1(config-router)#ip default-network ?
% Unrecognized command
or will I?
Dont try to use the ip defaultnetwork command in the EIGRP
config itself - its a globally
configured command.
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
D
100.0.0.0 [90/2297856] via
172.12.123.1, 00:02:30, Serial0

C
Serial0
Lets 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
The route is flagged as a candidate

default in R1s routing table..
C*
Ethernet0
and is advertised via EIGRP to
downstream routers.
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 todays world, its 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 networks data to
a rogue router.
EIGRP neighbor authentication isnt
the most intuitive feature youll
ever configure, and there are quite a
few command options. Before you
even get that far, though, you have to
decide whether youre going to use
clear-text passwords or use MD5
authentication to encrypt those
passwords.
and while Ill show you how to

do both, in the real world that
shouldnt be much of a decision. If
youre 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 youre much more likely to
work
with
MD5
EIGRP
authentication, lets 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, well
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
10:00:00 Jan 1 ?
<1993-2035> Year to start
10:00:00 Jan 1 2010 ?
duration Set key lifetime duration
hh:mm:ss Time to stop
infinite
Never expires
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 thats not the case yet weve just created the key, but we
havent applied the key to the
interface(s).
In essence, weve forged the key
but havent locked the door. Thats
about to change. Lets 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, well 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 ?
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.
Lets 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 ?
R3(config-if)#ip authentication key-chain eigrp
100 ?
WORD name of key-chain
100 EIGRPNEIGHBOR ?
<cr>
100 EIGRPNEIGHBOR
We have no chance of getting the

adjacency back until we configure
R2 with the same config, so Ive
done that as well - heres 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 - Id 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
The key KINISKI is shown to be

valid now. What if it wasnt
valid? Lets 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
00:00:00 Jan 1 2020 infinite
R2(config-keychain-key)#send-lifetime 00:00:00
Jan 1 2010 infinite
When youre typing this many

numbers, its easy to hit just one
wrong key - so always verify with
show key chain.
If youre expecting this key chain to
be valid now, but you dont 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
.. you know you mistyped

something. To fix this, dont 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:
v=LPuXmiKznEI
Administrative Distance Lab And
EIGRP:
v=yNgZwD8kXP0
Dont miss this one - The Mystery
Of The AD 5
v=X9AzQCt7rCM
Video Exam & Boot Camp Includes EIGRP:
v=f5_i2yEXj3s
Enjoy! -- Chris B.
Copyright 2012 by The Bryant

Advantage. All Rights Reserved.
Link State Protocols &

Single-Area OSPF
Link State Protocol Basics

Youre familiar with link state
protocol behaviors from your
CCNA studies, but were 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 dont work that
way. Link state routers that have
formed adjacencies exchange Link
State Updates (LSUs), which

contain Link State Advertisements
(LSAs). Its 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 its 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
O
6.6.6.6 [110/11] via 10.1.1.5,
02:32:53, Ethernet0
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 dont 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 youre sending is
outdated. Heres 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 routers adjacencies,
run show ip ospf neighbor or the
less-common show ip ospf
interface. That last command tends
to be forgotten, but theres 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 routers 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. Its 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
dont 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 thats 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 well take a
detailed look at those situations
later in this section. For now, lets
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, lets 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 well
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
isnt being advertised by OSPF
actually serve as the RID, doesnt
it?
Lets 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, youre 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 neighbors RID.
To illustrate another important point

regarding DRs and BDRs, lets 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 interfaces
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 RouterDs 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 isnt 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.
Lets 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 As
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 thats 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, theyre all the same,
right? :)
No worries, were 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 networks subnet is
10.1.1.0 /24. The final octet of
every IP address will be that
routers number. Every router has a
loopback interface with its router
number as each octet. (R1s
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, its 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
Process ID 1, Router ID 1.1.1.1,
Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State BDR, Priority
1
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
Next 0x0(0)/0x0(0)
Last flood scan time is 0 msec, maximum is 4
msec
count is 1
(Designated Router)
Its not a requirement to have a

certain router become the DR or
BDR on a broadcast segment, but

thats not true of our next network
segment.
The OSPF NBMA Network
Well 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
Its not enough to make sure R1

wins the DR election - weve 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
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, were rigging the DR
election so theres 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
172.12.123.0
0.0.0.255 area 0
R1(config-router)#neighbor 172.12.123.2

Transmit Delay is 1 sec, State DR, Priority 1
address 172.12.123.1
No backup designated router on this
network
Next 0x0(0)/0x0(0)
4 msec
count is 2
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
interfaces 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
Well 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.

Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State
POINT_TO_POINT,
Next 0x0(0)/0x0(0)
0 msec
count is 1
Note that no DR or BDR is listed.

On a point-to-point link, there are
only two routers on the link.

Therefore, theres 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 R1s 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. Well now configure the
frame relay network as point-topoint broadcast and then point-topoint nonbroadcast.
Point-to-Multipoint
Broadcast
Network Configuration
This network type doesnt 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; thats 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
15
25
Running
OSPF
Networks
Over
Topologies:
Broadcast
NBMA
Just Because You Can Do

Something Doesnt 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 theres 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 wouldnt 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.
Well 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 R4s 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
O
6.6.6.6 [110/11] via 10.1.1.5,
01:05:45, Ethernet0
O IA
172.23.23.0 [110/74] via
172.12.123.3, 00:04:14, Serial0

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
youre rusty on those, dont worry theres a lot of information on these
areas coming later in the course!)
Heres 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. Well
go over to R3 now and finish the
config.
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)#area 34 virtual-link 4.4.4.4
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 devices OSPF

RID, not necessarily the IP
address on the interface thats
in the transit area. Watch that its a very common error.
Check that RID!
Also, dont worry about that
error message you see in the
output from R3. Thats normal
and youll see it on R3 until
you finish building the virtual
link. If you see it after youve
completed the virtual link, you
do have a problem.
Always confirm the virtual link

with show ip ospf virtual-link. If
youve 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,
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. Its my
experience that the error message
highlighted in R3s output causes a
lot of panic, but the only thing that
message means is that youre 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.
Weve looked at a lot of OSPFcentric commands in this section,
but dont 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
youre 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 wouldnt have to
worry about design issues, virtual
links, or anything! After all, RIP
doesnt use areas.
Thats true, and its also one reason
you dont 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? Heres the definition of

hierarchical:
adj : classified according to
various criteria into successive
levels or layers
The Benefits
OSPF
Of
Multi-Area
Thats 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
doesnt need a huge routing table.
An unnecessarily large routing table

can be quite a drain on router
resources -- and if theres 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 its 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
is 1
Area ranges are
0x0822C6
Flood list length 0
Area 34
is 1
Area ranges are
0x06BDFB
Flood list length 0
Well take an in-depth look at multiarea OSPF in the next section.

OSPF Path Cost Determination
When you look at an OSPF routing
table, youll 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.
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d03h, Serial0
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d02h, Serial0
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d03h, Serial0
OSPF assigns a cost to every

OSPF-enabled
interface.
The
interface cost is based on the ports
speed. The default formula OSPF
uses to calculate the interface cost
is:
100,000,000 / Bandwidth in bps
(NOT kbps!)
Youll see some documentation that
lists the first part of that formula as
10 to the 8th power, but I feel its
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#conf t
with CNTL/Z.

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
with CNTL/Z.
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 werent 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.
OSPFs 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.
Heres a quick review of whats

going on in each state:
Down - No hellos received from
that neighbor
Attempt - Unicast hello packets are
being sent to the neighbor. Youll
only see this in OSPF NBMA
networks, since theyre 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, thats the
remote routers 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
Process ID 1, Router ID 10.1.1.1,
Network Type BROADCAST,Cost: 10
Transmit Delay is 1 sec, State BDR,
Priority 1

address 100.1.1.5
Interface address 100.1.1.1
Next 0x0(0)/0x0(0)
0 msec
count is 1
(Designated Router)
Show ip ospf interface is excellent

for spotting issues related to hello
and dead timers. If you dont 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
Serial1 seq 0x14EC opt 0x42 flag 0x2
len 9
2 mtu 1500 state EXSTART
4d22h: OSPF: NBR Negotiation Done. We are
the MASTER
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
Serial1 seq 0x14ED opt 0x42 flag 0x0
len 3
2 mtu 1500 state EXCHANGE
seq 0x14EE opt 0x42 flag 0x1
len 32
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
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. Im 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, youll get some interesting
adjacency results. I get asked about
this one often in Facebook and
Twitter (@ccie12933, by the way),
so I thought Id 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.
Youll
hear
about
OSPF
adjacencies stuck in 2-way, and
many people think thats what is
happening here, but its 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
lets tackle multiarea OSPF!

Recommended
Videos:
OSPF
YouTube
OSPF Router Types:

v=QNQCy-LQLFY
OSPF Hub-And-Spoke Checklist
v=46x--GIiKZk
OSPF Total Stub Areas:
v=DwZIRMfTaE4
OSPF Stub Areas In Action:

v=rHNXyNJpfpM
OSPF ASBRs:
v=hGrbyb6p4MI
My YouTube Channel Page:
Camp on OSPF stub areas and route

redistribution:
Copyright 2012, The Bryant Advantage.

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
well 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
routers
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, its

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 youve 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 routers
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
dont leave the local area.
This results in fewer Link
State Updates traveling across
the OSPF network as a whole.
(If youre rusty on LSA types,
dont worry, well go over
those in this section!)
As a result, fewer Shortest

Path First (SPF) recalculations
are needed.
Lets 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.
Well 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, R1s 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 youre 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.
172.12.123.0
0.0.0.255 area 0
R1(config-router)#network 1.1.1.1 0.0.0.0 area
1
172.12.123.0
0.0.0.255 area 0
2
172.12.123.0
0.0.0.255 area 0
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 neighbors RIDs, and as
we would expect at this point, the
RID for each router is the routers
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.
O AI
2.2.2.2 [110/65] via 172.12.123.2,
00:00:00, Serial0
O AI
3.3.3.3 [110/65] via 172.12.123.3,
00:00:00, Serial0
O AI
1.1.1.1 [110/65] via 172.12.123.1,
00:00:23, Serial0
O AI
3.3.3.3 [110/65] via 172.12.123.3,
00:00:23, Serial0
O AI
1.1.1.1 [110/65] via 172.12.123.1,
00:01:59, Serial0
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
Supports opaque LSA
R2#show ip ospf

Supports opaque LSA
R3#show ip ospf
Supports opaque LSA
Now well 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.
0.0.0.255 area 34
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.

Lets take a look at R4s OSPF
routing table:
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:01:03, Ethernet0
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 theres 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 theyve all got
the same next-hop IP address,

doesnt it?
Lets keep that in mind.
Were 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)#version 2
R1(config-router)#version
2
R1(configrouter)#no auto
R1 will see all of R5s loopbacks

in its RIP routing table. R1 also has
a route to R2s loopback, R3s
loopback, and the 172.34.34.0 /24
network in its OSPF table.
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

O IA
2.2.2.2 [110/65] via 172.12.123.2,
00:04:17, Serial0
O IA
3.3.3.3 [110/65] via 172.12.123.3,
00:04:17, Serial0
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 protocols routes will be
seen, but pings wont go through.
% 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, youll see that in the
output of show ip ospf. Youll 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
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 R5s RIP routing table,
followed by pings of all remote
loopback interfaces and R4s
Ethernet0 interface.
Note there is no special code for
routes being introduced into RIP via
route redistribution. R is R.

R
1.1.1.1 [120/1] via 15.1.1.1, 00:00:20,
Ethernet0
R
2.2.2.2 [120/1] via 15.1.1.1, 00:00:20,
Ethernet0
R
3.3.3.3 [120/1] via 15.1.1.1, 00:00:20,
Ethernet0
R
172.34.34.0 [120/1] via 15.1.1.1,
00:00:20, Ethernet0
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

!!!!!
R5#ping 2.2.2.2
!!!!!
R5#ping 3.3.3.3
!!!!!
R5#ping 172.34.34.4
!!!!!
R5 can indeed see the OSPF routes

and can ping all three remote
loopbacks. Notice that theres no
special code next to a RIP route that
was
originally learned
via
redistribution - the only RIP route
code is R.
Lets take a look at R4s OSPF
routing table, and see if R4 can ping
R5s loopbacks.
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:33:33, Ethernet0
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:33:33, Ethernet0
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:33:33, Ethernet0
O E2
5.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
subnets, 2 masks
O IA
172.12.123.0/24 [110/74] via
172.34.34.3, 00:33:33, Ethernet0
O E2
7.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
O E2
15.1.1.0 [110/20] via 172.34.34.3,
00:33:32, Ethernet0
R4#ping 5.1.1.1
(Ever notice the router doesnt tell
you the ping escape sequence? Its

<ctrl-shift-6> TWICE, in rapid
succession.)
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
timeout is 2 seconds:!!!!! Success rate is 100
ms
R4#ping 7.1.1.1

timeout is 2 seconds:!!!!! Success rate is 100
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.
Well 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 R4s 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
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
subnets, 2 masks
O E2
7.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
O E2
15.1.1.0 [110/20] via 172.34.34.3,
00:33:32, Ethernet0
Its 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.
Its 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
with CNTL/Z.
R3(config-router)#area 34 stub
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
with CNTL/Z.
Area 34 is now a stub area. Look at

R4s OSPF routing table:
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:01:07, Ethernet0
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:01:07, Ethernet0
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:01:07, Ethernet0
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. R5s
loopback addresses can still be
pinged:
R4#ping 5.1.1.1
!!!!!
R4#ping 6.1.1.1
!!!!!
R4#ping 7.1.1.1
!!!!!
The cost for the default route can be

adjusted with the default-cost
command. On R3, well change the
OSPF metric for the default route to

20, which should give it a total cost
of 30 on R4:
R3(config-router)#area 34 default-cost 20

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 doesnt have
to be added to the other routers in
the area, but they still have to be
configured as stub.
R3(config-router)#area 34 stub no-summary
A little theory vs. real-world

discussion is merited here. In the
real world, youll often see OSPF
total stub areas that have every
router in the total stub configured
with no-summary. That doesnt 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:
O*IA 0.0.0.0/0 [110/30]
00:07:26, Ethernet0
via
172.34.34.3,
Now weve 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, youll 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
area 34
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,
lets make Area 0 a stub! After all,
R2 and R3 only have one possible
next
hop
to
the
external
destinations, and thats through R1.
So lets try that
R1#conf t
with CNTL/Z.
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 shouldnt do.
Or at the very least, youll be
warned!
Here, the router wont 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 wont 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 youll read more about
in the LSA review later in this
section.
This is a highly specialized OSPF
area type, and its not common, but
they are out there. Lets take a look
at the commands to configure a stub
NSSA and total stub NSSA.
Well now add another loopback to
R3 and inject it into the OSPF

domain with the redistribute
connected subnets command.
R3(config-if)#ip
address
255.255.255.255
14.14.14.14
subnets
connected
R1 will see the route as an E2

route
O IA
2.2.2.2 [110/65] via 172.12.123.2,
00:03:11, Serial0
O IA
33.33.33.33 [110/65] via
172.12.123.3, 00:03:11, Serial0
O IA
3.3.3.3 [110/65] via 172.12.123.3,
00:03:11, Serial0
O IA
172.34.34.0 [110/74] via
172.12.123.3, 00:03:12, Serial0
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.
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
Well 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
Neighbor Down: Adjacency forced to reset
R3(config-router)#area 34 nssa
R4(config-router)#no area 34 stub
R4(config-router)#area 34 nssa
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.
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:00:14, Ethernet0
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:00:14, Ethernet0
O
33.33.33.33 [110/11] via
172.34.34.3, 00:00:14, Ethernet0
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:00:14, Ethernet0

O IA
172.12.123.0 [110/74] via
172.34.34.3, 00:00:14, Ethernet0
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 R3s NSSA statement. Note that
the adjacency again goes down.
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
Neighbor Down: Adjacency forced to reset
4.4.4.4 on Ethernet0 from LOADING to FULL,
Loading Done
R4 now has a default route in

addition to the N2 route.
O
33.33.33.33 [110/11] via
172.34.34.3, 00:00:25, Ethernet0
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, lets
go over the meaning of each type.

R1#show ip route
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.
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:
O IA
1.1.1.1 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
O IA
2.2.2.2 [110/75] via 172.34.34.3,
00:01:03, Ethernet0
O IA
3.3.3.3 [110/11] via 172.34.34.3,
00:01:03, Ethernet0
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
O E2
6.1.1.1 [110/20] via 172.34.34.3,
00:33:21, Ethernet0
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
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, well look at
two of the original external routes
in R4s 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:
rip
subnets
metric-type ?
1 Set OSPF External Type 1 metrics
2 Set OSPF External Type 2 metrics
metric-type 1
rip
subnets
Look at the same two routes in R4s

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
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. Thats 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 heres 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
Weve 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
cant 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, lets 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. Thats the only
requirement. Our OSPF network
contains three backbone routers;
R1, R2, and R3.

Its 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
theyre both internal routers. They
also have at least one interface in
Area 0, so theyre 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
wont surprise you to find that there
are different LSA types being sent
around an OSPF network. The
contents of a routers 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. Thats another way multiarea OSPF lessens the load on a
routers 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 isnt
in widespread use, but it doesnt
hurt to know about LSA Type 6
while were 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 dont
leave that area; they are actually
converted into Type 5 LSAs and are
then sent out of the NSSA.
Heres 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
Its 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
its 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 cant be a stub or total stub.
The routing table can still be made

smaller via route summarization.
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.)
Well
now
configure
route
summarization with the area range

command. This is configured only
on an ABR. Well 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
!
ip address 11.1.1.1 255.0.0.0
0.255.255.255 area 1
0.255.255.255 area 1
0.255.255.255 area 1
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:
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d01h, Serial0
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d01h, Serial0
O IA
8.1.1.1 [110/65] via 172.12.123.1,
00:02:44, Serial0
O IA
9.1.1.1 [110/65] via 172.12.123.1,
00:02:34, Serial0
O IA
10.1.1.1 [110/65] via 172.12.123.1,
00:02:34, Serial0
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.
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d02h, Serial0
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d01h, Serial0
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

R2#ping 9.1.1.1
R2#ping 10.1.1.1
timeout is 2 seconds:!!!!!
R2#ping 11.1.1.1

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

O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d02h, Serial0
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d01h, Serial0
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d02h, Serial0
O E1
4.1.1.1 [110/84] via
172.12.123.1, 00:06:31, Serial0

O E1
5.1.1.1 [110/84] via
172.12.123.1, 00:08:33, Serial0
O E1
6.1.1.1 [110/84] via
172.12.123.1, 00:08:33, Serial0
O E1
7.1.1.1 [110/84] via
172.12.123.1, 00:08:33, Serial0
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 weve got the
summary address and mask; these
values are applied to the ASBR
with
the
summary-address
command.
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.
O IA
1.1.1.1 [110/65] via 172.12.123.1,
2d03h, Serial0
O IA
33.33.33.33 [110/65] via
172.12.123.3, 2d01h, Serial0
O IA
3.3.3.3 [110/65] via 172.12.123.3,
2d03h, Serial0
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

R2#ping 5.1.1.1
R2#ping 6.1.1.1
R2#ping 7.1.1.1

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 wont 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 Dont Forget
Youve got a lot of new and
detailed commands to learn with
OSPF, but dont 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 its 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 its a good idea
to know exactly how theyre used.
Well 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. Theres a classic
gotcha with this command that
you should be familiar with. Ill
configure
a
password
of
ccnptestexam on the serial interface
and then look at the routers
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. Thats because this
command has a limit of eight
characters, and for some reason the
IOS doesnt 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
theres 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
Well 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#
172.12.123.2 on Serial0 from FULL to DOWN,
R1#
172.12.123.3 on Serial0 from FULL to DOWN,
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-if)#ip
ospf
authentication-key
ccnptest
R3(config-if)#ip
ospf
authentication-key
ccnptest
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.
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,
well 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. Well authenticate that
adjacency with the password CCIE.
The ip ospf message-digest-key
command is rather long, so well
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 R3s ethernet0
interface.
R3(config)#int e0
R3(config-if)#ip ospf authentication messagedigest
R3(config-if)#ip ospf message-digest-key 1
MD5 CCIE
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
Id have a lot of nickels. You have
to use adj, because the full word

doesnt work with this debug!
R3#debug ip ospf adj

OSPF adjacency events debugging is on
For the first debug example, Ive

removed
message-digest
authentication from R3s ethernet
interface and replaced it with cleartext authentication. As expected, the
adjacency goes down quickly.
R3(config)#int e0
R3(config-if)#
172.12.23.2 on Ethernet0 from FULL to
DOWN, Neighbor Down: Dead timer expired
But if you didnt 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 theres a
mismatch in the authentication type.
The incoming Hello is using type
2 authentication (MD5). Since
R3s ethernet0 interface is running
type 1 (clear-text), we have a
mismatch. By changing R3s 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#
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.
Ill remove the initial key from R3s
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

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
Thats 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
were 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 cant 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 - R1s serial0
interface, 172.12.123.1.
That fact would simply scream at us

to configure this as a stub or total
stub area, but theres just one
problem
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>
area
. all three routers are in Area 0,

and we cant 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,
well need to use the always option.
Heres what happens if we dont 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
R2#
Nothing on R2 or R3. Well go back

to R1, remove the first version of
the command, and replace it with
the same command and the always
option.
default-information
originate
always
And now to R2 and R3 .

O*E2 0.0.0.0/0 [110/1]
00:00:10, Serial0
via
172.12.123.1,

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:
v=hGrbyb6p4MI
OSPF ABR 3-Minute Boot Camp:
v=cZityXoLmgI
Video Practice Exam: Link State
Protocols
v=yTBYdICOHGM
OSPF Over Frame Relay: Practice
Exam and Tutorial:

v=VfILkf9s5OE
OSPF Video Practice Exam:
v=jQAQFk3Xseo
OSPF Stub Areas and Route
Redistribution Video Boot Camp

BGP
Introduction To BGP
BGP is like nothing youve 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, youll
see what Im 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 youve
mastered so far in your studies. The
term autonomous system applies
to EIGRP as well as BGP -- youll
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 youll
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 youve
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.
Youll 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,
its
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 dont
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 arent.
Before we get too deep into BGP
theory, lets get a configuration
started. Youll 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 speakers
potential neighbors.
(The terms peer and neighbor
are interchangeable in BGP, but its
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 dont have to

know every single one of these to
pass the CCNP ROUTE exam. Im
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.
Lets start with the basics and
configure R1 and R3 as eBGP
peers. Well place R1 into AS 100

and R3 into AS 200. The routers
are on the 172.12.123.0 /24
network.
% 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, lets 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.
Theres nothing wrong with this
state, but we dont 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 were 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 hasnt heard anything back

yet.
As with Idle, theres nothing wrong
with this state - unless your
connection stays there. If the
connection goes Active and stays
there, its really a mirror image of
the Idle issue we spoke of earlier,
so
Check the remote routers
neighbor statement
Be sure the remote router
knows how to get the
OpenConfirm packet back to

the local router (OpenConfirm
is BGPs 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,
thats not as good as it sounds. Of
course, the reason the peer
relationship hasnt been established
is that we havent configured R3

yet!
remote-as 100
172.12.123.1
Verify the peer establishment with

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
Neighbor capabilities:
Route refresh: advertised and received(old
& new)
Address family IPv4 Unicast: advertised
and received
queue
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 theyve 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
routers own IP address as a BGP
peer address!)

172.12.123.3
remote-as 200
172.12.123.1
remote-as 100
% Cannot configure the local system as
neighbor
172.12.123.2
remote-as 100

BGP neighbor is 172.12.123.2, remote AS 100,
internal link
BGP version 4, remote router ID
172.12.123.2
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 youre shown how to create
those interfaces, but not really given
many reasons why. Heres 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 heres
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. Youll 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
routers loopback. After all, for this
config to work, the router needs to
know how to get to the address used
in the neighbor command.
Lets 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-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
3.3.3.3
ebgpmultihop 2
R1(config-router)#neighbor 3.3.3.3 updatesource loopback1
R3(config-if)#ip
address
255.255.255.255
3.3.3.3

R3(config-router)#no auto R3(config-router)#no
synch
100
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 theyd 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
routers loopback address, the BGP
adjacency will form. Well 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 doesnt 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 dont forget about a simple
default route.
Naturally, those static routes have
to stay there; if theyre 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 theyre
built.
The AS number is incorrectly
identified in the config. If you
do this, trust me, youre not the
first and you wont 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
couldnt hurt on the exam) -- using

the mask in the network statement is
not required, but I highly
recommend you use it. If youre
called on to troubleshoot a BGP
configuration and its missing the
masks on the network statements,
that could well be the issue. Use the
masks or youll end up only with
the classful networks.
Here, well advertise R3s

loopback (3.3.3.3 /32) in BGP.
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.
Lets use another network to

illustrate what happens if the mask
is just a bit off
R3(config-if)#ip
address
255.255.255.0
33.33.33.33

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 doesnt even see the route in its
own BGP table!
The BGP network mask must match

the IP routing tables 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.
Heres how the route looks in the IP
routing table:
C
Loopback33
Once we change the BGP network

statement to reflect a /24 mask, the
route will appear in R3s BGP table
and be successfully advertised to
R1 via BGP. Well first remove the
erroneous network statement and
then enter the correct one.
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 weve 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 didnt
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,

well add a few extra routers and
some
additional
autonomous
systems. Every router will be
advertising its loopback address
into BGP, and every routers
loopback is its own number in each
octet (R1s loopback is 1.1.1.1,

etc.) Just for fun, well build some
multiple BGP peerings between two
routers; in production networks, we
most likely would not do that.
The BGP configurations of the

routers:
500
remote-as 100
remote-as 300
255.255.255.255
remote-as 100
remote-as 300
remote-as 300
remote-as 400
255.255.255.255
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
172.12.123.1
remote-as 100
172.12.123.2
remote-as 100
172.12.234.2
remote-as 100
172.12.234.4
remote-as 400
R3(config-router)#neighbor 172.12.34.4 remoteas 400
3.3.3.3
mask
255.255.255.255
172.12.234.3
remote-as 300
172.12.234.2
remote-as 100
R4(config-router)#neighbor 172.12.34.3 remoteas 300
4.4.4.4
mask
255.255.255.255

100
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.
R1s 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, heres
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.
Lets 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

R1s path selection for the network
3.3.3.3 and 4.4.4.4? Lets 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, lets look at
R1s 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)
internal
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)
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 cant 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
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
Sending 5, 100-byte ICMP Echos
172.12.234.4, timeout is 2 seconds:
..
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)#neighbor 172.12.123.1 nexthop-self
R1s 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.

10.1.1.5 172.12.123.2
300
172.12.123.3 from 172.12.123.3 (3.3.3.3)
external, best
300
172.12.123.2 from 172.12.123.2 (2.2.2.2)
internal

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)
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. Its important to know
this list for any real-world job

involving BGP - but it wont hurt on
exam day, either.
The Next-Hop Attribute
We just spent quite a bit of time
examining this attribute, but lets
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 R3s serial
interface.
Makes sense, right? Right!

Now heres 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 theres 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 wont
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 R3s 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)#?
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 ?
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
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)
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, well double the default local
preference on R1.
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 wouldnt expect the
exam to remind you, though.)
Lets take a look at R2s 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
10.1.1.4
34
10.1.1.3 from 10.1.1.1 (172.12.123.1)
valid, internal, best
34
10.1.1.4 from 10.1.1.4 (4.4.4.4)
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,
Id
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)#no bgp
preference 200
default
local-
255.255.255.0
210.1.1.0
mask
255.255.255.0
210.1.1.0
mask
Lets 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 wont 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 dont 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.
Were not denying traffic with this
config, though - were 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)#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)#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
R1s
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 dont 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
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
interface Ethernet0
ip address 100.1.1.3 255.255.255.0
As expected, R2s 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 dont 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 its 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 routers 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.

remote-as 123
remote-as 123
172.12.123.2
172.12.123.3

172.12.123.1
remote-as 123
4
R2(config-router)#neighbor 172.12.123.1 next-
hop-self
172.12.123.1
remote-as 123
4
123
123
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, heres 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
theres 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 youre 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
well 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 wed change the local
pref to get a similar result.
This change to a routes 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 wont, so lets 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.
Thats all fine - but whats
aggregation? Its just another term
for summarization. Youll 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 youll see later in

this section.
And who doesnt like less work?
The Originator ID and Cluster ID
Attributes
Both these optional attributes can
be put into effect when route
reflectors are used. Well examine
these attributes during the route
reflector discussion.
BGP Route Aggregation (Not
AggreVation)
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. Youll 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.
255.0.0.0
255.0.0.0
255.0.0.0
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 its 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, its time for our old friend
binary math! Since these networks
all have 0 for the last three octets,
well 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.
Well 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.
Its 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.
Theres 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 isnt being advertised, be sure
your BGP table actually has the
routes being summarized.
Resetting and Clearing The BGP
Peer Connections
Sometimes youll 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#
10.1.1.5 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.

Its common practice to use a
remote routers 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, lets examine
BGPs 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 cant 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, R5s
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 Synchronizations
major
benefit is that packets that cant
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 cant reach the
destination?
BGP Synchronization is turned off
in many deployments, though, and
as of IOS version 12.2(8) its
turned off by default. There are
three scenarios under which its
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)#no synchronization
The Problem With BGP Full

Mesh Deployments
BGPs 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 cant 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? Theres a
reason - and its the same reason
we dont see many BGP full
meshes.
Any full-mesh deployment of BGP
is going to have a large cost on the
routers 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 youll 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. Thats 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 youll 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
youve 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.
Youre going to spend a lot of
time configuring all these peer
connections, and sooner or
later, youre going to miss one
(especially in a large AS).
Then you get to spend even
more time troubleshooting
your network!
Luckily, theres 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
dont 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, wed 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.
Thats a huge reduction in the
overhead caused by all those TCP
connections, not to mention the
hours
of
configuration
and
troubleshooting youll 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.
Lets 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 routers
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 R4s loopback in its BGP
table:
What about the other routers in AS
1235? Will they have this route in

their BGP tables? Lets first look at
R3s iBGP peer, R1:
The route is there but there is no

> next to the route, so this is not a
valid and best route.
Heres a good three-step t-shooting
process for BGP - and for just about
anything else in Ciscoworld:
What is the problem?
If we dont immediately know

what the issue is, what
command will show us what
the problem is?
Once weve 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 R1s IP routing table, or
configure next-hop-self on R3.
Lets get some practice with nexthop-self:
The result is a next-hop address that

R1 can reach, so the BGP route is
now valid and best.
What about R1s 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 BGPs 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.
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 doesnt have the route to R2s

network, since it was learned by R1
via an iBGP peer (R2) and cant 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
routers resources, and will take
additional time to configure and
possibly troubleshoot -- and its 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)#neighbor 172.12.123.2 routereflector-client

172.12.123.2 Down RR client config change
R1(config-router)#neighbor 172.12.123.3 routereflector-client
172.12.123.3 Down RR client config change
172.12.123.2 Up
172.12.123.3 Up
The results here may be different

than those youve 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 its
an important point to remember.

Especially on production networks!
:)
Lets 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 cant turn BGP
Split Horizon off at the interface
level.
So if BGP Split Horizon is there to
prevent routing loops, why dont
we have routing loops form when
using
route
reflectors
and
effectively disabling Split Horizon?
Were going to answer that in just a
moment. First, lets 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
theres some great information here.
Below
you can see
that
172.12.123.2 is seen as a route
reflector client. Im only showing
you about half of this commands
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
internal link
BGP state = Established, up for 00:00:41
Route refresh: advertised
and received
queue
Sent 890 messages, 0 notifications, 0 in
queue

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 youve got the basic BGP
configuration up and running, its
time to fine-tune the routes being
advertised
or maybe the routes you dont
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, theyre

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.
Its also easy to go back and insert
lines in the middle of a pre-existing
prefix list, which is great when

youve written a 20-line list and
suddenly have the need to put a line
at position 12.
Before we look at the actual
configuration, lets look at the
theory of how a BGP prefix-list
operates. Its quite similar to an
ACL. First, if a route is expressly
permitted, its used; if its denied,
its 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, its
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 dont actually number
the statements as you write the

prefix list, theyre 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, well
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.
ip address 16.1.1.1 255.0.0.0
!
ip address 17.1.1.1 255.0.0.0
!
ip address 18.1.1.1 255.0.0.0
!
ip address 19.1.1.1 255.0.0.0
!
255.255.255.255
255.0.0.0
5.5.5.5
mask
16.0.0.0
mask
17.0.0.0
mask
255.0.0.0
255.0.0.0
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. Well remedy that with the
appropriate
next-hop-self
commands on R1.
Lets verify that commands 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 dont want
every router in a network to have
every available route.
Lets 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. Lets write and
examine the prefix list first:
R1(config)#ip prefix-list
deny 16.0.0.0/8
deny 17.0.0.0/8
deny 18.0.0.0/8
deny 19.0.0.0/8
permit 0.0.0.0/0 le 32
NO16THROUGH19
NO16THROUGH19
NO16THROUGH19
NO16THROUGH19
NO16THROUGH19
Dont 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,
doesnt it? This is the prefix list
equivalent of an ACLs 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,
lets 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>
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)#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, youve 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.
Lets 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
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 routers
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 youll
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.
AS1235GROUP
peer-group
AS1235GROUP
remote-as 1235
AS1235GROUP
route-map AS_POLICY out
R1(config-router)#neighbor 2.2.2.2 peer-group
AS1235GROUP
AS1235GROUP
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 - its outbound. To
repeat, peer group members are
required to share the same outbound
policies. They can share the same
inbound policies, but they dont
have to.
Peer group names are locally
significant only - the name of the
group isnt passed to other routers.
This means you can reuse the name
throughout the network, but Id be

careful about that - it can get a little
confusing to the network admins.
Peer groups take a little getting used
to, but theyre 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.
R1s configuration will look like

this:
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
123
123
R1(config-router)#neighbor 5.5.5.5 remote-as 7
671
R9s neighbor statement for R1 will refer to AS
321, the confederation number.
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 Ciscos
website
for
the
available
communities for your IOS. Youll
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. Were
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 dont 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 ISPs 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 youve got a
brand-new top-of-the-line router for
R6 here, but that isnt 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, youve
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: Dont ever, ever, ever
perform redistribution between IGP
and BGP unless you really know
what youre doing. And I mean
really know what youre doing.
Thats what practice labs are for!
Route redistribution isnt always
bidirectional. You can redistribute
RIP routes into an EIGRP AS
without taking the EIGRP routes and
placing them into RIP.
Whats 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.
Youre 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 ?
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 cant assign
AS number zero with BGP, just as
you couldnt 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 routers BGP
neighbors, it may well be too much
information. Heres the output of
show ip bgp neighbor on a BGP
speaker that has only one neighbor!

internal link
Route refresh: advertised and
received(new)
and received
queue
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
Thats 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
Theres 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 weve 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 ?
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#show ipbgp
15.1.1.5 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 - thats 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 youre looking at a
potential eBGP neighbor and that
neighbor isnt 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. Its doubtful
thatll 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 theyre

in the same autonomous system, its
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 *
-- thats a hard BGP reset and it
brings the adjacencies down. We go
to a lot of trouble to build those
suckers, so lets 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 youre like me - and I mean
no insult by that - youd wonder
why the soft option by itself
doesnt 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
its still a bit of a memory hog.
We have a relatively new method of

performing this reset thats 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
internal link
Member of peer-group POLICYOUT for
session parameters
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 arent 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>
Weve 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#
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#
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: 172.12.123.2 reset due to User
reset
20:32:34: BGP: 172.12.123.3 reset due to User
reset
R1#
R1#
from 1 to 1
R1#u all
All possible debugging has been turned off

Troubleshooting
advertisements:
BGP
route
v=6d1P3GWLo_w
Configuring and
troubleshooting
BGP route summarization:

v=qKrJ14Hbdts
More BGP route aggregation:
v=80fGaebifHo
Video Practice Exam on BGP
attributes:
v=gMApy_pVctU
Video Practice Exam on BGP

fundamentals:
v=hkG2ZOvos8c
already low price!
and on DVD!

The Remote Workplace,

Part I: VPNs And IPSec
These days, its not enough to have

communication - we need secure
communication. Virtual Private
Networks (VPNs) are a great way
to secure these transmissions.
Its 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.
Whats 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, its

actually seen as a separate interface
- youll 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 dont refer to the same
feature. Lets 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 receivers 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. GREs drawback is that theres
no encryption scheme, and thats a
pretty big drawback.
Defined in RFC 2661, The Layer 2
Tunneling Protocol (L2TP) is
actually a hybrid of Microsofts

Point-to-Point Tunneling Protocol
(PPTP) and Ciscos own Layer 2
Forwarding (L2F). Again, the major
drawback is that L2TP doesnt 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 thats
why youll see more IPSec in
todays networks than L2TP or
GRE. Thats also why were 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.
Well 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 As 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 As 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 somethings 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.
Thats 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 youd 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 Dans public key

and the CAs 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 Bobs
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 doesnt 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 its 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.
Thats because some of the IP fields
cant be correctly predicted by the
receiver - these are mutable fields
which
may
change
during
transmission. AH will successfully
protect the IP packets payload,
though, which is really what were
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 youd 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 isnt
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 its 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 doesnt 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. Well configure one later
in this section.
The routers will now enter IKE

Phase I. Assuming were 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,
IKEs looking for an ISAKMP
policy thats 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 were 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 tunnels 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. Its 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
Were not going to use the default,

however. Well 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. Well 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. Well 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 well 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 well 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.
Well 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 doesnt match, the
receiver checks its next lowest
numbered policy. Its vital to
remember that just because the first
policy comparison doesnt 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 theres 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.
Youd think that all five values

would have to match for the
negotiation to be successful, but
thats not quite true. Heres 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 youll see below on
R1. IOS Help shows that the
options are slightly different
between the IOS versions were
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, theres
nothing to show! The ISAKMP SA
doesnt exist until the entire IPSec
configuration is in place and

interesting traffic has started the
process. Thats one frustrating thing
about IPSec - theres a good deal of
configuration, but you really cant
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 theres an exact match, the IPSec
process continues; if theres 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? Were
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 wasnt.
Such traffic will be discarded.
Extended ACLs can serve as Crypto

ACLs, but theres 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 its unprotected.
The trickiest part of writing Crypto
ACLs for IPSec peers is making
sure theyre symmetrical rather than
identical.
Lets use the following network to
show you what I mean.
To have traffic on R1s ethernet

segment protected by IPSec if its
destined for the ethernet segment on
R2, R1s 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 R2s ethernet segment

to be protected by IPSec if its
destined for the ethernet segment on
R1, R2s 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 youre configuring IPSec and

concentrating on the many details
weve discussed in this chapter, its
really easy to think Hey, Ill just
write the ACL on one router and
then copy and paste it to the other.
Always double-check your ACLs if theyre identical, there is a
problem.
We dont 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,

its time to apply them to the
appropriate interfaces. Thats just
one purpose of a Crypto Map. Lets
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)#
Weve successfully created a crypto

map named CCNP, sequence
number 100, that will use ISAKMP
to establish the IPSec Security
Associations. Were 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 well leave
that value alone for now.
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)#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, well
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
*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,
(Tunnel),
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,
(Tunnel),

spi= 0x91791CF(152539599).!!!
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,
(Tunnel),
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),
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 dont want to see,
along with a quick explanation of
each courtesy of Ciscos website.
A common error message is
MM_NO_STATE, and if you think
that sounds bad, youre 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 peers 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):
recd
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),
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, youre 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 networks ACLs
are not inadvertently blocking these
ports and protocol numbers
anywhere you have IPSec running.
To review, heres 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 cant
do, and vice versa.
We
used
to
love
GREs
multiprotocol capabilities, but
thats not as important to us in
todays 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
couldnt 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 cant
handle all multicast traffic,
however.
Multicast
traffic
generated by OSPF and EIGRP
cant be carried by basic IPSec weve 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 others 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, Ciscos
website recommends the use of
transport mode over tunnel mode
with GRE over IPSec. Using
transport mode results in less total
overhead, and were 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, thats enough talking about
GRE over IPSec. Lets configure it
with SDM - the Security Device
Manager.
NOTE: SDM has actually been
phased out by Cisco, but since many
CCNP candidates havent seen a
Cisco GUI, I want you to see one

here.
Configuring A GRE Tunnel Over
IPSec Via SDM (PDQ)
As always, well start by clicking
the Configure button, and from
there choose VPN.
From the main VPN window, well

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, were given some reminders
of why were 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 dont
have any of these features on this
interface, but if we did, its good
information to have in mind for the

tunnel config.
Now back to the config! Were 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 well
accept the default IKE policy.
The next window is the Transform

Set selection area, and well accept
the default there as well.
Were 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 youre 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, Id
suggest working with the delay
option rather than the other metrics

as its 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. Well 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. Ciscos website offers
several solutions to this issue,
should you run into that problem in
the real world.
As always, were presented with a
Summary of the configuration
weve chosen.
At this point, the VPN is down,

since we havent 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 cant 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 were in a lab environment,

Im going to do just what they told
me not to do, and save this config
and then paste it into the
downstream router.
Heres 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
routers 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.
Whats 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 - thats
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
thats how Ill 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 weve 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
Well 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 Ciscos 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, were almost there!
IPSec Quick Mode then negotiates

the IPSec SA, and were all set.
Configuring Easy VPN Server In
SDM
Well start our Easy VPN server
config by clicking the VPN button in
the Configure section of SDM.
Youll see a list of topics under

VPN, and well select Easy VPN
Server.
The description screen shows the

following. Note the prerequisite
task.
Theres a link to enable AAA on

that screen, so Ill click that. Note
that the Enable Easy VPN button is
grayed out since AAA is not yet
enabled.
After clicking the enable AAA link,

were presented with this message:
We do want to enable AAA, so

well 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!
Heres the next window:
The interface facing the workstation

is Fast 0/0, so Ill choose that in the
drop-down box. Well 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 well use the
default.
The Transform Set selection

window is next, and well accept
the default there as well.
The next window prompts us for the

group authorization method, and
well use local authentication only.
I like the summary description here.

Actually, if you dont have a
RADIUS or TACACS server in
your network, the local database is
the only option you have!
In the next window, well indicate

local authentication for users.
In the next window, well 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.
Well enable Split Tunneling, which

is disabled by default. When I
clicked that check box, the Enter
the protected subnets selection
window enabled. Ill 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, were 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! Ill launch

the Cisco VPN Client and click
New.
Ill 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. Were not going to

configure
Mutual
Group
Authentication, but if we chose that
option, wed need to import a valid
root certificate.
Now the HQ connection appears

under Connection Entry. Ill click
Connect, and well 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 youll get check
marks when all is well. If
something isnt well, youll get
some great information on the issue
here. This is the first place I check
when a VPN configuration isnt
working correctly.
Youll also receive the following

confirmation that all is well.
Lets look at an SDM screen we
havent visited yet - the Monitor

screen. Just click the Monitor
button at the top of SDM, and
youre there.
This screen has buttons on the lefthand side as well. Naturally, well
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,

youll 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, youll 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, youll 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 whats 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.

The Remote Workplace,

Part II
Whether theyre 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 todays network
admins.
And thats 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
Lets take a look at that first
challenge - and at broadband.
Dialup connections are pretty much

a thing of the past for todays
mobile
workers,
thanks
to
broadband.
We know that broadband brings us a
lot more speed than the dialup
connections used to, and if youve
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
users connection is carried through
a preexisting cable TV connection,
enabling many cable companies to
offer do-it-yourself broadband
connectivity kits. (I notice those
arent 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)
? Thats 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 doesnt
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, heres 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, thats 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 youre 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 youre
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
customers 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.SHDSLs maximum
distance range from 20,000 feet to
28,000 feet, depending on whose
documentation youre 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 isnt
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
Theres 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? :) Its not as
complex as it seems.
When it comes to transporting data
over this setup, weve 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, youll 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
Heres the network well be
working with in the following
section. Well 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.
Heres 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, theres
only one possible exit interface for
it to use, and thats the dialer
profile on the way back to HQ.
Theres no need to run a routing
protocol, since the exit interface
will remain the same and well
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
were 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 wed 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 lets 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,
well 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, youll have many

options with DHCP on Cisco
routers, so just do your homework
on Ciscos 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 hosts 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 routers 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-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
210.1.1.3
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
permit
10.5.5.0
R3#conf t
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-if)#ip nat inside source list 1 interface
serial0 overload
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.

IP Version 6
Why Do We Need A Version 6 Of

IP, Anyway?
The main reason - were running
out of IPv4 addresses!
That isnt the only drawback to
IPv4 addresses as compared to
IPv6, but frankly, its 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 youve really
looked at IPv6 - and youre not
alone if it is -- thats the major
shock factor. Once you get used to
the address format, though, its
really not that bad.
Before we start comparing the
version, lets look at some
additional improvements brought to
us by IPv6:
Those dreaded broadcasts
were always trying to limit
are a thing of the past - IPv6
doesnt 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. Thats particularly
true when it comes to Mobile
IP. IPv4 can run that with
additional config (boo!), but
IPv6 doesnt 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 well jump into that right now
with a comparison of the actual
IPv4 and v6 headers.
IPv6 Header Fields
Youre familiar with the IPv4
headers, but there are quite a few
changes in the move to IPv6.
Heres a link to an illustration on
Ciscos 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
fields 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 - IPv4s
equivalent is the Total Length
field
hop limit - Roughly equivalent
to IPv4s 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
IPv4s Protocol field
source address, destination
address - theyre 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 isnt 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
dont 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 theres no difference
between an upper-case letter or
lower-case letter in hexadecimal.
Thats the first rule. The other rules
deal with all the zeroes youll run
into in IPv6 addresses.
If youre 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,
youll know how.
Please take my word for this: Even
if you think youre 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 doesnt 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. Heres 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.
Lets 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
Were 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
youll 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 youre 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 thats 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 youd 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.
Its 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 theres 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 thats just what this bit does
-it tells us whether this address is
universally unique or just locally
unique (unique only to this link). Its
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
youll occasionally see it called the
i/g bit for individual/group. If this
bit is set to zero, its a unicast
address; if set to one, its 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 well discuss is
aggregateable global unicast
address.
Quite
a
bit
of
documentation on IPv6 leaves the
aggregateable off, so well 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 - its an address that is kept

on the local link. Theyll 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 IPv6s
equivalent to IPv4s private address
classes. Youre likely reading that
and thinking If we dont need NAT
any more and we have sooooo many
addresses with IPv6, why do we
need private address classes?
Great question! Its such a great

question that site-local addresses
are no longer used by IPv6. Im
mentioning it here just in case
youve read some of my older IPv6
materials (or someone elses!) 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, doesnt it?
Unique to IPv6 is the unspecified
address. You may be thinking if
its 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

zs are the rightmost 24 bits
of the unicast/address of the
node.
Heres a link to a regularly-updated
IANA document with plenty of
additional reserved addresses and
links to related RFCs. Its 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
couldnt 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 Im closest. How am I
closest? What is so closest about
me?
Sorry. But we really do need to
know how IPv6 defines closest
here
Its the first learned directly
connected neighbor - if there
are directly connected

neighbors.
If thats not the case, its
simply the closest neighbor as
determined by the routing
protocol metric.
Thats how Im closest, Henry.
The
IPv6
Process
Autoconfiguration
IPv4 has DHCP; IPv6s 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, thats because it is DHCPv6, actually! You hear the
term stateful autoconfiguration
more often than DHCPv6, though,
but you should know theyre one
and the same.
The key phrase there is from a
server. If the DHCPv6 server goes
down, were out of luck. With
stateless autoconfiguration, theres
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
heres 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. Its been
successfully calculated, but now we
must make sure that no other host is
using the same address. Thats a
remote possibility, but still a
possibility, and thats 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.
Whats 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,
youll 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

hosts link-local address, which
results in the hosts 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 routers
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. Lets take a look at some
basic OSPFv3 commands and
compare OSPF v3 to IPv4s OSPF
v2.
During your migration between the
two, you may run both v2 and v3 on
the same router. Theres 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, youre 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 routers RID - and v3 is going
to use an IPv4 address as the RID!
If there is no IPv4 address
configured on the router, youll
need to use our old friend router-id

to create the RID. The RID must be
entered in IPv4 format, even if
youre 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 cef
R1(config)#ipv6 router ospf 1
R1(config-rtr)#
R2(config)#ipv6 cef
R2(config-rtr)#
If you dont have any IPv4

addresses configured on the router,
you must configure an OSPF RID
with the router-id command.
R1(config-rtr)#router-id 1.1.1.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
R2(config-rtr)#int fast 0/1
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
local address
FE80::20A:41FF:FE64:31C2
Index 1/1/1, flood queue length 0 Next
0x0(0)/0x0(0)/0x0(0)
0 msec
count is 1
Adjacent with neighbor 1.1.1.1 (Backup
Designated Router)
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

IPv4s 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
0x0293F7
Flood list length 0
The IPv6 equivalent of OSPF

IPv4s 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 were not running OSPF v2.
OSPF v3 still asks us if were
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]
L 5DDE:EEEE:1::1/128 [0/0]
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 thats 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, youre 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 routers 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. Lets 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 whats 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 its 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 dont need to know
IPv6. I heard the same thing when
Windows 2000 Server came along We use NT4 and well use that
forever. That didnt work out for
too many people.

My point here is that you dont 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 dont. Like IPv6.
Those who know IPv6 are going to
have a huge advantage over those
who dont. Ive 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. Youll be glad you

did!
Copyright 2012 The Bryant Advantage..

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
doesnt have to be a dynamic
routing protocol - we can
redistribute directly connected
networks and static routes.
Sounds simple, right? Maybe even
fun?
Actually, youll 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. Thats
especially true when youre
redistributing between
networks with multiple
entrance / exit points.
Were in the business of
details, but with route
redistribution, you really have

to watch the details. Some
protocols require seed
metrics; others dont. Some
require you to configure a
default metric; some dont.
The rules arent complex, but
they are vital.
Route redistribution is much like
route summarization in that theyre
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, youre going
to find very few scenarios where
route redistribution takes place
automatically. Its a good idea to
know where that might happen,
though
Heres a network where the nowobsolete IGRP is the LAN protocol,

and OSPF is used as the
organizations 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 doesnt have any
of the OSPF routes.
Thats likely the way we want it,
for two major reasons:
Theres no reason for the LAN
to have individual routes for
any destinations across the
WAN, since the next-hop
address would always be R1.
Theres 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
were 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,
wed 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).
Lets 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

D
2.2.2.2 [90/2297856] via
172.12.123.2, 00:09:33, Serial0
D
3.3.3.3 [90/2297856] via 172.12.13.3,
00:00:29, Serial1
.. but neither R2 nor R3 sees the

others loopback.

R2#
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
havent
done
any
route
redistribution, so we have no
external routes. Well 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 others loopback.

O
2.2.2.2 [110/65] via 172.12.123.2,
00:00:35, Serial0
O
3.3.3.3 [110/65] via 172.12.13.3,
00:00:07, Serial1
R2#
R3#
Now that weve covered nonredistribution in detail, lets get to

some redistribution!
RIP And The Seed Metric
RIPs configuration is pretty simple

- so maybe redistributing routes into
RIP is simple, too.
Maybe.
Lets take a look at the redistribute
command in a RIP config with IOS
Help.
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, its not enough to do the
job when redistributing routes into
RIP - we need to plant a seed.
Seed metric, that is.
RIPs sole metric is hop count. If
we redistribute an OSPF route into
RIP that has a cost of 74 - a
common OSPF metric - RIP doesnt
want anything to do with that route,
since RIP considers a metric of 16
to be unreachable.
We have to tell RIP heres 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, well try to
redistribute the route without
specifying the seed metric.
R1#show ip route
C
20.1.1.0 is directly connected, Serial0
O
172.12.34.0 [110/74] via 172.12.13.3,
00:00:12, Serial1
C
Serial1
R1(config-router)#redistribute ospf 1
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

youve 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 dont see any of the

routes, theres likely another
issue. Well 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
youve successfully performed
route redistribution and find
some pings dont go through
during your testing, its likely

you need to redistribute your
connected networks.
In this example, redistributing
OSPF routes into RIP isnt
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#
When a show command returns

nothing, theres 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
its 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 its R2 that isnt getting

the routes, the troubles at the
border router.
We didnt 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. Lets go
back to R1 and run the command
again, but use a seed metric this
time.
R1(config-router)#no redistribute ospf 1
R1(config-router)#no redistribute connected
ospf
1
metric 2
metric 2
I removed the original redistribute

commands. When you configure a
redistribute statement, that does not
remove any previously configured
ones. (Its common to have multiple
redistribute commands in a
protocol config.)
Lets go to R2, clear the routing
table, and see what the situation is
now with 172.12.34.0 /24.
R2#clear ip route *
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
..
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 didnt go
through!
Pings show us that there is an IP
connectivity issue, but they dont
tell us where the problem is. To
begin pinpointing an IP connectivity
issue, run traceroute.
R2#traceroute 172.12.34.3
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.

Lets try pinging 172.12.34.3 from
there.
R1#ping 172.12.34.3
!!!!!
Interesting, eh? The real problem

here is that the pings can get from
R2 to R3, but R3 cant 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
doesnt 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
Were in the redistribution business
right now, so lets stay there.

% Only classful networks will be redistributed
connected
subnets
We didnt 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 its likely you do.

Lets look at R3s routing table
now:
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,
OSPFs 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).
Lets see if R3 and R2 can exchange
pings
R3#ping 20.1.1.2
!!!!!
min/avg/max = 100/101/108 ms
R2#ping 172.12.34.3
!!!!!
R2 can now ping R3s Ethernet0

interface, and R3 can ping R2s
Serial0 interface.
This is about as simple as a route
redistribution scenario can get, and
you saw that it could go wrong
easily. Thats why were 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. Theres always an
exception, and the exception
here is that BGP routes are
given a metric of 1 by OSPF.
And as youll 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.)
OSPFs default seed metric can be
changed in the redistribute
command itself. Here, well double
the OSPF default seed metric of 20
for
EIGRP
routes
being
redistributed into OSPF.
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
40
% Only classful networks will be
redistributed
40 subnets
Theres one more reminder to

include the subnets option if you
want subnets to be redistributed.
Call me crazy, but I think thats an
important detail to remember,
because the CCNP ROUTE exam
wont remind you of it.
Suboptimal Routing And Routing

Loops
When route redistribution works
well, its quite a rush, both in
production networks and the exam
room.
When it doesnt 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 youve 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 youre 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 R4s
resources.
Thats
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,
youve got a routing loop. as
youre about to see.
This labs networks:
Frame Relay: 172.12.123.0 /24

Ethernet: 172.23.23.0 /24
R3 / R4 Link: 172.34.34.0 /24
R4s Loopback: 4.4.4.4
advertised into OSPF
/32,
We want the routers in the RIP

domain to have connectivity to R4s
loopback - and as always, before

beginning
to
configure
redistribution, well check the
border router and make sure it has
that route to begin with!
O
4.4.4.4 [110/65] via 172.34.34.4,
00:00:03, Serial1
R3#ping 4.4.4.4
!!!!!
The
BR
has
the
route
and
connectivity to that network, so now

well config redistribution. This
time well use the default-metric
command to define RIPs seed
metric.
R3(config-router)#redistribute ospf 1
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 Ive seen admins

enter the redistribute connected
and redistribute static commands
when they werent really necessary.
You might want to avoid this blind
configuration, since someone may
add a static route to the config later
that you dont 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 R1s serial interface, not
R4s.
Lets see the result on R2:

R
4.4.4.4 [120/2] via 172.23.23.3,
00:00:07, Ethernet0
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. Lets ping 4.4.4.4 now:
R2#ping 4.4.4.4
..
We had connectivity a few minutes
ago, and lost it when that static

route was redistributed -- and thats
because the result of that
redistribution is a routing loop, as
shown by traceroute.
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,
heres whats happening:
Line 1: R2 pings 4.4.4.4.

According to R2s 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 -R1s 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 -- R2s 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, were 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 its more than worth
your time to carefully analyze your
network topology and identify
potential trouble spots.
If youre lucky, youll 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, its not always that easy many networks have multiple
connectivity points between routing
domains for redundancys sake.
This is a great idea - until you have
to configure redistribution. Then
youre going to hate redundancy.
(Its okay, I wont 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 youd have to
concern yourself with here are
routes being sent back and forth
between the other routers.
Ive 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. Youve 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
Protocols
Distance
And
Adjusting A
Administrative
You know what the AD is and you

know the common and not-socommon AD values - and now
were 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, theres 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, youve got to make
some changes.
You cant 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, well 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 .

R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:19, Serial0
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
R3 sees the route, and well now

redistribute that route into the OSPF
domain. I put R2s table there as
well, because its a very good idea
to keep an eye on the other routing
tables in your routing domain as
well
when
performing
redistribution.

connected
subnets
R3(config-router)#router rip
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 R3s E0
interface.
R5 shows the exact same OSPF
routing table:

O E2
172.12.123.0 [110/20] via 30.1.1.3,
00:00:15, Ethernet0
O E2
10.1.1.0 [110/20] via 30.1.1.3,
00:00:15, Ethernet0
O E2
172.12.123.0 [110/20] via 30.1.1.3,
00:02:25, Ethernet0
O E2
10.1.1.0 [110/20] via 30.1.1.3,
00:02:25, Ethernet0
When you have multiple border

routers and youre configuring one
of them for redistribution, be sure to
watch the others for ill effects of
redistribution.
R2s
routing
redistribution:
table
before

R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
R2# (No OSPF routes to show)
R2s
routing
redistribution:
table

R2# (No RIP routes to show)
after

O E2
10.1.1.0 [110/20] via 30.1.1.3,
00:04:14, Ethernet0
We dont expect 172.12.123.0/24 to

show up in R2s RIP or OSPF
routing table, because its a directly
connected network. However, the
route to 10.1.1.0 /24 is now using
R3s Ethernet0 as a next-hop
address, and its 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 RIPs is 120, so the
OSPF route is chosen.
You would have noticed this by
looking at the table, but its 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
!!!!!
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 routes metrics
Filtering routes with
distribute-lists (covered in a
later section)
Lets apply the first option.
To change the AD of a protocol on a
router, use the distance command
under the appropriate routing
process. Well use this command to
change the AD of OSPF on R2 to

200.
ospf
OSPF distance
R2(config-router)#distance 200
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:02, Serial0

< No OSPF routes to show >

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 routes AD
has been successfully changed to
200.

O E2
172.12.123.0 [200/20] via 30.1.1.3,
00:00:04, Ethernet0
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, youll 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, lets take a routing
table from another lab. R2 has three
routes in its EIGRP routing table,
all with an AD of 90.
D
3.3.3.3 [90/409600] via 172.12.23.3,
00:00:28, Ethernet0
D
4.4.4.4 [90/409600] via 172.12.23.3,
00:00:28, Ethernet0
D
5.5.5.5 [90/409600] via 172.12.23.3,
00:00:28, Ethernet0
Lets 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)#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.

D
3.3.3.3 [90/409600] via 172.12.23.3,
00:00:27, Ethernet0
D
4.4.4.4 [180/409600] via 172.12.23.3,
00:00:27, Ethernet0
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 wont be used.
Now you know how to selectively
change the AD of those particular
RIP routes.
Default-Information
(Always?)
Originate
Youll see the following discussion

in the Multi-Area OSPF section as
well.
Since
this
command
redistributes a default route, Im
putting it here as well.

Its 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 cant 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 - R1s serial0
interface, 172.12.123.1.
That fact would simply scream at us

to configure this as a stub or total
stub area, but theres just one
problem
area
R1(config-router)#area 0 stub ?
no-summary Do not send summary LSA into

stub area
<cr>
area
. all three routers are in Area 0,

and we cant 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,
well need to use the always option.
Heres what happens if we dont:
R1(config-router)#default-information ?
originate Distribute a default route
?
always
metric
metrictype
route-
Always
advertise
default
route
OSPF
default
metric
OSPF
metric type
for default
routes
Route-map
map
<cr>
reference
R2#
Nothing on R2 or R3. Well go back

to R1, remove the first version of
the command, and replace it with
the same command and the always
option.
default-information
originate
always
And now to R2 and R3 .

O*E2 0.0.0.0/0 [110/1]
00:00:10, Serial0
via
172.12.123.1,

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. Youll
have to filter those some other way
- shortly, well 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.
R2#show ip route
< code table deleted for clarity >
network 0.0.0.0
C
Serial0
C
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.
Its easy to get ip default-network

and ip default-gateway mixed up.
Theyre 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
weve done here, redistributing a
static route is simple enough - just
watch the seed metric requirements
of the protocol receiving that route.
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>
EIGRP Redistribution
Well 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.
Well 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 - thats just an IOS quirk.
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
10 255 ?
<1-255> IGRP Effective bandwidth
metric (Loading) where 255 is 100%
loaded
10 255 1 ?
<1-4294967295> IGRP MTU of the path
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, its 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.
Lets check R4 and R5 to see if
their EIGRP tables show the
redistributed routes.
D EX
172.12.123.0 [170/1686016] via
30.1.1.3, 00:02:04, Ethernet0

D EX
10.1.1.0 [170/1686016] via 30.1.1.3,
00:02:04, Ethernet0
D EX
172.12.123.0 [170/1686016] via
30.1.1.3, 00:02:29, Ethernet0
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)#default-metric 1544 10 255 1
1500
Lets now look at R2s RIP and

EIGRP routing tables, before and
after redistribution.
Before redistribution:
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
R2# (No EIGRP routes to show)
After redistribution:
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:01, Serial0
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. Well 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?)
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 R2s routing tables:
D EX
10.1.1.0 [119/1686016] via
30.1.1.3, 00:01:45, Ethernet0
This skill becomes even more

valuable when youre 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
youd 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
youre 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. Were
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 were
dealing with Area 0:
If we are, default-information
originate (always) would
come in handy.
If were 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
youre dealing with:
RIP: Passive interfaces do not send
routing updates, but will accept
them. RIP adjacencies arent
affected by passive interfaces since
RIP doesnt have adjacencies in the
first place.
In the following example, R1s
Ethernet0 interface has been
configured as passive. R1s
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.
R1s 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.
R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:15, Serial0
R
30.1.1.0 [120/1] via 172.12.123.1,
00:00:15, Serial0

R
10.1.1.0 [120/1] via 172.12.123.1,
00:00:21, Serial0
R
30.1.1.0 [120/1] via 172.12.123.1,
00:00:21, Serial0
R5 does not see R1s loopback - the

passive interface is not sending
routing updates to R5.
R5#
Lets add the loopback on R5 to the

RIP process and see if R1 sees it:

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 arent 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.
Well 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? Lets 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 doesnt happen.
As a result, R5 loses the EIGRP
route for the Frame Relay network.
R5#
What about R2 and R3? Will they

still see the 30.1.1.0 /24 network?

D
30.1.1.0 [90/2195456] via
172.12.123.1, 00:08:47, Serial0
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.
Well 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.

O
30.1.1.0 [110/74] via 172.12.123.1,
00:02:52, Serial0
O
30.1.1.0 [110/74] via 172.12.123.1,
00:02:57, Serial0

O
172.12.123.0 [110/74] via 30.1.1.1,
00:03:02, Ethernet0
Lets make E0 passive and watch

the results.
We know what the first result is
going to be
R1(config-router)#passive-int ethernet0
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?
O
30.1.1.0 [110/74] via 172.12.123.1,
00:01:47, Serial0
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)#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, youll 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.
Heres the network for the first
example:
R1 is receiving RIP updates from

R5 for six networks:
R
5.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
R
6.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
R
7.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
R
8.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
R
9.1.1.0 [120/1] via 30.1.1.5, 00:00:09,
Ethernet0
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.
connected
subnets

O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
O E2
8.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
O E2
9.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0
O E2
30.1.1.0 [110/20] via 172.12.123.1,
00:00:07, Serial0

O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
O E2
8.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
O E2
9.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
O E2
30.1.1.0 [110/20] via 172.12.123.1,
00:00:20, Serial0
What if we dont 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 its
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
Doh!
Filtering routes with OSPF is just a
little tricky, since were not
filtering routes per se as we would
with RIP or EIGRP. We deal with
LSAs in link state protocols, and
we cant start filtering LSAs or our
OSPF databases in an area wont
be synched.
Lets try specifying a protocol there
instead of an interface.
R1(config-router)#distribute-list 17 out rip
We didnt get an error message, so

lets check the OSPF tables on R2
and R3
O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
O E2
30.1.1.0 [110/20] via 172.12.123.1,
00:02:04, Serial0
O E2
5.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
O E2
6.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
O E2
7.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
O E2
10.1.1.0 [110/20] via 172.12.123.1,
00:12:17, Serial0
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 R1s routing table, I
could have put the distribute-list in
the RIP process.
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:

R
5.1.1.0 [120/1] via 30.1.1.5, 00:00:00,
Ethernet0
R
6.1.1.0 [120/1] via 30.1.1.5, 00:00:00,
Ethernet0
R
7.1.1.0 [120/1] via 30.1.1.5, 00:00:00,
Ethernet0
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.
Lets use an EIGRP topology that
we used earlier in this section, but
well advertise routes from R2 in

this lab.
Here are those routes on R1:

D
2.2.2.0 [90/2297856] via
172.12.123.2, 00:00:09, Serial0
D
22.2.2.0 [90/2297856] via
172.12.123.2, 00:00:04, Serial0
And on R5:
D
2.2.2.0 [90/2323456] via 30.1.1.1,
00:00:15, Ethernet0
D
172.12.123.0 [90/2195456] via
30.1.1.1, 00:01:29, Ethernet0
D
22.2.2.0 [90/2323456] via 30.1.1.1,
00:00:10, Ethernet0
What if we dont want R5 to see

any of those routes - but we need to
keep the adjacency? That means we
cant 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:
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
D
2.2.2.0 [90/2323456] via 30.1.1.1,
00:11:36, Ethernet0
D
172.12.123.0 [90/2195456] via
30.1.1.1, 00:12:50, Ethernet0
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 theres 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
well check the EIGRP table on R5
immediately.
R5#clear ip route *
R5#

< 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

distribute list
02:11:27: IP-EIGRP: Int 2.2.2.0/24 metric
4294967295 - 1657856 4294967295
distribute list
as well as our old buddy 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 well 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.
R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:52, Serial0
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
1500
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.
D EX
2.2.2.0 [170/1734656] via 30.1.1.1,
00:00:16, Ethernet0
D EX
172.12.123.0 [170/2195456] via
30.1.1.1, 00:00:11, Ethernet0
D
172.13.13.0 [90/2195456] via
30.1.1.1, 00:06:28, Ethernet0
D EX
22.2.2.0 [170/1734656] via 30.1.1.1,
00:00:16, Ethernet0
D EX
2.2.2.0 [170/2221056] via
172.13.13.1, 00:00:31, Serial1

D EX
172.12.123.0 [170/2681856] via
172.13.13.1, 00:00:26, Serial1
D EX
22.2.2.0 [170/2221056] via
172.13.13.1, 00:00:31, Serial1
D
30.1.1.0 [90/2195456] via
172.13.13.1, 00:06:25, Serial1
What if we didnt 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)#distribute-list 47 out ethernet0
The result: R5 has none of the

routes.
R5#
and R3 still sees them all.

D EX
2.2.2.0 [170/2221056] via
172.13.13.1, 00:05:56, Serial1

D EX
172.12.123.0 [170/2681856] via
172.13.13.1, 00:05:51, Serial1
D EX
22.2.2.0 [170/2221056] via
172.13.13.1, 00:05:56, Serial1
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, whats the net effect
to all of our routing tables?
Lets 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. Well

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

D EX
2.2.2.0 [170/2221056] via
172.13.13.1, 00:00:17, Serial1

D EX
172.12.123.0 [170/2681856] via
172.13.13.1, 00:00:17, Serial1
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 R5s routing table?
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.
Lets 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 well want to do
more than simply permit or deny
routes to be advertised and
redistributed.
Sometimes well want to set
different metrics for different
routes, and maybe even change an
OSPF external route type or two and well do that with route maps.
Lets take a look at the mechanics of
route map operation, and then well
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
dont transmit. With route maps,
we can actually change route
attributes.
Heres an example of how an ACL
and a route-map work together well 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>
permit ?
<0-65535> Sequence to insert to/delete
from existing route-map entry
<cr>
permit 10
R2(config-route-map)#set ip next-hop 10.1.1.1
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. Well 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

its a good idea to give it an
intuitive name. Since were going to
change the next-hop IP address of
matching traffic, well call the 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 dont, 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.
Well 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:
R
222.2.2.0/24 [120/1] via
172.12.123.2, 00:00:16, Serial0
R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:16, Serial0
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)#
0.0.0.255
R1(config)#
Now well 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
(expanded
range)
IP accesslist name
prefixlist
Match
entries of
prefix-lists
<cr>
R1(config-route-map)#match ip address 2 ?
<1199>
<13002699>
WORD
(expanded
range)
IP accesslist name
<cr>
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?
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 well 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-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 were
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)#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
were denying it in the first place.
R1(config)#route-map RIP2OSPF deny 30
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, well write what I call a
catch-all clause - a clause that
matches any route that wasnt
specifically matched earlier. This
clause has no match rule, and since
were not changing any attributes, it

wont have any set rules either.
R1(config)#route-map RIP2OSPF perm 40
R1(config-route-map)#
As youve now seen, these can get

pretty involved!
Lets 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

Match clauses:
Set clauses:
metric-type type-1
route-map RIP2OSPF, deny, sequence 30
Match clauses:
Set clauses:
Match clauses:
Set clauses:
Now after all that, we get to apply

it!
Lets see the results of the
redistribution without the route-
map.
R1(config-router)#redis rip subnets
O E2
222.2.2.0/24 [110/20] via 172.13.13.1,
00:00:03, Serial1
O E2
2.2.2.0 [110/20] via 172.13.13.1,
00:00:03, Serial1
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:00:03, Serial1
O E2
22.2.2.0 [110/20] via 172.13.13.1,
00:00:03, Serial1
O
30.1.1.0 [110/74] via 172.13.13.1,
00:00:03, Serial1
O E2
222.2.2.0/24 [110/20] via 30.1.1.1,
00:00:15, Ethernet0
O E2
2.2.2.0 [110/20] via 30.1.1.1, 00:00:15,
Ethernet0
O E2
172.12.123.0 [110/20] via 30.1.1.1,
00:00:15, Ethernet0
O
172.13.13.0 [110/74] via 30.1.1.1,
00:00:15, Ethernet0
O E2
22.2.2.0 [110/20] via 30.1.1.1,
00:00:15, Ethernet0
Just what we expected. Now lets

remove that redis statement and
replace it with one that calls the
route-map. Well put a regular
redistribute connected in there,
too.
R1(config-router)#redis rip subnets route-map
RIP2OSPF
R1(config-router)#redis conne subnets
The result on R3:

O
E1 2.2.2.0 [110/104] via 172.13.13.1,
00:01:56, Serial1
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:01:56, Serial1
O
E1 22.2.2.0 [110/84] via 172.13.13.1,
00:01:56, Serial1
O
30.1.1.0 [110/74] via 172.13.13.1,
00:01:56, Serial1
Lets review the route-map on R1

and check the impact on R3:
R1#show route-map
Match clauses:
Set clauses:
metric 40
metric-type type-1
Match clauses:
Set clauses:
metric-type type-1
Match clauses:
Set clauses:
Match clauses:
Set clauses:
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 - theyre not
just for BGP configs.
Hey, theres 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.
Lets add a RIP route to the network

on R2 and see if its redistributed
into OSPF at R1 with the defaults.
The route is created and added to
RIP
R2(config)#int loopback 55
R2(config-if)#router rip
. the route is seen in R1s RIP

routing table
R
222.2.2.0/24 [120/1] via
172.12.123.2, 00:00:02, Serial0
R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:02, Serial0
R
55.5.5.0 [120/1] via 172.12.123.2,
00:00:02, Serial0
R
22.2.2.0 [120/1] via 172.12.123.2,
00:00:02, Serial0
and its seen at R3 with the

default seed metrics, having
matched clause 40 of the route-map.
O
E1 2.2.2.0 [110/104] via 172.13.13.1,
00:08:56, Serial1
O E2
55.5.5.0 [110/20] via 172.13.13.1,
00:00:24, Serial1
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:08:56, Serial1

O
E1 22.2.2.0 [110/84] via 172.13.13.1,
00:08:56, Serial1
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.
Ive 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)#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
Theres 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 theyre

redistributed, and then prohibit
routes with that same value from
being re-redistributed back into
the original routing protocol.
Lets use the previous lab topology
for a demo.
Lets say were 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.
Ive removed the previous labs
configuration and well start by
checking for RIP routes on R1.

R
2.2.2.0 [120/1] via 172.12.123.2,
00:00:20, Serial0
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 thats all we need to do, we
dont need an ACL or any match
statements - just this route-map:
R1(config-route-map)#set tag 10
The redistribution config:

R1(config-router)#redistribute rip route-map
RIP2OSPF subnets
% Only classful networks will be redistributed
connected
subnets
Dont 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 doesnt
matter, just make sure you put it
somewhere.
The OSPF table on R3:

O E2
2.2.2.0 [110/20] via 172.13.13.1,
00:00:24, Serial1
O E2
172.12.123.0 [110/20] via
172.13.13.1, 00:00:06, Serial1
O E2
22.2.2.0 [110/20] via 172.13.13.1,
00:00:25, Serial1
O
30.1.1.0 [110/74] via 172.13.13.1,
00:00:25, Serial1
Three routes are learned via

redistribution. You wont see tag
values in the routing table, but you
will see them in the extended show
ip route command. Lets run that
command for one of the external
routes and for the internal 30.1.1.0

network.
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
* 172.13.13.1, from 172.13.13.1, 00:00:43
ago, via Serial1
Route metric is 20, traffic share count is
1
Known via ospf 1, distance 110, metric 74,
type intra area
Last update from 172.13.13.1 on Serial1,
00:00:52 ago

* 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
wasnt learned via redistribution,
and therefore wasnt 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? Heres what that
route-map looks like now:
R1#show route-map RIP2OSPF
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.
Heres 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
Match clauses:
tag 20
Set clauses:

Match clauses:
Set clauses:
tag 10
The joy of sequence numbers!

If we had the permit clause run
first, everything would be permitted
and tagged with 10 -- even the
routes were 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. Thats why I put a
5 in the first line of this new
config - thats 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), youll 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 doesnt 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 heres
remember.
the
Route map
CHANGE_
CHANGE_
big
rule
to
If a packet doesnt 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 dont want to route packets
that dont 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)#route-map EXAMPLE permit 10
R2(config-route-map)#set ip next-hop 40.1.1.1
R2(config-route-map)#route-map EXAMPLE
deny 20
Assuming the route map has been

applied to the routers 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
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 didnt 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
youll use them often in production
networks as well - theyre not just
for BGP, it just seems that way!

Speaking of that, since weve used
these maps in different sections of
the course, heres 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), Dont 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 theyre 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)#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 wed

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 youll 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
youre 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.
Lets 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.
Theres one more use for such a
null route, and thats 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 didnt
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. Theres 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.
Theres
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
doesnt begin to describe what can
happen here.
Here, R1 is redistributing a BGPlearned route into OSPF. Thats 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 routers
going to discard the data.
By the
always
actually
security
applied.
way, black holes arent

a bad thing - theyre
an effective network
technique when properly
(Note the emphasis on
properly applied!) Thats beyond

the scope of the CCNP ROUTE
exam, but if you enter routing
black hole into your favorite
search engine, youll quickly find a
few documents on using black holes
for network security purposes.
Whether BGP is involved or not,
youve 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 cant
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 Ive warned you about 2000

times not to redistribute anything to
and from BGP unless absolutely
necessary, I wont 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)#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 ?
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

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

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 Protocols Default

Metric (Review)
Heres a quick review on using the
default-metric command with RIP,
EIGRP, and OSPF.
RIPs metric is simple - hop count and so is the command.
EIGRP requires five values to be

set:
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
?
<1-4294967295> Maximum Transmission
Unit metric of the path
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)#default-metric ?
<1-16777214> OSPF default metric
Recommended Video Viewing

From My YouTube Channel:
Troubleshooting
Redistribution:
Route
v=ol1boiYUtEk
Video Practice Exam on route
redistribution:
v=eY2yyRd0lvM
The Good, The Bad, and The
Redistributed
v=GdJOle54whI
Configuring and Troubleshooting
RIP Redistribution:
v=pRtZgfLxlbQ
Routing Loops In The Wild:
v=pKimoicJCFQ

already low price!
and on DVD!

Bonus Section:
Creating A VLSM Scheme
Working with VLSM isnt a topic

on the CCNP ROUTE exam, and
isnt covered in the Cisco study
guides on this topic - but its a
valuable skill to have.
For that reason, Ive included this
section on creating a VLSM
scheme.
Lets 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 were
not going to be subnetting those.
Also, keep in mind that while its
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, youll get a
message informing you that this is
not a valid host address.
R1(config)#int loopback 100
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, youve got
to know those network classes and
network masks. This is the starting
point for answering any subnetting
question, whether its 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. Ciscos 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
Ciscos 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, its 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.
Its much more likely that your
network will have segments that
need a lot of host addresses, and
other segments that may require
only two. Thats 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 youre 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, well 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
Ciscos 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 youre 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. Its a good idea to

keep a running chart of your VLSM
scheme, so well 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. Well 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, its 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 youve
got 30 left.) That gives us a subnet
mask of /27.

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 wed be looking out for in the
real world is that there are only 6
valid addresses on this subnet.)
Well 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; thats 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 dont need a practice exam to

practice this skill - just a few
minutes and something to write
with. Thats it.
And this I guarantee you: those few
minutes of extra practice here and
there add up big time. -- Chris B.

Bonus Section:
How To Develop A VLSM
Scheme
Heres a little more practice with

VLSM!
Our first drill will involve the
major network number 210.49.29.0.
Weve been asked to create a
VLSM scheme for the following
five networks, and weve 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
Well 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, well
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
32; 32 - 2 = 30). What is the
smallest subnet that can be created
with all host bits set to zero?

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.
Its an excellent idea to keep a
running chart of your VLSM
scheme, so well 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.

address. In this case, thats
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.

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. (Dont 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
address as before, and bring the
VLSM table up to date.
Weve 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 youre 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 didnt 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:
Were 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 weve allowed for the
networks future growth, were
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

256; 256 - 2 = 30). What is the
smallest subnet that can be created
with all host bits set to zero?

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.

140.10.1.0. With a need for 115
subnet mask be?
Seven host bits will yield 126

usable host addresses. The resulting
address are shown below, and NW
B is added to the VLSM table.

140.10.1.128. With a need for 90
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, well

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
dont - and how do you learn how
to do it?
Practice.
You dont 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


CCNP Route Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CCNP Route Guide

Uploaded by

Copyright:

Available Formats

Welcome to your Bulldog Study

Guide for the CCNP ROUTE exam!

(I do not use simulators in my books

Youll find Video Practice Exams,

Free Resources To Help You

In addition to this informationpacked CCNP ROUTE Study

Certification Channel has quite a

I have a separate Videos &

Copyright 2012 The Bryant Advantage.

Always loved, never forgotten.

Copyright 2012 The Bryant Advantage.

Theres only one way

of training to let you

leg for a DVD.

Throughout this Study Guide, The

All efforts have been made by the

This Course Guide is an original

Copyright 2012 The Bryant Advantage.

Okay, I know what youre thinking!

cant become truly great.

Lets get started!

RIPv1 will broadcast full routing

RIPv2 multicasts updates to

literally, how many hops there

There are two paths between A and

but RIP will see these paths as

routing loops. You saw all of these

Poison Reverse allows a router to

Its obviously in our best interest to

The Basics Of RIPv1, RIPv2, and

default, max hop count is 15

Sends entire routing table only

EIGRP is not a pure distance-vector

When a route lookup is performed

looking for the best route to use:

AD, the route with the lowest

example, but please note that IGRP

In this case, the OSPF route would

/24. The administrative distance

A tiebreaker is needed, and thats

here from the ADs you learned in

hows and whys of the routing

D - EIGRP, EX - EIGRP external, O OSPF, IA - OSPF inter area

10.0.0.0/24 is subnetted, 1 subnets

There is one RIP route and two

The network 172.12.23.0/27 is the

for a valid RIP route unless the

The term longest prefix

with the same prefix length and

In this example, we can also see

Outgoing update filter list for all interfaces is

Automatic network summarization is not

As great as dynamic routing

As well see in the Advanced

backup to a dynamic routing

no other match in the routing table

R1(config)#ip route 3.3.3.3 255.255.255.255

These two static routes are both

In the first example, the IP address

< code table removed for clarity >

The ip route statement contains all

have a match in the routing table

While the gateway is now set to

Floating Static Routes In Action