OSPF Area Types and LSAs

| | Comments (2)

OSPF area types and LSAs seem to be somewhat misunderstood concepts. If you've read this far, you're probably already aware that OSPF makes use of areas to break up the potential administrative nightmare of running an IGP in a network. If you've read THIS far, you're probably also aware that area 0, the backbone area, has a special significance to OSPF. The other area types and the link state advertisements used to toss information around between the routers are where a lot of people get confused.

Standard Areas


A standard area is often described with a phrase like "A standard area is the most basic type of area". Well great - 'standard' in what way? Standard areas can be thought of as being the "equal opportunity employer" of OSPF areas as every router in the area knows about every route. This is just fine if the routers are high-powered enough to store every route and run the SPF calculations without getting bogged down. Type 1 and 2 LSAs are passed between routers to convey information regarding their own interfaces and their neighbors. Internal routes, communicated by type 3 LSAs, and external routes, communicated by type 5 LSAs are sent through all standard areas as well as the backbone area, which is a type of standard area. Type 3 LSAs can be sourced by any OSPF router whereas type 5 LSAs only ever come from autonomous system border routers. Autonomous system border routers are also responsible for generating type 4 LSAs. An area border router that has an interface in that area and an interface in the backbone area will inject the type 4 LSA into the backbone area to ensure the route to the autonomous system border router is known. Type 4 LSAs are only passed internally.

In summary, a standard area can contain LSAs of type 1,2,3,4, and 5.

Stub Areas


If an area can be thought of as a leaf node on a network then a stub area may be appropriate. A stub area can be handy if devices in it are low-powered, or simply have no need to know about every route. A stub area is similar to a standard area, but routers in it are not aware of externally-sourced routes directly. In terms of LSAs, that means that type 5 LSAs are not permitted in a stub area. A type 3 LSA is injected into the area by an area border router to act as a default route, allowing connectivity outside the stub area. The type 3 LSA provides the equivalent of an "All Points East" sign for stub area routers. Type 4 LSAs are not forwarded into a stub area, as the default route is used.

For a router to be in a stub area, the area must be configured as such on all routers involved:

Weasel(config-router)# area 3 stub

In summary, a stub area can contain LSAs of type 1,2, and 3.

Totally Stubby Areas


Totally stubby areas are a Cisco invention designed to take the concept of a stub area one step further. In addition to the lack of type 4 and 5 LSAs, type 3 LSAs, which carry information about internal routes are also prohibited. The concept of an injected default route still applies (the only instance of a type 3 LSA in a stub or totally stubby area) but it also covers internal routes. All traffic leaving the area does so using this default route. While I've never tried this in a lab, I've been told that one can have multiple 'default routes' (in stub, totally stubby, and not-so-stubby areas) and internal metrics will be used to select the least-cost route. If you've tried this, let me know.

To configure an area as a totally stubby area, use the no-summary argument when defining the area:

Vole(config-router)# area 4 stub no-summary

In summary, a totally stubby area can contain LSAs of type 1 and 2 as well as a type 3 LSA for the default route.

Not-so-stubby Areas


Yet another Cisco-concocted area type, the NSSA is a variant of the stub area type but is allowed to contain an autonomous system border router. Since type 5 LSAs are not permitted in stub areas of any type, a type 7 LSA is used. For the record, there is a type 6 LSA that is used by Multicast OSPF. MOSPF is an extension of OSPF designed to support (surprise!) multicast. At any rate, a type 7 LSA is essentially a type 5 LSA with a fake beard and glasses on. It performs the same function as a type 5, but is permitted through NSSAs. A hard-learned lesson for me was that by default an NSSA does NOT have a default route injected into it by an area border router. To have one (yes, please) the default-information-originate argument must be used:

Marmoset(config-router)# area 5 nssa default-information-originate

This comes in handy if one wishes to route traffic out of an NSSA.

If totally stubby area functionality is desired, all area border routers must be configured appropriately:

Marmoset(config-router)# area 5 nssa no-summary

Note that if an NSSA is configured to behave like a totally stubby area, a default route IS injected by the area border routers so the default-information-originate parameter is not necessary.

In summary, a not-so-stubby area can contain LSAs of type 1,2,7 and if configured for it, a type 3 for a default route.

Bonus Fact


Type 8 LSAs are very rarely used, but can carry BGP information over OSPF. I haven't the faintest idea how to use them, so don't ask.

LSA types 9 - 11 are called 'opaque LSAs' and are reserved for future growth. I plan to make use of them in my proposed "Kinda-stubby-but-only-if-you-squint-right" area.

While I'm pretty sure all of this is correct, it's possible that I either missed something or made a type somewhere. If you spot an error, please let me know so I can correct it.

2 Comments

You're getting pretty good at Layer 3 stuff. This isn't surprising at all as you picked up all the Layer 2 pretty quick.

I know you aren't a big fan of gns3 but you can do some really cool stuff with virtualized linux hosts and virtualized IOS devices.

I'm going to do a post on a advanced type config shortly.

Virtualizing Cisco devices does have some interesting possibilities. I don't claim to begin to understand what, but given time I plan to. I'll be looking for your article and hopefully it'll spawn some ideas!

About this Entry

This page contains a single entry by Philip Ratzsch published on April 22, 2010 9:10 PM.

IPv6 and OSPFv3 was the previous entry in this blog.

Intro to BGP route-maps is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.