Wednesday, February 2, 2011

OSPF path selection is depends on a router finding the lowest cost path between itself and the destination network. Path cost is the cumulative cost of interfaces in the path. Interface cost is generally derived from interface bandwidth.

Okay, nothing new here. But I skipped a critical detail: Which interfaces are we talking about exactly?

What happens when neighboring routers disagree about the cost of a transit network?

The different interface types (100Mb/s and 10Mb/s) in this topology are going to cause these routers to disagree about the cost of moving a packet across the 10.0.1.0/31 network. R1's Fast Ethernet interface cost is 1, while R2's Ethernet interface cost is 10.

In OSPF, all routers have a complete picture of the network topology, so both routers know the other router's idea of the cost:

So what's the cost of this link? As it turns out, that's asking the wrong question. Links don't have costs in OSPF. OSPF deals in terms of interface transmit cost only, and gives no consideration to the cost associated with receiving a packet on an interface.

Both routers in the topology will agree that an Eastbound packet on this link accrues a cost of 1, while a Westbound packet accrues a cost of 10.

This can lead to some seriously bad decision making on OSPF's part. Assume that OSPF's auto cost reference bandwidth has been set 1Gb/s here:

R1 will evenly balance northbound traffic across R2 and R3 here, in spite of R3's reduced capacity, because R1's cost to transmit onto this multiaccess network is the same regardless of the next hop router's interface bandwidth.

Now, I'm a staunch supporter of Ethernet autonegotiation (It works! Use it! Don't force things!), except in cases where reducing the link speed to 100Mb/s will hurt. This is one of them. Issuing 'speed 1000' on either end of this link is enough to cause the R3 link to fail rather than downspeed to 100Mb/s when it has a problem on pin 4, 5, 7 or 8.

Here's another fun example.

Every OSPF route in this network goes clockwise. The path from R1 to R4's loopback includes 3 hops through 10Mb/s interfaces. It's clearly preferable for R1 to use 192.168.41.4 as the next hop for R4's loopback, but OSPF doesn't consider it.