Wow, that’s an interesting discovery. I labbed this one up and found the same result. And actually, it’s interesting that in my case the ABR chose the non-backbone route to the destination.
For some reason, it seems that OSPF will not load balance to destinations that may exist in different areas. I have been unable to find any documentation that tells us why, but there is a possibility that this behavior is Cisco-specific or even IOS-specific. RFC 2328 regarding OSPF load balancing, states the following:
There is no requirement that a router running OSPF keep track of
all possible equal-cost routes to a destination. An
implementation may choose to keep only a fixed number of routes
to any given destination. This does not affect any of the
algorithms presented in this specification.
This seems to jive with what is happening here. It would be interesting if you could experiment further to see what is used as the tiebreaker. Could it be the next hop IP address or the router ID of the advertising router? It would be an interesting experiment to undertake.
Because RFC 3101, section 2.5 Calculating Type-7 AS External Routes, point 6 (b) states:
(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.
[OSPF]
So, if the metric is lower on E2, it will be preferred over N2.
And 6. (d) also says:
(d) If the new AS external path is still indistinguishable
from the current paths in N's routing table entry, select
the preferred path based on a least cost comparison. Type
1 external paths are compared by looking at the sum of the
distance to the ASBR/forwarding addresses and the
advertised type 1 metric (X+Y). Type 2 external paths
advertising equal type 2 metrics are compared by looking
at the distance to the ASBR/forwarding addresses.
~[OSPF]
So, although Type 1 is preferred over Type-2, E1 is preferred over N1 if its metric is lower, and the same with E2 and N2.
It’s only if metrics are the same that Type-7 (N1 and N2) are preferred over Type-5 (E1 and E2), as per the next step:
(e) If the current LSA is functionally the same as an
installed LSA (i.e., same destination, cost and non-zero
forwarding address) then apply the following priorities in
deciding which LSA is preferred:
1. A Type-7 LSA with the P-bit set.
2. A Type-5 LSA.
3. The LSA with the higher router ID.
I have confirmed this with labs, but please correct me if I am wrong.
Yes, you are correct. I believe a more correct way of stating the overall order of preference of route types for OSPF becomes:
Intra-Area Paths (O)
Inter-Area Paths (O IA)
External Type 1 (E1) Paths / NSSA Type 1 (N1) Paths
External Type 2 (E2) Paths / NSSA Type 2 (N2) Paths
Within the same path-type category (like E1/N1 or E2/N2), OSPF will prefer the path with the lower metric. Only when the metric is the same will type E1 be preferred over N1, and type E2 be preferred over N2.
I will let Rene know so he can consider updates to the lesson. Thanks for sharing your thoughts and your experimentation with us!
Both the error in the previous post you quoted, as well as the one you are seeing is actually expected behavior. Within the lesson, Rene has added the following note:
Since Cisco IOS release 15.1(2)S, Cisco uses the path selection order from RFC 3101, which obsoletes RFC 1587. This means that it prefers N1 routes before E1 and N2 over E2 routes. In other words, the preferred path list is O > O IA > N1 > E1 > N2 > E2.
So it looks like you are using IOS release 15.1(2)S or later, and if so, that is why you are seeing the N1 routes before the E1 routes. Similarly, you’ll see the N2 routes being selected before the E2 routes. Does that make sense?
Take a look at this NetworkLessons note on OSPF Path Selection for more details.