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

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

R1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) Link ID 1.1.1.1 8.8.8.8 ADV Router 1.1.1.1 8.8.8.8 Age 1286 795 Seq# 0x80000006 0x8000000C Checksum 0x0057A7 0x00085E

Net Link States (Area 0) Link ID 10.1.1.5 ADV Router 8.8.8.8 Age 795 Seq# Checksum 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 1.1.1.1 1.1.1.1 4.4.4.4 Pri 1 1 1 State FULL/DR FULL/ FULL/DR Dead Time Address 00:01:52 172.12.123.1 00:00:32 172.12.13.1 00:00:32 172.23.23.4 Interface Serial0 Serial1 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 8.8.8.8 Pri State 1 FULL/DR Dead Time 00:00:37 Address 10.1.1.5 Interface 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: RouterB: RouterC: RouterD: Loopback 1.1.1.1, ethernet0 172.1.1.1 Loopback 2.2.2.2, ethernet0 172.1.1.2 No loopback, ethernet0 172.1.1.3 No loopback, ethernet0 172.1.1.4

The RIDs would be as follows:

RouterA: RouterB: RouterC: RouterD: 1.1.1.1 2.2.2.2 172.1.1.3 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 fourway 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 non-broadcast Specify point-to-multipoint Specify point-to-point Specify OSPF OSPF OSPF OSPF broadcast multi-access network NBMA network point-to-multipoint network 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 1.1.1.1 1.1.1.1 Pri State 1 FULL/DR 1 FULL/ Dead Time Address Interface 00:01:46 172.12.123.1 Serial0 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 <cr>

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 <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 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. go over to R3 now and finish the config.

We'll

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. R1(config)#interface serial0 R1(config-if)#bandwidth 512

End with CNTL/Z.

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 ? <1-4294967> The reference bandwidth in terms of Mbits per second

One very good reason can be the addition of Fast and GigEthernet interfaces to your network. Since those interfaces weren't even around when the costs we spoke of earlier were developed, you may (very) occasionally need to adjust this reference bandwidth - especially with GigEthernet interfaces. Comparing OSPF To RIP OSPF is generally considered superior to RIP. Here are just a few of the reasons. OSPF's metric is a better measurement of the actual distance to a remote network.

OSPF uses a composite metric, cost, where RIP uses the sole metric of hop count. OSPF does not impose a limit on when networks are "reachable" or "unreachable", where RIP has a maximum hop count of 15 to combat the counting to infinity issue. OSPF supports VLSM, where RIPv1 does not. RIPv2 does, though. VLSM support allows a protocol to have more efficient utilization of IP addresses than a protocol that does not. OSPF utilizes network bandwidth much more efficiently than RIP. OSPF multicasts updates only upon initial adjacency, a network change, or expiration of a 30-minute period where there have been no network changes. RIPv1 broadcasts full routing tables every 30 seconds. RIPv2 does use multicasting, but still sends full routing tables every 30 seconds. (A single RIP update can contain a maximum of only 25 routes, so a larger network would require multiple update packets.) OSPF converges much more quickly than either version of RIP. OSPF allows you to create a hierarchical scheme by using multiple areas. Neither version of RIP offers this capability. The main drawback of OSPF, especially in comparison to RIP, is that OSPF can be a lot harder on router resources. OSPF operations requires more CPU and memory than RIP does. Troubleshooting 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 19.1.1.1 172.12.123.3 Pri State 1 2WAY/DROTHER 1 FULL/ Dead Time Address 00:00:38 100.1.1.5 00:00:35 13.13.13.3 Interface Ethernet0 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 4.4.4.4 3.3.3.3 2.2.2.2 Pri 1 1 1 State Dead Time Address FULL/DROTHER 00:00:33 30.1.1.4 FULL/DROTHER 00:00:31 30.1.1.3 FULL/BDR 00:00:30 30.1.1.2 Interface Ethernet0 Ethernet0 Ethernet0

Router2#show ip ospf nei Neighbor ID 4.4.4.4 3.3.3.3 1.1.1.1 Pri 1 1 1 State FULL/DROTHER FULL/DROTHER FULL/DR Dead Time Address 00:00:35 30.1.1.4 00:00:33 30.1.1.3 00:00:39 30.1.1.1 Interface Ethernet0 Ethernet0 Ethernet0

Router3#show ip ospf nei Neighbor ID 4.4.4.4 2.2.2.2 1.1.1.1 Pri State 1 2WAY/DROTHER 1 FULL/BDR 1 FULL/DR Dead Time 00:00:35 00:00:32 00:00:39 Address 30.1.1.4 30.1.1.2 30.1.1.1 Interface Ethernet0 Ethernet0 Ethernet0

Router4#show ip ospf nei Neighbor ID Interface 2.2.2.2 Ethernet0 1.1.1.1 Ethernet0 3.3.3.3 Ethernet0 Pri 1 1 1 State FULL/BDR FULL/DR 2WAY/DROTHER Dead Time Address 00:00:29 00:00:37 00:00:30 30.1.1.2 30.1.1.1 30.1.1.3

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.