OSPF RFC1583 Compatibility (External Route Selection Rules)

OSPF RFC1583 Compatibility (External Route Selection Rules)

When two ASBRs advertise the same external route, an OSPF router has to decide which one to use. RFC 2328 defines the order of that comparison, and one step in it is switched on or off by a setting called RFC1583Compatibility. When that step is in effect, the ASBR with the lower cost is not necessarily chosen.

This article checks in RFC 2328 what that step compares and why it was introduced, and then confirms on IOS XE and IOS XR which ASBR each router picks. The basics of external routes and the difference between E1 and E2 are covered in OSPF External Routes.

The order in which external routes are compared

Section 16.4 of RFC 2328 says that when there are several external routes to the same destination, they are compared in this order.

(c) applies only when RFC1583Compatibility is disabled. When it is enabled, (c) is skipped and the comparison goes straight to the cost in (d).

The order of preference that (c) uses is given in Section 16.4.1.

Intra-area paths using non-backbone areas are always the most preferred. The other paths, intra-area backbone paths and inter-area paths, are of equal preference. (RFC 2328 Section 16.4.1)

In other words, if the ASBR can be reached entirely within a non-backbone area, that path is chosen no matter how large its cost is. Intra-area backbone paths and inter-area paths are of equal rank, so between them the cost in (d) decides.

Why this step exists

RFC 1583 (the previous version of RFC 2328) had no (c) and compared external routes by cost alone. Appendix C.1 of RFC 2328 explains the rule used when RFC1583Compatibility is disabled as follows.

The preference rules of Section 16.4.1 prevent routing loops when AS-external-LSAs for the same destination have been originated from different areas. (RFC 2328 Appendix C.1)

When ASBRs in different areas originate the same external route, comparing by cost alone can make routers reach different decisions, which can lead to a loop. Appendix G.2 points out that, especially with virtual links, a path that is an intra-area backbone path for one router can be an inter-area path for another, and says that this is why the two were given equal preference.

The RFC 2328 default is enabled (the RFC 1583 rule is kept). Appendix C.1 then says that all routers in the domain should have the same setting: all enabled if old RFC 1583 implementations are present, otherwise all disabled.

How each platform handles it

IOS XE switches the rule with compatible rfc1583 under router ospf. The default is enabled (the RFC 1583 rule), and no compatible rfc1583 switches to the rule of Section 16.4.1. When it is disabled, no compatible rfc1583 appears in the running-config.

IOS XR (XRd 26.1.1) has no command to switch this rule. compatible under router ospf is rejected with % Invalid input. External routes are chosen by the RFC 1583 rule, which compares cost alone.

In a domain that mixes the two, disabling it only on IOS XE makes routers pick different ASBRs. Appendix C.1 asks for the same setting on every router because this disagreement is what causes loops.

Lab verification

Lab setup

R2 and R3 redistribute a static route 192.0.2.0/24 to Null0 and originate the same external route (E2, metric 20, forwarding address 0.0.0.0). R2 is an ASBR in area 0 and R3 is an ASBR in area 1.

R1 and R4 are both ABRs for areas 0 and 1, with cost 10 toward R2 and cost 30 toward R3. The rule is switched on R1 (IOS XE), and the ASBR it chooses is compared with that of R4 (IOS XR) in the same position.

(a) and (b) produce a tie, so the comparison moves on to (c) or (d). R3 is reachable entirely within area 1, so Section 16.4.1 prefers R3. Comparing by cost alone gives R2.

Steps

Whether it can be configured (STEP 0)

This is the result of typing compatible ? under router ospf on R1 (IOS XE).

R1(config)#router ospf 1
R1(config-router)#compatible ?
  rfc1583  compatible with RFC 1583
  rfc1587  compatible with RFC 1587
  rfc5243  supports DBD exchange optimization

R1(config-router)#compatible 
% Incomplete command.

rfc1583 is there. Doing the same on R4 (IOS XR) is rejected at compatible.

RP/0/RP0/CPU0:R4(config)#router ospf 1

RP/0/RP0/CPU0:R4(config-ospf)#compatible ?

                                 ^
% Invalid input detected at '^' marker.

By default the cost decides (STEP 1)

