Link-state advertisement
A link-state advertisement (LSA) is a fundamental data packet in the Open Shortest Path First (OSPF) routing protocol, used to convey information about the local state of a router's links, interfaces, or network topology within an autonomous system.[1] Originated by routers, designated routers, area border routers, or autonomous system boundary routers in response to topology changes or periodically for refresh, each LSA includes a standardized header with fields such as LS type, link state ID, advertising router ID, sequence number, and age to ensure uniqueness, freshness, and integrity during propagation.[2] These advertisements are reliably flooded across OSPF areas (or the entire autonomous system for certain types) via link-state update packets, allowing all participating routers to construct and synchronize an identical link-state database that represents the full network topology.[3] By enabling independent shortest-path calculations using Dijkstra's algorithm on this shared database, LSAs facilitate efficient, loop-free routing convergence in large-scale IP networks.[4] OSPF employs several distinct LSA types to encapsulate different aspects of network information, each with specific origins and flooding scopes to optimize information distribution.[5] Type 1 Router-LSAs, generated by every router, detail the router's directly connected links, including costs and neighbor states, and are flooded only within the originating area.[6] Type 2 Network-LSAs, produced by designated routers on multi-access networks like broadcast or NBMA segments, list all attached routers to represent transit networks and are also confined to the area.[7] For inter-area routing, Type 3 Summary-LSAs and Type 4 ASBR Summary-LSAs are created by area border routers to advertise aggregated network routes or paths to external route sources, respectively, flooding them into other areas while suppressing detailed topology.[8] Type 5 AS-external-LSAs, originated by autonomous system boundary routers, describe routes learned from outside the OSPF domain (e.g., via BGP) and are flooded throughout the entire autonomous system, excluding stub areas to prevent overload.[9] Additional types, such as Type 7 NSSA-external-LSAs for not-so-stubby areas, extend this framework by allowing limited external route injection within specific area types, with conversions to Type 5 at area borders.[10] The reliability of LSA propagation is ensured through mechanisms like acknowledgments, retransmissions, and aging, where the LS age field increments during flooding and reaches MaxAge (typically 3600 seconds) for obsolete entries, triggering their removal from databases.[3] During adjacency formation, routers exchange LSAs via a database synchronization process to resolve inconsistencies, using sequence numbers to prioritize newer instances and checksums for error detection.[11] This design supports OSPF's scalability in hierarchical networks, as intra-area LSAs remain localized while inter-area and external information is summarized, reducing bandwidth and computational overhead compared to distance-vector protocols.[12] Extensions in later OSPF versions, such as OSPFv3 for IPv6, retain the LSA core while adapting formats for new address families and adding extensibility through type-length-value encodings.Overview
Definition and Purpose
Link-state advertisements (LSAs) are data structures in link-state routing protocols that encapsulate detailed information about the state of network links, including router interfaces, adjacent neighbors, and associated link costs or metrics.[1] These advertisements serve as the primary mechanism for routers to exchange topology data, enabling the construction and synchronization of a link-state database (LSDB) that provides each router with a complete, consistent view of the network graph.[1] The core purpose of LSAs is to facilitate independent route computation by individual routers, allowing them to calculate loop-free shortest paths to all destinations using algorithms such as Dijkstra's shortest path first (SPF).[1] By disseminating link-state information, LSAs promote rapid convergence to topology changes and mitigate issues like routing loops and slow updates prevalent in distance-vector protocols.[1] LSAs originated in the late 1980s through development by the Internet Engineering Task Force (IETF) OSPF Working Group, evolving from earlier link-state concepts in protocols like the ARPANET's routing system and ISO's IS-IS to overcome the scalability limitations of distance-vector approaches such as RIP.[1] The first specification appeared in RFC 1131 for OSPF Version 1 in October 1989. In general, LSAs are reliably flooded across designated scopes—such as routing areas or entire autonomous systems—to ensure ongoing topology awareness and database synchronization among participating routers.[1]Role in OSPF Protocol
Link-state advertisements (LSAs) play a central role in the Open Shortest Path First (OSPF) protocol by enabling routers to build and maintain a consistent view of the network topology within defined areas. OSPF organizes routers into a hierarchical structure of areas, with the backbone Area 0 serving as the core for inter-area routing; LSAs are confined to individual areas to limit the scope of flooding and reduce overhead, while Area Border Routers (ABRs) summarize and advertise inter-area routes into the backbone using aggregated LSAs, ensuring efficient propagation across the autonomous system (AS).[13][14] The flooding process begins with routers originating LSAs to describe their local links and networks, which are then disseminated throughout the area (or the entire AS for certain external LSAs) via Link State Update (LSU) packets; this reliable multicast or unicast transmission on point-to-point links ensures delivery, with mechanisms such as explicit acknowledgments and retransmissions at configurable intervals (e.g., every 5 seconds by default) preventing loss and guaranteeing synchronization.[3][15] During adjacency formation between neighboring routers, the link-state database (LSDB) is synchronized through an exchange of Database Description (DBD) packets, which provide summaries of each router's LSDB contents including LSA headers to detect discrepancies; missing or outdated LSAs are then requested via Link State Request (LSR) packets, prompting the sender to reply with the necessary LSU packets for database alignment.[16][17] To manage data freshness and prevent the accumulation of obsolete information, each LSA includes a 16-bit Age field initialized to 0 and incremented periodically (every second in the LSDB and by the interface transmit delay during flooding), with a maximum value of 3600 seconds (1 hour) after which the LSA is considered stale and flooded for removal; originators refresh LSAs every 30 minutes (LSRefreshTime) or immediately upon detecting topology changes to maintain accuracy.[18][19] LSAs are versioned using a 32-bit signed sequence number that wraps around, starting at 0x80000001 for newly originated instances and incrementing with each update to determine recency—higher numbers indicate newer LSAs, with the maximum value of 0x7FFFFFFF triggering premature aging to avoid overflow.[20][21]LSA Types
Standard Types in OSPFv2
In OSPFv2, link-state advertisements (LSAs) are categorized into standard types that facilitate the exchange of routing information within and between areas of an autonomous system (AS). These types primarily handle intra-area topology, inter-area summaries, and external route propagation, each with defined scopes to optimize flooding and reduce overhead.[1] The standard types include Router-LSAs (Type 1), Network-LSAs (Type 2), Summary-LSAs (Types 3 and 4), AS-External-LSAs (Type 5), and NSSA External-LSAs (Type 7), all sharing a common 20-byte LSA header that includes fields like LS age, type, and sequence number for synchronization.[1] Type 1: Router-LSARouter-LSAs are originated by each router within an area to describe its local state, including directly attached links such as point-to-point, stub, and transit connections, along with associated metrics and link types.[1] These LSAs list the router's interfaces, neighbor adjacencies, and costs, enabling other routers to construct a complete intra-area topology map.[1] Flooded only within the originating area, they form the foundation for shortest-path calculations inside that area.[1] Type 2: Network-LSA
Network-LSAs are generated by the Designated Router (DR) on multi-access networks, such as broadcast or NBMA segments, to represent the network segment and enumerate all fully adjacent routers connected to it.[1] Key contents include the DR's IP interface address, network mask, and a list of attached router IDs, which collectively describe the transit network's topology without requiring each router to advertise its own connections redundantly.[1] Like Type 1 LSAs, they are flooded solely within the originating area to maintain efficient intra-area synchronization.[1] Type 3: Network-Summary-LSA
Network-Summary-LSAs, also known as Summary-LSAs for IP networks, are produced by Area Border Routers (ABRs) to advertise aggregated intra-area routes to other areas as summarized prefixes, including the destination network address, mask, and path cost.[1] This inter-area advertisement allows routers in receiving areas to learn about external networks without full topology details, promoting scalability across the AS.[1] They are flooded throughout the destination area but excluded from stub areas to prevent unnecessary external information.[1] Type 4: ASBR-Summary-LSA
ASBR-Summary-LSAs are originated by ABRs to inform routers in non-backbone areas about the location and reachability of Autonomous System Boundary Routers (ASBRs), specifying the ASBR's Router ID and the cost to reach it.[1] These LSAs enable proper routing to external destinations by providing a path summary to the ASBR that injects external routes.[1] Flooding scope mirrors Type 3 LSAs, limited to the destination area other than stub configurations.[1] Type 5: AS-External-LSA
AS-External-LSAs are generated by ASBRs to flood external route information domain-wide, describing destinations outside the AS (or default routes) with details like the network prefix, mask, metric (Type 1 for additive costs or Type 2 for fixed costs), forwarding address, and route tag for policy routing.[1] They support integration of routes from external protocols like BGP, ensuring AS-wide visibility while allowing metric comparisons for path selection.[1] These LSAs propagate throughout the entire AS, except in stub areas where external routes are suppressed.[1] Type 7: NSSA External-LSA
NSSA External-LSAs extend OSPFv2 for Not-So-Stubby Areas (NSSAs) by allowing ASBRs within such areas to advertise external routes using a format nearly identical to Type 5 LSAs, including prefix, metric type, forwarding address, and a propagate (P) bit to signal translation needs.[10] Originated by NSSA ASBRs, they enable limited external route injection in stub-like areas without compromising their efficiency.[10] Flooded only within the originating NSSA, with ABRs optionally translating them to Type 5 LSAs for further propagation if the P bit is set.[10]
| LSA Type | Scope | Primary Role |
|---|---|---|
| Type 1 (Router-LSA) | Intra-area | Local router links and metrics |
| Type 2 (Network-LSA) | Intra-area | Multi-access network attachments |
| Type 3 (Network-Summary-LSA) | Inter-area | Summarized intra-area routes |
| Type 4 (ASBR-Summary-LSA) | Inter-area | ASBR reachability summaries |
| Type 5 (AS-External-LSA) | AS-wide | External route advertisements |
| Type 7 (NSSA External-LSA) | Intra-NSSA (translatable to AS-wide) | External routes in NSSAs |
Opaque and Extended Types
In addition to the standard link-state advertisements (LSAs) used for core routing in OSPFv2, extended types provide support for specialized functions, including deprecated multicast extensions and flexible opaque mechanisms for protocol enhancements.[22] Type 6 LSAs, known as Group Membership LSAs, were introduced for Multicast OSPF (MOSPF) to advertise multicast group memberships within an area, enabling routers to compute multicast shortest paths based on unicast topology information. Defined in RFC 1584, these LSAs carried vertex and prune information for multicast trees but were primarily experimental and limited to intra-area multicast routing. MOSPF is rarely implemented and unsupported by major vendors like Cisco, which prefer Protocol Independent Multicast (PIM) as the standard multicast routing solution. As such, Type 6 LSAs are effectively obsolete in practice but remain defined in OSPFv2 specifications.[23] Opaque LSAs, designated as types 9, 10, and 11, represent a class of extensible advertisements that allow OSPFv2 to carry application-specific data without altering the core protocol, using a flexible format to support advanced features like traffic engineering.[24] Standardized in RFC 2370 (1998) and updated in RFC 5250 (2008), these LSAs share a common structure: a standard 20-byte LSA header followed by a 32-bit opaque ID (uniquely identifying the advertisement's purpose within its scope) and a variable-length opaque data field, typically encoded in Type-Length-Value (TLV) tuples for extensibility.[24] [22] The flooding scope varies by type: Type 9 is link-local, confined to a single interface for advertising local interface parameters; Type 10 is area-local, flooded throughout an OSPF area for intra-area extensions; and Type 11 is autonomous system (AS)-wide, propagated across the entire routing domain except stub areas, suitable for inter-area or global information.[24] [22] A primary application of opaque LSAs is in MPLS Traffic Engineering (TE), where Type 10 LSAs advertise link parameters such as maximum bandwidth, reservable bandwidth, and unreserved bandwidth to enable constraint-based path computation for TE tunnels within an area.[25] Similarly, Type 11 LSAs support Generalized MPLS (GMPLS) extensions for AS-wide TE, including inter-domain routing enhancements like optical link attributes or virtual network topologies.[25] [22] More recent extensions, such as the OSPFv2 Extended Link Opaque LSA (effectively leveraging Type 9 for prefix and link attribute advertisement), further utilize this framework to associate additional attributes like extended communities with routes, as defined in RFC 7684 (2015).[26] These opaque and extended types maintain backward compatibility with standard LSAs by ignoring unrecognized data, ensuring OSPF routers can flood them without disrupting unicast routing while enabling incremental deployment of new capabilities.[24]OSPFv2 Implementation
Packet Exchange Process
The packet exchange process in OSPFv2 facilitates the synchronization of link-state databases (LSDBs) between neighboring routers, ensuring consistent topological knowledge within an area. This process occurs during the formation of adjacencies, which progress through seven distinct states: Down, Init, 2-Way, ExStart, Exchange, Loading, and Full.[27] In the Down state, no communication exists, and the interface is unusable, with all timers disabled.[27] The Init state begins upon receiving a Hello packet, detecting the neighbor but lacking bidirectional confirmation.[27] Bidirectional communication is established in the 2-Way state, where the Designated Router (DR) and Backup DR are selected among neighbors in this state or higher.[27] The ExStart state negotiates the master/slave relationship and sets the initial Database Description (DBD) sequence number, marking the start of LSDB synchronization.[27] LSA exchanges primarily occur in the subsequent Exchange and Loading states, culminating in the Full state where databases are synchronized and the adjacency is operational.[27] During the Exchange state, routers exchange DBD packets to summarize their LSDB contents, listing headers of all LSAs in the area (including router-LSAs, network-LSAs, summary-LSAs, and AS-external-LSAs, excluding those in stub areas).[27] Each DBD packet includes key flags: the I-bit set to 1 for the initial packet to start the exchange, the M-bit set to 1 if more DBD packets follow (0 for the last), and the MS-bit set to 1 for the master router (which controls sequence numbering) or 0 for the slave.[27] The master sends the first DBD with I, M, and MS bits set, and the slave echoes the sequence number to acknowledge receipt.[27] By comparing DBD summaries, routers identify discrepancies such as missing or outdated LSAs, triggering the transition to the Loading state if requests are needed; otherwise, they advance directly to Full.[27] DBD packets are explicitly acknowledged through sequence number echoing, with only one outstanding at a time to maintain order.[27] In the Loading state, the router with identified discrepancies sends Link State Request (LSR) packets to request specific LSAs, specifying each by LS type, Link State ID, and Advertising Router fields.[27] Multiple LSRs can be batched, and unsatisfied requests are retransmitted at intervals defined by the RxmtInterval parameter (default 5 seconds) until resolved or an error occurs, such as the BadLSReq event that tears down the adjacency.[27] The receiving neighbor responds with Link State Update (LSU) packets, each carrying one or more full LSAs matching the requests.[27] LSU packets are also used for flooding new or updated LSAs beyond initial synchronization: on multi-access networks, they are multicast to AllSPFRouters (224.0.0.5) or AllDRouters (224.0.0.6) depending on the router's DR role, while point-to-point or NBMA networks use unicast.[27] Flooding propagates LSAs one hop further from the originating router, with each LSA's age incremented by the InfTransDelay (typically >0 seconds) per transmission to track propagation.[27] Received LSAs are validated via checksum and age before installation in the LSDB and further flooding.[27] Reliable delivery is ensured through Link State Acknowledgment (LSAck) packets, which confirm receipt of LSAs in LSU packets.[27] Acknowledgments can be explicit, via a dedicated LSAck packet containing LSA headers (multicast on broadcast networks or unicast otherwise, potentially delayed for grouping), or implicit, by including the LSA header in the neighbor's own subsequent LSU or DBD packet.[27] Each LSA requires individual acknowledgment; on multi-access networks, Backup DRs may delay explicit acks to allow DRs to handle them first.[27] Unacknowledged LSAs are added to a neighbor's retransmission list and resent every RxmtInterval (default 5 seconds), with the process continuing until confirmation or the LSA reaches MaxAge.[27] This mechanism prevents unnecessary retransmissions after successful delivery, typically within 5 seconds of the initial transmission.[27] Once all requests are satisfied and acknowledgments complete, the adjacency reaches the Full state, enabling full LSDB synchronization and routing computations.[27]Common LSA Header Structure
All Link State Advertisements (LSAs) in OSPFv2 share a fixed 20-byte common header that provides essential metadata for identification, versioning, integrity verification, and flooding control within the OSPF routing domain. This header precedes the type-specific LSA body and is crucial for routers to process and synchronize link-state databases efficiently. The structure ensures that LSAs can be uniquely identified, aged appropriately during propagation, and validated against corruption or obsolescence.[2] The header fields are as follows:| Field | Size (bits) | Purpose and Details |
|---|---|---|
| LS Age | 16 | An unsigned integer representing the time in seconds since the LSA's origination. It starts at 0 and increments by the interface's InfTransDelay value (default 1 second) at each hop during flooding to account for transmission delays. The maximum value is MaxAge (3600 seconds), after which the LSA is considered expired, reflooded for removal, and flushed from databases to prevent stale information. This aging mechanism adds robustness by ensuring periodic updates and timely removal of outdated LSAs.[19][3][18] |
| Options | 8 | An 8-bit field indicating optional capabilities associated with the LSA. Defined bits include: Bit 0 (V-bit, set to 1 for OSPF version 2 support); Bit 1 (E-bit, set to 1 if the LSA pertains to external routing capabilities, such as in non-stub areas or AS-external-LSAs, and reset to 0 in stub areas); Bit 2 (B-bit, set to 1 if the LSA describes an area border router). Bits 3-7 are reserved and must be set to 0 when originating an LSA; unrecognized bits are ignored upon receipt to maintain compatibility. These bits provide informational cues about the routing domain's features but do not directly alter shortest-path calculations.[28][29] |
| LS Type | 8 | An unsigned integer identifying the LSA's type, which determines its format, flooding scope, and function. Standard values range from 1 (Router-LSA) to 5 (AS-external-LSA), with additional types up to 11 defined in extensions; types 1-4 flood area-wide, while type 5 floods AS-wide except in stub areas.[30][11] |
| Link State ID | 32 | A 32-bit identifier that, in combination with LS Type and Advertising Router, uniquely specifies the piece of the routing domain described by the LSA. Its interpretation varies by type: for example, the originating Router ID for type 1, or the destination network address for types 3 and 5.[31][32] |
| Advertising Router | 32 | The OSPF Router ID (a 32-bit unique identifier) of the router that originated the LSA. For router-LSAs (type 1), this matches the Link State ID.[30] |
| LS Sequence Number | 32 | A signed 32-bit integer tracking the LSA's version to detect newer instances and discard duplicates or obsolete ones. It initializes to 0x80000001 and increments monotonically with each update (up to 0x7FFFFFFF), after which the LSA is flushed and reoriginated. Higher sequence numbers indicate fresher LSAs when checksums match.[20] |
| LS Checksum | 16 | A 16-bit Fletcher checksum computed over the entire LSA, excluding the LS Age field, to verify data integrity against transmission errors. It must be non-zero and is recalculated upon receipt; mismatches trigger LSA discard. Excluding LS Age allows aging without invalidating the checksum. Verification occurs on reception and periodically (e.g., every CheckAge interval of 5 minutes).[33][21] |
| Length | 16 | An unsigned integer specifying the total LSA length in bytes, including the 20-byte header, enabling routers to parse the complete LSA correctly.[34] |
OSPFv2 LSA Formats
Router and Network LSAs
Router-LSAs, designated as Type 1 in OSPFv2, are originated by each router to describe its local state, including the router's directly attached links and their associated costs within an OSPF area. These LSAs form the foundational building blocks of the intra-area topology database, enabling other routers to construct a complete map of the area's network infrastructure. The LSA header, common to all OSPFv2 LSAs, precedes the body and includes fields such as LS age, options, LS type, link state ID (the originating router's ID for Type 1), advertising router ID, LS sequence number, LS checksum, and length.[2] Following the header, the Router-LSA body begins with optional capability flags: the V bit indicates if the router is an endpoint of a virtual link, the E bit marks it as an AS boundary router, and the B bit identifies it as an area border router. The core of the body is a 16-bit field specifying the number of links (ranging from 0 to 65535, though typically fewer), followed by a variable-length list of per-link descriptions. Each link entry consists of a 32-bit Link ID (identifying the neighbor router ID for point-to-point or virtual links, the designated router's interface address for transit links, or the IP network number for stub links), a 32-bit Link Data field (the router's own interface IP address for point-to-point, transit, or virtual links, or the subnet mask for stub links), an 8-bit Link Type (1 for point-to-point connections to a neighboring router, 2 for connections to transit networks, 3 for stub networks without further attachments, and 4 for virtual links), and a 16-bit Metric field representing the output cost on the link for TOS 0 (Type of Service 0, with higher TOS metrics optional but not used in basic implementations).[6] The link types reflect distinct network topologies: point-to-point links directly connect two routers without intermediate devices, using the metric as the cost to reach the neighbor; transit links connect to multi-access networks like Ethernet, where the Link ID points to the designated router and the metric indicates the cost to that network segment; stub links represent terminal networks or host attachments without transit capability, often with a non-zero metric to denote the cost to the attached subnet; virtual links, used to extend an area through a transit area, mimic point-to-point but traverse non-backbone areas. These details allow routers to model adjacencies and calculate shortest paths accurately. Both Router-LSAs and Network-LSAs have an intra-area flooding scope, meaning they are flooded only within their originating OSPF area to maintain area isolation and scalability.[6][17] Network-LSAs, designated as Type 2 in OSPFv2, are originated exclusively by the designated router (DR) on transit multi-access networks (such as broadcast or NBMA segments) to enumerate all routers fully adjacent to that network segment. Unlike Router-LSAs, which describe a single router's perspective, Network-LSAs provide a collective view of the network's attachments, preventing redundant link descriptions in the topology database. The Link State ID in the header is set to the DR's IP interface address on the network.[7] After the header, the body starts with a 32-bit Network Mask field specifying the subnet mask of the transit network (e.g., 255.255.255.0 for a /24 segment). This is followed by a 16-bit field indicating the number of attached routers (up to 65535, listing only fully adjacent OSPF neighbors), and then a sequence of 32-bit OSPF Router ID fields for each attached router, including the DR itself. No metrics are included, as costs to the network are derived from the corresponding Router-LSAs of the attached routers. These LSAs are also flooded intra-area only, complementing Router-LSAs to fully define multi-access topologies without duplication.[7] For example, consider a router with Router ID 192.168.1.1 connected to a stub subnet 10.0.1.0/24 (metric 10) and a transit Ethernet segment 192.168.2.0/24 (metric 5 to the DR at 192.168.2.1). Its Router-LSA would list two links: one with Link ID 10.0.1.0, Link Data 255.255.255.0, Type 3 (stub), and Metric 10; the other with Link ID 192.168.2.1, Link Data 192.168.2.2 (its interface IP), Type 2 (transit), and Metric 5. On the transit segment, the DR might originate a Network-LSA with Network Mask 255.255.255.0, three attached routers (e.g., IDs 192.168.1.1, 192.168.2.1, and 192.168.2.3), ensuring the topology graph connects all participants efficiently.[6][7]Summary and External LSAs
In OSPFv2, Summary Link-State Advertisements (Type 3 LSAs) are originated by Area Border Routers (ABRs) to advertise inter-area routes for networks or aggregate prefixes to routers within a single area, enabling summarization of intra-area routes from other areas.[36] These LSAs follow the standard LSA header and include a 32-bit Network Mask field to define the destination prefix, followed by Type of Service (TOS) metrics, where the primary 24-bit field specifies the metric for TOS 0 (with additional TOS metrics optional but rarely used in modern implementations), typically the default IP precedence.[36] The metric represents the cost to reach the destination, expressed in the same units as OSPF interface costs (ranging from 1 to 65,535), and these LSAs are flooded area-wide but not into stub or Not-So-Stubby Areas (NSSAs) to prevent external route propagation.[36] Type 4 LSAs, known as ASBR Summary LSAs, are also generated by ABRs to inform routers within an area about the location and reachability of an Autonomous System Boundary Router (ASBR) in another area, using the ASBR's Router ID as the Link State ID.[36] After the LSA header, the Network Mask field is unused and set to 0.0.0.0, followed by a 24-bit metric field indicating the cost to the ASBR, again with optional TOS metrics for compatibility.[36] This allows routers to compute paths to external routes advertised by the ASBR without flooding full external details into the area, with the same area-flooding scope as Type 3 LSAs and exclusion from stub areas.[36] AS External LSAs (Type 5) are produced by ASBRs to propagate routes from outside the OSPF Autonomous System (AS) throughout the entire AS, excluding stub and totally stubby areas, using the external network's IP address (or 0.0.0.0 for a default route) as the Link State ID.[36] The format begins with a 32-bit Network Mask for the destination prefix, followed by the 32-bit E_ExternalMetric field, which includes a 24-bit metric (bits 0-23) and flags: bit 26 (E-bit) for metric type (0=Type 1 additive, 1=Type 2 external-only); bit 25 (F-bit) for non-zero Forwarding Address presence; bit 24 (T-bit) for External Route Tag presence; bits 27-31 reserved.[36] A 32-bit Forwarding Address field follows (set to 0.0.0.0 if none, otherwise specifying an intra-AS next hop for optimal forwarding), and a 32-bit External Route Tag provides policy information, such as for route redistribution from BGP.[36] Optional TOS metrics are included for legacy support. Type 1 metrics add the external cost to the intra-AS path cost for comparable internal-external routing, while Type 2 metrics prioritize the external cost alone (with intra-AS cost as a tiebreaker), serving as the default for redistributed routes like those from BGP.[36] For Not-So-Stubby Areas (NSSAs), which allow limited external route injection while blocking standard Type 5 LSAs, Type 7 LSAs (NSSA External LSAs) are used by ASBRs within the NSSA to advertise external routes, mirroring the Type 5 format but restricted to NSSA flooding.[10] After the header, the structure includes the 32-bit Network Mask, E_ExternalMetric with E-bit, F-bit, and T-bit as in Type 5, plus a P-bit (bit 4 in the Options field of the LSA header) to request translation to Type 5 by the ABR if set.[10] The Forwarding Address (32-bit, non-zero when P-bit is set) and External Route Tag (32-bit) follow, supporting the same Type 1 and Type 2 metrics.[10] ABRs translate selected Type 7 LSAs (preferring those with P-bit set) into Type 5 LSAs for propagation beyond the NSSA, ensuring external routes reach the rest of the AS without compromising the area's stub-like properties.[10]| LSA Type | Key Purpose | Flooding Scope | Metric Types Supported | Notable Flags/Fields |
|---|---|---|---|---|
| Type 3 (Summary) | Inter-area prefix summarization | Single area | Type 1 (additive) | Network Mask (32-bit), TOS metrics |
| Type 4 (ASBR Summary) | ASBR reachability | Single area | Type 1 (additive) | Network Mask (0), metric to ASBR |
| Type 5 (External) | AS-external routes | Entire AS (except stubs) | Type 1 (additive), Type 2 (external only) | E/F/T-bits, Forwarding Address, Route Tag |
| Type 7 (NSSA External) | External routes in NSSA | NSSA only (translated to Type 5) | Type 1 (additive), Type 2 (external only) | P-bit, E/F/T-bits, Forwarding Address, Route Tag |