Skip to main content
  1. Network Articles/
  2. OSPF Articles/

OSPF Virtual Links

Table of Contents

What a virtual link is

An OSPF virtual link extends area 0 (the backbone) logically. It stretches the backbone through another area to a place the backbone does not physically reach.

RFC 2328 Section 3.1 states that the backbone always contains every area border router (ABR) and must be contiguous. Two situations break that assumption, and a virtual link addresses both.

SituationWhat happens
An area does not touch the backboneIts ABR has no interface in area 0, so no routes enter or leave
The backbone is partitionedArea 0 breaks into fragments that cannot exchange routes

This article reproduces both on real routers. The configuration is identical in each case, but the kind of route that appears at the end differs. That difference says a lot about what a virtual link really is.

Configuration and three constraints

The command goes under the transit area and takes the router ID of the far end.

Configuring a virtual link
router ospf <process>
 area <transit area>
  virtual-link <router ID of the far end>

There are three constraints. Each comes from RFC 2328, and this article checks how the router actually behaves.

  • Both ABRs need the configuration. One side alone does not bring the link up
  • The transit area cannot be a stub (Section 3.6), because a stub area does not carry full routing information
  • The cost of the path across the transit area becomes the cost of the virtual link. You cannot set it directly

Test setup

R1 - R2 - R3 - R4 in a line. Two labs run on the same four routers, and only the area assignment changes between them.

ItemLab ALab B
R1 - R2Area 0Area 0
R2 - R3Area 1 (transit)Area 1 (transit)
R3 - R4Area 2Area 0
Situation reproducedAn area off the backboneA partitioned backbone

The router IDs are 1.1.1.1 on R1, 2.2.2.2 on R2, 3.3.3.3 on R3 and 4.4.4.4 on R4. The software is XRd 26.1.1.

The test runs in nine STEPs.

STEPChangeWhat to look for
0Lab A, defaultsR3 is not treated as an ABR. Not a single route reaches R4
1Configure R2 onlyThe link does not come up. The cost is 65535
2Configure R3 as wellIt comes up, routes flow, and R3 becomes an ABR
3Make the transit area a stubThe commit is rejected
4Set the transit link cost to 50The virtual link cost follows
5Remove the cost and the virtual linkArea 2 is isolated again
6Move R3 - R4 into area 0The backbone is partitioned
7Configure the virtual linkThe partition is repaired and the routes become intra-area
8Restore the original setupBack to the STEP 0 state (final state)

Lab A: rescuing an area that does not touch the backbone

STEP 0: it looks like an ABR but it is not

R3 has interfaces in area 1 and area 2. By the plain definition it is an ABR, yet show ospf prints no ABR line for it.

R2 is shown as an area border router (STEP 0)
 Routing Process "ospf 1" with ID 2.2.2.2
 Role: Primary Active
 NSR (Non-stop routing) is Enabled
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 It is an area border router
 Maximum number of non self-generated LSA allowed 500000
    Current number of non self-generated LSA 3

The same place on R3 is missing that line.

R3 has no such line (STEP 0)
 Routing Process "ospf 1" with ID 3.3.3.3
 Role: Primary Active
 NSR (Non-stop routing) is Enabled
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Maximum number of non self-generated LSA allowed 500000
    Current number of non self-generated LSA 6
    Threshold for warning message 75%

A router with no interface in area 0 is not treated as an ABR, even when it belongs to two areas. That matches RFC 2328’s statement that the backbone contains every ABR.

The consequence shows up on R4. Its adjacency with R3 is FULL, yet it has not a single OSPF route.

R4 has not a single route (STEP 0)
RP/0/RP0/CPU0:R4#show route ospf
Fri Sep 11 23:47:49.499 UTC

% No matching routes found

STEP 1: one side is not enough

Configure the virtual link on R2 only.

Configuration applied in STEP 1 (R2 only)
(R2)
router ospf 1
 area 1
  virtual-link 3.3.3.3

The interface is created but reads is down, and the cost is 65535, the value that says it cannot be used.

R2 stays down with only one side configured (STEP 1)
Virtual Links for OSPF 1

Virtual Link OSPF_VL1 to router 3.3.3.3 is down
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, Cost of using 65535
  Transmit Delay is 1 sec, State DOWN,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Nothing is logged in this state. To notice the missing half you have to look at show ospf virtual-links.

