Advanced 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 9. Advanced OSPF Concepts

This chapter covers the following subjects:

Image Route Filtering: This section introduces three separate methods of route filtering with OSPF and discusses the commands to configure two of these methods.

Image Route Summarization: This section examines how OSPF can summarize routes at ABRs and at ASBRs.

Image Default Routes and Stub Areas: This section examines the two main reasons that an enterprise might use default routes and then shows OSPF’s solution to each need: flooding a domain-wide default route and using OSPF stub areas.

Image OSPF version 3: This section introduces the newest version of OSPF, OSPF version 3 (commonly written as OSPFv3). OSPFv3 adds support for the routing of IPv6 traffic. The theory and commands for OSPFv3 Address Family configuration are also covered.

This chapter discusses several features that optimize Open Shortest Path First (OSPF) operations: route filtering, route summarization, default routing, and OSPF stub areas, in addition to the features available in OSPFv3.

Route filtering can be used to purposefully prevent hosts in one part of an internetwork from sending packets to another part. It can also reduce the size of a topology table and IP routing table, reducing both OSPF memory and CPU consumption, plus make the packet-forwarding process run slightly better. Route summarization can also reduce routing protocol and packet forwarding overhead, but with a potential negative effect of creating less-efficient paths through an internetwork.

Additionally, this chapter briefly covers default routing, followed by a discussion of OSPF stub routers. These stub routers can be used to limit the amount of topology data in an area, again reducing overhead.

Finally, this chapter concludes with a look at OSPFv3, including configuration examples. This discussion also introduces the concept of OSPFv3 Address Families and includes configuration and verification examples.

“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 two of these 11 self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 9-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 these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A.

Image

Table 9-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Router B1, an internal router in area 1, displays the following output. The only two ABRs connected to area 1 are performing Type 3 LSA filtering. Which of the following answers is true based on the information in the output from B1?

R1# show ip route 10.1.0.0 255.255.0.0 longer-prefixes
! Legend lines omitted for brevity

10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
O 10.1.2.0/24 [110/658] via 10.10.13.1, 00:00:32, Serial0/0/0.1
O IA 10.1.1.0/24 [110/658] via 10.10.23.2, 00:41:39, Serial0/0/0.2
O IA 10.1.3.0/24 [110/658] via 10.10.23.2, 00:41:39, Serial0/0/0.2

a. A Type 3 LSA for 10.2.2.0/24 was filtered by both ABRs.

b. A Type 3 LSA for 10.1.2.0/24 was not filtered by both ABRs.

c. A Type 3 LSA for 10.1.3.0/24 was not filtered by at least one ABR.

d. A Type 3 LSA for 10.1.1.0/24 was filtered by both ABRs.

2. The following command output was gathered from Router R1, an ABR between area 0 (backbone) and area 1. In this internetwork, area 0 contains all the subnets of Class A network 10.0.0.0. R1’s OSPF process has a distribute list configured. Assuming that the subnets listed in the answers actually exist in area 0, which of the following occurs on Router R1?

R1# sh ip prefix-list
ip prefix-list question: 3 entries
seq 5 deny 10.1.2.0/24 ge 25 le 27
seq 15 deny 10.2.0.0/16 ge 30 le 30
seq 20 permit 0.0.0.0/0 le 32

a. R1 will not create/flood a Type 3 LSA for subnet 10.1.2.0/26 into area 1.

b. R1 will not create/flood a Type 3 LSA for subnet 10.1.2.0/24 into area 1.

c. R1 will not have an OSPF route for subnet 10.1.2.0/26 in its IP routing table.

d. R1 will not have an OSPF route for subnet 10.1.2.0/24 in its IP routing table.

3. Use the same scenario as the previous question, with one change. Instead of the distribute list configured on R1, R1’s OSPF process has an area 1 filter list configured. Again assuming that the subnets listed in the answers actually exist in area 0, which of the following occurs on Router R1?

R1# sh ip prefix-list
ip prefix-list question: 3 entries
seq 5 deny 10.1.2.0/24 ge 25 le 27
seq 15 deny 10.2.0.0/16 ge 30 le 30
seq 20 permit 0.0.0.0/0 le 32

a. R1 will not create/flood a Type 3 LSA for subnet 10.1.2.0/26 into area 1.

b. R1 will not create/flood a Type 3 LSA for subnet 10.1.2.0/24 into area 1.

c. R1 will not have an OSPF route for subnet 10.1.2.0/26 in its IP routing table.

d. R1 will not have an OSPF route for subnet 10.1.2.0/24 in its IP routing table.

4. R1, an ABR between backbone area 0 and area 1, has intra-area routes in area 0 for 10.1.1.0/24, 10.1.2.0/24, and 10.1.3.0/24. These routes have metrics of 21, 22, and 23, respectively. An engineer then adds the area 0 range 10.1.0.0 255.255.0.0 command under the OSPF process of R1. Which of the following are true? (Choose two.)

a. R1 loses and then reestablishes neighborships with all neighbors.

b. R1 no longer advertises 10.1.1.0/24 to neighbors into area 1.

c. R1 advertises a 10.1.0.0/16 route into area 1 with a metric of 23 (largest metric).

d. R1 advertises a 10.1.0.0/16 route into area 1 with a metric of 21 (lowest metric).

5. The following output exists on Router R1, a router internal to area 1. What can you determine as true from the output of the show ip ospf database summary command?

Routing Bit Set on this LSA
LS age: 124
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links (Network)
Link State ID: 10.1.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x878F
Length: 28
Network Mask: /22
TOS: 0 Metric: 11

a. The LSA was created by an ABR because of an area range command.

b. The LSA was created by an ASBR because of a summary-address command.

c. If created by an area range command, the best metric for a subordinate subnet on that ABR must have been 11.

d. None of the other answers are correct.

6. Router R1, an ASBR connected to the Internet and to backbone area 0, has been configured with a default-information originate command. Which of the following is true about the effects of this configuration command?

a. R1 will always create and flood a default route into the OSPF domain.

b. R1 will create and flood an LSA for prefix/length 0.0.0.0/0 into the OSPF domain if R1’s IP routing table has a route to 0.0.0.0/0.

c. R1 will set a flag on the LSA for the subnet between itself and one of the ISPs, noting this subnet as a default network, regardless of whether R1 has a default route.

d. R1 will set a flag on the LSA for the subnet between itself and one of the ISPs, noting this subnet as a default network, but only if R1 has a route to 0.0.0.0/0.

7. Which of the following are true about routers internal to a totally NSSA area? (Choose two.)

a. Routers cannot redistribute external routes into the area.

b. Routers should have zero Type 3 LSAs in their LSDBs.

c. Routers should have zero Type 5 LSAs in their LSDBs.

d. Routers should learn default routes from the ABRs attached to the area.

8. ABR R1 has been configured with an area 1 stub no-summary command. Which stubby area type is area 1?

a. Stub

b. Totally stubby

c. NSSA

d. Totally NSSA

9. With an OSPFv3 Address Family configuration supporting both IPv4 and IPv6 routing, which of the following is true regarding OSPFv3’s link-state database?

a. IPv4 LSAs populate one database, while IPv6 LSAs populate a second database.

b. Information received from all LSAs is aggregated in a single link-state database.

c. OSPFv3 does not use a link-state database. Rather, it represents link-state information in a lookup table similar to Cisco Express Forwarding (CEF).

d. A virtual Address Family is created, and it contains information from both IPv4 and IPv6 LSAs.

10. In an OSPFv3 Address Family configuration, how do you tell an interface to participate in the OSPFv3 process for IPv6 routes?

a. Router(config-router)# ospfv3 process_id ipv6 area area_number

b. Router(config-router-af)# ospfv3 process_id ipv6 area area_number

c. Router(config-router-af-if)# ospfv3 process_id ipv6 area area_number

d. Router(config-if)# ospfv3 process_id ipv6 area area_number

11. Which LSA used in IPv6 networks carries information similar to the information carried by Type 1 and Type 2 LSAs in IPv4 networks?

a. Type 6 LSA

b. Type 8 LSA

c. Type 9 LSA

d. Type 10 LSA

Foundation Topics

Route Filtering

OSPF supports several methods to filter routes. However, the OSPF’s internal logic restricts most filtering, requiring that the filtering be done either on an area border router (ABR) or autonomous system boundary router (ASBR). This same internal logic dictates what each type of filtering can do and what it cannot do. So, when thinking about OSPF route filtering, you need to go beyond the concept of matching IP prefix/length information and consider OSPF internals as well. This first major section begins with a discussion of the OSPF internals that impact OSPF route filtering, followed by information about two of OSPF’s route-filtering tools.

First, consider the difference in how OSPF chooses intra-area versus interarea routes. For intra-area routes, OSPF uses pure link-state logic, with full topology information about an area, piecing together the topology map from the Type 1 and Type 2 LSAs. This logic relies on all routers inside the area having an identical copy of the link-state database (LSDB) for that area. With the full topology, the shortest path first (SPF) algorithm can be run, finding all possible routes to each subnet.

For interarea routes, OSPF uses distance vector logic. The intra-area SPF calculation includes the calculation of the metric of the best route to reach each ABR in the area. To choose the best interarea route, a router uses distance vector logic of taking its known metric to reach the ABR and adds the metric for that subnet as advertised by the ABR. This means that no additional SPF calculation is required to find all interarea routes for a given prefix/length, making this logic more like distance vector logic.

