Understanding OSPF Transit Capability
The feature we are going to talk about today may look a bit convoluted, but it demonstrates core OSPF behavior: combining link-state and distance-vector behaviors. The command capability transit was introduced in IOS 12.3T and is on by default. However, the description is rather confusing and does not explain the underlying mechanics. We are going to give an in-depth look to this feature now.
What is Transit Capability?
In short, this is a special property of non-backbone area that allows this area to transport traffic for other areas (either zero or non-zero). Per the OSPF definition, a transit area is the area that has a virtual-link connecting two or more ABRs attached to this area. Thus, having a virtual-link provisioned across the area is the necessary thing to make the area transit. In fact, it’s just an alternate definition of a transit area. So the first thing we want to find out is what kind of thing is virtual-link?
What are virtual-links
The idea of virtual link is to extend area 0 across non-backbone areas. There are two main situations when you may want to do this:
1) Due to design considerations, where you have an area not directly connected to the backbone area. This could be a result of two networks merging together. An example is when you have to connect two previously disconnected backbone areas. The purpose, of course, is allowing two OSPF topologies to exchange routing information dynamically.
2) Using a non-backbone area to reach destinations in other areas. The main idea of OSPF inter-area routing is that all areas should be communicating across the backbone area 0. The backbone area is used to exchange the routing information in distance-vector manner, requiring the star-topology to avoid routing loops. Per the RFC, the router is only considered an ABR if it has an interface in Area 0 and ignore summary LSA delivered across the non-backbone areas. This ensures the simple loop-less star topology. Look at the diagram below. Here the paths between R4 and R5 and R2 and R5 are “slow” and OSPF metrics reflect this. The fastest way for R4 to reach the subnet 163.X.12.0/24 is to go over the FR cloud to R3 and then to R1.
However, in reality, in order for R4 to reach the subnet 163.X.12.0/24, it needs to traverse across the “slow” Serial link to R5 as this is where Area 0 is. Even though Area 1 provides a shorter path, R3 will never advertise it as it does not have an interface in area zero, and R5’s summary sent into area 1 will be ignored in favor of the summary received via area 0! The way to avoid this is by providing a virtual link between R4 and R5, or R4 and R3 or both of these links. Let’s see how this allows for lifting the restriction of ignoring the inter-area routes received via non-backbone area.
How virtual-links work
Virtual links are seen as point-to-point links in the topology graph, belonging to area 0. When you configure the virtual link you specify the transit area and the endpoint router-ids. Based on the router-ids and intra-area shortest-path tree the path for the virtual link is calculated and the hello packets (unicast!) are exchanged. After this, OSPF follows the regular adjacency establishment process. This adjacency is treated at P2P like we mentioned above and used to exchange OSPF LSAs.
However, virtual-links are only used to flood specific LSAs: the router, network and summary LSAs found in area 0. Type 5 LSAs on contrary are NOT flooded across the virtual links. Here is the reason why. As you know, type 1,2,3 and 4 LSAs have the flooding scope of one area. Thus if you have a virtual link connecting 2 ABRs, you cannot flooding the LSAs across the transit area, as this area is different from Area 0. Thus, that type 1-4 LSAs need to be flooded across. On contrary, external LSAs have the flooding scope of the OSPF AS, and thus they are flooded across the area anyways (unless it’s stub) so there is no need in replicating them across the virtual link.
After the LSAs have been loaded across the virtual link, they could be used to populate the routing table. Initially all the prefixes learned are assigned the next hop of “virtual-link” which should be resolved to something physical. Here is where it becomes confusing. As the LSAs have been received over a P2P link connecting two ABRs, it makes sense to avoid SPF calculations and simply put the prefixes in the routing table using the metric X+Y where X is the cost of reaching the other ABR and Y is the cost the other ABR advertises for this prefix. This is what OSPFv1 did and what Cisco IOS was doing prior to the support of “transit capability” found in OSPFv2.
Thus in case of OSPFv1 (or OSPFv2 + no capability transit) and the diagram above, if you provision a virtual-link between R4 and R5, R4 will be able to reach the prefixes across Area 1 following the same path that the virtual link takes. What if we want to use the PVC R4-R3 that has more bandwidth than the PVC to reach R5? You’ll have to provision a virtual-link R4 to R3 then. Could you use a daisy-chained virtual-link as follows: R4-R5-R3? You could, but then R4 will choose to reach the 163.X.12.0/24 subnet across R5, as it has to follow the virtual-link path! Even though in this case R3 will inject a summary LSA for 163.X.12.0/24 into Area 1 as an ABR, R4 will learn this prefix via the virtual-link to R5 and use the path via this ABR. Here is an example: R3, R4 and R5 are configured for OSPFv2 but all have “capability transit” disabled. There is a daisy chain of links R4->R5->R3 configured. Router R4 will prefer using the path across R5, even though the shortest path would be across R3 and R3 advertises the corresponding summary into Area 1!
Virtual links are provisioned b/w R3-R5 and R4-R5
R5#show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 150.1.3.3 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 1, via interface Serial0/0/0, Cost of using 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:01
Adjacency State FULL (Hello suppressed)
Index 3/6, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Virtual Link OSPF_VL0 to router 150.1.4.4 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 1, via interface Serial0/0/0, Cost of using 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Adjacency State FULL (Hello suppressed)
Index 2/5, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
The preferred path is across R5:
R4#show ip route
...
163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
C 163.1.45.0/24 is directly connected, Serial0/1/0
O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:27:57, Serial0/0/0
C 163.1.0.0/24 is directly connected, Serial0/0/0
O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:27:57, Serial0/0/0
O IA 163.1.12.0/24 [110/193] via 163.1.0.5, 00:00:46, Serial0/0/0
...
On the above output 163.X.12.0/24 is seen as inter-area route via R5. However, we can see that R3 advertises the same summary with a better cost!
R4#sh ip ospf database summary 163.1.12.0
OSPF Router with ID (150.1.4.4) (Process ID 1)
Summary Net Link States (Area 1)
Routing Bit Set on this LSA
LS age: 2 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.12.0 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xBBF1
Length: 28
Network Mask: /24
TOS: 0 Metric: 65
But R4 ignores it due to the fact that it’s not received via Area 0! So how does OSPFv2 improves over the above described behavior? The fact is, it uses the inter-area routes received via the non-backbone area!
How does OSPFv2 perform Transit Path calculations
So OSPFv2 has some improvements over the simple procedure of next-hop resolution over a virtual-link. Specifically, it relies on the fact that the inter-area routes flooded into the transit area are “congruent” to the virtual-link and thus may not result in a routing loop – they are advertised following the same basic “star” topology. Thus, if those prefixes provide a better cost than the virtual-link path cost (X+Y based on the previous description) they could be used in place of the same prefixes learned via the virtual-link! This is only valid for inter-area prefixes injected from non-backbone areas and the intra-area routes found in Area 0 itself. We are going to review the case of the inter-area routes first.
However, prior to that, we are will describe how OSPFv2 detects if the area has the “Transit Capability. This is done in a pretty obvious manner. If an ABR detects that it has a fully adjacent virtual link coming from Area A, it sends all of its router LSAs into this area with the special “V” bit set. All the routers in Area A will see that bit set, and learn that the area is effectively supporting the transit feature (”V” stands for virtual-link of course). Now for the inter-area routes and path optimization.
OSPF transit Capability for inter-area routes
Back to our diagram above. If there is a virtual-link terminating on R3, this router is assumed to be an ABR, and generates summary LSAs for the prefixes learned from Area 2. These summaries are flooded across Area 1 and R4 learns them. Next, R4 will receive the summary LSAs for the SAME prefixes over the virtual link from R5. When the OSPF process in R4 computes the best routes, it takes in the account the fact that Area 1 is transit. Based on this, it attempts to find a BETTER path for the prefixes found in the summary-LSAs learned over the virtual link by looking at the inter-area routes received from Area 1. If it finds a match with a better metric, it simply uses that route over the one received across the virtual link! Look at the routing table of R4 when all the routers R3, R4 and R5 have the capability transit enabled: The prefix 163.X.12.0/24 is now reachable via R3, even though the virtual link from R4 links us to R5!
R4#show ip route ospf
163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:44:22, Serial0/0/0
O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:44:22, Serial0/0/0
O IA 163.1.12.0/24 [110/129] via 163.1.0.3, 00:00:02, Serial0/0/0
...
Effectively, even though R4 has the same prefix received via Area 0 it now prefers the path via R3 due to the transit capability feature. Check the summary LSA advertised by R3:
R4#show ip ospf database summary 163.1.12.0
...
LS age: 1115
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.12.0 (summary Network Number)
Advertising Router: 150.1.5.5
LS Seq Number: 80000001
Checksum: 0x8EE5
Length: 28
Network Mask: /24
TOS: 0 Metric: 10063
Summary Net Link States (Area 1)
LS age: 1122
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.12.0 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xBBF1
Length: 28
Network Mask: /24
TOS: 0 Metric: 65
LS age: 1127
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.12.0 (summary Network Number)
Advertising Router: 150.1.5.5
LS Seq Number: 80000002
Checksum: 0x8CE6
Length: 28
Network Mask: /24
TOS: 0 Metric: 10063
However, this procedure will NOT work if you summarize the prefixes from Area 2 while generating type-3 LSAs for Area 1 in R3. This is because there are no longer exact match between prefixes and OSPF cannot use them for path optimization.
R3:
router ospf 1
area 2 range 163.1.0.0 255.255.240.0
R4#show ip route ospf
163.1.0.0/16 is variably subnetted, 8 subnets, 3 masks
O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:48:51, Serial0/0/0
O IA 163.1.0.0/20 [110/65] via 163.1.0.3, 00:00:05, Serial0/0/0
O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:48:51, Serial0/0/0
O IA 163.1.12.0/24 [110/10127] via 163.1.0.5, 00:00:00, Serial0/0/0
However take notice that you CAN summarize the inter-area prefixes in this case, even though it is undesirable for the optimization.
What If the Area on the Other side is Area 0?
Now what if instead of Area 2 we have Area 0? That’s an interesting scenario, because in this case, R4 will be receiving the information about 163.X.12.0/24 via type-1 LSAs from R5 and should prefer intra-area routes over inter-area all the times. However, things are not that easy as they seems. The above described transit-area optimization works in this case as well! That is, R4 will look for a better path to reach the prefixes learned in router-LSAs via the inter-area LSAs in transit area! The procedure only works for Area 0 intra-area prefixes, and not for any other area intra-area routes, as the backbone area is the center of the star topology and thus loopless. Here is how it looks like in real life. Now consider the diagram below, which is the same as the previous one, with Area 2 replaced to Area 0. All ABRs have the capability transit turned on.
Look at R4’s routing table.. what’s this?! R4 has an intra-area route (means it’s via area 0) with the next hop pointing to R3?
R4#show ip route ospf
163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:55:13, Serial0/0/0
O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:55:13, Serial0/0/0
O 163.1.12.0/24 [110/129] via 163.1.0.3, 00:00:07, Serial0/0/0
O 163.1.13.0/24 [110/65] via 163.1.0.3, 00:00:50, Serial0/0/0
O 163.1.25.0/24 [110/10063] via 163.1.0.5, 00:00:30, Serial0/0/0
If we check the summary LSAs advertised by R3, will find this same prefix for 163.X.12.0/24 that should appear in R4’s routing table as inter-area route but INSTEAD used as “optimizer” for the inter-area path learned via Area 0!
R4#sh ip ospf database summary 163.1.12.0
OSPF Router with ID (150.1.4.4) (Process ID 1)
Summary Net Link States (Area 1)
LS age: 137
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.12.0 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xBBF1
Length: 28
Network Mask: /24
TOS: 0 Metric: 65
This is an awesome feature, which clearly demonstrates the use of the OSPF transit feature. What’s really odd, is that an intra-area route actually takes the INTER-area path! The transit capability essentially allows the use of non-backbone inter-area routes to optimize inter-area paths and area 0 intra-area paths IF the area in question is transit!
Virtual Links and Summarization
Now we remember that the optimization could be broken by using summarization (area ranges) at the respective ABR (R3 in our case). However, in case of source Area 0 this will not work! That’s it, R3 will IGNORE the range statements if they apply to the prefixes in area 0 and there is an active virtual-link. What’s the deal? The reason is that area 0 is the core transit area, and the prefixes learned via it could be used to reach the other inter-area routes. Summarizing Area 0 information while injecting it in a transit might result in routing loops in reaching those prefixes, as some of the transit paths might get hidden. Thus, OSPF will never summarize the backbone-area prefixes when injecting them into a TRANSIT area. You may validate it by configuring area range statements:
R3:
router ospf 1
area 0 range 163.1.12.0 255.255.240.0
!
R4#sh ip ospf database summary 163.1.0.0
OSPF Router with ID (150.1.4.4) (Process ID 1)
R4#sh ip ospf database summary 163.1.12.0
OSPF Router with ID (150.1.4.4) (Process ID 1)
Summary Net Link States (Area 1)
LS age: 766
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.12.0 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xBBF1
Length: 28
Network Mask: /24
TOS: 0 Metric: 65
This is the side-effect of the virtual-link configuration with area 0 ranges. What is we disable the transit capability? In that case, optimization breaks down, but the summarization works!
R3, R4, R5:
router ospf 1
no capability transit
R4#sh ip ospf database summary 163.1.0.0
OSPF Router with ID (150.1.4.4) (Process ID 1)
Summary Net Link States (Area 1)
LS age: 29
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 163.1.0.0 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0x7296
Length: 28
Network Mask: /20
TOS: 0 Metric: 1
R4#sh ip route ospf
163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O 163.1.0.3/32 [110/64] via 163.1.0.3, 06:10:26, Serial0/0/0
O 163.1.0.5/32 [110/64] via 163.1.0.5, 06:10:26, Serial0/0/0
O 163.1.12.0/24 [110/193] via 163.1.0.5, 00:01:21, Serial0/0/0
Summary
We quickly outlined the idea of the Transit Capability found in OSPFv2 and not present in OSPFv1. The core idea is that the inter-area routes found in a transit area might be used to optimize the routing paths instead of simply following the paths carved by the virtual links like OSPFv1 did. We found that
1) This procedure optimizes the paths for inter-area routes and backbone intra-area routes.
2) This procedure blocks Area 0 prefix summarization to prevent routing loops
3) This behavior is different from the one used in OSPFv1, which was transiting across the virtual-link paths.
