NSSAs are a relatively new,
standards-based OSPF enhancement. To understand how to use NSSAs,
consider the network shown in Figure .
RTA connects to an external RIP
domain, and RTB currently serves as an ABR for Area 0. If the RIP
domain is not under your administrative control, what options do you
have to exchange routing information between these two domains? If
you are going to use dynamic routing, you could create an OSPF
standard area, as shown in Figure .
However, what if the routers that you
place in Area 1 do not have the required processing power or memory
to run OSPF? You have learned that you can reduce the burden on OSPF
routers by configuring them to participate in a stub or totally
stubby area. Figure
illustrates what would happen in this case.
A stub area cannot include an ASBR
because Type 5 (external) LSAs are not allowed in a stub domain. The
configuration shown in Figure
would fail miserably.
So, how do you dynamically exchange
external routing information without creating a standard OSPF area?
You could configure another routing protocol, such as RIP or IGRP,
in place of creating an Area 1. This may prove to be disadvantageous
because an additional routing protocol must be maintained and
imported into OSPF (and the RIP domain, is not under your
administrative control).
With the introduction of the NSSA,
you have another, more palatable option. An NSSA acts like a stub
network in the sense that it does not allow Type 5 LSAs. It can also
be configured to prevent floods of Type 3 and Type 4 summary LSAs,
just as a totally stubby area would. However, an NSSA does allow Type 7
LSAs, which can carry external routing information and be flooded
throughout the NSSA.
Note: NSSAs are supported in Cisco
IOS version 11.2 and later.
|