OSPF Virtual Links

In a previous post (OSPF Areas and Area Types), I have mentioned that Area 0 is the backbone Area.   In a multi-area OSPF autonomous system, all areas must be connected to the backbone area Zero (0), otherwise, no inter-area communications are possible.  Now, since Area 0 is the backbone, it must be a contiguous area.

In situations where is not possible to connect an area with the Backbone, OSPF Virtual links enter to play.

Let’s take a look to the following topology:


In this example, R1 has a link in Area 0 and other in Area 123. R1 is acting as ABR between area 0 and routers in area 123.    Area 123 is configured as a normal area.

R2 has routes from Area 0 advertised from R1 (ABR) as Type-3 LSAs and also has routes from within the area 123 (Type-1 and 2 LSAs); however it does not have any route or paths to R4 networks.

R3 like R2 has routes from Area 0 advertised from R2 (ABR) as Type 3 LSA, also has routes from within the area 123 (Type-1 and 2 LSAs); also has routes within the area 34 (Type 1 and 2 LSAs).   R3 does not have a link in Area 0; therefore, it is not an ABR (Which is a requirement to be an ABR).  Then it cannot generate Type-3 LSAs nor advertise networks to and from R4.

Finally, R4 has routes of area 34 (if any) but has no route for networks in areas 0 or area 123.

To solve this problem Virtual-links and GRE tunnels can be used, however, there are some “disadvantages” using GRE over Virtual Links which worth mentioning:

  • Encapsulation overhead.
  • GRE is process-switched.
  • GRE require more configurations.
  • Routing LSAs and Data traffic are encapsulated in GRE.

Now GRE over Virtual-Links has a big advantage which worth to mention:  With GRE the transit area can be of any Type, meaning that supports Stub Areas and its variants.

A Virtual Link is an OSPF tunnel, a multi-hop point-to-point unicast adjacency; it is, in essence, an extension of Area 0 across (transit area) another area.   In the previous example, area 123 is the transit area between area 0 and area 34.


There are some restrictions that I have to mention:

  • The transit area cannot be any type of stub area.
  • The transit area shouldn’t have filtering configured.
  • If a change is done on one side of the virtual link, the change must be replicated on the other end. For example, adding authentication or changing hello/dead timers must be done on both sides of the Virtual Link.

The virtual link must be defined between the ABR and the node connecting the discontiguous area (transit area).  To create the virtual link use the command area x virtual-link [Router-ID].


Virtual links support additional features such authentication, hello/dead interval tuning and TTL-security.  I will discuss this features in further posts.

Finally, there are some additional considerations to keep in mind when working with Virtual Links:

  • When configured a P2P logical interface is created with state P2P and attached to Area 0.
  • The default Timers of the Virtual Link interface is Hello 10 / Dead 40. However, the Hello packets in Virtual Links are suppressed by default.
  • Virtual Links calculate its cost based on the cost of the Router connecting the discontiguous networks to the ABR.
  • Virtual Links runs as a demand circuit. Misconfigurations in Virtual Links could not be detected until LSA flooding occurs.   This is because LSAs originated by ABRs don’t age by default as occurs in LSAs originated for standard areas (30 mins by default).
It is time to close this post. Thank you for visiting.


This post will cover only LSA Types for OSPFv2.  The OSPFv3 LSAs will be covered in further posts.

In order to fully understand how OSPF works is necessary understand of all of the OSPF LSA types.

Type 1 – Router LSA

Type 1 LSA is generated by every router and contains information about directly connected links in the area.

  • Describe the state of all router interfaces and their cost of the link to the neighbor and the IP prefix.
  • The ADV Router will always be the Router ID of the device injecting the LSA into the area.

Type 2 – Network LSA

Type 2 LSAs are present only on multi-access links for Broadcast and Nonbroadcast network types.

  • Generated by the DR and is never flooded outside of the area.
  • Lists all attached routers including the DR.
  • Gives information about the subnet mask on that segment.

Type 3 – Network Summary LSA

Type 3 LSAs describes the routes to neighbors outside the area (inter-area routes) but within the OSPF domain.

  • Generated by ABRs and is flooded between areas.
  • Include cost from ABR to the network.
  • The Link-State ID is the IP address of the subnet that is being advertised.

Type 4 – ASBR Summary LSA

Type 4 LSAs describes the routes to ASBRs.

  • Generated by the ABRs and is flooded between areas except stub areas.
  • The Link-State ID is the Router ID of the ASBR described.

 Type 5 – External LSA

Type 5 LSAs describes the routes to networks that are external to the AS.

  • Generated by ASBR and is flooded between areas.
  • The Link-State ID is network number advertised in the LSA.

Type 6 – Multicast OSPF LSA

This type of LSA is used for multicast applications and is not supported by Cisco.  However, the presence of Type 6 LSAs generates Syslog messages when the router receives the link-state advertisements.   To suppress the Syslog messages use the “ignore lsa mospf” process command.

Type 7 – NSSA External LSA

Type 7 LSAs describes the routes that are external to the AS in the NSSA area.

  • Generated by NSSA ASBR
  • The ABR translate LSA type 7 to LSA type 5 when sends from NSSA into Area Zero.

It is time to close this post. Thank you for visiting.