OSPF external path selection

I ran into some unexpected behavior regarding OSPF external path selection recently and am having trouble fully understanding the results.

Starting with the v5 Basic OSPF Routing topology, I made the following changes:

  • On R4, create a loopback (1.1.1.1/32) and redistribute into OSPF
  • On R10, create a loopback (1.1.1.1/32) and redistribute into OSPF
  • On R5's ethernet (not tunnel) link to R4, change the OSPF cost to 2

The result was to have an equal forward-metric path to two ASBRs from the perspective of R2, one intra-area (R4) and one inter-area (R10). I was using this as a base for some self-study to reinforce OSPF route selection concepts.

Based on information in the ATC videos and labs, I expected R2 to chose the route to R4 as preferred as the videos and the "OSPF Path Selection Challenge" lab indicate that external paths to intra-area ASBRs will always be preferred. What I found was that R2 chose the path to R10 (the inter-area path) and installed only that route in the RIB. R5 installed both paths using ECMP. If I changed R10's router ID to be lower than R4's, R2 would change it's decision to use the path to R4.

I found this post among others which indicates Cisco IOS uses RFC 1583 (not RFC 2328) for external path selection which treats intra- and inter-area paths equally. I set up another topology with equal-cost intra- and inter-area paths that agrees with this.

The remaining question is why R2 in this case installs only one of the routes. The only answer that I can come up with is the fact that the next hop is same for both paths. From RFC 1583 16.4(4):

(4) Next, look up the routing table entry for the destination N.
If no entry exists for N, install the AS external path to N,
with next hop equal to the list of next hops to the
forwarding address, and advertising router equal to ASBR.

Question 1: Since R2's next hop is R5 for both paths, is it only installing one route due to the "list of next hops" having only R5?

Question 2: RFC 1583 16.8 (Equal-cost multipath) notes:
Each one of the multiple routes will be of the same type
(intra-area, inter-area, type 1 external or type 2 external),
cost, and will have the same associated area. However, each
route specifies a separate next hop and Advertising router.

I have a separate case where an IOS router is installing multiple equal-cost routes: one intra-area and the other inter-area. Is this a vendor-specific implementation of ECMP or am I reading the RFC incorrectly?

Thanks for any clarification!

Comments

  • Hi,

    1. "I found this post among others which indicates Cisco IOS uses RFC 1583 (not RFC 2328) for external path selection which treats intra- and inter-area paths equally." I'm gonna fully reply to that post when i have the time, as it is a long reply; it's unfortunate that actually IOS and IOS-XE, by default it runs in RFC2328 compatible-mode, but the end result is that it's partially compliant with RFC1538 and partially with RFC2328.

    2. " Since R2's next hop is R5 for both paths, is it only installing one route due to the "list of next hops" having only R5?" This is not specific to OSPF, same behaviour is for any IGP, the NH of an IGP route installed in the RIB HAS to be a directly connected NH/router, because IGP's are single-hop and to validate the NH the router does a single recursive-lookup to find the egress interface. So now if you understand this, and yes the actuall NH for both paths is R5, what would be the benefit to install in the RIB two OSPF routes for the same destination with the same NH of R5? It doesn't make sense, so this is why you see only one entry in the RIB.

    Regards,

    Cristian.

  • Thanks for your time and info. Makes perfect sense

    I look forward to your reply to the other post if you get time to share. Researching some OSPF path selection topics uncovered several documents and online discussions regarding RFC adherance for both IOS and NX-OS which I found quite interesting. It may have been a bit of a diversion from core study but it was valuable in understanding operational differences between the RFCs and situations that can occur between devices using different RFC mechanisms.

Sign In or Register to comment.