OSPF Areas, Part 4, the Not-So-Stubby Area

Now it is time for us to examine yet another OSPF special area type – the Not-So-Stubby Area. I am sure you recall out topology from the previous parts, but here it is again:

When we left Area 11 in the last post, it was a Totally Stubby Area. This prevented LSA Types 3, 4, and 5 from entering the area, with the exception of the special default route (Type 3) generated by the Area Border Router.
The Not-So-Stubby Area (NSSA) allows us to bring in some redistributed routes into the stub area! Wow. I guess the area really isn’t that stubby at all. These redistributed routes propagate through the NSSA as Type 7, and are then converted on the ABR to Type 5. At least that is what we read in the RFCs. Let us see it in action at the command line!
I have removed the previous Totally Stubby configuration and I have placed the following command on all routers in Area 11 – area 11 nssa. After doing this, let us take a look at the OSPF database and routing table on R3:

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         29          0x80000005 0x00A78B 1
3.3.3.3         3.3.3.3         28          0x80000004 0x0062CB 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         28          0x80000001 0x00DACB

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         58          0x80000003 0x00E91B
172.16.10.0     2.2.2.2         58          0x80000003 0x0069F1

R3#show ip route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:00:33, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:00:33, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
R3#

Notice how at this point,it looks just like a stub area. Type 4 and 5 LSAs have been filtered. Now, I will configure some loopbacks on R3, run RIP on them, and redistribute them into OSPF. Let us examine the OSPF database on R3 now:

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         765         0x80000005 0x00A78B 1
3.3.3.3         3.3.3.3         10          0x80000005 0x0066C4 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         764         0x80000001 0x00DACB

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         794         0x80000003 0x00E91B
172.16.10.0     2.2.2.2         794         0x80000003 0x0069F1

  Type-7 AS External Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Tag
33.33.33.0      3.3.3.3         9           0x80000001 0x00F06E 0
44.44.44.0      3.3.3.3         11          0x80000001 0x0063DA 0
R3#

I guess the RFC did not lie to us! There they are – the Type 7 LSAs! Let us examine the OSPF database and IP routing table on R2 (the ABR):

R2#show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1120        0x80000002 0x0025E3 2
2.2.2.2         2.2.2.2         1023        0x80000003 0x007B5A 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         1120        0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         1119        0x80000001 0x00F4CB

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         994         0x80000005 0x00A78B 1
3.3.3.3         3.3.3.3         241         0x80000005 0x0066C4 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         996         0x80000001 0x00DACB

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         1025        0x80000003 0x00E91B
172.16.10.0     2.2.2.2         1025        0x80000003 0x0069F1

  Type-7 AS External Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Tag
33.33.33.0      3.3.3.3         242         0x80000001 0x00F06E 0
44.44.44.0      3.3.3.3         242         0x80000001 0x0063DA 0

  Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
11.11.11.0      1.1.1.1         1171        0x80000001 0x0075AB 0
33.33.33.0      2.2.2.2         235         0x80000001 0x00A3C9 0
44.44.44.0      2.2.2.2         239         0x80000001 0x001636 0

R2#show ip route

Gateway of last resort is not set

     33.0.0.0/24 is subnetted, 1 subnets
O N2    33.33.33.0 [110/20000] via 192.168.1.3, 00:04:12, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.10.0 [110/11] via 10.10.10.1, 00:17:16, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E2    11.11.11.0 [110/20000] via 10.10.10.1, 00:04:12, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
     44.0.0.0/24 is subnetted, 1 subnets
O N2    44.44.44.0 [110/20000] via 192.168.1.3, 00:04:12, FastEthernet0/1
R2#

Holy LSAs Batman! This router has indeed converted the Type 7s to Type 5s and installed them in the routing table. Notice the N2 designations for NSSA area prefixes. Now let us examine R1 – an internal backbone router:

R1#show ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 1)

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1704        0x80000002 0x0025E3 2
2.2.2.2         2.2.2.2         1609        0x80000003 0x007B5A 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         1704        0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         1705        0x80000001 0x00F4CB

  Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
