OSPF Virtual Link is part of the CCNP Enterprise certification program, including the CCNP ENCOR and ENARSI exams. This concept is described in RFC 2328 and it is supported by major vendors such as Cisco, Juniper, and Huawei. In this tutorial, you will learn what is OSPF virtual link, how it works, and how to configure and troubleshoot it.

Here is the network topology I will be using. The routing domain consists of five routers and three OSPF areas: 0, 12, and 234.

Figure 1 – The network diagram of an OSPF routing domain

Here are the links to download the initial configurations of the routers.

Router R1 Router R2 Router R3
Router R4 Router R5

What is OSPF Virtual Link?

The backbone area (area 0) cannot be discontiguous across an OSPF routing domain. This means each router attached to area 0 must have at least one OSPF adjacency with a router in that area. Routers in the backbone area can share LSAs between OSPF areas. if a router is connected to multiple areas, not including area 0, then it cannot share LSAs between areas because if it is not connected to area 0. Here comes the concept of OSPF virtual link.

OSPF virtual link is a tool used to connect an OSPF-enabled router to area 0 across a particular transit area.

How Does OSPF Virtual Link Work?

In Figure 1, router R2 is connected to two OSPF areas, not including area 0 (Figure 1). Therefore, it does not flood LSAs received in area 12 into area 234, and vice versa. This way, router R1 does have routes to subnets 10.0.23.0/24, 10.0.34.0/24, and 10.0.45.0/24 (Example 1).

R1# show ip route


omitted output

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.12.0/24 is directly connected, GigabitEthernet0/2
L        10.0.12.1/32 is directly connected, GigabitEthernet0/2

Example 1 – Displaying R1’s routing table

Similarly, routers R3, R4, and R5 don’t have routes to subnet 10.0.45.0/24 (Examples 2, 3, and 4).

R3# show ip route



omitted output

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.0.23.0/24 is directly connected, GigabitEthernet0/2
L        10.0.23.3/32 is directly connected, GigabitEthernet0/2
C        10.0.34.0/24 is directly connected, GigabitEthernet0/4
L        10.0.34.3/32 is directly connected, GigabitEthernet0/4
O IA     10.0.45.0/24 [110/2] via 10.0.34.4, 00:02:45, GigabitEthernet0/4

Example 2 – Displaying R3’s routing table

R4# show ip route



omitted output

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O        10.0.23.0/24 [110/2] via 10.0.34.3, 00:02:49, GigabitEthernet0/3
C        10.0.34.0/24 is directly connected, GigabitEthernet0/3
L        10.0.34.4/32 is directly connected, GigabitEthernet0/3
C        10.0.45.0/24 is directly connected, GigabitEthernet0/5
L        10.0.45.4/32 is directly connected, GigabitEthernet0/5

Example 3 – Displaying R4’s routing table

R5# show ip route



omitted output

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA     10.0.23.0/24 [110/3] via 10.0.45.4, 00:02:45, GigabitEthernet0/4
O IA     10.0.34.0/24 [110/2] via 10.0.45.4, 00:02:45, GigabitEthernet0/4
C        10.0.45.0/24 is directly connected, GigabitEthernet0/4
L        10.0.45.5/32 is directly connected, GigabitEthernet0/4

Example 4 – Displaying R5’s routing table

To fix this issue, we need to connect router R2 to a router in area 0 via either an OSPF virtual link or a physical/logical router interface. In these examples, we configure a virtual link between R2 and R4 across area 234, called transit area in this case. The transit area cannot be a stub, totally stubby, NSSA, or totally NSSA area.

Router R2

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

Router R4

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

Let’s check the routing tables on routers R1, R3, R4, and R5. Example 5 shows that R1 learned routes to subnets 10.0.23.0/24, 10.0.34.0/24, and 10.0.45.0/24.

R1# show ip route


omitted output


      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.0.12.0/24 is directly connected, GigabitEthernet0/2
L        10.0.12.1/32 is directly connected, GigabitEthernet0/2
O IA     10.0.23.0/24 [110/2] via 10.0.12.2, 00:00:56, GigabitEthernet0/2
O IA     10.0.34.0/24 [110/3] via 10.0.12.2, 00:00:56, GigabitEthernet0/2
O IA     10.0.45.0/24 [110/4] via 10.0.12.2, 00:00:32, GigabitEthernet0/2

Example 5 – Displaying R1’s routing table

Examples 6, 7, and 8 indicate that routers R3, R4, and R5 learned a route to subnet 10.0.12.0/24.

