Link State Protocols and Single Area OSPF - 6

The Bryant Advantage Ultimate BSCI Study Guide
Chris Bryant, CCIE #12933 - www.thebryantadvantage.com
Back To Index
Link State Protocols And Single-Area

OSPF
Overview
Link State Protocol Basics
LSA Sequence Numbers
When Are LSAs Exchanged?
show ip ospf neighbor
show ip ospf interface
The Designated Router And Backup Designated Router
How DRs Flood Network Changes
What Are DROTHERS?
The DR/BDR Election
The OSPF RID Selection
Impact Of The DR Going Offline And Back Online
OSPF Network Types
Why Do Network Types Matter?
OSPF Broadcast Network
OSPF NBMA Network
OSPF Point-To-Point Network
OSPF Point-To-Multipoint Network
OSPF Virtual Link
show ip ospf virtual link

show ip protocols
Drawbacks Of Single-Area OSPF
Benefits Of Multi-Area OSPF
SPF Recalculations And show ip ospf
OSPF Path Cost Determination
OSPF - RIP Comparison
Troubleshooting OSPF Adjacencies
Link State Protocol Basics

You're familiar with link state protocol behaviors from your CCNA
studies, but we're going to review the important points here in just a
moment. Again, I want to mention that you must not breeze through
this information, thinking that since you already have your CCNA, you
already know all this material. 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 routers running a distance vector protocol such as RIP or IGRP
send routing updates, these updates contain the sender's routing
table. By running debug ip rip or debug ip igrp transactions, you can

actually see the routes contained in the update, along with the route
metrics.
Link state protocols don't work that way - they do not send routing
updates in the form that RIP and IGRP do. Link state routers that have
formed adjacencies exchange Link State Updates (LSUs), which contain
Link State Advertisements (LSAs). It's these LSAs that carry subnet
masking information and allow OSPF to support VLSM.
These LSAs are placed into a link state database. The Dijkstra algorithm
(also known as the Shortest Path First algorithm, or simply SPF ) is run
against the contents of this database to create the OSPF routing table.
Routers should have synchronized link state databases.
To see the contents of the database, run show ip ospf database. This
command shows the links and link types, sequence numbers, and how
long it's been since a particular LSA was received. This value is in
seconds and is seen under the "age" column.
The Dijkstra algorithm runs against the contents of the OSPF database...
R1#show ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)

Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum

1.1.1.1 1.1.1.1 1286 0x80000006 0x0057A7
8.8.8.8 8.8.8.8 795 0x8000000C 0x00085E
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum

10.1.1.5 8.8.8.8 795 0x80000006 0x001CC3
... calculates the routes, and these routes are placed into the OSPF routing table.
R1#show ip route ospf
6.0.0.0/32 is subnetted, 1 subnets
O 6.6.6.6 [110/11] via 10.1.1.5, 02:32:53, Ethernet0
O 7.7.7.7 [110/11] via 10.1.1.5, 02:32:53, Ethernet0
The SPF algorithm actually calculates a shortest path tree, and that tree
is used to create the routing table. We don't have to think much more
about the SPF algorithm since it does a great job without our
interference, but we have plenty of other details to attend to!
LSA Sequence Numbers

To ensure that OSPF routers receive the most recent information, these
LSAs are assigned sequence numbers. When an OSPF-enabled router
receives an LSA, that router checks its OSPF database to see if there is
already an entry for that link.
If there is, 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
sends an LSU containing that LSA back to the original sender. In this
situation, the router with the more-recent information is telling the
original sender, "The information you're sending is outdated. Here's
what you should be sending."
If the sequence number is higher, the router will add that LSA to its
database and send an LSAcknowledgment. The router will then flood
that LSA and will run the SPF algorithm in order to update its own
routing table.
When Are LSAs Exchanged?

Distance vector protocols send updates at a regularly scheduled interval,
regardless of whether there has actually been a change in the network
topology. In a stable network, this is a waste of network resources.
Once the initial exchange of LSAs takes place between two OSPF
neighbors, there will not be another exchange until there is a change in
the network topology. A router will also advertise all its LSAs every 30
minutes.
Before this LSA exchange begins, routers must become neighbors by
forming an adjacency. To form an adjacency, routers must agree on the
area number, the hello and dead timer settings, and whether the area is
a stub area. If link authentication has been configured, it must be
configured on both sides of the link.
The OSPF process number itself is locally significant and does not affect
the adjacency process.
To check your router's adjacencies, run show ip ospf neighbor or the

