Skip to content
Log in Sign up My account

1.10.d Path Preference

Blueprint 1.10.d: Troubleshoot OSPF (v2/v3): Path preference

  • The order OSPF uses to choose between route types: intra-area, inter-area, external type 1, external type 2 (and N1/N2 in an NSSA)
  • Cost: reference bandwidth, interface bandwidth and manual cost, and why mismatches cause odd paths
  • External metrics: E1 versus E2, seed metric and the forward metric tie-breaker
  • Equal-cost multipath
  • How longest match, administrative distance, filtering and the forwarding address interact with OSPF's own choice

Path preference tickets look like this: "traffic takes the slow link", "the backup ISP is being used", "half the traffic goes one way and comes back another". OSPF picked a path by its rules, and the rules were not what the designer expected. Your job is to read the routing table and the LSDB, work out which rule decided the outcome, and change the input that matters with the smallest possible change.

Before OSPF even gets a vote

The routing table compares candidates in three stages, and only the last is OSPF's own logic:

  1. Longest prefix match. A /24 is used before a /16 for addresses inside the /24, whatever protocol or route type each comes from. An O E2 /24 beats an O /16 for traffic to that /24.
  2. Administrative distance between protocols for the same prefix and length. OSPF is 110 for all its route types by default, so an EIGRP internal route (90) for the same prefix wins over any OSPF route.
  3. OSPF path selection among OSPF routes for the same prefix, covered below.

Exam trap

"Intra-area is always preferred" only applies to the same prefix and length. If an ABR summarizes area 1 as 10.1.0.0/16 and an ASBR redistributes 10.1.5.0/24, traffic to 10.1.5.10 follows the external /24. That is longest match, not an OSPF preference rule.

OSPF route type order

graph LR
  O["O intra-area"] --> IA["O IA inter-area"]
  IA --> E1["O E1 or O N1<br/>external, cost grows"]
  E1 --> E2["O E2 or O N2<br/>external, fixed metric"]

OSPF chooses by route type first, and compares cost only between routes of the same type:

Rank Code Source Metric used
1 O Intra-area: Type 1 and Type 2 LSAs in the same area Total path cost
2 O IA Inter-area: Type 3 LSAs Cost to the ABR plus the ABR's advertised cost
3 O E1, O N1 External type 1: Type 5 or Type 7 Seed metric plus internal cost to the ASBR
4 O E2, O N2 External type 2: Type 5 or Type 7 (the default) Seed metric only; ties broken by forward metric

OSPFv3 uses O, OI, OE1, OE2, ON1 and ON2 in show ipv6 route, with the same order.

The consequences catch people out:

  • An intra-area route with cost 500 beats an inter-area route with cost 5.
  • An E1 route with metric 900 beats an E2 route with metric 20.
  • An ABR with a slow intra-area path to a prefix in area 1 uses it even if a much faster path exists through area 0 and another ABR, because the area 0 path would make it inter-area.

Intra-area wins: an example

graph LR
  subgraph A0 ["Area 0, 10 Gbps"]
    R1["R1 ABR"] -- "cost 1" --- R2["R2 ABR"]
  end
  subgraph A1 ["Area 1"]
    R3["R3<br/>10.1.30.0/24"]
  end
  R1 -- "backup link, cost 100" --- R3
  R2 -- "cost 1" --- R3

R1 and R2 are both ABRs for area 1. R1 reaches 10.1.30.0/24 directly over its area 1 backup link at cost 100 (O). Through R2 it would be cost 2, but R1 learns that path only as a Type 3 summary from R2 across area 0 (O IA). Intra-area wins, so R1 uses the slow link. Fixes include putting the R1 to R2 link in area 1 as well (for example an extra subinterface or link in area 1), or redesigning which links belong to which area. Raising the backup link cost does not help, because the type comparison happens before cost.

Cost

OSPF interface cost is reference bandwidth / interface bandwidth, rounded down, with a minimum of 1. The default reference bandwidth is 100 Mbps, so every interface of 100 Mbps or faster gets cost 1. A path cost is the sum of the outgoing interface costs from the router toward the destination.

