Lab Objective
Configure an OSPF virtual link across a transit area to connect an otherwise-isolated area to the backbone, and verify routes that previously could not propagate begin flowing correctly once the virtual link is established.
Lab Purpose
Every OSPF area must connect directly to Area 0, discussed earlier in this series regarding multi-area design — a strict requirement, not a suggestion. A virtual link provides an exception mechanism for the rare case where physical topology does not allow a direct connection, logically extending the backbone through an intermediate transit area.
Lab Topology
R1 (Area 0) ---- R2 (Area 0/Area 1, ABR) ---- R3 (Area 1/Area 2, ABR) ---- R4 (Area 2)
Area 2 has NO direct connection to Area 0 --
it only connects through Area 1, an invalid
design without a virtual linkTask 1: Configure Basic Multi-Area OSPF
Configure all four routers with OSPF, placing R1-R2's link in Area 0, R2-R3's link in Area 1, and R3-R4's link in Area 2.
Task 2: Observe the Resulting Problem
Confirm R1 cannot learn R4's routes, since Area 2 has no valid path to the backbone.
Task 3: Configure the Virtual Link
Configure a virtual link between R2 and R3, using Area 1 as the transit area, referencing each other's Router ID.
Task 4: Verify the Virtual Link Is Up
Confirm the virtual link shows as active.
Task 5: Verify Routes Now Propagate Correctly
Confirm R1 now learns R4's routes, and vice versa.
Solution and Verification
R1(config)# router ospf 1
R1(config-router)# network 10.1.1.0 0.0.0.3 area 0
R2(config)# router ospf 1
R2(config-router)# network 10.1.1.0 0.0.0.3 area 0
R2(config-router)# network 10.2.2.0 0.0.0.3 area 1
R3(config)# router ospf 1
R3(config-router)# network 10.2.2.0 0.0.0.3 area 1
R3(config-router)# network 10.3.3.0 0.0.0.3 area 2
R4(config)# router ospf 1
R4(config-router)# network 10.3.3.0 0.0.0.3 area 2
R4(config-router)# network 192.168.44.0 0.0.0.255 area 2R1# show ip route ospf | include 192.168.44
-- (no output -- R4's LAN is completely
-- invisible to R1, since Area 2 has no
-- valid connection to the backbone)R2# show ip ospf | include Router ID
Routing Process "ospf 1" with ID 2.2.2.2
R3# show ip ospf | include Router ID
Routing Process "ospf 1" with ID 3.3.3.3R2(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
-- Both ends reference the SAME transit area
-- (Area 1) and each other's Router ID --
-- this logically extends Area 0 through
-- R2 and R3, treating Area 2 as if it now
-- had an indirect path to the backboneR2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
Run as demand circuit
Transit area 1, via interface Serial0/0/1R1# show ip route ospf | include 192.168.44
O IA 192.168.44.0/24 [110/128] via 10.1.1.2
R4# show ip route ospf | include 10.1.1.0
O IA 10.1.1.0/30 [110/128] via 10.3.3.2
-- Routes now flow correctly in both
-- directions across the virtual linkKey Takeaway
A virtual link is explicitly a workaround for a design that violates OSPF's every-area-touches-Area-0 requirement, not a standard design pattern to build around intentionally — the correct long-term fix is almost always re-architecting the physical topology so every area genuinely connects to Area 0 directly, with the virtual link reserved for temporary transitions or genuinely unavoidable physical constraints.