less-common show ip ospf interface. That last command tends to be
forgotten, but there's a lot of great information there.
R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 1 FULL/DR 00:01:52 172.12.123.1 Serial0
1.1.1.1 1 FULL/ - 00:00:32 172.12.13.1 Serial1
4.4.4.4 1 FULL/DR 00:00:32 172.23.23.4 Ethernet0
R3#show ip ospf interface serial0

Serial0 is up, line protocol is up
Internet Address 172.12.123.3/24, Area 0
Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DROTHER, Priority 0
Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1
No backup designated router on this network
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
Hello due in 00:00:16
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 3
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 1.1.1.1 (Designated Router)
Suppress hello for 0 neighbor(s)
show ip ospf interface gives you the local router's OSPF RID, its role on
that segment (DR, BDR, DROther), the RID of the DR and BDR for that
segment, how many adjacencies the local router has formed on that
segment, and a lot more. It's an excellent starting point for OSPF
troubleshooting.
The Role Of The DR and BDR

A major drawback of distance vector protocols is the slow convergence
rate. The term convergence refers to a network state where every
router has a similar and accurate view of the network, particularly after a
topology change such as a downed route. Distance vector protocols
don't converge quickly at all, which can lead to suboptimal routing and
routing loops.
Link state protocols converge almost immediately upon a topology

change. OSPF uses designated routers and backup designated routers to
make network convergence a fast and orderly process.
How DRs Flood Network Changes

When a router on an OSPF segment with a DR and BDR detects a change
in the network, that router will not notify all of its 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. It's
important to note that only the DR and BDR will receive this particular
multicast, even though the term used for the sending of this change
notification is flooding. This "flood" only goes to the DR and BDR.

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.
The DR/BDR Election Process
Almost every OSPF network segment is going to contain a DR and BDR.
As always, there are exceptions, and we'll take a detailed look at those
situations later in this section. For now, let's take a close look at the
rules regarding DR and BDR selection.
Consider the following network diagram. (I could have put a switch in
the middle of this particular diagram rather than a segment labeled
"ethernet"; be prepared to see either in network documentation.)
There are four routers on this Ethernet segment. One will become the
DR, one will become the BDR, and the others will be DROthers. Before
we look at how Cisco routers decide which routers will fill these roles,
let's take an overview of the OSPF DR/BDR election process.
1. All routers with an OSPF priority of 1 or higher are eligible for the
election. This priority is set at the interface level and is 1 by default.
Setting the interface priority to 0 will eliminate that router from the
election. This is done with the interface-level command ip ospf priority
0.
2. The router with the highest priority is elected DR .
3. If there is a tie, the OSPF Router ID (RID) value will be the
tiebreaker. The router with the highest RID wins.
4. This process is repeated to elect a new BDR. A single router cannot
be the DR and BDR for the same segment.
There will be some interesting behavior concerning DROthers on an
ethernet segment, which we'll discuss later in this section. For now, the
focus will remain on the DR / BDR election process with an examination

of the OSPF RID.
The OSPF RID Selection Process
Obviously, the OSPF RID plays a huge part in the selection of the DR and
BDR - but how is the RID value determined? By this set of rules:
1. 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 OSPF-enabled.A loopback interface that is the OSPF RID is

*NOT* automatically advertised by OSPF.
2. 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 OSPF-enabled.
3. These rules are both be overridden by setting the OSPF RID manually
with the router-id command, but the router must be reloaded or the
OSPF processes cleared before the command will take effect.
It seems a little strange that a router can have a loopback address that
isn't being advertised by OSPF actually serve as the RID, doesn't it?
Let's see this in action. R1 and R5 have formed an OSPF adjacency over
an Ethernet segment on network 10.1.1.0 /24. R5 has multiple
loopbacks, and is only advertising two of them via OSPF:
hostname R5
!
interface Loopback6
ip address 6.6.6.6 255.255.255.255
!
interface Loopback7
ip address 7.7.7.7 255.255.255.255
!
interface Loopback8
ip address 8.8.8.8 255.255.255.255
!
interface Ethernet0
ip address 10.1.1.5 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 7.7.7.7 0.0.0.0 area 0
network 10.1.1.0 0.0.0.255 area 0
Knowing what you know about OSPF RIDs, what will R1 show as the RID
for R5? Take a moment to look at the above configuration and figure
that out.
If you said 8.8.8.8, you're right. To see the OSPF RID of a neighbor, run
show ip ospf neighbor:
8.8.8.8 1 FULL/DR 00:00:37 10.1.1.5 Ethernet0
The value shown under Neighbor ID is that neighbor's RID.
To illustrate another important point regarding DRs and BDRs, let's go