Keeping these thoughts in mind, next consider the concept of route filtering inside one area. First, OSPF routers do not advertise routes; instead, they advertise LSAs. Any filtering applied to OSPF messages would need to filter the transmission of LSAs. However, inside one area, all routers must know all LSAs, or the entire SPF concept fails, and routing loops could occur. As a result, OSPF cannot and does not allow the filtering of LSAs inside an area, specifically the Type 1 and Type 2 LSAs that describe the intra-area topology.

OSPF does allow some route filtering, however, taking advantage of the fact that OSPF uses distance vector logic with Type 3 LSAs (and Type 5 LSAs used for external routes). Because of the underlying distance vector logic, an OSPF ABR can be configured to filter Type 3 LSAs, with no risk of creating routing loops. (The same applies for ASBRs filtering Type 5 LSAs created for external routes.) As a result of these related concepts, Cisco IOS limits OSPF route filtering to the following:

Image Filtering Type 3 LSAs on ABRs

Image Filtering Type 5 LSAs on ASBRs

Image Filtering the routes that OSPF would normally add to the IP routing table on a single router

Of these, the second option occurs as an option of the route redistribution process as explained in Chapter 10, “Route Redistribution.” So, it will not be covered in this chapter. The other two topics will be examined next.

Type 3 LSA Filtering

ABRs, by definition, connect to the backbone area and at least one other area. ABRs, as a fundamental part of their role, create and flood Type 3 Summary LSAs into one area to represent the subnets in the other areas connected to that ABR. Type 3 LSA filtering tells the ABR to filter the advertisement of these Type 3 LSAs.

For example, consider Figure 9-1, which shows a generalized design with two ABR routers. The figure focuses on three subnets in area 0 for which each ABR would normally create and flood a Type 3 Summary LSA into area 1. However, in this case, the engineer has made the following choices:

Image On ABR1, filter subnet 3 from being advertised.

Image On ABR2, filter both subnets 2 and 3 from being advertised.

Image

Figure 9-1 Generic View of Type 3 LSA Filtering

The goal of such a filtering plan could be to prevent all area 1 users from reaching subnet 3 and to allow access to subnet 2—but only through ABR1. If ABR1 were to fail, none of the area 1 routers could calculate a route for subnet 2 through ABR2, because ABR2 has not created and flooded a Type 3 LSA for that subnet. The goal for subnet 1 would be to allow each area 1 router to choose the best route through either ABR, while having a redundant route in case one route failed.

To configure Type 3 LSA filtering, you use the area number filter-list prefix name {in | out} command under router ospf configuration mode. The referenced prefix list matches subnets, with subnets matched by a deny action being filtered, and subnets matched with a permit action allowed through as normal. OSPF then performs the filtering by not flooding the Type 3 LSAs into the appropriate areas.

The trickiest part of the configuration relates to the in and out parameters at the end of the area filter-list router subcommand. These parameters define the direction relative to the area listed in the command, as follows:

Image When in is configured, Cisco IOS filters prefixes being created and flooded into the configured area.

Image When out is configured, Cisco IOS filters prefixes coming out of the configured area.

The need for the in and out parameters makes more sense when you consider an ABR connected to at least three areas. Figure 9-2 shows just such a sample, with both the in and out directions represented.

Image

Figure 9-2 Generic View of Type 3 LSA Filtering

The area 0 filter-list... in command in the figure shows that the ABR considers filtering routes from all other areas (areas 1 and 2, in this case) when creating and flooding Type 3 LSAs into area 0. The area 2 filter-list... out command in the figure shows how the ABR only considers prefixes that exist in area 2. However, in this case, the ABR filters LSAs regardless of the area into which the Type 3 LSAs would be advertised.

For example, consider the case of subnet 111, in area 1. Assume that all prefix lists happen to match subnet 111, so that subnet 111 should be filtered. The following list summarizes what happens on ABR1 regarding the potential advertisement of a Type 3 LSA for this subnet being flooded into areas 0 and 2:

Image ABR1 filters the subnet 111 LSA from being sent into area 0 because of the area 0 filter-list... in command.

Image ABR1 does not filter the subnet 111 LSA from being sent into area 2, because there is no area 1 filter-list... out command nor area 2 filter-list... in command.

As another example, Figure 9-3 shows an example internetwork with three candidate routes to be filtered by ABRs R1 and R2. ABRs R1 and R2 will play the roles of ABR1 and ABR2 in Figure 9-1, with R1 filtering one of the three subnets and R2 filtering two of the subnets. Note that R1 and R2 will each use different in and out keywords as well.

Image

Figure 9-3 Type 3 LSA Filtering Example

Example 9-1 shows the configuration on both R1 and R2.

Example 9-1 R1’s and R2’s distribute-list to Filter Manufacturing Routes


! On Router R1:
ip prefix-list filter-into-area-34 seq 5 deny 10.16.3.0/24
ip prefix-list filter-into-area-34 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 1
area 34 filter-list prefix filter-into-area-34 in


! On Router R2:
ip prefix-list filter-out-of-area-0 seq 5 deny 10.16.2.0/23 ge 24 le 24
ip prefix-list filter-out-of-area-0 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 2
area 0 filter-list prefix filter-out-of-area-0 out


First, take a closer look at the specifics of the R1 configuration commands. The prefix list on R1 exactly matches route 10.16.3.0/24, with a deny action. The second prefix-list command matches all subnets, because the 0.0.0.0/0 parameter matches all subnet numbers, and the le 32 parameter, combined with the original /0 prefix length, matches all prefix lengths from /0 through /32. The area 34... in command tells R1 to apply this filtering to all Type 3 LSAs that R1 creates and would otherwise flood into area 34. As a result, the area 34 LSDB will not contain a Type 3 LSA for 10.16.3.0/24, as injected by R1.

R2’s configuration uses a slightly different prefix list. The filter examines all Type 3 LSAs for subnets in area 0. The first prefix-list command matches all prefixes in the range 10.16.2.0–10.16.3.255 (per the 10.16.2.0/23 parameter) but specifically for a prefix length of exactly 24. This command matches two of the three data center subnets. The second prefix-list command matches all other subnets with the same match-all logic seen earlier on R1, using a permit action. R2’s area 0... out command tells R2 to filter the subnets that R2 learns in area 0 and for which R2 would normally create Type 3 LSAs to flood into all other areas. So, neither area 34 nor area 5 will learn these two filtered subnets (10.16.2.0/24 and 10.16.3.0/24) in Type 3 LSAs from R2.

The end result of this added configuration results in the following Type 3 LSAs for the three subnets shown on the right side of Figure 9-3:

Image Two Type 3 LSAs for 10.16.1.0/24 (created by R1 and R2, respectively)

Image One Type 3 LSA for 10.16.2.0/24 (created by R1)

Image None for 10.16.3.0/24

Example 9-2 confirms the contents of the LSDB in area 34, on Router R3.

Example 9-2 Area 34 LSDB, as Seen on R3


R3# show ip route 10.16.0.0 255.255.0.0 longer-prefixes
! Legend lines omitted for brevity

10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
O IA 10.16.2.0/24 [110/658] via 10.10.13.1, 00:00:32, Serial0/0/0.1
O IA 10.16.1.0/24 [110/658] via 10.10.23.2, 00:41:39, Serial0/0/0.2
[110/658] via 10.10.13.1, 00:00:32, Serial0/0/0.1

R3# show ip ospf database | include 10.16
10.16.1.0 1.1.1.1 759 0x80000002 0x008988
10.16.1.0 2.2.2.2 745 0x80000002 0x006BA2
10.16.2.0 1.1.1.1 759 0x80000002 0x007E92


The first command in the example lists R3’s routes for all subnets whose first two octets are 10.16. Note that R3 has no route to 10.16.3.0/24, because both R1 and R2 filtered the Type 3 LSA. R3 happens to have equal-cost routes for 10.16.1.0/24, which is possible, because both R1 and R2 permitted the advertisement of the Type 3 LSA for that subnet. R3 has only one route for 10.16.2.0/24, through R1, because R2 filtered its Type 3 LSA for that prefix.

The second command in Example 9-2 lists all LSAs that include “10.16,” which includes the two Type 3 LSAs for 10.16.1.0/24 and the single Type 3 LSA for 10.16.2.0/24.

Finally, note that although the configuration in Example 9-1 showed area filter-list commands with both in and out parameters for variety, the result of R2’s area filter-list... out command is that R2 does not flood the filtered LSAs to either area 34 or area 5. If the design goals specifically meant to filter only LSAs from being advertised from area 0 into area 34, the area 34 filter-list... in command should have been used on both routers.

Filtering OSPF Routes Added to the Routing Table

In some cases, an engineer might need to filter a route, but the area design does not lend itself well to his filtering goals. For example, if an area has 20 routers and the engineer wants to filter a route so that five of the routers do not learn the route, Type 3 LSA filtering cannot be used. Type 3 LSA filtering can only filter the LSAs from being flooded throughout the entire area.

The next feature discussed in this section, referenced as filtering with distribute lists (based on the configuration command it uses), allows individual routers to filter OSPF routes from getting into their respective IP routing tables. This type of filtering injects logic between the SPF algorithm on a router and that same router’s IP routing table. This feature does not change the LSDB flooding process, does not change the LSAs added by ABRs or ASBRs, and does not change the SPF algorithm’s choice of best route. However, when SPF chooses routes to add to the IP routing table, if a router has been configured with a distribute-list in router subcommand, enabling this feature, that router then filters the routes before adding them to that router’s IP routing table. Figure 9-4 shows the general idea.

Image

Figure 9-4 OSPF Filtering with Distribute Lists

In effect, you could prevent an OSPF route from being added to one or more routers’ routing tables, but without risking causing routing loops, because the intra-area LSDB topology remains intact. By filtering routes from being added to the IP routing table, you prevent the routers from forwarding packets to the filtered subnets, but presumably that’s the intended goal of route filtering.

