Configuring OSPF Areas

You can group the routing devices in a single autonomous system (AS) into areas to reduce the amount of link-state advertisement (LSA) traffic on the network and to reduce the size of the topological databases that OSPF routing devices must maintain. If you do this, the AS must contain a single backbone area and optionally can contain any number of nonbackbone areas. The routing devices that make up the backbone must be physically contiguous. If they are not, you must configure virtual links to create the appearance of connectivity. You also can configure stub areas, which are areas through which AS external advertisements are not flooded, and not-so-stubby areas (NSSAs), which allow external routes to be flooded within an area.

The Junos OS supports active backbone detection. Active backbone detection is implemented to verify that area border routers are connected to the backbone. If the connection to the backbone area is lost, then the routing device’s default metric is not advertised, effectively rerouting traffic through another area border router with a valid connection to the backbone.

Active backbone detection enables transit through an area border router (ABR) with no active backbone connection. An ABR advertises to other routing devices that it is an ABR even if the connection to the backbone is down, so that the neighbors can consider it for interarea routes.

To configure areas, you can perform the following tasks:

• Configuring the OSPF Backbone Area
• Configuring OSPF Nonbackbone Areas
• Configuring OSPF Stub Areas
• Configuring OSPF Not-So-Stubby Areas
• Configuring OSPF Virtual Links

Configuring the OSPF Backbone Area

You must create a backbone area if your network consists of multiple areas. An ABR must have at least one interface in the backbone area, or it must have a virtual link to a routing device in the backbone area. The backbone comprises all ABRs and all routing devices that are not included in any other area. You configure all these routing devices by including the area 0.0.0.0 statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for the statement.

Configuring OSPF Nonbackbone Areas

Each OSPF area consists of routing devices configured with the same area number. To configure a routing device to be in an area, include the area statement. The area ID can be any number except 0.0.0.0, which is reserved for the backbone area.

For a list of hierarchy levels at which you can include this statement, see the statement summary section for the statement.

Configuring OSPF Stub Areas

Stub areas are areas into which OSPF does not flood AS external advertisements. You might want to configure stub areas when much of the topological database consists of AS external advertisements and you want to minimize the size of the topological databases on an area’s routing devices.

You cannot configure an area as being both a stub area and an not-so-stubby area (NSSA).

To configure a stub area, include the stub statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

To inject a default route with a specified metric value into the area, include the default-metric option and a metric value. The default route matches any destination that is not explicitly reachable from within the area.

To have the stub areas not advertise summary routes into the stub area, include the no-summaries option. Only the default route is advertised, and only if you include the default-metric option. The default route injected into the NSSA is a Type 3 LSA.

You must include the stub statement when configuring all routing devices that are in the stub area.

Note: In Junos OS Release 8.5 and later, a router-identifier interface that is not configured to run OSPF is no longer advertised as a stub network in OSPF link-state advertisements. For more information about how to configure a router identifier, see Configuring Router Identifiers for BGP and OSPF. In Junos OS Release 8.5 and later, OSPF advertises a local route with a prefix length of 32 as a stub link if the loopback interface is configured with a prefix length other than 32. OSPF also advertises the direct route with the configured mask length, as in earlier releases.

Configuring OSPF Not-So-Stubby Areas

An OSPF stub area has no external routes, so you cannot redistribute from another protocol into a stub area. An NSSA allows external routes to be flooded within the area. These routes are then leaked into other areas. However, external routes from other areas still do not enter the NSSA.

You cannot configure an area to be both a stub area and an NSSA.

To configure an NSSA, include the nssa statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

By default, a default route is not advertised. To advertise a default route with the specified metric within the area, include the default-metric statement. You can configure this option only on ABRs.

To prevent an ABR from advertising summary routes into an NSSA, include the no-summaries statement. If you include the default-metric option in addition to the no-summaries statement, only the default route is advertised. The default route is a Type 3 LSA injected into the NSSA. To flood summary LSAs into the NSSA area, include the summaries statement. When summaries is configured (which is the default if the no-summaries statement is not specified), a Type 7 LSA is sent. To define the type of metric, include the metric-type statement.

To aggregate external routes learned within the area when a route is advertised to other areas, include one or more area-range statements. If you also include the restrict option, the aggregate is not advertised, effectively creating a route filter. All external routes learned within the area that do not fall into the range of one of the prefixes are advertised individually to other areas. To restrict an exact area range, include the exact option. For an example, you can suppress the exact 0/0 prefix from being advertised from a NSSA area into the backbone area by including both the exact and restrict options. To override the metric for the IP address range and configure a specific metric value, include the override-metric option.

Configuring OSPF Virtual Links

If any routing device on the backbone is not physically connected to the backbone itself, you must establish a virtual connection between that routing device and the backbone. You can establish a virtual connection between ABRs by configuring an OSPF virtual link.

To configure an OSPF virtual link, include the virtual-link statement when configuring the backbone area (area 0):

To configure an OSPFv3 virtual link, include the virtual-link statement when configuring the backbone area (area 0):

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Specify the router ID (as an IPv4 address) of the routing device at the other end of the virtual link. This router must be an ABR that is physically connected to the backbone. Also, specify the number of the area through which the virtual link transits.

For the virtual connection to work, you also must configure a link to the backbone area on the remote ABR (the routing device at the other end of the LSP).

Example: Configuring an OSPF Virtual Link

Configure an OSPF virtual link on the local router. This routing device must be an area border router that is physically connected to the backbone.

You must also configure an OSPF virtual link on the remote ABR: