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

7 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. :)

    ReplyDelete
  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.

    ReplyDelete
  3. I'm curious as to why this is in the RFC as well. I can't see any obvious purpose.

    ReplyDelete
  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 jishnub@yahoo.com

    ReplyDelete
  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.

    ReplyDelete
  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

    ReplyDelete
  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.

    ReplyDelete

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

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.