Virtual links — patching the backbone across a transit area

A virtual link is a tunnel through a non-backbone OSPF area that makes two routers appear to share a common area 0 segment. The mechanism is defined in RFC 2328 Section 4.5 as the escape hatch for when the backbone is not physically contiguous — for example, when a remote site joins the OSPF estate through a partner’s network or through a merger-acquired network that the operator does not yet have full control over. Virtual links work, but they have caveats that make them a last-resort tool rather than a design choice.

This lesson explains the rules the virtual link enforces, the configuration, the operational failure modes, and the security implications.

Why virtual links exist

OSPF requires the backbone (area 0) to be contiguous. Every other area must connect to area 0 through an ABR; an area that is not directly attached to area 0 is unreachable for inter-area traffic. This contiguity rule is what allows OSPF to guarantee loop-free inter-area routing: every inter-area path goes through area 0, and every inter-area path is a tree with area 0 as the root.

The contiguity rule breaks when the operator inherits a network where area 0 is split, or where a new site joins the OSPF estate through a network the operator does not control. Examples:

• A merger. Two companies merge their networks. Each has its own area 0 with different router-id ranges. The merged estate needs a single area 0 that spans both companies’ networks. Until the physical topology is rebuilt, a virtual link bridges the gap.
• A partner network. A remote site joins the OSPF estate through a partner’s MPLS network. The partner’s network is itself an OSPF area (call it area 5). The remote site needs to be in area 0 but cannot be physically attached. A virtual link from the remote site’s ABR to a router inside area 0, traversing area 5, extends area 0 to the remote site.
• A transition state. During a network rebuild, an area has been renumbered or restructured but the rebuild is not complete. A virtual link bridges the gap while the rebuild proceeds.

flowchart LR
  subgraph "Physical reality"
    A0Left["Area 0<br/>(left half)"]
    Area5[Area 5<br/>transit]
    A0Right["Area 0<br/>(right half, wants to be one area 0)"]
    A0Left --- Area5
    Area5 --- A0Right
  end
  subgraph "Logical reality (with virtual link)"
    A0[Area 0<br/>contiguous<br/>via virtual link]
  end
  A0Left -. "virtual link" .-> A0Right
  A0Left -.- A0
  A0Right -.- A0
  Area5 -. "transit area<br/>(not visible in logical view)" .-> A0

In the diagram, the physical topology has two separate area 0 segments connected through area 5. The virtual link tunnels through area 5 and makes the two area 0 segments appear contiguous to OSPF.

How the virtual link works

A virtual link is a logical point-to-point adjacency between two routers. The two routers must:

• Both be ABRs.
• Share an interface in a common non-backbone area (the “transit area”).
• Have their router-ids configured to point at each other.

The virtual link’s adjacency is established using OSPF unicast Hello packets sent through the transit area. The Hello packets are addressed to the standard OSPF multicast address 224.0.0.5 but encapsulated as unicast to the remote router-id. The transit area’s routers forward the unicast packets as ordinary IP traffic.

Once the adjacency is up, the two routers exchange Type 1 (Router) LSAs as if they were directly connected in area 0. Each router installs a virtual link interface in its router-LSA, with the link type set to “virtual”. The downstream effect is that the LSDBs of the two area 0 segments merge: every router in one segment learns every LSA in the other segment.

The transit area is unchanged from OSPF’s perspective — its routers do not see the virtual link as anything special. They forward the unicast Hello packets as ordinary IP traffic and do not learn any new routing information about area 0.

The transit area constraints

RFC 2328 imposes two strict constraints on the transit area:

1. The transit area must be a standard area. Stub, totally stubby, NSSA, and totally NSSA areas cannot be transit areas for a virtual link. The reason is that the transit area must carry the virtual link’s unicast Hello packets and the Type 1 LSAs the virtual link exchanges. A stub / NSSA area does not have the full set of LSA types and cannot carry the Type 1 LSAs that describe the virtual link interface.
2. Both ABRs must have a route to each other through the transit area. The virtual link’s unicast Hello packets are routed through the transit area’s intra-area topology. If either ABR does not have a route to the other through the transit area, the Hello packets are dropped and the adjacency stays in Down.

The second constraint is the more subtle. A virtual link between two ABRs requires the transit area to have a working intra-area routing topology that the two ABRs can use to reach each other. If the transit area is fragmented (e.g. it is itself partitioned), the virtual link fails.

flowchart TB
  subgraph "Area 0 (left)"
    ABR1[ABR-1]
    CORE1[Core-1]
    ABR1 --- CORE1
  end
  subgraph "Area 5 (transit, must be standard)"
    ABR1
    ABR2[ABR-2]
    R5A[R-5A]
    R5B[R-5B]
    ABR1 --- R5A
    R5A --- R5B
    R5B --- ABR2
  end
  subgraph "Area 0 (right)"
    ABR2
    CORE2[Core-2]
    ABR2 --- CORE2
  end
  ABR1 -. "virtual link<br/>unicast Hello through area 5" .-> ABR2

In the diagram, ABR-1 and ABR-2 are both ABRs between area 0 and area 5. The virtual link is between them, traversing area 5 as the transit. The transit area’s routers (R-5A, R-5B) forward the unicast Hello packets and do not see the virtual link as anything special.

Configuration on VyOS 1.5 LTS