11.11.11.0      1.1.1.1         1755        0x80000001 0x0075AB 0
33.33.33.0      2.2.2.2         819         0x80000001 0x00A3C9 0
44.44.44.0      2.2.2.2         820         0x80000001 0x001636 0

R1#show ip route

Gateway of last resort is not set

     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/20000] via 10.10.10.2, 00:13:45, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.10.0 is directly connected, Loopback1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, Loopback11
O IA 192.168.1.0/24 [110/20] via 10.10.10.2, 00:26:50, FastEthernet0/0
     44.0.0.0/24 is subnetted, 1 subnets
O E2    44.44.44.0 [110/20000] via 10.10.10.2, 00:13:45, FastEthernet0/0
R1#

This is what we would expect as well! This device just sees these prefixes as good, old-fashioned, Type 5 LSAs.
But wait, I think we have an issue now in this OSPF domain. Let us examine the routing table on R3:

R3#show ip route

Gateway of last resort is not set

     33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:18:43, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:18:43, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
     44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
R3#

We are not getting the Type 5 being generated on R1 as expected. But we are also not getting a default route from the ABR anymore. The default route is not automatic with the NSSA. All we need to do is modify the area 11 nssa command on R2 to area 11 nssa default-information-originate. Now everyone is happy, happy. Check out the routing table now on R3:

R3#show ip route
Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:21:51, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:21:51, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
     44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
O*N2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:12, FastEthernet0/0
R3#

I hope you will join me for the next part of this blog series where we examine the Jumbo Shrimp of OSPF areas, the Totally Not-So-Stubby area!

OSPF Areas, Part 3, the Totally Stubby Area

In this part of our blog series on OSPF area types, our Area 11 is going to undergo a major flashback! The area is going to be reintroduced to an early 1980′s American stereotype called Valley Girls and their Valspeak. The area is no longer going to be Stubby, but it is going to be like. . .like Totally Stubby! Lets review how we left Area 11 and how things looked when it was just a Stub area:

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         7           0x80000005 0x001A23 1
3.3.3.3         3.3.3.3         6           0x80000005 0x00D85C 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         6           0x80000004 0x004D5E

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         33          0x80000001 0x0075C0
10.10.10.0      2.2.2.2         33          0x80000003 0x0062AA
172.16.10.0     2.2.2.2         33          0x80000003 0x00E181
R3#

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:01:23, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:01:23, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:01:23, FastEthernet0/0
R3#

The Stub area configuration wiped out any Type 4 and Type 5 LSAs in Area 11 and gave us the default route to the Area Border Router (ABR) in order to reach those prefixes. Like way cool, man! OK, now I sound like Scott Morris.
Now lets make that Area 11 Totally Stubby and see what happens. All we need to do is go to the Area Border Router (ABR; R2), and add the no-summary keyword to the previous area 11 stub command. Notice this keyword only needs to be on the ABR. While you could add it to each and every area stub command in Area 11, it would have no effect and the proctor would question your abilities.
OK. Now that we have made the Totally Stubby configuration, lets examine the OSPF Database and IP Routing table on R3:

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

        Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         216         0x80000002 0x002020 1
3.3.3.3         3.3.3.3         215         0x80000002 0x00DE59 1

        Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         215         0x80000001 0x00535B

        Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         24          0x80000002 0x0073C1

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

C    192.168.1.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:11:07, FastEthernet0/0
R3#

Now I am reminded of a famous episode of the American television hit, Seinfeld. We have major shrinkage! Notice the Totally Stubby configuration has gone a step further than the Stub Area config. It not only wiped out the LSA Type 4s and 5s, but it also removed the LSA Type 3s. Those were the Summary LSAs about prefixes within our OSPF domain, but in other areas. In fact, the only LSA Type 3 we have left is the special, default route generated by the ABR. Boy is that route important now. It is the only hope of this router reaching any prefixes outside of the area.
Please join us in the next part of this series where we examine the equally, cleverly-named, Not-So-Stubby Area.

OSPF Areas, Part 2, Normal and Stub Areas

Welcome back to our series on OSPF areas. Click here for Part 1 of the series. It is time to focus on normal areas and stub areas in this post. Recall our topology:


