NSSA

OSPF Filtering with Distribute-Lists

In the first installments of the OSPF filtering series, we were able to discuss the three major filtering techniques in OSPF: LSA Type-3 Filtering, NSSA External Routes Filtering and Filtering with Summarization.   I have also mentioned in the first Post of the series some “Corner Cases” where is necessary apply filtering in places other than ABRs or ASBRs.   This is achieved by applying filtering to the OSPF RIB using Distribute-Lists.

Well, time has come to talk about using Distribute-Lists to filter “Routes”.

Please note that I have quoted the word “Routes”.   We must be clear that OSPF is a link-state protocol.   OSPF don’t advertise routes per se, OSPF advertises topology information.   The routers participating in OSPF share an identical copy of the Link-State Database (LSDB) for the areas where are participating.    So far we have been achieving filtering but not by actually filtering routes perse, we have been “modifying” some LSAs in such way OSPF will simply end up discarding the LSA from the LSDB.

When we applied LSA Type-3 filtering, what we have done is modifying the LSA generated by the ABR with the LSA AGE set to its max-age value. Therefore, the LSA is eventually withdrawn from the topology.  We didn’t actually prevent the LSA from being formed.   It’s the same effect when we apply OSPF Filtering with Summarization.   In this case, we have summarized a group of prefixes before generating the LSA with the max-age value set.

For NSSA external route filtering, the only thing we did was just instructing the ASBR to generate the Type-7 LSA without the P-Bit set.   When ASBRs generates Type-7 LSAs, they do it with the P-Bit set by default.   The P-Bit or Propagate-Bit instructs ABRs connecting the area to perform Type-7 to Type-5 translation.   In other words, LSAs without the P-Bit set won’t be advertised beyond the NSSA.

Now, since the Link-State Database (LSDB) must be the identical within areas, what can be done to filter the required routes?

The solution here is filtering the routes from entering the routing table by using the distribute-list {access-list-number|name} {gateway} {prefix-list} {route-map} in|out OSPF process command.

Now, there are some rules to be considered when using distribute-lists:

  • The distribute-list command is used to filter routes from being installed in the routing table or redistributed into another routing protocol, it does not filter LSAs.
  • Using the distribute-list command in the inbound direction is used to filter routes to be installed in the routing table.
  • Using the distribute-list command in the outbound direction filters only the desired redistributed routes. Meaning that is used only on ASBR’s.

We must be careful when using this command, as mentioned before this applies filtering to the Global RIB; it doesn’t prevent the LSAs from being advertised.   Therefore, it may cause a traffic black hole.

Let’s use the following topology for the examples:

OSPF-FILTERING-3-01

Here you can download the diagram and configuration files:  OSPF-Filtering – Part III

Using the distribute-list command in the inbound direction:

Goal 1:

Filter the route to 2.2.2.2 in R4.

First, let’s take a look to the routing table in R4:

OSPF-FILTERING-3-02

As can be seen in the above output, the route 2.2.2.2/32 is in the routing table.  It is displayed as an “O” OSPF route, meaning that it was advertised from another OSPF-enabled router within the same area (intra-area).   From this output, we can conclude that the prefix was advertised via a Type-1 (Router) LSA.

Just as a reference, let’s take a look to the Type-1 (Router) LSA:

OSPF-FILTERING-3-03

As can be seen in the output, the LSA has 3 link advertisements enclosed.  One LSA corresponds to the Stub Network 2.2.2.2/32 and the last two corresponds to the Transit Networks.

Ok, because the advertising router 0.0.0.2 (R2) is placed in the same area, the only possible filtering option is by using distribute-list in the inbound direction.

So, let’s apply the filter using a simple ACL.

In R4:

!
access-list 2 deny   2.2.2.2
access-list 2 permit any
!
router ospf 1
distribute-list 2 in
exit
!

Now, let’s take a look at the routing table of R4:

OSPF-FILTERING-3-04

As can be seen in the output, the route is no longer present.  What about the LSDB?  What was the effect of the filter in there?

OSPF-FILTERING-3-05

As can be seen, the Type-1 LSA is still there.   There was no effect on the LSDB.   Now let’s take a look to the OSPF RIB:

OSPF-FILTERING-3-06

Have you noticed the difference?  Yes, the “greater than symbol” next to the route.  This means the route is present but it wasn’t marked as Best.   Thus, the route is not installed in the Router’s RIB.

Now, we could achieve the same result by using extended ACLS.

Let me show you a trick.    Not long ago I was requested to filter a specific route, the same way it was done before.   However, the request also has included one very specific requirement as well.  The filter must apply only over business hours, Monday thru Friday from 7:00 am to 7:00 pm.

Here goes how to do it:   (This requires time synchronization.)

  1. Create a Time-Based ACL.
  2. Apply the distribute-list referencing the Time-Based ACL.

In R4:

!
time-range NO-ACCESS
periodic weekdays 7:00 to 19:00
!
access-list 102 deny   ip any host 2.2.2.2 time-range NO-ACCESS
access-list 102 permit ip any any
!
router ospf 1
distribute-list 102 in
exit
!

Another way to do it is by using prefix-lists:

In R4:

!
ip prefix-list NO-LO-R2 seq 10 deny 2.2.2.2/32
ip prefix-list NO-LO-R2 seq 20 permit 0.0.0.0/0 le 32
!
router ospf 1
distribute-list prefix NO-LO-R2 in
exit
!

Another possible thing we can do with distribute-list is matching the source of the route.  To clarify this, by the source of the route I mean the gateway used to reach the route to be filtered.

Let’s make a small change to the topology for this:

OSPF-FILTERING-3-07

Let’s add the link in red and remove any configured filtering.

The link configurations are as follows:

In R3:

!
interface Ethernet0/2
ip address 192.168.34.3 255.255.255.0
ip ospf 1 area 0
!

In R4:

!
interface Ethernet0/2
ip address 192.168.34.4 255.255.255.0
ip ospf 1 area 0
!

Ok, now let’s take a look at the routing table in R4:

OSPF-FILTERING-3-08

As can be seen in the above output, by adding this link, R4 has now two equal cost paths to reach networks beyond the transit network 192.168.123.0/24.

Goal 2:

