Eeee Eeeee Eeeeeeeee Eee Eeeeee-Eeee Feef: Eeeeeeeeeee

The Bryant Advantage CCNP ROUTE Study Guide
Chris Bryant, CCIE #12933 - www.thebryantadvantage.com

xxxxxxxxxxxxxx

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

Link State Protocol Basics
You're familiar with link state protocol behaviors from your CCNA
studies, but we're going to review the important points here in just a
moment.
Avoid the temptation to skip the review.
While quite a bit of it will be familiar to you, there are many additional
details you must master at the CCNP level. Those of you with your eyes
on the CCIE will need to truly master the fundamentals of OSPF.
When RIP sends routing updates, these updates contain the full routing
table. By running debug ip rip, you can actually see the routes contained
in the update, along with the route metrics.
Link state protocols don't work that way. Link state routers that have
formed adjacencies exchange Link State Updates (LSUs), which contain
Link State Advertisements (LSAs). It's these LSAs that carry subnet
masking information and allow OSPF to support VLSM.
These LSAs are placed into a link state database. The Dijkstra algorithm
(also known as the Shortest Path First algorithm, or simply SPF) is run
against the contents of this database to create the OSPF routing table.
Routers should have synchronized link state databases.
To see the contents of the database, run show ip ospf database. This
command shows the links and link types, sequence numbers, and how
long it's been since a particular LSA was received. This value is in
seconds and is seen under the "age" column.
The Dijkstra algorithm runs against the contents of the OSPF database...
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
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 no entry for that link, the receiving router will make one
*and* flood that LSA out every OSPF-enabled interface on the router
except the one it came in on.
If there is an entry, one of three situations exists. Either the incoming
LSA has a sequence number that is the same, lower, or higher than the
entry already in the database.
If the sequence number is the same, the LSA is ignored and no
additional action is taken.
If the sequence number is lower, the router will ignore the update
and will then transmit an LSU containing that LSA back to the
original sender. In this situation, the router with the more-recent
information is telling the original sender, "The information you're
sending is outdated. Here's what you should be sending."
If the sequence number is higher, the router will add that LSA to its
database and send an LSAcknowledgment. The router will then
flood that LSA and will run the SPF algorithm in order to update its
own routing table.
When Are LSAs Exchanged?
Distance vector protocols send updates at a regularly scheduled interval,
regardless of whether there has actually been a change in the network
topology. In a stable network, this is a waste of network resources.
Once the initial exchange of LSAs takes place between two OSPF
neighbors, there will not be another exchange until there is a change in
the network topology.
An OSPF-speaking router will also send out a summary LSA every 30
minutes.
Before this LSA exchange begins, routers must become neighbors by
forming an adjacency. To form an adjacency, routers must agree on the
area number, the hello and dead timer settings, and whether the area is
a stub area. If link authentication has been configured, it must be
configured on both sides of the link.
The OSPF process number itself is locally significant and does not affect
the adjacency process.
To check your router's adjacencies, run show ip ospf neighbor or the
less-common show ip ospf interface. That last command tends to be
forgotten, but there's a lot of great information there.
Note that both of these commands tell you what neighbor relationships
currently exist, and only show ip ospf neighbor shows you the status of
the database loading (FULL, 2WAY, etc)
R3#show ip ospf neighbor
Neighbor D Pri State Dead Time Address nterface
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 protocol is slow convergence.
Convergence refers to a network state where every router has a similar
and accurate view of the network, particularly after a topology change
such as a downed route. Distance vector protocols don't converge
quickly at all, which can lead to suboptimal routing and routing loops.
Link state protocols converge almost immediately upon a topology
change. OSPF uses designated routers and backup designated routers to
make network convergence a fast and orderly process.
How DRs 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 neighbors. Instead, the
detecting router will send a multicast to 224.0.0.6, the address to which
both the DR and BDR listen to learn about such changes.
The DR will then send a multicast to 224.0.0.5 to notify all non-DR and
non-BDR routers of the change. (Routers that are neither the DR or BDR
for a network segment are called DROthers, as shown in the output of
the command show ip ospf neighbor.) The DROthers will send an
LSAcknowledgment, or LSAck, back to the DR to indicate receipt of the
update.
Two notes here:
Only the DR and BDR listen to 224.0.0.6.
Only the DR will actually send the multicast to 224.0.0.5 to notify
the DROTHERS of the network change. The BDR receives the
original change notification, but does not notify other routers of that
change. Listening to 224.0.0.6 allows the BDR to have the most
recent database entries possible - and that's important in case it
has to quickly become the DR.
The DR/BDR Election Process
Almost every OSPF network segment is going to contain a DR and BDR.
As always, there are exceptions, and we'll take a detailed look at those
situations later in this section. For now, let's take a close look at the
rules regarding DR and BDR selection.
Consider the following network diagram. (I could have put a switch in
the middle of this particular diagram rather than a segment labeled
"ethernet"; be prepared to see either in network documentation.)