R3# show ip route


omitted output

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA     10.0.12.0/24 [110/2] via 10.0.23.2, 00:01:03, GigabitEthernet0/2
C        10.0.23.0/24 is directly connected, GigabitEthernet0/2
L        10.0.23.3/32 is directly connected, GigabitEthernet0/2
C        10.0.34.0/24 is directly connected, GigabitEthernet0/4
L        10.0.34.3/32 is directly connected, GigabitEthernet0/4
O IA     10.0.45.0/24 [110/2] via 10.0.34.4, 00:11:54, GigabitEthernet0/4

Example 6 – Displaying R3’s routing table

R4# show ip route



omitted output

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA     10.0.12.0/24 [110/3] via 10.0.34.3, 00:00:43, GigabitEthernet0/3
O        10.0.23.0/24 [110/2] via 10.0.34.3, 00:11:58, GigabitEthernet0/3
C        10.0.34.0/24 is directly connected, GigabitEthernet0/3
L        10.0.34.4/32 is directly connected, GigabitEthernet0/3
C        10.0.45.0/24 is directly connected, GigabitEthernet0/5
L        10.0.45.4/32 is directly connected, GigabitEthernet0/5

Example 7 – Displaying R4’s routing table

R5# show ip route



omitted output

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA     10.0.12.0/24 [110/4] via 10.0.45.4, 00:00:47, GigabitEthernet0/4
O IA     10.0.23.0/24 [110/3] via 10.0.45.4, 00:11:52, GigabitEthernet0/4
O IA     10.0.34.0/24 [110/2] via 10.0.45.4, 00:11:52, GigabitEthernet0/4
C        10.0.45.0/24 is directly connected, GigabitEthernet0/4
L        10.0.45.5/32 is directly connected, GigabitEthernet0/4

Example 8 – Displaying R5’s routing table

OSPF Virtual Link Configuration on Cisco IOS with Examples

In this section, you will learn to configure an OSPF virtual link, and adjust all associated parameters including hello timer, authentication, LSA retransmission interval, LSA update transmission delay, and TTL security hop count. Additionally, you learn how to verify commands we apply to an OSPF virtual link.

Configuring OSPF Virtual Links with The area virtual-link Command

To set up an Open Shortest Path First (OSPF) virtual link, use the area area_number virtual-link router_id command in router configuration mode. area_number is the identifier of the transit area (non-stub area) that connects the two routers. You can type in area_number as a decimal value between 0 and 4,294,967,295 or as an IP address between 0.0.0.0 and 255.255.255.255.

router_id is the OSPF router ID of the router with which you want to form the virtual link. To get the router ID of an OSPF node, use the show ip ospf command.

Note that the OSPF virtual link fails if both routers are not ABRs. Also, a virtual link between two routers in the same area can be established even if they are not directly connected.

In this example, we create a virtual link between routers R2 and R4.
Router R2

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

Router R4

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

To verify our configuration, we use the show ip ospf virtual-links, show ip ospf , and show ip ospf neighbor commands.

The show ip ospf virtual-links command output states that the virtual link across area 234 between R2 and R4 is up.

R4# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 2.2.2.2 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  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:01
    Adjacency State FULL (Hello suppressed)
    Index 1/2/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

The following show ip ospf command output indicates that R2 is now connected to area 0.

R2# show ip ospf
 Routing Process "ospf 1" with ID 2.2.2.2
 Start time: 00:04:16.776, Time elapsed: 02:03:07.640
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Supports NSSA (compatible with RFC 3101)
 Supports Database Exchange Summary List Optimization (RFC 5243)
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 It is an area border router
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 EXCHANGE/LOADING adjacency limit: initial 300, process maximum 300
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 3. 3 normal 0 stub 0 nssa
 Number of areas transit capable is 1
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 1
        Area has no authentication





omitted output

Finally, a new OSPF adjacency is established between those routers, as shown in the following show ip ospf neighbor command output.

R4# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -           -        10.0.23.2       OSPF_VL0
5.5.5.5           1   FULL/DR         00:00:35    10.0.45.5       GigabitEthernet0/5
3.3.3.3           1   FULL/BDR        00:00:32    10.0.34.3       GigabitEthernet0/3

Configuring The Hello Interval of an OSPF Virtual Link

The default value of the hello interval on the virtual link between R2 and R4 is 10 seconds. To change it, use the area area_number virtual-link router_id hello-interval seconds, where seconds is between 1 and 8192.