Apply filtering in such way that the Loopback0 in R1 be can be reached from R4 only thru R2.

Ok, so far we know the route to 1.1.1.1/32 (Loopback 0 in R1) is being load-balanced.   This is because OSPF is doing ECMP (Equal Cost Multi-Path) between R2 and R3.   What we must do is filtering only the route through R3.

There are two ways to achieve this.   One applying the distribute-list using one of the different ways we have learned so far (access-list, extended ACL, named ACL or prefix-list) and specify the interface from where is learning the route.

Let’s try it this way:

For this example, I would use a named ACL.

In R4:

!
ip access-list standard R1_Loopback0
deny   1.1.1.1
permit any
!
router ospf 1
distribute-list R1_Loopback0 in Ethernet0/2
!

Now, let’s take a look at the routing table in R4 and to the details of the OSPF RIB for that particular route:

OSPF-FILTERING-3-09

As can be seen in the above output, the route to 1.1.1.1/32 is now reachable only via R2.  The rest of the routes remain to be load-balanced.    Also, take a look to the OSPF RIB.   Both routes are present.   However, the one with the arrow in blue through R3 has no RIB flag, while the other route, thru R2, has it.    Only the route in green was installed into the Router’s routing table.

The other way to achieve this goal is by using Route-Maps.   Route-Maps provide more flexibility than ACLS or Prefix-Lists.   With route-maps we can match multiple options such:

  • match interface
  • match ip {address|next-hop|route-source}
  • match metric
  • match route-type {internal|external [type-1|type-2] | nssa-external [type-1|type-2]}
  • match tag

We could achieve the same result by using the following configuration:

In R4:

!
ip prefix-list Filter-R1-L0 seq 5 permit 1.1.1.1/32
!
route-map FILTER->RIB deny 10
match ip address prefix-list Filter-R1-L0
match interface Ethernet0/2
!
route-map FILTER->RIB permit 100
!
router ospf 1
distribute-list route-map FILTER->RIB in
exit
!

I think that you get the idea.

Now, why have I mentioned that we must be careful when using this command?

I will use another example to illustrate why.  Let’s use the original topology, without any filtering.

OSPF-FILTERING-3-01

 

Goal 3:

Filter the route to 1.1.1.1 only in R2.

It seems a fairly simple task now that we know how to do it.   So let’s apply the filter in R2.

In R2:

!
access-list 1 deny   1.1.1.1
access-list 1 permit any
!
router ospf 1
distribute-list 1 in
exit
!

Now let’s take a look at the routing table in R2:

OSPF-FILTERING-3-10

Ok, as shown in the above output, seems that it worked.  The route to 1.1.1.1 is no longer in the routing table of R2.

Let’s say it’s the last trouble ticket of the day.  Then we proceed to turn off the computer and drive back home.   That’s it for the day.

An hour later, we receive a phone call reporting problems to reach 1.1.1.1 from R4.

OSPF-FILTERING-3-11

But, wait a minute!  We did not make any change to R4.  Do we?

As a matter of fact, yes indirectly we did it. We have created a black hole in the network.

Let me explain this.

When we apply the filter to the route 1.1.1.1, it was applied directly to the routing table.  The LSDB was not altered.  R4 has received an LSA from R2 containing information how to reach 1.1.1.1, thus, R4 has installed the route in its routing table.

Guess what is the next-hop to reach 1.1.1.1 from R4?   Yes.  It’s the same next-hop used to reach any other network, R2.

Now you know why OSPF RIB filtering must be used carefully.   This was just an example, but what if we make the same mistake to a high sensitive area of the production network?   This could be a Resume Generating Event.

Using the distribute-list command in the outbound direction:

As mentioned before, using the distribute-list command in the outbound direction filters only the redistributed routes.   Meaning that is used only on ASBR’s.

Goal 4:

Prevent the route to 55.55.55.55/32 from being advertised beyond R1.

Let’s turn on the debug ip ospf lsa-generation for this example.

In R1:

!
debug ip ospf lsa-generation
!
configure terminal
!
access-list 55 deny   55.55.55.55
access-list 55 permit any
!
router ospf 1
distribute-list 55 out
exit
!

Let’s take a look at the output of the debug.

OSPF-FILTERING-3-12

Immediately after applying the filter, R1 generated a Type-5 LSA with the max-age set (3600 seconds).  Remember, LSAs with max age set are discarded.  Also, note the metric was set to 16777215.  This is the maximum metric for routes in the OSPF database in decimal.  A route with this metric is inaccessible therefore is discarded from the OSPF database.  This metric is also known as LSInfinity.   The result is the filtering of the desired route from the OSPF domain.

Let’s confirm this by looking the routing table in R4:

OSPF-FILTERING-3-13

As can be seen in the above output, the filtering worked as expected.   The route to 55.55.55.55/32 is not present in the routing table.

There is one last thing to mention in regards to filtering.  It has to do with NSSA areas.

Let’s modify a little bit the topology:

OSPF-FILTERING-3-14

 

Let’s put R4 into an NSSA area and create loopback1, let’s redistribute it into the process.  Let’s also remove any filtering in R2.

In R2:

!
router ospf 1
area 24 nssa
!
interface Ethernet0/1
ip ospf 1 area 24
!

In R4:

!
interface Loopback0
ip ospf 1 area 24
!
interface Loopback1
ip address 44.44.44.44 255.255.255.255
!
route-map CONN-LOOPBACKS->OSPF permit 10
match interface Loopback1
!
router ospf 1
area 24 nssa
redistribute connected subnets route-map CONN-LOOPBACKS->OSPF
exit
!

With this configuration applied, R4 has generated and flooded a Type-7 LSA within the area, corresponding to the redistributed route. R2 (ABR) received the Type-7 LSA with the P-bit set; R2 then has generated a Type-5 LSA and start advertising the redistributed route on behalf of R4.

Let’s take a look at the routing table in R2, just to confirm that the route is there.

OSPF-FILTERING-3-15

Ok, the route was installed. Now, let’s apply filtering to 4.4.4.4 (Loopback0) in R2.

In R2:

!
ip access-list standard R4_L0
deny   4.4.4.4
permit any
!
router ospf 1
distribute-list R4_L0 in
exit
!

