Packetswitch Home NetDevOps Cisco Firewall ISE Juniper Ansible About me Contact me / Subscribe

JUNIPER

Configuring Junos OSPF Stub and NSSA

Areas
Suresh Vina
Aug 23, 2020 9 min read

In: Juniper SHARE

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 1 Junos

Type-5 External LSAs are originated by an ASBR and

flooded within the OSPF domain.

Packetswitch • • Suresh Vinasiththamby

Diagram

Area1 Area0 Area2

RID-1.1.1.1 /RID-3.3.3.3 RID-4.4.4.4

RID-2.2.2.2
12.1 12.2 23.1 23.2 34.1 34.2

VMX1 VMX2
VMX3 VMX4

IPADDRESSING
10.100.x.x/24
VMX5

172.16.31.0/24

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 (vMX3C 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 IType-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 INSSAO.

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
I172.16.31.0/24O 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 (vMX1C generates NSSA external
KType 7C 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 (vMX2C 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.

1 root@vMX4> show ospf database

2
3 OSPF database, Area 0.0.0.2
4 Type ID Adv Rtr Seq Age Opt Cksum Len
5 Router 3.3.3.3 3.3.3.3 0x80000002 67 0x22 0x5f77 48
6 Router *4.4.4.4 4.4.4.4 0x80000002 64 0x22 0xfbd6 48
7 Summary 10.100.12.0 3.3.3.3 0x80000001 80 0x22 0x872d 28
8 Summary 10.100.23.0 3.3.3.3 0x80000002 90 0x22 0x2a7 28
9 ASBRSum 1.1.1.1 3.3.3.3 0x80000001 69 0x22 0x723 28
10 OSPF AS SCOPE link state database
11 Type ID Adv Rtr Seq Age Opt Cksum Len
12 Extern 172.16.31.0 1.1.1.1 0x80000001 85 0x22 0x7cb 36
13
14 root@vMX4> show route
15
16 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
17 + = Active Route, - = Last Active, * = Both
18
19 10.100.12.0/24 *[OSPF/10] 00:01:08, metric 3
20 > to 10.100.34.1 via ge-0/0/0.0
21 10.100.23.0/24 *[OSPF/10] 00:01:08, metric 2
22 > to 10.100.34.1 via ge-0/0/0.0
23 10.100.34.0/24 *[Direct/0] 00:01:13
24 > via ge-0/0/0.0
25 10.100.34.2/32 *[Local/0] 00:01:13
26 Local via ge-0/0/0.0
27 172.16.31.0/24 *[OSPF/150] 00:01:08, metric 0, tag 0
28 > to 10.100.34.1 via ge-0/0/0.0
29 224.0.0.5/32 *[OSPF/10] 00:01:41, metric 1
30 MultiRecv
31

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 (vMX3C

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 — IOptional) 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 (vMX2C 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 — IOptional) 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.

1 root@vMX1> show ospf database nssa extensive

2
3 OSPF database, Area 0.0.0.1
4 Type ID Adv Rtr Seq Age Opt Cksum Len
5 NSSA 0.0.0.0 2.2.2.2 0x80000002 256 0x20 0xa57a 36
6 mask 0.0.0.0
7 Topology default (ID 0)
8 Type: 1, Metric: 10, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
9 Aging timer 00:55:43
10 Installed 00:04:13 ago, expires in 00:55:44
11 Last changed 00:24:26 ago, Change count: 1
12 NSSA *172.16.31.0 1.1.1.1 0x80000002 1466 0x28 0x5cf1 36
13 mask 255.255.255.0
14 Topology default (ID 0)
15 Type: 2, Metric: 0, Fwd addr: 10.100.12.1, Tag: 0.0.0.0
16 Gen timer 00:25:33
17 Aging timer 00:35:33
18 Installed 00:24:26 ago, expires in 00:35:34, sent 00:24:24 ago
19 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
I'm very excited to start blogging and share with you insights about my favourite Networking,
Cloud and Automation topics. Simple guy with simple taste and lots of love for Networking and
Automation.

View all posts

Comments

Start the conversation

Become a member of Packetswitch to start commenting.

Sign up now

Already a member? Sign in

More from Packetswitch

JUNIPER
JUNIPER JUNIPER
Juniper Multicast PIM
Configuring PIM AnyCast Juniper Source-Specific Sparse Mode
RP with MSDP on Juniper Multicast (SSM)
PIM Sparse mode uses an 'explicit join'
What problem does AnyCast RP solves? In the previous articles, we have discussed approach whereas PIM Dense mode uses
Having a single active rendezvous point about PIM Dense Mode and PIM Sparse 'implicit join' approach. With PIM Sparse
FRPG is a single point of failure. Anycast Mode. Both protocols use IGMPv2 and mode,

Suresh Vina Suresh Vina Suresh Vina

Oct 13, 2020 7 min read Oct 10, 2020 7 min read Oct 7, 2020 10 min read

PACKETSWITCH NAVIGATION SOCIAL

Home Privacy Policy Facebook

A collection of articles focusing on Networking, Cloud
NetDevOps Twitter
and Automation
RSS
Cisco
Your email address SUBSCRIBE Firewall
ISE
Juniper
Ansible
About me
Contact me

©2022 Packetswitch. Published with Ghost & Fumio.