OSPF Virtual Links and Backbone Repair

Virtual Links at a Glance

A virtual link is a logical point-to-point Area 0 connection between two OSPF Area Border Routers. It crosses a normal non-backbone area called the transit area.

Logical connectionArea 0

EndpointsTwo ABRs

Command identifiesRemote router ID

Best roleTemporary repair

Design principle: Use a virtual link to restore service while you repair the topology. A directly connected and redundant Area 0 is easier to understand, monitor, and troubleshoot.

In This Lesson

See the broken-backbone lab
Understand how the virtual link works
Check every requirement
Build the base OSPF topology
Configure both virtual-link endpoints
Verify the logical backbone
Match optional authentication
Troubleshoot a virtual link that stays down
Replace and remove the workaround safely
Complete the guided practice lab
Review the frequently asked questions

1. See the Broken-Backbone Lab

R1 and R2 sit in the main Area 0. R2 reaches R3 through Area 1. R3 connects to another Area 0 segment containing R4. The two Area 0 segments are not physically connected, so the backbone is discontiguous.

Area 0 · Main

R1Backbone router

R2 · ABRRID 2.2.2.2

Area 1 · Transit

Logical Area 0 pathVirtual link

Normal area with full reachability between R2 and R3

Area 0 · Disconnected

R3 · ABRRID 3.3.3.3

R4Backbone router

Configure the virtual link between R2 and R3. Area 1 carries the logical Area 0 adjacency; it does not become part of Area 0.

Before repair: R3's Area 0 segment has no continuous path to the main backbone.
Temporary repair: R2 and R3 form a logical Area 0 adjacency through Area 1.
After repair: R4 can exchange inter-area information through the restored backbone path.

2. Understand How the Virtual Link Works

The virtual link does not create a tunnel interface and does not encapsulate user packets like GRE. It creates an OSPF adjacency that behaves as an unnumbered point-to-point connection in Area 0.

1

R2 finds R3

R2 uses Area 1's intra-area routes to reach router ID 3.3.3.3.

2

Adjacency forms

R2 and R3 exchange OSPF packets as virtual-link neighbors.

3

Area 0 synchronizes

The endpoints exchange backbone LSAs across the logical connection.

4

Routes recover

Inter-area information can cross the repaired backbone again.

Dependency: The virtual link is only as reliable as Area 1. If the transit-area route between the endpoint router IDs disappears, the logical Area 0 adjacency also fails.

3. Check Every Requirement

Requirement	Why it matters	How to verify
Two endpoint ABRs	Both routers must connect Area 0 to the same transit area	`show ip ospf`
Matching transit area	Both commands must name the area between the endpoints	`show run \| section router ospf`
Normal transit area	A stub or NSSA area cannot be used as the transit area	Check area options on both ABRs
Reachable router IDs	Each endpoint needs an intra-area path to the other endpoint	`show ip route 2.2.2.2`
Remote router ID in command	The command does not use a physical interface address	`show ip ospf`

Most common mistake: On R2, enter R3's router ID. On R3, enter R2's router ID. Do not enter the local router ID or a link address.

4. Build the Base OSPF Topology

Set stable router IDs first. Then place the R2–R3 transit link in Area 1 and the outer links in Area 0. The example uses interface-level OSPF commands so the area assignment is easy to read.

R2 · Main backbone endpoint

router ospf 1
 router-id 2.2.2.2
!
interface GigabitEthernet0/0
 ip ospf 1 area 0
interface GigabitEthernet0/1
 ip ospf 1 area 1

R3 · Remote backbone endpoint

router ospf 1
 router-id 3.3.3.3
!
interface GigabitEthernet0/0
 ip ospf 1 area 1
interface GigabitEthernet0/1
 ip ospf 1 area 0

Confirm the physical R2–R3 Area 1 adjacency reaches Full.
Confirm R2 has an Area 1 path to 3.3.3.3 and R3 has an Area 1 path to 2.2.2.2.
Save baseline neighbor, LSDB, and routing-table output before adding the virtual link.

5. Configure Both Virtual-Link Endpoints

The configuration is entered under the OSPF process. The first value is the transit area. The second value is the remote endpoint's router ID.

R2 points to R3

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

R3 points to R2

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

Read the command aloud: “Across transit Area 1, build a virtual link to the remote router ID.” This makes it easier to avoid reversing the area number and router ID.

6. Verify the Logical Backbone

Do not stop when the configuration is accepted. Prove the virtual interface is up, the neighbor is Full, Area 0 LSAs cross the link, and traffic follows a valid forward and return path.

Check virtual-link state

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 GigabitEthernet0/1
  State POINT_TO_POINT, Cost 10

Check the Area 0 neighbor

R2# show ip ospf neighbor 3.3.3.3

Neighbor 3.3.3.3, interface address 10.0.23.3
  In the area 0 via OSPF_VL0
  Neighbor priority is 0, State is FULL