The mechanics of the distribute-list router subcommand have a few surprises, which are summarized in this list:

Image The command requires either an in or out direction. Only the in direction works for filtering routes as described in this section.

Image The command must refer to either a numbered access control list (ACL), named ACL, prefix list, or route map. Regardless, routes matched with a permit action are allowed into the IP routing table, and routes matched with a deny action are filtered.

Image Optionally, the command can include the interface interface-name-and-number parameters. The router compares these parameters to the route’s outgoing interface.

Example 9-3 shows a sample configuration on Router R3 from Figure 9-3. In this case, all filtering listed in Examples 9-1 and 9-2 has been removed, so no routes or LSAs have been filtered. Then, the engineer adds the distribute-list command on R3 to filter the route for 10.16.1.0/24, based on prefix-list filter-1.

Example 9-3 R3’s distribute-list to Filter 10.16.1.0/24


! On Router R3:
ip prefix-list filter-1 seq 5 deny 10.16.1.0/24
ip prefix-list filter-1 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 3
distribute-list prefix filter-1 in
!
R3# show ip route ospf | include 10.16.1
R3#
R3# show ip ospf database | include 10.16.1.0
10.16.1.0 1.1.1.1 1143 0x80000007 0x007F8D
10.16.1.0 2.2.2.2 1538 0x80000007 0x0061A7


Note that the configuration matches only prefix 10.16.1.0/24 with a deny clause and permits all other routes. As a result, OSPF on R3 does not add a route for subnet 10.16.1.0/24 to the IP routing table, as implied by the null output of the show ip route ospf | include 10.16.1 command. Theshow ip ospf database | include 10.16.1 command lists all LSAs that have 10.16.1 in the text output, showing the two Type 3 LSAs for the subnet.

Route Summarization

OSPF allows summarization at both ABRs and ASBRs but not on other OSPF routers. The main reason is again that the LSDB must be the same for all routers in a single area. So, if summarization is needed, the summary prefixes should be created at the edge of an area (ABR or ASBR) and flooded throughout that area. However, the idea of summarizing on a router internal to an area, hoping that some routers in the area use the summary route and others in the same area do not, cannot be done with OSPF.

Good planning of route summaries can overcome the restriction of performing the summarization only on ABRs and ASBRs. A good OSPF area design includes consideration of future address summaries, and a good OSPF route summarization design considers the ABR locations. Although it is rare to design a large internetwork from scratch, an addressing plan that assigns all or most subnets in an area from one large address block does make address summarization easier.

OSPF summarization differs slightly on ABRs versus ASBRs. This section first examines route summarizations on ABRs and then considers ASBRs.

Manual Summarization at ABRs

The more difficult task with OSPF route summarization occurs when planning the design of IP address blocks and OSPF areas. When the IP addressing plan and OSPF design have been completed, if the subnet numbers inside an area happen to be from the same general range, and none of the subnets in that range exist in other OSPF areas, a reasonable summary route can be created at the ABRs connected to that area. Without first having such a reasonable block of addresses, route summarization might not be a useful option.

After a range of subnets has been chosen for summarization, the parameters in the area range command must be planned. This command defines the parameters for the summary route, most notably the origin area from which the subnets exist and the subnet number/mask that defines the summary route that should be advertised. The generic version of the command is listed next, followed by some notes about the various parameters:

area area-id range ip-address mask [cost cost]

Image

Image The configured area number refers to the area where the subnets exist; the summary will be advertised into all other areas connected to the ABR.

Image The ABR compares the summary route’s range of addresses with all intra-area OSPF routes, in the origin area, for which the ABR is creating Type 3 LSAs. If at least one subordinate subnet exists (subnets that sit inside the range), the ABR advertises the summary route as a Type 3 LSA.

Image The ABR does not advertise the subordinate subnet’s Type 3 LSAs.

Image The ABR assigns a metric for the summary route’s Type 3 LSA, by default, to match the best metric among all subordinate subnets.

Image The area range command can also explicitly set the cost of the summary.

Image If no subordinate subnets exist, the ABR does not advertise the summary.

For example, Figure 9-3 (shown earlier in this chapter) lists three subnets on the right side of the figure, noted as data center subnets 10.16.1.0/24, 10.16.2.0/24, and 10.16.3.0/24. ABR R1 could be configured to summarize these routes as 10.16.0.0/22, which includes all three subnets. (10.16.0.0/22 implies a range from 10.16.0.0 to 10.16.3.255.) The ABRs (R1 and R2) could be configured to advertise a summary route using the area 0 range 10.16.0.0 255.255.252.0 router subcommand.

Behind the scenes, ABR route summarization causes the ABR to no longer advertise the subordinate routes’ Type 3 LSAs, but to instead advertise one Type 3 LSA for the summary prefix. Figure 9-5 shows this concept on ABR R1, assuming that the area 0 range 10.16.0.0 255.255.252.0router subcommand has been configured. The three Type 3 LSAs that would normally have been advertised are shown above the ABR, and the one Type 3 LSA for the summary route, which replaces the upper LSAs, is shown under the ABR.

Image

Figure 9-5 OSPF Area Summarization—Consolidating Type 3 LSAs

Example 9-4 shows some show command output related to this example. All route filtering in earlier examples has been removed, and both R1 and R2 have configured OSPF to summarize 10.16.0.0/22 with the area 0 range 10.16.0.0 255.255.252.0 router OSPF subcommand. However, in R2’s case, the metric 12 parameter was used.

Example 9-4 R1/R2/R3’s Area Summarization on 10.16.0.0/16


! On Router R1, before the summarization:
R1# sh ip route ospf | incl 10.16
O 10.16.2.0/24 [110/12] via 10.10.17.7, 00:00:24, FastEthernet0/0
O 10.16.3.0/24 [110/13] via 10.10.17.7, 00:00:24, FastEthernet0/0
O 10.16.1.0/24 [110/11] via 10.10.17.7, 00:00:34, FastEthernet0/0

! Next, configuring the summarization:
router ospf 1
area 0 range 10.16.0.0 255.255.252.0


! Next, on R2, configuring the same summary
router ospf 2
area 0 range 10.16.0.0 255.255.252.0 cost 12


! Next, from R3
R3# show ip ospf database summary 10.16.0.0

OSPF Router with ID (3.3.3.3) (Process ID 3)

Summary Net Link States (Area 34)

Routing Bit Set on this LSA
LS age: 124
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.16.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x878F
Length: 28
Network Mask: /22
TOS: 0 Metric: 11

LS age: 103
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.16.0.0 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x739E
Length: 28
Network Mask: /22
TOS: 0 Metric: 12

R3# show ip route 10.16.0.0 255.255.0.0 longer-prefixes
! legend omitted for brevity

10.0.0.0/8 is variably subnetted, 16 subnets, 4 masks
O IA 10.16.0.0/22 [110/658] via 10.10.13.1, 00:03:46, Serial0/0/0.1


The example demonstrates the theory of what happens behind the scenes. R3 lists only two Type 3 LSAs related to the 10.16.1.0/24, 10.16.2.0/24, and 10.16.3.0/24 subnets: the Type 3 LSAs created by R1 and R2 for 10.16.0.0/22. However, the output does not denote that this LSA represents a summarized route. It simply looks like yet another Type 3 LSA. (Any mention of the word “summary” in the output refers to the fact that Type 3 LSAs are called Summary LSAs.) In this case, R3’s path to reach both R1 and R2 ties, but the LSA for R1’s 10.16.0.0/22 summary was injected with metric 11, based on the lowest metric subordinate route on R1, whereas R2’s uses the explicitly configured metric 12. As a result, R3’s best route for 10.16.0.0/22 uses R1, as shown in the route at the end of the example.

The first show command in the example shows R1’s metrics for the three subordinate subnets, specifically metrics 11, 12, and 13. As such, R1’s summary for 10.16.0.0/22, as shown in R3’s show ip ospf database summary 10.16.0.0 command, confirms that, by default, R1 gave the summary route’s Type 3 LSA the best metric among the component subnets.


Note

Although not discussed in depth here, the optional not-advertise option on the area range command tells the ABR to not advertise the Type 3 LSA for the summary route, making it possible to do the equivalent of Type 3 LSA filtering with the area range command.


Manual Summarization at ASBRs

OSPF defines an ASBR as a router that redistributes routes into OSPF from some other routing sources. When redistributing the routes, the ASBR creates a Type 5 External LSA for each redistributed subnet, listing the subnet number as the LSID and listing the mask as one of the fields in the LSA. The LSA also lists the ASBR’s RID as the advertising router and a cost metric for the route. For the purposes of route summarization, you can think of a Type 5 LSA as working much like a Type 3 LSA, except for routes learned externally.

This section describes ASBR route summarization, which has many similarities to summarization by an ABR. If you add the summary-address prefix mask OSPF subcommand, OSPF will then attempt to summarize the external routes by creating a Type 5 LSA for the summary route, and by no longer advertising the Type 5 LSAs for the subordinate subnets. When looking for potential subordinate subnets inside the summary, the ASBR looks at all routes being redistributed into OSPF from all outside route sources, and if any subordinate subnets exist, the ASBR performs the route summarization.

Notably, this command works very much like the area range command on ABRs, with the main exception being that the summary-address command cannot explicitly set the metric of the summary route. The list of features is as follows:

Image

Image The ASBR compares the summary route’s range of addresses with all routes redistributed into OSPF on that ASBR to find any subordinate subnets (subnets that sit inside the summary route range). If at least one subordinate subnet exists, the ASBR advertises the summary route.