We have gone to R1 and created a prefix (11.11.11.0/24) using a loopback interface. We run RIP version 2 on this interface and redistribute this into OSPF Area 0. What should this create on R3 in Area 11 (a normal OSPF area)? That’s right  – a Type 5 LSA for an External prefix. Let us examine the OSPF database on R3 now and the accompanying IP routing table:

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1216        0x80000002 0x00023C 1
3.3.3.3         3.3.3.3         1215        0x80000002 0x00C075 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         1215        0x80000001 0x003577

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         1281        0x80000001 0x0048C4
172.16.10.0     2.2.2.2         1241        0x80000001 0x00C79B

  Summary ASB Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         2.2.2.2         449         0x80000001 0x0075B0

  Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
11.11.11.0      1.1.1.1         456         0x80000001 0x0075AB 0
R3#

R3#show ip route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:24:41, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:24:41, FastEthernet0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E2    11.11.11.0 [110/20000] via 192.168.1.2, 00:11:53, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
R3#

Sure enough, there is the Type 5 prefix in the normal area. And we cannot forget about the LSA Type 4 (Summary ASB Link State). This informs the OSPF domain of the location of the Autonomous System Boundary Router (ASBR). I am sure you have been noticing how some of the LSAs in the database do not translate directly into routing table entries. For example, the LSA Type 4. This is reminiscent of the EIGRP topology table. That protocol sure tries to act link state as well!
OK, well let us see what happens when we convert Area 11 into a STUB AREA. Remember, this is a simple configuration. All we need to do is go to ALL of the routers in the stub area (there can be many), and issue the router configuration command area 11 stub. Now that we have done that, let us examine the databases on R3.

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         7           0x80000005 0x001A23 1
3.3.3.3         3.3.3.3         6           0x80000005 0x00D85C 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     3.3.3.3         6           0x80000004 0x004D5E

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         33          0x80000001 0x0075C0
10.10.10.0      2.2.2.2         33          0x80000003 0x0062AA
172.16.10.0     2.2.2.2         33          0x80000003 0x00E181
R3#

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:01:23, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:01:23, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:01:23, FastEthernet0/0
R3#

Wow, things really changed here. Notice the Stub Area effect worked just as advertised in our Core Knowledge studies. The Type 4 and 5 LSAs were removed from the OSPF database! They were replaced with a “special” LSA Type 3. It is special because it is an automatically generated default route by the Area Border Router (ABR).
Join us in the next part of this blog series where we examine the next OSPF area type, the Totally Stubby Area.

OSPF Areas, Part 1, The Backbone Area

Here is the network we will use in this first post. Notice this simple network can be constructed easily in Dynamips, or with three pretty basic Cisco routers capable of OSPF version 2.


To prepare for this blog post, we have configured all of the underlying layer 2 and 3 connectivity. We have also configured  OSPF per the diagram. Note the OSPF router IDs were set using the OSPF router-mode router-id command. These addresses do not exist on the devices,  and therefore they are not advertised in the protocol, and obviously, they are not reachable.
So let us examine the first device, R1. This is an internal, backbone router. What do we expect to see in the OSPF database? Well, since there is  broadcast media at work in that area, I expect to see an LSA Type 2, and we have another area, Area 11, so we should also see an LSA Type 3. Here is the actual OSPF database on the device:

R1#show ip ospf database

            OSPF Router with ID (1.1.1.1) (Process ID 1)

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         99          0x80000002 0x001FEB 2
2.2.2.2         2.2.2.2         95          0x80000002 0x007761 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         99          0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         98          0x80000001 0x00F4CB
R1#

Interesting, OK, as an internal, backbone router, the first thing I notice is the fact that we only have one link state database here – it is for Area 0 of course. OK, very interesting, we have LSA 1 types (Router Link States) for the Router IDs of R1 and R2 in that area. Wow, these are not even valid (reachable) IP addresses in the scenario. I guess this is how we can use these Router IDs when we create a virtual link. These Router IDs are tracked and shared by the OSPF speakers.
The next entry is the LSA Type 2 (Net Link State) we expected. The advertising router is the local router (R1, RID: 1.1.1.1). We must be the Designated Router (DR), and that is indeed true. Finally, we have our LSA Type 3 (Summary Net Link State) that we expected from Area 11. Awesome. This is a fun and rewarding exercise. Predicting show command output based on our Core Knowledge (Level 1).
Now, close your eyes and think about the show command output for the OSPF database we will see in R2. This is an Area Border Router (ABR), and also a backbone router. We immediately realize we should see LSA entries for Area 0 and Area 11. This poor router has to maintain two databases:

R2#show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

  Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         905         0x80000002 0x001FEB 2
2.2.2.2         2.2.2.2         899         0x80000002 0x007761 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         905         0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         902         0x80000001 0x00F4CB

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         856         0x80000002 0x00F747 1
3.3.3.3         3.3.3.3         858         0x80000002 0x00B680 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.2     2.2.2.2         859         0x80000001 0x006D44

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         904         0x80000001 0x0048C4
172.16.10.0     2.2.2.2         894         0x80000001 0x00C79B
R2#

Examine the above output line for line. There should be no surprises, and it should all fall right into place from your Core Knowledge about OSPF LSA Types now. Here is a look at the IP Routing table on this device, R2. Correlate the entries to those you see in the OSPF Database:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.10.0 [110/11] via 10.10.10.1, 00:17:59, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
R2#

OSPF Areas, Part 5, the Totally Not-So-Stubby Area

As a former English Major at the University of Massachusetts, Amherst, I really loved the oxymoron. You remember those…”sharply dull” or “cruel kindness”. Well, the OSPF protocol has one whopper of an oxymoron in its special areas – The Totally, Not-So-Stubby area!
When we last left our Area 11 in Part 4 of this blog series, it was a Not-So-Stubby Area, with the default-information-originate command used on the Area Border Router (ABR) in order to ensure a default route existed in the area. Here is the topology, and a look at the existing routing table on R3:

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

 33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
 172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.10.0 [110/21] via 192.168.1.2, 00:00:14, FastEthernet0/0
 10.0.0.0/24 is subnetted, 1 subnets
O IA    10.10.10.0 [110/20] via 192.168.1.2, 00:00:14, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
 44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
O*N2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:09, FastEthernet0/0
R3#

Notice I have highlighted some Type 3 LSAs that exist on this router. These, of course, are Inter-Area routes that are permitted into the Not-So-Stubby area. If we want to eliminate them, we need to make the area Totally Not-So-Stubby.
Let me go to the Area Border Router (R2) and remove the command area 11 nssa default-information-originate and replace it with the command area 11 nssa no-summary. Now, with that accomplished, let us examine the OSPF database and the routing table on R3:

R3#show ip ospf database

 OSPF Router with ID (3.3.3.3) (Process ID 1)

 Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         6           0x80000003 0x00A194 1
3.3.3.3         3.3.3.3         181         0x80000003 0x0060CD 1

 Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.2     2.2.2.2         6           0x80000002 0x001199

 Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         2.2.2.2         12          0x80000001 0x00FC31

 Type-7 AS External Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Tag
33.33.33.0      3.3.3.3         180         0x80000001 0x00F06E 0
44.44.44.0      3.3.3.3         180         0x80000001 0x0063DA 0

R3#show ip route

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

 33.0.0.0/24 is subnetted, 1 subnets
C       33.33.33.0 is directly connected, Loopback33
C    192.168.1.0/24 is directly connected, FastEthernet0/0
 44.0.0.0/24 is subnetted, 1 subnets
C       44.44.44.0 is directly connected, Loopback44
O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:00:17, FastEthernet0/0
R3#

Notice that the Type 3 LSAs do indeed disappear from the area. Also, notice that we do not need to instruct the Area Border Router to send the default route any more. It happens “automagically” once again like in a Totally Stubby area. Of course the Type 7 LSAs still exist in the area as a method to transport the redistributed routes in to the Area Border Router for the Type 5 LSA conversion process.
I sincerely hope you enjoyed this blog series on OSPF areas. As always, thanks for choosing INE to assist you in your Cisco certification needs.
Keep following the blog of course…I want to do a post soon for one of our awesome CCIE 2.0 customers, Terry Vinson. Terry wants me to take on the powerful VLAN Access Control Lists (VACLs) feature of Catalayst switches.