Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

OSPF route selection rules

OSPF implementation in Cisco IOS deviates slightly from OSPF/NSSA standards (RFC 2328 and RFC 3101). These are the OSPF route selection rules as implemented by Cisco IOS release 12.2(33)SRE1 (all recent releases probably behave identically):

Note: Update history is at the end of the post

Update history:
  • The original version of this post was published on 2008-01-17.
  • The post was updated and renamed on 2011-03-30 after a lengthy (and very productive) discussion with one of my readers.
  • 2011-04-16: Fixed the final tie-breaker part.
  • 2016-02-19: Fixed a typo - early OSPF RFC was RFC 1583, not RFC 1683

23 comments:

  1. its a good one.

    regards
    shivluy

    ReplyDelete
  2. Excelent information.

    I've been searching for this for hours, but always you just find information about E1, E2 routes and what they mean...as you said...not the whole story..

    thanks a lot/....

    ReplyDelete
  3. Anton Yurchenko31 March, 2011 02:05

    Big big thanks! I had pieces of it written down, but pieces about Cisco specific behavior are excellent finds.

    ReplyDelete
  4. I have a question about OSPF default originates.

    I have 4 ABR in once OSPF domain. Three of the ABRs are generating a OSPF default route with a metric of 200 and 1 is using a metric of 1000. The show ip ospf database external 0.0.0.0 shows that the default originate with 200 as an E2 and the default originate with the metric of 1000 as and E2 route. The ABR with a metric of 1000 is the BDR and the ABR with metrics of 200 are the DRs. The default route for clients of the DRs prefer the BDR default route with a metric of 1000 over the default of the DR with a metric of 200. Any ideas on how to fix this situation?


    Thanks,

    ReplyDelete
  5. DR/BDR doesn't matter. They just influence how updates are flooded through the network.

    Make sure all routers originate either E1 or E2 default routes (not a mix).

    ReplyDelete
  6. Can someone please tell what the tie breaker is, i have 2 routes in OSPF that are teh same but it prefers the first one when both are recieved



    192.168.5.0/24 172.17.18.2 (172.17.18.2 Rid) 20 A Oi tunnel.5
    192.168.5.0/24 172.17.19.2 (192.168.5.11 Rid) 20 A Oi tunnel.200

    ReplyDelete
  7. It is well known (and in every textbook) that in IOS intra-area through the backbone are preferred over intra-area across a nonzero area, cost notwithstanding, but I cannot find any reference for this behaviour in RFC2328. Do you know the reason for this feature (or bug)?

    One similar case where behaviour is different is identical externals from the same ASBR, which is also an ABR, received across two distinct areas from another ABR in the same areas: these are selected by cost, with possible ECM, at least in 12.4(4)T1. This seems to be consistent with section 16.4.1 of RFC2328.

    No matter how many times you read RFC2328, there is always one more case that forces you to read it again and fire up GNS3.

    ReplyDelete
  8. Well, apparently I did misread all those textbooks, and IOS follows RFC. Intra-area routes from two different areas (a corner case not as easy to see as I previously believed) are treated by the ABR exactly as externals, selected by cost with possible ECM.

    ReplyDelete
  9. Ivan I have a comment here :

    Inter-area routes are preferred over external routes; see Section 16.2 paragraph (5) of the OSPF RFC.

    This is 100% true :)
    In case of redistribution, an O-E2 Route can be preferred over an O route ... :(

    Quote from :
    http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml#routepref

    "The OSPF route selection rule is that intra-area routes are preferred over inter-area routes, which are preferred over external routes. However, this rule should apply to routes learned via the same process. In other words, there is no preference between external routes from one process compared to internal routes of other process."


    I don't want to flood your blogpost but this is the result of the test:

    O E2 1.1.1.1 [110/20] via 23.0.0.2, 00:00:16, FastEthernet0/1

    Type-5 AS External Link States

    Link ID ADV Router Age Seq# Checksum Tag
    1.1.1.1 1.1.1.1 1307 0x80000001 0x009BFC 0

    R2(config-router)#distance ospf intra-area 109

    O 1.1.1.1 [109/11] via 12.0.0.1, 00:00:09, FastEthernet0/0



    Hope you enjoy the sharing !

    See ya !


    Nic


    ReplyDelete
  10. Does only ABR sends default route to neighbor , while we enable default originate ?
    or it is not specific.

    ReplyDelete
    Replies
    1. Any router can originate E1 or E2 default route (unless it's in a stub area). On top of that, ABR would originate default route into stub/NSSA areas.

      Delete
  11. I'm trying this out on junipers and cannot explain this

    Area 0 Area 1

    ---------------R2 ( ABR ) --------------------
    R1 R4
    ---cost 100----R3 ( ABR and ASBR ) ------------
    E1 Redistibuted at R3

    Costs not indicated are 1

    the route from R1 to E1 will always be the highcost direct link

    I can only conclude that R1 prefers this link as it considers ASBR as in its own area
    but I cannot find this documented in the RFC
    do you have any idea ?

    ReplyDelete
  12. Hi! Article need update. In Cisco IOS Release 15.1(2)S and later releases, RFC 3101 replaces RFC 1587, and RFC 3101 behavior is automatically enabled.

    ReplyDelete
  13. Hi Ivan,

    When you say " Cisco IOS ignores this rule even after configuring no compatible rfc1683 (Section 16.4.1 of the OSPF RFC)" it should say " Cisco IOS ignores this rule even after configuring no compatible rfc1583 (Section 16.4.1 of the OSPF RFC)"

    Apart from this, thanks for the post!

    ReplyDelete
  14. Hello Ivan,

    i think that N2P=1 routes are preferred over E2 routes, which are preferred over N2P=0 routes. P is the P-bit.
    This behaviour is actually a bit more compliant with RFC3101, Section 2.5, (6)(e).
    i believe i have verified this with IOS 15.2(4)M2 in gns3.

    ReplyDelete
    Replies
    1. Yes, I did so also.

      This is the part confirming this:

      N2 route is preferred over E2 route

      R4#sh ip ospf database external

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

      Type-5 AS External Link States

      LS age: 12
      Options: (No TOS-capability, DC, Upward)
      LS Type: AS External Link
      Link State ID: 100.100.100.0 (External Network Number )
      Advertising Router: 4.4.4.4
      LS Seq Number: 80000001
      Checksum: 0x8871
      Length: 36
      Network Mask: /24
      Metric Type: 2 (Larger than any link state path)
      MTID: 0
      Metric: 18
      Forward Address: 192.168.1.1
      External Route Tag: 0

      LS age: 18
      Options: (No TOS-capability, DC, Upward)
      LS Type: AS External Link
      Link State ID: 100.100.100.0 (External Network Number )
      Advertising Router: 5.5.5.5
      LS Seq Number: 80000007
      Checksum: 0x1348
      Length: 36
      Network Mask: /24
      Metric Type: 2 (Larger than any link state path)
      MTID: 0
      Metric: 18
      Forward Address: 0.0.0.0
      External Route Tag: 0

      R4#sh ip ospf database nssa-external

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

      Type-7 AS External Link States (Area 1)

      Routing Bit Set on this LSA in topology Base with MTID 0
      LS age: 79
      Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
      LS Type: AS External Link
      Link State ID: 100.100.100.0 (External Network Number )
      Advertising Router: 1.1.1.1
      LS Seq Number: 8000000A
      Checksum: 0x3CB6
      Length: 36
      Network Mask: /24
      Metric Type: 2 (Larger than any link state path)
      MTID: 0
      Metric: 18
      Forward Address: 192.168.1.1
      External Route Tag: 0

      R4#sh ip ospf border-routers

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


      Base Topology (MTID 0)

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

      i 1.1.1.1 [2] via 192.168.1.1, GigabitEthernet1/0, ASBR, Area 1, SPF 28
      i 5.5.5.5 [2] via 192.168.47.7, GigabitEthernet3/0, ASBR, Area 0, SPF 7
      i 2.2.2.2 [2] via 192.168.47.7, GigabitEthernet3/0, ABR/ASBR, Area 0, SPF 7
      i 2.2.2.2 [2] via 192.168.1.2, GigabitEthernet1/0, ABR/ASBR, Area 1, SPF 28
      i 3.3.3.3 [2] via 192.168.47.7, GigabitEthernet3/0, ABR/ASBR, Area 0, SPF 7
      i 3.3.3.3 [2] via 192.168.1.3, GigabitEthernet1/0, ABR/ASBR, Area 1, SPF 28

      R4#sh ip route 100.100.100.100
      Routing entry for 100.100.100.0/24
      Known via "ospf 1", distance 110, metric 18, type NSSA extern 2, forward metric 2
      Last update from 192.168.1.1 on GigabitEthernet1/0, 00:00:50 ago
      Routing Descriptor Blocks:
      * 192.168.1.1, from 1.1.1.1, 00:00:50 ago, via GigabitEthernet1/0
      Route metric is 18, traffic share count is 1

      Delete
    2. Yes, I agree. I have confirmed this hereunder on the same IOS train:

      N2 route is preferred over E2 route

      R4#sh ip ospf database external

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

      Type-5 AS External Link States

      LS age: 12
      Options: (No TOS-capability, DC, Upward)
      LS Type: AS External Link
      Link State ID: 100.100.100.0 (External Network Number )
      Advertising Router: 4.4.4.4
      LS Seq Number: 80000001
      Checksum: 0x8871
      Length: 36
      Network Mask: /24
      Metric Type: 2 (Larger than any link state path)
      MTID: 0
      Metric: 18
      Forward Address: 192.168.1.1
      External Route Tag: 0

      LS age: 18
      Options: (No TOS-capability, DC, Upward)
      LS Type: AS External Link
      Link State ID: 100.100.100.0 (External Network Number )
      Advertising Router: 5.5.5.5
      LS Seq Number: 80000007
      Checksum: 0x1348
      Length: 36
      Network Mask: /24
      Metric Type: 2 (Larger than any link state path)
      MTID: 0
      Metric: 18
      Forward Address: 0.0.0.0
      External Route Tag: 0

      R4#sh ip ospf database nssa-external

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

      Type-7 AS External Link States (Area 1)

      Routing Bit Set on this LSA in topology Base with MTID 0
      LS age: 79
      Options: (No TOS-capability, Type 7/5 translation, DC, Upward)
      LS Type: AS External Link
      Link State ID: 100.100.100.0 (External Network Number )
      Advertising Router: 1.1.1.1
      LS Seq Number: 8000000A
      Checksum: 0x3CB6
      Length: 36
      Network Mask: /24
      Metric Type: 2 (Larger than any link state path)
      MTID: 0
      Metric: 18
      Forward Address: 192.168.1.1
      External Route Tag: 0

      R4#sh ip ospf border-routers

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


      Base Topology (MTID 0)

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

      i 1.1.1.1 [2] via 192.168.1.1, GigabitEthernet1/0, ASBR, Area 1, SPF 28
      i 5.5.5.5 [2] via 192.168.47.7, GigabitEthernet3/0, ASBR, Area 0, SPF 7
      i 2.2.2.2 [2] via 192.168.47.7, GigabitEthernet3/0, ABR/ASBR, Area 0, SPF 7
      i 2.2.2.2 [2] via 192.168.1.2, GigabitEthernet1/0, ABR/ASBR, Area 1, SPF 28
      i 3.3.3.3 [2] via 192.168.47.7, GigabitEthernet3/0, ABR/ASBR, Area 0, SPF 7
      i 3.3.3.3 [2] via 192.168.1.3, GigabitEthernet1/0, ABR/ASBR, Area 1, SPF 28

      R4#sh ip route 100.100.100.100
      Routing entry for 100.100.100.0/24
      Known via "ospf 1", distance 110, metric 18, type NSSA extern 2, forward metric 2
      Last update from 192.168.1.1 on GigabitEthernet1/0, 00:00:50 ago
      Routing Descriptor Blocks:
      * 192.168.1.1, from 1.1.1.1, 00:00:50 ago, via GigabitEthernet1/0
      Route metric is 18, traffic share count is 1

      Delete
  15. Hello Ivan,

    I'm testing E2 routes selection with Cisco IOS Version 15.4(2)T4. The purpose is to get clear understanding of OSPF E2 selection (and perhaps implementation bugs).

    The topology is the following:


    R1(ASBR) =(192.168.1.0/24, area 0)= R2 =(192.168.2.0/24, area 1)= R3 (ASBR)
    ||
    R4
    IP @ as follloing:
    R1 - 192.168.1.1
    R2 - 192.168.1.12, 192.168.2.12
    R3 - 192.168.2.3
    R4 - 192.168.2.23

    Router R4 is in network 192.168.2.0/24 (if the schema below corrupts during comment posting)

    R1 advertises E2 prefix with metric 19, R3 advertises same prefix with metric 20.

    R4 chooses route towards R1.

    R4#show ip route
    Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
    D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    E1 - OSPF external type 1, E2 - OSPF external type 2
    i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
    ia - IS-IS inter area, * - candidate default, U - per-user static route
    o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
    a - application route
    + - replicated route, % - next hop override

    Gateway of last resort is 192.168.2.12 to network 0.0.0.0

    O*E2 0.0.0.0/0 [110/19] via 192.168.2.12, 00:07:06, Ethernet0/0
    O IA 192.168.1.0/24 [110/20] via 192.168.2.12, 00:07:06, Ethernet0/0
    192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
    C 192.168.2.0/24 is directly connected, Ethernet0/0
    L 192.168.2.23/32 is directly connected, Ethernet0/0

    R4#show ip ospf database external

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

    Type-5 AS External Link States

    Routing Bit Set on this LSA in topology Base with MTID 0
    LS age: 1456
    Options: (No TOS-capability, No DC, Upward)
    LS Type: AS External Link
    Link State ID: 0.0.0.0 (External Network Number )
    Advertising Router: 192.168.1.1
    LS Seq Number: 80000003
    Checksum: 0x84CD
    Length: 36
    Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    MTID: 0
    Metric: 19
    Forward Address: 0.0.0.0
    External Route Tag: 0

    LS age: 850
    Options: (No TOS-capability, No DC, Upward)
    LS Type: AS External Link
    Link State ID: 0.0.0.0 (External Network Number )
    Advertising Router: 192.168.2.3
    LS Seq Number: 80000005
    Checksum: 0x77D4
    Length: 36
    Network Mask: /0
    Metric Type: 2 (Larger than any link state path)
    MTID: 0
    Metric: 20
    Forward Address: 0.0.0.0
    External Route Tag: 0

    R4#


    The 4th rule above states that:

    "External routes received from an intra-area ASBR should be preferred over external routes received from ASBRs in other areas. Cisco IOS ignores this rule even after configuring no compatible rfc1583 (Section 16.4.1 of the OSPF RFC)"

    This rule doesn't go well with what I see. It seems to me that multiple ASBRs is a different setup if to compare to multiple path to one ASBR.
    With multiple ASBR the rules should have the following order:
    1) When comparing E2 routes, only the external costs are compared, Section 16.4 paragraph (6.b)
    2) (if we still can't select the best) External routes received from an intra-area ASBR should be preferred over external routes received from ASBRs in other areas, Section 16.4.1 takes it's turn.

    What do you think to this point?

    Thanks in advance.

    Pavel

    ReplyDelete
  16. I would recommend you set up the topology of Figure 19 of Appendix G.7 of RFC 2178 with IOS 15.4(2)T, and explicitly disable rfc1583 compatibility with the `no compatible rfc1583` command.
    Then issue the following commands on A1 and B1:
    sh ip ospf rib 10.0.0.0

    You will see that for each router,
    the next hop for 10.0.0.0/8 is the other router.

    ReplyDelete
  17. Hello Wizard,

    Thanks for your reply. I have read Appendix G.7 of RFC 2178 before and it doesn't give the answer to my question.

    We consider situations only with RFC1583Compatibility = disabled.

    Appendix G.7 of RFC 2178 talks about one ASBR but we have two ASBRs. This is a crucial difference to my mind and we have 2 options here.

    1/ If we have 1 ASBR and 2 paths to ASBR (this is not our case)
    In this case RFC 2328 16.4(3) pruning procedure kicks in according to Section 16.4.1:

    (3) ...
    If the forwarding address is set to 0.0.0.0, packets should
    be sent to the ASBR itself. Among the multiple routing table
    entries for the ASBR, select the preferred entry as follows. <<< true, we have 2 path to ASBR
    If RFC1583Compatibility is set to "disabled", prune the set <<< pruning takes place
    of routing table entries for the ASBR as described in
    Section 16.4.1. In any case, among the remaining routing
    table entries, select the routing table entry with the least
    cost; when there are multiple least cost routing table
    entries the entry whose associated area has the largest OSPF
    Area ID (when considered as an unsigned 32-bit integer) is
    chosen.

    P. 16.4.1 decides which patch is the best according to the rule:

    "Intra-area paths using non-backbone areas are always the
    most preferred."



    2/ If we have 2 ASBR and 2 paths to ASBRs, i.e. 1 path to each ASBR (this is our case)

    In this case RFC 2328 16.4(3) pruning procedure DOESN'T kick and Section 16.4.1 is not applied at this step:

    (3) ...
    If the forwarding address is set to 0.0.0.0, packets should
    be sent to the ASBR itself. Among the multiple routing table
    entries for the ASBR, select the preferred entry as follows. <<< false, we have 1 path to ASBR
    If RFC1583Compatibility is set to "disabled", prune the set <<< pruning doesn't take place
    of routing table entries for the ASBR as described in
    Section 16.4.1. In any case, among the remaining routing
    table entries, select the routing table entry with the least
    cost; when there are multiple least cost routing table
    entries the entry whose associated area has the largest OSPF
    Area ID (when considered as an unsigned 32-bit integer) is
    chosen.

    As soon as 16.4.1 doesn't kick in we use 16.4(6)(b) to select the best E2 route


    16.4(6)(b) ...
    Type 1 external paths are always preferred over type 2
    external paths. When all paths are type 2 external
    paths, the paths with the smallest advertised type 2
    metric are always preferred.



    Makes sense?

    BR

    ReplyDelete
  18. You are almost 100% in your original post with the two rules at the end, but i would correct them to the following:

    With multiple ASBRs, the rules for selecting the AS-external LSA that will be preferred are the following:
    1) When comparing E2 routes, only the external costs (E2 metric value) are compared, as per Section 16.4 paragraph 6.b
    2) If we still can't select the best, it means that the external cost has tied. External routes received from a non-backbone intra-area ASBR should be preferred over external routes received from ASBRs in other areas, as per Section 16.4.1.

    I am not sure which network you are talking about in your latest reply, but i will assume you are talking about the network in G.7 of RFC 2178. In this network, we have A1 selecting one of the two AS-external LSAs it has received, and then we have B1 making a similar decision. Both AS-external LSAs have the same E2 metric. Both routers have the same two AS-external LSAs in their LSDB:

    1. from A3, and
    2. from B3

    First, we will examine A1:

    The forwarding cost to reach A3 (from A1) is 6. The forwarding cost to reach B3 is 4 (as advertised by B2). As per RFC 2328, section 16.4 (6)(d), the least forwarding cost will be preferred:

    Type 2
    external paths advertising equal type 2 metrics are
    compared by looking at the distance to the forwarding
    addresses.

    A1 does not distinguish between A3 (which is a backbone intra-area ASBR) and B3 (which is an inter-area ASBR).

    Therefore, A1 will prefer routing to B3 via B1.

    Now let's look at B1:

    B1 has one path to B3, and one path to A3:

    1. cost of intra-area path to B3: 8
    2. cost of intra-area path to A3: 7

    According to RFC1583 rules, B1 will prefer to use the path to A3, causing a loop.

    Now assume that the algorithm from RFC 2328 is used, and B1 installs the path to network N (10.0.0.0/8) into the OSPF RIB via A3 (because the AS-external LSA from A3 was examined first).
    Now B1 examines the next AS-external LSA that it has received from B3:

    steps 16.4(1) and 16.4(2) are false, so we start examining the third paragraph of 16.4(3):

    There is a single routing table entry for the ASBR, so the set of routing table entries is NOT pruned. At this point, you are correct. Then, we move to step 16.4(6) where we examine if the path via A3 which is already in the OSPF routing table will be replaced by the path via B3:

    (a) Both entries are AS external paths - no replacement
    (b) Both AS-external LSAs advertise equal E2 costs - no replacement
    (c) This step says:

    select the preferred paths based on the intra-AS paths to the
    ASBR/forwarding addresses, as specified in Section 16.4.1. <<<<<< This step assumes that there are two paths. Because at this point, you must be comparing two different paths, to two separate ASBRs.

    We have to go to section 16.4.1 to select one of the two intra-area ASBRs:
    According to 16.4.1:
    The Intra-area path to an ASBR using the non-backbone area is preferred to the intra-area backbone path to another ASBR. The intra-area path to B3 is preferred to the backbone path to A3, and so the routing table entry to N via A3 gets replaced.

    To find the implementation "bug" in IOS, set up the RFC2178/G.7 network, and watch IOS create a routing loop. And keep in mind that this is not a bug. When contacting Cisco TAC, the boilerplate answer you will get is either:

    1. Upgrade to NX-OS or IOS-XE
    2. Do not create this weird scenario
    3. Configure Multi-Area Adjacency (RFC 5185) between B1-B2

    I am not clear as to what your point is, or what exactly you are asking. Do you believe that IOS *does* implement RFC 2328 precisely? Because it does not. Again, just watch the loop that was supposed to not exist (because of section 16.4.1) appear when you set up the RFC2178/G.7 network.

    Best Regards,
    Angelos Vassiliou @ipmess

    ReplyDelete
  19. Hi, Wizard!

    Thanks for such a great answer!

    My initial problem was to understand how OSPF E2 route selection should work according to RFC. Since there were multiple RFCs, RFCs not clearly written (my personal opinion), and there are some bugs in implementation from different vendors it is hard to inderstand why routing loops appear.


    In particular I was investigating how E2 route selection works in a sample network.

    Sample network topology as below:

    R1(ASBR) =(192.168.1.0/24, area 0)= R2 =(192.168.2.0/24, area 1)= R3 (ASBR)

    Router R4 is in network 192.168.2.0/24 (router on a stick)


    IP @ as follloing:
    R1 - 192.168.1.1
    R2 - 192.168.1.12, 192.168.2.12
    R3 - 192.168.2.3
    R4 - 192.168.2.23


    R1 advertises default route with E2 metric 19
    R3 advertises default route with E2 metric 20

    R4 is router-under-test.

    While testing I got that R4 chooses E2 route with metric 19, i. e. route from ASBR R1 that is in another area (route from intra-area ASBR R3 appeared to be worse).


    Here is why this Ivan's post confused me a lot. If to look from R4 perspective and read route selection rules from top to bottom we hit rule #4:

    "External routes received from an intra-area ASBR should be preferred over external routes received from ASBRs in other areas"

    According to this rule R4 should select E2-route with metric 20, but that is not true in practice. Seems like the rule assumes that E2 metrics are the same or it is not in its place (has wrong order).

    In my case it doesn't seem that we faced some Cisco bug. Perhaps that there are some implementation bugs that make RFC2178/G.7 network to fail but in my case Cisco seems to work according to RFC. I have also tested Juniper vMX and it behaves the same as Cisco.


    Your last post made me thinking that my understaning was correct.

    Thanks again!

    BR

    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.

Sidebar