Image The ASBR does not advertise the subordinate subnets.

Image To create the summary, the ASBR actually creates a Type 5 LSA for the summary route.

Image The ASBR assigns the summary route the same metric as the lowest metric route among all subordinate subnets.

Image If no subordinate subnets exist, the ASBR does not advertise the summary.

Image Unlike the area range command, the summary-address command cannot be used to directly set the metric of the summary route.

The summary-address subcommand defines the summary route on the ASBR, with similar syntax and parameters as compared to the area range command seen on ABRs. Table 9-2 lists the two commands for comparison and study.

Image

Image

Table 9-2 OSPF Route Summarization Commands

Default Routes and Stub Areas

Enterprises typically use default routes in two different cases:

Image To direct remote-site routers at the edge of the enterprise network to send all packets toward the core of the enterprise, with the core routers knowing all the more-specific routes to enterprise destination addresses

Image To direct traffic on all enterprise routers toward an Internet-facing router so that all traffic destined for the Internet eventually arrives at the enterprise’s Internet-connected routers

Engineers could achieve both of these goals by using route summarization with the area range and summary-address commands. For example, consider a case in which the goal is to drive all packets destined for Internet hosts to one of two equal Internet routers for an enterprise, as shown in Figure 9-6. The design shows two ASBRs connected to the Internet. Both ASBRs could learn routes with Border Gateway Protocol (BGP). Rather than redistribute all BGP routes into the enterprise, the ASBRs summarize to the ultimate summary, 0.0.0.0/0. The two OSPF ASBRs flood the Type 5 LSA for a summary route—one from ASBR1 and one from ASBR2—throughout the enterprise. As a result, all OSPF routers choose a default route, with the packets destined for locations in the Internet eventually reaching one of the two ASBRs, which then forwards the packets into the Internet.

Image

Figure 9-6 Using ASBR Route Summarization to Advertise Summary Routes

To meet the other design goal for using defaults—to get the routers in an area to use default routing to deliver packets to an ABR—the ABR could use the area range command to flood a default route into a single area. Again in Figure 9-6, if the design called for the routers in area 1 to use a default route to reach other destinations in the enterprise, the ABRs connected to area 1, like ABR1, could use the area 0 range 0.0.0.0 0.0.0.0 command. ABR1 would then advertise a default route into the area, as an LSA Type 3, and not advertise any of the other Type 3 LSAs known from area 0. The routers internal to area 1 would use their default route for packets destined to unknown destination addresses, but the ABRs would have full knowledge of the routes inside the enterprise and know how to forward the packets at that point.

Even though you can use the summary-address and area range commands, most engineers use other methods to introduce and control default routes inside an OSPF domain. The first tool, the default-information originate OSPF subcommand, introduces a default route to be flooded throughout the OSPF domain. As a result, it is most useful for default routing to draw packets toward ASBRs connected to external networks. The other tool, stub areas, focuses on the other common use of default routes, controlling when ABRs flood default routes into a given area. This section examines both topics.

Domain-Wide Defaults Using the default-information originate Command

The OSPF subcommand default-information originate tells OSPF to create a Type 5 LSA (used for external routes) for a default route—0.0.0.0/0—and flood it like any other Type 5 LSA. In other words, it tells the router to create and flood information about a default route throughout the OSPF domain.

For example, consider a typical single multihomed Internet design, as shown in Figure 9-7. In this case, the enterprise has two Internet-connected routers, and the engineer wants to use default routing inside the enterprise to cause all the enterprise routers to send packets toward either ASBR1 or ASBR2.

Image

Figure 9-7 Single Multihomed Internet Design Using Default Routes

The default-information originate command tells the ASBRs to flood a default route into OSPF, but only if the ASBR itself has a default route in its IP routing table. This logic relies on the fact that the ASBRs typically either have a static default route pointing to the connected ISP router, or they learn a default route from the ISP using BGP. (In Figure 9-7, each ISP is advertising a default route.) All the routers then learn a default route, based on the Type 5 LSAs for 0.0.0.0/0 as flooded by the ASBRs.

Because a router withdraws its OSPF default route when its own IP route to 0.0.0.0/0 fails, OSPF allows the design in Figure 9-7 to fail over to the other default route. When all is well, both ISP1 and ISP2 advertise a default route to the enterprise using BGP, so both ASBR1 and ASBR2 have a route to 0.0.0.0/0. As shown in the figure, ASBR2 has been configured to advertise its OSPF default with a lower metric (1) than does ASBR1 (metric 30). Therefore, the enterprise routers will forward traffic to the Internet through ASBR2. However, if ISP1 quits advertising that default with BGP, or if BGP fails between ASBR2 and ISP1’s I1-1 router, ASBR2 will withdraw its OSPF default route. The only remaining OSPF default route will be the one that leads to ASBR1, making use of the backup default route.

The full command syntax, as shown here, provides several optional parameters that impact its operation:

default-information originate [always] [metric metric-value] [metric-type type-
value
] [route-map map-name]

The following list summarizes the features of the default-information originate OSPF subcommand:

Image With all default parameters, it injects a default route into OSPF, as an External Type 2 route, using a Type 5 LSA, with metric 1, but only if a default route exists in that router’s routing table.

Image With the always parameter, the default route is advertised even if there is no default route in the router’s routing table.

Image The metric keyword defines the metric listed for the default route (default 1).

Image The metric-type keyword defines whether the LSA is listed as external Type 1 or external Type 2 (default).

Image The decision of when to advertise, and when to withdraw, the default route is based on matching the referenced route-map with a permit action.

When configured, OSPF will flood the default route throughout the OSPF routing domain, drawing traffic to each ASBR, as shown earlier in Figure 9-6.


Note

The type of external OSPF route (Type 1 or Type 2) is explained more fully in Chapter 10.


Stubby Areas

As mentioned earlier, the two most common reasons to consider using default routes are to drive all Internet-destined traffic toward Internet-connected routers in an enterprise and to drive traffic inside an area toward an ABR in that area. This second design choice allows the routers in an area to use default routes for forwarding packets to ABRs, rather than more specific routes. Using default routes inside an area reduces memory consumption and CPU processing time on routers inside the area, because the routers in that area can have fewer LSAs in their LSDBs.

The OSPF stub router feature provides engineers with a very simple way to enable the function of flooding default routes inside an area, with those default routes driving IP packets back toward the ABRs attached to that area. ABRs in stub areas advertise a default route into the stub area. At the same time, the ABR chooses to not advertise external routes (Type 5 LSAs) into the area. Similarly, the ABR chooses to not advertise interarea routes (in Type 3 LSAs) into the area. As a result, all routers in the stub area can still route to the destinations (based on default route information), and the routers require less memory and processing.

The following list summarizes these features of stub areas for easier study and review:

Image ABRs create a default route, using a Type 3 LSA, listing subnet 0.0.0.0 and mask 0.0.0.0, and flood that into the stub area.

Image ABRs do not flood Type 5 LSAs into the stub area.

Image ABRs might not flood other Type 3 LSAs into the area.

Image The default route has a metric of 1 unless otherwise configured using the router subcommand area area-num default-cost cost.

Image Routers inside stub areas cannot redistribute external routes into the stubby area, because that would require a Type 5 LSA in the area.

Image All routers in the area must be configured to be stubby; if not, neighbor relationships cannot form between potential neighbors based on this mismatched configuration.

Figure 9-8 shows a familiar design in which area 34 will become a stub area. The design shows three external routes and lists three of many internal routes inside area 0. The figure shows ABRs R1 and R2 advertising defaults into area 34.

Image

Figure 9-8 Stubby Area Design

Figure 9-8 demonstrates the core feature common to all types of stub areas: The ABRs flood a default route into the area. The routers inside the area can then calculate their best default route. Next, the text examines the different types of OSPF areas, before moving on to the details of configuration and verification.

Introducing Stubby Area Types

Even within the realm of stubby areas, four types of stubby areas exist: stub, totally stubby, not-so-stubby areas (NSSA), and totally NSSA.

Two types of stubby areas have the word “totally” as part of the name, and two do not. The differences between those with the word “totally” and those without have to do with whether Type 3 LSAs are flooded into the area. The rules are

Image For all types of stubby areas, the ABR always filters Type 5 (external) LSAs.

Image For totally stubby and totally NSSA areas, the ABR also filters Type 3 LSAs.

Image For stubby and NSSA areas—those without the word “totally” in the name—the ABRs do not filter Type 3 LSAs, advertising Type 3 LSAs as normal.

For example, consider the diagram shown in Figure 9-8, with area 34 as simply a stub area. As for all types, the ABRs each advertise a default route into area 34. As for all stubby area types, the ABRs filter all Type 5 LSAs, which means that the three Type 5 LSAs for 11.11.0.0/16, 11.12.0.0/16, and 11.13.0.0/16 would not exist in the LSDBs for area 34. Finally, because the area is not a totally stubby area, the ABRs do create and flood Type 3 LSAs for interarea routes as usual. So, they flood LSAs for the 10.16.11.0/24, 10.16.12.0/24, and 10.16.13.0/24 subnets listed in the figure.

Next, consider a similar scenario but with a totally stubby area for area 5, as seen back in Figure 9-3. As for all stubby area types, the ABRs each advertise a default route into area 5. As for all stubby area types, the ABRs filter all Type 5 LSAs, which means that the three Type 5 LSAs for 11.11.0.0/16, 11.12.0.0/16, and 11.13.0.0/16 would not exist in the LSDBs for area 5. The key difference exists in that the ABRs also would not create and flood Type 3 LSAs for interarea routes as usual, so they would not advertise Type 3 LSAs for the 10.16.11.0/24, 10.16.12.0/24, and 10.16.13.0/24 subnets listed in the figure into area 5.