# On both ABRs
set protocols ospf area 0 virtual-link 192.0.2.1
set protocols ospf area 0 virtual-link 192.0.2.1 hello-interval 10
set protocols ospf area 0 virtual-link 192.0.2.1 retransmit-interval 5
set protocols ospf area 0 virtual-link 192.0.2.1 transmit-delay 1
set protocols ospf area 0 virtual-link 192.0.2.1 dead-interval 40
set protocols ospf area 0 virtual-link 192.0.2.1 authentication message-digest
set protocols ospf area 0 virtual-link 192.0.2.1 message-digest-key 1 md5-key 'change-me'

The virtual-link declaration takes the remote router-id as its argument. The configuration is symmetrical: both ABRs declare a virtual-link to the other. The timers and authentication are optional and apply to the virtual link’s Hello / LSA exchange.

Under the hood, VyOS translates this to FRR’s:

router ospf
 area 0
  virtual-link 192.0.2.1 hello-interval 10 retransmit-interval 5 ...

The remote router-id 192.0.2.1 is the router-id of the other ABR.

How the result is validated

show ip ospf virtual-links
show ip ospf neighbor
show ip ospf database
vtysh -c 'show ip ospf virtual-links'
vtysh -c 'show ip ospf neighbor'

What the operator looks for:

• show ip ospf virtual-links shows the virtual link’s state. A healthy virtual link shows Adjacency State Full, the transit area, the remote router-id, and the cost.
• show ip ospf neighbor shows the virtual link’s neighbour entry with the neighbour’s router-id. The state should be Full.
• show ip ospf database router self-originate (on either ABR) shows the virtual link encoded as a virtual link in the Router LSA.

How it fails

The production failure modes:

• Transit area is stub / NSSA. The FRR configuration rejects the virtual link with an error message: “Virtual link transit area must be a standard area”. The fix is to convert the transit area to standard.
• No route through the transit area. The virtual link’s Hello packets are dropped because one or both ABRs cannot route to the other through the transit area. The diagnostic is show ip ospf virtual-links showing the adjacency stuck in Down. The fix is to restore the transit area’s intra-area routing.
• Authentication mismatch. The two ABRs have different authentication keys for the virtual link. The fix is to ensure the keys match.
• Router-id mismatch. The two ABRs have declared virtual links to each other, but the router-id arguments do not match. The fix is to correct the router-id arguments.
• The remote site has its own area 0 that conflicts. The downstream backbone has a router-id range that overlaps with the upstream. The fix is to renumber or to use a different routing domain.

The security implications

A virtual link is a tunnel through the transit area. The transit area must be considered trusted: any router inside the transit area can spoof the virtual link’s unicast Hello packets and inject Type 1 LSAs that affect area 0. The LSA injection is not authenticated unless the operator configures authentication on the virtual link.

The authentication configuration is mandatory in a production estate:

set protocols ospf area 0 virtual-link 192.0.2.1 authentication message-digest
set protocols ospf area 0 virtual-link 192.0.2.1 message-digest-key 1 md5-key '<strong-key>'

Without authentication, an attacker inside the transit area can:

• Inject Type 1 LSAs that advertise a virtual link to a router-id the attacker controls, creating a black hole for traffic destined for area 0.
• Inject Type 1 LSAs that advertise a virtual link with a low cost, attracting traffic from area 0 to a router the attacker controls.
• Disrupt the virtual link entirely by injecting LSAs that conflict with the legitimate ABRs’ LSAs.

The transitive trust is the issue. A virtual link makes the transit area part of the trust boundary for area 0. If the operator does not trust the transit area (e.g. it is a partner’s network), a virtual link is not the right tool — the operator should rebuild the physical topology so area 0 is genuinely contiguous.

The operational cost

Virtual links have ongoing operational costs:

• The virtual link must be monitored. A failed virtual link makes area 0 fragmented, and the failure surfaces as silent loss of inter-area routes. The operator must monitor show ip ospf virtual-links regularly.
• The transit area’s health is critical. The virtual link depends on the transit area’s intra-area routing. A flap in the transit area flaps the virtual link. The operator must monitor the transit area’s adjacencies and metrics.
• The virtual link’s authentication must be rotated. The MD5 key on the virtual link must be rotated on the operator’s standard rotation schedule.

Rollback

# Capture the running configuration before the change
show configuration commands | save /tmp/ospf-virtual-link-$(date +%s).txt

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

The rollback for a virtual link change is delete protocols ospf area 0 virtual-link <remote-router-id> followed by commit. If the virtual link is critical to the routing topology, the rollback fragments area 0 and the operator must be prepared to restore it quickly.

Production discipline

Cross-course references

• The OSPF fundamentals part covers the LSA types (vyos-xviii-03-lsa-types), the area concept (vyos-xviii-04-areas), and the basic OSPF configuration (vyos-xix-03-ospf-area-config).
• The previous lessons (vyos-xx-01-area-types and vyos-xx-02-stub-nssa) cover the area-type constraints that make stub / NSSA areas ineligible as transit areas for virtual links.
• The OSPF authentication lesson (vyos-xix-04-authentication) covers the authentication configuration in detail. Authentication on a virtual link follows the same idiom.
• The security hardening part (vyos-liii-01-routing-protocol-authentication) covers the broader pattern of routing protocol authentication.

Quiz