Finally, let’s take a look at the routing table in R2 and take a look at the results:

OSPF-FILTERING-3-16

Ok, the filtering didn’t work as expected.   The route to 4.4.4.4/32 was filtered, but also, the route to the redistributed 44.44.44.44/32 was removed from the routing table.

So, what happened here?

First, let’s take a look to the LSDB and then to the OSPF RIB in R2:

OSPF-FILTERING-3-17

Ok, as can be seen in the above output, the Type-7 LSA is there, the route 4.4.4.4/32 was filtered in the OSPF RIB (It doesn’t have the greater than symbol or RIB flag).  Also, the route 44.44.44.44/32 is not present in the OSPF RIB.

Now, let’s take a look to the Type-7 LSA and try to figure out what the problem is.

OSPF-FILTERING-3-18

 

Ok, did you find the problem?

The P-bit is there.  Meaning the translation from Type-7 to Type-5 must take place.   That is not the problem.   What about the forward address?   Yup, you got it.   At the moment we filter 4.4.4.4, the route finds itself without next-hop.  Thus, the LSA was discarded.

The problem has to do with the way NSSA advertise redistributed routes.  NSSA choose the forwarding address as follows:

It chooses the highest IP address of an internal address; if an internal address is not available, it will prefer the higher found OSPF stub network.

It is good to emphasize that although filtering the OSPF RIB sometimes seems a good idea, in some cases; it may lead to undesired behaviors and in extreme cases may end in self-inflicted denial of service.   So, use it carefully.

It is time to close this long post. In the next one, we will continue discussing OSPF Filtering but, this time, using Administrative Distance.

Thank you for visiting.

Traffic Engineering with OSPF Summarization (Part 2)

In the last post, we discussed how to modify the traffic path using summarization for external routes. Today we will continue discussing Traffic Engineering using OSPF summarization for intra-area routes.    So, let’s get started.

Just to recap:   The Inter-Area summarization is performed in ABRs, it summarizes Type-1 into Type-3 LSAs.   We can perform OSPF traffic engineering with summarization when we have multiple exit points out of an area or multiple exit points out of the autonomous system using longer prefix match over shorter prefix match routing.

Let’s use the same topology we have been using so far but with a few changes:

OSPF-SUMMARY-APPS-2-01

Here you can download the diagram and configuration files: TE with OSPF Summarization – Part II

Among the changes done with respect to the topology used in the previous post, I can mention the creation and advertisement of 10 loopback interfaces in R1, the interface Lo0 in R1 is not being advertised into OSPF and the re-numbering of the loopback interfaces in R4.  Another change is the ospf cost manually set to 20 in the Ethernet0/1 interface of R3.

Let’s take a look to the routing table from the perspective of R1:

OSPF-SUMMARY-APPS-2-02

As can be seen in the above output, R1 is routing the eastbound traffic through R2. This is because of the higher OSPF cost assigned in the interface Ethernet0/1 of R3.

Now let’s take a look to the routing table from the perspective of R4:

OSPF-SUMMARY-APPS-2-03

From R4’s perspective, westbound traffic is load-balanced.  So, let’s play a little bit with traffic engineering.

Goal 1:

Eastbound traffic from R1 destined to the loopback interfaces in R4 must go through R2.

Let’s start by taking a look to the LSA corresponding to the loopbacks:  (One loopback will be fine, the rest will have the same output.)

OSPF-SUMMARY-APPS-2-04

As shown in the output, both ABRs generated LSAs corresponding to the route 10.4.1.0/24; however only the route with best metric was installed in the routing table.

To achieve the goal, we will have to summarize the loopbacks in one of the ABRs and take advantage of longer prefix match over shorter prefix match routing.   Because the goal dictates route through R3 we have to summarize the routes in the ABR R2, so let’s summarize the loopbacks into a /20 range which covers from 10.4.1.1 to 10.4.15.254.

In R2 (ABR):

!
router ospf 1
area 0 range 10.4.0.0 255.255.240.0
!

Now let’s take a look to the routing table in R1:

OSPF-SUMMARY-APPS-2-05

As can be seen in the above output, a summary route (10.4.0.0/20) was advertised from R2 and the more specific routes are now being advertised by R3.

Let’s take a look at link-state database in R2, specifically Area 30:

OSPF-SUMMARY-APPS-2-06

 

What happened here was that unlike R3, R2 ABR instead generating Type-3 LSAs for each loopback interface, it generates a single Type-3 summary LSA.  Thus, R3 advertise more specific routes to R1.

Finally, let’s test the solution tracing routes to the loopbacks and directions in R5 and R7.

OSPF-SUMMARY-APPS-2-07

As seen in the above output, the solution worked.   The first trace sourced from Loopback1 in R1 route through R3 to reach Loopback1 in R4.  The other traces route through R2 to reach the loopbacks in R5 and R7 respectively.

Let’s complicate a little bit more the traffic engineering examples.

Goal 2:

We have been requested to divide the westbound traffic from R1 towards R4 loopback interfaces into two summary addresses and route them as follows:

  • The Summary Address 10.1.0.0/21 must be routed through R3.
  • The Summary Address 10.1.8.0/21 must be routed through R2.
  • In the routing table of R4, only the summarized ranges belonging to the loopback interfaces of R1 must be displayed.

So, let’s do it.

First, let’s take a look to the routing table from the perspective of R4:

OSPF-SUMMARY-APPS-2-08

As shown above, all of the westbound traffic is being load-balanced between R2 and R3 ABRs.

So, let’s proceed with the tasks:

Create the summary address 10.1.0.0/21 in R2 and the summary address 10.1.8.0/21 in R3.

In R2 (ABR):

!
router ospf 1
area 30 range 10.1.0.0 255.255.248.0
!

In R3 (ABR):

!
router ospf 1
area 30 range 10.1.8.0 255.255.248.0
!

Now let’s take a look to the routing table of R4:

OSPF-SUMMARY-APPS-2-09

Well, the summarization works as shown above.  The traffic towards R1’s loopback interfaces is routed as requested. But the routing table also has more specific routes instead summaries.   Also, note the routes for the external domain.   The routes to 172.16.0.0/16 and 192.168.16.0/30 are now been advertised only via R3.  But why?