The other difference in stubby area types relates to whether the name uses NSSA (NSSA or totally NSSA) or not (stubby, totally stubby). Stubby area types that use the NSSA name can redistribute external routes into the area; stubby area types without NSSA in the name cannot.

Configuring and Verifying Stubby Areas

Configuring stub and totally stubby areas requires only three commands, but with at least one command on each router, as listed in Table 9-3.

Image

Image

Table 9-3 Stub Area Configuration Options


Note

For totally stubby areas, only the ABRs must have the no-summary keyword on the area area-id stub no-summary command. However, including this keyword on internal routers does not cause a problem.


Figure 9-9 shows a more detailed view of area 34 from Figure 9-8. By making area 34 a stub area, ABRs R1 and R2 will not flood Type 3 LSAs into area 34—other than the Type 3 LSAs for the default routes. Example 9-5 shows the configuration on Routers R1, R2, and R3 from Figure 9-9.

Image

Figure 9-9 Detailed View of Area 34

Example 9-5 Stub Area Configuration


! On Router R1:
router ospf 1
area 34 stub
auto-cost reference-bandwidth 1000
!
interface s0/0/0.3 point-to-point
ip ospf 1 area 34
!
interface s0/0/0.4 point-to-point
ip ospf 1 area 34


! On Router R2:
router ospf 2
area 34 stub
auto-cost reference-bandwidth 1000
!
interface s0/0/0.3 point-to-point
ip ospf 2 area 34
!
interface s0/0/0.4 point-to-point
ip ospf 2 area 34


! On Router R3:
router ospf 3
area 34 stub
auto-cost reference-bandwidth 1000
!
interface s0/0/0.1 point-to-point
ip ospf 3 area 34
ip ospf 3 cost 500
!
interface s0/0/0.2 point-to-point
ip ospf 3 area 34
!
interface fa0/0
ip ospf 3 area 34


With the configuration as shown, both R1 and R2 will inject a default route, represented as a Type 3 LSA, with default metric 1. They will also not flood the Type 5 LSAs into area 34. Example 9-6 confirms these facts, showing the Type 3 LSA for the summary, and the absence of Type 5 LSAs in the output of the show ip ospf database command on Router R3.

Example 9-6 Evidence of Type 5 LSAs Existing, Disappearing, and Defaults Appearing


! Before making Area 34 stubby:

R3# show ip ospf database | begin AS External
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
11.11.0.0 7.7.7.7 929 0x80000001 0x00016D 0
12.12.0.0 7.7.7.7 845 0x80000001 0x00E784 0
13.13.0.0 7.7.7.7 835 0x80000001 0x00CE9B 0

! After making area 34 stubby – no output from the next command.

R3# show ip ospf database | begin AS External
R3#

! The database for area 34 now has two Type 3 LSAs for default routes.
R3# show ip ospf database

OSPF Router with ID (3.3.3.3) (Process ID 3)

Router Link States (Area 34)

! Lines omitted for brevity – skipped to "Summary Net" (Type 3) section

Summary Net Link States (Area 34)

Link ID ADV Router Age Seq# Checksum
0.0.0.0 1.1.1.1 692 0x80000001 0x0093A6
0.0.0.0 2.2.2.2 686 0x80000001 0x0075C0
10.10.5.0 1.1.1.1 692 0x8000000E 0x00445C
10.10.5.0 2.2.2.2 686 0x8000000F 0x002477
10.10.12.0 1.1.1.1 692 0x8000000E 0x0054AF
10.10.12.0 2.2.2.2 686 0x8000000E 0x0036C9
! Many Type 3 LSAs omitted for brevity's sake


Example 9-6 shows the existence of the Type 5 external LSAs before area 34 became a stubby area, and the disappearance of those same LSAs after it was made a stubby area. The show ip ospf database command then shows two LSAs that list default routes, one learned from RID 1.1.1.1 (R1) and one learned from RID 2.2.2.2 (R2).

Example 9-7 continues the verification of how stub areas work with three more commands.

Example 9-7 Three External Routes Before and None After Changing to Stubby


! Next, R3 confirms it thinks area 34 is a stub area
R3# show ip ospf
Routing Process "ospf 3" with ID 3.3.3.3
Start time: 00:00:38.756, Time elapsed: 07:51:19.720
! lines omitted for brevity
Area 34
Number of interfaces in this area is 3
It is a stub area
Area has no authentication
SPF algorithm last executed 00:11:21.640 ago
SPF algorithm executed 18 times
Area ranges are
Number of LSA 29. Checksum Sum 0x0D3E01
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

! The next command shows all Type 3 (summary) LSAs of prefix 0.0.0.0

R3# show ip ospf database summary 0.0.0.0

OSPF Router with ID (3.3.3.3) (Process ID 3)

Summary Net Link States (Area 34)

Routing Bit Set on this LSA
LS age: 879
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 0.0.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x93A6
Length: 28
Network Mask: /0
TOS: 0 Metric: 1

LS age: 873
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 0.0.0.0 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x75C0
Length: 28
Network Mask: /0
TOS: 0 Metric: 1
! The next command lists statistics of the number of LSAs of each type –
! note a total of 0 Type 5 LSAs, but many Type 3 LSAs

R3# show ip ospf database database-summary

OSPF Router with ID (3.3.3.3) (Process ID 3)

Area 34 database summary
LSA Type Count Delete Maxage
Router 4 0 0
Network 1 0 0
Summary Net 24 0 0
Summary ASBR 0 0 0
Type-7 Ext 0 0 0
Prefixes redistributed in Type-7 0
Opaque Link 0 0 0
Opaque Area 0 0 0
Subtotal 29 0 0

Process 3 database summary
LSA Type Count Delete Maxage
Router 4 0 0
Network 1 0 0
Summary Net 24 0 0
Summary ASBR 0 0 0
Type-7 Ext 0 0 0
Opaque Link 0 0 0
Opaque Area 0 0 0
Type-5 Ext 0 0 0
Prefixes redistributed in Type-5 0
Opaque AS 0 0 0
Non-self 28
Total 29 0 0


Following are the three commands in Example 9-7, in order:

Image show ip ospf: Confirms with one (highlighted) line that the router believes the area is a stub area.

Image show ip ospf database summary 0.0.0.0: By definition, this command lists all summary (Type 3) LSAs with a prefix of 0.0.0.0. It lists two such LSAs, created by R1 and R2 (RIDs 1.1.1.1 and 2.2.2.2, respectively), both with metric 1 (the default setting).

Image show ip ospf database database-summary: This command lists statistics about the numbers of and types of LSAs in the database. The counters show 0 Type 5 LSAs, and several Type 3 LSAs—confirming that the area, while stubby, is not totally stubby.

Configuring and Verifying Totally Stubby Areas

Configuring totally stubby areas requires almost no additional effort as compared with stubby areas. As listed earlier in Table 9-3, the only difference for totally stubby configuration versus stubby configuration is that the ABRs include the no-summary keyword on the area stub command. (no-summary refers to the fact that ABRs in totally stubby areas do not create/flood Type 3 summary LSAs.)

Example 9-7 shows another example configuration, this time with area 34 as a totally stubby area. Additionally, the default routes’ metrics have been set so that both R3 and R4 will use R1 as their preferred ABR, by setting R2’s advertised summary to a relatively high metric (500). Example 9-8 just shows the changes to the configuration shown in Example 9-4.

Example 9-8 Totally Stubby Area Configuration


! On Router R1:
router ospf 1
area 34 stub no-summary
auto-cost reference-bandwidth 1000

! On Router R2:
router ospf 2
area 34 stub no-summary
area 34 default-cost 500
auto-cost reference-bandwidth 1000


The configuration of a totally stubby area reduces the size of the LSDB in area 34, because the ABRs no longer flood Type 3 LSAs into area 34, as shown in Example 9-9. R3 displays its LSDB, listing only two Summary (Type 3) LSAs—the two default routes advertised by the two ABRs, respectively. No other Type 3 LSAs exist, nor do any external (Type 5) or ASBR summary (Type 4) LSAs.

Also, note that the example lists the OSPF routes known to R3. Interestingly, in the topology shown for area 34, R3 learns only three OSPF routes: the two intra-area routes for the subnets between R4 and the two ABRs plus the best default route. The default route has a metric of 501, based on R3’s S0/0/0.1 interface cost plus the cost 1 listed for R1’s Type 3 LSA for the default route.

Example 9-9 Confirmation of the Effects of a Totally Stubby Area


R3# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.10.13.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.10.13.0/29 is directly connected, Serial0/0/0.1
O 10.10.14.0/29 [110/657] via 10.10.34.4, 00:57:37, FastEthernet0/0
C 10.10.23.0/29 is directly connected, Serial0/0/0.2
O 10.10.24.0/29 [110/657] via 10.10.34.4, 00:57:37, FastEthernet0/0
C 10.10.34.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/501] via 10.10.13.1, 00:24:35, Serial0/0/0.1

R3# show ip ospf database database-summary

OSPF Router with ID (3.3.3.3) (Process ID 3)
! lines omitted for brevity

Process 3 database summary
LSA Type Count Delete Maxage
Router 4 0 0
Network 1 0 0
Summary Net 2 0 0
Summary ASBR 0 0 0
Type-7 Ext 0 0 0
Opaque Link 0 0 0
Opaque Area 0 0 0
Type-5 Ext 0 0 0
Prefixes redistributed in Type-5 0
Opaque AS 0 0 0
Non-self 6
Total 7 0 0

