Fundamental OSPF Concepts - IGP Routing Protocols - CCNP Routing and Switching ROUTE 300-101 Official Cert Guide (2015)
CCNP Routing and Switching ROUTE 300-101 Official Cert Guide (2015)
Part II. IGP Routing Protocols
Chapter 7. Fundamental OSPF Concepts
This chapter covers the following subjects:
OSPF Review: This section reviews the OSPF concepts, configuration, and verification commands assumed as prerequisites, specifically those details included in the CCNA Exam’s coverage of OSPF.
OSPF Neighbors and Adjacencies on LANs: This section discusses a variety of features that impact when a router attempts to form OSPF neighbor relationships (neighborships), what must be true for those neighborships to work, and what might prevent those neighborships.
OSPF Neighbors and Adjacencies on WANs: This short section examines the typical usage of OSPF neighborships over various types of WAN technologies.
Virtual Links: This section examines how engineers can use virtual links to connect separate parts of an area through another area to maintain the requirement that OSPF areas be contiguous.
Open Shortest Path First (OSPF) requires only a few relatively simple commands when using it in a small- to medium-sized internetwork. However, behind those commands resides a fairly complex routing protocol, with internals that can intimidate those new to OSPF. When compared to the less-complex Enhanced Interior Gateway Routing Protocol (EIGRP), OSPF requires more thought when planning and a few more configuration commands. Additionally, the underlying complexity of OSPF makes operating and verifying an OSPF internetwork more challenging.
This chapter begins with a review of OSPF concepts covered in your CCNA studies. Next, the chapter turns its attention to the formation of OSPF neighborships and adjacencies, followed by the establishment of OSPF neighbors and adjacencies over various WAN technologies. Finally, this chapter examines how a virtual link can be used to make discontiguous areas appear to be contiguous, or how an area not adjacent to an OSPF backbone area can appear to be adjacent.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these nine self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 7-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so that you can assess your knowledge of those specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A.
Table 7-1“Do I Know This Already?” Foundation Topics Section-to-Question Mapping
1. A router has been configured with the commands router ospf 9, network 172.16.1.0 0.0.0.255 area 8 and network 172.16.0.0 0.0.255.255 area 9, in that order. No other OSPF-related commands have been configured. The answers list the IP addresses that could be assigned to this router’s Fa0/0 interface. Which answers list an IP address/prefix length that would cause the router to put Fa0/0 into area 9? (Choose two.)
a. 172.16.0.1/23
b. 172.16.1.1/26
c. 172.16.1.1/24
d. 172.16.0.255/23
e. None of the other answers is correct.
2. Which of the following is true about an OSPF area border router (ABR)?
a. The ABR must have multiple interfaces connected to the backbone area.
b. An ABR is a router with two interfaces, each connected to a different nonbackbone area.
c. The only requirement to be considered an ABR is at least one interface connected to the backbone area.
d. An ABR must have at least one interface in the backbone area plus at least one other interface in a nonbackbone area.
3. Which of the following can either directly or indirectly identify all the interfaces for which 1) OSPF has been enabled and 2) OSPF is not passive? (Choose two.)
a. show ip ospf database
b. show ip ospf interface brief
c. show ip protocols
d. show ip route ospf
e. show ip ospf neighbors
4. Router R1 directly connects to subnet 10.1.1.0/24 with its Fa0/0 interface. R1 can ping four other working OSPF routers in that subnet. R1 is neither the designated router (DR) nor backup DR (BDR). OSPF is working correctly on all five routers. Which of the following are true on R1? (Choose two.)
a. The show ip ospf neighbors command lists two neighbors off Fa0/0.
b. The show ip ospf neighbors command lists four neighbors off Fa0/0.
c. The show ip ospf neighbors command lists two neighbors off Fa0/0 in the FULL state.
d. The show ip ospf neighbors command lists two neighbors off Fa0/0 in the DISCO state.
5. Routers R1 and R2 are OSPF neighbors using their Fa0/0 interfaces, respectively, using default settings for all timers. An engineer adds the ip ospf hello-interval 6 command to R1’s Fa0/0 configuration. Which of the following are true regarding the results from this change? (Choose two.)
a. The show ip ospf neighbor command on R1 lists the revised Hello timer.
b. The show ip ospf interface brief command on R1 lists the revised Hello timer.
c. The R1-R2 neighborship fails because of Hello timer mismatch.
d. The show ip ospf interface command on R1 lists the revised Hello timer.
6. Which of the following settings do not prevent two potential OSPF neighbors from becoming neighbors?
a. The interface used to connect to that neighbor being passive in the OSPF process
b. Duplicate OSPF router IDs
c. Mismatched Dead timers
d. IP addresses of 10.1.1.1/24 and 10.2.2.2/24
e. Mismatched OSPF process IDs
7. A company has a Frame Relay WAN with one central-site router and 100 branch office routers. A partial mesh of PVCs exists: one PVC between the central site and each of the 100 branch routers. All routers use point-to-point subinterfaces and one subnet per PVC. Which of the following is true about OSPF in this design?
a. The central-site router has 100 fully adjacent neighborships with the 100 branches.
b. The central-site router has neighborships with all branch routers, but fully adjacent neighborships with only two branches.
c. The central-site router has a neighborship with the Frame Relay switch.
d. None of the other answers is correct.
8. Which of the following answers can be verified as true based on the following command output from Router R1?
R1# show ip ospf virtual-links Virtual Link OSPF_VL0 to router 4.4.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface FastEthernet0/1, Cost of using 3?
a. R1 is configured with an area 0 virtual-link 4.4.4.4 cost 3 command.
b. The ping 4.4.4.4 command on R1 must currently be successful.
c. R1’s Fa0/1 OSPF cost is 3.
d. 4.4.4.4 is known to R1 based on a Type 1 LSA in area 1.
9. Several links have been broken so that for the next day or two, what was formerly a contiguous area 0 has been broken into two parts. However, both parts of area 0 have working links into area 1 using routers with RID 1.1.1.1 and 2.2.2.2. Which answer lists the command on the router with RID 1.1.1.1 to create a virtual link to help solve this temporary problem?
a. area 0 virtual-link 2.2.2.2
b. area 1 virtual-link 2.2.2.2
c. area 0 source-rid 1.1.1.1 dest-rid 2.2.2.2
d. virtual-link transit-area 1 RID 2.2.2.2
Foundation Topics
OSPF Review
All the CCNP exams consider CCNA materials as prerequisite. Similarly, this book also assumes that the reader is already familiar with CCNA topics. However, the CCNP exams do include features that overlap with CCNA. Additionally, most people forget some details about CCNA topics along the way. This section is intended as a quick reminder of the basics from your earlier CCNA studies related to OSPF, with the addition of a few related details you might not have seen during your CCNA study.
Note that this section does not cover every detail of CCNA-level OSPF topics—the main goal is a quick refamiliarization. To that end, this section begins with a review of OSPF terminology and link-state theory, followed by a configuration and verification sample.
OSPF Link-State Concepts
OSPF uses link-state (LS) logic, which can be broken into three major branches. The first step, neighbor discovery, has the same overall goal as EIGRP’s neighbor discovery process: to find the neighboring routers and exchange enough information so that the two routers know whether they should exchange topology data. (Like EIGRP, OSPF keeps a list of neighbors in its neighbor table.)
The second step, topology database exchange, requires each OSPF router to cooperate by sending messages so that all routers learn topology information—information that is the equivalent of the kinds of information a human would draw and write in a diagram of the internetwork. Each router stores this topology information in its topology database, sometimes called its link-state database (LSDB). The information communicated by OSPF routers and held in their LSDBs includes
The existence of, and an identifier for, each router (router ID)
Each router interface, IP address, mask, and subnet
The list of routers reachable by each router on each interface
During the third major step, route computation, each router independently analyzes the topology data to choose the best routes from its perspective. In particular, LS algorithms such as OSPF use a Shortest Path First (SPF) algorithm to analyze the data, choose the shortest (best) route for each reachable subnet, and add the correct next-hop/outgoing interface information for those routes to the IP routing table.
OSPF requires more planning than does EIGRP, particularly with regard to the necessity for a hierarchical design using OSPF areas. Each router interface exists in a single area, with some special routers, called area border routers (ABR), being the boundary between areas. Inside an area, routers exchange detailed topology information. However, the detailed topology information does not flow between areas. Instead, the ABRs advertise briefer information between areas, including information about subnets/masks, but the information advertised into one area does not include details about the topology of the other area. For perspective on the OSPF design issues, consider Figure 7-1, which shows a typical hierarchical design.
Figure 7-1Typical Hierarchical OSPF Design
One area, called the backbone area, must connect to all other areas. Packets that need to pass between two nonbackbone areas must pass through (at least) one backbone router. The ABRs must keep a copy of the LSDB for each area to which they attach. For example, ABR1 has LSDBs for area 0, area 1, and area 2. However, the ABRs do not forward all the topology details between areas. Instead, they simply advertise the subnets (prefix/length) between the areas.
Because of the sparse information advertised into one area about another area, topologically, routers inside one area know only about the subnets in another area. They do not know about the details of the topology in the other area; instead, from a topology perspective, it appears as if the subnets from another area connect to the ABR. Figure 7-2 shows the concept with the two routers in area 3 from Figure 7-1.
Figure 7-2Area 3 LSDB Concept
Figure 7-2 essentially shows the contents of area 3’s LSDB in graphical form. Two routers exist, with a link between them, and one LAN subnet (Subnet 3) internal to the area. However, the other three sample subnets shown in Figure 7-1 (Subnets 1, 2, and 4) appear connected to ABR2. (Other subnets exist outside area 3 as well; the figure just shows a few as examples.) The routers inside area 3 can calculate and add routes to their routing tables, but without needing all the topology information shown in Figure 7-1. By using an area design similar to the one illustrated inFigure 7-1, network engineers can group routers and interfaces into areas, which results in smaller topology databases on those routers, as shown in Figure 7-2. As a result, each router reduces the processing time, memory consumption, and effort to calculate the best routes.
OSPF uses a fairly large number of terms. Table 7-2 lists some of the more common OSPF terms as an early reference as you read through the chapter.
Table 7-2Commonly Used OSPF Terms
OSPF Configuration Review
Other than the configuration of the OSPF areas, a basic configuration of OSPF basics looks similar to a simple EIGRP configuration. Cisco IOS uses the router ospfprocess-id command, plus one or more networknet-id wildcard-maskareaarea-id subcommands, to enable OSPF on the router and on router interfaces. The rules for these commands are as follows:
Step 1. Neighboring routers’ router ospfprocess-id commands do not have to be configured with the same process-id parameter to become neighbors.
Step 2. Cisco IOS only enables OSPF on interfaces matched by an OSPF network command. When enabled, the router does the following:
a. Attempts to discover OSPF neighbors on that interface by sending multicast OSPF Hello messages
b. Includes the connected subnet in future topology database exchanges
Step 3. To match an interface with the network command, Cisco IOS compares the net-id configured in the network command with each interface’s IP address, while using the configured wildcard mask as an ACL wildcard mask.
Step 4. Regardless of the order in which the network commands are added to the configuration, Cisco IOS puts these commands into the configuration file with the most specific (most binary 0s) wildcard mask first, for overlapping network ranges. Cisco IOS lists the networkcommands in this sorted order in the configuration.
Step 5. The first network command that matches an interface, per the order shown in the output of the show running-config command, determines the OSPF area number associated with the interface.
Example 7-1 shows a sample configuration for each router in Figure 7-3.
Figure 7-3Three-Router Internetwork with Two OSPF Areas
Example 7-1OSPF Configuration on Routers R1, R2, and R3
! On Router R1:
! On Router R2:
! On Router R3:
First, note that all three routers use a different process ID on their respective router ospfprocess-id commands. These mismatches do not prevent neighborships from forming.
Next, consider the requirement that R1’s S0/0/0 and R2’s S0/0/1 must be in the same area. Typically, all routers on the same subnet need to be in the same area; the routers themselves are the boundary between areas. In this case, R1’s network 10.0.0.0 0.255.255.255 area 1 command matches all interfaces whose addresses begin with 10 in the first octet and assigns those interfaces (Fa0/0 and S0/0/0) to area 1. Similarly, R2’s network 10.1.12.2 0.0.0.0 area 1 command matches only one IP address—R2’s S0/0/1 IP address—and places it in area 1. Looking further at R2’s OSPF configuration, note that both network commands actually match the 10.1.12.2 S0/0/1 IP address: one with area 0 and one with area 1. However, R2 orders these two network commands with the most-specific wildcard mask first, placing the command with wildcard mask 0.0.0.0 first and the one with wildcard mask 0.0.255.255 second. Then, R2 compares the commands to the interface IP addresses in order, so R2 places S0/0/1 into area 1. (Note that in real internetworks, choosing wildcard masks such that it is clear which network command should match each interface is the better choice.)
On R3, the network 10.1.0.0 0.0.255.255 area 0 command matches interfaces Fa0/0 and S0/0/0, adding them to area 0. R3 then needs an additional network command to enable OSPF on R3’s Fa0/1 interface with all three interfaces in area 0.
Finally, note that the addition of the loopback interfaces causes each router to choose an obvious OSPF router ID (RID). OSPF uses the same logic as does EIGRP to choose a router ID on each router, at the time the OSPF process is initialized, as follows, in the listed order of precedence:
Step 1. Use the router ID defined in the router-idx.x.x.x OSPF router subcommand.
Step 2. Use the highest IP address of any up loopback interface.
Step 3. Use the highest IP address of any up nonloopback interface.
Note that for the second and third choices, the interface does not need to have OSPF enabled.
OSPF Verification Review
The verification process, whether it uses a formal verification plan or not, requires some knowledge of the intended design and function of the network. The design and implementation documents dictate what the network should do, and the verification plan should confirm whether the network is meeting those goals.
For the purposes of this OSPF review section, assume that the only design goal for the internetwork in Figure 7-3 is that OSPF be used so that all routers have routes to reach all subnets shown in the figure, within the constraints of the area design.
To verify such a simple design, an engineer should start by confirming on which interfaces OSPF has been enabled on each router. The next step should be to determine whether the OSPF neighbor relationships that should occur are indeed up and working. Then, the OSPF topology table should be examined to confirm that non-ABRs have only topology information for their respective areas. Finally, the IP routes on each router should be examined, confirming that all routes are known. To that end, Table 7-3 summarizes five key show commands that provide the information to answer these questions:
Table 7-3Commonly Used OSPFshowCommands
Example 7-2 shows samples of each command listed in Table 7-3. Note that the output highlights various samples of items that should be verified, including the interfaces on which OSPF is enabled, the known neighbors, the neighbors’ states, the LSAs in the topology table, and the OSPF routes.
Example 7-2OSPF Verification on Routers R1, R2, and R3
! On Router R2:
OSPF Feature Summary
Table 7-4 summarizes some key OSPF facts. The table includes some review items from CCNA-level OSPF topics, plus some topics that will be developed in this and upcoming chapters. The items that are not CCNA topics are included just for convenience when reviewing for final preparation before taking the exam.
Table 7-4OSPF Feature Summary
This concludes the review of OSPF topics. The rest of this chapter focuses on OSPF topics related to the formation of OSPF neighbor relationships.
OSPF Neighbors and Adjacencies on LANs
With EIGRP, neighborship is relatively simple, if two EIGRP routers discover each other (using Hellos) and meet several requirements (like being in the same subnet). After becoming neighbors, the two EIGRP routers exchange topology information.
Comparing OSPF and EIGRP, OSPF neighborship is more complex. First, with EIGRP, two routers either become neighbors or they do not. With OSPF, even after all the neighbor parameter checks pass, two classes of neighborships exist: neighbors and fully adjacent neighbors. The OSPF neighbor discovery process has many pitfalls when the internetwork uses Frame Relay, with a class of issues that simply do not exist with EIGRP. Finally, OSPF uses an underlying Finite State Machine (FSM) with eight neighbor states used to describe the current state of each OSPF neighbor, adding another layer of complexity compared to EIGRP.
This section breaks down the OSPF neighbor relationship, the logic, and the OSPF configuration settings—anything that impacts OSPF neighborship on LAN interfaces. This section examines the following questions:
On what interfaces will this router attempt to discover neighbors by sending multicast OSPF Hello messages?
Does a potential neighbor meet all requirements to become a neighbor?
This section examines these topics, in sequence.
Enabling OSPF Neighbor Discovery on LANs
OSPF sends multicast OSPF Hello messages on LAN interfaces, attempting to discover OSPF neighbors, when two requirements are met:
OSPF has been enabled on the interface, either through the network router subcommand or the ip ospf area interface subcommand.
The interface has not been made passive by the passive-interface router subcommand.
When both requirements are met, OSPF sends Hellos to the 224.0.0.5 multicast address, an address reserved for all OSPF-speaking routers. The Hello itself contains several parameters that must be checked, including the OSPF RID of the router sending the Hello and the OSPF area that router has assigned to that LAN subnet.
Of the three configuration commands that might impact whether a router attempts to discover potential neighbors on an interface, one is commonly understood (network) and was already covered in this chapter’s “OSPF Configuration Review” section. The second configuration command that impacts whether potential neighbors discover each other, passive-interface, works just like it does with EIGRP. In short, when a router configures an interface as passive to OSPF, OSPF quits sending OSPF Hellos, so the router will not discover neighbors. The router will still advertise the interface’s connected subnet if OSPF is enabled on the interface, but all other OSPF processing on the interface is stopped.
The third configuration command that impacts whether a router discovers potential neighbors using Hellos is the ip ospfprocess-idareaarea-id interface subcommand. This command acts as a replacement for the OSPF network command. Simply put, this command enables OSPF directly on the interface and assigns the area number.
To demonstrate the ip ospf area and passive-interface commands, Example 7-3 shows a revised configuration on Router R3, as seen originally in Example 7-1. In this new example configuration, R3 has made two interfaces passive, because no other OSPF routers exist on its LAN subnets. Additionally, R3 has migrated its configuration away from the older network commands, instead using the ip ospf area interface subcommand.
Example 7-3Configuringpassive-interfaceandip ospf area
interface loopback 1 Ip address 3.3.3.3 255.255.255.255
interface FastEthernet0/0 ip ospf 3 area 0 interface FastEthernet0/1 ip ospf 3 area 0 interface Serial0/0/1 ip ospf 3 area 0
R3# show ip protocols Routing Protocol is "ospf 3" 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 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: Routing on Interfaces Configured Explicitly (Area 0): Serial0/0/1 FastEthernet0/1 FastEthernet0/0 Reference bandwidth unit is 100 mbps Passive Interface(s): FastEthernet0/0 FastEthernet0/1 Routing Information Sources: Gateway Distance Last Update Distance: (default is 110)
Note that in the second half of Example 7-3, the show ip protocols command now lists the interfaces as matched with the ip ospf area commands, and it lists the passive interfaces. You can take the list of explicitly configured interfaces, remove the passive interfaces, and know which interfaces on which R3 will attempt to discover OSPF neighbors. Also, take a moment to compare this output with the same command’s output in Example 7-2, with the earlier example listing the parameters of the configured network commands.
Settings That Must Match for OSPF Neighborship
After an OSPF router has discovered a potential neighbor by receiving a Hello from the other router, the local router considers the router that sent the Hello as a potential neighbor. The local router must examine the contents of the received Hello, plus a few other factors, compare those settings to its own, and check for agreement, and only then can that other router be considered an OSPF neighbor.
For reference, the following list details the items seen in OSPF Hello messages. Note that some fields might not be present in a Hello, depending on the conditions in the network.
OSPF router ID
Stub area flag
Hello interval
Dead interval
Subnet mask
List of neighbors reachable on the interface
Area ID
Router priority
Designated router (DR) IP address
Backup DR (BDR) IP address
Authentication digest
Table 7-5 summarizes the items that two routers will compare when deciding whether they can become OSPF neighbors. For study purposes, the table also lists some items that one might think prevent OSPF neighborship but do not, with comparisons to EIGRP.
Table 7-5Neighbor Requirements for EIGRP and OSPF
The first few items in Table 7-5 require only a minor amount of discussion. First, OSPF checks the IP address (found as the source address of the Hello message) and mask (listed in the Hello message) of the potential neighbor, calculates the subnet address, and compares the subnet address and mask to its own interface IP address. Both the subnet address and mask must match. Additionally, the OSPF Hello messages include the area number of the subnet, as defined by that router. The receiving router compares the received Hello with its own configuration and rejects the potential neighbor if the area numbers do not match.
The next several sections examine other settings that can prevent OSPF neighborship.
Optimizing Convergence Using Hello and Dead Timers
Using the same concept as EIGRP, but with different terminology, OSPF uses two timers to monitor the reachability of neighbors. With OSPF, the Hello interval defines how often the router sends a Hello on the interface. The Dead interval defines how long a router should wait, without hearing any Hello messages from a neighbor, before deciding that the neighbor failed. For example, with a default LAN interface Hello timer of 10 seconds, and a Dead interval of 40 seconds, the local router sends Hello messages every 10 seconds. The neighbor resets its downward-counting Hold timer to 40 upon receiving a Hello from that neighbor. Under normal operation on a LAN, with defaults, the Dead timer for a neighbor would vary from 40 down to 30, and then be reset to 40 upon receipt of the next Hello. However, if Hello messages were not received for 40 seconds, the neighborship would fail, driving convergence.
To tune for faster convergence, you can configure OSPF to set a lower Hello and Dead timer. It speeds convergence in some cases. Note that if the interface fails, OSPF will immediately realize that all neighbors reached through that interface have also failed and will not wait on the Dead timer to count down to 0. For example, consider the internetwork in Figure 7-4. This internetwork has four routers connected to the same VLAN, with interfaces, IP addresses, masks, and OSPF areas as shown.
Figure 7-4Four OSPF Routers on the Same Subnet, with Two OSPF Areas
Example 7-4 verifies some of the facts about the routers in Figure 7-4, showing the changes to the Hello interval and the resulting failed neighborships. Each router has been assigned an obvious RID: 1.1.1.1 for R1, 2.2.2.2 for R2, and so on.
Example 7-4Effect of Configuring a Different OSPF Hello Interval
R4# show ip ospf neighbors Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 2WAY/DROTHER 00:00:35 10.5.5.1 FastEthernet0/0 2.2.2.2 1 FULL/BDR 00:00:39 10.5.5.2 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:38 10.5.5.3 FastEthernet0/0 R4# conf t Enter configuration commands, one per line. End with CNTL/Z. R4(config)# interface fastethernet0/0 R4(config-if)# ip ospf hello-interval 9 R4(config-if)# ^Z *Apr 28 00:06:20.271: %SYS-5-CONFIG_I: Configured from console by console R4# show ip ospf interface fa0/0 FastEthernet0/0 is up, line protocol is up Internet Address 10.5.5.4/28, Area 0 Process ID 4, Router ID 4.4.4.4, Network Type BROADCAST, Cost: 1 Enabled by interface config, including secondary ip addresses Transmit Delay is 1 sec, State DROTHER, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 10.5.5.3 Backup Designated router (ID) 2.2.2.2, Interface address 10.5.5.2 Timer intervals configured, Hello 9, Dead 36, Wait 36, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:01 Supports Link-local Signaling (LLS) Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 3 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 3, Adjacent neighbor count is 2 Adjacent with neighbor 2.2.2.2 (Backup Designated Router) Adjacent with neighbor 3.3.3.3 (Designated Router) Suppress hello for 0 neighbor(s) R4# *Apr 28 00:06:51.559: %OSPF-5-ADJCHG: Process 4, Nbr 1.1.1.1 on FastEthernet0/0 from 2WAY to DOWN, Neighbor Down: Dead timer expired *Apr 28 00:06:57.183: %OSPF-5-ADJCHG: Process 4, Nbr 3.3.3.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired *Apr 28 00:06:58.495: %OSPF-5-ADJCHG: Process 4, Nbr 2.2.2.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
This example demonstrates several interesting facts. First, note that upon configuring the ip ospf hello-interval 9 command under Fa0/0, the show ip ospf interface fa0/0 command shows that not only did the Hello interval change, but the Dead timer was also set to 4X the Hello interval, or 36. To directly set the Dead timer on the interface, use the ip ospf dead-intervalvalue interface subcommand. Then, at the end of the example, note that all three of R4’s neighbor relationships failed, because those routers now have mismatched Hello and Dead timers. However, the neighbor relationships failed only after the Dead timers expired, as noted in the messages and as confirmed by the timestamps on the messages.
Example 7-4 also shows the two normal, stable, and working neighbor states. Look to the heading “state” in the output of the show ip ospf neighbors command at the top of the example. The first word (before the /) lists the state or status of each neighbor. FULL refers to a fully adjacent neighbor, meaning that the OSPF topology has been fully exchanged with that neighbor. The other state listed there, 2WAY, is a normal, stable, working state for neighbors with which topology data was not exchanged directly. In some cases, OSPF routers exchange their topology information to one specific router on a LAN, called the designated router (DR), but they do not exchange their database directly with other routers. In the preceding example, taken from R4, R4 lists its relationship with R1 as 2WAY, which happens to be the status for a working neighbor that does not become fully adjacent.
Note
OSPF has two methods to tune the Hello and Dead intervals to subsecond values. Like EIGRP, OSPF supports Bidirectional Forwarding Detection (BFD). Additionally, OSPF supports the command ip ospf dead-interval minimal hello-multipliermultiplier, which sets the Dead interval to one second, and the Hello interval to a fraction of a second based on the multiplier. For example, the command ip ospf dead-interval minimal hello-multiplier 4 sets the Dead interval to one second, with Hellos occurring four times (the multiple) per second, for an effective Hello interval of 1/4 seconds.
Using a Unique OSPF Router ID
As mentioned earlier in the “OSPF Review” section, each OSPF router assigns itself a router ID, based on the same rules as EIGRP. In OSPF’s case, that means a router first looks for the OSPF router-idrid-value OSPF subcommand; next, to the highest IP address of any up loopback interface; and finally, to the highest IP address of any up nonloopback interface.
An OSPF RID mismatch makes for unpredictable results, because OSPF routers base their view of the topology on the topology database, and the database identifies routers based on their RIDs. By design, all OSPF RIDs in a domain should be unique. To avoid such issues, OSPF prevents neighborships between routers with duplicate RIDs.
The next example shows what happens when two routers discover each other as potential neighbors but notice a duplicate RID. Using the same network as in Figure 7-4, each router has been assigned an obvious RID: 1.1.1.1 for R1, 2.2.2.2 for R2, and so on. Unfortunately, R4 has been mistakenly configured with RID 1.1.1.1, duplicating R1’s RID. R4 is powered on after all three other routers have established neighbor relationships. Example 7-5 shows some of the results.
Example 7-5OSPF RID Mismatch—R1 and R4, R4 Connects After R1
! On R1... the following output occurs AFTER R4 powers on. R1, RID 1.1.1.1, ! does not form a neighbor relationship with R4. R1# show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/BDR 00:00:35 10.5.5.2 FastEthernet0/0 3.3.3.3 1 FULL/DR 00:00:33 10.5.5.3 FastEthernet0/0
! On R3 ! R3 does form a neighbor relationship, but does not learn routes from ! R4. Note that R3 does not have a route for R4's 10.4.4.0/27 subnet. R3# show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DROTHER 00:00:38 10.5.5.1 FastEthernet0/0 1.1.1.1 1 FULL/DROTHER 00:00:37 10.5.5.4 FastEthernet0/0 2.2.2.2 1 FULL/BDR 00:00:35 10.5.5.2 FastEthernet0/0 R3# show ip route ospf 10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks O 10.2.2.0/25 [110/2] via 10.5.5.2, 00:06:56, FastEthernet0/0 O 10.1.1.0/24 [110/2] via 10.5.5.1, 00:01:34, FastEthernet0/0
As you can see from the output on R1, whose RID is duplicated with R4, the routers with duplicate RIDs do not form a neighbor relationship. Additionally, other routers, such as R3, do form neighbor relationships with the two routers, but the duplication confuses the topology flooding process. Because R3 formed its neighborship with R1 before R4, R3 does learn a route for R1’s 10.1.1.0/24 subnet, but does not for R4’s 10.4.4.0/27 subnet. However, with the same configuration, but a different sequence and timing of neighbors coming up, R3 might learn about 10.4.4.0/27 instead of 10.1.1.0/24.
Note
The OSPF process will not start without an RID.
Using the Same IP MTU
The maximum transmission unit (MTU) of an interface tells Cisco IOS the largest IP packet that can be forwarded out an interface. This setting protects the packet from being discarded on data links whose Layer 2 features will not pass a frame over a certain size. For example, routers typically default to an IP MTU of 1500 bytes.
From a data plane perspective, when a router needs to forward a packet larger than the outgoing interface’s MTU, the router either fragments the packet or discards it. If the IP header’s Do Not Fragment (DF) bit is set, the router discards the packet. If the DF bit is not set, the router can perform Layer 3 fragmentation on the packet, creating two (or more) IP packets with mostly identical IP headers, spreading the data that follows the original IP packet header out among the fragments. The fragments can then be forwarded, with the reassembly process being performed by the receiving host.
From a design perspective, the MTU used by all devices attached to the same data link ought to be the same value. However, routers have no dynamic mechanism to prevent the misconfiguration of MTU on neighboring routers.
When an MTU mismatch occurs between two OSPF neighbors, one router will attempt to become neighbors with the other router whose MTU differs. The other router will be listed in the list of neighbors (show ip ospf neighbor). However, the two routers will not exchange topology information, and the two routers will not calculate routes that use this neighbor as a next-hop router.
The IP MTU can be set on an interface using the ip mtuvalue interface subcommand and for all Layer 3 protocols with the mtuvalue interface subcommand. Example 7-6 shows an example, with R4 again configured so that it has problems.
Example 7-6Setting IP MTU and Failing the OSPF Database Exchange Process
R4# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R4(config)# int fastethernet0/0 R4(config-if)# ip mtu 1498 R4(config-if)# ^Z R4# R4# show ip interface fa0/0 FastEthernet0/0 is up, line protocol is up Internet address is 10.5.5.4/28 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1498 bytes ! lines omitted for brevity R4# show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 EXSTART/DROTHER 00:00:39 10.5.5.1 FastEthernet0/0 2.2.2.2 1 EXSTART/DROTHER 00:00:37 10.5.5.2 FastEthernet0/0 3.3.3.3 1 EXSTART/BDR 00:00:39 10.5.5.3 FastEthernet0/0
*Apr 28 12:36:00.231: %OSPF-5-ADJCHG: Process 4, Nbr 2.2.2.2 on FastEthernet0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions R4# show ip ospf neighbors
Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 INIT/DROTHER 00:00:39 10.5.5.1 FastEthernet0/0 2.2.2.2 1 DOWN/DROTHER - 10.5.5.2 FastEthernet0/0 3.3.3.3 1 INIT/DROTHER 00:00:39 10.5.5.3 FastEthernet0/0
Note that you could argue that the mismatched MTU does not prevent routers from becoming neighbors, but it does prevent them from successfully exchanging topology data. When the mismatch occurs, a pair of routers tries to become neighbors, and they list each other in the output of theshow ip ospf neighbors command, as seen in Example 7-6. However, the neighbor state (listed before the /, under the heading “State”) moves from EXSTART (which means that the database exchange process is starting), but it fails as implied by the highlighted message in the example. Then, the state changes to DOWN, and later one router tries again, moving to the INIT (initializing) state. So, the neighbor is listed in the output of the show ip ospf neighbors command, but it never succeeds at exchanging topology data.
OSPF Neighbors and Adjacencies on WANs
To form OSPF neighbor relationships on WAN connections, OSPF still must meet the same requirements as on LANs. The area number must match with each neighbor; the IP subnet address and mask of each router must match; authentication must pass; and so on. In short, the items in Table 7-5 earlier in this chapter must be true.
However, the operation of OSPF on WAN links of various types requires some additional thought, particularly when developing an implementation and verification plan. In particular, depending on the WAN technology and configuration, the following additional questions might matter for proper OSPF operation over WAN connections:
Will the routers discover each other using multicast OSPF Hello messages, or do the neighbors require predefinition?
Will the routers try to elect a DR, and if so, which router should be the DR?
With which other routers should each router become an OSPF neighbor?
The first two of these items depend in part on the setting of the OSPF network type, and the third question depends on the WAN service. This section first examines the concept of OSPF network types and then examines the use of OSPF over common WAN technologies.
OSPF Network Types
The OSPF network type (a per-interface setting) directs OSPF in regard to three important facts:
Whether the router can expect to discover neighbors using multicast Hello messages
Whether only two or more than two OSPF routers can exist in the subnet attached to the interface
Whether the router should attempt to elect an OSPF DR on that interface
For example, LAN interfaces require a DR because of the default OSPF network type of broadcast. An OSPF network type of broadcast dynamically discovers neighbors using multicast Hello messages. Also, the broadcast OSPF network type supports more than two routers on the same subnet, and it elects a DR. Conversely, point-to-point links and point-to-point WAN subinterfaces default to use a network type of point-to-point, meaning that only two OSPF routers can exist in the subnet, neighbors can be dynamically discovered through Hellos, and the routers do not elect a DR.
In production networks, the network type is often ignored, because there is no motivation to change this setting—you pick a combination that works, and most everyone ignores it. However, for the sake of CCNP ROUTE, you need to be able to distinguish between these different OSPF network types.
Table 7-6 summarizes the OSPF network types and their meanings. Note that this per-interface or per-subinterface setting is configured with the ip ospf networktype interface subcommand.
Table 7-6OSPF Network Types
OSPF Neighborship over Point-to-Point Links
Point-to-point serial links can be a bit boring. You configure IP addresses on either end, configure the clock rate if using a back-to-back serial cable in a lab, and configure no shutdown on the interfaces. When enabling OSPF on the interfaces, no extra effort is required compared to LANs—just enable OSPF on the interface, and rely on the default OSPF network type of point-to-point.
However, serial links can provide a convenient and uncluttered place to experiment with OSPF network types. As such, Figure 7-5 shows a small network with two routers, with Example 7-7 that follows showing several examples of the OSPF network type. (This small network matches a portion of the network shown in Figure 7-1 earlier in this chapter.)
Figure 7-5Simple Two-Router Internetwork
Example 7-7 demonstrates OSPF network types with all defaults on the High-Level Data Link Control (HDLC) link between R1 and R2.
Example 7-7OSPF Network Types, Default, on an HDLC Link
R1# show run int s0/0/0 Building configuration...
Current configuration : 102 bytes ! interface Serial0/0/0 ip address 10.1.12.1 255.255.255.252 no fair-queue clock rate 1536000 ! router ospf 1 network 10.0.0.0 0.255.255.255 area 1 ! end
R1# show ip ospf interface s0/0/0 Serial0/0/0 is up, line protocol is up Internet Address 10.1.12.1/30, Area 1 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64 ! lines omitted for brevity
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 0 FULL/ - 00:00:31 10.1.12.2 Serial0/0/0
Example 7-7 begins listing R1’s configuration on the serial link, mainly to make the point that the OSPF network type has not been explicitly configured. The show ip ospf interface command then lists the network type (point-to-point). Based on Table 7-7, this type should dynamically discover neighbors, and it does, with neighbor 2.2.2.2 (R2) being listed at the end of the example. In particular, note that under the state heading in the show ip ospf neighbor command output, after the /, only a dash is listed. This notation means that no attempt was made to elect a DR. If the network type had implied that a DR should be elected, some text would be listed after the /, for example, “/DR” meaning that the neighbor was the DR. (Refer back to the end of Example 7-4 for an example of the output of show ip ospf neighbor in which a DR has been elected.)
Table 7-7Design Review
Example 7-8 shows an alternative where both routers change their OSPF network type on the serial link to nonbroadcast. This change is nonsensical in real designs and is only done for the purposes of showing the results: that the neighbors are not discovered dynamically, but after being defined, a DR is elected.
Note
R2 has been preconfigured to match the configuration on R1 in Example 7-8. Specifically, the OSPF network type has been changed (ip ospf network non-broadcast), and R2 has been configured with a neighbor 10.1.12.1 OSPF router subcommand.
Example 7-8Configuring OSPF Network Type Nonbroadcast on an HDLC Link
R1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)# interface s0/0/0 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 R1(config-if)# ip ospf network non-broadcast R1(config-if)# ^Z
R1# show ip ospf neighbor
R1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)# router ospf 1 R1(config-router)# neighbor 10.1.12.2 R1(config-router)# ^Z R1#
*Apr 28 20:10:15.755: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0/0 from LOADING to FULL, Loading Done R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DR 00:01:58 10.1.12.2 Serial0/0/0
The example begins with R2 already configured, so the neighbor relationship has already failed. When the OSPF network type changes on R1’s S0/0/0, the routers do not dynamically discover each other, based on the network type (nonbroadcast). However, by completing the configuration in the example by adding R1’s neighbor 10.1.12.2 command, the neighbor relationship is formed. Also, note that the final show ip ospf neighbor command lists a state of FULL, then a /, and then DR, meaning that a DR was indeed elected, as required by this OSPF network type.
Neighborship over Frame Relay Point-to-Point Subinterfaces
Frame Relay design allows several options for IP addressing and subnetting. One option treats each pair of routers on the ends of each PVC as a point-to-point topology, with one subnet assigned to each pair of routers. Another option treats more than two routers as a group, whether connected with a full mesh or partial mesh of PVCs, with a single subnet assigned to that group.
Many Frame Relay designs use the first option, treating each pair of routers on the ends of a PVC as a single subnet, as shown in Figure 7-6. In such cases, it makes sense to treat each PVC as a separate point-to-point connection, assigning a single subnet (at Layer 3) to each Layer 2 PVC.
Figure 7-6Hub-and-Spoke Frame Relay Network
With this design, if all the routers use point-to-point subinterfaces as shown in R1’s configuration in the figure, you can ignore the OSPF network (interface) type and OSPF works fine. Cisco IOS point-to-point subinterfaces unsurprisingly default to use an OSPF network type of point-to-point. The two routers discover each other using multicast OSPF Hellos. They do not bother to elect a DR, and everything works well.
Neighborship on MPLS VPN
Multiprotocol Label Switching (MPLS) virtual private networks (VPN) create a WAN service that has some similarities but many differences when compared to Frame Relay. The customer routers connect to the service, often with serial links but at other times with Frame Relay PVCs or with Ethernet. The service itself is a Layer 3 service, forwarding IP packets through a cloud. As a result, no predefined PVCs need to exist between the customer routers. Additionally, the service uses routers at the edge of the service provider cloud—generically called provider edge (PE) routers—and these routers are Layer 3 aware.
That Layer 3 awareness means that the customer edge (CE) routers form an OSPF neighborship with the PE router on the other end of their local access link, as shown in Figure 7-7. The PE routers exchange their routes, typically using Multiprotocol BGP (MP-BGP). So, unlike the design seen previously in Figure 7-6, the central-site router will not have an OSPF neighborship with each branch office router but will have a neighborship with the MPLS VPN provider’s PE router. MPLS VPN characteristics do impact the data seen in the LSDB in the enterprise routers and require some different thinking in regard to area design.
Figure 7-7OSPF Neighborships over MPLS VPN
Neighborship on Metro Ethernet
In the like-named section “Neighborship on Metro Ethernet” in Chapter 4, “Fundamental EIGRP Concepts,” you were introduced to some basic terminology for Metro Ethernet, including Virtual Private Wire Service (VPWS), a point-to-point service, and Virtual Private LAN Service (VPLS), a multipoint service. In both cases, however, if a customer connects to the service using a router, the configuration typically uses VLAN trunking with subinterfaces off a Fast Ethernet or Gigabit Ethernet interface. If connecting with a Layer 3 switch, the configuration again often uses VLAN trunking, with the Layer 3 configuration being made on various VLAN interfaces inside the switch configuration.
Because MetroE services provide Layer 2 connectivity, customer routers do not form OSPF neighborships with routers inside the service provider’s network. Instead, OSPF neighborships form between customer routers, essentially as if the service were a large WAN. Figure 7-8 shows the basic idea, with four routers connected to the service.
Figure 7-8OSPF Neighborships over Metro Ethernet
Figure 7-8 shows four routers with any-to-any connectivity, typical of a VPWS service. However, from an OSPF design perspective, each pair of routers could communicate over a different VLAN, using a different Layer 3 subnet. Each Layer 3 subnet could be in a different area.
Virtual Links
OSPF area design requires the use of a backbone area, area 0, with each area connecting to area 0 through an ABR. However, in some cases, two backbone areas exist. In other cases, a nonbackbone area might not have a convenient point of connection to the backbone area, for example:
Case 1: An existing internetwork needs to add a new area, with a convenient, low-cost connection point with another nonbackbone area; however, that connection does not give the new area any connection to area 0.
Case 2: Even with a well-designed area 0, a combination of link failures might result in a discontiguous backbone area, essentially creating two backbone areas.
Case 3: Two companies could merge, each using OSPF. To merge the OSPF domains, one backbone area must exist. It might be more convenient to connect the two networks using links through an existing nonbackbone area, but that design means two backbone areas, which is not allowed.
Figure 7-9 shows an example of each of the first two cases.
Figure 7-9Examples of Area Design Issues
The problems in each case have different symptoms, but the problems all stem from the area design requirements: Each area should be contiguous, and each nonbackbone area should connect to the backbone area through an ABR. When the network does not meet these requirements, engineers could simply redesign the areas. However, OSPF provides an alternative tool called an OSPF virtual link.
Understanding OSPF Virtual Link Concepts
An OSPF virtual link allows two ABRs that connect to the same nonbackbone area to form a neighbor relationship through that nonbackbone area, even when separated by many other routers and subnets. This virtual link acts like a virtual point-to-point connection between the two routers, with that link inside area 0. The routers form a neighbor relationship, inside area 0, and flood LSAs over that link.
For example, consider the topology in Figure 7-10, which shows an example of the third of the three cases described in the beginning of this section. In this case, two companies merged. Both companies had a small office in the same city, so for expediency’s sake, they connected the two former enterprise internetworks through a newly combined local sales office in area 1.
Figure 7-10Connecting Two Area 0s with a Virtual Link
Although adding the link between branch offices can be a cost-effective temporary choice, it creates a design problem: Two backbone areas now exist, and OSPF requires that the backbone area be contiguous. To solve this problem, the engineer configures a virtual link between ABRs C1 and C2. The virtual link exists inside area 0, making area 0 contiguous.
To define the virtual link, each router configures the other router’s RID and a reference to the area through which the virtual link passes (area 1 in this case). The two routers send the usual OSPF message types, encapsulated inside unicast IP packets, with a destination IP address of the router on the other end of the virtual link. Any routers between the two routers that create the virtual link—for example, the two branch routers in Figure 7-10—just forward these OSPF packets like any other packet. The neighbors on the ends of the virtual link flood their LSDBs to each other so that all routers in both parts of area 0 learn the routes from the other area 0.
The ABRs connected over a virtual link act mostly like any other ABR, with a couple of differences. The first difference is that ABRs send all OSPF messages as unicasts to the IP address of the router on the other end of the link. Second, the routers also mark the Do Not Age (DNA) bit in the LSAs, meaning that all routers on the other side of the virtual link will not expect the LSAs to be reflooded over the virtual link on the usual 30-minute refresh interval. This helps reduce overhead over the virtual link, which often runs over slower links and less-powerful routers. The router also assigns an OSPF cost to the virtual link, just as it would for an interface.
After the virtual link is up, the ABRs’ SPF processes can calculate their best routes just like before, using the virtual link as another point-to-point link in area 0. For packets destined to pass from one part of the backbone over the virtual link to the other part of the backbone, the chosen best routes eventually lead the packets to the router with the virtual link. That router, connected to the transit nonbackbone area, has already calculated its next hop based on the LSDB in the transit area (Router C1 and transit area 1 in the example of Figure 7-10). The routers in the transit area choose routes that eventually deliver the packet to the router on the other end of the virtual link (Router C2 in Figure 7-10).
Configuring OSPF Virtual Links
Configuring an OSPF virtual link requires a minor amount of configuration just to get the link working, with several optional configuration items. Most of the optional configuration settings relate to features that would normally be configured on the interface connecting two neighboring routers, but with a virtual link, there is no such interface, so the parameters must be added to the area virtual-link command. The following list summarizes the key configuration options on the area virtual-link router subcommand:
The remote-RID in the areaarea-numvirtual-linkremote-RID command refers to the other router’s RID.
The area-num in the areaarea-numvirtual-linkremote-RID command refers to the transit area over which the packets flow between the two routers.
The transit area over which the two routers communicate must not be a stubby area.
The optional configuration of OSPF neighbor authentication parameters, normally configured as interface subcommands, must be configured as additional parameters on the area virtual-link command.
The optional configuration of Hello and Dead intervals, normally configured as interface subcommands, must be configured as additional parameters on the area virtual-link command.
The router assigns the virtual link an OSPF cost as if it were a point-to-point link. The router calculates the cost as the cost to reach the router on the other end of the link, as calculated using the transit area’s LSDB.
Example 7-9 shows the configuration of a virtual link on Router C1 and Router C2 shown in Figure 7-10. The configuration shows the virtual link, referencing area 1 as the transit area, with each router referring to the other router’s RIDs. The configuration also shows the loopback IP addresses on which the ABR’s RIDs are based being advertised into OSPF.
Example 7-9OSPF Virtual Link Configuration on Routers C1 and C2
! On Router C1: router ospf 1 area 1 virtual-link 4.4.4.4 ! interface fastethernet0/0 ip address 10.1.1.1 255.255.255.0 ip ospf 1 area 0 ! interface fastethernet0/1 ip address 10.21.1.1 255.255.255.0 ip ospf 1 area 1 ! interface loopback 1 ip address 1.1.1.1 255.255.255.0 ip ospf 1 area 1
! On Router C2: router ospf 4 area 1 virtual-link 1.1.1.1 ! interface fastethernet0/0 ip address 10.4.4.4 255.255.255.0 ip ospf 4 area 0 ! interface fastethernet0/1 ip address 10.24.1.1 255.255.255.0 ip ospf 4 area 1 ! interface loopback 1 ip address 4.4.4.4 255.255.255.0 ip ospf 4 area 1
Verifying the OSPF Virtual Link
To prove whether the virtual link works, a neighbor relationship between C1 and C2 must reach the FULL state, resulting in all routers in both parts of area 0 having the same area 0 LSDB. Example 7-10 shows the working neighbor relationship, plus status information for the virtual link with the show ip ospf virtual-links command.
Example 7-10OSPF Virtual Link Configuration on Routers C1 and C2
C1# show ip ospf virtual-links Virtual Link OSPF_VL0 to router 4.4.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface FastEthernet0/1, Cost of using 3 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:02 Adjacency State FULL (Hello suppressed) Index 1/2, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec ! ! next, note that the neighbor reaches FULL state, with no DR elected.
C1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 0 FULL/ - - 10.24.1.1 OSPF_VL0 2.2.2.2 1 FULL/DR 00:00:35 10.21.1.2 FastEthernet0/1
C1# show ip ospf neighbor detail 4.4.4.4 Neighbor 4.4.4.4, interface address 10.24.1.1 In the area 0 via interface OSPF_VL0 Neighbor priority is 0, State is FULL, 6 state changes DR is 0.0.0.0 BDR is 0.0.0.0 Options is 0x32 in Hello (E-bit, L-bit, DC-bit) Options is 0x72 in DBD (E-bit, L-bit, DC-bit, O-bit) LLS Options is 0x1 (LR) Neighbor is up for 00:00:21 Index 1/2, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec
The only new command in the example, show ip ospf virtual-links, details some items unique to virtual links. In particular, the first highlighted portion shows the assignment of a name to the link (VL0); if multiple virtual links were configured, each would have a different number. This virtual link name/number is then referenced inside the LSDB. It also shows that the routers both allow the use of the Do Not Age (DNA) bit, so periodic reflooding will not occur over this virtual link. It lists a cost of 3. As it turns out, each of the three interfaces between Router C1 and C2 have an OSPF cost of 1, so C1’s area 1 cost to reach C2 is 3. The output also confirms that the routers have reached a fully adjacent state and are suppressing the periodic Hello messages.
The familiar show ip ospf neighbor command lists a few new items as well. Note that the interface refers to the virtual link “OSPF VL0” instead of the interface, because there is no interface between the neighbors. It also lists no Dead timer, because the neighbors choose to not use the usual Hello/Dead interval process over a virtual link. (Instead, if all the transit area’s routes to reach the router on the other router of the link fail, the virtual link fails.) Finally, the show ip ospf neighbor detail 4.4.4.4 command shows the interesting phrase “In the area 0 via interface OSPF VL0,” confirming that the neighborship does indeed exist in area 0.
Note
OSPF does not require that the RID IP address range be advertised as a route in OSPF. As a result, the RID listed in the area virtual-link command might not be pingable, but the virtual link still works.
Exam Preparation Tasks
Planning Practice
The CCNP ROUTE exam expects test takers to review design documents, create implementation plans, and create verification plans. This section provides some exercises that can help you to take a step back from the minute details of the topics in this chapter, so that you can think about the same technical topics from the planning perspective.
For each planning practice table, simply complete the table. Note that any numbers in parentheses represent the number of options listed for each item in the solutions in Appendix F, “Completed Planning Practice Tables.”
Design Review Table
Table 7-7 lists several design goals related to this chapter. If these design goals were listed in a design document, and you had to take that document and develop an implementation plan, what implementation options come to mind? For any configuration items, a general description can be used, without concern about specific parameters.
Implementation Plan Peer Review Table
Table 7-8 shows a list of questions that others might ask, or that you might think about, during a peer review of another network engineer’s implementation plan. Complete the table by answering the questions.
Table 7-8Notable Questions from This Chapter to Consider During an Implementation Plan Peer Review
Create an Implementation Plan Table
To practice skills useful when creating your own OSPF implementation plan, list in Table 7-9 configuration commands related to the configuration of the following features. You might want to record your answers outside the book and set a goal to complete this table (and others like it) from memory during your final reviews before taking the exam.
Table 7-9Implementation Plan Configuration Memory Drill
Choose Commands for a Verification Plan Table
To practice skills useful when creating your own OSPF verification plan, list in Table 7-10 all commands that supply the requested information. You might want to record your answers outside the book and set a goal to complete this table (and others like it) from memory during your final reviews before taking the exam.
Table 7-10Verification Plan Memory Drill
Note
Some of the entries in this table may not have been specifically mentioned in this chapter but are listed in this table for review and reference.
Review All the Key Topics
Review the most important topics from inside the chapter, noted with the Key Topic icon in the outer margin of the page. Table 7-11 lists a reference of these key topics and the page numbers on which each is found.
Table 7-11Key Topics for Chapter 7
Complete the Tables and Lists from Memory
Print a copy of Appendix D, “Memory Tables,” (found on the CD) or at least the section for this chapter, and complete the tables and lists from memory. Appendix E, “Memory Tables Answer Key,” also on the CD, includes completed tables and lists to check your work.
Define Key Terms
Define the following key terms from this chapter, and check your answers in the glossary:
OSPF Review: This section reviews the OSPF concepts, configuration, and verification commands assumed as prerequisites, specifically those details included in the CCNA Exam’s coverage of OSPF.