After R2 and R3 start redistributing, these are the ASBRs R1 knows and the paths to them.

R1#show ip ospf border-routers

            OSPF Router with ID (1.1.1.1) (Process ID 1)


		Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 4.4.4.4 [20] via 10.0.12.2, GigabitEthernet1, ABR, Area 0, SPF 6
i 4.4.4.4 [60] via 10.0.13.3, GigabitEthernet2, ABR, Area 1, SPF 5
i 2.2.2.2 [10] via 10.0.12.2, GigabitEthernet1, ASBR, Area 0, SPF 6
i 3.3.3.3 [30] via 10.0.13.3, GigabitEthernet2, ASBR, Area 1, SPF 5

R2 (2.2.2.2) is reached by an intra-area path in area 0 with cost 10, and R3 (3.3.3.3) by an intra-area path in area 1 with cost 30. The routing tables of R1 and R4 are as follows.

R1#show ip route 192.0.2.0
Routing entry for 192.0.2.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.0.12.2 on GigabitEthernet1, 00:03:31 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 2.2.2.2, 00:03:31 ago, via GigabitEthernet1
      Route metric is 20, traffic share count is 1

RP/0/RP0/CPU0:R4#show route 192.0.2.0/24
Tue Sep 22 11:34:05.215 UTC

Routing entry for 192.0.2.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2
  Installed Sep 22 11:30:55.165 for 00:03:10
  Routing Descriptor Blocks
    10.0.24.2, from 2.2.2.2, via GigabitEthernet0/0/0/0
      Route metric is 20
  No advertising protos. 

Both show from 2.2.2.2, that is, they chose R2. On IOS XE, forward metric 10 is the cost to the ASBR. The default rule compares cost alone, so R2 with cost 10 wins.

Disabling RFC1583 compatibility (STEP 2)

no compatible rfc1583 was entered on R1. These are the commands recorded by IOS XE’s archive and the running-config.

R1#show archive log config 71 99999 provisioning
router ospf 1
 no compatible rfc1583 

R1#show running-config | section router ospf
router ospf 1
 router-id 1.1.1.1
 no compatible rfc1583

The routing table of R1:

R1#show ip route 192.0.2.0
Routing entry for 192.0.2.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 30
  Last update from 10.0.13.3 on GigabitEthernet2, 00:02:51 ago
  Routing Descriptor Blocks:
  * 10.0.13.3, from 3.3.3.3, 00:02:51 ago, via GigabitEthernet2
      Route metric is 20, traffic share count is 1

It switched to from 3.3.3.3 (R3). With forward metric 30, it is the higher-cost one. R3 is reached by an intra-area path in area 1, so Section 16.4.1 picks it before the cost is considered.

R4 at the same time:

RP/0/RP0/CPU0:R4#show route 192.0.2.0/24
Tue Sep 22 11:37:10.042 UTC

Routing entry for 192.0.2.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2
  Installed Sep 22 11:30:55.165 for 00:06:14
  Routing Descriptor Blocks
    10.0.24.2, from 2.2.2.2, via GigabitEthernet0/0/0/0
      Route metric is 20
  No advertising protos. 

R4 stays on R2. R4 also reaches R3 by an intra-area path in area 1, so under the rule of Section 16.4.1 it would pick R3. R4’s show ospf border-routers shows the same path types and costs as R1.

RP/0/RP0/CPU0:R4#show ospf border-routers
Tue Sep 22 11:37:10.612 UTC

OSPF 1 Internal Routing Table

Codes: i - Intra-area route, I - Inter-area route

i 1.1.1.1 [20] via 10.0.24.2, GigabitEthernet0/0/0/0, ABR , Area 0, SPF 8
i 1.1.1.1 [60] via 10.0.34.3, GigabitEthernet0/0/0/1, ABR , Area 1, SPF 8
i 2.2.2.2 [10] via 10.0.24.2, GigabitEthernet0/0/0/0, ASBR , Area 0, SPF 8
i 3.3.3.3 [30] via 10.0.34.3, GigabitEthernet0/0/0/1, ASBR , Area 1, SPF 8

Two ABRs in the same position chose different ASBRs: R1 chose R3 and R4 chose R2. In this topology both reach the ASBR directly, so there is no loop, but this is exactly the disagreement that Appendix C.1 asks to avoid by using the same setting everywhere.

