Manipulating OSPF Path Selection With Cost

My good friend JJ asked me a question the other day about OSPF path selection. It was something like “I have a redundant network and I want to adjust cost on an individual route…how do I do that?” Seems pretty straight forward, right?…not exactly.

Cost is the metric OSPF uses to judge a path’s feasibility. Normally to adjust cost on a route you would adjust the cost value on an interface itself. This, however, affects all routes learned via this interface. What if you want to adjust an individual route coming in that interface up or down and not affect anything else?

In my brain this seemed like something that would be possible via a route-map(Cisco) or a route-filter(Mikrotik).

Take the below example:

You can see that the cost on RTR3’s interface going towards RTR1 is set to 20. All other interfaces are at their default 10. This means traffic will flow from RTR1 => RTR2 => RTR4, because this route will have a lower cost. So the question is, can we select JUST that single 10.0.0.0/24 route and adjust the cost on it. The answer is no.

You have the ability to do aggregation and adjust cost on those aggregated routes, but you can only do that at an area boundary, so that’s out. Route-maps/route-filters don’t give you the ability to adjust cost…and here’s why.

The way OSPF works in a single area is to collect LSAs(Link State Advertisements) from all other routers in that area. This forms the router’s LDB(Link State Database). The LDB MUST be identical for all routers in a single area. The idea is that if all routers in a single area have an identical picture of the network they can make the optimal routing decision. We, therefore, can’t adjust what this LDB looks like on a single router…we can’t have it both ways.

Adjusting interface cost in Cisco:

1
2

interface fa0/1
ip ospf cost 100

Adjusting interface cost in Mikrotik:

1
2

/routing ospf interface
add comment="" cost=100 disabled=no interface=bridge1 network-type=broadcast passive=no

Here’s a previous article using adjusted cost for some interesting routing.

You could conceivably use some static routing along with some scripting to create some kind of work around for this contingency, but it would be cumbersome and possibly unpredictable.