STEP 2: configure both ends and the link comes up

Now configure R3 as well.

Configuration applied in STEP 2 (R3 only)
(R3)
router ospf 1
 area 1
  virtual-link 2.2.2.2

It changes to is up and the cost becomes 1. That 1 is not a configured value: it is the cost of the path from R2 to R3 across area 1.

R2 the virtual link is up (STEP 2)
Virtual Links for OSPF 1

Virtual Link OSPF_VL1 to router 3.3.3.3 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface GigabitEthernet0/0/0/1, Cost of using 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:03:282
    Adjacency State FULL (Hello suppressed)
    Number of DBD retrans during last exchange 0

Note Run as demand circuit and Adjacency State FULL (Hello suppressed). A virtual link runs as a demand circuit and suppresses Hellos once the adjacency is stable. The LSAs that cross it carry (DNA) (Do Not Age) and are exempt from the usual 1800-second refresh.

A virtual link counts as an area 0 interface. show ospf interface brief lists OSPF_VL1 with no IP address, in area 0, as P2P.

R2 OSPF_VL1 is listed as an area 0 interface (STEP 2)
RP/0/RP0/CPU0:R2#show ospf interface brief
Fri Sep 11 23:53:52.018 UTC

* Indicates MADJ interface, (P) Indicates fast detect hold down state

Interfaces for OSPF 1

Interface          PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0                1     0               2.2.2.2/32         1     LOOP  0/0
OSPF_VL1           1     0                     -            1     P2P   1/1
Gi0/0/0/0          1     0               10.1.2.2/24        1     BDR   1/1
Gi0/0/0/1          1     1               10.2.3.2/24        1     DR    1/1

There are now two adjacencies. The same R3 appears once over the virtual link and once over the physical link.

R2 has two adjacencies with the same neighbor (STEP 2)
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3         1     FULL/  -           -        10.2.3.3        OSPF_VL1
    Neighbor is up for 00:01:27
1.1.1.1         1     FULL/DR         00:00:33    10.1.2.1        GigabitEthernet0/0/0/0
    Neighbor is up for 00:10:18
3.3.3.3         1     FULL/BDR        00:00:32    10.2.3.3        GigabitEthernet0/0/0/1
    Neighbor is up for 00:09:11

On R3 the area count goes from two to three and the ABR line appears.

R3 becomes an ABR and now has three areas (STEP 2)
 Routing Process "ospf 1" with ID 3.3.3.3
 Role: Primary Active
 NSR (Non-stop routing) is Enabled
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 It is an area border router
 Maximum number of non self-generated LSA allowed 500000
    Current number of non self-generated LSA 13

The routes follow. R1 learns 4.4.4.4/32 from area 2 as O IA, an inter-area route.

R1 has learned the area 2 routes (STEP 2)
RP/0/RP0/CPU0:R1#show route ospf
Fri Sep 11 23:53:25.084 UTC

O    2.2.2.2/32 [110/2] via 10.1.2.2, 00:09:49, GigabitEthernet0/0/0/0
O IA 3.3.3.3/32 [110/3] via 10.1.2.2, 00:08:43, GigabitEthernet0/0/0/0
O IA 4.4.4.4/32 [110/4] via 10.1.2.2, 00:00:54, GigabitEthernet0/0/0/0
O IA 10.2.3.0/24 [110/2] via 10.1.2.2, 00:09:49, GigabitEthernet0/0/0/0
O IA 10.3.4.0/24 [110/3] via 10.1.2.2, 00:00:54, GigabitEthernet0/0/0/0

In the capture, the Hellos over the virtual link are unicast and carry area ID 0.0.0.0. Area 1’s own Hellos travel to 224.0.0.5 on the same physical link, so both kinds are mixed together.