Four routers have interfaces on the Ethernet segment. One will become
the DR, one will become the BDR, and the others will be DROthers.
Before we look at how Cisco routers decide which routers will fill these
roles, let's take an overview of the OSPF DR/BDR election process.
1. All routers with an OSPF interface priority of 1 or higher are eligible
for the election. (That priority of 1 is the default.) Setting the interface
priority to 0 will eliminate that router from the election on that segment.
2. The router with highest priority is elected DR.
3. If there is a tie, the OSPF Router ID (RID) value will be the
tiebreaker. The router with the highest RID wins.
4. This process is repeated to elect a new BDR. A single router cannot
be the DR and BDR for the same segment.
There will be some interesting behavior concerning DROthers on an
ethernet segment, which we'll discuss later in this section. For now, the
focus will remain on the DR / BDR election process with an examination
of the OSPF RID.
The OSPF RID Selection Process
Obviously, the OSPF RID plays a huge part in the selection of the DR and
BDR - but how is the RID value determined? By this set of rules:
The OSPF RID of a router will be the highest IP address assigned to
a loopback interface on that router, regardless of whether that
loopback interface is OSPF-enabled. 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 OSPF-enabled.
These rules can both be overridden by setting the OSPF RID
manually with the router-id command, but the router must be
reloaded or the OSPF processes cleared before the command will
take effect.
It seems a little strange that a router can have a loopback address that
isn't being advertised by OSPF actually serve as the RID, doesn't it?
Let's see this in action. R1 and R5 have formed an OSPF adjacency over
an Ethernet segment on network 10.1.1.0 /24. R5 has multiple
loopbacks, and is only advertising two of them via OSPF:
hostname R5
!
interface Loopback6
ip address 6.6.6.6 255.255.255.255
!
interface Loopback7
ip address 7.7.7.7 255.255.255.255
!
interface Loopback8
ip address 8.8.8.8 255.255.255.255
!
interface Ethernet0
ip address 10.1.1.5 255.255.255.0
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 7.7.7.7 0.0.0.0 area 0
network 10.1.1.0 0.0.0.255 area 0
Knowing what you know about OSPF RIDs, what will R1 show as the RID
for R5? Take a moment to look at the above configuration and figure
that out.
If you said 8.8.8.8, you're right. To see the OSPF RID of a neighbor, run
show ip ospf neighbor:
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 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 four-
way router election for DR and BDR, we would expect to see Router D
become the DR and Router C become the BDR. But what happens if
RouterD goes down and then comes back up?
In RouterD's absence, Router C becomes the DR. Router B would then
become the BDR. And when Router D comes back up, those routers
keep their roles.
This isn't like Spanning-Tree Protocol (STP), where a new switch with a
lower BID would become the root bridge. With OSPF, a DR/BDR election
is not held when a new router comes online or when a router that was
previously a DR or BDR comes back online.
Let's take an example where three routers are on an Ethernet segment.
Router A has a priority of 100, Router B a priority of 50, and R3 a
priority of 10. Router A has been elected DR and Router B the BDR.

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

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

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

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

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

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

