In which configuration mode is area [id] nssa used?

The area [id] nssa command is entered in Router Config mode on Cisco IOS devices.

OSPFRouter Config

area [id] nssa

Configures an OSPF area as a Not-So-Stubby Area (NSSA), allowing external routes from outside the OSPF domain to be imported as Type 7 LSAs while still blocking most external routes from other areas.

Definition: area [id] nssa is a Cisco IOS router config command. Configures an OSPF area as a Not-So-Stubby Area (NSSA), allowing external routes from outside the OSPF domain to be imported as Type 7 LSAs while still blocking most external routes from other areas.

Overview

The `area [id] nssa` command is used in OSPF router configuration mode to designate an area as a Not-So-Stubby Area (NSSA). NSSA is an extension of the stub area concept, allowing the import of external routes (redistributed routes) into the OSPF domain while still preventing the injection of Type 5 LSAs from other areas. This is particularly useful in scenarios where an area needs to connect to an external network (e.g., a branch office with a VPN link to the internet) but should not receive a full set of external routes from the rest of the OSPF domain.

By configuring an area as NSSA, the router generates Type 7 LSAs for external routes, which are then translated to Type 5 LSAs at the Area Border Router (ABR) for propagation into other areas. This command is essential for network engineers designing scalable OSPF networks that require controlled external route injection. Compared to a standard stub area, NSSA allows redistribution; compared to a totally stubby area, NSSA still permits Type 3 summary LSAs (unless the `no-summary` keyword is used).

The command is entered in router configuration mode and takes effect immediately, modifying the running configuration. It requires privileged EXEC access (enable mode) and is typically used during initial OSPF design or when integrating external networks. Understanding NSSA is critical for CCNA and CCNP candidates as it appears in both configuration and troubleshooting scenarios.

Syntax·Router Config

area [id] nssa

When to Use This Command

Connect a remote site with a single router to an ISP using OSPF, where the remote site needs to redistribute a default route or a few external routes without receiving all external routes from the backbone.
Integrate a non-OSPF network (e.g., EIGRP) into an OSPF stub area by redistributing external routes into the NSSA, allowing those routes to be advertised as Type 7 LSAs.
Create a stub area that still needs to import a limited set of external routes (e.g., a default route) from an external source, such as a router connected to the internet.
Connect two OSPF domains where one domain uses NSSA to inject external routes into the other domain without flooding Type 5 LSAs.

Parameters

Parameter	Syntax	Required	Description
id	A.B.C.D \| <0-4294967295>	Required	The OSPF area identifier. This can be specified as a decimal number (e.g., 10) or in dotted-decimal format (e.g., 0.0.0.10). The area ID must match on all routers in the same area. A common mistake is using an IP address that does not correspond to any subnet; it is simply an identifier.

Command Examples

Configure area 1 as NSSA

area 1 nssa

R1(config-router)# area 1 nssa
R1(config-router)#

No output is displayed upon successful configuration. The command simply enables NSSA for area 1.

Configure area 2 as NSSA with no redistribution

area 2 nssa no-redistribution

R1(config-router)# area 2 nssa no-redistribution
R1(config-router)#

The 'no-redistribution' keyword prevents the NSSA ABR from redistributing Type 7 LSAs into Type 5 LSAs. This is useful when you want to keep external routes within the NSSA only.

Understanding the Output

The 'area [id] nssa' command itself does not produce any output. To verify the NSSA configuration, use 'show ip ospf' or 'show ip ospf interface'. In 'show ip ospf', look for the line 'Area is NSSA' under the specific area.

In 'show ip ospf interface', the output will include 'Area is NSSA' if the interface belongs to an NSSA. Additionally, 'show ip ospf database nssa-external' displays Type 7 LSAs. A healthy NSSA will have Type 7 LSAs for external routes, and the ABR will translate them to Type 5 LSAs (unless 'no-redistribution' is configured).

Watch for missing Type 7 LSAs if redistribution is not working, or for Type 5 LSAs leaking into the NSSA if the ABR is misconfigured.

Configuration Scenarios

Configure NSSA on a Branch Router to Allow Redistribution of a Default Route

A branch office router (R2) is in OSPF area 1 and needs to advertise a default route to the corporate network via a VPN connection. The area should be NSSA to allow redistribution of the default route while blocking other external routes.

Topology

R1 (ABR) Gi0/0---10.0.12.0/30---Gi0/0 R2 (Branch)
R2 Gi0/1---192.168.1.0/24 (LAN)
R2 Gi0/2---VPN to Internet

Steps

1.Step 1: Enter global configuration mode: configure terminal
2.Step 2: Enter router OSPF configuration mode: router ospf 1
3.Step 3: Configure area 1 as NSSA: area 1 nssa
4.Step 4: Redistribute the default route from the VPN into OSPF as Type 7: default-information originate metric 100 metric-type type-7
5.Step 5: Exit and verify: end, show ip ospf

Configuration

!
router ospf 1
 area 1 nssa
 default-information originate metric 100 metric-type type-7
!

Verify: Use 'show ip ospf database nssa-external' to see Type 7 LSAs. Expected output includes the default route (0.0.0.0/0) as a Type 7 LSA.

Watch out: Ensure the ABR (R1) also has 'area 1 nssa' configured; otherwise, the Type 7 LSAs will not be translated to Type 5.

Configure NSSA with No Summary to Create a Totally NSSA Area

A remote site (R3) in area 2 should only receive a default route from the ABR and not any inter-area routes. The area is configured as NSSA with the no-summary option to block Type 3 LSAs.

Topology