back to our four-router example. The routers have the following
addresses:
RouterA: Loopback 1.1.1.1, ethernet0 172.1.1.1
RouterB: Loopback 2.2.2.2, ethernet0 172.1.1.2
RouterC: No loopback, ethernet0 172.1.1.3
RouterD: No loopback, ethernet0 172.1.1.4
The RIDs would be as follows:

RouterA: 1.1.1.1
RouterB: 2.2.2.2
RouterC: 172.1.1.3
RouterD: 172.1.1.4
The RID process will always prefer a loopback interface IP address over a
physical interface's IP address.
Summing all of this up, we've got 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 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 four-
way router election for DR and BDR, we would expect to see RouterD
become the DR and RouterC become the BDR. But what happens if
RouterD goes down and then comes back up?
In RouterD's absence, RouterC becomes the DR. RouterB would then
become the BDR. And when RouterD comes back up, those routers keep
their roles. This isn't like Spanning-Tree Protocol (STP), where a new
switch with a lower BID would become the root bridge. With OSPF, a
DR/BDR election is not held when a new router comes online or when a
router that was previously a DR or BDR comes back online.
Let's take an example where three routers are on an Ethernet segment.

Router A has a priority of 100, Router B a priority of 50, and R3 a priority
of 10. Router A has been elected DR and Router B the BDR.
All is well until Router A goes down. Router B will then become the DR,
and Router C will be elected BDR.
Router A coming back on line is not a reason for a DR/BDR election to be

held, even though Router A's priority is higher than the DR and the
BDR. When Router A comes back up, it will be a DROther.
For Router A to become the DR again, both the current DR and BDR
have to go down! What will happen when Router B goes down?
Router C is promoted to DR and Router A is elected BDR. When Router

B comes back up, it will become a DROther.
For Router A to finally become the DR again, now Router C will have to
go down. Router A will then be promoted from BDR to DR, and Router B
will become the BDR.
When Router C comes back up, it will be a DROther, and the network is
finally the way it was before!
The OSPF Network Types

Why OSPF Network Types Matter
The default OSPF network type depends on the topology of the network
segment. Different OSPF network types have different default hello and
dead timers, and that's one of the factors that must match between two
routers for an adjacency to form. In addition, some of these networks
do not have DRs and BDRs, and others that do have special
considerations that must be observed.
We'll now build an OSPF network, step by step, to illustrate each of the
OSPF network types you'll need to know for the BSCI exam. Unless
otherwise noted, each segment is being placed into Area 0 - the
backbone area.
The broadcast network's subnet is 10.1.1.0 /24. The final octet of every
IP address will be that router's number. Every router has a loopback

interface with its router number as each octet. (R1's loopback is
1.1.1.1 /32, and so forth.)
The OSPF Broadcast Network
An OSPF configuration on an Ethernet segment will default to an OSPF
broadcast network, and a DR and BDR will be elected. If we wanted one
particular router to become the DR or BDR, we could use the ip ospf

priority command to rig the election.
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 timer will be four times
the hello timer.
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
Backup Designated router (ID) 1.1.1.1, Interface address 10.1.1.1
Next 0x0(0)/0x0(0)
It's not required to have a certain router become the DR or BDR on a
broadcast segment, but that's not true of our next network segment.
The OSPF NBMA Network

We'll now add another network segment to the existing adjacency, this
one running over a frame relay cloud. The new segment will use the
network number 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.
Before configuring any OSPF configuration over frame relay, make sure
your frame map statements have the broadcast option enabled!

Otherwise, OSPF packets will not be sent across the frame.
R1(config-if)#frame map ip 172.12.123.2 122 broadcast

