Last week I wrote part 1 of this series on how do to nasty things to OSPF's transit areas. This time we'll jump right in with two more examples, so I'd suggest starting with part 1 if you haven't read it.
And remember, all cases in this series assume that transit area capability is not enabled!
Case number 2
This example builds on Case number 1, so it's technically more like case number 1.5. Details.
I thought it would be amusing if I introduced two equal-cost paths to make matters even more chaotic. Basically, I wanted
R5 to load-balance towards
Vlan100, so I changed the cost on the
R5-R4 link to
90 - the result you can see below.
R4 has to use
R3 as its only exit point, so nothing much changes (apart from the overall cost).
R5 has two options, only they're both as desirable now: getting to
R2 costs the same:
120. It installs both routes in its routing table and the result pretty much looks like this:
R4#ping 100.100.100.100 r 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds: !.!.!.!.!. Success rate is 50 percent (5/10), round-trip min/avg/max = 60/62/68 ms
We still have a routing loop, but only half of the time. When
R4 routes a packet through
R5 decides to forward it to
R3, all's well. But there's a 50-50 chance it'll forward the packet back to
Obviously, the same solution applies: just let
capability transit do its magic and
R4 will choose
R2 as its exit towards
Area 0, thereby avoiding this "part-time" loop.
Case number 3
Now, I can hear some of you grumbling that the previous examples are far-fetched, why would you put the VL across the area like that, are you even serious about those costs... etc.
This case is a bit different, there's a partitioned backbone area now. But the most important difference here is that I haven't touched the transit area costs. The problem is hidden by an asymmetric cost out in the backbone. Quite harder to notice.
Now let's look what happens after the Virtual-Link is configured (with
capability transit disabled). You're probably saying a routing loop, obviously. And you are totally right.
R1 was already an ABR, but now, as it has an Area 0 adjacency with
R4, it can stop ignoring its LSAs and calculate some paths as internal routes. Therefore, it calculates the
Vlan600 path as
R1->R2->R4->R6 with a cost of
R3, the routers internal to Area 100, have two choices again. They get Type3 LSAs from both
R5 (with a cost of 110 and 20, respectively). So
R2, in order to get to
Vlan600, chooses the
R2->R1->R3->R5->R6 path with a cost of
And there's our loop.
For the return path (
R6->Vlan100), I'll leave it to you to answer the following questions: is it reachable? how many paths does it have? are they a loop, sub-optimal or what you'd expect?. Let me know in the comments below.
In order to fix this loop,
capability transit makes sure that
R5 as the ABR to reach
Vlan600 due to its lower cost.
Another solution that works is to bring up another Virtual-Link between
R5. More VLs, yay!
I hope you enjoyed these examples - the main thing to take away from this post is that the trouble-maker might not be where you expect it to be. In a bigger routing domain with bad (or non-existent) documentation, it can be very hard to predict and troubleshoot what happens so do your designs properly!.
We'll conclude the series with an example of why summarization is not allowed into transit areas.
And, as always, thanks for reading.