Juniper

Configuring Junos OSPF Stub and NSSA Areas

In: Juniper

In the previous post, we discussed Type-4 and Type-5 LSAs. This article focuses on Stub and NSSA areas. I highly recommend you to read my previous post here:

OSPF Type-4 & Type-5 LSAs - Junos
Type-5 External LSAs are originated by an ASBR and flooded within the OSPF domain.

Diagram

Problem

As you can see on the diagram that External routes and routes from other areas are flooding throughout the OSPF domain. If these 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.

Stub Areas

For example, Area 2 is not directly connected to the outside network. All outbound traffic is routed through the ABR (vMX3) to the backbone and then to the destination addresses. By designating Area-2 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.

Stub areas are areas through which or into which OSPF does not flood AS external link-state advertisements (Type-5 LSAs).

Stub Area restrictions:

  • You cannot create a virtual link through a stub area.
  • A stub area cannot contain an ASBR.
  • 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).

Totally-Stub Area

A stub area that only allows routes internal to the area and restricts Type-3, Type-5 LSAs from entering the stub area is often called a totally stubby area. You can convert Area-2 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.

You must explicitly configure the ABR to generate a default route when attached to a stub or not-so-stubby-area (NSSA).

Not-So-Stubby Areas

Area-1 has no external connections. However, Area-1 has static route (172.16.31.0/24) that are not internal OSPF route. You can limit the external route advertisements to the area and advertise the static routes by designating the area an NSSA. In an NSSA, the ASBR (vMX1) 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 ASBR and their corresponding external routing information. The ABR (vMX2) converts Type-7 LSAs into Type-5 External LSAs and leaks them to the other areas, but external routes from other areas are not advertised within the NSSA.


Configuring OSPF Stub and Totally Stubby Areas

Totally-Stub (Area-2)

Le's take a look at the OSPF database and routing table on MX4 before making the change.

root@vMX4> show ospf database

    OSPF database, Area 0.0.0.2
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   3.3.3.3          3.3.3.3          0x80000002    67  0x22 0x5f77  48
Router  *4.4.4.4          4.4.4.4          0x80000002    64  0x22 0xfbd6  48
Summary  10.100.12.0      3.3.3.3          0x80000001    80  0x22 0x872d  28
Summary  10.100.23.0      3.3.3.3          0x80000002    90  0x22 0x2a7   28
ASBRSum  1.1.1.1          3.3.3.3          0x80000001    69  0x22 0x723   28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   172.16.31.0      1.1.1.1          0x80000001    85  0x22 0x7cb   36

root@vMX4> show route

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.100.12.0/24     *[OSPF/10] 00:01:08, metric 3
                    > to 10.100.34.1 via ge-0/0/0.0
10.100.23.0/24     *[OSPF/10] 00:01:08, metric 2
                    > to 10.100.34.1 via ge-0/0/0.0
10.100.34.0/24     *[Direct/0] 00:01:13
                    > via ge-0/0/0.0
10.100.34.2/32     *[Local/0] 00:01:13
                      Local via ge-0/0/0.0
172.16.31.0/24     *[OSPF/150] 00:01:08, metric 0, tag 0
                    > to 10.100.34.1 via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 00:01:41, metric 1
                      MultiRecv

Let's make Area-2 a Totally-Stub area and check the database and route table again.

root@vMX3# show | compare
[edit protocols ospf area 0.0.0.2]
+     stub default-metric 10 no-summaries;


root@vMX4# show | compare
[edit protocols ospf area 0.0.0.2]
+     stub
root@vMX4> show ospf database

    OSPF database, Area 0.0.0.2
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   3.3.3.3          3.3.3.3          0x80000004     4  0x20 0x795d  48
Router  *4.4.4.4          4.4.4.4          0x80000004     3  0x20 0x16bc  48
Summary  0.0.0.0          3.3.3.3          0x80000001    99  0x20 0xb177  28

root@vMX4> show route

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/10] 00:00:06, metric 11
                    > to 10.100.34.1 via ge-0/0/0.0
10.100.34.0/24     *[Direct/0] 00:06:07
                    > via ge-0/0/0.0
10.100.34.2/32     *[Local/0] 00:06:07
                      Local via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 00:06:35, metric 1
                      MultiRecv

As you can see above, vMX4 doesn't have individual Typ-3 LSAs and Type-5 external LSAs. vMX4 also received a default route from the ABR (vMX3)

  • 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-2 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. 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.


Not-So-Stubby Area (Area-1)

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.

