OSPF Cost: Reference Bandwidth, Manual Overrides, and Gotchas

OSPF cost is the single metric that decides which path through your network wins. Get it wrong and traffic takes the long way around even though you have the right links in place. Get it right and the network does what you drew on the whiteboard. This post walks through how cost is calculated, where the default reference bandwidth bites, when to override cost manually, and the gotchas that show up the first time you run OSPF on a network with mixed-speed links.

For the cluster overview, see the OSPF complete guide. For an interior gateway protocol that handles cost calculation differently, see the EIGRP pillar.

The formula

OSPF calculates the cost of each interface using:

cost = reference_bandwidth / interface_bandwidth

Both numbers are in bits per second. The default reference bandwidth on Cisco IOS XE is 100,000,000 (100 Mbps). The interface bandwidth is whatever the physical interface reports (or whatever you have set with the bandwidth command).

Worked examples with default reference:

This is the default problem. Every interface from 100 Mbps to 100 Gbps gets cost 1. OSPF cannot tell your 100 Gbps backbone link apart from a 100 Mbps copper drop. Traffic will route over whichever path has fewer hops, regardless of bandwidth.

Fixing the reference bandwidth

The fix is to raise the reference bandwidth to a number that gives meaningfully different costs for the link speeds you actually have.

router ospf 1
 auto-cost reference-bandwidth 100000

That sets the reference to 100 Gbps. Recalculate the table:

Now each link speed has a distinct cost. The 10 Gbps backbone wins over the 1 Gbps path. The 1 Gbps wins over the 100 Mbps. Path selection actually reflects bandwidth.

Critical rule: the reference bandwidth must be the same on every router in the OSPF domain. If one router uses 100 (the default in Gbps reading) and another uses 100000 (100 Gbps), the cost calculations will not align and the SPF tree will compute differently on different routers. The resulting routing loops are hard to diagnose. Always configure auto-cost reference-bandwidth network-wide, or accept the default network-wide.

Manual cost override per interface

For specific interfaces where you want to override the calculated cost, use:

interface GigabitEthernet0/0
 ip ospf cost 50

This forces the OSPF cost for that interface to 50 regardless of the bandwidth-based calculation. Common reasons to override:

• You want traffic to prefer one specific path over another for policy reasons (cost of the carrier circuit, security boundary preference)
• You have a low-bandwidth backup link that should only be used if the primary fails. Set its cost to a very large number (e.g., 1000) so it loses to everything except true failure.
• You have a high-bandwidth link that you know is congested and want to actively de-prefer for OSPF traffic (rare, but happens)

The manual cost wins over the auto-calculated cost.

The bandwidth command vs the actual link speed

The OSPF cost calculation uses the bandwidth value reported by the interface. By default, this matches the physical link rate (1000000 kbps for a Gigabit interface). You can override it:

interface GigabitEthernet0/0
 bandwidth 100000     ! Tells the router this interface is 100 Mbps for protocol purposes
                      ! Does not actually slow the physical link

This is a powerful and dangerous knob. It lets you influence OSPF cost without using ip ospf cost directly. But the bandwidth value is consumed by other protocols too (EIGRP uses it for metric, QoS uses it for shaping references, MPLS-TE uses it for available-bandwidth tracking). Changing it for OSPF reasons can break things you did not plan to touch.

Rule of thumb: use ip ospf cost when you want to influence only OSPF. Use bandwidth only when you actually need to advertise a different rate to multiple protocols.

Verifying the cost

R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.20.0.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           10         no         no            Base

Three things to read:

• Cost: 10. This is the cost OSPF is using for this interface. After my auto-cost reference-bandwidth 100000, a 10 Gbps interface should show 10. (A 1 Gbps would show 100.)
• Network Type: BROADCAST. The Hello/dead intervals and DR/BDR election depend on this. Not directly cost-related but visible in the same output.
• Area 0. Just confirms what area this interface is in.

Total path cost

The total cost of an OSPF path is the sum of the interface costs along the path. Specifically, the cost of every outbound interface from the local router to the destination. The cost of incoming interfaces does not count.

If the path is R1 -> R2 -> R3 over two 10 Gbps interfaces, with reference bandwidth 100 Gbps, the total cost is 10 + 10 = 20. R1 advertises the prefix to other routers with that summed cost. show ip route X.X.X.X displays this total.

Equal-cost multipath (ECMP)

When two paths to the same destination have the same total cost, OSPF installs both in the FIB by default and load-balances. The maximum number of equal-cost paths is controlled by:

router ospf 1
 maximum-paths 4

Default is 4. Can be raised. ECMP is one of the reasons careful cost engineering matters: if you accidentally make two paths equal cost when you wanted one to be preferred, traffic splits across both, including possibly across a path with worse jitter or latency.

Common gotchas

Key takeaways

OSPF cost is reference bandwidth divided by interface bandwidth. The default reference of 100 Mbps was set when 100 Mbps was a backbone link, and is now wrong for every modern network. Raise it to at least 100 Gbps. Configure the new value on every router in the OSPF domain to keep the math consistent. Use ip ospf cost per-interface for surgical overrides, but resist the temptation to micromanage cost on every link; the auto-calculated cost is correct often enough that explicit overrides should be rare and documented.

For broader OSPF coverage, see the OSPF pillar.