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 at this feature now.
The idea of a 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 a 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 ignores summary LSAs delivered across the non-backbone areas. This ensures the simple loop free 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 located. 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.
However, virtual-links are only used to flood specific LSAs: the router, network, and summary LSAs found in area 0. Type 5 LSAs 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 a single area. Thus, if you have a virtual link connecting two ABRs, you cannot flood LSAs across the transit area, since this area is different from Area 0. However, external LSAs have the flooding scope of OSPF autonomous system, and thus they are flooded across the area anyways (unless it’s stub), so there is no need to duplicate information across the virtual link. Obviously, a stub area cannot be transit due to this reason.
After LSAs have been loaded across the virtual link, they could be used to run SPF and populate the routing table. Initially, all prefixes learned across a virtual link are assigned the next hop value of “virtual-link”. This value should be resolved to something physical. Here is where it becomes a little trickier. 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, across the virtual link and Y is the cost the other ABR advertises for this prefix. This is precisely what OSPFv1 did and what Cisco IOS was doing prior to supporting “transit capability” documented in OSPFv2 standard.
Therefore, in the case of OSPFv1 (or OSPFv2 + no capability transit) deployed in the topology documented on 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 compared to the PVC used to reach R5? You will 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 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 virtual links R4->R5->R3 configured on these routers. R4 will prefer 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 between R3-R5 and R4-R5:
Prior to that, we will quickly outline how OSPFv2 detects if an area has the “Transit Capability”. This is done in a pretty straighforward manner. If an ABR detects that it has a fully adjacent virtual link coming from Area A, it floods all of its router LSAs into this area with the special “V” bit set. All 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).
Here is what it looks like in a live scenario. Consider the diagram below, which is the same as the previous one, just having Area 2 changed to Area 0. All ABRs have the capability transit turned on.
Look at R4′s routing table and notice that it has an intra-area route (via area 0) with the next hop pointing to R3:
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.
What is Transit Capability?
In short, this is a special property of a 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 mechanism is a virtual-link?What are Virtual-links?
The idea of a 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 a 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 ignores summary LSAs delivered across the non-backbone areas. This ensures the simple loop free 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 located. 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 the 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 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 a single area. Thus, if you have a virtual link connecting two ABRs, you cannot flood LSAs across the transit area, since this area is different from Area 0. However, external LSAs have the flooding scope of OSPF autonomous system, and thus they are flooded across the area anyways (unless it’s stub), so there is no need to duplicate information across the virtual link. Obviously, a stub area cannot be transit due to this reason.
After LSAs have been loaded across the virtual link, they could be used to run SPF and populate the routing table. Initially, all prefixes learned across a virtual link are assigned the next hop value of “virtual-link”. This value should be resolved to something physical. Here is where it becomes a little trickier. 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, across the virtual link and Y is the cost the other ABR advertises for this prefix. This is precisely what OSPFv1 did and what Cisco IOS was doing prior to supporting “transit capability” documented in OSPFv2 standard.
Therefore, in the case of OSPFv1 (or OSPFv2 + no capability transit) deployed in the topology documented on 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 compared to the PVC used to reach R5? You will 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 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 virtual links R4->R5->R3 configured on these routers. R4 will prefer 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 between 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 msecThe 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
...
In the above output, 163.X.12.0/24 is seen as an 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 improve upon this described
behavior? It uses the inter-area routes received via the non-backbone
area as a source of better information!How Does OSPFv2 Perform Transit Path Calculations
OSPFv2 implements some improvements over the simple procedure of next-hop resolution for virtual-link connection. 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 loopless “tree” topology. Thus, if those inter-area prefixes provide a better cost than the virtual-link path (X+Y as in the previous description) they could be used in place of the same prefixes learned via the virtual-link! However, this is optimization hold true only 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.Prior to that, we will quickly outline how OSPFv2 detects if an area has the “Transit Capability”. This is done in a pretty straighforward manner. If an ABR detects that it has a fully adjacent virtual link coming from Area A, it floods all of its router LSAs into this area with the special “V” bit set. All 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).
OSPF Transit Capability for Inter-area Routes
Back to our diagram above. If there is a virtual-link terminating on R3, this router is an ABR (per the RFC), 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 into 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 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: 10063However, this procedure will NOT work if you summarize the prefixes from Area 2 into Area 1 on R3. This is because there are no longer an 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 optimization. It is possible to
summarize prefixes from non-backbone area into a transit area, but we
will see that you cannot summarize prefixes from backbone area into a
transit area.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 at all times. However, 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 the transit area! The procedure only works for Area 0 intra-area prefixes, and not for any other intra-area routes.Here is what it looks like in a live scenario. Consider the diagram below, which is the same as the previous one, just having Area 2 changed to Area 0. All ABRs have the capability transit turned on.
Look at R4′s routing table and notice that it has an intra-area route (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, we will find the same
prefix for 163.X.12.0/24 that should appear in R4′s routing table as an
inter-area route, but INSTEAD is used as an “corrector” 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
What’s really interesting, 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
We remember that this optimization could be broken by using summarization (area ranges) at the ABRs (R3 in our case). However, in the case of source Area 0, summarization will not work! R3 will IGNORE the range statements if they cover to the prefixes in area 0 and there is an active virtual-link across any area. What’s the problem with that? 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 area, might result in routing loops in reaching those prefixes, as the same information will flow unsummarized down the chain of virtual links. Thus, OSPF will never summarize backbone-area prefixes when injecting them into a TRANSIT area. You may validate this 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 if 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 outlined the idea of the Transit Capability found in OSPFv2 and not present in OSPFv1. The key idea is that the inter-area routes found in a transit area could be used to optimize the routing paths instead of simply following the paths carved by the virtual links (OSPFv1). 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.