Let's check the OSPF database and route table on vMX1 before make the change.

root@vMX1> show ospf database

    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.1          1.1.1.1          0x80000003    22  0x22 0xc553  48
Router   2.2.2.2          2.2.2.2          0x80000003   477  0x22 0x62b2  48
Summary  10.100.23.0      2.2.2.2          0x80000003  1846  0x22 0x1e8e  28
Summary  10.100.34.0      2.2.2.2          0x80000002   933  0x22 0xb0f0  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern  *172.16.31.0      1.1.1.1          0x80000002    27  0x22 0x5cc   36

root@vMX1> show route

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.100.12.0/24     *[Direct/0] 00:50:30
                    > via ge-0/0/0.0
10.100.12.1/32     *[Local/0] 00:50:30
                      Local via ge-0/0/0.0
10.100.15.0/24     *[Direct/0] 00:50:30
                    > via ge-0/0/1.0
10.100.15.1/32     *[Local/0] 00:50:30
                      Local via ge-0/0/1.0
10.100.23.0/24     *[OSPF/10] 00:50:20, metric 2
                    > to 10.100.12.2 via ge-0/0/0.0
10.100.34.0/24     *[OSPF/10] 00:50:20, metric 3
                    > to 10.100.12.2 via ge-0/0/0.0
172.16.31.0/24     *[Static/5] 00:50:30
                    > to 10.100.15.2 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 00:50:58, metric 1
                      MultiRecv

Let's make Area-1 an NSSA area and check the database and route table again.

root@vMX1# show | compare
[edit protocols ospf area 0.0.0.1]
+     nssa;

root@vMX2# show | compare
[edit protocols ospf area 0.0.0.1]
+     nssa {
+         default-lsa {
+             default-metric 10;
+             type-7;
+         }
+         no-summaries;
+     }

[edit]
root@vMX1> show ospf database

    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.1          1.1.1.1          0x80000004    14  0x20 0xe138  48
Router   2.2.2.2          2.2.2.2          0x80000004    15  0x20 0x848f  48
NSSA     0.0.0.0          2.2.2.2          0x80000001    25  0x20 0xa779  36
NSSA    *172.16.31.0      1.1.1.1          0x80000002    14  0x28 0x5cf1  36

root@vMX1> show route

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/150] 00:00:26, metric 11, tag 0
                    > to 10.100.12.2 via ge-0/0/0.0
10.100.12.0/24     *[Direct/0] 00:54:28
                    > via ge-0/0/0.0
10.100.12.1/32     *[Local/0] 00:54:28
                      Local via ge-0/0/0.0
10.100.15.0/24     *[Direct/0] 00:54:28
                    > via ge-0/0/1.0
10.100.15.1/32     *[Local/0] 00:54:28
                      Local via ge-0/0/1.0
172.16.31.0/24     *[Static/5] 00:54:28
                    > to 10.100.15.2 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 00:54:56, metric 1
                      MultiRecv

no-summaries — Prevents the ABR (vMX2) 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.

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.


We can verify the Type-7 LSA exchange between vMX1 and vMX2 by using packet capture.

root@vMX1> show ospf database nssa extensive

    OSPF database, Area 0.0.0.1
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
NSSA     0.0.0.0          2.2.2.2          0x80000002   256  0x20 0xa57a  36
  mask 0.0.0.0
  Topology default (ID 0)
    Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
  Aging timer 00:55:43
  Installed 00:04:13 ago, expires in 00:55:44
  Last changed 00:24:26 ago, Change count: 1
NSSA    *172.16.31.0      1.1.1.1          0x80000002  1466  0x28 0x5cf1  36
  mask 255.255.255.0
  Topology default (ID 0)
    Type: 2, Metric: 0, Fwd addr: 10.100.12.1, Tag: 0.0.0.0
  Gen timer 00:25:33
  Aging timer 00:35:33
  Installed 00:24:26 ago, expires in 00:35:34, sent 00:24:24 ago
  Last changed 00:24:42 ago, Change count: 1, Ours

vMX1 is sending Type-7 LSA for 172.16.31.0/24 and vMX2 is sending Type-7 LSA for a default route.

Reference

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ospf-stub-and-not-so-stubby-areas.html

Thanks for reading

As always, your feedback and comments are more than welcome.

Written by
Suresh Vina
Tech enthusiast sharing Networking, Cloud & Automation insights. Join me in a welcoming space to learn & grow with simplicity and practicality.
Comments
More from Packetswitch
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Packetswitch.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.