OSPF Virtual Links Configuration

OSPF has one architectural rule that is not negotiable: every non-backbone area must connect directly to area 0. Inter-area routes only flow through the backbone, so an area that touches area 0 nowhere is effectively cut off from the rest of the network, even when its LSDB looks perfectly healthy. Virtual links are the escape hatch OSPF provides for exactly this situation: they extend area 0 across a transit area so a stranded ABR can behave as if it had a real backbone connection. The full OSPF guide covers where this rule comes from and how areas fit together.

This article walks through the whole lifecycle on real gear: what a discontiguous area looks like when it breaks, the two commands that fix it, and the verification output that proves the fix worked. All device output comes from a Cisco Modeling Labs topology on IOS XE 17.18: R1 and R2 share a LAN in area 0, R2-R3 is a /30 in area 1, and R3 holds a loopback (192.168.5.1/24) in area 2. That last detail is the problem: area 2 hangs off R3, and R3 has no interface in area 0.

The problem: an area with no path to the backbone

R3 is technically an ABR here, since it connects area 1 and area 2. But look at what it is missing:

R3# show ip ospf | include Router ID|area|Area
 Number of areas in this router is 2. 2 normal 0 stub 0 nssa
    Area 1
        Number of interfaces in this area is 6 (5 loopback)
    Area 2
        Number of interfaces in this area is 1

Two areas, neither of them area 0. An ABR only generates inter-area (type 3) summary LSAs into and out of the backbone, so area 2's prefix never makes it past R3 (the mechanics of which LSA types cross area boundaries are covered in OSPF LSA types explained). The result on R1, sitting in area 0 on the other side of the network:

R1# show ip route 192.168.5.0
% Network not in table

No neighbor problem, no flapping, no error message anywhere. The network is simply absent, which is what makes discontiguous areas such a quiet failure. If you are fuzzy on why the backbone must be contiguous in the first place, OSPF areas explained covers the design logic.

Configuring the virtual link

A virtual link is configured between two ABRs through a shared transit area. In the lab, R2 is a real backbone ABR (areas 0 and 1) and R3 is the stranded ABR (areas 1 and 2). They share area 1, so area 1 becomes the transit area. The command goes under the OSPF process on both routers, and it references the remote router's router ID, not an interface address:

R2(config)# router ospf 1
R2(config-router)# area 1 virtual-link 3.3.3.3

R3(config)# router ospf 1
R3(config-router)# area 1 virtual-link 2.2.2.2

Two commands total, one on each side, both naming the transit area. Once both are in place, the routers form an additional adjacency across the virtual link, and R3 is treated as if it were connected to area 0. Check the link's status with a command purpose-built for it:

R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface Ethernet0/1
  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:02
    Adjacency State FULL (Hello suppressed)

A few details worth reading in that output. The virtual link behaves as a point-to-point interface called OSPF_VL0. It runs as a demand circuit with hellos suppressed and DoNotAge LSAs allowed, meaning LSAs learned over it do not age out and periodic hellos stop once the adjacency is FULL (OSPF assumes the underlying transit area's routing will signal any real failure). "Transit area 1, via interface Ethernet0/1" tells you exactly which physical path the virtual link rides on.

Verifying it end to end

The virtual link shows up as a normal neighbor entry, alongside the physical adjacencies:

R2# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -        00:00:24    10.0.23.1       OSPF_VL0
1.1.1.1           1   FULL/BDR        00:00:31    10.0.12.1       Ethernet0/0
3.3.3.3           1   FULL/BDR        00:00:34    10.0.23.1       Ethernet0/1

R3 (router ID 3.3.3.3) now appears twice: once over the physical Ethernet0/1 in area 1, and once over OSPF_VL0, which is logically an area 0 adjacency. The real test, though, is the route that was missing. Back on R1:

R1# show ip route 192.168.5.0
Routing entry for 192.168.5.0/24
  Known via "ospf 1", distance 110, metric 21, type inter area
  Last update from 10.0.12.2 on Ethernet0/0, 00:00:24 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 3.3.3.3, 00:00:24 ago, via Ethernet0/0
      Route metric is 21, traffic share count is 1

The area 2 prefix is now a normal inter-area route, advertised by 3.3.3.3, because R3 can finally inject its type 3 summary into the backbone. From "% Network not in table" to a full routing entry with two commands.

Why virtual links are a temporary fix

Working as designed is not the same as well designed. A virtual link is a patch over a topology problem: the moment you need one, your area layout has drifted from the model OSPF wants. Virtual links add a hidden dependency (the backbone now relies on the health of the transit area), they complicate troubleshooting (a problem in area 1 can now break area 0 connectivity), and they are easy to forget about until they fail during an unrelated change. They are legitimate as a migration tool, for example while merging two networks after an acquisition or restructuring addressing, but the end state should always be a redesign where every area has a real area 0 connection, either by re-homing the area or by moving the backbone boundary.

Requirements and gotchas

• Both endpoints must be ABRs, and the virtual link must terminate on the remote router ID, not an interface IP. If the adjacency never forms, verify the configured ID matches show ip ospf on the far side.
• The transit area cannot be a stub, totally stubby, or NSSA area. If area 1 were a stub area in this lab, the virtual link would be refused.
• The transit area must have full routing knowledge between the two ABRs; the virtual link rides on top of the transit area's intra-area routes.
• Virtual links inherit OSPF interface behavior, including authentication. If you run authentication in area 0, the virtual link is part of area 0 and needs matching authentication too, a very common miss.
• Because hellos are suppressed on the demand circuit, do not expect the dead timer to catch problems the way it does on a physical link; watch the transit area instead.

Key Takeaways

Every area must touch area 0; when one does not, its routes silently vanish from the rest of the network, and a virtual link through a shared transit area is the sanctioned workaround. Configure it on both ABRs with area <transit> virtual-link <remote-router-id>, verify with show ip ospf virtual-links (look for "up" and Adjacency State FULL), and confirm the missing prefixes return as inter-area routes. Treat the virtual link as scaffolding: it keeps traffic flowing while you redesign the areas so it is no longer needed.