Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Examples: Configuring OSPF Stub and Not-So-Stubby Areas

Understanding OSPF Stub Areas, Totally Stubby Areas, and Not-So-Stubby Areas

Figure 1 shows an autonomous system (AS) across which many external routes are advertised. If external routes make up a significant portion of a topology database, you can suppress the advertisements in areas that do not have links outside the network. By doing so, you can reduce the amount of memory the nodes use to maintain the topology database and free it for other uses.

Figure 1: OSPF AS Network with Stub Areas and NSSAs

OSPF AS Network with Stub
Areas and NSSAs

To control the advertisement of external routes into an area, OSPF uses stub areas. By designating an area border router (ABR) interface to the area as a stub interface, you suppress external route advertisements through the ABR. Instead, the ABR advertises a default route (through itself) in place of the external routes and generates network summary (Type 3) link-state advertisements (LSAs). Packets destined for external routes are automatically sent to the ABR, which acts as a gateway for outbound traffic and routes the traffic appropriately.

Note: You must explicitly configure the ABR to generate a default route when attached to a stub or not-so-stubby-area (NSSA). To inject a default route with a specified metric value into the area, you must configure the default-metric option and specify a metric value.

For example, area 0.0.0.3 in Figure 1 is not directly connected to the outside network. All outbound traffic is routed through the ABR to the backbone and then to the destination addresses. By designating area 0.0.0.3 as a stub area, you reduce the size of the topology database for that area by limiting the route entries to only those routes internal to the area.

A stub area that only allows routes internal to the area and restricts Type 3 LSAs from entering the stub area is often called a totally stubby area. You can convert area 0.0.0.3 to a totally stubby area by configuring the ABR to only advertise and allow the default route to enter into the area. External routes and destinations to other areas are no longer summarized or allowed into a totally stubby area.

Note: If you incorrectly configure a totally stubby area, you might encounter network connectivity issues. You should have advanced knowledge of OSPF and understand your network environment before configuring totally stubby areas.

Similar to area 0.0.0.3 in Figure 1, area 0.0.0.4 has no external connections. However, area 0.0.0.4 has static customer routes that are not internal OSPF routes. You can limit the external route advertisements to the area and advertise the static customer routes by designating the area an NSSA. In an NSSA, the AS boundary router generates NSSA external (Type 7) LSAs and floods them into the NSSA, where they are contained. Type 7 LSAs allow an NSSA to support the presence of AS boundary routers and their corresponding external routing information. The ABR converts Type 7 LSAs into AS external (Type 5 ) LSAs and leaks them to the other areas, but external routes from other areas are not advertised within the NSSA.

Example: Configuring OSPF Stub and Totally Stubby Areas

This example shows how to configure an OSPF stub area and a totally stubby area to control the advertisement of external routes into an area.

Requirements

Before you begin:

Overview

The backbone area, which is 0 in Figure 2, has a special function and is always assigned the area ID 0.0.0.0. Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only be unique within an autonomous system (AS). All other networks or areas (such as 3, 7, and 9) in the AS must be directly connected to the backbone area by area border routers (ABRs) that have interfaces in more than one area.

Stub areas are areas through which or into which OSPF does not flood AS external link-state advertisements (Type 5 LSAs). You might create stub areas when much of the topology database consists of AS external advertisements and you want to minimize the size of the topology databases on the internal routers in the stub area.

The following restrictions apply to stub areas:

  • You cannot create a virtual link through a stub area.
  • A stub area cannot contain an AS boundary router.
  • You cannot configure the backbone as a stub area.
  • You cannot configure an area as both a stub area and an not-so-stubby area (NSSA).

In this example, you configure each routing device in area 7 (area ID 0.0.0.7) as a stub router and some additional settings on the ABR:

  • stub—Specifies that this area become a stub area and not be flooded with Type 5 LSAs. You must include the stub statement on all routing devices that are in area 7 because this area has no external connections.
  • default-metric—Configures the ABR to generate a default route with a specified metric into the stub area. This default route enables packet forwarding from the stub area to external destinations. You configure this option only on the ABR. The ABR does not automatically generate a default route when attached to a stub. You must explicitly configure this option to generate a default route.
  • no-summaries—(Optional) Prevents the ABR from advertising summary routes into the stub area by converting the stub area into a totally stubby area. If configured in combination with the default-metric statement, a totally stubby area only allows routes internal to the area and advertises the default route into the area. External routes and destinations to other areas are no longer summarized or allowed into a totally stubby area. Only the ABR requires this additional configuration because it is the only routing device within the totally stubby area that creates Type 3 LSAs used to receive and send traffic from outside of the area.

In Junos OS Release 8.5 and later, the following applies:

  • A router-identifier interface that is not configured to run OSPF is no longer advertised as a stub network in OSPF LSAs.
  • 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.

