So now that we have covered the basics of OSPF including
neighborships and the communications blocks that are used
in single area OSPF designs, we will move on and talk about multi-area OSPF.
Up to this point in the course we have focused on how OSPF
works in a single area configuration.
This type of configuration is reasonably easy to configure and works
very well when the size of the network is very small,
but problems can begin when a network grows.
Remember from the previous module that type 1 router and type 2
network LSAs are sent to every area OSPF device,
and type 5 external LSAs are sent to every domain OSPF device by default.
So what this means is that in a single area configuration,
the databases of all devices are identical,
which on its face is the point of a link state protocol; however,
in a large network,
do you really want to have every device know about every other device,
as well as every network that is attached to each one of those devices?
As you would imagine,
this behavior which works very well in smaller networks would
make a large network inefficient quickly.
The reason for this is the size of both the link state database,
and in the volume of communications that would be required to maintain it.
Let's think about this for a minute.
If a large network has 50 devices, which really isn't all that large,
but it works well here,
all 50 of these devices would need to know about each other.
This is done with a router LSA.
So at a minimum, each one of these devices would have these 50 entries,
which would include link entries for every link connecting the 50 devices.
This assumes that none of these links require a DR.
If they did,
then additional network LSAs would need to be added
to further describe these links,
but since the point in the network is not to solely
route between network devices,
we would need to include entries for every connected LAN network.
These would add additional link entries inside the router and network LSAs.
So now what happens if any one of these LAN links fails?
When this happens,
the devices involved in the failure would re-originate an LSA or LSAs
that would notify the other devices of the link failure.
Remember, since the link state databases must be identical inside the area,
every one of the other 49 devices would need to receive the update,
update its database, and relay the information to any of its connected neighbors.
And remember this is just one link failing.
What happens if multiple links fail, or if a device reloads,
or if someone changes a configuration?
All of these cause a large amount of burden both in terms of
device processing and in network utilization.
So how would we possibly limit this burden?
This is where the design of a network can make a large difference.
OSPF has the ability to support multiple areas.
These areas can be structured in a segmented, hierarchical design.
With OSPF this includes a primary area that sits in the middle of all others.
This is referred to as a backbone area or Area 0.
All other areas are required to have a connection with this backbone area.
When multiple areas are used,
the router and network LSAs are limited to within a single area boundary,
thus reducing the demand on devices in other areas.
Of course, by doing this, you also lose some reachability information.
To avoid this from happening, additional LSA types are used,
specifically the summary LSAs, type 3, and type 4.
A type 3 summary LSA is used to relay reachability
information from one area into another.
Essentially it takes the information that is stored
inside the router and network LSAs, condenses it,
and sends it into another area.
A type 4 summary LSA is used along with a type 5 LSA to ensure that
the autonomous system boundary router or ASBR that is advertising an
external network is reachable domain wide.
Additional,
more in-depth details of these new LSAs will be covered in a later section.
For now let's move into the lab and take a quick look at
what this looks like in a live environment.
Let's get started with our first lab here,
and what we're going to do first is we're going to take a look at the
topology as it's been altered for a multi-area OSPF design,
and this is just an example design; there are several
different ways this could have been put together.
For the purposes of this course,
the core routers and the Ral1 and NYC1 routers are part of Area 0,
and Ral1 and Ral2 are part of Area 1, and then all the NYC routers,
NYC1, 2, and 3 are all part of Area 2.
So let's move into the lab real quick and we'll just take a look real
quick at how this looks a little bit different,
and then we will move a little bit further down in the slides and we will
slowly move deeper into how this design differs in terms of how the
information is exchanged than with a single area design.
So if we move into Core 1,
we're just going to do a quick show of the routing table
and see how it differs from our previous adventures in the
lab in our previous modules,
and what we'll find here is that all of the networks that were
advertised in the former labs are all still here,
but what is different is these last few entries here,
the 20 network advertisements and the 30 network advertisements are
shown with this little additional IA thing here,
and to be clear, the 20 network has been configured on the Ral routers,
and the 30 network is configured on the NYC routers.
But this little IA addition here, if we look up here at the legend,
we'll see that IA stands for OSPF inter-area.
Now if we remember the terminology, inside an area is intra,
in-between areas is inter.
So in this case all of these routes that are up here that
just have an O on them are intra routes,
which are inside the area of, in this case Core 1,
and the IA routers, the O IA,
these are all routes that are being advertised from a different area,
and as we just looked at the topology and we said that the Ral
routers are in Ral routers are in a different areas and the NYC
routers are in a different area, this shows that organizational difference.
If we look at the show ip ospf neighbor,
the neighborships look exactly the same.
If we move to the Ral router, Ral1, the neighbors are going to look the same,
but the database is going to look a little bit different.
So if we look, he still has three neighbors,
one to Core 2, one to Core 3, and one to Ral2,
but if we look at the show ip ospf database command,
we'll see there's a much longer-looking database.
And if we look closer we'll see the front half here.
These are all the routes that are part of the link state database in Area 0.
In this case the Ral1 router is actually part of both areas at the same time.
He's part of Area 0 and he's part of Area 1.
So because he's part of both areas,
he must have an identical link state database for two separate areas.
So the first part of that is for Area 0,
which is shown in these link entries on top here.
This is the router link states so this is the router LSA, the type 1.
These are the network LSAs or type 2,
and we mentioned previously in a slide and we'll look a
little bit closer into what this means, this is the type 3 summary LSA,
and what we'll see if we move down a little bit in here is he also has router
links for Area 1 so these are specific to only Ral1 and Ral2.
So you only see two devices here, whereas above here we'll see all of,
so we know from this there are five different entries under router.
So this means there are five devices that are in Area 0,
and we look down here and we know that there are two
routers that are part of Area 1.
And again, there are no type 2 network LSAs in Area 1,
but there are several type 3 summary LSAs,
and these are advertised.
If we look a little closer we can see these are all the networks,
if we look at this first part,
these are all the networks that are connected in different areas.
So these are the advertisements that have come from a different
area and have been converted into a summary LSA so that both the
Ral1 router and the NYC1 router are going to have two separate
link state databases, one for each area that they are part of.
So with that,
let's move into the next section where we'll talk about these different OSPF device types.