OSPF: WHAT IS A STUB AREA?

OSPF is easy to understand – once you get over the FIVE BILLION new acronyms and buzzwords that you need to memorise.

Unfortunately, the people who write study guides frequently insist on using as many of those buzzwords as they can in the space of a minute, so you end up having to wrap your head around sentences like “We filter Type 5 LSAs in the NSSA at the ABR, though the ASBR can still generate Type 7s and they’ll be swapped for Type 5s on egress to the backbone”. When I hear sentences like that, I conclude that it’s actually a good thing when nerds get bullied.

Stub areas are a good example of something that isn’t too complicated – unless you insist on explaining it using all the jargon under the sun, in which case it can be daunting. So, in this post I’ll start by explaining what a stub area is, without using any OSPF jargon. We’ll take it slow, like new lovers, or someone cooking an expensive turkey.

Then, once we’ve got the idea down, we’ll start to talk about the various LSAs (Link-State Advertisements) that our routers generate, to see exactly what’s going on under the hood when we configure this area type. Let’s do it!

(Hi there CCNP students! This blog mainly uses Juniper output, but shows you both Cisco and Juniper config examples. The behaviour is almost exactly the same between the two vendors, and on the rare occasions where the behaviour is different, I’ll let you know how both works. And hey, if you’re curious to see how Juniper config works, you might well enjoy my Junos for Cisco IOS Engineers series. Gosh I treat you well!)

 

WHAT IS AN OSPF STUB AREA? WHY MIGHT WE NEED THEM?

Imagine a large network, perhaps one that spans across an entire country, or one that goes all the way to the moon. Either way, this network probably contains hundreds of links, and thousands of prefixes. Is it exciting for you to think about a network so big? It is? That’s nice. You can keep on thinking about it if you like? If it’s making you happy? No need to rush away from that lovely thought.

What would such a network look like in practice? You’ve probably seen already in your OSPF studies that sometimes you might just have one large flat Area 0 backbone, while other times you might additionally have any number of branch office contained in their own OSPF area, attached to the backbone.

In that scenario, where you have smaller areas attached to the backbone area, here’s a question for you: do those branch offices really need to know every single prefix in your entire OSPF network?

The answer to that question depends on a lot of factors.

For example, does the branch area have just the one WAN circuit out to the rest of the network, or does it instead have multiple WAN links? If it is indeed just the one link, maybe you’d be better off with a single default route, instead of thousands of prefixes in your routing table which all ultimately point out of the same interface.

Another example: perhaps the routers at that branch are very old or cheap, and have limited memory? Sounds like another good reason to just have a default route, even if you’ve got multiple WAN links. After all, if you’ve got a $60 DSL router that can allegedly run OSPF, I’d bet money that its memory is pretty small. Just because a router can run OSPF in theory, doesn’t mean that it will run it well.

In those examples we’re thinking about replacing everything with just a default route. But if you’ve got a couple of links out, there might be situations where we actually do want to let certain prefixes through, to give us a balance between more optimal routing decisions vs keeping our router’s memory light. Perhaps we point a default route down one interface, and then we choose just a few more specific routes to “leak” into the area. Not everything: just our most important prefixes, let’s say. If you’ve got cheap routers that aren’t powerful, and you’ve got multiple WAN links out, that would be a perfect candidate for this scenario.

So then the next question is: how can we filter out the prefixes we don’t care about? How do we take just a small sub-set of the total prefixes in our OSPF domain, and advertise only them into this smaller area?

There’s a few methods available to us. One is to do it manually, using some kind of access list/prefix list, or a routing policy. Not a bad idea – but prone to errors, particularly if new prefixes appear elsewhere in the network which slip through your list.

So how about this: what if there was a way of just saying “filter out all prefixes that didn’t originate in OSPF”, or maybe even “filter out all prefixes that don’t originate from this area”.

Well, as it happens, that’s exactly what the different kinds of “stub area” do!

It turns out that the way OSPF advertises prefixes from other areas is different from the way OSPF advertises prefixes from within the area your router is in. The same is true for prefixes that didn’t originate from OSPF: redistributed prefixes are advertised in a slightly different way too. This “different way” involves using different types of Link-State Advertisement. You might remember that these LSAs are like the building blocks of the entire OSPF database, containing all the topology/prefix/cost information – and knowing the different types of LSAs that are generated gives us the power to choose which LSA types we want to let in, and which ones we want to get rid of.

Later on we’ll talk more about these LSA types. For now, let’s build a lab.

 

CHECK OUT MY SWEET TOPOLOGY

Here’s a silly topology I’ve made to highlight the different kinds of area we can choose from, and what happens when we choose them. It’s a perfect topology for a lab – but if you ever see anyone design a network like this in real life, fire them.

