[AUDIO LOGO]
So in this video, we're going to start
by just getting an overview of the different OSPF area types
that we have available.
So we'll be talking about the stub, the totally stubby area,
the not so stubby area, and the totally stubby, not
so stubby area, which we really just often refer
to as the total NSSA just because it's
a lot easier to say.
It's a bit shorter.
So let's jump in and take a look at these different area types.
We'll bring up our topology map.
And we'll talk about which LSA types are or are not
allowed into which areas and how they get filtered and where.
So let's go ahead and jump in and get started.
So to begin, we will talk about the normal or the regular area.
Now, there's not really a whole lot
to say about these as it's sort of what we're
working with normally in OSPF.
This is an area type that allows all LSA types.
Now, we say all, we mean all normal LSAs.
So that would effectively be type
1's, 2's, 3's, 4's, and 5's.
Remember that 6's are used for multicast
and not supported by Cisco.
And a type 7 is actually a very special use.
We'll see that here in just a couple of minutes.
So a type 7 would not actually be in a normal area.
Now, the next thing to take note of
is the backbone area must be a normal area.
Of course, we're referring to area zero up here.
You cannot have the backbone be a non-normal area.
It must support all of these LSA types.
Also note that virtual links, which
we'll be talking about later in this course,
can only transit a normal area.
They can't transmit a stub or a not so stubby area.
It has to be a normal area.
So other than these few attributes,
there's not really a whole lot to say about the normal area.
Again, this is what we have by default
if we just create an area in OSPF.
So now let's move on to the stub.
So the main idea behind the stub area
is that we want to filter out the type 5 external LSAs.
And at the same time, since the type 4
is used to support the type 5, we'll filter those out as well.
The idea is a stub area--
a good example of this would be something
like area 200 up here--
would not need external routes such as this one coming
from EIGRP over here.
We don't need it as long as we inject a default
route into that area instead.
So if we inject this default into area 200,
there is no need for area 200 to get
external routing information from other areas such as area
100.
We can just default right to the ABR.
Now, a side effect of all of this, of course,
is that if we cannot have type 5 LSAs, in other words,
we cannot have external routes, then an ASBR, which, of course,
by nature, is bringing external routes into OSPF,
cannot exist in a stub area simply,
because type 5 LSAs are not allowed.
Also, since having external routes in the database
would affect whether the database is
the same between two devices, all of the routers in an area
must be configured for it to be a stub area.
Again, the simple reason for this,
all the routers in an area must have identical databases.
I can't have one router, thinking
that external routes are OK, and another router saying,
no, they're not.
We have to agree on what LSA types are
allowed in the database.
So stub areas are good in situations where
we don't need external routes.
And with this default route coming into area 200,
we have to ask ourselves, do we even need the other type
3 LSAs?
Do I even need router 8's loopback address, for example,
if I can just follow the default?
If the answer to that question is
no, which would be the case here because router 6 is
the only way out of area 200, well, then we
can move on to a total stub.
So any time we see the word "totally" in relation
to OSPF areas, just think about blocking type 3 LSAs.
If we look at the rest of these points,
that we block type 5's, and we block type 4's.
And there's a default route injected,
and there can be no ASBR.
And all of the routers have to be configured for stub area,
all of these things are the same things
we said about the stub area to begin with.
So what the real difference here is the type 3 LSA.
And what we're going to do is we're
going to stop things like router 8's loopback that
would normally come in to area 200 as a type 3.
We're going to, in fact, filter that and not
send it in at all since we're getting the default.
So the difference between a stub area and a total stub
is, simply, we don't send the type 3 LSAs
into the total stub.
This is further filtering that's happening on the ABR.
Now, the default it injects will still be a type 3.
So it's not the type 3's are not allowed in the area.
It's just the ABR is filtering them out.
Now, this isn't going to be perfect in every environment.
If there's more than one exit from the stub,
we may prefer one ABR over another ABR coming out
of that area.
In that case, we would want the type
3's so that we can prefer specific prefixes through one
ABR versus another.
So in that case, you would want to just do
a stub, not the total stub.
But in the case of our area 200 here, it only has one way out.
So there's no need to have anything other
than that default.
Now, one of the big limitations here of a stub area is that
an ASBR cannot exist in this area type.
So maybe we just had a few external routes
we wanted to bring in.
Well, we can't do that in a stub.
And because of that, we have another area type,
the Not So Stubby Area, or the NSSA.
So the idea behind the NSSA is that although we are still
not allowing type 5's and type 4's,
we can still bring in external routes.
Now, one other fundamental difference here with a stub
is that a default route is not injected automatically
into the NSSA.
And we'll see that more when we actually
look at this in action.
However, the biggest difference is that an ASBR actually
can exist in this area.
It's going to use LSA type 7 for those external prefixes.
So a good example would be area 100 here.
If we were going to try to make this a stub,
we would lose the routes from router 9 coming in from EIGRP.
Well, that's not what we would want to do.
We do need those routes.
So if we still want to bring those routes
into this area, meaning, of course,
we still want router 2 to be an ASBR,
the only choice would be to make this NSSA.
What happens is these updates come in as type 7's.
That type 7 will then get translated into a type 5
by one of the ABRs and sent into the rest of the network.
So the type 7 only exists inside of the NSSA.
Now, at the end of the day, this is still a stub.
So keep in mind those type 5's and those type 4's are still
not allowed.
And, again, just like we said before,
since that's affecting what's in the database,
all the routers are going to have to be configured for NSSA
just like they did for the stub.
Now, the NSSA is actually probably our more complicated
of the area types.
So we're going to jump in and take a look at this.
And we're actually going to spend
a little bit more time on this one
than we do on stub and total stub.
NSSA does get a little more complicated.
So we'll see that in an upcoming video.
But just like we have for stub, there's a counterpart here.
So as we had stub 2 totally stubby,
we also have NSSA to the total NSSA.
Let's take a look at that one.
So just like with the total stub, the totally NSSA,
or the total NSSA, as it's more commonly referred to,
simply adds that additional filtering of the type 3.
Again, all the rest of these points
are going to be exactly the same as the NSSA.
The only real difference is, once again, on the ABRs.
Any type 3's that would be sent into this area
are going to be filtered out.
A couple of things to note about the use of total,
be it for the stub or the NSSA.
Technically, the total stub and the total NSSA
are Cisco proprietary.
However, since it's just the ABR doing additional filtering,
the other routers in that area don't know anything
about that total flag.
They don't know anything about the fact
that the ABR is doing extra filtering.
So even though it is technically Cisco proprietary, that
doesn't really affect compatibility
with other vendor's routers because,
again, they don't know it's happening.
And, also, on that note, the total
only has to be configured on the ABRs.
And there's nothing that stops those
from still forming neighborships with other devices that
are just configured as either stub or NSSA.
So in this video, we just took a look
at the basics of the different OSPF area
types, their attributes, which LSAs are sent between which
areas, and a little bit more look at where that type 7
LSA is used in the NSSA.
In the next video, we're going to jump into the command line
and get started looking at this, starting
with the stub and the total stub.
I hope this has been informative for you,
and I'd like to thank you for viewing.