OSPF Virtual Link

dppagc

Type 1,2,3 LSAs are flooded across virtual links.
Type 5 and 7 are not flooded.
How about type 4?

Silverymoon

From the RFC:

The virtual link is treated as if it were an unnumbered point-to-
point network belonging to the backbone and joining the two area
border routers. An attempt is made to establish an adjacency over
the virtual link. When this adjacency is established, the virtual
link will be included in backbone router-LSAs, and OSPF packets
pertaining to the backbone area will flow over the adjacency. Such
an adjacency has been referred to in this document as a "virtual
adjacency".

The other details concerning virtual links are as follows:

o AS-external-LSAs are NEVER flooded over virtual adjacencies.
This would be duplication of effort, since the same AS-
external-LSAs are already flooded throughout the virtual link's
Transit area. For this same reason, AS-external-LSAs are not
summarized over virtual adjacencies during the Database Exchange
process.

Type 1,2,3 and 4 LSA's will flow over the virtual link but type 5 will not. Reason is Type 1,2,3, and 4 LSAs have the flooding scope of a single area. Everything that has an area 0 scope will pass over the virtual link, as its a point-to-point link within area 0. Type 7 LSA if I remember correctly will never flood over a virtual link as they only exist in a NSSA or a stuby area. When they hit the ABR they are converted from a type 7 LSA to a type 5 LSA before they enter another area. No type 7 LSA exist in the backbone area 0. They are all converted to a type 5 LSA. As the above information states there is not requirement for these LSA's to pass over a virtual link that the transit network transfers them.


R5#sh ip ospf data


OSPF Router with ID (5.5.5.5) (Process ID 1)


Router Link States (Area 0)


Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 1000 (DNA) 0x80000002 0x0050F5 1
4.4.4.4 4.4.4.4 1 (DNA) 0x80000004 0x007BFB 2
5.5.5.5 5.5.5.5 432 0x80000003 0x005709 1


Net Link States (Area 0)


Link ID ADV Router Age Seq# Checksum
34.34.34.3 3.3.3.3 999 (DNA) 0x80000001 0x00891F


Summary Net Link States (Area 0)


Link ID ADV Router Age Seq# Checksum
13.13.13.0 3.3.3.3 1047 (DNA) 0x80000001 0x00BD42
23.23.23.0 3.3.3.3 1047 (DNA) 0x80000001 0x00548D
45.45.45.0 4.4.4.4 985 (DNA) 0x80000001 0x001B80
45.45.45.0 5.5.5.5 439 0x80000001 0x00FC9A
56.56.56.0 5.5.5.5 439 0x80000001 0x006F07

Summary ASB Link States (Area 0)


Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 1047 (DNA) 0x80000001 0x0057CA

Normally LSA's are removed from LSDB after reaching MaxAge. From the RFC:

12.1.1. LS age


This field is the age of the LSA in seconds. It should be
processed as an unsigned 16-bit integer. It is set to 0
when the LSA is originated. It must be incremented by
InfTransDelay on every hop of the flooding procedure. LSAs
are also aged as they are held in each router's database.

The age of an LSA is never incremented past MaxAge. LSAs
having age MaxAge are not used in the routing table
calculation. When an LSA's age first reaches MaxAge, it is
reflooded. An LSA of age MaxAge is finally flushed from the
database when it is no longer needed to ensure database
synchronization.

LSA's that pass over a virtual link do not age and are marked with a DNA (do not age) bit. Normal ones are re-flooded after 30mins (paranoid update) and removed after 60mins

RFC 1793 OSPF over Demand Circuits April 1995 attached demand circuits (it is still flooded out other interfaces however). This check should be performed in Step 5b of Section 13 in [1]. When comparing an LSA to its previous instance, the following are all considered to be changes in contents: o The LSA's Options field has changed. o One or both of the LSA instances has LS age set to MaxAge (or DoNotAge+MaxAge). o The length field in the LSA header has changed. o The contents of the LSA, excluding the 20-byte link state header, have changed. Note that this excludes changes in LS Sequence Number and LS Checksum.

Source : https://www.rfc-editor.org/rfc/rfc1793.txt