Now we have two things to figure it out.

Let’s start with the summarization problem, and then we will see what happened to those routes.

For the summarization, we know that the more specific routes rule is working.  Now we have to find the way to suppress them.

If we also apply summarization of the specific routes in each ABR we will have again load-balancing.   Let’s make the change and take a look.   Of course, we have to apply the same summarization applied to the ABRs in an inverse way.   In other words, the summarization applied to R3 into R2 and vice versa.

In R2 (ABR):

!
router ospf 1
area 30 range 10.1.8.0 255.255.248.0
!

In R3 (ABR):

!
router ospf 1
area 30 range 10.1.0.0 255.255.248.0
!

After the changes were applied both ABRs will have summarization applied for both ranges in their routing process as follows:

OSPF-SUMMARY-APPS-2-10

OSPF-SUMMARY-APPS-2-11

Now, let’s take a look again to the routing table in R4:

OSPF-SUMMARY-APPS-2-12

Ok, the summary addresses are now being load-balanced, but wait a minute!  Now we have again the routes to the External domain load-balanced.  This means the change we just did is directly related.   We will go back to this in a minute.   Let’s finish the first problem.

As can be seen in the above output, the summary addresses are being load balanced because they have identical metric.

OSPF-SUMMARY-APPS-2-13

Now what we can do to change the traffic pattern is modify the metric to the summary addresses.

To do this, we will have to manually alter the cost on each ABR for the desired routes.

Let’s make the following change:

Because the summary Address 10.1.0.0/21 must be routed through R3, let’s modify the cost of the summary address in the ABR R2 and make it higher and let’s take a look at the result in the routing table of R4.

In R2 (ABR):

!
router ospf 1
area 30 range 10.1.0.0 255.255.248.0 cost 20
!

OSPF-SUMMARY-APPS-2-14

As shown in the above output, now the route 10.1.0.0/21 is now reachable only via R3.

Now, let’s take a look at the summary Type-3 LSA:

OSPF-SUMMARY-APPS-2-15

As can be seen, the metric of the LSA advertisement is now 20 when received from R2 and 11 when received from R3.   Now, the lowest metric wins thus its installed in the RIB.

Now let’s do the change for the other summary route.

Because the summary Address 10.1.8.0/21 must be routed through R2, let’s modify the cost of the summary address in the ABR R3 and make it higher and let’s take a look at the result in the routing table of R4.

In R3 (ABR):

!
router ospf 1
area 30 range 10.1.8.0 255.255.248.0 cost 20
!

OSPF-SUMMARY-APPS-2-16

As shown in the above output, now the route 10.1.8.0/21 is now reachable only via R2.

Finally, the desired traffic pattern was achieved and the task was completed.

Now, let’s talk about the External routes.  Why did they change when we applied the summarization?   This behavior is clearly defined in the RFC 3101, in section 2.3.   I would recommend you to read it.

Long story short:   It has to be with the forwarding address, or better said:  The way NSSA treat forward addresses when redistributing.   The selection process to choose the forwarding address is:  Choose the highest IP address of an internal address; if an internal address is not available, it will prefer the higher found OSPF stub network.

Let’s take a look to the external LSA:

OSPF-SUMMARY-APPS-2-17

In this case, the router has compared Loopback0 and Loopback1.  Because Loopback1 has the higher IP address it wins.

The Forward Address (10.1.1.1) is within the range 10.1.0.0/21 previously summarized and routed throughout R3.

It is time to close this long post. In the next one, we will start discussing OSPF filtering.

Thank you for visiting.

Traffic Engineering with OSPF Summarization (Part 1)

In today’s posts, we will start discussing the additional applications also provided by OSPF summarization. OSPF summarization can be also used for Traffic Engineering and Filtering.

Just to recap:   OSPF scalability is achieved by summarization of the topology using OSPF areas and network prefixes summarization.   Now, OSPF summarization can only be applied for inter-area and external routes.      The Inter-Area summarization is performed in ABRs, it summarizes Type-1 into Type-3 LSAs.    The external routes summarization is performed on ASBRs, it summarizes Type-5 into Summarized Type-5 LSAs and type-7 into Summarized Type-7 LSAs.

When summarization is done, the discard route (route to Null0) is automatically created.   This is a loop prevention mechanism used to discard routes if no more specific route to a network destination exists.   In OSPF, summarization must be done in a manual way.    Please take a look at the previous post for details in OSPF summarization and its configuration.

Using OSPF summarization for Traffic Engineering:

We can perform OSPF traffic engineering with summarization when we have multiple exit points out of an area or multiple exit points out of the autonomous system.    It is achieved using longer prefix match over shorter prefix match routing.     In other words, route traffic over more specific routes than summary routes.     Let’s use the following topology to illustrate how traffic engineering with summarization works:

OSPF-SUMMARY-APPS-01

Here you can download the diagram and configuration files: TE with OSPF Summarization – Part I.

Let’s take a look to the routing table in R4:

OSPF-SUMMARY-APPS-02

As can be seen in the above output, R4 (ABR for area 20) has inter-area routes (Red) coming from R5 and R7 belonging to area 20 respectively with its corresponding /21 summary discard routes pointing to Null0.

OSPF-SUMMARY-APPS-03

R4 also has external routes (Above in Blue) coming from R6 (EIGRP Domain) as shown below.

OSPF-SUMMARY-APPS-04

Now, the external routes are been load-balanced between R2 and R3 ABRs.  Let’s take a look to the LSA corresponding to the prefix 172.16.1.0.

OSPF-SUMMARY-APPS-05

The LSA corresponds to a Type-5 External LSA, the Advertising Router is R3 (RID 0.0.0.3).  This field corresponds in this case to the “Elected Translator Router”, or the router in charge to translate from Type-7 LSA into Type-5 LSA, however, the route comes from R1 (LINK ID 1.1.1.1) which is the router doing the redistribution into OSPF.    Now let’s take a look to the LSA corresponding to the link-ID 1.1.1.1:

OSPF-SUMMARY-APPS-06

As can be seen in the output, the Type-3 LSAs corresponding to the link-id 1.1.1.1 has two possible routes.   From R2 (Advertising Router: 0.0.0.2) and R3 (Advertising Router: 0.0.0.3) with identical metric.   Thus, the route is been load-balanced.