R1 (ABR) Gi0/0---10.0.13.0/30---Gi0/0 R3 (Remote)
R3 Gi0/1---172.16.1.0/24 (LAN)

Steps

1.Step 1: Enter global configuration mode: configure terminal
2.Step 2: Enter router OSPF configuration mode: router ospf 1
3.Step 3: Configure area 2 as NSSA with no-summary: area 2 nssa no-summary
4.Step 4: On R3, configure area 2 as NSSA (without no-summary): area 2 nssa
5.Step 5: Verify on R3 that only a default route (0.0.0.0/0) appears in the routing table.

Configuration

!
! On ABR R1
router ospf 1
 area 2 nssa no-summary
!
! On remote router R3
router ospf 1
 area 2 nssa
!

Verify: On R3, use 'show ip route ospf' to confirm only a default route via R1 is present. Use 'show ip ospf database nssa-external' to see any Type 7 LSAs.

Watch out: The 'no-summary' keyword is only configured on the ABR; the internal router (R3) should not use it. Misconfiguration can cause routing issues.

Troubleshooting with This Command

When troubleshooting NSSA configurations, the primary tool is 'show ip ospf database nssa-external' to verify Type 7 LSAs. A healthy output shows external routes with a link state ID and advertising router. If no Type 7 LSAs appear, check that redistribution is configured correctly and that the area is indeed NSSA on all routers.

Another key command is 'show ip ospf interface' to confirm the interface is in the correct area and that the OSPF state is FULL/DR or BDR. Common symptoms include missing external routes in non-NSSA areas; this often indicates that the ABR is not translating Type 7 to Type 5 LSAs. Verify with 'show ip ospf database external' on the ABR; if Type 5 LSAs are missing, ensure the ABR has the 'area X nssa' command and that the 'translate' feature is enabled (default).

Another issue is the absence of a default route; check that 'default-information originate' is configured with the 'metric-type type-7' keyword. Use 'debug ip ospf lsa-generation' cautiously to see LSA creation. Also, verify that the NSSA area does not contain virtual links, as NSSA does not support them.

A step-by-step diagnostic flow: 1) Confirm NSSA configuration on all routers in the area. 2) Check OSPF neighbor states. 3) Examine the NSSA external database. 4) Verify redistribution sources. 5) Check ABR translation using 'show ip ospf database translator'. Correlate with 'show ip route' to see if routes are installed. Remember that NSSA areas block Type 5 LSAs from other areas, so external routes from other areas will not appear; this is expected behavior.

CCNA Exam Tips

Remember that NSSA allows Type 7 LSAs for external routes, which are translated to Type 5 by the ABR. This is a key distinction from stub areas that block all external routes.

The 'no-redistribution' keyword prevents the ABR from translating Type 7 to Type 5. This is a common exam scenario to test your understanding of NSSA behavior.

NSSA is the only area type that can import external routes while still being a stub-like area. Expect questions comparing NSSA to stub and totally stubby areas.

On the CCNA exam, you may be asked to configure NSSA to allow redistribution of a default route from an external source into an OSPF area.

Common Mistakes

Mistake: Configuring NSSA on an area that already has virtual links. NSSA does not support virtual links.

Mistake: Forgetting that NSSA ABRs translate Type 7 to Type 5 by default, which may cause external routes to leak into other areas unintentionally.

Mistake: Using 'area [id] nssa' on an area that is not a stub area; NSSA is a variant of stub area and inherits stub area restrictions (e.g., no Type 5 LSAs).

area [id] nssa vs show ip ospf

These commands are commonly considered together because both are essential OSPF operations—one configures a special area type (NSSA) and the other displays global OSPF status. However, they operate in completely different modes and serve distinct purposes: configuration versus verification.

Aspect	area [id] nssa	show ip ospf
Scope	Affects a specific OSPF area	Displays entire OSPF process
Mode	Router configuration (config-router)	Privileged EXEC (enable mode)
Persistence	Written to running-config, persists	Show output, no persistent effect
Effect on behavior	Changes LSA type handling (Type 7)	No behavioral change, only observation
Typical use	Configure stubby behavior with external route injection	Verify OSPF neighbor/area status and LSDB

Use area [id] nssa when you need to make an OSPF area a Not-So-Stubby Area to allow redistribution of external routes while still blocking most Type 5 LSAs.

Use show ip ospf when you need to verify OSPF process details like router ID, area count, and LSDB statistics for troubleshooting or monitoring.

Platform Notes

In IOS-XE (e.g., 16.x), the syntax is identical to classic IOS. The 'area [id] nssa' command works the same way. In NX-OS (e.g., Nexus 9000), the equivalent command is 'area [id] nssa' under 'router ospf [process-id]' but note that NX-OS uses the 'default-information originate always' command without the 'metric-type type-7' keyword; instead, it automatically generates Type 7 LSAs in NSSA areas.

For ASA (Adaptive Security Appliance), OSPF is supported but NSSA is not available; use 'area [id] stub' instead. In IOS-XR, the command is 'area [id] nssa' under 'router ospf [process-id]' but the syntax requires the area to be specified in dotted-decimal format. There are no significant differences between IOS 12.x, 15.x, and 16.x for this command.

Always ensure that the OSPF process is configured before applying area commands.

Related Commands

show ip ospf

Displays general information about OSPF routing process, including router ID, areas, and LSDB statistics, used to verify OSPF configuration and operational status.

show ip ospf database

Displays the OSPF link-state database (LSDB) to verify OSPF adjacencies, check for missing or corrupt LSAs, and troubleshoot OSPF routing issues.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions