OSPF type-1 and type-2 LSAs

Updated: Mar 1, 2019


OSPF has the following LSA types:


Type 1, router LSA

Type 2, network LSA

Type 3, summary LSA

Type 4, ASBR-summary LSA

Type 5, external LSA

Type 7, NSSA

Type 9-11, opaque LSAs (used for MPLS TE, etc)


Type-1 and type-2 LSA


- this is the router LSA. It is used to describe the state and the cost of links of a router in the area. All the routers links must be described in a single router LSA.

- this is flooded throughout the area and does not cross over into another area.

- this LSA also includes flags to indicate whether a router is performing special functions (such as that of an ABR, ASBR).

- the purpose of this LSA is two fold:

  1. to assist in creating a graph of all routers in an area so that SPF can be run over it to find the shortest path to each node/router.

  2. to provide reachability information about directly connected networks for each router.


*** Remember that the point of SPF is to find the shortest path to different nodes in the area and not to the actual routes/networks themselves. The logic behind this is that if I find the shortest path to a node, I automatically find the shortest path to the networks owned by that node. With OSPF, you only find the shortest path to all nodes within the same area. You don’t care about what exists outside the area. Again, the logic behind this is based on how recursive routing works - say route to A points to B, route to B points to C and route to C finally leads you to the exit interface. So by recursive properties, route to A leads to exit interface. In the same way, for external routes, if we can find the shortest path to the ABR, we would find the shortest path to the external routes themselves ***


Let’s take a look at how the OSPF database looks like on R1. To get a high level overview of all the LSAs stored in the database, we can use the command ‘show ip ospf database’.



To look at the router LSAs, use the command ‘show ip ospf database router <router-ID>’. You can also use ‘show ip ospf database router self-originate’ to look at the LSAs generated by the local router. In short, this LSA gives the router an understanding of every other OSPF running router in the same area and all networks that it is connected to.


Looking at the OSPF database on R1, we see that R1 knows about 6 router IDs in the area - 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5 and 6.6.6.6. To build the graph, the router is required to inpect each of these LSAs more closely. Let’s go ahead and do that.



There are two attributes associated with the description of links here. One is the link ID and the other is the link data. What these two describe changes with the type of link.

- for a stub link, the link ID describes the IP network and the link data describes the subnet mask.


- for a point-to-point link, we generate two subtypes - one stub link and one point-to-point link. The stub link describes the network and mask of the link, while the point-to-point link has the link ID describing the neighboring routers router ID and my local IP address for that link. The reason for generating two subtypes is that in the point-to-point subtype, we only describe the router ID of the neighbor and the local IP address. We still need to describe the actual network and the subnet mask. In order to describe that, the additional stub type is created.

- for a transit link, the link ID is the DRs IP address for that segment while the link data is the local routers IP address for that segment.


For R1s router LSA, we cannot recurse any further since all we have our stub networks and point-to-point networks (which are described with the help of another stub link).


Let’s look at R2s router LSA now.



We have a stub network for R2s loopback (2.2.2.2/24), a point-to-point + stub link for the serial link going to R3, a point-to-point + stub network for the serial link going to R1 and finally a transit link. A transit link requires recursion into the type-2 LSA, so let’s hold our thoughts and get to that piece once we look at type-2 LSAs.


Moving on to R3, we see the following in its router LSA.



Nothing new here - a stub link describing R3s loopback and a point-to-point + stub link describing the serial link going to R2. Notice how the serial link going to R7 is not described here. This is because that is in a different area and router LSAs are unconcerned with what is in a different area. Also look at how the ABR flag is set in R3s router LSA. This is letting everyone know that R3 is an ABR.


Let’s move on to R4, R5 and R6 now.





Each of these routers are describing their transit link, with the DRs IP address as well as their local IP address that connects to this transit segment. We’ve now looked at all the router LSAs in this area.


I had stated earlier that for a transit link, it is necessary to recurse to the type-2 LSA, so let’s take a look at that now.



The DR of a transit segment generates a type-2 LSA. A simple example of a transit segment would be a broadcast network type. This LSA describes all routers attached to this transit link. This LSA, like the router LSA, is flooded throughout the area but does not cross over to any other areas.


The LSA itself describes multiple things:

- it contains the IP address of the DR as a link state ID.

- the subnet mask.

- the router ID of the DR (which is the advertising router).

- router IDs of all routers attached to this segment.


To zoom into a type-2 LSA, we can use the command ‘show ip ospf database network <DRs IP address>’. Alternatively, you can use ‘show ip ospf database network adv-router <router ID of DR>’. We know the DRs IP address for the transit segment is 10.1.245.4 (from the router LSAs).



We are then required to recurse back to the type-1 LSAs of all the router IDs listed here to continue building the graph.


This concludes type-1 and type-2 LSAs.

3 comments

For any queries, concerns or conversations, please email contact@theasciiconstruct.com