No.13 Hello over the virtual link (area ID 0.0.0.0, mask 0.0.0.0)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 48
        Source OSPF Router: 3.3.3.3
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xc191 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF Hello Packet
        Network Mask: 0.0.0.0
        Hello Interval [sec]: 10
        Options: 0x32, (DC) Demand Circuits, (L) LLS Data block, (E) External Routing
            0... .... = DN: Not set
            .0.. .... = (O) Opaque: Not set
            ..1. .... = (DC) Demand Circuits: Supported
            ...1 .... = (L) LLS Data block: Present
            .... 0... = (N) NSSA: Not supported
            .... .0.. = (MC) Multicast: Not capable
            .... ..1. = (E) External Routing: Capable
            .... ...0 = (MT) Multi-Topology Routing: No
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 0.0.0.0
        Backup Designated Router: 0.0.0.0
        Active Neighbor: 2.2.2.2
    OSPF LLS Data Block
        Checksum: 0xfff6
        LLS Data Length: 12 bytes
        Extended options TLV
            TLV Type: 1
            TLV Length: 4
            Options: 0x00000001, (LR) LSDB Resynchronization
                .... .... .... .... .... .... .... ..0. = (RS) Restart Signal: Not set
                .... .... .... .... .... .... .... ...1 = (LR) LSDB Resynchronization: Set
Download the pcap of the packet in the tshark output above (No.13 Hello)

On the area 0 link, the LSAs R3 originates arrive in a burst.

The LS Updates that reached area 0 (R1 - R2)
    6 2026-09-12 08:52:25.502271     10.1.2.2 → 224.0.0.5    OSPF 198 LS Update
    7 2026-09-12 08:52:25.552975     10.1.2.2 → 224.0.0.5    OSPF 122 LS Update
    8 2026-09-12 08:52:25.588217     10.1.2.2 → 224.0.0.5    OSPF 98 LS Update
   10 2026-09-12 08:52:30.395777     10.1.2.2 → 10.1.2.1     OSPF 98 LS Update

No.6 carries five LSAs. The first is R3’s own router-LSA with Number of Links: 0: its area 0 LSA has only the virtual link, which is not counted as a link here. The other four are summary-LSAs, including 4.4.4.4 and 10.3.4.0 from area 2.

The start of No.6 (five LSAs, Do Not Age set)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 5
        LSA-type 1 (Router-LSA), len 24
            .000 0000 0000 1011 = LS Age (seconds): 11
            1... .... .... .... = Do Not Age Flag: 1
            Options: 0x22, (DC) Demand Circuits, (E) External Routing
                0... .... = DN: Not set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..1. = (E) External Routing: Capable
                .... ...0 = (MT) Multi-Topology Routing: No
            LS Type: Router-LSA (1)
            Link State ID: 3.3.3.3
            Advertising Router: 3.3.3.3
            Sequence Number: 0x80000001
            Checksum: 0xbb6e
            Length: 24
            Flags: 0x01, (B) Area border router
                0... .... = (H) Host: No
                ..0. .... = (S) Shortcut-capable ABR: No
                ...0 .... = (N) NSSA translation: No
                .... 0... = (W) Wild-card multicast receiver: No
                .... .0.. = (V) Virtual link endpoint: No
                .... ..0. = (E) AS boundary router: No
                .... ...1 = (B) Area border router: Yes
            Number of Links: 0
        LSA-type 3 (Summary-LSA (IP network)), len 28
Download the pcap of the packet in the tshark output above (No.6 LS Update)

STEP 3: the transit area cannot be a stub

Trying to make area 1 a stub is rejected at commit time.

The configuration attempted in STEP 3
(R2)
router ospf 1
 area 1
  stub

The commit does not go through, and the reason comes straight back.

R2 the commit is rejected (STEP 3)
RP/0/RP0/CPU0:R2(config-ospf-ar)#commit

Sat Sep 12 00:28:37.001 UTC

% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RP0/CPU0:R2(config-ospf-ar)#show configuration failed

Sat Sep 12 00:28:44.920 UTC
!! SEMANTIC ERRORS: This configuration was rejected by 
!! the system due to semantic errors. The individual 
!! errors with each failed configuration command can be 
!! found below.

router ospf 1
 area 1
  stub
!!% 'OSPF' detected the 'warning' condition 'Error: The specified area cannot be a stub or nssa as it contains a virtual link'
 !
!
end

The reason comes straight back. The change is rolled back and never reaches the running configuration. The constraint in RFC 2328 Section 3.6 is enforced when the configuration is applied.

STEP 4: the transit area decides the cost

Set a cost of 50 on the transit-side interface at both ends.