The OSPF Network Types
Why OSPF Network Types Matter
The default OSPF network type depends on the network segment type.
Different OSPF network types have different default hello and dead
timers, and that's one of the factors that must match between two
routers for an adjacency to form. In addition, some of these networks
do not have DRs and BDRs, and others that do have special
considerations that must be observed.
Other than that, they're all the same, right? :)
No worries, we're going to build and cover each OSPF network type you
need to master to pass the CCNP ROUTE exam right now!
Unless otherwise noted, each segment is being placed into Area 0 - the
backbone area.
The broadcast network's subnet is 10.1.1.0 /24. The final octet of every
IP address will be that router's number. Every router has a loopback
interface with its router number as each octet. (R1's loopback is
1.1.1.1 /32, and so forth.)
The OSPF Broadcast Network

An OSPF configuration on an Ethernet segment will default to an OSPF
broadcast network, and a DR and BDR will be elected. If we wanted one
particular router to become the DR or BDR, we could use the ip ospf
priority command to rig the election.
On a large segment, it's a good idea to have your more powerful routers
fill these roles - being the DR or BDR for a segment or segments does
increase the load on the CPU. As always, everything we do on a Cisco
router has a cost.
The output of show ip ospf interface ethernet0 on R1 displays the
network type, as well as a great deal of other important information.
Note the default hello and dead timers for a broadcast segment - 10 and
40 seconds, respectively. By default, the dead time will be four times
the hello time.
R1# show ip ospf interface ethernet0
Ethernet0 is up, line protocol is up
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 a requirement to have a certain router become the DR or BDR on
a broadcast segment, but that's not true of our next network segment.
The OSPF NBMA Network
We'll now add another network segment to the existing adjacency, this
one running over a frame relay cloud. The new segment will use
172.12.123.0 /24. R1 has a frame relay PVC to both R2 and R3; there is
no PVC between the spokes. All routers have their Serial0 interface in
Area 0.

The serial interfaces in this new segment will default to the OSPF
network type non-broadcast multiaccess, or NBMA. Since there is no full
mesh through the frame cloud (no PVC between R2 and R3), the hub
router R1 has to be the DR and there can be no BDR.
Why? Because the DR or any potential BDR must be able to get a
multicast through to all other routers on that network. With a hub-and-
spoke topology, a spoke router will not be able to get a multicast or
broadcast to the other spoke, since all spoke-to-spoke traffic will go
through the hub - and routers do not forward broadcasts or multicasts!
Before configuring any OSPF configuration over frame relay, make sure
your frame map statements have the broadcast option enabled!
Otherwise, OSPF packets will not be sent across the frame.
R1(config-if)#frame map ip 172.12.123.2 122 broadcast
R1(config-if)#frame map ip 172.12.123.3 123 broadcast
R1#show frame map
Serial0 (up): ip 172.12.123.2 dlci 122(0x7A,0x1CA0), static,
broadcast,
CISCO, status defined, active
Serial0 (up): ip 172.12.123.3 dlci 123(0x7B,0x1CB0), static,
broadcast,
CISCO, status defined, active
It's not enough to make sure R1 wins the DR election - we've got to
prevent the spoke routers R2 and R3 from having a chance to win! To
prevent R2 and R3 from participating in the DR/BDR election, change
the OSPF priority from its default of 1 to zero.
R2(config)#int s0
R2(config-if)#ip ospf priority 0
R3(config)#int s0
R3(config-if)#ip ospf priority 0
The router with the highest priority set on an OSPF-enabled interface will
become the DR. If there is a tie, the router with the highest OSPF
Router ID (RID) wins the election.
Basically, we're rigging the DR election so there's no chance the spokes
can possibly win, even if the hub disappears! Setting the spoke priorities
to zero prevents one of the spokes from becoming the DR in case the
hub router reloads.
The "NB" in NBMA stands for non-broadcast, so the hub router must be
configured with manual neighbor statements, as shown below. No
neighbor statements are needed on the spokes.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#network 172.12.123.0 0.0.0.255 area 0
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3
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 an NBMA network where there is both a DR and BDR, but
they still both have to be hub routers. A network with two hubs could
have one as the DR and the other as the BDR. Every DR or BDR in an
NBMA network must have static neighbor statements; they are not
needed on the other routers. (If you have multiple hub routers, you can
have one of them become the BDR.)
Note the default hello and dead timers for an NBMA network - 30 and
120 seconds, respectively. The dead timer is again four times the hello
timer by default.
Serial interfaces default to NBMA, but you can also change an interface's
OSPF network type to NBMA with the ip ospf network command.
R1(config-if)#ip ospf network ?
broadcast Specify OSPF broadcast multi-access network
non-broadcast Specify OSPF NBMA network
point-to-multipoint Specify OSPF point-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 /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-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, 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
The dash next to FULL/ for that adjacency indicates the neighbor is
neither a DR, BDR, or DROther, which means there was no DR/BDR
election in the first place. You would see the same situation on a point-
to-multipoint OSPF network, which OSPF considers to be a collection of
point-to-point links.
For example, we could go back and configure the frame relay OSPF
network as a point-to-multipoint network by running the ip ospf network
point-to-multipoint command on R1's serial interface. There would be no
DR or BDR elected, and no neighbor statements would be necessary.
The OSPF network type point-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-Multipoint Broadcast Network Configuration
This network type doesn't require use of the neighbor statement, but
you can use it to define a cost for a given neighbor.
R1(config-if)#ip ospf network point-to-multipoint ?
non-broadcast Specify non-broadcast 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-Multipoint Nonbroadcast Network Configuration
On the other hand, use of the point-to-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

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 segment can lead to unpredictable results, and I personally
wouldn't do it. Why spend your time troubleshooting when you can just
stick with the default?

