18 May, 2013

Stubby Areas

Stubby Areas
As mentioned earlier, the two most common reasons to consider using default routes are to drive all Internet-destined traffic toward the Internet-connected routers in the Enterprise and to drive traffic inside an area toward one of the ABRs 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 the routers inside the area, because the routers in that area can have fewer LSAs in their LSDBs.

The OSPF stub router feature provides engineers 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 (5 LSAs) into the area, or even instead to no longer 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 the default route), but the routers require less memory and processing.

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

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.

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

ABRs may not flood other Type 3 LSAs into the area.

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

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

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

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

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

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 in Figure 7-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 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 7-3:

Note: For totally stubby areas, only the ABR 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 7-9 shows a more detailed view of area 34 from Figure 7-8, so 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 LSA for the default routes. Example 7-4 shows the configuration on Routers R1, R2, and R3 from Figure 7-9.
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 7-5 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 7-5 shows the existence of the Type 5 external LSAs before area 34 became a stubby area, and the disappearance of those same LSAs once 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 7-6 continues the verification of how stub areas work with three more commands.
Following are the three commands in Example 7-6 in order:

show ip ospfConfirms with one (highlighted) line that the router believes that the area is a stub area.

show ip ospf database summary 0.0.0.0By definition, this command lists all summary (Type 3) LSAs with prefix 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).

show ip ospf database database-summaryThis command lists statistics about the numbers of and types of LSAs in the database. The counters show 0 Type 5 LSAs, and a few dozen Type 3s–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 7-3, the only difference for totally stubby configuration versus stubby configuration is that the ABR’s 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 7-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 7-7 just shows the changes to the configuration shown in
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 7-8. 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.
Following are the three commands in Example 7-8 in order:

show ip routeIt 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.

show ip ospf database database-summaryThe statistics still show no External Type 5 LSAs, just as when the area was stubby, but now shows only 2 Type 3 LSAs, whereas before a few dozen existed.

show ip ospf database | begin SummaryThis 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 7-6 and 7-8 demonstrate the key differences between stub (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 7-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.

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.

The configuration of an NSSA area requires only a little effort compared to configuring stubby and totally stubby areas: Just use the area nssa command instead of the area stub command, with no differences in other parameters. NSSA areas can be simply stubby, filtering only external routes from getting into the area, or totally stubby. The NSSA designation just defines whether routers in that area can redistribute external routes into OSPF.

Example 7-9 shows a sample with the configuration of a totally NSSA area 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.

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

Stubby Area Summary
Table 7-4 summarizes the key points regarding stubby areas.
Note: Both types of totally stubby areas (totally stubby, totally NSSA) are Cisco proprietary.