Configuration applied in STEP 4 (both ends)
(R2)
router ospf 1
 area 1
  interface GigabitEthernet0/0/0/1
   cost 50

(R3)
router ospf 1
 area 1
  interface GigabitEthernet0/0/0/0
   cost 50

The virtual link cost moves from 1 to 50. You cannot set a cost on a virtual link directly. The intra-area cost of the section is used as-is.

R2 the cost followed to 50 (STEP 4)
Virtual Links for OSPF 1

Virtual Link OSPF_VL1 to router 3.3.3.3 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface GigabitEthernet0/0/0/1, Cost of using 50
  Transmit Delay is 1 sec, State POINT_TO_POINT,

STEP 5: remove it and everything reverts

Removing the cost and the virtual link leaves R4 without routes again. That is the end of Lab A.

Lab B: repairing a partitioned backbone

STEP 6: partition the backbone

Move R3 - R4 from area 2 into area 0. Area 0 now exists as two fragments with area 1 in between.

Configuration applied in STEP 6 (R3 - R4 moves into area 0)
(R3)
router ospf 1
 no area 2
 area 0
  interface GigabitEthernet0/0/0/1

(R4)
router ospf 1
 no area 2
 area 0
  interface Loopback0
   passive enable
  !
  interface GigabitEthernet0/0/0/0

R1 and R4 cannot learn each other’s loopback. Each sees as far as the neighbouring ABR, and the fragment beyond it is missing.

R1 does not have 4.4.4.4 (STEP 6)
RP/0/RP0/CPU0:R1#show route ospf
Sat Sep 12 00:37:50.651 UTC

O    2.2.2.2/32 [110/2] via 10.1.2.2, 00:54:15, GigabitEthernet0/0/0/0
O IA 3.3.3.3/32 [110/3] via 10.1.2.2, 00:03:23, GigabitEthernet0/0/0/0
O IA 10.2.3.0/24 [110/2] via 10.1.2.2, 00:03:23, GigabitEthernet0/0/0/0
R4 does not have 1.1.1.1 (STEP 6)
RP/0/RP0/CPU0:R4#show route ospf
Sat Sep 12 00:39:06.002 UTC

O IA 3.3.3.3/32 [110/2] via 10.3.4.3, 00:01:43, GigabitEthernet0/0/0/0
O IA 10.2.3.0/24 [110/2] via 10.3.4.3, 00:01:43, GigabitEthernet0/0/0/0

The symptom differs from Lab A. There, R4 had no routes at all; here it has two. Information about the neighbouring ABR and area 1 arrives, and only the far backbone fragment is missing. That contrast is a useful diagnostic.

STEP 7: rejoin with a virtual link

The configuration is exactly the same as in Lab A.

Configuration applied in STEP 7 (identical to STEP 1 and 2 of Lab A)
(R2)
router ospf 1
 area 1
  virtual-link 3.3.3.3

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

The routes come back. What matters is their kind. 4.4.4.4/32 is now O, an intra-area route, not O IA.

R1 has 4.4.4.4 as an intra-area route (STEP 7)
RP/0/RP0/CPU0:R1#show route ospf
Sat Sep 12 00:41:18.055 UTC

O    2.2.2.2/32 [110/2] via 10.1.2.2, 00:57:42, GigabitEthernet0/0/0/0
O IA 3.3.3.3/32 [110/3] via 10.1.2.2, 00:06:50, GigabitEthernet0/0/0/0
O    4.4.4.4/32 [110/4] via 10.1.2.2, 00:01:12, GigabitEthernet0/0/0/0
O IA 10.2.3.0/24 [110/2] via 10.1.2.2, 00:06:50, GigabitEthernet0/0/0/0
O    10.3.4.0/24 [110/3] via 10.1.2.2, 00:01:12, GigabitEthernet0/0/0/0
R4 also learns 1.1.1.1 as an intra-area route (STEP 7)
RP/0/RP0/CPU0:R4#show route ospf
Sat Sep 12 00:42:32.032 UTC