In this example, we set the hello interval of the virtual link between R2 and R4 to 5 seconds.

Router R2

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 hello-interval 5

Router R4

R4(config)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 hello-interval 5

To verify the configuration, we use the show ip ospf virtual-links command, as you can see in this example:

R4# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 2.2.2.2 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 5, Dead 60, Wait 40, Retransmit 5
    Hello due in 00:00:02
    Adjacency State FULL (Hello suppressed)
    Index 1/2/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Configuring The Dead Interval of an OSPF Virtual Link

The default value of the dead interval on OSPF virtual links is 40 seconds. To change it, use the area area_number virtual-link router_id dead-interval seconds, where seconds is between 1 and 8192.

In this example, we set the dead interval of the virtual link between R2 and R4 to 60 seconds.

Router R2

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 dead-interval 60

Router R4

R4(config)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 dead-interval 60

The following show ip ospf virtual-links command output states that the dead interval of the virtual link interface on R2 is now 60 seconds instead of 40 seconds.

R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 60, Wait 40, Retransmit 5
    Hello due in 00:00:08
    Adjacency State FULL (Hello suppressed)
    Index 1/1/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Configuring The Retransmission Interval on an OSPF Virtual Link

The Retransmit Interval represents the time in seconds OSPF waits before it resends an unacknowledged LSA.

To modify the default retransmit interval, use the area area-id virtual-link router-id retransmit-interval seconds command, where seconds is between 1 and 8192. This parameter does not need to be the same on both ends of the virtual link.

In this example, we configure router R2 to set the retransmit interval of the virtual link to 10 seconds.

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 retransmit-interval 10

To check that the change has been applied, we use the show ip ospf virtual-links command in enable mode, as shown below:

R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 5, Dead 60, Wait 40, Retransmit 10
    Hello due in 00:00:01
    Adjacency State FULL (Hello suppressed)
    Index 1/1/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Configuring The Transmission Delay on an OSPF Virtual Link

To change the default transmit delay value, use the area area-id virtual-link router-id transmit-delay seconds command, where seconds is between 1 and 8192. This parameter does not have to be identical on both ends of the virtual link.

In this example, we configure router R2 to set the transmit delay of the virtual link to 2 seconds.

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 transmit-delay 2

To verify that the change has been applied, we use the show ip ospf virtual-links command in enable mode, as shown below:

R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  Transmit Delay is 2 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 5, Dead 60, Wait 40, Retransmit 10
    Hello due in 00:00:02
    Adjacency State FULL (Hello suppressed)
    Index 1/1/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Configuring The TTL-Security Hops for an OSPF Virtual Link

The area area_id virtual-link router_id ttl-security hops hop_count command allows to instruct Cisco IOS to start checking TTL values on OSPF packets received over a virtual link and set the Time-to-Live (TTL) security hops allowed on one end of a virtual link, where area_id is the ID of the transit area, router_id is the router ID of the other end node of the virtual link, and hop_count is an integer between 1 and 254.

You don’t have to configure this setting on both ends of the virtual link, but you should pay attention to not set it to a value that may break OSPF adjacency across the transit. For example, OSPF packets between R2 and R3 traverse two devices, and thus the minimum TTL security hops value should at least be 2. Otherwise, the virtual link between R2 and R4 will fail.

In this example, we set the TTL-security hops to 2 on R2 and R4.

Router R2

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 ttl-security hops 2

Router R4

R4(config)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 ttl-security hops 2

The show ip ospf virtual-links command output below states that the TTL-security check feature is enabled and the maximum hop count allowed is 2.

R2# show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Strict TTL checking enabled, up to 2 hops allowed
    Hello due in 00:00:06
    Adjacency State FULL (Hello suppressed)
    Index 1/1/3, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
  Cryptographic authentication enabled
    Youngest key id is 1

OSPF Virtual Link Authentication

In Cisco IOS, when you activate authentication in the backbone area (area 0), it gets enabled automatically for all virtual links configured on the current router. In this case, either you keep the same authentication for each virtual link or you may implement different authentication types (null, simple password, MD5, or HMAC-SHA).

Moreover, when you enable authentication over an OSPF virtual link, you should set up the same authentication mechanism on both nodes of the virtual link.

Configuring Null Authentication Over a Virtual Link

To configure OSPF null authentication over a virtual link, use the area number virtual-link router_id authentication null command in router configuration mode, where number is the ID of the transit area, and router_id is the router ID of the other end node of the virtual link.