R3# show ip ospf database | begin Summary
Summary Net Link States (Area 34)

Link ID ADV Router Age Seq# Checksum
0.0.0.0 1.1.1.1 1407 0x80000003 0x008FA8
0.0.0.0 2.2.2.2 1506 0x80000004 0x00FF3E


Following are the three commands in Example 9-9, in order:

Image show ip route: It lists a single interarea route—a default route, with destination 0.0.0.0/0. The output also lists this same next-hop information as the gateway of last resort.

Image show ip ospf database database-summary: The statistics still show no external Type 5 LSAs, just as when the area was stubby, but now show only two Type 3 LSAs, whereas before, several existed.

Image show ip ospf database | begin Summary: This command shows the output beginning with the Type 3 Summary LSAs. It lists two default route LSAs: one from R1 and one from R2.

Examples 9-7 and 9-9 demonstrate the key differences between stub areas (they do see Type 3 LSAs) and totally stubby areas (which do not see Type 3 LSAs). Next, this section looks at the different types of not-so-stubby areas.

The Not-So-Stubby Area (NSSA)

Stub and totally stubby areas do not allow external routes to be injected into a stubby area—a feature that originally caused some problems. The problem is based on the fact that stub areas by definition should never learn a Type 5 LSA, and OSPF injects external routes into OSPF as Type 5 LSAs. These two facts together mean that a stubby area could not normally have an ASBR that was injecting external routes into the stub area.

The not-so-stubby area (NSSA) option for stubby areas overcomes the restriction on external routes. The solution itself is simple: Because stubby areas can have no Type 5 LSAs, later OSPF RFCs defined a newer LSA type (Type 7) that serves the same purpose as the Type 5 LSA, but only for external routes in stubby areas. So, an NSSA area can act just like a stub area, except that routers can inject external routes into the area.

Figure 9-10 shows an example, with four steps. The same stubby area 34 from the last few figures still exists; it does not matter at this point whether area 34 is totally stubby or simply stubby.

Image

Figure 9-10 External Routes in an NSSA (34)

The steps labeled in the figure are as follows:

Step 1. ASBR R3 learns routes from some external source of routing information, in this case, EIGRP from R9.

Step 2. An engineer configures route redistribution using the redistribute command, taking the routes learned with EIGRP and injecting them into OSPF.

Step 3. R3 floods Type 7 LSAs throughout stub area 34.

Step 4. ABRs R1 and R2 then create Type 5 LSAs for the subnets listed in the Type 7 LSAs, and flood these Type 5 LSAs into other areas, like area 0.

Configuring NSSA works much like the configuration of stubby areas. For totally NSSAs, configure area area-number nssa no-summary instead of area area-number stub no-summary. For normal NSSAs, as with stub areas, omit the no-summary keyword. Additionally, normal NSSAs require that ABRs have the default-information-originate keyword specified, making the command on ABRs area area-number nssa default-information-originate.

Example 9-10 shows a sample with the configuration of a totally NSSA 34 from the network represented in the last four figures. Note that as with the area stub command, the area nssa command’s no-summary option is required only on the ABRs.

Example 9-10 Totally NSSA Configuration and Verification


! On Router R1:
router ospf 1
area 34 nssa no-summary


! On Router R2:
router ospf 2
area 34 nssa no-summary
area 34 default-cost 500


! On Router R3:
router ospf 3
area 34 nssa


! On Router R4:
router ospf 4
area 34 nssa


The same verification steps and commands can be used for NSSAs as were shown in the earlier examples for stub areas. In particular, the show ip ospf command states that the area is an NSSA. You can also see Type 7 LSAs in the OSPF LSDB after redistribution has been configured.

Table 9-4 summarizes the key points regarding stubby areas.

Image

Image

Table 9-4 OSPF Stubby Area Types


Note

Both types of totally stubby areas (totally stubby, totally NSSA) are Cisco proprietary.


OSPF Version 3

The OSPF discussions thus far in this book focused on OSPF version 2 (OSPFv2). While OSPFv2 is feature-rich and widely deployed, it does have one major limitation in that it does not support the routing of IPv6 networks. Fortunately, OSPF version 3 (OSPFv3) does support IPv6 routing, and it can be configured to also support IPv4 routing.

This section discusses two OSPFv3 configuration options:

Image The traditional approach

Image The OSPF Address Family approach

The OSPF Address Family configuration approach is somewhat similar to Named EIGRP configuration, where you can have an IPv4 Address Family and an IPv6 Address Family hierarchically configured under the same routing protocol instance.

This section begins by discussing some of the similarities and differences between OSPFv2 and OSPFv3. Then, the traditional OSPFv3 configuration is presented, followed by an explanation of the OSPF Address Family approach.

OSPFv2 and OSPFv3 Comparison

OSPFv3 bears many similarities to OSPFv2. For example, they both use interface cost as their metric; the same network types exist (that is, broadcast, point-to-point nonbroadcast, multiaccess, and virtual links); the same packet types are used; and LSAs behave in much the same way.

However, a couple of OSPFv2 LSA types are renamed, and a couple of new LSAs are introduced. The LSA changes are as follows:

Image

Image Renamed LSAs:

Image Type 3: The Type 3 LSA is renamed as Interarea prefix LSA for ABRs. As with OSPFv2, this Type 3 LSA advertises one area’s internal networks with another area. This LSA is generated by an area border router (ABR).

Image Type 4: The Type 4 LSA is renamed Interarea prefix LSA for ASBRs. As with OSPFv2, this Type 4 LSA advertises information about how to reach an autonomous system boundary router (ASBR) to routers in a different area than the ASBR. Then, those routers wanting to reach an external network (that is, outside the OSPF autonomous system) use the Type 4 LSAs to determine the best path to reach the ASBR that will get them to a desired external network.

Image New LSAs:

Image Type 8: The Type 8 LSAs, called Link LSAs, only exist on a local link, where they are used by a router to advertise the router’s link-local address to all other routers on the same link. Additionally, the Type 8 LSA provides to routers on that link a listing of all IPv6 addresses associated with the link. OSPFv3 also uses the Type 8 LSA to set option bits for a specific network’s LSA. These bits give OSPFv3 more information about the nature of a network advertisement. As just one example, the NU (no unicast) bit indicates that a network should not be used in OSPF calculations. See RFC 5340 for a complete discussion of the option bits.

Image Type 9: Type 9 LSAs, called Intra-Area Prefix LSAs, can send information about IPv6 networks (including stub networks) attached to a router (similar to the Type 1 LSA for IPv4 networks). Additionally, a Type 9 LSA can send information about transit IPv6 network segments within an area (similar to the Type 2 LSA for IPv4 networks).

OSPFv3 Traditional Configuration

The traditional approach to OSPFv3 configuration involves creating an OSPF routing process, going into the interfaces that you want to participate in the OSPF process, and instructing those interfaces to be part of that process.

The steps required to configure OSPFv3 using the traditional approach are as follows:

Image

Step 1. Enable IPv6 unicast routing on the router (if it is not already enabled). This can be accomplished with the ipv6 unicast-routing global configuration mode command. Although not required, a best practice is to also enable Cisco Express Forwarding (CEF) for IPv6, using the ipv6 cef command, because CEF enables the router to make more efficient route lookups.

Step 2. Start the OSPF process with the ipv6 router ospf process-id command, issued in global configuration mode.

Step 3. (Optional) Configure a router ID for the OSPF process with the router-id rid command, where the rid is a 32-bit value, in router configuration mode. This router ID is commonly an IPv4 address of one of the router’s interfaces. If you do not statically configure a router ID, the router attempts to dynamically determine a router ID to use based on currently active IPv4 addresses on the router. However, if you do not set a router ID, and no active IPv4 addresses exist on the router, the OSPF process will fail to start.

Step 4. Instruct one or more interfaces to participate in the OSPF routing process by entering the ipv6 ospf process-id area area_number command in interface configuration mode.

To illustrate the traditional approach to OSPFv3 configuration, Examples 9-11, 9-12, 9-13, and 9-14 show a sample OSPFv3 configuration for the topology illustrated in Figure 9-11.

Image

Figure 9-11 Sample IPv6 OSPFv3 Topology with Multiple Areas

Image

Example 9-11 Traditional OSPFv3 Configuration—Router R1


! Configuration on Router R1
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ipv6 address 2007::1111/64
ipv6 ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ipv6 address 2001::1/64
ipv6 ospf 1 area 0
!
interface FastEthernet0/1
ip address 10.1.2.1 255.255.255.252
ipv6 address 2002::1/64
ipv6 ospf 1 area 0
!
ipv6 router ospf 1
router-id 1.1.1.1
passive-interface FastEthernet0/0
passive-interface Loopback0


Example 9-12 Traditional OSPFv3 Configuration—Router R2


!Configuration on Router R2
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ipv6 address 2007::2222/64
ipv6 ospf 1 area 0
!
interface FastEthernet0/0
ip address 10.1.2.2 255.255.255.252
ipv6 address 2002::2/64
ipv6 ospf 1 area 0
!
interface Serial1/0
ip address 10.1.2.5 255.255.255.252
encapsulation ppp
ipv6 address 2003::1/64
ipv6 ospf 1 area 1
!
interface Serial1/1
ip address 10.1.2.9 255.255.255.252
encapsulation frame-relay IETF
ipv6 address 2005::1/64
ipv6 ospf 1 area 2
frame-relay map ipv6 2005::2 204 broadcast
frame-relay map ipv6 FE80::C804:DFF:FE24:0 204 broadcast
frame-relay map ip 10.1.2.10 204 broadcast
!
ipv6 router ospf 1
router-id 2.2.2.2
passive-interface Loopback0


