OSPF is one of those protocols that has been around
for a very long time, and basically every vendor supports it.
So it's not surprising that Cisco really want you to know this for the CCNA exam.
So for that reason, we're now going to take a look into detail
in how OSPF works and how we can configure it.
All business grade Cisco routers can use OSPF,
but it's not turned on by default. To turn OSPF on,
we need to enable the OSPF process.
Let me show you how it's done on a router.
The command we use is 'router
ospf', followed by process number.
As soon as we entered this command, OSPF is running.
We use the 'router' command for all dynamic routing protocols.
You could use it with EIGRP or BGP to start those processes.
10 is the process ID that we've chosen.
This can be any number from one to 65,535. At the CCNA level,
it doesn't matter what number you choose.
The reason we have a process, number, is to support
advanced configurations. In some cases,
we need to run more than one OSPF process,
but one process is plenty for us, so we'll stick with that.
You probably don't know this yet, but there are two versions of OSPF
we can use. Version 2 and version 3. Version
2 is still the most common, but it only supports IPv4.
If you want to use IPv6, which we'll do much later
in different video, you need OSPFv3.
If we want to stop the OSPF process, we have two options.
one is to remove the OSPF configuration.
The other is to enter the 'shutdown' command.
This is more gentle as it keeps all our configuration in place
and allows us to turn it on again with 'no shutdown'.
As a dynamic routing protocol,
OSPF discovers other routers that also run OSPF.
The only catch is they all have to be adjacent.
This means they need to connect to each other
directly from a layer three perspective.
In the topology here, R1 connects to R2, these routers are adjacent
so they can become neighbors of each other.
It's the same as R2 and R3.
R1 and R3 are not adjacent, as they are not connected to each other.
R1 and R3 do not become neighbors.
They don't immediately become neighbors, though,
we need to add some more configuration first.
We're going to add the command 'network 172.16.0.0'
.
and then '0.0.0.3 area zero'
Right away,
we get a message, which means that R1 and R2 are now neighbors.
This means that R2 has already been configured with the same commands.
So let's break this command down.
Every routing protocol uses the network command.
It tells the routing protocol which interfaces
we're willing to see neighbors on.
If you want to check out the lab later,
we'll see an alternative to this network command.
172.16.0.0
is the network address of the interface on our router.
That part's easy.
Now, '0.0.0.3'
That's a new one.
This is called a wildcard mask.
It's a bit like a reverse subnet mask.
I'll get back to explaining how that works soon.
Area zero is something specific to OSPF.
OSPF
likes to arrange routers and links into areas all over
All OSPF topologies must have at least one area which must be area zero.
In short, though, what this command is saying is
I want to look for other OSPF neighbors on this interface.
So it's clear that I'm going to need to explain a few more things.
Let's start with areas.
OSPF is very good at organizing the network.
It uses areas to group links and routers.
This makes it possible to tune how OSPF works according to your needs.
The good news for you is that the CCNA exam doesn't test you in multiple areas,
so you don't need to worry about this in much detail right now.
What you do need to know
is that all OSPF topologies must have at least one area.
This is area zero, and this is called the backbone of the network.
If we do have other areas, they must connect to Area zero somehow.
But it is quite acceptable to have only one area, area zero in the entire network.
Other areas are entirely optional.
The command we used earlier
meets these requirements by using Area zero.
The next interesting thing is the wildcard mask.
So what is it?
It's like a subnet mask in many ways.
It's a 32 bit number, which we can show in binary or decimal,
and it goes along with an IP address.
Also, like a subnet mask,
it shows parts of an IP address that we're interested in.
When we look at it in binary,
the zeros represent the parts of the addresses that we're interested in.
The ones, are the bits that we don't care about.
When we use the mask to compare the network address
and the IP address, we can see that we only care about the first 30 bits only
and we don't care at all about the last two bits.
The router knows that we want
OSPF to use any interface with an IP
that matches the bits that we care about .
And in this case, they do match.
And that seems complicated, right?
Well, for a simple example like this.
Well, it really is.
But wildcard masks let us do all sorts of fancy matching if we want to.
You don't need to get too complicated for the CCNA exam, though.
If you want to see a fancier example, check out the lab at the end of the video,
we'll use one wildcard mask and network command
to match a few interfaces at once.
Time now to go back to OSPF neighbors.
By entering the network command, we told the router to enable OSPF
on any interface that matches the network and wildcard mask
and put them into area zero.
There was
one interface that matched this criteria on router R1.
This caused two things to happen.
The router started sending hello messages,
often using multicast on interface gig0/0.
It also starts processing any
hello messages that it receives rather than ignoring them.
These hello messages
enable the two routers to find each other and become neighbors.
The second thing the network command does
is to advertise this interfaces network.
This enables other OSPF routers to learn about this network
and how to get there.
To verify that this has indeed happened, there are a few commands we can use.
first, let's try 'show ip ospf',
which gives us general OSPF settings.
We can see things like the process, number, as well as they router's ID.
And the areas that the router is
in, we'll come back to the router's ID soon.
We can use 'show ip ospf interface'
to list all the OSPF enabled interfaces and whether they're up.
This also shows us the process ID that the interface is part of.
And finally, 'show ip ospf neighbor'.
Remember to use the American spelling,
which is something I often forget to do.
This shows our OSPF neighbors, the interfaces there on, their address,
and their ID.
This is the command I use most with OSPF.
Let's come back to the router ID.
Each router needs a unique way to identify itself to other routers.
That's what the router ID does.
So each OSPF router has a router ID and the router ID has to be unique.
You'll also notice that it looks like an IP address.
It's only a 32 bit number, but it's formatted like an IP to make things
easier.
There are three ways a router ID could be set.
The first is if we set it ourselves, we'll see that soon.
If we haven't set it, the router will select the highest
IP address on a loopback interface
by highest, I mean, the largest number.
If we haven't set it and there's no loopback
then, the round of selects the highest IP of any active interface.
To see the router ID, we use the command
'show ip ospf'.
The ID is here on the first line, in this case,
the router chose the ID based on the highest IP of an active interface.
To set this
will first configure the OSPF process.
Remember to use the right process ID.
If we use a different number here,
we'll start a new and unique OSPF process.
Now we can use the router ID Command to set the ID to whatever we want,
it needs to be something that makes sense to us and is in IP address format.
As shown in this message, this change doesn't apply right away.
We need to restart the OSPF process first, and to do that,
we use the 'clear ip ospf process' command.
Be careful when you run this command.
This causes the neighbors to drop and their adjacencies to form.
This is fine in the lab, but on a real network, this is disruptive.
If we look at the router ID again, we can confirm it has changed.
There's one
last thing I want to say about forming adjacencies,
router use hello messages to share information about themselves.
There are a few details in these messages that must match
before neighbors will form.
These include being in the same area,
having the same authentication details or no authentication.
They connected interfaces must match,
meaning the same network and subnet mask.
Timers.
That is how often hello messages are sent, as well as the dead interval
will cover that a bit later on.
The MTU of the connected interfaces,
this one has caught me out a few times in the real world.
I've got a couple of questions here
that you might find a bit tricky with a bit of thought, though.
I'm sure you can do it.
Now we'll look at
how neighbors fail when neighbors fail or a link to them
does, this changes how traffic flows through the network
We can broadly consider three possibilities.
When the OSPF process is shut down or fails,
when the interface the neighbor is on goes down.
This could be deliberate or accidental.
And when hello messages go missing.
Usually when the OSPF process shuts down, it's deliberate.
We want to shut it down for some reason.
We can do this with the shut down command under OSPF configuration.
We may need to do this in a case where we want to do maintenance
on the router and don't want it advertising routes for a while.
Although rare, it's also possible
that the OSPF process could crash if this happens.
You should really log a ticket with Cisco to find out what went wrong.
And, of course,
rebooting the router will also cause the OSPF process to stop.
Interface is going down is a different story.
This could happen when we shut down an interface or when a link fails.
Imagine a case like this one where a router connects
directly to another, and an OSPF adjacency is up.
Now, imagine that this link were to fail for some reason.
Maybe someone's cut the cable or disconnected it from either router.
What would the result be?
It's an easy question to answer, isn't it?
The interfaces on both routers would go down,
both routers would immediately know that this neighbor is gone.
This results in the loss of the neighbor adjacency.
OSPF would need to reconverge
and find alternate paths through the network if they exist.
What if the two routers aren't directly connected?
Consider this example these two routers are neighbors,
but they connect through a switch.
What happens in this case, if a link were to fail?
The top router would detect this failure immediately as its interface will go down.
It will respond by tearing down its neighbor relationship.
The bottom router, though, will behave differently.
It won't immediately detect that link has failed
as the link between itself and the switch is still up.
It would be the same if the top of died or rebooted
the bottom router wouldn't immediately know that something is wrong.
This could present a problem.
If a router thinks it's a valid path when there isn't
it could forward traffic off to its doom.
So this
router needs to learn the change in the network so it can adapt.
You may have guessed the solution here.
Remember how neighbors continually send each other hello messages?
The main point of hellos, as we already know, is to form adjacencies
with neighboring routers, but they have another purpose.
These continual hello messages show that a neighbor router is up
if the Hello messages go missing for too long.
one router will know that the other router is unreachable.
It will then adapt as needed.
By default, router's send hello messages
every 10 or 30 seconds, depending on the network type.
I'll explain that with types in the next video.
This is known as the hello interval or hello timer.
OSPF routers also have a dead timer
the default dead timer is four times the hello interval.
So that means that the dead timer is 40
or 120 seconds, depending on the network type.
If router does not see a hello message from its neighbor
for the duration of the dead timer, it will assume the neighbor is down.
So in the example shown here, the bottom router
would expect to see hello messages every ten seconds.
When it hasn't seen any hello messages in 40 seconds,
it decides at the neighboring router is down.
It is then able to adapt and find other paths through the network,
assuming other paths exist, of course.
Can you see any problems with this?
The problem is that routers are slow to detect some failures. In our example,
It takes 40 seconds for the router to even know that something is wrong,
let alone adapt to it.
That's not great in a modern network.
Can you imagine if users are on teams or Zoom meetings and a link fails?
It could be a full minute before they recover.
Meanwhile, they're all wondering what's going on
if the routers could recover quicker, the users would only notice
a small blip in their meetings that they think, Oh, that's odd.
And then they move on with their day.
Remember that OSPF is quite old,
Zoom and teams didn't exist back then.
That doesn't mean that we can't improve things, though.
In fact, the way to improve this is to tune the timers.
Let's try this out now.
We do this using OSPF configuration under each interface.
That means we can have different timers as per interface if we want to.
Let's change the
hello interval to one second with the
'ip ospf hello-interval' command.
The same principle is true for the dead interval.
We'll say that to four seconds with the 'ip ospf dead-interval'
command.
I've sped the video off a bit here,
but as you can see, this causes the neighbor adjacency to fail.
Let's make the same changes on the neighboring router.
The configuration is identical to before.
The neighbor relationship
also comes back as a result.
And that's one way of improving OSPFs performance.
You can use this principle with other routing protocols too.
There are often pros and cons when we tune our network.
It's good to try to find the right balance and set the right values.
And finally, we have the lab.
Part one is configuring the topology as shown
this includes configuring a loop back, which provides the router ID
configuring peering between all routers.
Advertising the three connected networks and the loopback IP.
And finally verifying that it's all working.
To make it more fun on R1 and R2,
you should use the network command with a wildcard mask.
On R3 and R4,
you should configure peering per interface.
You can decide which of these two methods you like best.
For part two, as usual, it's the same topology,
but the network is broken, neighbors aren't forming as they should be,
find the faults in the network and resolve them.
So that's how OSPF Neighbors form adjacencies.
The next video looks at some more of OSPFs complexities.
This includes network types, neighbor states and the OSPF database.
I hope to see you there.