Nokia NRS II Composite (OSPF) study materials
Nokia NRS II Composite (OSPF) study resources

NSSA Conversion Loses the Stub Default Route

Nokia NRS II Composite (OSPF) · Put your knowledge to work in context.

All case studies

NSSA Conversion Loses the Stub Default Route

An enterprise has a hub R1 in area 0 and a branch R3 in area 1. Area 1 is a stub area, and the ABR R2 injects a default route into it. The branch has a new local Internet circuit and wants to redistribute its 0.0.0.0/0 into OSPF so that other branch routers in area 1 can use it as a backup. The engineer changes area 1 from stub to NSSA on R2 and R3. Immediately after the change, R3's OSPF route table loses the default route from R2, and the branch's backup path fails. R3's local default is present in the route table as a static route, and redistribution is configured, but no Type-7 default appears in show router ospf database. The engineer expected the NSSA to behave like the stub area plus redistribution.

1. Explain why the default route disappeared after the stub-to-NSSA change.

Read the worked answer

A stub ABR automatically originates a default summary route into the stub area. That default is part of the stub area definition and is why R3 had a default route before the change.

An NSSA ABR does not automatically originate a default route. Converting area 1 from stub to NSSA removes the automatic default. The NSSA ABR will only inject a default if it is explicitly configured to do so, for example with a default-information-originate setting on the NSSA, or if a Type-7 default is originated by an ASBR inside the NSSA. R3's static default is not automatically translated into a Type-7 LSA just because redistribution is configured; the export policy must match 0.0.0.0/0 and the OSPF process must accept a redistributed default. That is why show router ospf database shows no Type-7 default and R3's OSPF route table loses the path.

The change also alters the area's external behavior: Type-5 LSAs are no longer allowed, so any external routes must be carried as Type-7 and translated by an NSSA ABR.

2. What configuration and verification steps would you use to restore a default while keeping area 1 as an NSSA?

Read the worked answer

First decide which default is desired. If the branch should still receive a default from the hub, configure the NSSA ABR R2 to originate a default into the NSSA. On SR OS this is an explicit NSSA default-information-originate setting, not an automatic stub behavior. Verify with show router ospf database type 7 on R3 and show router ospf routes for 0.0.0.0/0.

If the branch's local Internet circuit should provide the backup default, confirm that R3's export policy matches the static default and that the OSPF export is applied to the OSPF instance, not only to the router. Then check that R3 sets the P-bit on the Type-7 default if it wants the NSSA ABR to translate it into a Type-5 for other areas. Use show router ospf database type 7 detail to inspect the forwarding address and P-bit. Also confirm that the NSSA ABR is the translator, or that translator election is deterministic, before relying on the Type-7 default to reach the backbone.

Be careful with two defaults: if both R2 and R3 originate a default, branch routers may choose the lower-cost one and send traffic toward the hub instead of the local Internet circuit. Use metrics or route policy deliberately.

3. What are the trade-offs between keeping area 1 as an NSSA and reverting to a stub area?

Read the worked answer

Keeping area 1 as an NSSA allows R3 to inject external information, including the local default, as Type-7 LSAs. That supports the backup Internet design without making area 1 a normal area. The costs are additional LSAs, translator behavior, and the need to manage the P-bit and forwarding address. External routes from the branch can also create suboptimal routing if other branch routers prefer the backup path over the hub path.

Reverting to a stub area is simpler and restores the automatic default, but it forbids the ASBR behavior R3 needs. A stub area cannot carry Type-5 or Type-7 LSAs, so R3 cannot redistribute its local default into OSPF. The branch could still use the local circuit with a static route or policy-based routing, but that is outside OSPF and does not give other branch routers a dynamic backup.

A third option is to keep area 1 as a normal area and filter externals at the ABR, but that loses the stub/NSSA protection against external LSAs. The judgment is whether the backup Internet path is worth the NSSA complexity; if it is, keep NSSA and explicitly control the default origination and translation.