Virtual Links
OSPF area design requires the use of a backbone area, area 0, with each area connecting to area 0 through an ABR. However, in some cases two backbone areas exist; in other cases, a nonbackbone area may not have a convenient point of connection to the backbone
area, for example:
Case 1.
An existing internetwork needs to add a new area, with a convenient, low-cost connection point with another nonbackbone area. However, that connection does not give the new area any connection to area 0.
Case 2.
Even with a well-designed area 0, a combination of link failures might result in a discontiguous backbone area, essentially creating two backbone areas.
Case 3.
Two companies could merge, each using OSPF. To merge the OSPF domains,one backbone area must exist. It may be more convenient to connect the two networks using links through an existing nonbackbone area, but that design means two backbone areas, which is not allowed.
Figure 8-1 shows an example of each of the first two cases.
The problems in each case have different symptoms, but the problems all stem from the area design requirements: Each area should be contiguous, and each nonbackbone area should connect to the backbone area through an ABR. When the network does not meet these requirements, engineers could simply redesign the areas. However, OSPF provides an alternative tool called an OSPF virtual link.
Understanding OSPF Virtual Link Concepts
An OSPF virtual link allows two ABRs that connect to the same nonbackbone area to
form a neighbor relationship through that nonbackbone area, even when separated by many other routers and subnets. This virtual link acts like a virtual point-to-point connection
between the two routers, with that link inside area 0. The routers form a neighbor relationship, inside area 0, and flood LSAs over that link.For example, consider the topology in Figure 8-2, which shows an example of the third of the three cases described in the beginning of this section. In this case, two companiesmerged. Both companies had a small office in the same city, so for expediency’s sake, they connected the two former Enterprise internetworks through a newly combined local sales
office in area 1. Although adding the link between branch offices may be a cost-effective temporary choice, it creates a design problem: Two backbone areas now exist, and OSPF requires that the backbone area be contiguous. To solve this problem, the engineer configures a virtual link between ABRs C1 and C2. The virtual link exists inside area 0, making area 0 contiguous.
the usual OSPF message types, encapsulated inside unicast IP packets, with a destination IP address of the router on the other end of the virtual link. Any routers between the two
routers that create the virtual link—for instance, the two branch routers in Figure 8-2 just forward these OSPF packets like any other packet. The neighbors on the ends of the
virtual link flood their LSDBs to each other so that all routers in both parts of area 0 learn the routes from the other area 0.
The ABRs connected over a virtual link act mostly like any other ABR, with a couple of differences. The first difference is that ABRs send all OSPF messages as unicasts to the IP
address of the router on the other end of the link. Second, the routers also mark the Do Not Age (DNA) bit in the LSAs, meaning that all routers on the other side of the virtual
link will not expect the LSAs to be reflooded over the virtual link on the usual 30-minute refresh interval. This helps reduce overhead over the virtual link, which often runs over
slower links and less-powerful routers. The router also assigns an OSPF cost to the virtual link, just as it would for an interface.
After the virtual link is up, the ABRs’ SPF processes can calculate their best routes just like before, using the virtual link as another point-to-point link in area 0. For packets destined to pass from one part of the backbone over the virtual link to the other part of the backbone, the chosen best routes eventually lead the packets to the router with the virtual
link. That router, connected to the transit nonbackbone area, has already calculated its next hop based on the LSDB in the transit area (Router C1 and transit area 1 in the example of Figure 8-2). The routers in the transit area choose routes that eventually deliver the packet to the router on the other end of the virtual link (Router C2 in Figure 8-2).
Configuring OSPF Virtual Links with No Authentication
Configuring an OSPF virtual link requires a minor amount of configuration just to get the link working, with several optional configuration items. Most of the optional configuration
settings relate to features that would normally be configured on the interface connecting two neighboring routers, but with a virtual link, there is no such interface, so the parameters
must be added to the area virtual-link command. The following list summarizes the key configuration options on the area virtual-link router subcommand:
*The remote-RID in the area area-num virtual-link remote-RID command refers to the other router’s RID.
*The area-num in the area area-num virtual-link remote-RID command refers to the transit area over which the packets flow between the two routers.
*The transit area over which the two routers communicate must not be a stubby area.
*The optional configuration of OSPF neighbor authentication parameters, normally configured as interface subcommands, must be configured as additional parameters on the area virtual-link command.
*The optional configuration of Hello and Dead intervals, normally configured as interface subcommands, must be configured as additional parameters on the area virtuallink command.
*The router assigns the virtual link an OSPF cost as if it were a point-to-point link. The router calculates the cost as the cost to reach the router on the other end of the link, as calculated using the transit area’s LSDB.
Example 8-1 shows the configuration of a virtual link on Router C1 and Router C2 shown in Figure 8-2. The configuration shows the virtual link, referencing area 1 as the transit area, with each router referring to the other router’s RIDs. The configuration also shows the loopback IP addresses on which the ABR’s RIDs are based being advertised into OSPF.
Verifying the OSPF Virtual Link
To prove whether the virtual link works, a neighbor relationship between C1 and C2 must reach FULL state, resulting in all routers in both parts of area 0 having the same area 0 LSDB. Example 8-2 shows the working neighbor relationship, plus status information for the virtual link with the show ip ospf virtual-link command.
The output also confirms that the routers have reached a fully adjacent state and is suppressing the periodic Hello messages.
The familiar show ip ospf neighbor command lists a few new items as well. Note that the interface refers to the virtual link “OSPF VL0” instead of the interface, because there is no
interface between the neighbors. It also lists no dead timer, because the neighbors choose to not use the usual Hello/Dead interval process over a virtual link. (Instead, if all the transit area’s routes to reach the router on the other router of the link fail, the virtual link fails.) Finally, the show ip ospf neighbor detail 4.4.4.4 command shows he interesting phrase “In the area 0 via interface OSPF VL0,” confirming that the neighborship does indeed exist in area 0.
***Note: OSPF does not require that the RID IP address range be advertised as a route in OSPF. As a result, the RID listed in the area virtual-link command may not be pingable, but the virtual link still work.
Configuring Virtual Link Authentication
Because virtual links have no underlying interface on which to configure authentication, authentication is configured on the area virtual-link command itself. Table 8-2 shows the
variations of the command options for configuring authentication on virtual links. Note that the configuration shown in Table 8-2 may be typed in one longer area virtual-link
command, as shown in the table, or the authentication type and key can be configured on separate area virtual-link commands. Regardless, IOS stores two different area virtuallink
commands into the running-config: one command that enables the type of authentication,and one that lists the authentication key, as shown in upcoming Example 8-3.
