OSPF LSA Header Format
All types of LSA have a 20-byte common LSA header as illustrated in the figure above. The Link-State Advertisement (LSA) is the building block of the OSPF link-state database (LSDB). Its primary function is to advertise a router’s routing topology to other routers. Since OSPF is designed for scalability, some types of LSAs are not flooded out on all interfaces, instead only on those appropriate interfaces. As a result, detailed information can be localized to an area, while summary information is flooded to other areas of the network.
Below describes the various types of Link-State Advertisements (LSAs):
|Router-LSA. Originated from every router to other routers in the same area about the information of its directly connected links to other routers and networks. Type-1 LSAs are flooded within the originating area only. The Link-State ID of a Type-1 LSA is the Router ID of the originating router. The Link-State ID and Advertising Router fields in the LSA header are identical for Router-LSAs.|
|Network-LSA. Originated from the DR on a broadcast or multi-access network (eg: Ethernet) to list all the routers that attached to the transit network. Type-2 LSAs are flooded within the originating area only. The Link-State ID of a Type-2 LSA is the physical interface IP address of the DR that connects to the network and advertises the LSA.|
|Network-Summary-LSA. Originated from an ABR to advertise the subnets in an area (omitting the topological data) to neighboring routers outside the area. ABRs can be configured to summarize and filter the routing information in its LSDBs before sending it to other areas. Route summarization and filtering on ABRs provide greater scalability for OSPF. The Link-State ID of a Type-3 LSA is the IP address of the subnet that is being advertised.|
|ASBR-Summary-LSA. Originated from an ABR that resides within the same area as the ASBR to identify the ASBR and describes the route to the ASBR. Type-5 LSAs are flooded to all areas but the detailed information to reach the ASBR may not be available throughout all areas. This problem is solved by having an ABR to describe the route to the ASBR that originated the Type-5 LSA. The Link-State ID of a Type-4 LSA is the Router ID of the ASBR that is being advertised.|
|AS-External-LSA. Originated from an ASBR and contains information imported into an OSPF routing domain from other routing processes. Type-5 LSAs are flooded throughout all areas except stubby areas, totally stubby areas, and NSSAs. When a stub router receives a Type-5 LSA from another router within the stub area, the LSA will be rejected. The Link-State ID of a Type-5 LSA is the IP address of the external subnet that is being advertised.|
|Group-Membership-LSA. Defined for Multicast extensions to OSPF (MOSPF), a multicast routing protocol that does not receive wide acceptance. Note: Cisco IOS does not support MOSPF, mainly due to the reasons that it uses a dense-mode multicast forwarding scheme and is protocol dependent. A Cisco router would generate a %OSPF-4-BADLSATYPE error message upon receiving a Type-6 LSA. The ignore lsa mospf router subcommand configures an OSPF router to ignore Type-6 LSAs and therefore prevents the router from generating the error message.|
|NSSA-External-LSA. ASBRs in a Not-So-Stubby-Area (NSSA) do not receive Type-5 LSAs from ABRs within the NSSA, but are allowed to advertise external routing information upon route redistribution. They advertise Type-7 LSAs into the NSSAs about the external routes, which the NSSA ABRs then translate to Type-5 LSAs and flood normally throughout all areas except stubby areas, totally stubby areas, and NSSAs. Type-7 LSAs are flooded within an NSSA only.|
|External-Attributes-LSA. Type-8 OSPFv2 LSAs are being used as an alternative to Internal BGP (IBGP) for OSPF and BGP internetworking to carry BGP path attributes across an OSPF routing domain; while Type-8 OSPFv3 link-local scope LSAs advertise information about link-local IPv6 addresses on a link or segment. Note: Cisco IOS does not support Type-8 LSAs.|
|Opaque LSAs (RFC 2370 – The OSPF Opaque LSA Option) are designated to allow the future upgrades or extensions to OSPF for application-specific purposes. An Opaque LSA consists of a standard LSA header followed by information field, which may be used directly by OSPF or other applications. The standard OSPF LSA flooding mechanism distributes Opaque LSAs to all or limited portion of an OSPF routing domain – Opaque LSAs have different flooding scopes. |
Type-9 Link-Local-Opaque-LSA. Type-9 LSAs are flooded within a local link.
Type-10 Area-Local-Opaque-LSA. Type-10 LSAs are typically used for Traffic Engineering extensions to OSPF (RFC 3630) to advertise extra link information besides the metric, namely maximum bandwidth, maximum reservable bandwidth, unreserved bandwidth, and administrative group. Type-10 LSAs are flooded within an area by any OSPF router – both TE capable and non-TE capable routers.
Type-11 Autonomous-System-Opaque-LSA. Type-11 LSAs are flooded throughout all areas except stub areas – equivalent to Type-5 LSAs.
Note: Type-9 through Type-11 Opaque LSAs that are only defined in OSPFv3. Additionally, Opaque LSAs are not used for route calculation but are used for MPLS Traffic Engineering.
The LS Age field is often less than 1800. LSA checksum is performed upon an LSA excluding the LS Age field of the LSA. The Length field indicates the length of an LSA including the 20-byte LSA header.
Type-1 and Type-2 LSAs are found in all areas, and are never flooded across an area boundary. Whether the other types of LSAs are flooded within an area depends on the area types, eg: standard area, backbone area, stub area, totally stubby area, and not-so-stubby area (NSSA).
There is no Type-4 and Type-5 LSAs when there is no ASBR in an OSPF routing domain.