Interface Bandwidth Cost, reference 100 Mbps Cost, reference 100000 Mbps (100 Gbps)
Serial (default) 1544 kbps 64 64766
FastEthernet 100 Mbps 1 1000
GigabitEthernet 1 Gbps 1 100
TenGigabitEthernet 10 Gbps 1 10
Tunnel (GRE, default bandwidth 100 kbps on IOS XE) 100 kbps 1000 65535 (cost is capped at 65535)

Three ways to change it, in order of precedence:

interface GigabitEthernet0/1
 ip ospf cost 50                         ! 1. explicit cost wins over everything
!
interface GigabitEthernet0/2
 bandwidth 100000                        ! 2. changes the calculated cost (kbps)
!
router ospf 1
 auto-cost reference-bandwidth 100000    ! 3. reference in Mbps, change on every router

For OSPFv3 the interface command is ospfv3 cost 50 and the reference bandwidth is set under router ospfv3.

Exam trap

auto-cost reference-bandwidth must be the same on every router. If one router uses 100000 and the rest the default 100, that router's links look up to 1000 times more expensive to it than to everyone else, and paths become asymmetric. IOS even warns when you change it: "Please ensure reference bandwidth is consistent across all routers." When a ticket says traffic goes out one link and returns on another, compare show ip ospf | include Reference on every router.

R1# show ip ospf | include Reference
 Reference bandwidth unit is 100 mbps

R1# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               10.255.255.1/32    1     LOOP  0/0
Gi0/1        1     0               10.1.2.1/30        1     P2P   1/1
Gi0/2        1     0               10.1.3.1/30        1     P2P   1/1
Tu0          1     0               172.16.0.1/30      1000  P2P   1/1

The bandwidth command is also used by QoS and by EIGRP, so changing it to steer OSPF has side effects. ip ospf cost is the cleanest way to influence one link.

Equal-cost multipath

When two or more paths of the same type have the same lowest cost, OSPF installs them all, up to maximum-paths (4 by default on IOS; the platform maximum is higher). Traffic is shared per destination by CEF.

R1# show ip route 10.4.40.0
Routing entry for 10.4.40.0/24
  Known via "ospf 1", distance 110, metric 3, type inter area
  Last update from 10.1.3.3 on GigabitEthernet0/2, 00:01:22 ago
  Routing Descriptor Blocks:
    10.1.3.3, from 10.255.255.3, 00:01:22 ago, via GigabitEthernet0/2
      Route metric is 3, traffic share count is 1
  * 10.1.2.2, from 10.255.255.2, 00:01:22 ago, via GigabitEthernet0/1
      Route metric is 3, traffic share count is 1

OSPF does not do unequal-cost load balancing. If a ticket needs traffic shared over two unequal paths, the answer is to make the costs equal, not a variance command (that is EIGRP).

External routes: E1, E2 and the forward metric

graph LR
  R5["R5"] -- "cost 50" --- A1["ASBR1<br/>metric-type 1, seed 20"]
  R5 -- "cost 10" --- A2["ASBR2<br/>metric-type 2, seed 20"]
  A1 --- EXT["192.168.77.0/24"]
  A2 --- EXT
E2 (default) E1
Metric in the routing table Seed metric only, the same everywhere Seed metric plus internal cost to the ASBR
Configuration redistribute <source> subnets redistribute <source> subnets metric-type 1
Typical use One exit, or when internal cost does not matter Several exits, closest one should win
Tie-breaker for equal metrics Lower forward metric (cost to the ASBR), then ECMP ECMP

The default seed metric is 20 for every source except BGP, which gets 1. A redistributed default route (default-information originate) is an E2 with metric 1 unless you set it otherwise.

In the diagram, if both ASBRs used E2 with seed 20, R5 would see a metric of 20 through both and break the tie on forward metric: 10 to ASBR2 versus 50 to ASBR1, so ASBR2 wins. With ASBR1 set to E1, its route becomes type 1 with metric 70 and wins outright, because E1 is preferred to E2 regardless of metric.

