Chapter 1 – Introduction
As protocols go, OSPF is intelligent. But sometimes, we know better than it does. Sometimes we know that traffic should behave a certain way, to use a certain path that we know is better.
So, in this lesson, we’ll see how we can influence OSPF’s routing decisions, as well as how to handle the default route.
Chapter 2 – OSPF Cost
OSPF is intelligent, and can manage multiple paths. It does this by collecting information about each link and storing it in the LSDB.
An important piece of information for any routing protocol is the metric. The term ‘metric’ refers to how we measure something. For example, miles and kilometers are metrics that measure distance.
OSPF uses cost as its metric. It determines that some links are better than others. Better links cost less to get a packet to its destination.
Each router will run the SPF algorithm to find the best paths through the network. OSPF considers the path with the lowest cost to be the best.
The best paths are then offered to the routing table.
This is a pretty good system. Unfortunately, there’s a problem in modern networks…
But before we get to that, we need to understand how OSPF calculates a link’s cost. And that is all about bandwidth.
Each link has a bandwidth. In this example, we have four links with bandwidths of 10Mbps, 100Mbps, 1Gbps, and 10Gbps. In OSPF terms, the higher the bandwidth, the better the link.
There is also a reference bandwidth. This is, by default, 100Mbps. There is also a reference bandwidth. This is, by default, 100Mbps. Back in the early days of OSPF, 100Mbps was a fast link.
To calculate the cost of a link, OSPF divides the reference bandwidth by the link bandwidth.
So the cost of a 10Mbps link would be 100 divided by 10, which is 10. The 100Mbps link would be 100 divided by 100, which is a cost of 1.
Here’s where it gets interesting… The 1Gbps link is 100 divided by 1000. This should be 0.1, but OSPF only uses whole numbers. So the cost of this turns out to be 1. The same thing happens on the 10Gbps link.
Can you see the problem? Modern networks have links much faster than 100Mbps. But the cost of them always comes out to 1.
Let’s go back to the original topology now. Before I didn’t show you the bandwidths of the links, only the costs. Let’s add the bandwidth now…
See how the path that OSPF selected is not the best path? The best path should use the 10Gig links. But because the cost of each link is 1, the best path has a total cost of 4. This is a higher cost than the worse path, which has a cost of 2.
We need to do something about this! The solution is changing the reference bandwidth. Let’s connect to a router and see how it’s done. This is not one of the routers from the topology diagram here.
Before we change anything, let’s check the current reference bandwidth. There’s no guarantee that it’s at the default settings. Someone else could have changed it.
To do that, we use show ip ospf. Here is where we see this value. And this confirms that it’s 100Mbps.
Any of Cisco’s routers and switches running IOS will use 100Mbps by default. Other vendors, and even some of Cisco’s data centre range of switches, have a different default value.
I’m now using show ip route ospf to see only the routes that OSPF has learned. Do you remember which value is the metric? It’s the second value in the square brackets.
So, the costs here are 2, 2, and 3. Keep that in mind, as we’ll see how they change later.
Now to change the reference bandwidth. We do this under the router ospf configuration hierarchy.
The command we use is auto-cost reference-bandwidth, followed by our value. The value is in megabit per second. I’ll enter 1-million, which is a terrabit. I’ve chosen a high value, as it’s much higher than any of our links.
As the router says, this value should be consistent across all routers.
We can confirm the change with show ip ospf. It has definitely been updated, which is good.
And looking at the routes again, we see much higher costs. So we know the change we’ve made has worked.
If we made this change to the routers in our topology, the costs would now look like this… Big difference right?
How might this scenario change things? There are two routers at different sites, connected by a 100Mbps WAN link. They connect to this link with their gigabit0/0 interfaces.
How will this affect OSPF? Based on the defaults, OSPF will assume that there is 1Gbps of bandwidth between the sites. It has no way of knowing what the service provider’s limit is.
So, it will base the cost on 1Gbps of bandwidth. This is inaccurate, and depending on the rest of the network, it may lead to poor routing decisions.
We can tune this by telling the router the real bandwidth of the link. Under the interface, we can enter bandwidth 100.
When we look at the interface again, we can see that the bandwidth has changed. Unfortunately, I set it to 100Kbps, not 100Mbps, but you get the picture I’m sure.
I want to be clear on one thing though. The bandwidth command only supplies the router with more information. It does not change the actual bandwidth of the link.
On occasion, the reference bandwidth and the bandwidth statement won’t meet our needs. In a case like this, we can set the cost on an interface manually.
We might see this if there’s a fault on a link, and we would prefer to use a more reliable path. Or maybe it’s a backup link, and we only want to use it if necessary.
In cases like those, we can set the OSPF cost on the interface to be really high. This would cause some other path to be preferred.
Under the interface, we can use the ip ospf cost command. In this case, I’m setting the cost to 5000.
You can put these new skills into practice here. Work out the cost on each link, and then the path R1 would take to each destination.
Chapter 3 – The Routing Table
Let’s go back to network advertisements for a bit. We need to lock in some key concepts.
We’re going to configure OSPF for the topology shown here. There are two routers, connected with two links. There is an extra network per router.
The first thing is to get OSPF running, and form an adjacency. We’ll start on R1, using process ID 10. We’ll also set a Router-ID as a matter of best practice.
Next, we’ll use the network command to enable OSPF on our interfaces. Notice that the wildcard mask covers both interfaces in one single command. We’re telling the router to enable OSPF on any network interface with an IP that starts with 172.16.1
Here’s the key point. The network command does two things:
It enables OSPF on network interfaces identified by the network and wildcard mask
It advertises any connected networks identified by the network and wildcard mask
In this case, this means that the router enables OSPF on the two interfaces that connect to R2. They will start sending hello messages.
It also means that 172.16.1.0 /30 and 172.16.1.4 /30 will be advertised. That’s because they’re the networks configured on the local router..
While we’re here, we’ll add our other network, 192.168.10.0 /24, to OSPF.
We’ll move over to R2, and repeat the process there. That’s starting OSPF, setting a Router-ID, and adding networks.
Sorry, I added the wrong network there. To remove that config, we enter the same command, with a ‘no’ in front. Then, I’ll add in the right command. That looks better. The adjacency has come up.
We have another network to add of course…
And to confirm, we can look at the OSPF neighbour list. Here, we have one neighbour, but two neighbour relationships. We know it’s the same router because of the Router-ID.
Let’s see these in the routing table. Here’s the route learned from R1. Notice that there’s two next hops? That’s because of the two links, each with the same cost.
That’s Equal Cost Multipath, ECMP, in action. Cisco routers will allow up to four equal-cost paths in the routing table by default. If the links have different costs, then only the best one is selected.
In a case like this, both links share the load.
We can compare that to the entries in the LSDB. Notice that there’s an entry for each of the two routers. There’s also entries for each of the two links.
The other networks, 192.168.10 and 192.168.20 are not listed here. The LSDB doesn’t include these, as they are not paths through to other networks.
With that in mind, here’s an interesting point… When we use the network command, we do two things:
Enable OSPF on an interface, which includes sending and receiving hello messages
Advertise the network on that interface to other routers
What if we want to advertise a network, but we don’t want an interface to send hellos? In our example, we want to advertise 192.168.20.0. But we don’t want that interface trying to form an adjacency with another router.
We can configure this interface as a passive interface. This prevents OSPF sending hello messages on that interface, but still advertises it.
Let’s see what would happen if we configured gig0/0 as a passive interface. That’s the link with the 172.16.1.0 network.
Under the router ospf config, we use the passive-interface command. Straight away we see the neighbour relationship over that link drop. That’s because it’s no longer active, so there can’t be an adjacency there.
It’s easy to confirm this by looking at the list of neighbours. Before we had two adjacencies, but now there is only one.
If we go over to the routing table, the route to 192.168.10.0 has only one next hop.
That leads to an obvious question. When would we want to use passive interfaces? Wouldn’t it be better to have all possible interfaces working in OSPF?
I’ll leave you to think about that one.
Chapter 4 – Default Route
When it comes to advertising networks in any routing protocol, there is one key rule. For a router to advertise a network, it must first be in the routing table.
Why is that a rule? Because when a router advertises a network, it’s saying I know how to get to this location.
There are two ways a router will know about a network. If it’s connected to the router, or if it learns about it from another source. For example, a static route.
In both cases, that network will be in the routing table.
The default route though, is a little special. It is 0.0.0.0 /0. We will never have an interface with an IP like this.
So how can we advertise the default route to another router? First, remember our rule. It needs to be in the routing table. There is a small exception to this, we’ll take a look at that later.
In this topology, the simplest option is to add a static route to R1. As we’ve seen in other videos, this uses the ip route command. For the next-hop, we’ll use 192.168.10.2. This would usually be an IP address that your internet provider would give you.
When we look at the routing table, we now have a default route. Its type is static. That’s step 1 done.
If we look over at R2, we see that this has not made a difference yet. There’s no default route. Even though R1 and R2 are OSPF neighbours, R1 does not automatically share the default route.
We’ve got to tell OSPF to share the default route. We do this under the router ospf configuration area.
Then we want to use a magical command, default-information originate. This command redistributes the default route into OSPF, allowing it to advertise it.
Redistribution is taking a route from one location, and placing it in a routing protocol. In this case we have a static route, and we’re redistributing it into OSPF.
Redistribution is a much bigger topic that you’ll see if you go on to the CCNP exams. For now, this is just a small introduction.
If we take a look at the routing table on R2 again, we can see the default route.
The protocol code next to it is interesting. It says ‘O’ ‘Star’ ‘E2’.
The ‘O’ means that OSPF learned this route
The ‘star’ means it’s a default route
The ‘E2’ means that this route was redistributed into OSPF from an external source; That is, a static route
So whenever you see E1 or E2 on a route, you know it was redistributed into OSPF.
So we know the rule is that networks must be in the routing table to advertise them. Although, I did say there was an exception.
Take a look at quiz question 5, put in a bit of research, and see if you can work out how it’s done.
For today’s lab, you’re going to optimize OSPF. All the routers are working, but they could be better.
You can take the skills you’ve gained over the last few videos, and work through it. I know you can do it!
We’ve covered OSPF pretty well now. In the next video, we’re going to get started with Quality of Service. This is where we can prioritize different traffic types.
Hope to see you there!