Now, with this information let’s do some traffic Engineering:

Goal:

Traffic from the networks 10.0.0.0/21 in R4 (Area 0) and the whole Area 20 must use R2 to reach the 172.16.0.0/16 networks in the EIGRP domain.

OSPF-SUMMARY-APPS-07

At first hand we know the Totally Stubby Area 20 will automatically generate a default route, it will have into its link-state database Type-1 and Type-2 LSAs containing intra-area information and a Type-3 Summary LSA with the default route pointing to R4, which is the only way out to reach other areas and external routes.    This is the case for R5 and R7 respectively as shown below:  (Only R5 information shown by brevity)

OSPF-SUMMARY-APPS-08

We also know the routes to the external EIGRP domain are being load-balanced between R2 and R3 in R4:

OSPF-SUMMARY-APPS-09

So, let’s apply the Summarization in the ASBR (R1) and examine the routing table in R4 again:

In R1 (ASBR):

!
router ospf 1
summary-address 172.16.0.0 255.255.0.0
!

OSPF-SUMMARY-APPS-10

As shown in the above output, the routing table of R4 now has a summary 172.16.0.0/16 route; the route is still load-balanced.    The requirement is to route the traffic to the external EIGRP domain via R2.   Here is where the tricky part comes.

Let’s take a look at the link-state databases in R2 and R3, in particular to the Type-5 and Type-7 LSAs.

OSPF-SUMMARY-APPS-11

OSPF-SUMMARY-APPS-12

As can be seen, the ABRs translated Type-7 into Summarized Type-7 LSAs and as expected a Type-5 summary LSA was generated by the elected Type-7 to Type-5 Translator Router.  In this case R3 (RID 0.0.0.3).   R4 will receive only the Summarized Type-5 LSA;  Type-7 LSAs are not allowed out of NSSA areas, the ABR connecting NSSA areas will generate a Type-5 LSA to advertise the external routes on behalf of the ASBR.

But, what can we do to route the traffic only from R2?    Currently, we have two identical paths with identical metric.   Let’s recap and change the approach.   For traffic engineering with OSPF summarization to work is needed a summary route in one of the ABRs and more specific routes in the other.  So, let’s undo the previous change and summarize in the one of the ABRs.

In R1 (ASBR):

!
router ospf 1
no summary-address 172.16.0.0 255.255.0.0
!

In theory, if we summarize the loopbacks of R6 (EIGRP Domain) into 172.16.0.0/16 in R3, the more specific routes in R2 will be preferred.   Let’s give it a try.

In R3 (ABR):

!
router ospf 1
summary-address 172.16.0.0 255.255.0.0
!

Now let’s take a look to the routing table in R4:

OSPF-SUMMARY-APPS-13

Wait a minute.  It didn’t work!    Let’s find out why?

Let’s take a look again to the link-state databases in the ABRs, in particular to the Type-5 and Type-7 LSAs.

OSPF-SUMMARY-APPS-14

OSPF-SUMMARY-APPS-15

As can be seen in the above output, both ABRs have Type-7 LSAs flooded in the NSSA area from the ASBR (R1).  They also have a Type-5 LSA corresponding to the summarized prefix 172.16.0.0/16, but it’s not supposed to have in R2 Type-5 LSAs with specific routes?  Something likes the following:

OSPF-SUMMARY-APPS-16

Well, let’s take a closer look to the external LSA in R2:

OSPF-SUMMARY-APPS-17

Have you noticed the problem?   The forwarding address of the Type-5 LSA is set to null (0.0.0.0).  This means that the route is reachable only via the advertising router.   You may be thinking that the advertising router is the ASBR (R1) and this is correct in part, but you have to remember when multiple ABRs are present only one is elected as the Type-7/Type-5 translator.

The ABR R3 was elected translator because it has higher Router-ID (RID) configured.  R3 has suppressed the most specific prefixes and replace them with a single Summarized Type-5 LSA and then it flooded to all routers within the area.

The way to solve this task is to apply the summarization in R2 and make it the Type-7 to Type-5 router translator.    As you may know, the election is “automatic”, this means that changing the RID in R2 to something higher it will change the role to the Type-7/Type-5 translator.   But, it is also required when changing the RID in an OSPF-enabled router clearing the process.   Clearing the OSPF process is a disruptive change, so plan accordingly if you choose this path.

Another way to do this it’s instructing the ABR R2 to become always the Type-7/Type-5 translator.  This is done in the nssa area definition, adding the keywords translate type 7 always.   This change is non-disruptive.

Let’s make the change and give it a try.

In R2 (ABR):

!
router ospf 1
area 30 nssa translate type7 always
summary-address 172.16.0.0 255.255.0.0
!

OSPF-SUMMARY-APPS-18

OSPF-SUMMARY-APPS-19

 

As seen in the above outputs, the goal was achieved.   Traffic from the loopbacks in R4 and networks in Area 20 now traverses R2 as the primary path to reach the EIGRP domain.    Also, redundancy is in place. If a failure occurs in R2, then R3 will advertise the summary route.

It is time to close this long post.  In the next one, we will discuss traffic engineering with inter-area summarization.   Thank you for visiting.

OSPF NSSA Areas

In my last post, I mentioned that the stub areas are used to provide scalability. Basically, we focus on the stub and totally stubby areas.

But, what if we need redistribute routes from an external source in these stub areas?

It is important to remember that the redistribution is not allowed in stub areas.

In order to cope with this problem, OSPF provides a type of area that performs the same functions as Stub areas while allowing redistribution:  Not-So-Stubby-Areas or NSSA.

OSPF Not-So-Stubby-Areas:

The NSSA filters Type-5 LSAs, the same way the stubby areas does, however, redistribution is allowed.   What it does is generating a Type-7 LSA which is used to advertise the external routes to the ABR.   The ABR then translate the Type-7 LSA into Type-5 before flood it to the rest of the OSPF domain.   To configure an area as NSSA, use the area {area-id} nssa OSPF process command.     Now, a difference that should be mentioned is that NSSA does not automatically create a default route unlike stub areas unless explicitly configured to do so.  To generate the default route in NSSA, simply add the keyword default-information-originate to the NSSA command definition previously described.