Example 9-13 Traditional OSPFv3 Configuration—Router R3


!Configuration on Router R3
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ipv6 address 2007::3333/64
ipv6 ospf 1 area 1
!
interface FastEthernet0/0
ip address 10.1.3.1 255.255.255.0
ipv6 address 2004::1/64
ipv6 ospf 1 area 1
!
interface Serial1/0
ip address 10.1.2.6 255.255.255.252
encapsulation ppp
ipv6 address 2003::2/64
ipv6 ospf 1 area 1
!
ipv6 router ospf 1
router-id 3.3.3.3
passive-interface FastEthernet0/0
passive-interface Loopback0


Example 9-14 Traditional OSPFv3 Configuration—Router R4


!Configuration on Router R4
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ipv6 address 2007::4444/64
ipv6 ospf 1 area 2
!
interface FastEthernet0/0
ip address 10.1.4.1 255.255.255.0
ipv6 address 2006::1/64
ipv6 ospf 1 area 2
!
interface Serial1/0
ip address 10.1.2.10 255.255.255.252
encapsulation frame-relay IETF
ipv6 address 2005::2/64
ipv6 ospf 1 area 2
frame-relay map ipv6 2005::1 402 broadcast
frame-relay map ipv6 FE80::C802:1FF:FEC0:0 402 broadcast
frame-relay map ip 10.1.2.9 402 broadcast
!
ipv6 router ospf 1
router-id 4.4.4.4
passive-interface FastEthernet0/0
passive-interface Loopback0


In each of the four preceding examples, notice that an OSPF routing process was started with the ipv6 router ospf process-id command, and a router ID was associated with each routing process using the router-id rid command. Additionally, under router configuration mode, a passive-interface interface-id command was issued for each interface not connecting to another OSPF-speaking router. This prevents unnecessarily sending OSPF messages out of those interfaces.

These examples illustrate how an interface is made to participate in an OSPFv3 routing process. Specifically, you enter interface configuration mode and enter the ipv6 ospf process-id area area_number command.


Note

Routers R2 and R4 have a series of frame-relay map commands. This is because these configurations are for IPv6 over Frame Relay, an NBMA network. Interestingly, on some NBMA networks, you need to statically configure the mapping of IPv6 addresses to Layer 2 circuit identifiers (for example, Data-Link Connection Identifiers [DLCI] in Frame Relay networks).


Verification can be performed using the same commands you used to verify OSPFv2 configurations, except ip is replaced with ipv6. For example, instead of issuing the show ip ospf interface brief command, as you would with OSPFv2 to get a brief listing of OSPF-speaking interfaces, you would issue the show ipv6 ospf interface brief command for OSPFv3. The following examples provide sample output from a collection of verification commands.

Example 9-15 shows sample output from the show ipv6 ospf interface brief command, issued on Router R2. The output from this command indicates that four interfaces on Router R2 are participating in the OSPFv3 routing process, along with the area membership for each interface. Additionally, the interface costs are listed and the number of neighbors (if any) residing off of each interface is listed.

Example 9-15 Viewing Interfaces Participating in an OSPFv3 Process


R2# show ipv6 ospf interface brief
Interface PID Area Intf ID Cost State Nbrs F/C
Lo0 1 0 8 1 LOOP 0/0
Fa0/0 1 0 2 1 BDR 1/1
Se1/0 1 1 3 64 P2P 1/1
Se1/1 1 2 4 64 DR 0/0


In Example 9-16, the show ipv6 ospf neighbor command is used to create a listing of OSPFv3 neighbors. Interestingly, while Routers R1 (1.1.1.1) and R3 (3.3.3.3) are neighbors, Router R2 is not a neighbor.

Example 9-16 Viewing OSPFv3 Neighbors


R2# show ipv6 ospf neighbor

OSPFv3 Router with ID (2.2.2.2) (Process ID 1)

Neighbor ID Pri State Dead Time Interface ID Interface
1.1.1.1 1 FULL/DR 00:00:36 3 FastEthernet0/0
3.3.3.3 0 FULL/ - 00:00:30 3 Serial1/0


Before reading on, pause for a moment and consider what might be happening to prevent this neighborship from forming. Recall that a nonbroadcast multiaccess (NBMA) network, as the name suggests, does not support broadcasts (or multicasts). Therefore, routers belonging to an NBMA network do not dynamically discover one another. Instead, you need to statically configure a neighbor on at least one of the routers on the NBMA network.

To resolve the specific issue seen in Example 9-16, an ipv6 ospf neighbor neighbor_ipv6_address command is given on Router R2, pointing to Router R4’s link-local address for the Frame Relay link interconnecting Routers R2 and R4. This command is shown in Example 9-17, along with a verification that Router R4 then appears as Router R2’s neighbor.

Example 9-17 Statically Configuring a Neighbor on an NBMA Network


R2# conf term
R2(config)# interface s 1/1
R2(config-if)# ipv6 ospf neighbor FE80::C804:DFF:FE24:0
R2(config-if)# end
R2# show ipv6 ospf neigh

OSPFv3 Router with ID (2.2.2.2) (Process ID 1)

Neighbor ID Pri State Dead Time Interface ID Interface
1.1.1.1 1 FULL/DR 00:00:35 3 FastEthernet0/0
3.3.3.3 0 FULL/ - 00:00:32 3 Serial1/0
4.4.4.4 1 FULL/DR 00:01:42 3 Serial1/1


As a final OSPFv3 verification command, consider the output of the show ipv6 ospf database command issued on Router R1, as seen in Example 9-18.

Example 9-18 Viewing the Contents of the OSPFv3 Link-State Database


R1# show ipv6 ospf database

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

Router Link States (Area 0)

ADV Router Age Seq# Fragment ID Link count Bits
1.1.1.1 1490 0x80000002 0 1 None
2.2.2.2 1491 0x80000001 0 1 B

Net Link States (Area 0)

ADV Router Age Seq# Link ID Rtr count
1.1.1.1 1490 0x80000001 3 2

Inter Area Prefix Link States (Area 0)

ADV Router Age Seq# Prefix
2.2.2.2 1482 0x80000001 2003::/64
2.2.2.2 1482 0x80000001 2005::/64
2.2.2.2 1342 0x80000001 2007::3333/128
2.2.2.2 1259 0x80000001 2004::/64
2.2.2.2 147 0x80000001 2007::4444/128
2.2.2.2 147 0x80000001 2006::/64

Link (Type-8) Link States (Area 0)

ADV Router Age Seq# Link ID Interface
1.1.1.1 1855 0x80000001 3 Fa0/1
2.2.2.2 1491 0x80000001 2 Fa0/1
1.1.1.1 1876 0x80000001 2 Fa0/0

Intra Area Prefix Link States (Area 0)

ADV Router Age Seq# Link ID Ref-lstype Ref-LSID
1.1.1.1 1490 0x80000004 0 0x2001 0
1.1.1.1 1490 0x80000001 3072 0x2002 3
2.2.2.2 1224 0x80000001 0 0x2001 0


In the output shown in Example 9-18, Type 1 LSAs show up as Router Link States, just as they did with OSPFv2. Also like OSPFv3, Type 2 LSAs show up as Net Link States. However, the Type 3 LSAs have been renamed from Summary Net Link States to Inter-Area Prefix Link States.

Also, as described earlier in this chapter, OSPFv3 introduces a couple of new LSA types, both of which are visible in this output. Specifically, OSPFv3 introduced Type 8 LSAs (which appear as Link (Type-8) Link States in the output) and Type 9 LSAs (which appear as Intra-Area Prefix Link States). For details about what these new LSA types do, refer to the “OSPFv2 and OSPFv3 Comparison” section, earlier in this chapter.

OSPFv3 Address Family Configuration

Somewhat similar to Named EIGRP, the OSPFv3 Address Family configuration approach lets you support the routing of both IPv4 and IPv6 under a single OSPF process. With such a configuration, there is a single link-state database containing information for both IPv4 and IPv6 networks. The steps to configure OSPFv3 using the Address Family approach are as follows:

Image

Step 1. Start the OSPFv3 routing process with the router ospfv3 process-id command.

Step 2. (Optional) Configure a router ID with the router-id rid command.

Step 3. Create an Address Family for IPv4 and/or IPv6 with the address-family {ipv4 | ipv6} unicast command.

Step 4. Enter interface configuration mode for the interface(s) that you want to participate in the OSPF process, and enter the ospfv3 process-id {ipv4 | ipv6} area area_number command.


Note

Even though the OSPFv3 Address Family configuration approach supports both IPv4 and/or IPv6 networks, it will not peer with a router using an OSPFv2 configuration.


Notice that the topology in Figure 9-12 is configured with both IPv4 and IPv6 addresses, and it is configured with OSPFv3. Examples 9-19, 9-20, 9-21, and 9-22 show the OSPFv3 configuration for each router, to support the routing of both IPv4 and IPv6 networks.

Image

Figure 9-12 Sample IPv4 and IPv6 OSPFv3 Address Family Topology with Multiple Areas

Image

Example 9-19 OSPFv3 Address Family Configuration on Router R1


ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ipv6 address 2007::1111/64
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ipv6 address 2001::1/64
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface FastEthernet0/1
ip address 10.1.2.1 255.255.255.252
ipv6 address 2002::1/64
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
router ospfv3 1
router-id 1.1.1.1
!
address-family ipv4 unicast
passive-interface FastEthernet0/0
passive-interface Loopback0
exit-address-family
!
address-family ipv6 unicast
passive-interface FastEthernet0/0
passive-interface Loopback0
maximum-paths 32