A cost of 100 changes nothing (STEP 3)

The cost of R1’s interface toward R3 (GigabitEthernet2) was raised to 100.

R1#show archive log config 73 99999 provisioning
interface GigabitEthernet2 
 ip ospf cost 100

R1#show ip ospf border-routers

            OSPF Router with ID (1.1.1.1) (Process ID 1)


		Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 4.4.4.4 [20] via 10.0.12.2, GigabitEthernet1, ABR, Area 0, SPF 7
i 4.4.4.4 [130] via 10.0.13.3, GigabitEthernet2, ABR, Area 1, SPF 7
i 2.2.2.2 [10] via 10.0.12.2, GigabitEthernet1, ASBR, Area 0, SPF 7
i 3.3.3.3 [100] via 10.0.13.3, GigabitEthernet2, ASBR, Area 1, SPF 7

R1#show ip route 192.0.2.0
Routing entry for 192.0.2.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 100
  Last update from 10.0.13.3 on GigabitEthernet2, 00:05:58 ago
  Routing Descriptor Blocks:
  * 10.0.13.3, from 3.3.3.3, 00:05:58 ago, via GigabitEthernet2
      Route metric is 20, traffic share count is 1

The cost to R3 is 100, ten times that to R2. R1 still chooses R3. The path-type comparison (c) comes before the cost comparison (d).

Re-enabling RFC1583 compatibility (STEP 4)

compatible rfc1583 was entered on R1. The cost stays at 100.

R1#show archive log config 75 99999 provisioning
router ospf 1
 compatible rfc1583 

R1#show ip route 192.0.2.0
Routing entry for 192.0.2.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.0.12.2 on GigabitEthernet1, 00:02:51 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 2.2.2.2, 00:02:51 ago, via GigabitEthernet1
      Route metric is 20, traffic share count is 1

It went back to R2 (forward metric 10). (c) was skipped and the cost alone decided.

Design notes

• In a domain that includes IOS XR, leave IOS XE at the default (compatible rfc1583). IOS XR cannot switch to the rule of Section 16.4.1, so the RFC 1583 rule is the only one every router can share
• The comparison in (c) changes the result only when the paths to the ASBRs are of different types. The disagreement shows up in designs where ASBRs in different areas originate the same external route

Configurations and show outputs

In each STEP, the following files were collected from all four routers, one file per router. The configuration used in the lab is the ..._run.txt file (the final state is the one of the last STEP).

There is no cfg / commit file for STEPs and routers whose configuration did not change. The compatible ? help checked before STEP 0 is in R1 (IOS XE) and R4 (IOS XR). In the final state, redistribution is stopped and R1’s cost and RFC1583 compatibility are back at their defaults.

STEP 0: Initial state (nothing redistributed)

STEP 1: R2 and R3 redistribute 192.0.2.0/24

STEP 2: no compatible rfc1583 on R1

STEP 3: Raise the cost of R1’s link toward R3 to 100

STEP 4: compatible rfc1583 back on R1

STEP 5: Everything back to the defaults (final state)

References

Related articles

• What Is OSPF
• OSPF Router ID
• OSPF Packet Types and Header Format
• OSPF Authentication
• OSPF Neighbor States
• OSPF Options Field
• OSPF DR and BDR
• OSPF Network Types
• OSPF Cost (Metric)
• OSPF External Routes (Redistributing Static Routes)
• OSPF RFC1583 Compatibility (External Route Selection Rules)
• OSPF Multiple Areas and the ABR
• OSPF Virtual Links
• OSPF Stub and Totally Stubby Areas
• OSPF NSSA and Totally NSSA
• OSPF Default Route
• OSPF Route Summarization
• OSPF LSAs and the LSA Header
• OSPF Hello and Dead Intervals
• OSPF Convergence Timers (SPF / LSA Throttling)
• OSPF LSA Refresh and Pacing
• OSPF router-LSA (type 1)
• OSPF network-LSA (type 2)
• OSPF summary-LSA (type 3)
• OSPF ASBR summary-LSA (type 4)
• OSPF AS external-LSA (type 5)
• OSPF NSSA External-LSA (Type 7)