Build the Next-Generation Data Center
6 week online course starting in spring 2017

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 ( in area 1, in the backbone area) advertise the same external routes. The router in area 1 advertises the routes with a higher metric:

External OSPF routes for OSPF process ID 1
  Prefix Cost Tag ASBR Forward addr
> 10 E1 1 2000 E1 1
> 5 E2 2 200 E2 2

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 [64] via, Serial1/2, ASBR, Area 1, SPF 2
i [64] via, Serial1/1, ABR, Area 1, SPF 2
i [64] via, Serial1/0, ABR, Area 1, SPF 2
    Inter-area Router Path List
I [128] via, Serial1/0, ASBR, Area 1, SPF 2

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

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


  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

  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?

  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 i gather that Cisco Disabled RFC1583Compatibility by default on its NX-OS, and at last actually implemented RFC2178 and RFC2328.

    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!


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.