You can see that we have a small Area 0, with two other small areas attached to it: Area 1, and Area 2. If something in Area 1 wants to talk to something in Area 2, the traffic has to go via the Area 0 backbone. That’s the law!

Router 4 itself is home to six IP ranges: 4.1.1.0/24, 4.1.2.0/24, and so on. These ranges all live within Area 2. Keep an eye out for these prefixes when we look at Router 1’s routing table in a moment, because we’re going to do some magic with them.

Router 5 is outside of our OSPF network. And hey, guess what: Router 5 is also hosting six IP ranges. What are the chances of these ranges starting with a first octet of 5? One hundred percent chance! Yep: 5.1.1.0/24, 5.1.2.0/24 and so on.

Router 4 is learning these six prefixes by BGP, and there’s a policy on Router 4 to re-advertise them into OSPF. This makes Router 4 an ASBR, or Autonomous System Boundary Router. Calling a router an ASBR is basically a fancy way of saying that the router lives on the border (ie the boundary) of the network, connecting the OSPF world to the BGP world.

WARNING: In the real world you’ll want to be very very very very VERY careful about redistributing BGP into OSPF. But this is just a lab, so let’s throw caution to the wind.

In this topology, our boundary router actually does live on the boundary of the network. However, it doesn’t have to. In fact, if you have static routes on any box, and you redistribute them into OSPF, then technically that router has been promoted to being an ASBR! Even if that router lives slap-bang in the middle of the network, OSPF would still call it a “boundary” router. This makes sense when you think of static routes as being their own protocol. The router is acting as the boundary between OSPF and the static routes, like a bouncer at a night-club acting as the boundary between “you” and “getting your funk on”.

 

LET’S MAKE FRIENDS WITH ROUTER 1’S ROUTING TABLE

Let’s look at the routing table on Router 1, a router in Area 1.

(Hey there CCNP students: notice in this screenshot that in Junos, we just type “show route” rather than “show ip route”.

Also hey there: do you see how all the IPs are just listed in numerical order, rather than in a seemingly random order that’s then sub-divided by the extremely legacy “classful addressing” system which hasn’t been used in about 25 years, like IOS insists on doing it? I don’t know about you, but I find this layout FAR easier to read!)

Router 1’s routing table is pretty big, considering that Area 1 only contains one and a half routers! It’s clear that Router 1 knows about every single prefix in the entire network, including all six of the 4.1.x.x/24 prefixes from Router 4, and also all six of the 5.1.x.x/24 prefixes that were coming in from BGP.

(CCNP students: notice that OSPF’s administrative distance (what Junos calls the “route preference”) is different in Junos: 10 for regular OSPF, 150 for external OSPF.)

What we’ve learned here is that the default behaviour in OSPF is to take all prefixes from one area, and advertise them to another area. The border router between Area 0 and Area 2 takes all the prefixes in Area 2, and redistributes them into the backbone. Then, the border router between Area 1 and Area 0 takes all the prefixes in Area 0, and redistributes them into Area 1.

You can imagine that in the real world, this default behaviour would mean that a small branch router could potentially be learning thousands and thousands of prefixes! Is that really necessary? No sir/madam!

So, let’s make area 1 a “stub area”, and see what happens. How do we do that? Whether we’re using Juniper or Cisco, it’s hella easy. We just need to add the config below onto every box in area 1. It’s really important that it’s added everywhere in Area 1, otherwise our adjacencies won’t come up.

If you’re rocking dem fine Juniper boxes, it’s one command:

[edit]
root@Router_1# set protocols ospf area 1 stub

As for Cisco IOS, it’s just as easy:

R1(config)#router ospf 1
 R1(config-router)#area 1 stub

What’s the result of this config? To find out, let’s look at the routing table on Router 1 AFTER we turned Area 1 into a stub.

Give yourself ten points if you’ve spotted the difference: all the prefixes from the 5.1.x.x/24 BGP ranges are gone!

Our routing table is significantly lighter now. Scale this out to many thousands of external prefixes, and the value of a stub area becomes clear.

What have we learned? “Stub areas” block any prefixes that meet these two conditions: a) they’re being passed from Area 0 into the stub area, and b) they originally came from another protocol, redistributed into OSPF.

Remember, static routes count as “another protocol”. Folks often forget this, and end up filtering out prefixes they don’t mean to filter out!

In the next section we’re going to see how the different types of Link-State Advertisement are used to make this filtering a breeze.

Before we move on though, you might be wondering: it’s not much use filtering out those prefixes if we don’t have some alternative way of getting to them. Perhaps we need a summary prefix like a /22, or even a default route?

Interestingly, if Router 2 were a Cisco, it would actually advertise a default route by, er, default! It’s the standard behaviour, no extra config needed. On the other hand, Junos doesn’t assume that you want a default route. Junos leaves you to configure one if you do.