The command must be issued on both ends of the virtual link. This example configures null authentication on the virtual link between R2 and R4.

Router R2

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 authentication null

Router R4

R4(config)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 authentication null

Configuring Plain Text Password Authentication Over a Virtual Link

To add OSPF plain text authentication to a virtual link, use the area number virtual-link router_id authentication authentication-key psswrd command in router configuration mode, where number is the ID of the transit area, router_id is the router ID of the other end node of the virtual link, and psswrd is the shared password between both ends of the virtual link that is used to generate and authenticate OSPF packets.

When simple password authentication is applied over a virtual link, both endpoints of that link should be configured with the same password. In addition, the area virtual-link authentication authentication-key command must be issued on both ends of the virtual link. This example configures plain text authentication over the virtual link between R2 and R4 using the password CISCO.
Router R2

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 authentication authentication-key CISCO

Router R4

R4(config)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 authentication authentication-key CISCO

The following show ip ospf virtual-links command output states that our configuration has been applied successfully.

R2# show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  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)
    Index 1/1/3, retransmission queue length 0, number of retransmission 7
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 0 msec, maximum is 1 msec
  Simple password authentication enabled

Configuring MD5 Authentication Over a Virtual Link

The area area_id virtual-link router_id authentication message-digest and area area_id virtual-link router_id message-digest-key id md5 psswd commands let you enable the OSPF MD5 cryptographic authentication technique over a virtual link, where area_id is the identifier of the transit, router_id is the router ID of the other end of the virtual link, id is the shared secret key’s ID, and psswd is the secret key’s password.

Note that the secret keys configured on both ends of the virtual link should be identical. In these examples, we configure routers R2 and R4 to authenticate the virtual link between them using key 1 and password CISCO.

Router R2

R2(config)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 authentication message-digest
R2(config-router)# area 234 virtual-link 4.4.4.4 message-digest-key 1 md5 CISCO

Router R4

R4(config)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 authentication message-digest
R4(config-router)# area 234 virtual-link 2.2.2.2 message-digest-key 1 md5 CISCO

The show ip ospf virtual-links command output below indicates that MD5 authentication has been applied to the virtual link.

R2# show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  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:04
    Adjacency State FULL (Hello suppressed)
    Index 1/1/3, retransmission queue length 0, number of retransmission 16
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 1 msec, maximum is 1 msec
  Cryptographic authentication enabled
    Youngest key id is 1

Configuring HMAC-SHA Authentication Over a Virtual Link

The area area_id virtual-link router_id authentication key-chain key_chain_name command allows you to enable the OSPF HMAC-SHA cryptographic authentication method over a virtual link, where area_id is the identifier of the transit, router_id is the router ID of the other end of the virtual link, and key_chain_name is a key chain object.

Note that the configurations of the key chain objects on both ends of the virtual link should be the same, but the key ID and password accepted on one end of the virtual link should match the sending key ID and password on the other end.

Here are the steps to configure OSPF HMAC-SHA cryptographic authentication over the virtual link. These steps must be applied on both routers forming the link.

Step 1. Construct a key chain object, using the key chain name command in router configuration mode, where name is a string.

Step 2. Create the secret key’s identifier using the key command in key chain configuration mode.

Step 3. Configure the secret key’s password using the key-string pwd command, where pwd is a string that should not exceed 80 characters.

Step 4. Specify the cryptographic authentication algorithm using the cryptographic-algorithm command.

Step 5. (optional) configure the KeyStartAccept and KeyStopAccept time constants of the key using the accept-lifetime command.

Step 6. (optional) configure the KeyStartGenerate and KeyStopGenerate time constants of the key using the send-lifetime command.

Step 7. Apply the key chain object to the virtual link using the area virtual-link authentication key-chain command.

For more information about the KeyStartAccept, KeyStopAccept, KeyStartGenerate, and KeyStopGenerate constants, read this article about OSPF HMAC-SHA cryptographic authentication.

In the examples below, we configure routers R2 and R4 to activate the OSPF HMAC-SHA authentication method over the virtual link using the HMAC-SHA-512 algorithm, key 1, and password CISCO.

Router R2

R2(config-keychain-key)# router ospf 1
R2(config-router)# area 234 virtual-link 4.4.4.4 authentication key-chain kc1

Router R4

R4(config-keychain-key)# router ospf 1
R4(config-router)# area 234 virtual-link 2.2.2.2 authentication key-chain kc1

