In OSPF, when is a virtual link needed, how does it work, and why is it usually treated as a repair rather than a design?
answer
- an area with no door to the hub
- two ABRs and a shared area
- it belongs to the backbone
- its cost is borrowed
- a hidden dependency
basics
~20 sA virtual link is needed when an area cannot reach area 0 directly or the backbone is partitioned. It joins two ABRs across a shared non-stub transit area as a backbone link, so the backbone now depends on that area's internal paths.
solid answer
~50 sOSPF requires a **contiguous backbone** that every area touches. When an area attaches only to another non-backbone area, or when area 0 splits in two, a **virtual link** restores the rule. It is configured on two ABRs that share a non-backbone **transit area**, and it belongs to **area 0**: the protocol treats it as an unnumbered point-to-point backbone link, forms an adjacency across it and lists it in both routers' backbone router-LSAs. Its cost is not configured; it is the intra-area path cost through the transit area, and the link is up only while such a path exists. It cannot cross a stub area or an NSSA. It is a repair because area 0 now depends on another area's internal stability, the transit area starts carrying transit traffic, and the backbone's real shape is hidden in configuration on two routers.
go deeper
Recall that every OSPF area must connect to area 0, and that a virtual link is the workaround when one cannot.
Explain the endpoints, the transit area, that the link belongs to area 0, and that its cost comes from the transit path.
Show how a virtual link ties the backbone to the transit area's stability, and plan the topology change that removes it.
Decide whether a merger's areas get virtual links as a bridge or an area redesign, weighing outage risk against migration cost.
## The rule a virtual link exists to satisfy RFC 2328 builds inter-area routing as a star: **area 0** is the hub, every other area is a spoke, and the backbone **must be contiguous**. Two situations break that: 1. **An area with no backbone attachment.** In a 300-router network with area 0 and areas 1, 2 and 3, a merger adds area 3, whose only connection is to a router in area 1. That router sits in areas 1 and 3 but not in area 0, so it has no backbone summaries to pass on: area 3 can learn area 1's own networks through it, but not the rest of the network. RFC 3509 (Informational) notes that traffic to the other areas and out of the domain is dropped. 2. **A partitioned backbone.** If the only links joining two halves of area 0 fail while both halves still connect through a non-backbone area, part of the network becomes unreachable. RFC 2328 says OSPF does not repair partitions of other areas (each piece becomes a separate area, routed through the backbone) but that **backbone** partitions can be repaired with virtual links. ## How a virtual link works A virtual link is configured on **both** endpoints, and each side names the other endpoint's Router ID and the **transit area** they share. | Property | What RFC 2328 says | |---|---| | Endpoints | Two area border routers with interfaces in a common non-backbone area | | Area membership | Area 0; the link is part of the backbone | | Treated as | An unnumbered point-to-point network between the two ABRs | | Cost | Not configured: the intra-area path cost between the endpoints through the transit area | | Up or down | Up while an intra-area path through the transit area exists; down when it does not | | In the database | A link of type 4 (virtual link) in each endpoint's backbone router-LSA; the V bit in their transit-area router-LSAs | | Type 5 LSAs | Never flooded over the virtual adjacency, since the transit area already carries them | | Forbidden transit areas | Stub areas (RFC 2328) and NSSAs (RFC 3101) | For the area 3 case: 1. **B1** is the ABR between area 0 and area 1; **B13** joins areas 1 and 3. 2. A virtual link from B1 to B13 with transit area 1 makes B13 a backbone router. 3. B13 becomes a true ABR for area 3: it originates area 3's summaries into area 0 over the virtual link and summaries of the rest of the network into area 3. OSPF packets on the virtual link, Hellos included, are sent as unicasts addressed to the other endpoint and cross several IP hops; data packets are **not** tunnelled. They are forwarded hop by hop through area 1, because the virtual link's path is area 1's intra-area path. An endpoint behind an unnumbered link into the transit area may be unable to work out the addresses the virtual link needs, and the virtual link then fails. ## What the transit area takes on Serving as transit for a fully adjacent virtual link changes area 1: - RFC 2328 sets its **TransitCapability**: area 1 now carries transit data traffic between other areas. - The backbone's configured ranges are ignored when summarising backbone networks into a transit area, so area 1 receives them uncondensed. - The routing calculation examines the transit area's summaries for better backbone paths. ## Why it counts as a repair, not a design - **A hidden dependency.** Area 0's connectivity now depends on area 1's internal topology. A failure inside area 1 can partition the backbone or cut off area 3, a failure an area design is meant to contain. - **A non-backbone area carries backbone traffic.** Inter-area flows for area 3 cross area 1, which may not have been sized for them. - **Configuration hides the shape.** The backbone's real graph is no longer visible from the cabling; it lives in matching configuration on two routers that must be kept consistent. - **Restrictions spread.** Area 1 can no longer become a stub area or an NSSA while it carries the virtual link. The durable fixes change the topology: add a physical link from area 3 to area 0, place a router with interfaces in both, or fold area 3 into area 1. A virtual link is the standard way to keep the network working until one of those is done, and it remains legitimate where none of them is possible.
- Can an OSPF virtual link be configured through a stub area or an NSSA?No. RFC 2328 forbids virtual links through stub areas, and RFC 3101 says an NSSA may not be used as a transit area. To keep a virtual link, the transit area must stay a normal area.
- How is a partitioned OSPF backbone repaired with a virtual link?Pick an ABR in each backbone fragment such that both have interfaces in one common non-backbone area, and configure a virtual link between them through that area. The two fragments then form a single contiguous area 0 again, as long as the transit area itself stays connected.
- What is the cost of an OSPF virtual link, and when does it go down?It is not configured; it equals the intra-area path cost between the two endpoints through the transit area, and the endpoints re-originate their backbone router-LSAs when it changes. The link goes down when that path disappears; RFC 2328 also treats it as down when the path cost exceeds 0xffff, the largest interface cost a router-LSA can carry.
saying these in an interview costs you the question
- An OSPF virtual link tunnels data packets between the two ABRs.
- A virtual link's cost is configured like any interface cost.
- A virtual link belongs to the transit area it crosses.
- Virtual links can be built through stub areas.
- Virtual links are the normal way to attach new areas in a large design.
- A partition of a non-backbone area needs a virtual link to heal.