Use the
Not-So-Stubby Area (NSSA) for Open Shortest Path First version 3 (OSPFv3)
feature to simplify administration in a network that connects a central site
that uses OSPFv3 to a remote site that uses a different routing protocol.
When the NSSA
feature is not implemented, the connection between the border device at the
corporate site and the remote device is not established as an OSPFv3 stub area
due to following reasons:
- Routes for the remote site
are not redistributed into the stub area.
- Two routing protocols must
be maintained.
A protocol such as
Routing Information Protocol (RIP) for IPv6 is run to handle the
redistribution. By implementing NSSA, you can extend OSPFv3 to include the
remote connection by defining the area between the border device at the
corporate site and the remote device as an NSSA.
As with OSPFv3 stub
areas, NSSA areas cannot be injected with distributed routes via a Type 5 Link
State Advertisement (LSA). Route redistribution into an NSSA area is possible
only with a Type 7 LSA. An NSSA Autonomous System Border Router (ASBR)
generates the Type 7 LSA , and an NSSA Area Border Router (ABR) translates the
Type 7 LSA into a Type 5 LSA. These LSAs can be flooded throughout the OSPFv3
routing domain. Route summarization and filtering are supported during the
translation.
Route summarization
is the consolidation of advertised addresses. This feature enables an ABR to
advertise a single summary route to other areas. If the network numbers in an
area are assigned in a way such that they are contiguous, you can configure the
ABR to advertise a summary route that covers all the individual networks within
the area that fall into the specified range.
When routes from
other protocols are redistributed into an OSPFv3 area, each route is advertised
individually in an external LSA. However, you can configure the Cisco IOS
software to advertise a single route with a specified network address and mask
for all the redistributed routes that are covered by a specified network
address and mask. Thus, the size of the OSPFv3 link-state database decreases.
RFC 3101 allows you
to configure an NSSA ABR device as a forced NSSA LSA translator.
Note |
Even a forced
translator might not translate all LSAs; translation depends on the content of
each LSA.
|
The figure below
shows a network diagram in which OSPFv3 Area 1 is defined as the stub area. The
Enhanced Interior Gateway Routing Protocol (EIGRP) routes are not propagated
into the OSPFv3 domain because routing redistribution is not allowed in the
stub area. However, once OSPFv3 Area 1 is defined as an NSSA, an NSSA ASBR can
include the EIGRP routes to the OSPFv3 NSSA by generating Type 7 LSAs.
Figure 1. OSPFv3 NSSA
The redistributed
routes from the RIP device are not allowed into OSPFv3 Area 1 because NSSA is
an extension to the stub area. The stub area characteristics still exist,
including the exclusion of Type 5 LSAs.
The figure below
shows the OSPFv3 stub network with NSSA Area 1. The redistributed routes that
Device 4 is propagating from the two RIP networks are translated into Type 7
LSAs by NSSA ASBR Device 3. Device 2, which is configured to be the NSSA ABR,
translates the Type 7 LSAs back to Type 5 so that they can be flooded through
the rest of the OSPFv3 stub network within OSPFv3 Area 0.
Figure 2. OSPFv3 NSSA
Network with NSSA ABR and ASBR Devices