R1(config-if)#frame map ip 172.12.123.3 123 broadcast
R1#show frame map

Serial0 (up): ip 172.12.123.2 dlci 122(0x7A,0x1CA0), static,
broadcast,
CISCO, status defined, active
Serial0 (up): ip 172.12.123.3 dlci 123(0x7B,0x1CB0), static,
broadcast,
CISCO, status defined, active
It's not enough to make sure R1 wins the DR election - we've got to
prevent the spoke routers R2 and R3 from having a chance to win! To
prevent R2 and R3 from participating in the DR/BDR election, change
the OSPF priority from its default of 1 to zero.
R2(config)#int s0
R2(config-if)#ip ospf priority 0
R3(config)#int s0
R3(config-if)#ip ospf priority 0
The router with the highest priority set on an OSPF-enabled interface will
become the DR. If there is a tie, the router with the highest OSPF
Router ID (RID) wins the election. Basically, we're rigging the DR
election so there's no chance the spokes can possibly win, even if the
hub disappears! Setting the spoke priorities to zero prevents one of the
spokes from becoming the DR in case the hub router reloads.
The "NB" in NBMA stands for non-broadcast, so the hub router must be
configured with manual neighbor statements, as shown below. No
neighbor statements are needed on the spokes.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#network 172.12.123.0 0.0.0.255 area 0
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3

Transmit Delay is 1 sec, State DR, Priority 1
No backup designated router on this network
Next 0x0(0)/0x0(0)
Adjacent with neighbor 3.3.3.3
You can have NBMA networks 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.
Note the default hello and dead timers for an NBMA network - 30 and
120 seconds, respectively. The dead timer is again four times the hello
timer by default.
Serial interfaces default to NBMA, but you can also change an interface's
OSPF network type to NBMA with the ip ospf network command.

R1(config-if)#ip ospf network ?
broadcast Specify OSPF broadcast multi-access network
non-broadcast Specify OSPF NBMA network
point-to-multipoint Specify OSPF point-to-multipoint network
point-to-point Specify OSPF point-to-point network
The OSPF Point-To-Point And Point-To-Multipoint Network Types
We'll now add a direct connection between R1 and R3, but put it into
Area 13. The network number is 172.12.13.0 /24. Both routers are
placing their interface Serial1 into Area 13.

All non-0 areas must contain a router that does have 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 that this OSPF segment defaulted to
the OSPF network type point-to-point. This output also shows the
default hello and dead timers for this network type - 10 and 40 seconds,
respectively.

Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Next 0x0(0)/0x0(0)
Note that no DR or BDR is listed. On a point-to-point link such as this,
there are only two routers on the link. Therefore, there's no reason to
even have a DR or BDR, and none will be elected.
show ip ospf neighbor displays a dash where the role of the neighbor
would usually be seen. The entire DR/BDR election process is bypassed

with point-to-point and point-to-multipoint networks. No neighbor
statements are necessary with these network types. Below, R3 sees R1
as the DR on the NBMA segment while not seeing R1 in any role on the
point-to-point network.

1.1.1.1 1 FULL/DR 00:01:46 172.12.123.1 Serial0
1.1.1.1 1 FULL/ - 00:00:35 172.12.13.1 Serial1
This indicates that the remote neighbor is neither a DR, BDR, or
DROther, which means there was no DR/BDR election in the first place.
You would see the same situation on a point-to-multipoint OSPF

network, which OSPF considers to be a collection of point-to-point links.
For example, we could go back and configure the frame relay OSPF
network as a point-to-multipoint network by running the ip ospf network

point-to-multipoint command on R1's serial interface. There would be no
DR or BDR elected, and no neighbor statements would be necessary.
The OSPF network type point-to-multipoint now offers both a broadcast
and nonbroadcast option. We'll now configure the frame relay network
as point-to-point broadcast and then point-to-point nonbroadcast.
Point-to-point Broadcast Network Configuration
This network type doesn't require use of the neighbor statement, but
you can use it to define a cost for a given neighbor.
R1(config-if)#ip ospf network point-to-multipoint ?