Figure 2: OSPF Network Topology with Stub Areas and NSSAs

OSPF Network
Topology with Stub Areas and NSSAs

Configuration

CLI Quick Configuration

  • To quickly configure an OSPF stub area, copy the following command and paste it into the CLI. You must configure all routing devices that are part of the stub area.
    [edit] set protocols ospf area 0.0.0.7 stub
  • To quickly configure the ABR to inject a default route into the area, copy the following command and paste it into the CLI. You apply this configuration only on the ABR.
    [edit] set protocols ospf area 0.0.0.7 stub default-metric 10
  • (Optional) To quickly configure the ABR to restrict all summary advertisements and allow only internal routes and default route advertisements into the area, copy the following command and paste it into the CLI. You apply this configuration only on the ABR.
    [edit] set protocols ospf area 0.0.0.7 stub no-summaries

Step-by-Step Procedure

To configure OSPF stub areas:

  1. On all routing devices in the area, configure an OSPF stub area.

    Note: To specify an OSPFv3 stub area, include the ospf3 statement at the [edit protocols] hierarchy level.

    [edit]user@host# set protocols ospf area 0.0.0.7 stub
  2. On the ABR, inject a default route into the area.
    [edit]user@host# set protocols ospf area 0.0.0.7 stub default-metric 10
  3. (Optional) On the ABR, restrict summary LSAs from entering the area. This step converts the stub area into a totally stubby area.
    [edit]user@host# set protocols ospf area 0.0.0.7 stub no-summaries
  4. If you are done configuring the devices, commit the configuration.
    [edit]user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuration on all routing devices:

user@host# show protocols ospf
area 0.0.0.7 { stub;}

Configuration on the ABR (the output also includes the optional setting):

user@host# show protocols ospf
area 0.0.0.7 { stub default-metric 10 no-summaries;}

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

Verification

Confirm that the configuration is working properly.

Verifying the Interfaces in the Area

Purpose

Verify that the interface for OSPF has been configured for the appropriate area. Confirm that the output includes Stub as the type of OSPF area.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

Verifying the Type of OSPF Area

Purpose

Verify that the OSPF area is a stub area. Confirm that the output displays Normal Stub as the Stub type.

Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3.

Example: Configuring OSPF Not-So-Stubby Areas

This example shows how to configure an OSPF not-so-stubby area (NSSA) to control the advertisement of external routes into an area.

Requirements

Before you begin:

Overview

The backbone area, which is 0 in Figure 3, has a special function and is always assigned the area ID 0.0.0.0. Area IDs are unique numeric identifiers, in dotted decimal notation. Area IDs need only be unique within an AS. All other networks or areas (such as 3, 7, and 9) in the AS must be directly connected to the backbone area by ABRs that have interfaces in more than one area.

An OSPF stub area has no external routes, so you cannot redistribute routes from another protocol into a stub area. OSPF NSSAs allow external routes to be flooded within the area.

In addition, you might have a situation when exporting Type 7 LSAs into the NSSA is unnecessary. When an AS boundary router is also an ABR with an NSSA attached, Type 7 LSAs are exported into the NSSA by default. If the ABR is attached to multiple NSSAs, a separate Type 7 LSA is exported into each NSSA by default. During route redistribution, this routing device generates both Type 5 LSAs and Type 7 LSAs. You can disable exporting Type 7 LSAs into the NSSA.

Note: The following restriction applies to NSSAs: You cannot configure an area as both a stub area and an NSSA.

You configure each routing device in area 9 (area ID 0.0.0.9) with the following setting:

  • nssa—Specifies an OSPF NSSA. You must include the nssa statement on all routing devices in area 9 because this area only has external connections to static routes.

You also configure the ABR in area 9 with the following additional settings:

  • no-summaries—Prevents the ABR from advertising summary routes into the NSSA. If configured in combination with the default-metric statement, the NSSA only allows routes internal to the area and advertises the default route into the area. External routes and destinations to other areas are no longer summarized or allowed into the NSSA. Only the ABR requires this additional configuration because it is the only routing device within the NSSA that creates Type 3 LSAs used to receive and send traffic from outside the area.
  • default-lsa—Configures the ABR to generate a default route into the NSSA. In this example, you configure the following:
    • default-metric—Specifies that the ABR generate a default route with a specified metric into the NSSA. This default route enables packet forwarding from the NSSA to external destinations. You configure this option only on the ABR. The ABR does not automatically generate a default route when attached to an NSSA. You must explicitly configure this option for the ABR to generate a default route.
    • metric-type—(Optional) Specifies the external metric type for the default LSA, which can be either Type 1 or Type 2. When OSPF exports route information from external ASs, it includes a cost, or external metric, in the route. The difference between the two metrics is how OSPF calculates the cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the internal costs plus the external cost. Type 2 external metrics use only the external cost assigned by the AS boundary router. By default, OSPF uses the Type 2 external metric.
    • type-7—(Optional) Floods Type 7 default LSAs into the NSSA if the no-summaries statement is configured. By default, when the no-summaries statement is configured, a Type 3 LSA is injected into NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier Junos OS releases, include the type-7 statement.

