The Potential for Asymmetric Routing with Multi-Area ISIS
Last updated
Last updated
In this article we will explore the how L1 routers choose the path to inter-area prefixes, and how this can easily lend itself to asymmetric routing in certain conditions.
By following along with this article, I hope that you will gain a better understanding of how L1 inter-area routing works.
ISIS treats L1 as a totally NSSA area in OSPF. This is because L1 routers can inject prefixes, and L1/L2 routers hide inter-area routes, only “sending” a default. I put “sending” in quotes, because L1/L2 routers actually just set the attached bit on their L1 LSP, which L1-only routers use to create a default route to the L1/L2 routers.
To demonstrate the conditions that lend itself to asymmetric routing, we’ll use this topology:
All links have a default metric of 10, except for the link between R1-R2 (50) and R5-R6 (20)
Here are the startup configs:
Before we look at asymmetric routing, I’d like to point out a few things that I think are worth looking at:
We are using the default narrow-metrics which means an interface can have a max cost of 63. This is because the cost field is 6 bits (2^6 - 1 = 63). However, the total path metric can be more than 64. The total path is limited to a max of 1023. R2 currently has a path that is a metric of 70 to 3.3.3.3/32:
Routers will prefer intra-area routes over inter-area routes. Notice that R2 has a lower cost path to 3.3.3.3/32 via R4. This path would be 60, which is lower than the intra-area path’s metric of 70.
Let’s examine the routers’ paths to other router’s loopback addresses. Using the diagram, try to count how many total asymmetric paths there are, for only destinations to loopback IPs. Each router will have 5 different paths you will examine (for example, examine R1’s paths to 2.2.2.2/32, 3.3.3.3/32, 4.4.4.4/32, 5.5.5.5/32, and 6.6.6.6/32)
We only need to take a look at the first three routers, R1-R3, as any asymmetric paths they have to R4-R6 would just be redundant to list them for R4-R6 as well.
R1 has two asymmetric paths (4.4.4.4/32 and 6.6.6.6/32)
R1 takes the path R1-R3-R5-R6-R4 to R4, but R4 takes the path R4-R2-R1 back to R1.
R2 has one asymmetric path (5.5.5.5/32)
R3 has two asymmetric paths (4.4.4.4/32, 6.6.6.6/32)
There are two things going on that cause this asymmetrical routing to happen:
The discontiguous L2
The “totally NSSA” nature of L1
If you noticed that the L2 is discontigous, great job! The L2 is currently partitioned in two, R2-R4 and R3-R5. This is actually a broken design, because the L2 must be contiguous.
Right now R4 only knows 49.0001 prefixes via R2, and vice versa. Likewise for R5 and R3.
R4 has a better route to 3.3.3.3, but it has no idea that there is a path through R5.
Before we fix the L2 discontinuity, let’s see what happens if we simply leak L2 routes into L1 on all L1/L2 routers. On IOS-XE we must reference a route-map when leaking level-2 routes into level-1. On IOS-XR this is not required.
One interesting thing to notice is that L2 prefixes which had a cumulative metric over 63 now have to be advertised as a single metric of 63:
Let’s check R4’s route to 3.3.3.3/32 now. Will it be the inter-area path via R5, or the L2 path via R2?
The path is still the L2 path via R2, even though the metric (73) is larger than the inter-area path via R5 (50).
Let’s re-calculate the asymmetric paths now:
R1 has one asymmetric path (4.4.4.4/32)
6.6.6.6/32 is no longer asymmetric
R2 has one asymmetric path (5.5.5.5/32)
Same as before
R3 has one asymmetric path (4.4.4.4/32)
6.6.6.6/32 is no longer asymmetric
So we see that the leaking of L2 routes into L1 has primarily fixed the asymmetric routing for R1 and R6. Before, R1 and R6 only knew intra-area L1 routes plus a 0/0 to the L1/L2 router with the lowest metric path. Now, R1 and R6 have full knowledge of all /32 loopbacks with the associated metric. R6 can choose to use R5 to 3.3.3.3/32 and 1.1.1.1/32 now, because it knows both R4’s and R5’s cost to reach those prefixes now that they are inter-area routes. Before, all R6 knew was that the path to R5 had a higher cost than the path to R4, so R4 was used for everything that was not an intra-area route.
Let’s see if fixing the discontiguous L2 will solve the rest of our asymmetric paths.
Let’s simply add a link between R3 Gi3 and R4 Gi3:
What do you think will happen? Will there be any asymmetric routes still, and if so where are they?
There is one asymmetrical path still:
R2 to 5.5.5.5/32
This is because R4 uses the higher metric intra-area path to R5 (R4-R6-R5) instead of the shorter inter-area path (R4-R3-R5). This could be solved with another link connecting R2 to R5.
The default behaviour of L1 in ISIS causes the potential for asymmetric routing when routers have multiple exit points to the area. Think of the path from R1-R6 before we leaked L2 routes into L1. Because L1 routes by default will not see inter-area routes, they will simply use a L1/L2 router that is reachable via the lowest metric route. However, the reverse traffic may not take the same path. While this is usually not an issue, it could pose a big problem if there is some stateful device, such as a firewall, in the middle. The easiest solution to this is to leak L2 routes into L1. This gives the L1-only routers the “bigger picture” to select a path based on the full end-to-end metric (using the L1/L2 router’s metric to that prefix), instead of blindly selecting the nearest L1/L2 router for every non-intra-area destination.