non-broadcast Specify non-broadcast point-to-mpoint network
<cr>
Note that there is no option for "broadcast" here; that's because
broadcast is the default for point-to-multipoint.
R1(config-if)#router ospf 1
R1(config-router)#neighbor 172.12.123.2 ?
cost OSPF cost for point-to-multipoint neighbor
database-filter Filter OSPF LSA during synchronization and flooding for
point-to-multipoint neighbor
poll-interval OSPF dead-router polling interval
priority OSPF priority of non-broadcast 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-point Nonbroadcast Network Configuration
On the other hand, use of the point-to-point 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

Running OSPF Broadcast Networks Over NBMA Topologies:
Just Because You Can Do Something Doesn't Mean You Should!
We could have used the ip ospf network broadcast command on all the
routers connected to the frame network, and as long as there's a full
mesh, technically the network should work and the routers would act as
though they were actually communicating through a LAN. In the real
world, using the OSPF broadcast network type on an NBMA topology can
lead to unpredictable results, and I personally wouldn't do it. Why spend
your time troubleshooting when you can just stick with the default?
"RFC-Compliant" vs. Non-Compliant NBMA Network Types

Two OSPF network types, nonbroadcast multiaccess and point-to-
multipoint, are officially RFC compliant for use over an NBMA topology.
(The exact RFC is 2328.) The OSPF network types broadcast, point-to-
point, and point-to-multipoint nonbroadcast aren't officially compliant,
but can be configured over an NBMA topology.
The OSPF Virtual Link

The OSPF network running over the frame cloud has been restored to
the default NBMA and it will remain that type for the remainder of this
section.
We'll now add R4 to the network. R4 and R3 will have an adjacency
through Area 34, and R4 will have its loopback placed into Area 4. The
network segment between R3 and R4 is 172.12.34.0 /24 and runs over
an ethernet segment.
This configuration will result in incomplete routing tables, and that brings
us to our final OSPF network type. There is no problem with Area 34,
since one router with an interface in that area also has a physical
interface in Area 0 (R3).
However, no router with an interface in Area 4 has a physical interface in
Area 0. This means a logical connection to Area 0, a virtual link, must

be built.
Since R3 has a physical interface in Area 0, building a virtual link

between R3 and R4 will allow full IP connectivity throughout the
network. One problem with the current topology is that R1 has no route
for R4's loopback, even though that interface has been placed into the
OSPF configuration.
R4: router ospf 1
network 4.4.4.4 0.0.0.0 area 4
network 172.23.23.0 0.0.0.31 area 34

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
you're rusty on those, don't worry - there's a lot of information on these
areas coming later in the course!)
Here's the command to create a virtual link:

R4(config-router)#area 34 virtual-link 3.3.3.3
A virtual link must be configured on both ends of the transit area. We'll
go over to R3 now and finish the config.
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
R3(config-router)#^Z
2d07h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from LOADING to
FULL, Loading Done
A few details worth noting...
The virtual link command uses the remote device's OSPF RID, not
necessarily the IP address on the interface that's in the transit area.
Watch that - it's a very common error.
Also, don't worry about that error message you see in the output from
R3. That's normal and you'll see it on R3 until you finish building the
virtual link. If you see it after you've completed the virtual link, you do
have a problem.
Always confirm the virtual link with show ip ospf virtual-link. If you've
configured it correctly, the VL should come up in a matter of seconds.
R3#show ip ospf virtual-link
Virtual Link OSPF_VL0 to router 4.4.4.4 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 34, via interface Ethernet0, Cost of using 10
Transmit Delay is 1 sec, State POINT_TO_POINT,
Adjacency State FULL (Hello suppressed)
Index 2/4, retransmission queue length 1, number of retransmission 1
First 0x2C8F8E(15)/0x0(0) Next 0x2C8F8E(15)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Link State retransmission due in 3044 msec
Virtual links are actually simple to configure, but for some reason they
seem to intimidate people. It's my experience that the error message
highlighted in R3's output above causes a lot of panic, but the only thing
that message means is that you're not finished configuring the virtual
link yet.
There are three main misconfigurations that cause 99% of virtual link
configuration issues:
Using the wrong OSPF RID value
Trying to use a stub area as the transit area
Failure to configure authentication on the virtual link when