Luckily, getting Junos Router 2 to advertise this default route into Area 1 is as simple as adding two extra words to the command we typed earlier:

[edit]
root@Router_2# set protocols ospf area 1 stub default-metric 10

Neither vendor’s behaviour is better, or right, or wrong. What matters is to know the default behaviours of each vendor, and know when to override them. Truly, this attitude is the solution to a more peaceful and better world.

 

LET’S REVISE TYPE 1 AND TYPE 2 LSAs

Let’s talk more about these Link-State Advertisements that OSPF creates.

An LSA is basically like a database item that a router generates and then advertises to all other routers, that tells the rest of the network some interesting information about that router’s presence on the network, for example:

• The router’s unique ID
• What links are attached to the router
• What IP networks live on those links
• What the metric/cost is on that link
• Whether the link is attached to a shared segment, like an ethernet switch with multiple routers on the subnet

These LSAs are like pieces of a jigsaw puzzle. When every router has received every single LSA from every box in its own area, every router in the area can put them together to create the entire area’s topology – and crucially, every router in the area will have exactly the same set of LSAs, and therefore exactly the same view of the network.

There are lots of different kinds of LSA, and each one serves a different purpose.

For example, you might have learned already that a Type 1 LSA is also known as a Router LSA. Routers generates this LSA to say what the router’s ID is, what links are attached to it, and what prefixes are on those links. It will also list the cost of the link. Type 1 Router LSAs are one of the essential building blocks for creating the topology itself.

However, it’s not the end of the topology story: if a link is part of a shared segment, like that ethernet switch we mentioned a moment ago, then there’s actually a special LSA that describes this shared network, and lists all the links attached to it. It’s called a Type 2 LSA, which is also known as the Network LSA.

I want to stay focused on stub areas for now, so what I’m about to say is an oversimplification: a Type 2 Network LSA helps to simplify how routers calculate best paths.

Imagine fifteen routers on a shared segment, all connected to a switch. Without this special Type 2 LSA, the topology would logically look like each of these 15 routers had a direct point-to-point connection to every other router on the LAN. That’s a lot of links! Instead, the Type 2 Network LSA makes it look like there’s an invisible zero-cost router in the middle of it all – which, in effect, there is! There’s a switch, and all routers connect to it.

If you’ve got just the one area, then chances are that you only need those two kinds of LSA: one to advertise the routers themselves and the links they’re hosting, and one to advertise the existence of shared broadcast segments. Indeed, if you configure all your ethernet links as point-to-point, you could actually have a network made up entirely of Type 1 LSAs. Pretty simple!

 

LET’S REVISE TYPE 3 LSAs

However, if you’ve got multiple areas, like in our diagram, then chances are you might also have a few Type 3 LSAs, otherwise known as Summary LSAs.

Don’t be fooled by the name: the word “summary” here doesn’t refer to summarising multiple subnets into a single bigger subnet. Instead, the summary LSA is actually summarising the topology information.

In our lab network, Area 1 doesn’t need to know the topology of Area 0 and Area 2. Area 1 possibly needs to know about the prefixes in those areas – but not the topology. Indeed, that’s exactly why we’ve chosen to put Area 1 in it own unique area. A link going down in Area 0 or Area 2 shouldn’t mean that Area 1 needs do any new best-path calculations.

But what definitely should happen is that the relevant prefixes need to disappear from Area 1.

With that in mind, the router connecting Area 1 and Area 0 – the Area Border Router, or ABR – takes every prefix it’s learned from Area 0, and re-generates them as new Link-State Advertisements pointing to itself. It then advertises these prefixes into Area 1 via these special Type 3 Summary LSAs. In our topology, you can think of Router 2 almost as if it’s taking these 4.1.x.x/24 prefixes, and changing the next-hop to itself. Instead of telling Area 1 that these IPs live on Router 4, Router 2 is saying “don’t worry about where these prefixes live. All you need to know is that you can get to them via me, and I’ll take care of the rest.”

 

LET’S REVISE TYPE 5 LSAs

There’s one more Link-State Advertisement type that I want you to know about: External LSAs, otherwise known as Type 5 LSAs. As the name says, External LSAs represent IPs that live outside of the network. They’re generated by the border router, aka the ASBR, aka the Autonomous System Boundary Router – the router doing the redistribution.

At this point, many folks often wonder “Does OSPF actually need so many LSA types? This seems excessive!”. Well, you could argue that OSPF doesn’t need them – but by having many different types, it actually gives us some useful advantages.