OSPF Totally- Not-So-Stubby-Areas:

This type of area expands the NSSA capabilities, in essence, works like totally stubby areas.  It also filters Type-3 LSAs, however, redistribution is allowed.   To configure an area as Totally NSSA, use the area {area-id} nssa no-summary OSPF process command.     Now, this type of NSSA automatically creates a default route.

Let’s use the following topology to demonstrate the NSSA capabilities:

OSPF-NSSA-01

 

The relevant initial configuration files are as follows:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 30
!
interface Ethernet0/0
ip address 192.168.30.1 255.255.255.0
ip ospf 1 area 30
!
interface Serial1/0
ip address 192.168.16.1 255.255.255.252
serial restart-delay 0
!
router eigrp Branch-B
!
address-family ipv4 unicast autonomous-system 100
!
topology base
default-metric 10000 100 255 1 1500
redistribute ospf 1
exit-af-topology
network 192.168.16.0 0.0.0.3
eigrp router-id 1.1.1.1
exit-address-family
!
router ospf 1
router-id 0.0.0.1
redistribute eigrp 100 subnets
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.30.2 255.255.255.0
ip ospf 1 area 30
!
interface Ethernet0/1
ip address 192.168.10.2 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.30.3 255.255.255.0
ip ospf 1 area 30
!
interface Ethernet0/1
ip address 192.168.10.3 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.20.4 255.255.255.0
ip ospf 1 area 20
!
interface Ethernet0/1
ip address 192.168.10.4 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/2
ip address 192.168.254.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 192.168.254.1
!
router ospf 1
router-id 0.0.0.4
area 20 stub no-summary
default-information originate
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip ospf 1 area 20
!
interface Ethernet0/0
ip address 192.168.20.5 255.255.255.0
ip ospf 1 area 20
!
router ospf 1
router-id 0.0.0.5
area 20 stub
!

R6:

!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
interface Serial1/0
ip address 192.168.16.2 255.255.255.252
serial restart-delay 0
!
router eigrp Branch-B
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
network 6.6.6.6 0.0.0.0
network 192.168.16.0 0.0.0.3
eigrp router-id 6.6.6.6
exit-address-family
!

R7:

!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
ip ospf 1 area 20
!
interface Ethernet0/0
ip address 192.168.20.7 255.255.255.0
ip ospf 1 area 20
!
interface Ethernet0/2
ip address 192.168.254.5 255.255.255.252
!
router ospf 1
router-id 0.0.0.7
area 20 stub
!

Let’s focus on Area 30. R6 connects to a remote office (Branch B), which operates with EIGRP. R1 performs mutual redistribution between OSPF and EIGRP.   Internet access is being provided to the Branch office from R4 in HQ.

Let’s take a look to the routing table in R6 and test reachability to R5 and R7.

OSPF-NSSA-02

As can be seen in the above output, the Branch office has routes to all segments; the loopbacks in R5 and R7 are reachable from R6.   Another thing to note is the presence of the default route in R6.   It was originated by OSPF in R4 with the command default-information originate and then redistributed into EIGRP from R1.

Now, let’s take a look at the Link-State Database in R1:

OSPF-NSSA-03

As seen in the above output, the default route, the loopback of R6 and the segment 192.168.16.0/30 (Link between R6 and R1) appear as type-5 LSAs.

Now, let’s change Area 30 to NSSA.

To do this, we have to define the NSSA in the border routers connecting the NSSA area (R2 and R3) and the internal routers (R1).

R1, R2, and R3:

!
router ospf 1
area 30 nssa
!

WARNING RGE

Be careful, this is a disruptive change.   Remember, the area types must match for the adjacencies to be formed.   Plan accordingly when making changes in the network.

After applying the changes, let’s take a look at the link-state database of R1 and R4:

OSPF-NSSA-03-1

OSPF-NSSA-03-2

As seen in the above outputs, the redistributed routes generate Type-7 LSAs in R1 then were translated by the ABR (R3) into Type-5 LSAs.   In this topology, R2 and R3 are ABRs for Area 30.  When multiple ABRs are present the ABR with highest Router-ID is elected as the translator for Type-7 into Type-5 LSAs.   R3 was elected translator.

Now, let’s take a look at the routing table in R6 and test reachability again.

OSPF-NSSA-04

It seems like everything is fine.  But wait a minute.  There’s no internet access in the branch office.    If you look closer, the default route has disappeared.   This is because NSSA does not automatically generate a default route.   But you may think, this was generated by R4, so why this happened?

Let’s take a look at the Link-State database in R1:

OSPF-NSSA-05

As seen in the above output, the Type-5 LSAs were replaced by Type-7 LSAs but the default route is not present.   This is because the ABR will not automatically inject the default route into an NSSA.  This has to be explicitly configured.

To solve this problem, we can add the keyword default-information-originate into the NSSA definition in both ABRs for load-balancing or we can choose one of the routers and force the internet traffic to use only one path.

Let’s try these two possibilities.

First, let’s originate the default route from R2:

R2:

!
router ospf 1
area 30 nssa default-information-originate
!

Now, let’s take a look to the routing table of R1 and see if the default route was injected:

OSPF-NSSA-06

As can be seen, the default route was injected as OSPF NSSA external Type 2 (O*N2).

Now let’s take a look to the LSA:

OSPF-NSSA-07

As shown in the output, the advertising router is R2 and was generated as Type-7.  The default route is now present (via redistribution) in the Branch (R6).

OSPF-NSSA-08

As shown above, the path to reach the internet (8.8.2.2) is via R2.   Now, let’s originate the default route in the other ABR (R3):

R3:

!
router ospf 1
area 30 nssa default-information-originate
!

Let’s take a look at the result in R1:

OSPF-NSSA-09

As can be seen, now R1 has 2 equal cost paths to reach the default route.

OSPF-NSSA-10

Another feasible solution would be turning Area 30 into a Totally-Not-So-Stubby-Area. This type of Area suppresses Type-5 and Type-3 LSAs.  It generates the default route as Type-3 LSA.

Let’s change only R2 and R3 to Totally-NSSA and check the results:

R2 and R3:

