OSPF Costs

We've mentioned a few times that OSPF uses the metric of cost to calculate what is the best route. But how does it calculate cost, and what does that look like? And even more importantly, there's something we have to do within our network for it to calculate cost accurately.

Cost and the SPF tree

This right here is an example of a network that we have set up, and this is an example of the SPF tree, the shortest path first tree, that is generated from Dijkstra's algorithm. When we are looking at this, let's say that all of these links are equal — let's say that they're all one gig connections. So I'm going to say one gig across all of these right here.

Then what happens is, when this gets generated with one on all of these connections, you just add them up. So from R1 to R2 that's 1, 2, 3, 4, so there's a total cost of four to go this direction. One, two, three, four to go this direction. There's one, two, three to go this direction and one, two, three to go that direction. Now we see the two paths that are going to be the shortest path to this final destination right here hanging off of R6, and that is from R1. So that's how this is calculated, and that's pretty simplistic when we look at it from that perspective.

But let's say some of these are not the same as others. For instance, let's say these are 10 gig links across here. Now what happens is, if we were to add that to our list right here — 10 gig between R1 and R2, between R2 and R3 is a 10 gig, between R3 and R4, and R4 and R6 — so now if we were to add this up, 10 plus 10 plus 10 plus 10 would be 40. So now we have a different calculation, and this ends up being a bigger number, which is actually a faster route now because of the higher bandwidth between these. It's a faster route to this end network right here. So somehow we need to actually do something with these numbers to make them more accurate.

The cost equation

There's a little bit of an equation that goes into this. Really what our goal is is that as the bandwidth goes up, the cost actually decreases, so that way we can add up all these costs and find out what is the best route. So we want an inverse action to happen here.

What we have to do for an inverse action is have some sort of equation. If we are going to calculate the cost of a link, what we do is we take a reference bandwidth and then we divide that by the interface bandwidth. That way, when the interface bandwidth goes up, the cost actually goes down.

Here are some examples of that. This is a 10 megabit per second connection, this is a hundred, this is a gigabit per second, and this is a 10 gig connection right here. If we're dividing that all by 100,000, then we'd get 10, 1, 0.1 and 0.01. So our 10 gig connection is the lowest cost, so that's exactly what we want.

There is still a problem with this, though. Your router does not see this as a .1 or a .01. It doesn't do fractions like this, and so what it actually does is it translates that, and now it becomes a one. That is problematic, because now our 100 meg, our gig and our 10 gig connections are all one. That is because this is an outdated reference bandwidth. The reference bandwidth was from when we had much slower speeds and we didn't have these fast ethernet connection speeds.

Correcting the calculation

There's only one that I would really recommend. I'm going to go over two of them, and then the one that I recommend.

The first method that we can use to fix this is that I can actually change the bandwidth that OSPF uses to calculate the cost of each of these links. So what I could do is I could go on here and set anything that is 10 gigabit per connection to be a hundred megabit per connection, and anything that is a hundred megabit connection I could set to be a one megabit per connection. When I'm setting the bandwidth on here, it just is used for the calculation of OSPF, so it's not actually affecting the bandwidth — I'm not metering down how much bandwidth those connections have. The problem I have with this is it's a lot of figuring out, and I have to make sure it's done on every interface. It's just kind of sticky to me. I don't know that it's really a great route to go.

The other thing that I can do is I can manually set the cost, rather than having it calculated. I can go to each one of these interfaces and I can set this to be a cost of, let's say, 10, and I can set this to be a cost of a thousand, and then this right here could be a cost of 10 right there. So I can go on to these interfaces and then manually set them up with a cost that's used for OSPF. Here again, it's still a lot of making sure I get this all correct and making sure I get all the interfaces, and I wouldn't want to monkey around with that.

What I would do in this scenario right here is change the reference bandwidth. The reference bandwidth is something that we can actually affect, and that's going to change our calculation. So how do we fix this? We just come up with a higher reference bandwidth. Once we have a higher reference bandwidth, a 10 meg connection comes out to be 10,000, a 100 meg connection turns out to be a thousand, a gigabit connection is a hundred, and a 10 gig is a 10. So that's what we're going to do: we want to change this reference bandwidth.

Loopback interfaces

Just a quick mention about loopback interfaces. On each of our layer 3 devices we put a loopback interface. That loopback interface is just an interface that we can ping, and at some point in time we're going to want it to show up in our routing tables and be able to ping those devices. The cost of a loopback interface is going to be one by default.

An example

Here's just a quick example. What we're going to do is say that these links right here are at 100 meg connections and these links right here are at a 10 gigabit connection. So this is gig connections and this is megabits per second connections, and we're trying to reach from this network over to this network. The reference bandwidth right here is set to default. Figure out what the SPF, or shortest path first, tree is going to look like, and then we'll run through it a second time with changing the reference bandwidth.

So what we'd say is that all of these have a cost of one. We would plug that into our shortest path first tree right here, and it's a cost of two in each of those directions. What would actually happen with this is then we would have equal cost load balancing that would happen right here. It would send it down both routes. It would load balance between those two different routes.

Now let's change the reference bandwidth. Let's multiply it by a thousand. So this would be a 10, then right here this would be a hundred, and this would be a thousand would be the cost of each of these. So this up here would be a thousand, and down here would be 10 and 10. So this direction is 10 and this direction would be a thousand. The end result would be 2,000 over here versus 20 over here. Big difference in bandwidth — we can see how drastic the difference is with that. It's going to choose this as the shortest path. This is what's going to get installed into the routing table and send it on its way.

We talked about OSPF cost and how it calculates the cost on each of those interfaces and puts it into the SPF tree to figure out what is the fastest way. We also talked about how it's using old numbers, and because it's using an old reference bandwidth, it causes a problem with calculating some of these interfaces wrong. So we talked about a few different corrections, and the one that I recommend is changing that reference bandwidth so it can calculate the right speeds and the right costs for each of those links. And we talked about how loopback is just a cost of one when on the router.