O    1.1.1.1/32 [110/4] via 10.3.4.3, 00:02:21, GigabitEthernet0/0/0/0
O    2.2.2.2/32 [110/3] via 10.3.4.3, 00:02:21, GigabitEthernet0/0/0/0
O IA 3.3.3.3/32 [110/2] via 10.3.4.3, 00:05:09, GigabitEthernet0/0/0/0
O    10.1.2.0/24 [110/3] via 10.3.4.3, 00:02:21, GigabitEthernet0/0/0/0
O IA 10.2.3.0/24 [110/2] via 10.3.4.3, 00:05:09, GigabitEthernet0/0/0/0

In Lab A the same destination was O IA. The metric is 4 in both cases; only the kind differs.

DestinationLab ALab B
4.4.4.4/32 seen from R1O IA, metric 4O, metric 4

The virtual link acts as part of area 0, so the two fragments become one area 0 again. 3.3.3.3/32 and 10.2.3.0/24 live in area 1 and stay O IA.

The reason is visible in the capture. What flows on the area 0 link differs from Lab A.

R4's own router-LSA reaches area 0 (STEP 7)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 2
        LSA-type 1 (Router-LSA), len 48
            .000 0000 1010 0110 = LS Age (seconds): 166
            1... .... .... .... = Do Not Age Flag: 1
            Options: 0x22, (DC) Demand Circuits, (E) External Routing
                0... .... = DN: Not set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..1. = (E) External Routing: Capable
                .... ...0 = (MT) Multi-Topology Routing: No
            LS Type: Router-LSA (1)
            Link State ID: 4.4.4.4
            Advertising Router: 4.4.4.4
            Sequence Number: 0x80000002
            Checksum: 0x6660
            Length: 48
            Flags: 0x00
                0... .... = (H) Host: No
                ..0. .... = (S) Shortcut-capable ABR: No
                ...0 .... = (N) NSSA translation: No
                .... 0... = (W) Wild-card multicast receiver: No
                .... .0.. = (V) Virtual link endpoint: No
                .... ..0. = (E) AS boundary router: No
                .... ...0 = (B) Area border router: No
            Number of Links: 2
Download the pcap of the packet in the tshark output above (No.6 LS Update)

In Lab A only summary-LSAs (type 3) created by R3 arrived. In Lab B R4’s own router-LSA (type 1) and network-LSA (type 2) reach R1, and the flags read 0x00: this is an ordinary router, not an ABR. The two fragments have merged their link state databases, which is why the routes are intra-area.

STEP 8: restore the original setup

Putting the area assignment and the virtual link back returns everything to the STEP 0 state.

Design notes

  • A virtual link is a repair, not a design. RFC 2328 Section 15 presents it as a way to cope when backbone continuity cannot be maintained. If you can attach to area 0 physically, fix that instead
  • The transit area can never be a stub or NSSA. If you later want to make that area a stub, the virtual link is in the way
  • You cannot set the cost directly. Tuning the path means changing costs inside the transit area, which also affects that area’s ordinary routes
  • A one-sided configuration is easy to miss. Nothing is logged, so check show ospf virtual-links explicitly

Where the device differs from the RFC

RFC 2328 Section 12.4.1 says a router sets the V bit in its router-LSA for an area if and only if it is the endpoint of a fully adjacent virtual link whose transit area is that area. Section 16.1 uses that bit to decide an area’s TransitCapability.

XRd 26.1.1 did not set it. With the virtual link is up and Adjacency State FULL, the router-LSA for the transit area on both endpoints looks like this.

