-
The Bryant Advantage CCNP ROUTE 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
-
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 RIP send 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 7.0.0.0/32 is subnetted, 1 subnets O 7.7.7.7 [110/11] via 10.1.1.5, 02:32:53, Ethernet0
The SPF algorithm actually calculates a shortest path tree, and that tree
is used to create the routing table. We don't have to think much more
about the SPF algorithm since it does a great job without our interference, but we have plenty of other details to attend to!
LSA Sequence Numbers
To ensure that OSPF routers receive the most recent information, these
LSAs are assigned sequence numbers. When an OSPF-enabled router
receives an LSA, that router checks its OSPF database to see if there is already an entry for that link.
If there is no entry for that link, the receiving router will make one *and* flood that LSA out every OSPF-enabled interface on the router
except the one it came in on.
If there is an entry, one of three situations exists. Either the incoming
LSA has a sequence number that is the same, lower, or higher than the
entry already in the database.
If the sequence number is the same, the LSA is ignored and no
additional action is taken.
If the sequence number is lower, the router will ignore the update and 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.
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 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 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 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.
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 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:
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:
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
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 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 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 CCNP ROUTE 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.
On a large segment, it's a good idea to have your more powerful routers fill these roles - being the DR or BDR for a segment or segments does
increase the load on the CPU. As always, everything we do on a Cisco
router has a cost.
The output of show ip ospf interface ethernet0 on R1 displays the
network type, as well as a great deal of other important information. Note the default hello and dead timers for a broadcast segment - 10 and
40 seconds, respectively. By default, the dead time will be four times
the hello time.
R1# show ip ospf interface ethernet0 Ethernet0 is up, line protocol is up Internet Address 10.1.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 8.8.8.8, Interface address 10.1.1.5 Backup Designated router (ID) 1.1.1.1, Interface address 10.1.1.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:04 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 8.8.8.8 (Designated Router) Suppress hello for 0 neighbor(s)
-
It's not a requirement to have a certain router become the DR or BDR on
a broadcast segment, but that's not true of our next network segment.
The OSPF NBMA Network
We'll now add another network segment to the existing adjacency, this one running over a frame relay cloud. The new segment will use 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.
Why? Because the DR or any potential BDR must be able to get a multicast through to other routers. In this network type, a spoke router
will not be able to get a multicast or broadcast to the other spoke, since
all spoke-to-spoke traffic will go through the hub - and routers do not forward broadcasts or multicasts!
Before configuring any OSPF configuration over frame relay, make sure your frame map statements have the broadcast option enabled!
-
Otherwise, OSPF packets will not be sent across the frame.
R1(config-if)#frame map ip 172.12.123.2 122 broadcast R1(config-if)#frame map ip 172.12.123.3 123 broadcast
R1#show frame map Serial0 (up): ip 172.12.123.2 dlci 122(0x7A,0x1CA0), static, broadcast, CISCO, status defined, active Serial0 (up): ip 172.12.123.3 dlci 123(0x7B,0x1CB0), static, broadcast, CISCO, status defined, active
It's not enough to make sure R1 wins the DR election - we've got to
prevent the spoke routers R2 and R3 from having a chance to win! To prevent R2 and R3 from participating in the DR/BDR election, change
the OSPF priority from its default of 1 to zero.
R2(config)#int s0 R2(config-if)#ip ospf priority 0
R3(config)#int s0 R3(config-if)#ip ospf priority 0
The router with the highest priority set on an OSPF-enabled interface will become the DR. If there is a tie, the router with the highest OSPF
Router ID (RID) wins the election.
Basically, we're rigging the DR election so there's no chance the spokes
can possibly win, even if the hub disappears! Setting the spoke priorities
to zero prevents one of the spokes from becoming the DR in case the hub router reloads.
The "NB" in NBMA stands for non-broadcast, so the hub router must be
configured with manual neighbor statements, as shown below. No
neighbor statements are needed on the spokes.
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router ospf 1 R1(config-router)#network 172.12.123.0 0.0.0.255 area 0 R1(config-router)#neighbor 172.12.123.2 R1(config-router)#neighbor 172.12.123.3
R1#show ip ospf interface serial0 Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1 No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:11 Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 4 msec, maximum is 4 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 3.3.3.3 Adjacent with neighbor 2.2.2.2 Suppress hello for 0 neighbor(s)
You can have an NBMA network where there is both a DR and BDR, but
they still both have to be hub routers. A network with two hubs could
-
have one as the DR and the other as the BDR. Every DR or BDR in an
NBMA network must have static neighbor statements; they are not
needed on the other routers.
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-Area 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.
R3#show ip ospf interface serial1 Serial1 is up, line protocol is up Internet Address 172.12.13.3/27, Area 13 Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:08 Index 1/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1.1 Suppress hello for 0 neighbor(s)
Note that no DR or BDR is listed. On a point-to-point link 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.
R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 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-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
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
R1(config-router)#neighbor 172.12.123.2 cost ? 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
R1(config-router)#neighbor 172.12.123.2 cost 15 R1(config-router)#neighbor 172.12.123.3 cost 25
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?
The OSPF Virtual Link
The OSPF network running over the frame cloud has been restored to
the default NBMA and it will remain that type for the remainder of this
section.
We'll now add R4 to the network. R4 and R3 will have an adjacency
through Area 34, and R4 will have its loopback placed into Area 4. The
-
network segment between R3 and R4 is 172.12.34.0 /24 and runs over an ethernet segment.
This configuration will result in incomplete routing tables, and that brings
us to our final OSPF network type. There is no problem with Area 34,
since one router with an interface in that area also has a physical interface in Area 0 (R3).
However, no router with an interface in Area 4 has a physical interface in Area 0. This means a logical connection to Area 0, a virtual link, must
be built.
Since R3 has a physical interface in Area 0, building a virtual link
between R3 and R4 will allow full IP connectivity throughout the
network. One problem with the current topology is that R1 has no route for R4's loopback, even though that interface has been placed into the
OSPF configuration.
-
R4: router ospf 1 network 4.4.4.4 0.0.0.0 area 4 network 172.23.23.0 0.0.0.31 area 34
R1#show ip route ospf 6.0.0.0/32 is subnetted, 1 subnets O 6.6.6.6 [110/11] via 10.1.1.5, 01:05:45, Ethernet0 172.23.0.0/27 is subnetted, 1 subnets O IA 172.23.23.0 [110/74] via 172.12.123.3, 00:04:14, Serial0 7.0.0.0/32 is subnetted, 1 subnets O 7.7.7.7 [110/11] via 10.1.1.5, 01:05:45, Ethernet0
The area through which the virtual link is built, the transit area, cannot be a stub area of any kind - stub, total stub, or not-so-stubby stub. (If
you're rusty on those, don't worry - there's a lot of information on these
areas coming later in the course!)
Here's the command to create a virtual link:
R4(config)#router ospf 1 R4(config-router)#area 34 virtual-link 3.3.3.3
A virtual link must be configured on both ends of the transit area. We'll
go over to R3 now and finish the config.
R3(config)#router ospf 1 2d07h: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 172.23.23.4, Ethernet0 R3(config)#router ospf 1 R3(config-router)#area 34 virtual-link 4.4.4.4 R3(config-router)#^Z 2d07h: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from LOADING to FULL, Loading Done
A few details worth noting...
The virtual link command uses the remote device's OSPF RID, not
necessarily the IP address on the interface that's in the transit
area. Watch that - it's a very common error. Check that RID!
Also, don't worry about that error message you see in the output
from R3. That's normal and you'll see it on R3 until you finish
building the virtual link. If you see it after you've completed the virtual link, you do have a problem.
Always confirm the virtual link with show ip ospf virtual-link. If you've
configured it correctly, the VL should come up in a matter of seconds.
R3#show ip ospf virtual-link Virtual Link OSPF_VL0 to router 4.4.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 34, via interface Ethernet0, Cost of using 10 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:00 Adjacency State FULL (Hello suppressed) Index 2/4, retransmission queue length 1, number of retransmission 1 First 0x2C8F8E(15)/0x0(0) Next 0x2C8F8E(15)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 0 msec Link State retransmission due in 3044 msec
-
Virtual links are actually simple to configure, but for some reason they seem to intimidate people. It's my experience that the error message
highlighted in R3's output above 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 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 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. 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 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 it up, OSPF areas bring us these benefits:
More efficient routing via "complete yet concise" routing tables
Fewer overall SPF recalculations
Less LSU / LSA traffic and associated overhead
Speaking of SPF recalculations, you can see how many times this
algorithm has run with the show ip ospf command. If you continually
see this number rising, there is an unstable segment in that OSPF area.
(There is a lot of output with this command, and it's worth knowing.)
R3#show ip ospf Routing Process "ospf 1" with ID 3.3.3.3 Supports only single TOS(TOS0) routes Supports opaque LSA It is an area border router SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 3. 3 normal 0 stub 0 nssa External flood list length 0 Area BACKBONE(0) Number of interfaces in this area is 2 Area has no authentication SPF algorithm executed 10 times Area ranges are Number of LSA 12. Checksum Sum 0x06DBEB Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 3 Flood list length 0 Area 13 Number of interfaces in this area is 1 Area has no authentication SPF algorithm executed 4 times
-
Area ranges are Number of LSA 14. Checksum Sum 0x0822C6 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Area 34 Number of interfaces in this area is 1 Area has no authentication SPF algorithm executed 6 times Area ranges are Number of LSA 15. Checksum Sum 0x06BDFB Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0
We'll take an in-depth look at 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.
R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O IA 1.1.1.1 [110/65] via 172.12.123.1, 2d03h, Serial0 33.0.0.0/32 is subnetted, 1 subnets O IA 33.33.33.33 [110/65] via 172.12.123.3, 2d02h, Serial0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/65] via 172.12.123.3, 2d03h, Serial0 15.0.0.0/24 is subnetted, 1 subnets
OSPF assigns a cost to every OSPF-enabled interface. The interface cost is based on the port's speed. The default formula OSPF uses to calculate
the interface cost is:
100,000,000 / Bandwidth in BPS (NOT KBPS!)
You'll see some documentation that lists the first part of that formula as
10 to the 8th power, but I feel it's easier to remember 100,000,000 (one
hundred million). If you have reason to perform this calculation manually, remember that the expression for bandwidth here is bits per
second (bps), not thousands of bits per second (kbps).
Here are some default OSPF interface costs 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 EIGRP a more accurate picture of the
-
bandwidth of a serial link. This command can also be used with OSPF.
For example, if serial1 on a router was running at 512 kbps rather than
the assumed serial link speed of 1544 kbps, the bandwidth command
can be used to give OSPF a truer picture of the link speed. OSPF will recalculate the path cost almost immediately after using this command.
The cost of an interface can be seen with the show ip ospf interface command. Note that this serial port is shown with an OSPF cost of 64,
meaning that OSPF is assuming the interface is connected to a T1 line. If
it were actually connected to a 512 kbps line, the bandwidth command can be used on the interface to reflect this, after which OSPF will
recalculate the cost.
R1#show ip ospf interface serial0 Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface serial0 R1(config-if)#bandwidth 512
R1#show ip ospf interface serial0 Serial0 is up, line protocol is up Internet Address 172.12.123.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 195
The new bandwidth setting is about one-third of the T1 speed OSPF was
assuming, so the new cost is roughly three times the original cost.
The OSPF path with the lowest cost is preferred. Like RIP, OSPF will
load-balance over four equal-cost paths by default.
You can actually change the value that OSPF uses to base its path cost
calculation on. If you have a very good reason to change it from 100,000,000, you can use the ospf auto-cost reference-bandwidth
command to do so. To add to the fun, note that this command asks you
to enter the new bandwidth reference value in MBPS:
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router ospf 1 R2(config-router)#auto-cost reference-bandwidth ? The reference bandwidth in terms of Mbits per second
One very good reason can be the addition of Fast and GigEthernet
interfaces to your network. Since those interfaces weren't even around when the costs we spoke of earlier were developed, you may (very)
occasionally need to adjust this reference bandwidth - especially with
GigEthernet interfaces.
Comparing OSPF To RIP
OSPF is generally considered superior to RIP. Here are just a few of the
reasons.
OSPF's metric is a better measurement of the actual distance to a
remote network.
-
OSPF uses a composite metric, cost, where RIP uses the sole metric
of hop count.
OSPF does not impose a limit on when networks are "reachable" or
"unreachable", where RIP has a maximum hop count of 15 to combat the counting to infinity issue.
OSPF supports VLSM, where RIPv1 does not. RIPv2 does, though. VLSM support allows a protocol to have more efficient utilization of
IP addresses than a protocol that does not.
OSPF utilizes network bandwidth much more efficiently than RIP.
OSPF multicasts updates only upon initial adjacency, a network
change, or expiration of a 30-minute period where there have been
no network changes. RIPv1 broadcasts full routing tables every 30
seconds. RIPv2 does use multicasting, but still sends full routing tables every 30 seconds. (A single RIP update can contain a
maximum of only 25 routes, so a larger network would require
multiple update packets.)
OSPF converges much more quickly than either version of RIP.
OSPF allows you to create a hierarchical scheme by using multiple
areas. Neither version of RIP offers this capability.
The main drawback of OSPF, especially in comparison to RIP, is that
OSPF can be a lot harder on router resources. OSPF operations requires more CPU and memory than RIP does.
Troubleshooting 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
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.
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 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 Internet Address 100.1.1.1/24, Area 0 Process ID 1, Router ID 10.1.1.1, Network Type BROADCAST,Cost: 10 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 19.1.1.1, Interface address 100.1.1.5 Backup Designated router (ID) 10.1.1.1, Interface address 100.1.1.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:06 Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 19.1.1.1 (Designated Router) Suppress hello for 0 neighbor(s)
Show ip ospf interface is excellent for spotting issues related to hello and
dead timers. If you don't see the problem with the show command,
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. (Repeated for emphasis. :) )
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
Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 1 FULL/DROTHER 00:00:33 30.1.1.4 Ethernet0 3.3.3.3 1 FULL/DROTHER 00:00:31 30.1.1.3 Ethernet0 2.2.2.2 1 FULL/BDR 00:00:30 30.1.1.2 Ethernet0
-
Router2#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 1 FULL/DROTHER 00:00:35 30.1.1.4 Ethernet0 3.3.3.3 1 FULL/DROTHER 00:00:33 30.1.1.3 Ethernet0 1.1.1.1 1 FULL/DR 00:00:39 30.1.1.1 Ethernet0
Router3#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface 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
Router4#show ip ospf nei
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 2011, The Bryant Advantage. All Rights Reserved.