Common Sense Prevails Over RFC 2328

When trying to extract the OSPF route selection rules from RFC 2328, I've stumbled across a very weird rule (section 16.4.1): if an ASBR within a non-backbone area advertises an external route (or if the forwarding address is within the non-backbone area), it's preferred over external routes advertised by ASBRs in other areas regardless of its metric. I simply had to test this on Cisco IOS … and found out that Cisco engineers prefer common sense to OSPF RFC.

I've built a sample network where two routers (10.0.0.11 in area 1, 10.0.0.3 in the backbone area) advertise the same external routes. The router in area 1 advertises the routes with a higher metric:

S2#ospfExternals
 
External OSPF routes for OSPF process ID 1
 
  Prefix                Cost   Tag            ASBR Forward addr
==================================================================
> 10.1.0.1/32          10 E1     1        10.0.0.3
  10.1.0.1/32        2000 E1     1       10.0.0.11
> 10.1.0.2/32           5 E2     2        10.0.0.3
  10.1.0.2/32         200 E2     2       10.0.0.11

You can use the show ip ospf route command to verify which ASBR is within the area. An abbreviated printout is included:

S2#show ip ospf route
 
    Intra-area Router Path List
i 10.0.0.11 [64] via 10.0.2.17, Serial1/2, ASBR, Area 1, SPF 2
i 10.0.0.2 [64] via 10.0.2.13, Serial1/1, ABR, Area 1, SPF 2
i 10.0.0.1 [64] via 10.0.2.5, Serial1/0, ABR, Area 1, SPF 2
 
    Inter-area Router Path List
I 10.0.0.3 [128] via 10.0.2.5, Serial1/0, ASBR, Area 1, SPF 2

As you can see, 10.0.0.11 is within area 1, whereas 10.0.0.3 is in another area. Still, IOS prefers external routes advertised by 10.0.0.3 due to their lower metric:

S2#show ip ospf route
    External Route List
*>  10.1.0.1/32, Ext1, cost 138, tag 1
      via 10.0.2.5, Serial1/0
*>  10.1.0.2/32, Ext2, cost 5, tag 2
      via 10.0.2.5, Serial1/0

11 comments:

  1. I believe the RFC procedure for the want of better word, is a loop prevention mechanism, despite how stupid a network design you would have to have, to fall foul of it. :)
  2. Actually I cannot see why this would prevent loops (but any example to the contrary is most welcome :).

    On the other hand, OSPF already has a few other loop-generating mechanisms, as I've documented in my latest IP Corner article.
  3. I'm curious as to why this is in the RFC as well. I can't see any obvious purpose.
  4. Can anyone kindly explain me the topology in which this Cisco-specific OSPF behavior was seen.

    You may either post the same in the same topic "Common sense prevails over RFC2328" or you can send an email to my [email protected]
  5. It happens in a very simple topology: let's assume you have ASBR in Area 0, ABR between Area 0 and Area 1 and two routers in Area 1, one of them being ASBR and having very high link cost to the rest of the network.

    ASBR in Area 0 is thus closer to routers in Area 1 than ASBR in Area 1 and if they both advertise the same external route, the one from Area 0 is used.
  6. From the topology that you have mentioned, I cant actually make out in what way Cisco is smart in selecting a E-route on basis of cost and not on inter-area/intra-area path. Referring to your topology, it would be prudent for a non-bkbone router (in Area 1) to select the E-route coming from its direct neighbor (or even adjacent neighbor) rather via another router (connected backbone router). Well again, the confusion would arise what would the ABR (connected to backbone ASBR and Area1) do?
    Jishnu
  7. Yes, I'm three years late to this party.

    The reason for preferring intra-area external routes is explained in section G.7 of RFC 2178.

    I thought that I've duplicated this behavior on IOS before, but currently cannot. 12.4(25d) with 'no compatible rfc1583' in the OSPF configuration stanza.
  8. Setting up the topology as shown in Figure 19 of Appendix G.7 of RFC 2178 with IOS 15.4(2)T in 2016 actually causes the loop that Richard Woundy identified/discovered in mid 1990s. The no compatible rfc1583 command has no effect on the AS-external selection criteria, but only on the metric selection for aggregated type 3 LSAs.
    It seems that the topology as designed in Figure 19 of Appendix G.7 of RFC2178 is currently not supported by IOS.
    From http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/117824-config-ospf-00.html i gather that Cisco Disabled RFC1583Compatibility by default on its NX-OS, and at last actually implemented RFC2178 and RFC2328.
    Replies
    1. This is why I love to blog ;) ... every now and then someone writes a fantastic comment that sends me down yet another rabbit hole.

      Thank you!
  9. I've been reading RFC 2328 sections 16.4 and 16.4.1 for 2 days already and I'm not sure that Cisco implemented RFC 2328 wrong.

    In the case above we have:
    a) 2 different ASBRs that are in different areas (area 0 and area 1)
    b) 2 different ASBRs advertise same external network with different E2 metrics

    Section 16.4.1 is part of section 16.4 so we might not refer just 16.4.1 alone.

    When I follow Section 16.4 I consider "Each of the AS-external-LSAs is considered in turn" as RFC says. For each AS-external-LSA I come to 16.4(3) but I skip 16.4.1 here because we do not have "multiple routing table entries for the ASBR". I think that example in the post doesn't have multiple routing table entries for the ASBR for each of 2 AS-external-LSA either.

    So my procedure comes to 16.4(6)(b) where AS-external-LSA with smallest E2 metric wins.

    Please note that we could get into 16.4.1 from 16.4(6)(c) in case E2 metrics match (that is why Richard Woundy G.7 problem is solved)

    Am I reading RFC properly?

    Can anyone give comments on this?
    Replies
    1. There are two ways to get into section 16.4.1 of RFC 2328:

      1. When you have multiple paths to the same ASBR. This will happen in the 16.4(3) step. In this case, both the metric type and the E2 metric value will be ignored when preferring the intra-area path to the same ASBR over a backbone or inter-area path to the ASBR. Comparing E2 metric values at this stage of the path preference algorithm is pointless. We are not comparing AS-external LSAs from different ASBRs to find the best AS-external LSA (and in turn the best ASBR). We are at this point of the algorithm still trying to find the best path to this AS-external LSA's ASBR. Even of we go to section 16.4.1 and come back, the LSA's cost will be compared to other LSA's costs at step 16.4(6)(b).

      2. When comparing two paths to the same external prefix via two different ASBRs. This will happen in the 16.4(6)(c) step. In this case, we already know that the E2 metric value is identical for the two AS-external LSAs. This test has happened in step 16.4(6)(b). If the E2 metric values were different, the cheapest of the two AS-external LSAs would have been preferred in step 16.4(6)(b), ending the discussion there, and we would not have reached step 16.4(6)(c). In this case, the intra-area ASBR is preferable to the backbone or inter-area ASBR for the two equal-cost AS-external LSAs.

      So, as per RFC 2328, E2 metric value is king. The lowest E2 metric value is always preferred. The 16.4.1 section only affects how the path to the ASBR is determined, and which ASBR will be chosen in the case of equal E2 metric values.

      Cisco IOS implements none of these two cases.
Add comment
Sidebar