|
0:00:13
|
Our next topic here is the convergence timers for OSPF,
|
|
0:00:17
|
where are mainly gonna be based on how long does it take us to detect that the neighbor is down.
|
|
0:00:23
|
Then, once we can declare the neighbor down,
|
|
0:00:26
|
how long does it take us to flood new LSA updates,
|
|
0:00:30
|
and then do the actual SPF run.
|
|
0:00:33
|
Now, typically, the flooding of the updates and the SPF run,
|
|
0:00:36
|
there's only so much you can do to tweak these values.
|
|
0:00:41
|
If you look at the command reference, you could see there's a lot of individual timers that you can change,
|
|
0:00:46
|
like how long do I wait after I received the update before I run SPF,
|
|
0:00:50
|
how long between runs of SPF that I need to wait,
|
|
0:00:55
|
but generally, you can leave those alone
|
|
0:00:57
|
and work on just figuring out how long is it gonna take me to detect the neighbor down.
|
|
0:01:04
|
Now, just like in EIGRP or in RIP,
|
|
0:01:08
|
the problem that we could run into
|
|
0:01:10
|
is that if the Layer 2 link status to the neighbors
|
|
0:01:14
|
is not a good indication of the connectivity.
|
|
0:01:18
|
Then, we're gonna have to rely on our Layer 3 timers in order to figure out they are down.
|
|
0:01:25
|
So, if we look at our topology here,
|
|
0:01:27
|
let's say between router 1 and router 6.
|
|
0:01:31
|
So, I wanna figure out as quickly as possible
|
|
0:01:34
|
if router 6's interface goes down, we want router 1 to be able to know about this.
|
|
0:01:41
|
The problem though is that there's no direct relationship
|
|
0:01:46
|
between the line protocol status of router 6, and the line protocol status of router 1.
|
|
0:01:52
|
The reason why specifically is that there's another Layer 2 switch in the middle.
|
|
0:01:57
|
So, ideally, in a real world design,
|
|
0:02:00
|
before changing the OSPF timers,
|
|
0:02:03
|
we could want to implement some sort of mechanism
|
|
0:02:07
|
that can keep track of the Layer 2 status on the link end-to-end between the neighbors.
|
|
0:02:13
|
Now, we saw that over frame-relay, we could run the frame-relay end-to-end keepalives
|
|
0:02:19
|
on true point-to-point links like a PPP link or an HTLC link.
|
|
0:02:23
|
There's always gonna be an underlying keepalive that tells you if the link is up or down.
|
|
0:02:28
|
But in the case of Ethernet, since we're going over the Layer 2 switches,
|
|
0:02:32
|
then, this is gonna be a little bit more problematic.
|
|
0:02:36
|
Typically, the way that this is done in real designs today
|
|
0:02:40
|
is with the feature that is known as "Bi-directional Forwarding Detection", or BFD.
|
|
0:02:46
|
If we look under the Configuration Guide,
|
|
0:02:48
|
under IP Routing, we have the BFD Configuration Guide.
|
|
0:02:52
|
The feature us actually really simple, you just basically turn it on.
|
|
0:02:57
|
The problem is that a lot of these lower level platforms, they're not gonna support it.
|
|
0:03:02
|
So, if you're running on 7600 or greater,
|
|
0:03:04
|
then, they're all gonna support it.
|
|
0:03:07
|
But on the like the ISRs, and some of the older platforms, they're not gonna run this.
|
|
0:03:13
|
So, if we look at their example, like configuring BFD support for OSPF,
|
|
0:03:18
|
you simply go to the interface level,
|
|
0:03:21
|
and then saying, "If OSPF is on,
|
|
0:03:24
|
then, I will also run Bi-directional Forwarding Detection.
|
|
0:03:28
|
But if we look towards the end of the document, let's see if it shows the versions,
|
|
0:03:32
|
it says, "OSPF support for BFD over IPv4 is in 12OS.
|
|
0:03:41
|
And 12.2(33)SRA, these two are the service provider trains.
|
|
0:03:47
|
So, this would be on like the 7200s or the 7600s.
|
|
0:03:51
|
12.2(18)SXE that's gonna be a Catalyst version, so that would be like for the 6500s.
|
|
0:03:57
|
In our case, the enterprise platforms, this would be 12.4(4)T.
|
|
0:04:01
|
So, it's actually possible that these ones will support it.
|
|
0:04:05
|
So, let's look at router 1,
|
|
0:04:09
|
and let's say on the link level,
|
|
0:04:14
|
IP BFD...
|
|
0:04:19
|
No, I don't think it's gonna support it.
|
|
0:04:21
|
IP OSPF...
|
|
0:04:28
|
And let's see their example.
|
|
0:04:37
|
BFD interval. Let's see if it just has the BFD command.
|
|
0:04:42
|
Okay, this version doesn't support it.
|
|
0:04:43
|
But if it did, this will be the ideal solution,
|
|
0:04:47
|
because what we would be doing is basically doing an additional keepalive directly between router 1 and router 6.
|
|
0:04:53
|
Then, if the BFD timer goes down,
|
|
0:04:58
|
the Layer 2 link status is gonna report to the upper layer protocols
|
|
0:05:02
|
that you immediately need to start re-converging.
|
|
0:05:06
|
Because when we look at the OSPF timers and look at the default values,
|
|
0:05:10
|
if we Show IP OSPF Interface Fast Ethernet 0/0,
|
|
0:05:14
|
it says that by default, it's gonna take us 40 seconds to figure out that the neighbor is down.
|
|
0:05:19
|
So, on a high availability environment, this is definitely not acceptable, 40 seconds.
|
|
0:05:24
|
But the problem is, if we were to take OSPF and run it as sub-second hellos,
|
|
0:05:30
|
it's very, very processor intensive for the control plane to do that.
|
|
0:05:36
|
So, BFD is a better design choice for this,
|
|
0:05:40
|
because it's a very lightweight keepalive.
|
|
0:05:42
|
As opposed to the hello interval of the Layer 3 protocols,
|
|
0:05:47
|
it takes much more processing power to do that.
|
|
0:05:51
|
Now, we technically could do that keepalive, if we were to go to router 1's interface,
|
|
0:05:56
|
and say that we have the IP OSPF hello interval.
|
|
0:06:01
|
We could set it as low as 1 second with the Hello Interval command.
|
|
0:06:07
|
Or we could say, the IP OSPF dead interval is minimal.
|
|
0:06:11
|
So, this is 1 second.
|
|
0:06:13
|
And the hello multiplier is how often we are sending hellos inside the second.
|
|
0:06:20
|
So, it I were to say, the hello multiplier was 5,
|
|
0:06:24
|
it would mean that I'm 5 hellos per second,
|
|
0:06:27
|
or every 200 milliseconds.
|
|
0:06:31
|
Now, once I do this, we should see that router 6 is declared down.
|
|
0:06:38
|
Because we're no longer receiving the keepalives from them. So, if we Show IP OSPF Neighbors,
|
|
0:06:44
|
It says, "Right now, the dead time is still the high value."
|
|
0:06:47
|
Probably what I'm gonna need to do is reset the process.
|
|
0:06:50
|
So, let's do this on both sides.
|
|
0:06:55
|
We'll say, IP OSPF Dead Interval is minimal
|
|
0:06:59
|
with the hello multiplier of 5.
|
|
0:07:02
|
Then, we'll clear the process. So, on router 6's side, it did automatically shut it down.
|
|
0:07:07
|
So, if we Show IP OSPF Neighbors,
|
|
0:07:11
|
and we look at the dead time, we should see that it's gonna be...
|
|
0:07:19
|
never less than like 800 milliseconds or so.
|
|
0:07:22
|
Because router 1 should be sending the updates every 200 milliseconds.
|
|
0:07:27
|
But if now look at the Show Processor CPU,
|
|
0:07:34
|
and it depends on what the platform is here. Let's say Show Proc CPU History.
|
|
0:07:41
|
So, on router 6, this is not that bad. But on router 1,
|
|
0:07:45
|
if we Show Proc CPU History,
|
|
0:07:51
|
we may see that the control plane starts to take up too many CPU cycles.
|
|
0:07:56
|
Also, you have the potential case where if your Layer 3 keepalive is lost,
|
|
0:08:02
|
then, you end up in this case where you're flapping between interfaces,
|
|
0:08:06
|
and the router never converges because it cannot support that high of a...
|
|
0:08:10
|
or that low of a keepalive interval.
|
|
0:08:17
|
So, beyond doing the Layer 2 detection,
|
|
0:08:21
|
which would be if we had a point-to-point link between the neighbors,
|
|
0:08:24
|
or if we were running something like Bi-directional Forwarding Detection,
|
|
0:08:27
|
then, you're next best option is gonna be to change the hello timer.
|
|
0:08:31
|
Now again, when you change the hello interval, it will automatically update the dead timer to 4 times that value.
|
|
0:08:38
|
So, if we have a question in the exam that said something like...
|
|
0:08:41
|
"Change the dead interval to 4 seconds,
|
|
0:08:43
|
but don't use the IP OSPF Dead Interval command",
|
|
0:08:47
|
it means that if we change the hello interval to 1, then it's gonna automatically update the dead interval accordingly.
|
|
0:08:52
|
In any case, when we look at the Show IP OSPF Interface,
|
|
0:08:55
|
that's gonna give us a verification of what the timers are configured on that link.
|
|
0:09:01
|
And again, this value is negotiated during the adjacency.
|
|
0:09:04
|
So, the devices on the link do need to agree on what the timers are gonna be.
|