R5# show ip route 192.168.77.0
Routing entry for 192.168.77.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.5.25.2 on GigabitEthernet0/1, 00:12:31 ago
  Routing Descriptor Blocks:
  * 10.5.25.2, from 10.255.255.22, 00:12:31 ago, via GigabitEthernet0/1
      Route metric is 20, traffic share count is 1

type extern 2, forward metric 10 tells you the route is E2 and that the cost to the ASBR (router ID 10.255.255.22 in the from field) is 10. To confirm both candidates, look at the LSDB rather than the routing table, because only the winner is installed:

R5# show ip ospf database external 192.168.77.0 | include Advertising|Metric Type|Metric:|Forward
  Advertising Router: 10.255.255.21
        Metric Type: 2 (Larger than any link state path)
        Metric: 20
        Forward Address: 0.0.0.0
  Advertising Router: 10.255.255.22
        Metric Type: 2 (Larger than any link state path)
        Metric: 20
        Forward Address: 0.0.0.0

NSSA externals

Routes redistributed inside an NSSA are Type 7 and appear as O N2 (default) or O N1. They rank with the matching external type: N1 alongside E1, N2 alongside E2. After translation at the ABR they become O E1 or O E2 in the rest of the domain with the same metric type.

The forwarding address

A Type 5 LSA has a forwarding address field. When it is 0.0.0.0, traffic goes to the ASBR. When it is set, traffic goes to that address instead, and the route is installed only if the forwarding address is reachable through an OSPF intra-area or inter-area route. Cisco sets a non-zero forwarding address on a Type 5 when the external next hop is on an interface that runs OSPF, is not passive and is a broadcast or non-broadcast network type. Translated NSSA externals carry a forwarding address taken from the NSSA ASBR.

R1# show ip ospf database external 192.168.9.0 | include Forward|Advertising
  Advertising Router: 10.255.255.5
        Forward Address: 10.5.9.9

R1# show ip route 10.5.9.9
% Network not in table
R1# show ip route 192.168.9.0
% Network not in table

The LSA is there, the ASBR is reachable, and still no route. The forwarding address 10.5.9.9 is not reachable through OSPF (perhaps the subnet it lives in was filtered at an ABR or is not advertised into OSPF). Fix the reachability of the forwarding address, not the redistribution.

Exam trap

An external route present in show ip ospf database external but absent from the routing table has three usual causes: the ASBR is unreachable (check show ip ospf border-routers), the forwarding address is not reachable through an OSPF internal route, or a distribute-list in filters it from the RIB. Check them in that order.

Filtering and its effect on paths

Tool Where What it affects What it does not affect
distribute-list <acl/prefix> in under router ospf Any router That router's routing table The LSDB, and therefore other routers
area N filter-list prefix <name> in or out ABR Type 3 LSAs entering or leaving area N Type 1, 2, 5 and 7 LSAs
area N range <prefix> not-advertise ABR Suppresses the Type 3 for the range Intra-area routes
summary-address <prefix> not-advertise ASBR Suppresses externals in the range Internal routes
distance Any router Which source wins between protocols OSPF's own path choice

Because link-state routers must keep identical LSDBs within an area, distribute-list in cannot stop other routers from learning a route. It is a local RIB filter. A ticket that says "R4 still has the route although R3 filters it" is testing exactly this. Use an ABR filter-list or summarization when the route must disappear for a whole area.

Summarization also creates a discard route (O 10.1.0.0/16 is a summary, 00:00:12, Null0) on the ABR or ASBR, to stop loops toward unused parts of the range. Do not mistake it for a fault.

Troubleshooting path choice

graph TB
  A["Traffic takes the wrong path"] --> B["show ip route prefix on the first router"]
  B --> C{"Longest match is the route you expect?"}
  C -->|"No"| C1["A more specific route or summary is winning"]
  C -->|"Yes"| D{"Route source is OSPF?"}
  D -->|"No"| D1["Lower AD source wins: check AD and redistribution"]
  D -->|"Yes"| E{"Route type is the one you expect?"}
  E -->|"No"| E1["Type order decides: intra, inter, E1, E2"]
  E -->|"Yes"| F["Compare cost: show ip ospf interface brief, reference bandwidth, forward metric"]

