This post will discuss the Transit Capability feature that is enabled by default in OSPFv2 and above. To understand the transit capability, the network needs a virtual-link involved. So I have pre-configured the network shown in the diagram below ready for the virtual-link to be configured. OSPF been configured with just with a very basic config to get the areas up and running. I have also configured all interfaces to use an ospf cost of 1, with the only exception that R4’s Gi1.46 interface is set with an interface cost of 10,000.

OSPF-Transit-Capability

Note: All router-id’s have been configured relative to their router number. EG: R6’s Router-ID is 6.6.6.6. All interfaces IP addresses also finish the latest octect relative to their router number. EG: R6’s Gi1.46 interface is 10.0.46.6.

As you can see, we need to build a virtual link over area 1 so that area 2 can function in OSPF properly.

R4(config)#router ospf 1
R4(config-router)#area 1 virtual-link 6.6.6.6

R6(config)#router ospf 1
R6(config-router)#area 1 virtual-link 4.4.4.4
So now if we check the ospf routes on R5, we should have everything in the network.

R5#sh ip route ospf | b Gate
Gateway of last resort is not set

9.0.0.0/32 is subnetted, 1 subnets
O IA 9.9.9.9 [110/10002] via 155.1.45.4, 00:10:58, GigabitEthernet1.45
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA 10.0.14.0/24 [110/2] via 155.1.45.4, 00:12:05, GigabitEthernet1.45
O IA 10.0.17.0/24 [110/3] via 155.1.45.4, 00:12:05, GigabitEthernet1.45
O IA 10.0.46.0/24
[110/10001] via 155.1.45.4, 00:12:05, GigabitEthernet1.45
O IA 10.0.47.0/24 [110/2] via 155.1.45.4, 00:12:05, GigabitEthernet1.45
155.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
O IA 155.1.67.0/24
[110/10002] via 155.1.45.4, 00:10:58, GigabitEthernet1.45
And we do. Here’s where the good bit starts. Let me first explain some basics.

The basics

OSPF operates in a two level heirarchy; Area 0 (backbone) and not area 0 (non-backbone). When a router in a non-backbone area needs to communicate to a link in another non-backbone area in a normal design, the path should go via area 0 to reach the prefix. As per the RFC2328, it states “The backbone is responsible for distributing routing information between non-backbone areas.” Furthermore, when routing between areas the RFC states “When routing a packet between two non-backbone areas the backbone is used”.

In my design, this would mean then, that for R5 to reach 9.9.9.9/32, it should hit R4, then R4 should traverse the virtual-link to area 0 and hit R6 in order to reach the prefix. If we check this out, we can see that this is actually not the case:

R5#traceroute 9.9.9.9
Type escape sequence to abort.
Tracing the route to 9.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.45.4 3 msec 1 msec 1 msec
2 10.0.47.7 1 msec 1 msec 1 msec
3 155.1.67.6 1 msec * 2 msec
If we check the routing table on R4, we can see that it’s actually preferring the shorter path via R7.

R4#sh ip route 9.9.9.9
Routing entry for 9.9.9.9/32
Known via “ospf 1”, distance 110, metric 3, type intra area
Last update from 10.0.47.7 on GigabitEthernet1.47, 00:00:24 ago
Routing Descriptor Blocks:
* 10.0.47.7, from 6.6.6.6, 00:00:24 ago, via GigabitEthernet1.47
Route metric is 3, traffic share count is 1
The reason why is because of a feature called “capability transit”, which is enabled by default in OSPFv2 and above. To understand what’s happening, you need to read the next bit below.

Transit Capability

When we are using a virtual link, as per my network above, area 1 actually becomes a transit area for traffic passing from area 0 to area 2. When the “TransitCapability” is actually enabled (default setting in OSPFv2), the RFC specifically states:

“When area border routers connecting to one or more transit areas (i.e, non-backbone areas whose TransitCapability is found to be TRUE), the transit areas’ summary-LSAs are examined to see whether better paths exist using the transit areas [vs the summary-LSAs advertised from the virtual-link from the backbone]”.

In my example, what this means, is that when there is a virtual-link operating from R6 (the ABR) over area 1 (area1 being the effective transit area between area 0 and area 2) and the TransitCapability is enabled: The summary-LSA for 9.9.9.9/32 that would be sent from R6 and R7 into Area 1 will be compared against the same summary-LSA sent from R6 over the virtual link & the lowest metric to reach 9.9.9.9 will win. In my case, the summary LSA sent from R7 won because the path via R4-R7-R6 is better than the summary from R4 (via R6-R4). This is because I set the R4’s Gi1.46 interface to a cost of 10,0000. Thus the cost to 9.9.9.9 via the virtual link is 10,001 vs the cost of 3 via R7; hence R7 won.

If we disable the transit capability on R4, we now have to follow the normal procedure of routing inter-area traffic from non-backbone areas via area 0. So R4 MUST choose the best path to 9.9.9.9/32 via it’s virtual link to area 0 via R6, as opposed to the path towards R7 via area 1.

R4(config)#router ospf 1
R4(config-router)#no capability transit
R4#sh ip route 9.9.9.9
Routing entry for 9.9.9.9/32
Known via “ospf 1”, distance 110, metric 10001, type intra area
Last update from 10.0.46.6 on GigabitEthernet1.46, 00:15:32 ago
Routing Descriptor Blocks:
* 10.0.46.6, from 6.6.6.6, 00:15:32 ago, via GigabitEthernet1.46
Route metric is 10001, traffic share count is 1
Notice that the metric is 10,001. This is the cost of the virtual-link (10,000) to R6 (as it inherits the interface cost of gi1.46), plus the loopback interface cost on R6 which is 1.

None of the metrics have been modified during this post, so R4 still has a summary LSA from R7 providing (the original path) to 9.9.9.9/32 with a total cost path of 3. However, since the TransitCapability is disabled, we can no longer chose the path via R7 to reach 9.9.9.9/32 because we have to follow the rule that states that if you are routing between areas, you must use area 0 for transit. The point is that we can no longer use the shorter via from R5–(area2)—>R4–(area1)—>R7–(area0)—R6 because the rules state that you must transit area0 when routing between areas. So if we look at the traceroute again on R5, we can see the best (and only) path is via R4-R6:

R5#traceroute 9.9.9.9
Type escape sequence to abort.
Tracing the route to 9.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.45.4 3 msec 1 msec 1 msec
2 10.0.46.6 6 msec * 1 msec

Summary
So the whole point of the transit capability is to allow the transit area that the virtual link operates over, to be used (you guessed it) for transit. Where specifically, when it was enabled in my topology above, it enabled traffic to be sent via a shorter path via R5-R4-R7-R6 to reach 9.9.9.9/32. The key point being here that the traffic was allowed to pass between the area 1 link between R4 and R7 rather than use the virtual-link to area0 on R4.