For example, by having an LSA specifically for IPs that are external to OSPF (the Type 5 External LSA), it means that if we want to filter out these external prefixes, we don’t need to do anything complicated, like making access lists or prefix lists – all we have to do is block Type 5 LSAs! “Don’t give me any Type 5 LSAs”, our plucky router says. “I’m on a diet. Type 5 LSAs are empty calories to me.” This is what the routers say. This is literally what they say.

And, as you might have guessed by now, all we had to do to filter out these Type 5 LSAs was to configure Area 1 as a stub area. Like a lot of things in networking, the theory involves a lot of reading – but the actual configuration is one single line of config.

 

TOTALLY STUBBY AREAS

But it doesn’t stop there, because there’s another kind of stub area that can block even more stuff: Totally Stubby Areas. This area not only blocks the Type 5 (External) LSAs, but it also blocks Type 3 (Summary) LSAs too. Do you remember we talked about those a moment ago? They’re the ones that summarise the topology, and just advertise the prefixes of one area into another area.

If you configure an area to be Totally Stubby, you’ll get rid of both Type 3 and Type 5 LSAs. And just like a stub area, it’s super easy to configure.

In Junos, we add this extra config below to Router 2, the Area Border Router. We only need to add this extra config onto the ABR, because it’s this box that’s deciding whether to re-advertise the Type 3 Summary LSAs into Area 1.

[edit]
root@Router_2# set protocols ospf area 1 stub no-summaries

All routers in the area need to know it’s a stub area, but only the Area Border Router needs to know to filter out Summary LSAs.

As for Cisco, it’s like this:

R2(config)#router ospf 1
 R2(config-router)#area 1 stub no-summary

It’s interesting how neither vendor uses a command that’s something like “area 1 totally-stubby” or something. Instead, we make it a stub area, and then we say “no summary” – in other words, no summary LSAs.

The result of getting rid of all External AND all Summary LSAs is a routing table on Router 1 that’s vastly smaller than before:

(Once again, Cisco will give you a default route here, whereas Junos needs the “default-metric 10” command.)

Woah – every single OSPF route is gone! Is that really correct?

Well, in our topology, yes! It’s a very small network, after all. If there were other routers in Area 1, I’d still be learning those prefixes by OSPF with no problem. But as it happens, the only OSPF prefixes that were previously in Area 1 came from other areas, or from outside of OSPF altogether. And now, they’re all gone!

So, now you know all about the behind-the-scenes mechanics, we can finally give a more accurate definition of a stub area:

A stub area blocks Type 5 LSAs. A totally stubby area blocks both Type 3 AND Type 5 LSAs.

 

NOT-SO-STUBBY, AND TOTALLY NOT-SO-STUBBY

There’s actually two final types of area to know about: Not-So-Stubby Areas (NSSAs), and Totally Not-So-Stubby Areas. Yep: that is their genuine name, because OSPF is absolutely ridiculous.

Looking one final time at our topology, imagine that Area 2 was also a stub area. Now, think about those BGP prefixes that are being imported into the area as Type 5 LSAs. What’s the definition of a Stub Area? That’s right: it’s an area that blocks Type 5 LSAs. But if Area 2 is a stub area, and a stub area blocks Type 5 LSAs, then how can we import these BGP prefixes?

That’s where NSSAs come in. They’re basically a hack: instead of importing those BGP prefixes as Type 5 LSAs, Router 4 would actually import them as Type 7 LSAs. That’s right: YET ANOTHER LSA TYPE TO REMEMBER!

Type 7 LSAs are called Not So Stubby Area External LSAs – and the amazing thing is, they’re almost exactly identical to Type 5 External LSAs: they allow us to bring in external prefixes, while not breaking the “No Type 5” rule. Then, when Router 3 re-advertises them from Area 2 to Area 0, it converts them from Type 7 to Type 5.

Totally Not-So-Stubby Areas are exactly the same as Totally Stubby Areas – they filter out both Type 3 and Type 5 LSAs, but once again we can use Type 7s to bring in external prefixes.

And with that, we’ve covered the ridiculous world of Stub Area types, and LSA types. You will have your own opinions on whether this is all “very clever” or “absolutely nonsense”. All I’ll say on the matter is that there’s a reason why I prefer IS-IS as an interior routing protocol.

 

THAT’S IT!

I hope I’ve helped to clarify things a little bit! There’s a lot going on – but once it clicks, it’s really satisfying. By the way, you might have heard of something called a “Stub Network” in OSPF, and wondered whether it’s the same thing as a Stub Area. Confusingly, it turns out they’re different things. I’ve written a post all about it, so click if you’re interested!

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

And if you find my blog useful or entertaining, I’d love you to share it with your friends and co-workers, whether via a Twitter/Facebook/LinkedIn post, or just emailing it to them directly. Spread the world, and I’ll be inspired to write even more posts.

And if you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.