Commands in the order you use them:

  1. show ip route <prefix>: type (intra area, inter area, extern 1 or 2), metric, forward metric, next hops.
  2. traceroute <destination>: the actual hop-by-hop path.
  3. show ip ospf interface brief: cost per interface on each router along the path.
  4. show ip ospf | include Reference: reference bandwidth consistency.
  5. show ip ospf database <type> <prefix>: all candidates, not just the winner.
  6. show ip ospf border-routers: cost to each ABR and ASBR.

Lab: path preference break/fix

Topology: R1, R2 and R3 in area 0 in a triangle of Gigabit links. R4 hangs off R2 and R3 in area 1 (both are ABRs). Two ASBRs, R2 and R3, redistribute the same static route 192.168.77.0/24 (pointing to Null0) into OSPF.

graph TB
  subgraph A0 ["Area 0"]
    R1["R1"] -- "10.1.2.0/30" --- R2["R2 ABR ASBR"]
    R1 -- "10.1.3.0/30" --- R3["R3 ABR ASBR"]
    R2 -- "10.2.3.0/30" --- R3
  end
  subgraph A1 ["Area 1"]
    R4["R4<br/>Lo40 10.4.40.1/24"]
  end
  R2 -- "10.2.4.0/30" --- R4
  R3 -- "10.3.4.0/30" --- R4

Baseline: all links ip ospf network point-to-point, default costs, both ASBRs with redistribute static subnets (E2, seed 20). Verify that R1 has two equal-cost paths to 10.4.40.0/24 and two E2 paths to 192.168.77.0/24 with forward metric 1 through each.

Tickets

  1. Requirement: R1 must use R2 for 192.168.77.0/24, R3 as backup, without touching interface costs. Task: on R2 redistribute static subnets metric-type 1. Verify R1 now shows type extern 1 via R2 only. Explain why R3's E2 route is ignored even though its metric 20 is lower than R2's E1 metric 21.
  2. Asymmetric paths after an upgrade. Fault: auto-cost reference-bandwidth 10000 on R3 only. Proof: R3's Gigabit interfaces show cost 10, the others cost 1; traceroutes from R1 and from R4 take different paths. Fix: same reference bandwidth everywhere.
  3. R1 should prefer R3 for 10.4.40.0/24. Task: raise the cost of R1 Gi0/1 (ip ospf cost 10) and verify that the ECMP pair becomes a single path. Then explain why changing the cost on R2's Gi0/1 instead would affect R2's traffic toward R1, not R1's traffic.
  4. Filter does not filter. Fault: on R1 distribute-list prefix NO-77 in with a prefix list denying 192.168.77.0/24. Observe that R1 loses the route, but a new router attached to R1 still learns it. Then achieve area-wide filtering correctly with summary-address 192.168.77.0 255.255.255.0 not-advertise on both ASBRs, and discuss why that is the ASBR tool and area filter-list is not (it only filters Type 3).
  5. Intra-area beats a faster path. Change: put the R2 to R3 link into area 1. Look at R2's route to R3's loopback and to R4's LAN before and after. Note which paths changed from O IA to O, and why.

Quick check

An ABR has an intra-area route of cost 120 and an inter-area route of cost 4 for the same /24. Which does it install?

The intra-area route. OSPF compares route types first: intra-area, then inter-area, then E1/N1, then E2/N2. Cost is compared only between routes of the same type.

Two ASBRs advertise the same prefix as E2 with metric 20. How does an internal router choose?

It compares the forward metric, the cost from itself to each ASBR, and uses the ASBR with the lower forward metric. If those are equal too, it installs both (ECMP).

A Type 5 LSA is in the database and the ASBR is reachable, but the route is not installed. The LSA shows Forward Address 10.9.9.1. What do you check?

Whether 10.9.9.1 is reachable through an OSPF intra-area or inter-area route. A non-zero forwarding address that is not reachable through OSPF stops the external route from being installed.

References