To verify the configurations, we issue the show ip ospf virtual-links command, as you can see in this example.

R4# show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 2.2.2.2 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 234, via interface GigabitEthernet0/3
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           2         no          no            Base
  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:04
    Adjacency State FULL (Hello suppressed)
    Index 1/2/3, retransmission queue length 0, number of retransmission 1
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 0 msec, maximum is 0 msec
  Cryptographic authentication enabled
    Sending SA: Key 1, Algorithm HMAC-SHA-512 - key chain kc1

Troubleshooting Steps When an OSPF Virtual Link is Down

OSPF virtual link issues can be caused by several reasons, including the following:

  • Both ends of the virtual link are not attached to the transit area.
  • Misconfigured area id or router ID
  • The transit area is stubby
  • Mismatched hello/dead interval
  • Failed authentication

Here are the steps to troubleshoot an OSPF virtual link is down:

Step 1. Check that both ends of the virtual link are in the transit area.

Step 2. Check that both ends of the virtual link have router LSAs generated by them. Otherwise, check neighbor relationships between the OSPF routers in the path from those endpoints.

Step 3. Check that the area ID used in the area virtual-link command on both routers is the right transit area.

Step 4. Check that the router IDs used in the area virtual-link command on both routers are correct.

Step 5. Check that the transit area is not a stub, totally stubby, NSSA, or totally NSSA area.

Step 6. Check that the hello and dead intervals configured with the area virtual-link command on both routers are identical.

Step 7. Check that authentication is configured correctly.

OSPF Virtual Link vs GRE Tunnel

First, here are the steps to create a GRE tunnel between R2 and R4 in order to connect router R2 to area 0. Since the routers are directly connected, we have to assign IP addresses to the GRE tunnel interfaces.

Step 1. Create a GRE tunnel interface on R2 using the interface tunnel id, where id is a number between  0 and 2147483647.

Step 2. Set the tunnel’s IP address to 10.0.24.2.

Step 3. Set the tunnel source IP address to 10.0.23.2.

Step 4. Set the tunnel destination IP address to 10.0.34.4.

Step 5. Attach the interface to area 0 using the ip ospf area command.

Step 6. Create a GRE tunnel interface on R4 using the interface tunnel id, where id is a number between  0 and 2147483647.

Step 7. Set the tunnel’s IP address to 10.0.24.4.

Step 8. Set the tunnel source IP address to 10.0.34.4.

Step 9. Set the tunnel destination IP address to 10.0.23.2.

Step 10. Attach the interface to area 0 using the ip ospf area command.

Here are the configurations to apply to the routers:
Router R2

R2(config)# interface tunnel 0
R2(config-if)# ip address 10.0.24.2 255.255.255.0
R2(config-if)# tunnel source 10.0.23.2
R2(config-if)# tunnel destination 10.0.34.4
R2(config-if)# ip ospf 1 area 0

Router R4

R4(config)# interface tunnel 0
R4(config-if)# ip address 10.0.24.4 255.255.255.0
R4(config-if)# tunnel source 10.0.34.4
R4(config-if)# tunnel destination 10.0.23.2
R4(config-if)# ip ospf 1 area 0

The following show ip ospf neighbor command output states that R2 and R4 are forming an OSPF adjacency over the GRE tunnel.

R4# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:35    10.0.24.2       Tunnel0
5.5.5.5           1   FULL/DR         00:00:35    10.0.45.5       GigabitEthernet0/5
3.3.3.3           1   FULL/BDR        00:00:35    10.0.34.3       GigabitEthernet0/3

The table below summarizes the differences between OSPF virtual link and GRE tunnel.

Fact Virtual Link GRE Tunnel
By default in the backbone area Yes No
Works across stub areas No Yes
Configured in router configuration mode Yes No
May require configuring IP addressing No Yes
Allows OSPF packets only Yes No
Must be advertised into area 0 manually No Yes

Related Lessons to OSPF Virtual Link

Conclusion

I hope this blog post helps you learn something.
Now I’d like to turn it over to you:
What did you like about this tutorial?
Or maybe you have an excellent idea that you think I need to add.
Either way, let me know by leaving a comment below right now.

Mohamed Ouamer
Mohamed Ouamer
Mohamed Ouamer is a computer science teacher and a self-published author. He taught networking technologies and programming for more than fifteen years. While he loves to share knowledge and write, Mohamed's best passions include spending time with his family, visiting his parents, and learning new things.
Linkedin