!
router ospf 1
no area 30 nssa default-information-originate
area 30 nssa no-summary
!

 

OSPF-NSSA-11

As seen in the above output, the default route appears as OSPF Inter-Area (O*IA).

OSPF-NSSA-12

The Type-3 LSAs were replaced by default-routes advertised by the ABRs.

It is time to close this long post. Thank you for visiting.

OSPF Stub Areas

In a multi-area OSPF network, stub areas are basically used to provide scalability.   OSPF scalability is achieved by reducing the flooding domain using areas and reducing the size of the routing table doing summarization.

Now, summarization and filtering are functions of the ABR.  This is due the hierarchical design of OSPF.   A way to reduce the routing information in an area is converting the area into Stub.

When configuring an area as Stub, the ABR will filter whatever LSA (Type-3, Type-4 and/or Type-5) which enter the area depending on the type of Stub Area that is configured.    The filtered LSAs in Stub areas are then replaced with a Type-3 default route (LSA Summarization).  Another consideration when configuring stub areas is that all routers within the stub area must be also configured as stub. Otherwise, they won’t form the adjacency.

OSPF Stub Area Types

There are four stub area types:

  • Stub Area – Filters Type-5 LSAs.
  • Totally Stubby Area – Filters Type-3 and Type-5 LSAs. These LSAs are summarized into a single Type-3 LSA which is the default route.
  • Not-So-Stubby Area (NSSA) – Filter Type-5 LSAs. Allows local redistribution in the area. The router doing redistribution in the NSSA area generates LSA Type-7 for the redistributed prefixes. The ABR translates the Type-7 LSA into Type-5 LSA when advertised to the backbone Area.  In NSSA, the ABR does not automatically originate a default route.
  • Totally-Not-So-Stubby-Area – Like Totally Stubby Area, filters Type-3, Type-4, and Type-5 LSAs and also allows local redistribution. It is, in essence, a combination of the Totally Stubby Area and NSSA.  It also generates Type-7 LSAs for the redistributed prefixes, the ABR translate this Type-7 into Type-5 LSAs when entering the backbone area. In Totally-Not-So-Stubby-Area, the ABR automatically originates the default route.

Today we will focus in the first two Stub Area Types.

To configure an area as Stub, use the area {area-id} stub [no-summary] OSPF process command.   The stub area must be defined in all routers participating in the stubby area.  The no-summary keyword is used to change from stub area to Totally Stubby Area.

Let’s use the following topology for the examples:

OSPF-STUB-01

As can be seen in the topology, the area 234 is defined as a stub area.  R1 and R5 are doing mutual redistribution between RIP and OSPF.

The initial configuration files are as follows:

R1:

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 192.168.15.1 255.255.255.0
!
router ospf 1
router-id 0.0.0.1
redistribute rip subnets
!
router rip
redistribute ospf 1 metric 6
network 192.168.15.0
no auto-summary
!

R2:

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.12.2 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.2
!

R3:

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 234
!
interface Ethernet0/0
ip address 192.168.34.3 255.255.255.0
ip ospf 1 area 234
!
router ospf 1
router-id 0.0.0.3
!

R4:

!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip ospf 1 area 234
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip ospf 1 area 234
!
router ospf 1
router-id 0.0.0.4
!

R5:

!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Ethernet0/1
ip address 192.168.15.5 255.255.255.0
!
router rip
network 5.0.0.0
network 192.168.15.0
no auto-summary
!

At this moment area 234 is a normal area.

Let’s take a look at the routing tables in R5 and R3 and test the reachability between them.

OSPF-STUB-02

OSPF-STUB-03

As can be seen in the above outputs, R5 is learning the redistributed OSPF routes from R1 with a metric of 6.   When doing redistribution between OSPF and RIP the seed metric is required.   RIP has a max-metric of 15.   Also, note R3 is learning redistributed routes from R5.   These routes are being advertised as “O E2” or OSPF External type 2 with a default metric of 20.

Now let’s take a look at the link-state database in R3:

OSPF-STUB-04

As can be seen in the above link-state database output, R3 has Type-1, Type-2, Type-3, Type-4 and Type-5 LSAs.   The Type-3 Summary information is coming from the ABR, detailing the summary information of the networks in Area 0. The Type-5 External LSAs details the redistributed routes, they were generated by R1, the Type-4 LSA details how to reach the ASBR (R1 – RID: 0.0.0.1) from where the Type-5 LSAs were learned.   Also, note the Type-5 External don’t have an explicit area (Area X) attached to the description in the database.   This is because the flooding scope of External Type-5 LSAs is the entire OSPF domain.

Let’s configure the area 234 as stub and let’s see what happens:

R2:

!
router ospf 1
area 234 stub
!

Let’s stop here for a moment and take a look on the adjacency between R2 and R4:

OSPF-STUB-05

As soon we changed the area 234 to stub, the adjacency with R4 went down.   What is the problem?   Let’s debug the hello packets and see what’s going on.

OSPF-STUB-06

According to the above output, R2 has received a hello packet with mismatched Stub/Transit area option bit.   When configuring stub areas, all participating routers must be configured as stub.   Thus, changing from normal to stub areas will tear down your adjacencies.

Let’s continue with the configuration.

R3:

!
router ospf 1
area 234 stub
!

R4:

!
router ospf 1
area 234 stub
!

Let’s take a look to the routing table and the link-state database on R3:

OSPF-STUB-07

OSPF-STUB-08

As can be seen in the above output, the routing table has changed.   Now the “O E2” OSPF external routes have disappeared.   Now the routing table has an Inter-Area default route (O*IA).

Also, note the “O IA” OSPF inter-area routes corresponding to the prefixes in area 0 are still present.

Now, let’s take a look at the link-state database:

OSPF-STUB-09

As can be seen in the above output, the Type-5 LSAs were filtered, thus, the Type-4 LSA was not generated by the ABR.

Totally Stubby Area

The Totally Stubby Area what it does is increase the filtering even more.  This type of areas filters inter-area (O IA) and external routes (O E1|E2).   To configure the area as totally Stub just adds the keyword no-summary at the end of the stub area configuration.  Because the Totally Stubby Area is an extension of stub areas, the no-summary keyword is only required in the ABR connecting the stub area.