The router-LSA for the transit area (area 1). The V bit is not set
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Update (4)
        Packet Length: 76
        Source OSPF Router: 3.3.3.3
        Area ID: 0.0.0.1
        Checksum: 0x346a [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 1
        LSA-type 1 (Router-LSA), len 48
            .000 0000 0000 0001 = LS Age (seconds): 1
            0... .... .... .... = Do Not Age Flag: 0
            Options: 0x22, (DC) Demand Circuits, (E) External Routing
                0... .... = DN: Not set
                .0.. .... = (O) Opaque: Not set
                ..1. .... = (DC) Demand Circuits: Supported
                ...0 .... = (L) LLS Data block: Not Present
                .... 0... = (N) NSSA: Not supported
                .... .0.. = (MC) Multicast: Not capable
                .... ..1. = (E) External Routing: Capable
                .... ...0 = (MT) Multi-Topology Routing: No
            LS Type: Router-LSA (1)
            Link State ID: 3.3.3.3
            Advertising Router: 3.3.3.3
            Sequence Number: 0x80000004
            Checksum: 0xeee7
            Length: 48
            Flags: 0x01, (B) Area border router
                0... .... = (H) Host: No
                ..0. .... = (S) Shortcut-capable ABR: No
                ...0 .... = (N) NSSA translation: No
                .... 0... = (W) Wild-card multicast receiver: No
                .... .0.. = (V) Virtual link endpoint: No
                .... ..0. = (E) AS boundary router: No
                .... ...1 = (B) Area border router: Yes
            Number of Links: 2
            Type: Stub     ID: 3.3.3.3         Data: 255.255.255.255 Metric: 1
                Link ID: 3.3.3.3 - IP network/subnet number
                Link Data: 255.255.255.255
                Link Type: 3 - Connection to a stub network
                Number of Metrics: 0 - TOS
                0 Metric: 1
            Type: Transit  ID: 10.2.3.2        Data: 10.2.3.3        Metric: 1
                Link ID: 10.2.3.2 - IP address of Designated Router
                Link Data: 10.2.3.3
                Link Type: 2 - Connection to a transit network
                Number of Metrics: 0 - TOS
                0 Metric: 1

The raw bytes agree: the flag byte is 0x01 (B only) and does not include 0x04 for V. Even in Lab B, where the transit area does carry backbone traffic, the route computation worked. No ill effect from the missing bit was observed. The reason was not investigated.

Verification configuration and show output

Collected from all four routers at every STEP. The verification configuration is the ..._run.txt file (the final state is the STEP 8 one).

FileContents
..._show.txtshow version / show interface description / show route / show route ospf / show ospf / show ospf interface / show ospf interface brief / show ospf neighbor / show ospf neighbor detail / show ospf database / show ospf database router / show ospf database network / show ospf statistics interface / show ospf virtual-links / show ospf border-routers / show ospf database router self-originate / show ospf trace events
..._log.txtshow logging narrowed to that STEP
..._run.txtshow running-config at that STEP (the verification configuration for that STEP)
..._cfg.txtThe configuration applied in that STEP. The session from configure to commit, followed by the diff the device itself reports with show configuration commit changes last 1. Only routers that were configured have this file

STEP 0: Lab A, defaults - R3 is not treated as an ABR and not a single route reaches R4

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogrun
R3showlogrun
R4showlogrun

STEP 1: Configure R2 only - the link does not come up; the cost is 65535

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogruncfg
R3showlogrun
R4showlogrun

STEP 2: Configure R3 as well - it comes up, routes flow, and R3 becomes an ABR

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogrun
R3showlogruncfg
R4showlogrun

STEP 3: Make the transit area a stub - the commit is rejected

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogruncfg
R3showlogrun
R4showlogrun

STEP 4: Set the transit link cost to 50 - the virtual link cost follows

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogruncfg
R3showlogruncfg
R4showlogrun

STEP 5: Remove the cost and the virtual link - area 2 is isolated again

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogruncfg
R3showlogruncfg
R4showlogrun

STEP 6: Move R3 - R4 into area 0 - the backbone is partitioned

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogrun
R3showlogruncfg
R4showlogruncfg

STEP 7: Configure the virtual link - the partition is repaired and the routes become intra-area

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogruncfg
R3showlogruncfg
R4showlogrun

STEP 8: Restore the original setup (final state) - back to the STEP 0 state

Routershow outputsyslogrunning-configapplied config
R1showlogrun
R2showlogruncfg
R3showlogruncfg
R4showlogruncfg

Captures were taken while the link came up in Lab A and while the backbone was repaired in Lab B, on the transit link (R2 - R3) and the area 0 link (R1 - R2).

Lab A, the transit link while the link comes up (STEP 2)

Lab A, the area 0 link while the link comes up (STEP 2)

Lab B, the transit link while the backbone is repaired (STEP 7)

Lab B, the area 0 link while the backbone is repaired (STEP 7)

References

RFCTitleSummary
RFC 2328OSPF Version 2The backbone must be contiguous (Section 3.1); a virtual link cannot cross a stub area (Section 3.6); the definition of a virtual link and how its cost is derived (Section 15); the V bit in the router-LSA (Section 12.4.1).

Related articles