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:
Suresh Vinasiththamby
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
Thanks for reading
As always, your feedback and comments are more than welcome.
