Anyone that ever studied OSPF was probably confused about all the different link-state advertisement types (LSA 1,2,3,4,5,7 etc) at some point in time. Equally confusing are all the possible area types. OSPF allows for 5 different area types, which provides flexibility in deployments but also introduces quite a bit of complexity.
In this blog post we will discuss the different area types, their general use and especially focus on the configuration intricacies of the "stubbie" area types.
RFC2328 defines area as: "OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area". Now isn't this crystal clear :-)
Lets say you have a network with 100 routers in it. You now have to make a design choice how to organize this network. The basic options when using OSPF are:
- Single area: all 100 routers share the same information
- Multiple area's: split the 100 routers into multiple area's, for example 4 area's with each 25 nodes.
The reason for using multiple area's normally given is enhanced scalability. By splitting the network into area's, the database in each area can be become smaller and seemingly more stable. To really get these benefits summarization between area's is required. By using summary prefixes, instead of the individual prefixes, most instability (flapping) is no longer shared between area's. See my earlier post about OSPF summarization options for details on ways to summarize in an OSPF network.
By default, when you use a multiple area design, your created area's will be considered "normal" area's. This just means that these area's support the flooding of all standard LSA types (1,2,3,4,5).
The backbone area 0.0.0.0 is always a normal area even though it is special in its own right. All other area's should connect to area 0 either physically or through some logical connection (virtual-link / tunnel). The configuration for normal area is very straight forward, just assign interface to an area number.
The main problem with "normal" area's could be that they must carry all redistributed routes, including the redistributed routes instability. If the router has limited memory or CPU capabilities this would impact performance. So to limit the amount of routing information into area's, besides summarization, different "stubbie" area types are available.
The goal of these "stubbie" area types is to block specific route types from entering the area. External (LSA 4 and 5) routes are the main target but additionally inter-area (LSA 3) routes can be blocked. To retain connectivity the blocked prefixes need to be replaced by a default route.
Table 1 shows the relationship between the area type and the allowed LSA types.
All these "stubbie" area types have a couple of drawbacks that you need to be aware of:
- Virtual links can NOT transit these area types, as virtual links require the transport of all LSA types
- Possible suboptimal routing as a result of default route use.
Base Topology
We will look at each area type in more detail below, including configuration and database analysis.
The diagram below shows the base topology used to illustrate the different configurations and behavior of the stubbie area types. We will look at the following 3 routers:
- R1: This router is the ABR into area 10. Some of the stubbie area types configuration is ABR specific.
- R2: This router is an internal router in the normal area 1.
- R10: This router will change over time to be an internal router in a stub, totally stub, NSSA, and totally NSSA area.
To start of both area 1 and area 10 are configured as "Normal" area's. This will give us a baseline for the configuration and database output.
The configuration of R1:
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.10 interface ge-0/0/0.0
set protocols ospf area 0.0.0.1 interface ge-0/0/1.0
The configuration of R2 including the export policy and static routes:
set protocols ospf export REDIST_STATIC
set protocols ospf area 0.0.0.1 interface ge-0/0/0.0
set protocols ospf area 0.0.0.1 interface lo0.2
set R2 policy-options policy-statement REDIST_STATIC term 1 from protocol static
set R2 policy-options policy-statement REDIST_STATIC term 1 then accept
set R2 routing-options static route 172.16.1.0/26 reject
set R2 routing-options static route 172.16.1.64/26 reject
set R2 routing-options static route 172.16.1.128/26 reject
set R2 routing-options static route 172.16.1.192/26 reject
The configuration of R10 including the export policy and static routes:
set protocols ospf export REDIST_STATIC
set protocols ospf area 0.0.0.10 interface ge-0/0/0.0
set protocols ospf area 0.0.0.10 interface lo0.0
set policy-options policy-statement REDIST_STATIC term 1 from protocol static
set policy-options policy-statement REDIST_STATIC term 1 then accept
set R10 routing-options static route 172.16.10.0/26 reject
set R10 routing-options static route 172.16.10.64/26 reject
set R10 routing-options static route 172.16.10.128/26 reject
set R10 routing-options static route 172.16.10.192/26 reject
Lets start with the database output of area 10 on R10 in the normal area type scenario. From table 1 above it should be clear that we expect all LSA types 1-5 to be present in the database on R10 (assuming LAN type interfaces). The show ospf databse of R10 is shown below.
As expected we can see Router (type 1) and Network (type 2) LSA's from area 10 itself. From area 0 and 1 we can see the Summary (type 3) LSA's. As router R2 is redistributing routes there is also an ASBRSum (type 4) LSA, as R2 is NOT in area 10. Both the external routes from R2 and R10 are also shown. R2 is injecting all the 172.16.1.x/26 routes and R10 is injecting the 172.16.10.x/26 routes.
1. Stub area's
A stub area is the most basic form of the "stubbie" area types. It prevents any external route from entering into the area's database. Not only does it block external routes originating in other area's but also prevents any local redistribution.
Lets have a look at the configuration for a Stub area. All routers in the stub area must have the stub flag configured.
The added configuration for R10 (internal router):
set protocols ospf area 0.0.0.10 stub --> turns area 10 into a stub area
Only the ABR's also need to be configured for a default route injection.
The added configuration for R1 (ABR):
set protocols ospf area 0.0.0.10 stub
set protocols ospf area 0.0.0.10 stub default-metric 10 --> inject 0/0 route into area
Which metric you choose is only important when multiple ABR's exist and you want to influence outbound traffic through the default route.
- load-sharing: use same metric on all ABR's
- primary/backup: use lowest metric on primary ABR
The effect of the stub area configuration is clear from the show ospf database output as the external route related LSA's (LSA 4 and 5) have disappeared from the area 10 database. The default route injection is also easy to spot as there is a Summary LSA with id 0.0.0.0.
2. Totally Stub area's
Totally stub area's not only block any external route (LSA 4 and 5) from entering into the database but they also block any inter-area (LSA 3) routes from entering the area. This reduces the size of the database even further. Note that local redistribution is still not supported.
Below is the additional configuration for a totally stub area. The only difference is the no-summaries command on the ABR router R1: set protocols ospf area 10 stub no-summaries
Notice that the inter-area (LSA 3) entries are now also removed. The show ospf database output below only shows intra-area (LSA 1 and 2) and a 0.0.0.0 (LSA 3) entries. The default route is now used to reach any inter-area or external route destinations.
As mentioned before one of the disadvantages of stub and totally stub area's is the fact that local redistribution is not allowed. This issue can be fixed by using the relatively newer NSSA or Totally NSSA area types.
3. NSSA area's
Not so stubby area's (NSSA) are very similar to stub area's with 1 major addition. NSSA area's only block external routes from other area's from entering into the database (LSA 5). The NSSA area's however do allow for local redistribution using the special NSSA external route type (LSA 7).
Lets have a look at the configuration for a NSSA area. All routers in the NSSA area must have the NSSA flag configured.
The added configuration for R10 (internal router):
set protocols ospf area 0.0.0.10 nssa --> turns area 10 into a nssa area
Only the ABR's also need to be configured for a default route injection.
The added configuration for R1 (ABR):
set protocols ospf area 0.0.0.10 nssa
set protocols ospf area 0.0.0.10 nssa default-lsa default-metric 10 --> inject 0/0 route into area
The command to inject a default route into the area is slightly different as it also requires the default-lsa keyword.
The effect of the NSSA area configuration is clear from the show ospf database output. The external routes from other area's have been filtered out (LSA 4 and 5). However the local redistribution is still working as seen by the NSSA (LSA 7) entries.
The default route is now injected as type NSSA (LSA 7). Remember this 0/0 route is needed to reach the blocked external destinations. By using type NSSA (LSA 7) it means that the 0/0 injected by the ABR can now be compared to any redistributed 0/0 route from any ASBR in the area. So depending on the metric the "best" exit can now either be the ABR or an ASBR. As they both use the same type to inject the 0/0 route they can be compared during the SPF calculation and the lowest metric will be the winner. Alternatively if the metric is the same even load sharing can be accomplished.
4 Totally NSSA
Totally NSSA area's not only block external routes (LSA 4 and 5) from other area's but also inter-area routes (LSA 3) from other area's. So it will reduce the size of the database again while still allowing local redistribution using NSSA (LSA 7).
The configuration for totally NSSA area's is very similar as only the no-summaries stated needs to be added to the ABR R1: set protocols ospf area 10 nssa no-summaries.
The output of the show ospf database command shows that inter-area routes (LSA 3) also have been blocked and that local redistribution is still possible via type 7 LSAs.
The default route injection is now again done as a Summary (LSA 3). The reason for this is that the 0/0 in an Totally NSSA area is needed to reach both inter-area routes as well as external routes. Therefore it should point towards an ABR as otherwise the inter-area routes might become unreachable.
Note:
For backward compatibility the option exists to change the default LSA type that is used for injecting the default route in totally NSSA area's. This should never be needed anymore as it was needed for interoperability with Junos versions 5 or earlier. So the command set protocols ospf area 10 nssa default-lsa type 7 is obsolete in modern Junos networks.
NSSA Externals (LSA 7)
For completeness lets also have a look what happens to the local redistributed routes from any NSSA / totally NSSA area. The ABR will convert these type 7 external routes into type 5 external routes. During this conversion you can choose to summarize or filter these prefixes into the non-NSSA areas as discussed in an earlier post.
The output of show ospf database on R2 (normal area) shows the 172.16.10.x/26 prefixes as type External (LSA 5) in the database.
Redistribution on NSSA ABR
There is another item that we need to discuss related to redistribution and NSSA area types. What if we enable redistribution on the ABR itself. The default behavior is to redistribute the routes both as type 5 for normal area's and as type 7 for the NSSA area's attached to the ABR. This behavior can be modified so that the redistribution on the ABR will not inject external routes into the NSSA area's.
Lets add the following configuration on R1 (ABR with normal area 1, and NSSA area 10):
set protocols ospf export REDIST_STATIC
set policy-options policy-statement REDIST_STATIC term 1 from protocol static
set policy-options policy-statement REDIST_STATIC term 1 then accept
set routing-options static route 192.168.1.0/26 reject
set routing-options static route 192.168.1.64/26 reject
set routing-options static route 192.168.1.128/26 reject
set routing-options static route 192.168.1.192/26 reject
The configuration will turn R1 into a ASBR and 4 routes are injected in area 1 as Extern (LSA 5) and in area 10 as NSSA (LSA 7).
R2's show ospf database output is shown below. Notice the 192.168.1.X/26 prefixes as Extern.
On R10 the 192.168.1.X/26 prefixes show up as NSSA entries in the show ospf database output.
It is possible to change this default behavior on the ABR (R1) by using the set protocols ospf no-nssa-abr command. This prevents the routes redistributed on the ABR being injected into the NSSA area's connected to that ABR.
Summary
This blog post covered the OSPF stubbie area types. Both configuration options and database analysis have been discussed for each of the 4 different area types. For JNCIE candidates it is important to understand all these area types as they are fair game on any written or lab exam. For production network use I would strongly advise not to use the stub or totally stub variants. The NSSA or totally NSSA variants have the same benefits (smaller database / increased stability) but with the additional option to allow local redistribution if needed.
More information about OSPF area types and challenging OSPF scenarios can be found in the iNET ZERO’s JNCIE workbooks.
Let us know what other topics you would like to have covered in a blog post.