Considering that the link between R2 and R4 is the only transit link between the backbone and the area 234, it would make sense to convert it into a totally stubby area.

So let’s make the change:

R2:

!
router ospf 1
area 234 stub no-summary
!

Finally, let’s take a look to the routing table and the link-state database:

OSPF-STUB-10

OSPF-STUB-11

As can be seen in the above outputs, now the inter-area (O IA) and the External (O E1|E2) routes were replaced with a single Inter-Area default route (O*IA).  The Type-3, Type-4 and Type-5 LSAs were filtered from the link-state database.   The full topology is still reachable because the inter-area and external routes fall into the default route.

OSPF-STUB-12

Despite the Stub and Totally Stub Areas seems attractive because of their low overhead, they also have important limitations of which I want to emphasize:

  1. Stub and Totally Stub areas do not support redistribution.
  2. Stub areas, in general, do not support Virtual-Links.

It is time to close this long post.

Thank you for visiting.

OSPF Areas and Area Types

OSPF provides two levels of hierarchy through the use of Areas.  An easy way to explain what an Area is would be:  An OSPF area is a logical segment or a sub-domain containing networks, routers and links sharing the same area id.

Using multiple areas in OSPF reduces the router resource utilization because the routers belonging to the same area only maintain the network topology of the area where they belong. Thus, less LSA has to be flooded and maintained.  In other words, the Routers in other areas; don’t have information about the topology outside its own area.

An area is a 32-bit number which can be represented the same way as an IP address such  “area 0.0.0.0” or as a decimal number, such as “Area 0”.

OSPF-AT-Single-Area

The Area 0 is the backbone area in an OSPF domain.   If more than one area is configured, then Area 0 is required to provide inter-area communications.   This means that in an OSPF autonomous system, all areas must be physically connected to the backbone area 0.

OSPF-AT-Multi-Area

I’ve mentioned that all areas must be connected to Area 0; But, what about areas that cannot be physically connected to the area 0?

OSPF provides a native solution for this problem, OSPF Virtual-Links.  I will dedicate an entire post for this technology later on.

OSPF-AT-Virtual-Link.PNG

The Routers contained within the same area are called Area Routers (AR), the routers with a link in Area Zero (0) and a Non-Zero area is called Area Border Routers (ABRs).  Finally, the Routers with a link in Area Zero (0) or a Non-Zero area and redistributing from another Routing Protocol are called Autonomous System Boundary Routers (ASBRs).   Summarization can be done only on ABRs and ASBRs.

OSPF-Router-Type

OSPF Area Types

The OSPF area types can be divided into the following types:

  • Normal Areas
    • Standard.
    • Transit.
  • Stub Area.
    • Totally Stubby Area.
  • Not-So-Stubby Area (NSSA).
    • Totally NSSA.

Normal Area

Normal Areas can be standard or transit (backbone) areas.

  • The Standard areas are the non-zero defined areas where LSAs Type-1, 2, 3, 4 and 5 are allowed; this means that can accept intra-area, inter-area, and external routes.
  • The backbone area is, in essence, a Standard area but is the area from which all other areas in OSPF must be connected.

I’ve mentioned that summarization is possible only on ABRs and ASBRs; But, what about the default route?    Well I think is necessary to explain about the default-route in normal areas.

It is allowed to generate the default route in Normal Areas.  The default route is injected as Type-5 LSA.

In order to generate the default route use the default-information originate process command.  If the default route is not present in the Routing Table then won’t be generated unless the [always] keyword is added at the end of the command.

OSPF-AREA-Normal

 

Stub Area

Stub areas are typically used where the access to the rest of the network through a single link.  For these type of networks is not necessary having and maintaining a full link state database.   This area type can only accept intra-area, inter-area and the default route (generated by default).

Stub areas allow only LSAs Type-1, 2 and 3.   Redistribution is not allowed in Stub Areas.

The default route in a Stub area is generated by default and is injected in the area as Type-3 LSA.

To configure a Stub Area use the Area [x] stub process command.  This command must be added to the routers belonging to the stub area and also, must be added to the ABR connecting the stub area.

OSPF-AREA-STUB

 

Totally Stubby Area

Totally Stubby areas are an extension of Stub Areas and are in fact, the most restricted type of OSPF area.

In Totally Stubby Areas, the Routers receive only a default route from the ABRs, no External or Summary routes are allowed except for the default-route.   The default route in Totally Stubby area is generated by default and is injected in the area as Type-3 LSA.

To configure a Totally Stubby Area use the Area [x] stub no-summary process command.  This command with the no-summary keyword is required only on the ABR connecting the area.

The router connecting to the ABR does not require the no-summary keyword but requires to be defined as a stub.

OSPF-AREA-T-STUB

Not-So-Stubby Areas (NSSA)

Not-So-Stubby areas are also an extension of the stub areas.  This type of area adds the flexibility of redistribution of external routes into the area while retaining its stub characteristic.   This area type can only accept intra-area, inter-area, external and the default route (which is not generated by default).   Not-So-Stubby areas allow only LSAs Type-1, 2, 3 and 7.

When the default route in an NSSA is generated, it is injected in the area as Type-7 LSA.

To configure an NSSA use the Area [x] nssa [default-information-originate] process command.  This command must be added to the routers belonging to the NSSA area and must be also added to the ABR connecting the NSSA.  The default-information-originate keyword generates the default-route in NSSA.

OSPF-AREA-NSSA

 

Totally Stubby NSSA

Totally Stubby NSSA is an extension to the NSSA.  As a matter of fact, this is the most recommended form of NSSA area type.  This type of area adds the flexibility of redistribution of external routes into the area while retaining it’s totally stubbed characteristic.   This area type can only accept intra-area, external and the default route (which is generated by default).   Totally Stubby NSSA areas allow only LSAs Type-1, 2, [3] and 7.      The default route in a Stub area is generated by default and is injected in the area as Type-3 LSA.

To configure a Totally Stubby NSSA use the Area [x] nssa no-summary process command.  This command with the no-summary keyword is required only on the ABR connecting the area.

The router connecting to the ABR does not require the no-summary keyword but requires to be defined as NSSA.

OSPF-AREA-T-NSSA

It is time to close this post. Thank you for visiting.