The second example also shows the optional configuration required to disable exporting Type 7 LSAs into the NSSA by including the no-nssa-abr statement on the routing device that performs the functions of both an ABR and an AS boundary router.

Figure 3: OSPF Network Topology with Stub Areas and NSSAs

OSPF Network
Topology with Stub Areas and NSSAs

Configuration

Configuring Routing Devices to Participate in a Not-So-Stubby-Area

CLI Quick Configuration

To quickly configure an OSPF NSSA, copy the following command and paste it into the CLI. You must configure all routing devices that are part of the NSSA.

[edit] set protocols ospf area 0.0.0.9 nssa

To quickly configure an ABR that participates in an OSPF NSSA, copy the following commands and paste them into the CLI.

[edit] set protocols ospf area 0.0.0.9 nssa default-lsa default-metric 10set protocols ospf area 0.0.0.9 nssa default-lsa metric-type 1set protocols ospf area 0.0.0.9 nssa default-lsa type-7set protocols ospf area 0.0.0.9 nssa no-summaries

Step-by-Step Procedure

To configure OSPF NSSAs:

  1. On all routing devices in the area, configure an OSPF NSSA.

    Note: To specify an OSPFv3 NSSA area, include the ospf3 statement at the [edit protocols] hierarchy level.

    [edit]user@host# set protocols ospf area 0.0.0.9 nssa
  2. On the ABR, enter OSPF configuration mode and specify the NSSA area 0.0.0.9 that you already created.
    [edit ]user@host# edit protocols ospf area 0.0.0.9 nssa
  3. On the ABR, inject a default route into the area.
    [edit protocols ospf area 0.0.0.9 nssa]user@host# set default-lsa default-metric 10
  4. (Optional) On the ABR, specify the external metric type for the default route.
    [edit protocols ospf area 0.0.0.9 nssa]user@host# set default-lsa metric-type 1
  5. (Optional) On the ABR, specify the flooding of Type 7 LSAs.
    [edit protocols ospf area 0.0.0.9 nssa]user@host# set default-lsa type-7
  6. On the ABR, restrict summary LSAs from entering the area.
    [edit protocols ospf area 0.0.0.9 nssa]user@host# set no-summaries
  7. If you are done configuring the devices, commit the configuration.
    [edit protocols ospf area 0.0.0.9 nssa]user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuration on all routing devices in the area:

user@host# show protocols ospf
area 0.0.0.9 { nssa;}

Configuration on the ABR. The output also includes the optional metric-type and type-7 statements.

user@host# show protocols ospf area 0.0.0.9 {nssa {default-lsa {default-metric 10;metric-type 1;type-7;}no-summaries;}}

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

Disabling the Export of Type 7 Link State Advertisements into Not-So-Stubby Areas

CLI Quick Configuration

To quickly disable exporting Type 7 LSAs into the NSSA, copy the following command and paste it into the CLI. You configure this setting on an AS boundary router that is also an ABR with an NSSA area attached.

[edit] set protocols ospf no-nssa-abr

Step-by-Step Procedure

You can configure this setting if you have an AS boundary router that is also an ABR with an NSSA area attached.

  1. Disable exporting Type 7 LSAs into the NSSA.

    Note: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

    [edit]user@host# set protocols ospf no-nssa-abr
  2. If you are done configuring the device, commit the configuration.
    [edit]user@host# commit

Results

Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

user@host# show protocols ospf
no-nssa-abr;

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

Verification

Confirm that the configuration is working properly.

Verifying the Interfaces in the Area

Purpose

Verify that the interface for OSPF has been configured for the appropriate area. Confirm that the output includes Stub NSSA as the type of OSPF area.

Action

From operational mode, enter the show ospf interface detail command for OSPFv2, and enter the show ospf3 interface detail command for OSPFv3.

Verifying the Type of OSPF Area

Purpose

Verify that the OSPF area is a stub area. Confirm that the output displays Not so Stubby Stub as the Stub type.

Action

From operational mode, enter the show ospf overview command for OSPFv2, and enter the show ospf3 overview command for OSPFv3.

Verifying the Type of LSAs

Purpose

Verify the type of LSAs that are in the area. If you disabled exporting Type 7 LSAs into an NSSA, confirm that the Type field does not include NSSA as a type of LSA.

Action

From operational mode, enter the show ospf database command for OSPFv2, and enter the show ospf3 database command for OSPFv3.

Published: 2013-09-24