Chapter 1 – Introduction
OSPF is one of those protocols that has been around for a long time, and all vendors use it. So it makes sense that this is the protocol Cisco want you to focus on in the CCNA exam.
In this lesson, and the following two, we’re going to see how OSPF works, and how it’s configured.
Chapter 2 – Finding Neighbours
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 that’s done on a router.
The command we use is router ospf, followed by a process number. As soon as we enter 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 1 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 only supports IPv4. If you want to use IPv6, which we’ll do in a later 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 have to be adjacent. This means they need to connect to each other directly, from a layer-3 perspective.
In the topology here, R1 connects to R2. These routers are adjacent, so they can become neighbours of each other. It’s the same as R2 and R3.
R1 and R3 are not adjacent, as they’re not connected to each other. R1 and R3 do not become neighbours.
They don’t immediately become neighbours though. We need to add some more configuration first.
We’re going to add the command network 172.16.0.0 0.0.0.3 area 0.
Right away we get a message, which means that R1 and R2 are now neighbours. This means that R2 already had that command configured.
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 neighbours on. If you want to check out the lab later, we’ll see an alternative to the 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 a wildcard mask. It’s a bit like a reverse subnet mask. I’ll explain how that works soon.
Area 0 is specific to OSPF. OSPF likes to arrange routers and links into areas. All OSPF topologies must have at least one area, which must be area 0.
In short though, this command says “I want to look for other OSPF neighbours on this interface…”
So, it’s clear that I need to explain a few 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 on multiple areas. So you don’t need to worry about this in detail right now.
What you do need to know is that all OSPF topologies must have at least one area. This is area 0, and it is the backbone of the network.
If we do add other areas, they must connect to area 0 somehow. But it’s quite acceptable to have only area 0 in the entire network. Other areas are optional.
The command we used earlier meets these requirements by using area 0.
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. It also 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 address 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 care about the first 30 bits only. 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 we care about. And in this case, they do match!
This seems complicated right? Well, for a simple example like this it is. But wildcard masks let us do all sorts of fancy matching if we want to. You don’t need to get 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 to go back to OSPF neighbours. By entering the network command, we told the router to enable OSPF on any interface that matches the network and wildcard mask, and to put them into area 0.
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 it receives, rather than ignoring them. These hello messages enable the two routers to find each other, and become neighbours.
The second thing the network command does is to advertise this interface’s 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 the 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 interface is part of.
And finally, show ip ospf neighbor. Remember to use the American spelling, which something I often forget to do. This shows our OSPF neighbours, the interfaces they’re on, their address, and their ID.
This is the command I used the 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 router 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 on an active interface.
To set this, we 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. To do that, we use the clear ip ospf process command.
Be careful when you run this command. This causes the neighbours to drop, and their adjacencies to reform. 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. Routers use hello messages to share information about themselves.
- There are a few details in these messages that must match before neighbours will form. These include:
- Being in the same area
- Having the same authentication details (or no authentication)
The 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; We’ll cover that later on
The MTU of the connected interfaces – This one has caught me out a few times in the real world
We’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!
Chapter 3 – Losing Neighbours
Now we’ll look at how neighbours fail. When neighbours 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 neighbour 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 it shut down for some reason. We can do this with the shutdown command, under OSPF configuration.
We may do this in a case where we want to do maintenance on a router, and don’t want it advertising routing for a while.
Although rare, it’s also possible that the OSPF process could crash. If this happens, you need to 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.
Interfaces going down is a different story. This could happen when we shut an interface down, or when a link fails.
Imagine a case like this one, where one router connects directly to another, and an OSPF adjacency is up.
Now imagine that this link were to fail for some reason. Maybe someone has 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 neighbour is gone. This results in the loss of the neighbour 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 neighbours, 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 goes down. It will respond by tearing down its neighbour relationship.
The bottom router though, will behave differently. It won’t immediately detect that the link has failed, as the link between itself and the switch is still up. It would be the same if the top router died or rebooted. The bottom router wouldn’t immediately know that something is wrong.
This could present a problem. If a router thinks there’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 neighbours continually send each other hello messages? This has three purposes.
One, as we already know, is to form adjacencies with neighbouring routers. The second is to update neighbours with changes in the network.
The third is of interest here. These continual hello messages show that a neighbour 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, routers send hello messages every 10 or 30 seconds, depending on the network type. I’ll explain network 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 default dead timer is 40 or 120 seconds, depending on the network type.
If a router does not see a hello message from its neighbour, for the duration of the dead timer, it will assume the neighbour is down.
So in the example shown here, the bottom router would expect to see hello messages every 10 seconds. When it hasn’t seen any hello messages in 40 seconds, it decides that the neighbouring router is down. It is then able to adapt, and find other paths through the network. Assuming they 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 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. They’d think “oh, that’s odd” and then move on with their day.
Remember that OSPF is quite old. Zoom and Teams didn’t exist back then. That doesn’t mean 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 per interface if we want to.
Let’s change the hello interval to 1 second with the ip ospf hello-interval command. The same principle is true for the dead-interval. We’ll set that to 4 seconds with the ip ospf dead-interval command.
I’ve sped up the video a bit here, but as you can see, this causes the neighbour adjacency to fail.
Let’s make the same changes on the neighbouring router. The configuration is identical to before.
The neighbour 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 1 is configuring the topology as shown. This includes:
Configuring a loopback, which provides the router ID
Configuring peering between all routers
Advertising the three connected networks and the loopback IP
Verify 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 decide which you like best!
For part 2, as usual, it’s the same topology, but the network is broken. Neighbours aren’t forming as they should be.
Find the faults in the network, and resolve them.
So, that’s how OSPF neighbours form adjacencies! The next video looks at some more of OSPFs complexities. This includes network types, neighbour states, and the OSPF database.
Hope to see you there!