Area 0 is using authentication
I put that third cause in bold for a good reason. That last one is the one
that gets forgotten! A virtual link is really an extension of Area 0, and if
Area 0 is running authentication, the virtual link must be configured for it
as well.
We've looked at a lot of OSPF-centric commands in this section, but
don't forget our old friend show ip protocols. Regardless of the network
type, that command will show you the networks being routed, link
authentication information, and a lot more.
R3#show ip protocols
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 3.3.3.3
It is an area border router
Number of areas in this router is 3. 3 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.12.13.0 0.0.0.31 area 13
172.12.123.0 0.0.0.255 area 0
172.23.23.0 0.0.0.31 area 34
Routing Information Sources:
Gateway Distance Last Update
4.4.4.4 110 00:28:41
8.8.8.8 110 00:28:41
1.1.1.1 110 00:28:41
3.3.3.3 110 00:35:30
Distance: (default is 110)
Why Not Just Use One Big Area 0 ?
After you hear about the importance of Area 0 for the 10,000th time,
you might start thinking, "Why not just put all the routers into one big
Area 0? That way, you wouldn't have to worry about design issues, and
virtual links, or anything! After all, RIP and IGRP don't use areas."
That's true, and it's also one reason you don't see RIP and IGRP in use
on many WANs. The use of OSPF areas allows the creation of a
hierarchical design.
Now that sounds great, and Cisco exams love the word "hierarchical"....
but what does it mean? Here's the definition of "hierarchical":
adj : classified according to various criteria into successive levels or

layers
The Benefits Of Multi-Area OSPF
That's what OSPF areas allow you to do - build a layered network. This
does help reduce the wear on router resources such as CPU and
memory. As you'll see in the next section, there are situations where a
router doesn't need a huge routing table. An unnecessarily large routing
table can be quite a drain on router resources. And if there's only one
way for packets to get from a router to multiple destinations, why have a
full routing table when a default route will do?
A single-area OSPF deployment has other drawbacks. Logically dividing

an OSPF network into areas helps in limiting 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.
Speaking of SPF recalculations, you can see how many times this
algorithm has run with the show ip ospf command. If you continually
see this number rising, there is an unstable segment in that OSPF area.
(There is a lot of output with this command, and it's worth knowing.)
R3#show ip ospf
Routing Process "ospf 1" with ID 3.3.3.3
Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border router
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 3. 3 normal 0 stub 0 nssa
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm executed 10 times
Area ranges are
Number of LSA 12. Checksum Sum 0x06DBEB
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 3
Flood list length 0
Area 13
Area ranges are
Number of LSA 14. Checksum Sum 0x0822C6
Flood list length 0
Area 34
Area ranges are
Number of LSA 15. Checksum Sum 0x06BDFB
Flood list length 0
We'll take an in-depth look at multi-area OSPF in the next section.
OSPF Path Cost Determination
When you look at an OSPF routing table, you'll see two numbers
contained in brackets. The first is the administrative distance of OSPF,

which is 110. The second number is the metric used by OSPF, the cost
of the path.

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 port's speed. The default formula OSPF uses to calculate
the interface cost is:
100,000,000 / Bandwidth in BPS (NOT KBPS!)
You'll see some documentation that lists the first part of that formula as
10 to the 8th power, but I feel it's easier to remember 100,000,000 (one
hundred million). If you have reason to perform this calculation
manually, remember that the expression for bandwidth here is bits per
second (bps), not thousands of bits per second (kbps).
Here are some default OSPF interface costs for common interface
speeds:
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 IGRP and 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
R1(config)#interface serial0
R1(config-if)#bandwidth 512

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
R2(config-router)#auto-cost reference-bandwidth ?
<1-4294967> The reference bandwidth in terms of Mbits per second
I can't stress this enough - whenever you're running a command that

involves a value, take just a few seconds to use IOS Help and take note
of what the format of the value is. There are Cisco commands that will
ask you to enter bandwidth in BPS, KBPS, and MBPS. Be careful !
Comparing OSPF To RIP
OSPF is generally considered superior to RIP. Here are just a few of the
reasons.
OSPF's metric is a better measurement of the actual distance to a
remote network.
OSPF uses a composite metric, cost, where RIP uses the sole metric
of hop count.
OSPF does not impose a limit on when networks are "reachable" or

