This series of two articles will discuss OSPF areas. The first part of the article will focus on theoretical knowledge, while the second one will focus on a hands-on case study.

This article assumes that you already have a basic understanding of OSPF protocol. If not, before starting to read about OSPF areas, the reader is advised to go over the introductory OSPF articles: CCNA Prep: Complete Guide to OSPF (Part 1)and CCNA Prep: Complete Guide to OSPF (Part 2).

The first part of the series will discuss the following:

  1. LSA types—You will be presented with LSA types used by OSPF and a description of what they do and where they are used.
  2. Area types—A description of the area types will be given along with the interaction between an area type and the LSA types found in each area type.

Why would someone use areas? Areas are used to control the size of link state database and to overcome the impact of flooding and the burn put on router resources, memory, and CPU that are needed to run the SPF calculations.

If areas are used, the routing domain is split into smaller routing domains. The link state database has to be identical only in these smaller domains.

For communication to happen between two areas, an ABR (area border router) is needed. The ABR sits between the two areas and runs SPF for both of them. The routing information is passed between the two areas through the ABR.

One interesting thing results from this behavior. The OSPF protocol is link state only inside an area. The SPF calculation is done only within on area. When the ABR sends the routing information to area B regarding area A, the routers from area B just take the information as it is presented by the ABR. This is more a distance vector behavior.

One question pops up very often: How many routers you should put in one area? There is no correct answer. This depends very much on the size of the link-state database, the number of prefixes, and the characteristics of the routers: memory and CPU.

When an IGP has to be deployed, the options are either OSPF or ISIS. OSPF is the preferred one in almost all cases. This is because multi-area OSPF is easier to deploy and administer than ISIS.

Each OSPF area is identified by a 32-bit Area ID.

Let’s have a quick recap of traffic and router types:

  • * Intra-area traffic—Traffic between routers in the same area.
  • * Inter-area traffic—Traffic between routers in different areas.
  • * External—Traffic between OSPF routers and routers from external routing domain.
  • * Internal router—A router that has all interfaces in a single area.
  • * Area border router (ABR)—A router that has interfaces in at least one interface in area 0 and act as gateway for inter-area traffic.
  • * Backbone router—A router that has at least one interface in area 0.
  • * Autonomous system boundary router (ASBR)—A router that is a gateway for external destinations.

LSA types

Type Code Description
1 Router LSA
2 Network LSA
3 Network Summary LSA
4 ASBR Summary LSA
5 AS External LSA
6 Group Membership LSA
7 NSSA External LSA
8 External Attributes LSA
9 Opaque LSA(link-local LSA)
10 Opaque LSA(area-local LSA)
11 Opaque LSA(AS LSA)

LSA type 6, used as an improvement for OSPF, is also known as multicast OSPF. This is not supported in IOS.

LSA type 8 was supposed to be an alternative to Internal BGP to carry BGP information over an OSPF domain. This is not supported in IOS.

LSA 9, 10, and 11 (opaque) are extensions of OSPF and they are used for specific-application purposes. This is out of the scope of this article.

Let’s discuss the other LSA types in more detail:

  • * Router LSA is created by any router. Any router would have at least Router LSA. Inside this LSA there are all routers’ interfaces, the outgoing cost of each link and any known neighbors on the link. This LSA is flooded only inside the area where it was originated.
  • * The command “show ip ospf database router” displays the router LSAs from the OSPF link-state database
  • * Network LSA is produced by the DR of the multi-access segment. The network LSA include all router attached to the segment, including the DR. This LSA is flooded only within the area where it was originated. The command “show ip ospf database network” can be used to see all the network LSAs.
  • * Network summary LSA is originated by the ABR. This LSA is sent to an area to advertise the destinations outside of the area. It’s a way to tell the internal routers of the area what destinations the ABR can reach. Also, the destinations from the attached areas to the ABR are advertised inside the backbone area using the same LSA. Default routes, external to the area but internal to the OSPF domain, are also advertised using this LSA. The command “show ip ospf database summary” displays the network summary LSAs.
  • * ASBR summary LSA is originated by the ABR and it advertises an ASBR. The destination address within the LSA is a host address with mask being zero. The command “show ip ospf database asbr-summary” can be used to display the ASBR summary LSAs.
  • * External LSA is originated by the ASBR. This LSA advertises a destination that is external to the OSPF domain. Also, a default route that is external to OSPF domain can be advertised using this LSA. This LSA is advertised throughout the whole OSPF domain. There are few exceptions based on the area type that we will discuss later. The command “show ip ospf database external” displays the external LSAs. One thing has to be mentioned here: The external LSAs don’t belong to any area.
  • * NSSA external LSAs are originated by the ASBR within the NSSA (not-so-stubby area) areas. A NSSA external LSA advertises an external destination to the OSPF domain. The difference between NSSA external LSA and an external LSA is that the former one is not advertised throughout the OSPF domain, but only in the not-so-stubby area where it was originated. The command “show ip ospf database nssa-external” displays the NSSA external LSAs.