The OSPF Virtual Link
The OSPF network running over the frame cloud has been restored to
the default NBMA and it will remain that type for the remainder of this
section.
We'll now add R4 to the network. R4 and R3 will have an adjacency
through Area 34, and R4 will have its loopback placed into Area 4. The
network segment between R3 and R4 is 172.12.34.0 /24 and runs over
an ethernet segment.

This configuration will result in incomplete routing tables, and that brings
us to our final OSPF network type. There is no problem with Area 34,
since one router with an interface in that area also has a physical
interface in Area 0 (R3).
However, no router with an interface in Area 4 has a physical interface in
Area 0. This means a logical connection to Area 0, a virtual link, must
be built.
Since R3 has a physical interface in Area 0, building a virtual link
between R3 and R4 will allow full IP connectivity throughout the
network. One problem with the current topology is that R1 has no route
for R4's loopback, even though that interface has been placed into the
OSPF configuration.
R4: router ospf 1
network 4.4.4.4 0.0.0.0 area 4
network 172.23.23.0 0.0.0.31 area 34
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. Check that RID!
Also, don't worry about that error message you see in the output
from R3. That's normal and you'll see it on R3 until you finish
building the virtual link. If you see it after you've completed the
virtual link, you do have a problem.
Always confirm the virtual link with show ip ospf virtual-link. If you've
configured it correctly, the VL should come up in a matter of seconds.
R3#show ip ospf virtual-link
Virtual Link OSPF_VL0 to router 4.4.4.4 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 34, via interface Ethernet0, Cost of using 10
Transmit Delay is 1 sec, State POINT_TO_POINT,
Adjacency State FULL (Hello suppressed)
Index 2/4, retransmission queue length 1, number of retransmission 1
First 0x2C8F8E(15)/0x0(0) Next 0x2C8F8E(15)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Link State retransmission due in 3044 msec
Virtual links are actually simple to configure, but for some reason they
seem to intimidate people. It's my experience that the error message
highlighted in R3's output causes a lot of panic, but the only thing that
message means is that you're not finished configuring the virtual link
yet.
Knowledge destroys fear and panic.
There are three main misconfigurations that cause 99% of virtual link
configuration issues:
Using the wrong OSPF RID value
Trying to use a stub area as the transit area
Failure to configure authentication on the virtual link when
Area 0 is using authentication
I put that third cause in bold for a good reason. That last one is the one
that gets forgotten! A virtual link is really an extension of Area 0, and if
Area 0 is running authentication, the virtual link must be configured for it
as well.
We've looked at a lot of 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 much more. This is a great command to
start with when you're t-shooting any routing protocol.
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,
virtual links, or anything! After all, RIP doesn't use areas."
That's true, and it's also one reason you don't see RIP in use on many
WANs. The use of OSPF areas allows the creation of a hierarchy.
Now that sounds great, and Cisco exams love the word "hierarchical"....
but what does it mean? Here's the definition of "hierarchical":
adj : classified according to various criteria into successive levels or
layers
The Benefits 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. Thanks to this layered approach, sometimes a router doesn't
need a huge routing table.
An unnecessarily large routing table can be quite a drain on router
resources -- and if there's only one way for packets to get from a router
to multiple destinations, why have a full routing table when a default
route will do?
A single-area OSPF deployment has other drawbacks. Logically dividing
an OSPF network into areas helps in limiting LSU and LSA traffic, since
notification of changes in a multi-area OSPF network can be limited to
that area only. This limiting of LSAs helps to limit route table
recalculations by the Dijkstra algorithm as well.
Summing up, OSPF areas bring us these benefits:
More efficient routing via "complete yet concise" routing tables
Fewer overall SPF recalculations
Less LSU / LSA traffic and associated overhead
Speaking of SPF recalculations, you can see how many times this
algorithm has run with the show ip ospf command. If you continually
see this number rising, there is an unstable segment in that OSPF area.
(There is a lot of output with this command, and it's worth knowing.)
R3#show ip ospf
Routing Process "ospf 1" with ID 3.3.3.3
Supports only single TOS(TOS0) routes
Supports opaque LSA
It is an area border router
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 3. 3 normal 0 stub 0 nssa
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm executed 10 times
Area ranges are
Number of LSA 12. Checksum Sum 0x06DBEB
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 3
Flood list length 0
Area 13
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:
l 56 kbps = 1785
l T1 line = 64
l Ethernet = 10
l 16 MBPS Token Ring = 6
l 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
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
One very good reason can be the addition of Fast and GigEthernet
interfaces to your network. Since those interfaces weren't even around
when the costs we spoke of earlier were developed, you may (very)
occasionally need to adjust this reference bandwidth - especially with
GigEthernet interfaces.
Comparing OSPF To RIP
OSPF is generally considered superior to RIP. Here are just a few of the
reasons.
l OSPF's metric is a better measurement of the actual distance to a
remote network.
l OSPF uses a composite metric, cost, where RIP uses the sole metric
of hop count.
l 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.
l 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.
l OSPF utilizes network bandwidth much more efficiently than RIP.
l 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.)
l OSPF converges much more quickly than either version of RIP.
l 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. 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 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, 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:
l Hello and dead timers
l The Area ID
l Stub area flag setting (on or off)
l Link authentication password (use is optional, but if used, both
neighbors must agree on the password)
The process number does not have to be agreed upon - that value
is locally significant only. (Yeah, I know I said that before. I'm saying it
again. :) )
Adjacency Behavior With Multiple OSPF Routers On A Broadcast
Segment
When you have more than two OSPF routers on a broadcast segment,
you'll get some interesting adjacency results. I get asked about this one
often in Facebook and Twitter (@ccie12933, by the way), so I thought
I'd include it here.

The election has already taken place, with R1 as the DR, R2 as the BDR,
and R3 and R4 as the DROTHERS. The OSPF neighbor tables on R1 and
2 look like you would expect, but the DROthers' tables look a little odd.
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 D Pri State Dead Time Address
nterface
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 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 we have the fundamentals of OSPF down cold...
... let's tackle multiarea OSPF!

Copyright 2011, The Bryant Advantage. All Rights Reserved.

Eeee Eeeee Eeeeeeeee Eee Eeeeee-Eeee Feef: Eeeeeeeeeee

Uploaded by

Document Information

Original Description:

Original Title

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

Eeee Eeeee Eeeeeeeee Eee Eeeeee-Eeee Feef: Eeeeeeeeeee

Uploaded by

Copyright:

Available Formats

The Bryant Advantage CCNP ROUTE Study Guide

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

You might also like