"unreachable", where RIP has a maximum hop count of 15 to
combat the counting to infinity issue.
OSPF supports VLSM, where RIPv1 does not. RIPv2 does, though.
VLSM support allows a protocol to have more efficient utilization of
IP addresses than a protocol that does not.
OSPF utilizes network bandwidth much more efficiently than RIP.
OSPF multicasts updates only upon initial adjacency, a network

change, or expiration of a 30-minute period where there have been
no network changes. RIPv1 broadcasts full routing tables every 30
seconds. RIPv2 does use multicasting, but still sends full routing
tables every 30 seconds. (A single RIP update can contain a
maximum of only 25 routes, so a larger network would require
multiple update packets.)
OSPF converges much more quickly than either version of RIP.
OSPF allows you to create a hierarchical scheme by using multiple

areas. Neither version of RIP offers this capability.
The main drawback of OSPF, especially in comparison to RIP, is that

OSPF can be a lot harder on router resources. OSPF operations requires
more CPU and memory than RIP does.
Troubleshooting OSPF Adjacencies
You know from your CCNA studies that OSPF adjacencies go through the
following states: Down, Attempt, Init, 2-Way, Exstart, Exchange,

Loading, and Full. Here's a quick review of what's going on in each
state:
Down - No hellos received from that neighbor

Attempt - Unicast hello packets are being sent to the neighbor; you'll
only see this in OSPF NBMA networks, since they're configured with
neighbor commands.
Init - First Hello packet has been received from this neighbor.
2-Way - Each router has received a Hello packet containing its own RID,
meaning that bidirectional communication is in place. When a router
receives a Hello packet containing its own RID, that's the remote router's
way of saying "I received the Hello packet you sent me earlier."
Exstart - Following DR / BDR election, the exchange of link state

database information can begin. Router with the highest OSPF RID will
being 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 ospf neighbor and show ip ospf interface
commands to ensure your OSPF adjacencies reach the 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.

19.1.1.1 1 2WAY/DROTHER 00:00:38 100.1.1.5 Ethernet0
172.12.123.3 1 FULL/ - 00:00:35 13.13.13.3 Serial1
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
Backup Designated router (ID) 10.1.1.1, Interface address 100.1.1.1
Next 0x0(0)/0x0(0)
Show ip ospf interface is excellent for spotting issues related to hello and
dead timers. If you don't see the problem with the show command,
though, you can run debug ip ospf adj to see the adjacencies form - or
not form! Here is just part of the output from this command, and you
can see the different OSPF states the adjacency goes through on the way
to Full.
4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x5DD opt 0x42 flag 0x7
len 32
mtu 1500 state INIT
4d22h: OSPF: 2 Way Communication to 10.1.1.1 on Serial1, state 2WAY
4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1 seq 0x14EC opt 0x42 flag 0x7
len 32
4d22h: OSPF: First DBD and we are not SLAVE
4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x14EC opt 0x42 flag 0x2
len 9
2 mtu 1500 state EXSTART
4d22h: OSPF: NBR Negotiation Done. We are the MASTER
4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1 seq 0x14ED opt 0x42 flag 0x3
len 92
4d22h: OSPF: Database request to 10.1.1.1
4d22h: OSPF: sent LS REQ packet to 13.13.13.1, length 12
4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x14ED opt 0x42 flag 0x0
len 3
2 mtu 1500 state EXCHANGE
4d22h: OSPF: Send DBD to 10.1.1.1 on Serial1 seq 0x14EE opt 0x42 flag 0x1
len 32
4d22h: OSPF: Rcv DBD from 10.1.1.1 on Serial1 seq 0x14EE opt 0x42 flag 0x0
len 3
2 mtu 1500 state EXCHANGE
4d22h: OSPF: Exchange Done with 10.1.1.1 on Serial1
R22h: OSPF: Synchronized with 10.1.1.1 on Serial1, state FULL
4d22h: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.1 on Serial1 from LOADING to
FULL,
Loading Done
4d22h: OSPF: Build router LSA for area 0, router ID 172.12.123.3, seq
0x80000005
In short, for OSPF adjacencies to form, the following must be agreed

upon by the potential neighbors:
Hello and dead times

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.
Adjacency Behavior With Multiple OSPF Routers On A Broadcast

Segment
When you have more than two OSPF routers on a broadcast segment,
you'll get some interesting adjacency results. I get asked about this one
often, so I thought I'd include it here.