We will check later what the OSPF database looks like.

You might wonder what the purpose was of presenting the LSA types when we are discussing areas.

Basically, based on the types of LSAs present in an area, you can figure out what kind of area type is that. And you should be familiar with the inverse process. Based on the area type, you should know what kind of LSA you will find there.

Most likely, in your life as a network engineer you will be asked what LSA types do you have in a particular area type, so it’s better to have this well understood.

Area Types

  • * Backbone area is the area where all inter-area traffic originates in, terminates in or passes through.
  • * Non-backbone area is the area where all the destinations within the OSPF domain are known.
  • * Stub area is an area where the external LSAs are not flooded. Because the external LSAs are not present, then ASBR summary LSAs are not needed as well. Along with network summary LSAs matching the inter-area destinations, there will be a default route advertised by the ABR as network summary LSAs. In case the internal routers of the stub area cannot match a destination on intra-area and inter-area routes, then the default route will be used.
  • * Totally stubby area is the area where Type 4 and Type 5 LSAs are blocked just as in stub areas. Additionally, all the Type 3 LSAs are blocked as well, except the default route.
  • * NSSA (not-so-stubby area) is an area that allows external routes to be advertised in the OSPF domain while the characteristics of a stub area are kept. The router advertising the external routes, the ASBR, will generate LSA Type 7. These LSAs Type 7 are flooded only inside the NSSA and they are blocked by the ABR. To propagate the external destinations throughout the whole OSPF domain, the ABR translates the LSA Type 7 to LSA Type 5.
  • * Totally not-so-stubby area is a similar area to NSSA with the difference that no network summary LSAs are advertised, except the one needed for default route.

The following table sums up the LSA types that can be found in each area type:

Area type Type 1 Type 2 Type 3 Type 4 Type 5 Type 7
Backbone Yes Yes Yes Yes Yes No
Non-backbone Yes Yes Yes Yes Yes No
Stub Yes Yes Yes No No No
Totally Stubby Yes Yes No (only default route) No No No
NSSA Yes Yes Yes Yes No Yes
Totally NSSA Yes Yes No (only default route Yes No Yes

Let’s talk a little bit about the options field from the OSPF hello packet. The field is 8 bit long and only 7 bits are used. This is what the field looks like:

+————————————+

| * | O | DC | EA | N/P | MC | E | * |

+————————————+

Actually, the options field can be found in:

  • * Hello packets
  • * DD (database description) packets
  • * LSA

Bit “E” indicates that the router is supporting external routing. If the bit is set to zero, then the originating router doesn’t support Type-5 LSA. It’s obvious that this bit is zero in case of stub and totally stubby areas, as they don’t support external routing. In the case that there is a mismatch between the values of this bit in the hellos of two routers in the same area, then the OSPF adjacency is not established. That’s why all routers’ interfaces in a stub/totally stubby area have to be configured as stubs.

“N/P” bit is used to support NSSA areas. If the bit “N” is set, then the router indicates that it supports Type-7 LSAs. If the bit is set, then the “E” bit must be cleared. If two routers in the same area do not have the same setting of the “N” bit, then the OSPF adjacency between them is not established.

In the first part of the article, we discussed the most important LSA types:

  • Type 1 – Router LSA
  • Type 2 – Network LSA
  • Type 3 – Network summary LSA
  • Type 4 – ASBR LSA
  • Type 5 – External LSA
  • Type 7 – NSSA External LSA

And about the OSPF area types:

  • * Backbone/non-backbone area
  • * Stub area
  • * Totally stubby area
  • * Not-so-stubby area
  • * Totally not-so-stubby area

In the second part, we will see what is needed to configure the area types that we talked about, how to check if they are configured correctly by checking the routing table, and the OSPF link-state database.

References:

  1. OSPF and IS-IS: Choosing an IGP for Large-Scale Networks – Jeff Doyle
  2. Routing TCP/IP, Volume I – Jeff Doyle, Jennifer Carroll
  3. RFC 2328(http://www.ietf.org/rfc/rfc2328.txt) – OSPF Version 2