Short answer: OSPF cost is a directional link metric, not a bandwidth reservation.[1] For comparable OSPF paths, the router evaluates accumulated cost; changing the cost on one interface does not automatically change the reverse direction.[1]
This guide solves a specific problem: a 100 Gb/s path and a 10 Gb/s backup look equally attractive, or a cost change moves outbound traffic but leaves return traffic unchanged. We build an original four-router example, calculate the expected routes, and give a reversible change checklist.
Scope: where this fits in the routing series
The BGP fundamentals track has now covered its core attributes, policy, fabrics, failover and troubleshooting. This OSPF installment focuses on a different decision: choosing a path inside your routing domain. Existing neighbor-state, Hello, network-type and LSA articles are linked below instead of being repeated.
Why faster links can have the same OSPF cost
Cisco documents an automatic cost calculation based on reference bandwidth divided by interface bandwidth, with a default reference bandwidth of 100 Mb/s; an explicit interface cost overrides that calculation.[2]
FRRouting likewise documents a default reference of 100 Mbit/s and a cost of 1 for links at or above that speed.[4]
For a proposed 100,000 Mb/s reference, our arithmetic gives the following planning values. These are calculations, not device measurements:
| Interface bandwidth | Reference bandwidth | Calculated interface cost |
|---|---|---|
| 1 Gb/s | 100,000 Mb/s | 100 |
| 10 Gb/s | 100,000 Mb/s | 10 |
| 25 Gb/s | 100,000 Mb/s | 4 |
| 100 Gb/s | 100,000 Mb/s | 1 |
Do not choose a reference value simply because it is large. We recommend documenting the fastest relevant link, the slowest links, and any explicit cost overrides before selecting a domain-wide convention. FRRouting explicitly requires consistent reference-bandwidth configuration across the OSPF domain.[4]
Original lab: prefer the fast path, retain the backup
Use four routers in area 0 with two point-to-point paths between R1 and R4. R4 advertises loopback 192.0.2.4/32 with explicit OSPF cost 1; R1 advertises 192.0.2.1/32 with the same cost. All addresses here are illustrative.
R2
/ \
/ \
R1 R4 --- 192.0.2.4/32
\ /
\ /
R3
Upper path: R1--R2--R4, cost 1 per directed transit link
Lower path: R1--R3--R4, cost 10 per directed transit link
Loopback destination cost: 1
Our intended baseline is:
- R1 to R4's loopback: upper path, total cost 3.
- R1's backup through R3: total cost 21.
- R4 to R1's loopback: upper path, total cost 3.
- No equal-cost split between upper and lower paths.
Treat these as acceptance criteria, not captured CLI output. Recalculate them if you use different interfaces, add another link, or advertise a subnet instead of the stated loopback.
Cisco IOS/IOS XE-style configuration
The following is an original lab template, not a universal production paste. Interface names must match your platform. The Cisco command reference specifies reference bandwidth in Mb/s and an interface-cost range of 1 through 65,535.[3]
Apply this process-level convention on all four routers, with a unique router ID on each:
! R1 example; use router IDs .2, .3 and .4 on R2, R3 and R4
router ospf 10
router-id 192.0.2.1
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface GigabitEthernet0/0
no passive-interface GigabitEthernet0/1
For a reproducible exercise independent of virtual NIC speed, explicitly assign the lab costs. On R1:
interface GigabitEthernet0/0
description LAB-to-R2
ip address 198.51.100.1 255.255.255.252
ip ospf 10 area 0
ip ospf network point-to-point
ip ospf cost 1
no shutdown
!
interface GigabitEthernet0/1
description LAB-to-R3
ip address 198.51.100.5 255.255.255.252
ip ospf 10 area 0
ip ospf network point-to-point
ip ospf cost 10
no shutdown
!
interface Loopback0
ip address 192.0.2.1 255.255.255.255
ip ospf 10 area 0
ip ospf cost 1
Complete the addressing and directional cost plan as follows:
- R2 to R1: 198.51.100.2/30, cost 1; R2 to R4: 198.51.100.9/30, cost 1.
- R4 to R2: 198.51.100.10/30, cost 1; R4 to R3: 198.51.100.14/30, cost 10.
- R3 to R1: 198.51.100.6/30, cost 10; R3 to R4: 198.51.100.13/30, cost 10.
- R4 loopback: 192.0.2.4/32, cost 1. R2/R3 can use router IDs 192.0.2.2/192.0.2.3 without advertising extra loopbacks.
- Enable OSPF area 0 and point-to-point network type on every transit interface; remove passive mode on those interfaces only.
The explicit costs deliberately override automatic calculation. To test reference bandwidth instead, remove those transit overrides using the platform's documented no-form, then inspect the resulting interface costs; changing reference bandwidth alone will not supersede a configured interface cost.[3]
Outbound control versus inbound influence
Now change only R1's upper-path interface:
interface GigabitEthernet0/0
ip ospf cost 100
Our graph calculation predicts R1's upper path becomes 102, while the lower path stays 21. R1 should therefore send toward R3. R4 still calculates its path to R1 using the unchanged costs in the opposite direction, so its preferred return path remains R4–R2–R1 at cost 3. This illustrates the directional output-cost model specified by OSPF.[1]
For a symmetric move in this particular topology, our proposed second change is to raise R4's interface toward R2 to 100. Its path through R2 becomes 102, versus 21 through R3. That is a separate change on a separate router, not an automatic consequence of modifying R1.
What cost cannot guarantee: this example does not control an ISP's inbound BGP policy, reserve link capacity, or validate firewall/NAT session handling. Our recommendation is to test both traffic directions and application sessions rather than infer symmetry from a single traceroute.
Also, do not compare every visible OSPF number as if it belonged to one flat competition: OSPF distinguishes intra-area, inter-area and external paths, and type-2 external selection gives special weight to the external metric.[1]
FRRouting equivalent
FRRouting supports both the reference-bandwidth setting and explicit interface cost, and provides interface, neighbor and database inspection commands.[4]
An equivalent R1 fragment, assuming IPv4 forwarding and the FRR daemons are already enabled:
router ospf
ospf router-id 192.0.2.1
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface eth0
no passive-interface eth1
!
interface eth0
ip ospf area 0
ip ospf network point-to-point
ip ospf cost 1
!
interface eth1
ip ospf area 0
ip ospf network point-to-point
ip ospf cost 10
Assign the same link IP addresses as in the Cisco lab. Keep this explicit-cost exercise separate from the automatic-bandwidth exercise, so the result tells you which mechanism you actually tested.
Verification commands and expected logic
On Cisco, inspect the effective cost rather than relying only on configuration text; the command reference identifies show ip ospf interface as the interface inspection command.[3]
show ip ospf neighbor
show ip ospf interface GigabitEthernet0/0
show ip ospf interface GigabitEthernet0/1
show ip ospf database router self-originate
show ip route 192.0.2.4
show ip cef 192.0.2.4
On FRRouting, use these documented OSPF inspection forms through vtysh.[4]
show ip ospf interface eth0
show ip ospf neighbor
show ip ospf database router
show ip route 192.0.2.4/32
Our recommended acceptance test matrix:
| Test | R1 toward 192.0.2.4/32 | R4 toward 192.0.2.1/32 |
|---|---|---|
| Baseline | R2, cost 3 | R2, cost 3 |
| Only R1 upper cost raised to 100 | R3, cost 21 | R2, cost 3 |
| R1 and R4 upper costs both raised | R3, cost 21 | R3, cost 21 |
| Restore baseline, then remove R1–R2 | R3, cost 21 | R3, cost 21 |
These are graph-model predictions, not real-router execution results. We recommend checking the installed route, forwarding entry and sourced traffic probe at both endpoints. Save actual device output separately from these expectations.
Troubleshooting checklist
- Wrong effective cost? Compare the interface display with the intended cost plan; check for an explicit override before investigating automatic calculation.[3]
- Automatic costs identical? Check the reference and interface bandwidth values against the documented formula.[2]
- Only one direction changed? Walk the return path as a separate directed graph, using the remote router's advertised output costs.[1]
- Unexpected route still wins? Record its prefix length, route source and OSPF path type before changing another metric; do not use this intra-area lab's arithmetic as an external-route selection rule.[1]
- Configuration and route disagree? Our suggested evidence bundle is the neighbor table, effective costs, relevant LSAs, route and forwarding entry, plus timestamps from both endpoints.
- Tempted to restart the process? We recommend checking the above first. A restart is not part of this lab's normal metric-change procedure.
- Rollback unclear? Restore the saved per-interface values, recheck both routes, and repeat the baseline probes before ending the change window.
Applying the lesson to fabrics and cloud edges
For a design using OSPF beneath BGP EVPN, we recommend treating underlay path selection and overlay policy as separate acceptance tests. Check VTEP/peer loopback reachability first, then validate the overlay and application flows. Do not transplant this OSPF CLI into a managed ACI fabric.
For a dual-edge design, write down which decision you are changing: the internal path to the border, the border's external BGP selection, or the upstream network's policy. Our recommendation is to give each a separate test row and rollback condition. This prevents a successful internal metric change from being mistaken for proof of Internet inbound control.
Interview answer
OSPF cost is directional and accumulates along a path. Cisco's explicit interface cost overrides its automatic reference-bandwidth calculation. I verify the effective cost and installed route, then independently check the reverse path; a local change is not proof of symmetric forwarding.[1][3]
Summary and reusable change checklist
Before a cost change, record both endpoint routes, all relevant directional costs, the intended next hops, and rollback values. Afterward, repeat the same checks and test both traffic directions. Use the four-row acceptance matrix above as a starting template, not as a substitute for device evidence.
Related reading
- OSPF Neighbor States: Step-by-Step
- OSPF Hello Packets: Timers, Neighbors and Troubleshooting Checks
- OSPF Network Types Explained
- OSPF LSA Types: Practical Guide
- BGP Dual-ISP Edge Design
Sources
- https://www.rfc-editor.org/rfc/rfc2328.html — RFC 2328: OSPF Version 2
- https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/9237-9.html — Cisco OSPF Frequently Asked Questions
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/command/iro-cr-book/m_ospf-a1.html — Cisco IOS OSPF Command Reference: auto-cost and interface cost
- https://docs.frrouting.org/en/latest/ospfd.html — FRRouting OSPFv2 documentation
Post a Comment