The election has already taken place, with Router1 as the DR, Router2 as
the BDR, and Router3 and Router4 as the DROTHERS. The OSPF
neighbor tables on Router1 and Router2 look like you would expect, but
the DROthers' tables look a little odd.
Router1#show ip ospf nei

4.4.4.4 1 FULL/DROTHER 00:00:33 30.1.1.4 Ethernet0
2.2.2.2 1 FULL/BDR 00:00:30 30.1.1.2 Ethernet0

1.1.1.1 1 FULL/DR 00:00:39 30.1.1.1 Ethernet0

4.4.4.4 1 2WAY/DROTHER 00:00:35 30.1.1.4 Ethernet0
2.2.2.2 1 FULL/BDR 00:00:32 30.1.1.2 Ethernet0
1.1.1.1 1 FULL/DR 00:00:39 30.1.1.1 Ethernet0
Neighbor ID Pri State Dead Time Address

Interface
2.2.2.2 1 FULL/BDR 00:00:29 30.1.1.2
Ethernet0
1.1.1.1 1 FULL/DR 00:00:37 30.1.1.1
Ethernet0
3.3.3.3 1 2WAY/DROTHER 00:00:30 30.1.1.3
Ethernet0
You'll hear about OSPF adjacencies "stuck in 2-way", and many people
think that's what is happening here, but it's not. The DROTHERS are
never going to finish forming that adjacency. We could come back
tomorrow and they would still be in 2-way!
This is a default behavior of OSPF that helps to cut down on the number
of LSAs being transmitted on a segment like this. The only routers that
will have an adjacency to all other routers on the segment are the DR
and BDR. The DROthers will only have full adjacencies with the DR and
BDR, never between DROthers.
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.
Copyright © 2007, The Bryant Advantage. All Rights Reserved.

Link State Protocols and Single Area OSPF - 6

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Link State Protocols and Single Area OSPF - 6

Загружено:

Авторское право:

Доступные форматы

The Bryant Advantage Ultimate BSCI Study Guide

Chris Bryant, CCIE #12933 - www.thebryantadvantage.com

Link State Protocols And Single-Area

Link State Protocol Basics

LSA Sequence Numbers

When Are LSAs Exchanged?

show ip ospf neighbor

show ip ospf interface

The Designated Router And Backup Designated Router

How DRs Flood Network Changes

What Are DROTHERS?

The DR/BDR Election

The OSPF RID Selection

Impact Of The DR Going Offline And Back Online

OSPF Network Types

Why Do Network Types Matter?

OSPF Broadcast Network

OSPF NBMA Network

OSPF Point-To-Point Network

OSPF Point-To-Multipoint Network

OSPF Virtual Link

show ip ospf virtual link

Drawbacks Of Single-Area OSPF

Benefits Of Multi-Area OSPF

SPF Recalculations And show ip ospf

OSPF Path Cost Determination

OSPF - RIP Comparison

Troubleshooting OSPF Adjacencies

Link State Protocol Basics

the fundamentals of OSPF.

When routers running a distance vector protocol such as RIP or IGRP

send routing updates, these updates contain the sender's routing

table. By running debug ip rip or debug ip igrp transactions, you can

OSPF Router with ID (1.1.1.1) (Process ID 1)

Link ID ADV Router Age Seq# Checksum

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

interference, but we have plenty of other details to attend to!

LSA Sequence Numbers

If the sequence number is the same, the LSA is ignored and no

When Are LSAs Exchanged?

forming an adjacency. To form an adjacency, routers must agree on the

a stub area. If link authentication has been configured, it must be

configured on both sides of the link.

the adjacency process.

To check your router's adjacencies, run show ip ospf neighbor or the

forgotten, but there's a lot of great information there.

R3#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

R3#show ip ospf interface serial0

The Role Of The DR and BDR

Link state protocols converge almost immediately upon a topology

How DRs Flood Network Changes

the detecting router will send a multicast to 224.0.0.6, the address to

notification is flooding. This "flood" only goes to the DR and BDR.

The DR/BDR Election Process

Almost every OSPF network segment is going to contain a DR and BDR.

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

let's take an overview of the OSPF DR/BDR election process.

election. This priority is set at the interface level and is 1 by default.

election. This is done with the interface-level command ip ospf priority