show ip ospf virtual-links must report the virtual link as up.
The endpoint adjacency must reach Full through OSPF_VL0.
Compare show ip ospf database on both Area 0 sides.
Check remote routes, then test traffic in both directions.

7. Match Optional Authentication on Both Ends

Virtual-link authentication is configured on the virtual link itself. Use the same method, key ID, and secret at both endpoints. The example shows classic Cisco IOS message-digest syntax.

R2 authentication

router ospf 1
 area 1 virtual-link 3.3.3.3 authentication message-digest
 area 1 virtual-link 3.3.3.3 message-digest-key 1 md5 LAB-KEY

R3 authentication

router ospf 1
 area 1 virtual-link 2.2.2.2 authentication message-digest
 area 1 virtual-link 2.2.2.2 message-digest-key 1 md5 LAB-KEY

Production note: Platform capabilities differ. Use the strongest authentication supported by your software, protect configuration secrets, and test both endpoints during the same approved change.

8. Troubleshoot a Virtual Link That Stays Down

Work from the transit area outward. A virtual link cannot form until the underlying Area 1 path is healthy.

Symptom	Likely cause	First check
No virtual-link neighbor	Wrong remote router ID or one endpoint missing	Compare both OSPF configurations
Virtual link remains down	No intra-area path across the transit area	Routes to both endpoint router IDs
Area mismatch messages	Different transit area numbers	`area 1 virtual-link ...` on both sides
Authentication failure	Method, key ID, or secret does not match	Virtual-link authentication lines
Link flaps repeatedly	Unstable transit-area path	Physical links, neighbors, SPF events, and logs
Neighbor is Full but traffic fails	Missing route or return path	Routing table and end-to-end forwarding

Control-plane checks

show ip ospf virtual-links
show ip ospf neighbor
show ip ospf interface
show ip ospf database

Underlay and traffic checks

show ip route 2.2.2.2
show ip route 3.3.3.3
show logging | include OSPF
traceroute <remote-prefix>

Avoid the shortcut: Do not clear the OSPF process first. Capture evidence before using a disruptive command, especially on the transit-area routers that support the repair path.

9. Replace and Remove the Workaround Safely

A virtual link solves a topology problem but also adds a hidden dependency. Plan a direct Area 0 connection, confirm it is stable, and only then remove the virtual link.

1

Build the real backbone

Add a direct, preferably redundant, Area 0 path between the backbone sections.

2

Prove stability

Verify neighbors, LSDBs, routes, convergence, and both traffic directions.

3

Remove both endpoints

Delete the matching virtual-link commands during an approved change.

Remove from R2

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

Remove from R3

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

10. Guided Practice Lab

Complete each task in order. Save the important output so you can explain why the link works or fails.

Task 1: Build and Repair the Backbone

Build the four-router topology shown above.
Place the middle R2–R3 link in Area 1.
Confirm the Area 1 adjacency and router-ID reachability.
Configure the virtual link on R2 and R3.
Prove the virtual link and Area 0 adjacency are up.

Expected result: R2 and R3 become Full neighbors through OSPF_VL0, and remote Area 0 routes become available.

Task 2: Create and Diagnose a Safe Fault

Save the working output.
In an isolated lab, enter the wrong remote router ID on R3.
Observe the virtual-link state and neighbor table.
Compare both endpoint configurations.
Restore the correct router ID and confirm recovery.

Expected result: You can identify the endpoint mismatch without clearing the OSPF process.

Task 3: Test the Transit-Area Dependency

Confirm Area 1 carries routes to both endpoint router IDs.
Record the virtual-link cost and physical path.
Shut one lab transit path safely.
Observe whether another intra-area path keeps the link up.
Restore the path and document the dependency.

Expected result: The virtual link survives only when Area 1 still provides an intra-area path between R2 and R3.

11. Frequently Asked Questions

What problem does an OSPF virtual link solve?

It restores logical Area 0 connectivity when a backbone section or non-backbone area cannot connect directly to the main backbone.

Does a virtual link carry normal user traffic inside a tunnel?

No. It creates a logical OSPF adjacency and backbone path. It is not a GRE tunnel and does not create a separately addressed user-data tunnel interface.

Can the transit area be stub or NSSA?

No. The transit area must be a normal area that can provide complete intra-area reachability between the two endpoint router IDs.

Which address belongs in the virtual-link command?

Use the remote ABR's OSPF router ID. Do not use its interface address, the local router ID, or an arbitrary loopback address that is not the active router ID.

Should a virtual link be a permanent design?

Usually no. It is best treated as a temporary repair or migration tool. Replace it with a simple, directly connected, and resilient Area 0 design when possible.

What should I check first when the virtual link is down?

Check that the physical transit-area adjacency is Full and that each endpoint has an intra-area route to the other endpoint's router ID. Then compare the area number, remote router IDs, timers, and authentication.

OSPF Virtual Links: Repair a Disconnected Backbone