Not-So-Stubby-Areas
Not-so-stubby-areas (NSSAs) are similar to the existing OSPF stub area configuration option but have
the following two additional capabilities:
External routes originating from an ASBR connected to the NSSA can be advertised within the
●
NSSA.
External routes originating from the NSSA can be propagated to other areas, including the backbone
●
area.
The command line interface (CLI) command to control the NSSA function is similar to the command
used for configuring a stub area, as follows:
configure ospf area <area-identifier> nssa [summary | nosummary] stub-default-cost
<cost> {translate}
The
option determines whether type 7 LSAs are translated into type 5 LSAs. When
translate
configuring an OSPF area as an NSSA, the
where translation is to be enforced. If
of the ABRs for that NSSA is elected to perform translation (as indicated in the NSSA specification). The
option should not be used on NSSA internal routers. Doing so inhibits correct operation of the election
algorithm.
Normal Area
A normal area is an area that is not:
Area 0
●
Stub area
●
NSSA
●
Virtual links can be configured through normal areas. External routes can be distributed into normal
areas.
Virtual Links
In the situation when a new area is introduced that does not have a direct physical attachment to the
backbone, a virtual link is used. A virtual link provides a logical path between the ABR of the
disconnected area and the ABR of the normal area that connects to the backbone. A virtual link must be
established between two ABRs that have a common area, with one ABR connected to the backbone.
Figure 58
illustrates a virtual link.
NOTE
Virtual links cannot be configured through a stub or NSSA area.
ExtremeWare XOS 11.1 Concepts Guide
should only be used on NSSA border routers,
translate
is not used on any NSSA border router in a NSSA, one
translate
Overview of OSPF
387