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 ospf–Confirms with one (highlighted)
line that the router believes that the area is a stub area.
■ show ip ospf database summary 0.0.0.0–By 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-summary–This 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 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.
■ show ip ospf database database-summary–The 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 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 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.