[CBT NUGGETS THEME MUSIC]
So the next thing we want to talk about with OSPF
is optimizing it.
And probably the best way to optimize
it is to start with looking at some of its timers
that we can adjust to make it respond faster to errors
and to converge faster.
So let's start by jumping in and looking at the different timers
we can adjust.
And then we'll jump into the command line
and see some of those timers in action.
So as we said, one of the easiest ways--
and you could argue probably one of the best ways as well--
to increase OSPF performance is to adjust
some of those default timers.
Some of the default timers are fine, and some of them
need to be adjusted.
So let's go through and take a look
at what we can and should change.
Keep in mind as we go through this that the default timers
for many protocols--
I'm not just picking on OSPF here--
but of course, including OSPF, these
have been around for a long time, decades.
And at that time, we had different networking
technologies in place, and possibly even more importantly,
different equipment.
I remember when I first started doing Cisco routing.
A lot of the routers back then couldn't even
run full-blown OSPF.
They could run OSPF if it was a stub area,
but they couldn't run full-blown OSPF.
The equipment just couldn't handle it.
Now, of course, it's no problem.
All of the devices can run full-blown OSPF.
And since the equipment is so much better,
that's going to change how quickly they can process OSPF.
A lot of these timers were there to throttle these routers
so that they could handle OSPF on lesser equipment.
So the first of these timers that we should really look at
are the timers that determine how quickly we detect
the failure of a neighbor.
Now, the reason we have to do this
is to find a route around that neighbor if possible,
assuming that there is redundant links.
The two timers involved in this--
so the two things we have to be concerned about--
are the Hello and Dead timers.
It is recommended to keep these at a 4 to 1
ratio, where the Dead timer is four times the Hello timer.
Now, note that the default for these values
is based on the OSPF network type.
Most modern networks-- this would include things
like ethernet, point-to-point lengths.
So most of our modern network types
are going to default to 10 and 40.
Again, that's a 10-second Hello with a 40-second Dead timer.
Some traditional WAN network types--
and one that we might still have to be concerned with today--
would be network type point-to-multipoint.
The reason we still might be concerned with this today
is it does still fit on technologies such as DMVPN.
Honestly, OSPF isn't really recommended on DMVPN anyway,
but if you're going to run it, point-to-multipoint
might be a good solution for you.
However, we probably don't want those default timers
of 30 and 120.
These timers were traditionally used
because these were supposed to be WAN network types,
and the WAN was traditionally slower,
so it was better to have slower timers on the slower links.
Now in case, it's not clear by the fact
that we're saying that the timers are set by network type
and such, that does mean that the timers are
going to be set per interface.
So I can absolutely have one interface
set one way, one interface set a different way
on the same router.
It's done all the time.
These default values that we mentioned here,
these really should rarely be used.
When I say rarely, I sort of mean never.
You really shouldn't use the default timers.
I just don't really like to use words like never because there
may be a situation somewhere where the default timers are
still something somebody wants to use.
There's nothing wrong with using them.
It's just, again, on today's networks,
having 40 seconds of downtime before we
detect the failure of a neighbor is almost never acceptable.
So we're probably hardly ever going
to use these default timers.
So now let's take a look at some of the other timers we
can adjust.
So the other timers we're going to look at have to do with how
the Shortest Path First algorithm is run,
as well as how quickly or how often we send link-state
advertisements or LSAs--
to our neighbors.
Now, these timers can be optimized either manually,
which means you simply go in and manually change
the timers using the commands in the IOS,
or on most of today's equipment, these
will be set automatically using a feature called
routing-default-optimize.
This is actually on by default, starting in IOS XE version
16.5.1b.
It's also on by default in IOS XR.
So we'll be taking a look at this at the command line.
Well, that's great, but what does this actually do for us?
Well, what it's going to do is it's
going to change the default values
for these different options.
So first, for timers throttle spf,
it's going to change the initial, the secondary,
and the max timers from their defaults of 5,000, 10,000,
and 10, to be 50, 200, and 5.
For timers throttle lsa all, once again, the same three
timers.
It has initial, secondary, and max.
These are going to change from 0, 5000, and 5, to 50, 200,
and 5.
You can see these are pretty much the same timers
that it uses for timers throttle spf.
In other words, it's going to run shortest path
first the same way it's sending updates.
As far as timers for lsa arrival,
these don't really have a category.
It's just it changes the default from 1,000 to 100.
Now, there's a lot of information
out there on how you can tweak these timers to get the best
possible performance out of OSPF,
but Cisco has done a lot of research,
and these new optimized values actually work really, really
well in most environments.
So in most environments, you're probably
not going to have to change these settings.
You just want to make sure that this feature is actually
enabled.
So now what we want to do is jump into the command line
and just take a look at how do we change the neighbor timers,
as well as we'll take a look at this feature,
we'll turn it on and off, and just see
how it changes the numbers.
So let's start by jumping over to our topology,
just take a look at where we're going
to change the neighbor timers, and then we'll
jump on to the command line.
So for a neighborships, we're just
going to focus on this neighborship
up here in area 200 between router 6 and router 10.
So we'll start with that.
And then again, we'll look at our routing default optimized
feature.
So let's jump into the command line.
So we're going to start here by observing
what happens by default between router 6
and router 10 when a failure occurs.
And to see what's going on, we're
just going to use a split window here so that we
can see router 6 and 10 at the same time
as we go through this demonstration.
So let's start by going to router 10
and shutting down its interface to router 6,
and see how long it takes router 6 to figure out what happened.
So simply go into configuration mode for interface gigabit
1, and we will simply do a shut.
Notice router 10 knows immediately because, of course,
it's a direct link failure.
So router 10, of course, knows immediately
that that neighborship is going to go down.
Notice, however, that router 6 still doesn't know.
Now, this is going to take 40 seconds,
so we're not going to sit here necessarily and wait
the whole 40 seconds, but I'll fast forward until router 6
sees that that neighborship is down.
So here we can see router 6 has now realized
that the neighborship is down, and that
did take right around 40 seconds or so.
So let's go ahead and bring this connection back up.
We see that both sides now realize the neighborship is up.
Now, let's adjust those Hello timers
and see the difference in performance.
So what we want to do is we want to say ip ospf,
and we're going to use a feature called the dead-interval, which
you can set this, of course, to be from 1 to 65535 seconds.
Or you can go with this special command, minimal.
If you do minimal, it will set it to one second
as it says there on the description.
However, it gives you this other option
to configure the Hello multiplier.
If we do the Hello multiplier, we can set this from 3 to 20.
Now, as we mentioned in our lecture,
it's really best to keep this at a 4-to-1 ratio.
So to get four Hellos in one second,
we would want to send, well, four of them.
And that means it's going to send every 250 milliseconds.
Now we, of course, need to set these timers exactly the same
on router 6.
On router 6, it's gigabit 2.
If we look at our OSPF interface,
we can see that our Hello interval is, in fact,
set to 250 milliseconds with a Dead timer of one second.
So now let's go ahead and shut down our interface again
on router 10 and see how long it takes
router 6 to figure it out.
Notice now, it was within one second, much,
much faster and better performance using the faster
timers.
So let me take this at a split window now.
So we just broke router 10 back over here.
So now let's take a look at those default
timers for OSPF and LSA.
If we just do a show IP OSPF, we can see here
that the timers are set to what they were on our table.
We can see here that it's set to 50, 200, 5,000, 500, 200,
and 5000.
If however, we were to turn off the routing-default-optimize
feature, which we can do here simply by saying
no routing-default-optimize and then do a show IP OSPF,
we can see that these timers are back to the 5,000,
10,000, 10,000, and so on.
So again, this is a good feature to probably just leave on.
We'll turn it back on.
Verify it again.
And we can see they're back to the fast timers.
But this feature can be enabled or disabled if you want.
In this video, we looked at how to optimize some of the OSPF
timers, specifically, we looked at the new default values
for the SPF and the LSA timers using our routing default
optimize feature.
And we looked at how to optimize the detection of a neighbor
failure by changing the Hello and Dead
intervals to their minimum values of one
second for the Dead, 250 milliseconds for the Hellos.
I hope this has been informative for you.
And I'd like to thank you for viewing.