Example 9-20 OSPFv3 Address Family Configuration on Router R2


ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ipv6 address 2007::2222/64
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface FastEthernet0/0
ip address 10.1.2.2 255.255.255.252
ipv6 address 2002::2/64
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface Serial1/0
ip address 10.1.2.5 255.255.255.252
encapsulation ppp
ipv6 address 2003::1/64
ospfv3 1 ipv6 area 1
ospfv3 1 ipv4 area 1
!
interface Serial1/1
ip address 10.1.2.9 255.255.255.252
encapsulation frame-relay IETF
ipv6 address 2005::1/64
ospfv3 neighbor FE80::C800:AFF:FE20:0
ospfv3 1 neighbor FE80::C800:AFF:FE20:0
ospfv3 1 ipv4 area 2
ospfv3 1 ipv6 area 2
frame-relay map ipv6 FE80::C800:AFF:FE20:0 204 broadcast
frame-relay map ip 10.1.2.10 204 broadcast
frame-relay map ipv6 2005::2 204 broadcast
!
router ospfv3 1
router-id 2.2.2.2
!
address-family ipv4 unicast
passive-interface Loopback0
exit-address-family
!
address-family ipv6 unicast
passive-interface Loopback0
maximum-paths 32
area 2 stub no-summary
exit-address-family


Example 9-21 OSPFv3 Address Family Configuration on Router R3


ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ipv6 address 2007::4444/64
ospfv3 1 ipv6 area 2
ospfv3 1 ipv4 area 2
!
interface FastEthernet0/0
ip address 10.1.4.1 255.255.255.0
ipv6 address 2006::1/64
ospfv3 1 ipv4 area 2
ospfv3 1 ipv6 area 2
!
interface Serial1/0
ip address 10.1.2.10 255.255.255.252
encapsulation frame-relay IETF
ipv6 address 2005::2/64
ospfv3 1 neighbor FE80::C803:AFF:FEB8:0
ospfv3 1 ipv4 area 2
ospfv3 1 ipv6 area 2
frame-relay map ipv6 FE80::C803:AFF:FEB8:0 402 broadcast
frame-relay map ip 10.1.2.9 402 broadcast
frame-relay map ipv6 2005::1 402 broadcast
!
router ospfv3 1
router-id 4.4.4.4
!
address-family ipv4 unicast
passive-interface FastEthernet0/0
passive-interface Loopback0
exit-address-family
!
address-family ipv6 unicast
passive-interface FastEthernet0/0
passive-interface Loopback0
area 2 stub no-summary
exit-address-family


Example 9-22 OSPFv3 Address Family Configuration on Router R4


ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ipv6 address 2007::3333/64
ospfv3 1 ipv4 area 1
ospfv3 1 ipv6 area 1
!
interface FastEthernet0/0
ip address 10.1.3.1 255.255.255.0
ipv6 address 2004::1/64
ospfv3 1 ipv6 area 1
ospfv3 1 ipv4 area 1
!
interface Serial1/0
ip address 10.1.2.6 255.255.255.252
encapsulation ppp
ipv6 address 2003::2/64
ospfv3 1 ipv6 area 1
ospfv3 1 ipv4 area 1
!
router ospfv3 1
router-id 3.3.3.3
!
address-family ipv4 unicast
passive-interface FastEthernet0/0
passive-interface Loopback0
exit-address-family
!
address-family ipv6 unicast
passive-interface FastEthernet0/0
passive-interface Loopback0
area 2 stub no-summary
exit-address-family


In addition to the OSPFv3 configuration steps given earlier, these examples have a few optional features configured. For example, each router has one or more passive interfaces specified. Interestingly, even though the passive-interface interface_identifier command appears under Address Family configuration mode for both IPv4 and IPv6, those commands were entered under router configuration mode. The commands were then automatically copied down to the various Address Families configured under the router process.

Also, the maximum-paths 32 command is entered under the IPv6 Address Family on Routers R1 and R2, illustrating that OSPFv3 allows you to load-balance across as many as 32 equal-cost paths.

Additionally, notice that Routers R2 and R4 have area 2 configured as a totally stubby area, with the area 2 stub no-summary command. This option dramatically reduces the number of OSPFv3 routes that appear on Router R4, as illustrated in Example 9-23. This example contrasts the multiple OSPFv3 routes on Router R1 (which has all its interfaces residing in area 0) and the single summary OSPFv3 route on Router R4 (which has all its interfaces residing in area 2).

Example 9-23 Verifying the Effect of a Totally Stubby Area Configuration


!OSPFv3 Routes on R1
R1# show ip route ospfv3
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/1] via 10.1.2.2, 01:20:19, FastEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
O IA 3.3.3.3 [110/65] via 10.1.2.2, 01:14:36, FastEthernet0/1
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/65] via 10.1.2.2, 00:33:00, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
O IA 10.1.2.4/30 [110/65] via 10.1.2.2, 01:20:19, FastEthernet0/1
O IA 10.1.2.8/30 [110/65] via 10.1.2.2, 01:20:19, FastEthernet0/1
O IA 10.1.3.0/24 [110/66] via 10.1.2.2, 01:14:26, FastEthernet0/1
O IA 10.1.4.0/24 [110/66] via 10.1.2.2, 00:33:00, FastEthernet0/1


!OSPFv3 Routes on R4
R4# show ipv6 route ospf
IPv6 Routing Table - default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
OI ::/0 [110/65]
via FE80::C803:AFF:FEB8:0, Serial1/0


Next, consider a few OSPFv3 verification commands. Example 9-24 shows output from the show ospfv3 neighbor command. Notice that one section of the output is for the IPv4 Address Family, and the other section is for the IPv6 Address Family.

Example 9-24 Sample Output from the show ospfv3 neighbor Command


R1# show ospfv3 neighbor

OSPFv3 1 address-family ipv4 (router-id 1.1.1.1)

Neighbor ID Pri State Dead Time Interface ID Interface
2.2.2.2 1 FULL/BDR 00:00:35 2 FastEthernet0/1

OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

Neighbor ID Pri State Dead Time Interface ID Interface
2.2.2.2 1 FULL/BDR 00:00:38 2 FastEthernet0/1


Example 9-25 shows output from the show ospfv3 interface brief command. Again, a portion of the output is for the IPv4 Address Family, and another portion is for the IPv6 Address Family.

Example 9-25 Sample Output from the show ospfv3 interface brief Command


R1# show ospfv3 interface brief
Interface PID Area AF Cost State Nbrs F/C
Lo0 1 0 ipv4 1 LOOP 0/0
Fa0/0 1 0 ipv4 1 DR 0/0
Fa0/1 1 0 ipv4 1 DR 1/1
Lo0 1 0 ipv6 1 LOOP 0/0
Fa0/0 1 0 ipv6 1 DR 0/0
Fa0/1 1 0 ipv6 1 DR 1/1


Example 9-26 provides sample output from the show ospfv3 database command. Note that OSPFv3’s single link-state database contains information for both IPv4 and IPv6 networks.

Example 9-26 Sample Output from the show ospfv3 database Command


R1# show ospfv3 database

OSPFv3 1 address-family ipv4 (router-id 1.1.1.1)

Router Link States (Area 0)

ADV Router Age Seq# Fragment ID Link count Bits
1.1.1.1 677 0x80000010 0 1 None
2.2.2.2 917 0x8000000E 0 1 B

Net Link States (Area 0)

ADV Router Age Seq# Link ID Rtr count
1.1.1.1 677 0x8000000D 3 2

Inter Area Prefix Link States (Area 0)

ADV Router Age Seq# Prefix
2.2.2.2 917 0x8000000D 10.1.2.4/30
2.2.2.2 917 0x8000000D 10.1.2.8/30
2.2.2.2 408 0x8000000D 3.3.3.3/32
2.2.2.2 408 0x8000000D 10.1.3.0/24
2.2.2.2 1920 0x8000000B 4.4.4.4/32
2.2.2.2 1920 0x8000000B 10.1.4.0/24

...OUTPUT OMITTED...


OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

Router Link States (Area 0)

ADV Router Age Seq# Fragment ID Link count Bits
1.1.1.1 853 0x80000010 0 1 None
2.2.2.2 792 0x8000000E 0 1 B

Net Link States (Area 0)

ADV Router Age Seq# Link ID Rtr count
1.1.1.1 853 0x8000000D 3 2

Inter Area Prefix Link States (Area 0)

ADV Router Age Seq# Prefix
2.2.2.2 545 0x8000000D 2003::/64
2.2.2.2 282 0x8000000D 2007::3333/128
2.2.2.2 282 0x8000000D 2004::/64
2.2.2.2 1048 0x8000000B 2007::4444/128
2.2.2.2 1048 0x8000000B 2006::/64
2.2.2.2 1048 0x8000000B 2005::/64

...OUTPUT OMITTED...



Note

Even though the preceding commands used a series of show ospfv3 commands, you can still use the more traditional show ipv6 ospf commands to verify your OSPFv3 Address Family configuration.


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 9-5 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 the specific parameters.

Image

Table 9-5 Design Review

Implementation Plan Peer Review Table

Table 9-6 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.

Image

Image

Table 9-6 Notable 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 9-7 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.

Image

Table 9-7 Implementation 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 9-8 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.

Image

Image

Table 9-8 Verification 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 9-9 lists a reference of these key topics and the page numbers on which each is found.

Image

Image

Table 9-9 Key Topics for Chapter 9

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.

Type 3 LSA filtering

stub area

totally stubby area

not-so-stubby area

Type 5 external LSA

OSPFv3

OSPFv3 Address Family