Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

Injecting a default route in an OSPF NSSA area from a Juniper device

OSPF not-so-stubby area is described in RFC 3101 (https://tools.ietf.org/html/rfc3101) and it’s main characteristics are that it does not accept OSPF external LSAs (Type 5) as a stubby area, but it allows injection of AS external prefixes, as a normal area. It makes use of Type 7 LSAs that get translated into Type 5 External LSAs by the ABR into the rest of the OSPF domain. Section 1.3 of the RFC describes NSSA areas better than I can ever try .

A default route in an not-so-stubby OSPF area can result either from a Type 3 LSA or from a Type 7 LSA.

JunOS: How to inject a default route into an NSSA area with a Type - 3 Summary LSA

To inject a default route from a Juniper device which is an ABR into a not so stubby area, Junos needs to actually have “no-summaries” configured. This will prevent other Type 3 Summaries to go into the NSSA area with the exception of a “0.0.0.0” Summary. From the ABR:


and the result in OSPF database:


See the default LSA is a Summary LSA.

JunOS: How to inject a default route into an NSSA area with a Type - 7 NSSA LSA

On the ABR:


And the result:

The default Summary LSA gets aged out (age 3600) and a new default NSSA LSA is generated by the ABR.


To note here:
“no-summaries” disables Type 3 Summary LSAs the NSSA with the exception of default one. This turns the area practically into a NSSA totally stub area.
“Type-3” is default type for the default LSA into a NSSA area when "no-summaries" is set. If "no-summaries" is left out, it is injected as a Type-7.
The ABR needs an area 0 adjacency in order to inject a default route into the NSSA area.

Juniper official documentation: https://www.juniper.net/documentation/en_US/junos14.1/topics/topic-map/ospf-stub-and-not-so-stubby-areas.html.
Please comment.