[AUDIO LOGO]
So now that we've taken a closer look at Multiarea OSPF,
let's jump into the command line and take a look
at some of our database commands to see what this actually looks
like in the OSPF database.
So we'll start off by looking at our topology, how
our areas are currently set up.
Then we'll jump in, we'll take a look at the databases,
as well as watching how Dijkstra's algorithm actually
runs now that we have different areas in our OSPF environment.
So let's start off by looking at that topology.
So for this demonstration, we will be using OSPF topology 2.
And what we see here is now do we not only have area zero,
but we also have area 100 and we have area 200.
The way things are configured we have
router 6 is acting as an ABR.
So is router 1 and router 3.
We also have router 2 over here, which is an ASBR bringing
in external routes from EIGRP.
Now in this demonstration, we're simply
going to be focusing on what's happening inside of OSPF
with our different areas.
So we won't really be looking at the external routes coming
from router 9 at this point, we'll be using that later.
But for now we're going to focus on what happens when failures
occur in these different areas now that we're not
in one big area.
So let's jump into the command line,
and we're going to start by looking at area 200
since this is a very small area and let's see what happens
when a failure occurs there.
So let's start here on router 6.
And let's turn on a debug of IP OSPF SPF
and we'll go over to router 10, and let's shut down
one of its interfaces.
Specifically, we'll just shut down its loopback 0 interface.
Now let's go back over to router 6,
we'll turn off our debugging.
And what we want to notice here that SPF ran and notice that it
only took 8 milliseconds for this to occur,
which is significantly faster than what
happened when we ran this earlier when everything
was one big area.
So even in an environment as small as this,
we're definitely getting a performance increase
by having multiple areas.
So let's bring that interface back up on router 10.
So now let's take a look at what happens when
a failure occurs between areas.
For this demonstration, let's keep an eye
on what happens on router 7 when we
create a failure on router 5.
So we'll start by doing our observations on router 7.
Let's start with the show IP route OSPF.
Notice that we do have an entire area route for 10.5.5.5
which is router 5's loopback.
If we do a show IP OSPF database,
notice that we also have numerous type III LAs here,
which are the summary net link states.
And notice that we in fact, have one for 10.5.5.5.
In fact, we have two, one coming from each of our ABRs.
And finally, let's do a show IP OSPF.
And when we want to look at specifically
is for area zero how many times SPF has actually executed.
At the moment it's 129 times.
So let's take a look at what happens now if we shut down
that interface on router 5.
Let's turn on our debug.
So we'll debug SPF here on router 7
then we'll go over to router, 5 and we'll
shut down that interface.
Let's go back over to router 7.
We notice here that it definitely did calculations.
We can see where the network is being removed,
and we see that it processes things.
But what's not here is any calculation for how long it
took to run SPF because it didn't.
If we say show IP OSPF again, notice
that the execution of the SPF algorithm is still at 129 times
even though we recognize the failure.
And if we do a show IP route OSPF,
we'll see that the 10.5.5.5 is now in fact missing,
and we don't have it in our database either.
So we've removed it from our database,
we've removed it from our routing table
but we did not execute SPF.
This is the big advantage of having multiple areas in OSPF.
When a change or a failure or anything
happens in another area, yes we learn about it.
Of course we do, this wouldn't be much of a routing protocol
if we didn't, but we're not running SPF.
We still remove it from the database,
we still remove it from the routing table,
but we don't have to run SPF every time something changes
in another area, that would even include the route coming
back up.
Let's go back over to router 5 and bring that interface back
online.
So we'll pop over here, we'll do a no shut
to bring the interface back up, back over to router 7.
Notice once again, we're adding the routes back
into the routing table.
We do a show IP route OSPF, there's
the 10.5.5.5 back in our table again.
We do a show IP OSPF database, the 10.5.5.5
is again here in the database.
However, if we look at our show IP OSPF, notice
still the SPF algorithm has only executed 129 times.
We're not running SPF because the changes are not
occurring in this area.
In this video, we took a look at how the database reacts
and how the execution of SPF reacts
when changes occur both within our smaller areas,
as well as what happens between areas
when we have a failure that's not
in our directly connected area.
So we saw that within the area things
happen faster because it's a smaller area.
And we saw that between areas although we of course
lose the database entry and therefore the route,
we don't run SPF when something changes in a different area
when we're doing Multiarea OSPF.
And this is what adds to the scalability
of doing Multiarea OSPF.
I hope this has been informative for you,
and I'd like to thank you for viewing.