skip to content

What does an OSPFv3 Link-LSA carry, why is it flooded only on its own link, and which routers use it?

level: seniorimportance: nice to knowfreq 9%

answer

  1. three purposes, one link
  2. the next-hop address
  3. prefixes for the DR to collect
  4. Options for the network-LSA
  5. NBMA routers may never exchange Hellos

basics

~20 s

An OSPFv3 Link-LSA (LS type 0x0008) carries a router's link-local address, the IPv6 prefixes on that link, its priority and the Options it wants in the DR's network-LSA. Only routers on that link use these, so it never leaves the link.

solid answer

~40 s

Each OSPFv3 router originates one **Link-LSA** for every attached link with at least one other router, with its `Interface ID` as the Link State ID. It carries the router's `Rtr Priority`, an `Options` field, its **link-local interface address** and the **prefixes** configured on the link. RFC 5340 gives it three purposes: it tells the other routers on the link the address to use as a next hop, which matters on NBMA links where routers need not exchange Hellos; it gives the DR the prefixes it copies into the link's Intra-Area-Prefix-LSA; and it supplies the Options bits the DR ORs into the network-LSA. Its scope is the link alone because nobody else needs this. In OSPFv2 the equivalent interface addresses rode in the router-LSA and were flooded across the area although only neighbours used them.

go deeper

for a junior

Recall that the Link-LSA is an OSPFv3 LSA that stays on one link and carries the router's link-local address and the link's prefixes.

for a middle

Name its three purposes, next hop, prefixes for the DR and Options for the network-LSA, and explain why link-local scope is enough for each.

for a senior

Use it to reason about failures: a prefix missing area-wide because its router is not Full with the DR, or next-hop resolution on NBMA links where Hellos are not exchanged.

for a principal

Weigh link-scoped state against area-wide flooding as a general design rule: what belongs only to the neighbours that use it, and what the suppression option trades away.

## What a Link-LSA is The **Link-LSA** is one of the two LSA types RFC 5340 added for OSPFv3. Its LS type is `0x0008`: the scope bits are `00`, meaning **link-local flooding scope**. A router floods its Link-LSA on the link it describes, and the routers that receive it do not flood it on to their other links. A router originates a separate Link-LSA for every attached link that has two or more routers on it, counting itself, and RFC 5340 says it should not originate one for a virtual link. | Field | Contents | |---|---| | Link State ID | the originating router's `Interface ID` on the link | | `Rtr Priority` | the router's priority on this link | | `Options` | the Options bits the router wants set in the link's network-LSA | | Link-local Interface Address | the router's link-local address on this link | | `# prefixes` and the prefix list | every IPv6 prefix configured on this link, as length, options and prefix | ## Purpose 1: the next-hop address OSPFv3 forwards to neighbours by their **link-local** addresses. When a router computes a route whose next hop is another router on a shared link, RFC 5340 says it takes the next-hop address from that router's Link-LSA for the link. On many link types the same address could be read from the IPv6 source of the neighbour's Hellos. The Link-LSA exists for the cases where that fails: on an **NBMA** link two routers need not be neighbours and may never exchange Hellos; they learn of each other through the Designated Router. RFC 5340 notes this explicitly as the reason Hellos are not enough. ## Purpose 2: the link's prefixes, for the DR A multi-access link's prefixes are advertised to the rest of the area by its **Designated Router**, in an Intra-Area-Prefix-LSA that references the link's network-LSA. The DR builds it from the Link-LSAs: 1. It examines each Link-LSA for the link. 2. It uses only those whose originator is **fully adjacent** to it and whose Link State ID matches that neighbour's Interface ID. 3. It copies their prefixes, skipping link-local addresses and prefixes with the `NU-bit` or `LA-bit` set. 4. It merges duplicates, ORing their prefix options, and sets each prefix's metric to `0`. A side effect RFC 5340 points out: not every router on the link needs the prefix configured. A router that lacks it learns it from a neighbour's Link-LSA. ## Purpose 3: Options for the network-LSA The network-LSA that the DR originates for the link carries an Options field. RFC 5340 sets it to the logical OR of the Options in the Link-LSAs of all fully adjacent routers on the link, so the network-LSA reflects the capabilities present on the link rather than only the DR's own. ## Why link-local scope RFC 5340 argues the point by comparison with OSPFv2. In OSPFv2 a router-LSA carries the router's interface addresses, which other routers use only to compute next hops, and that router-LSA is flooded across the whole area. Moving the next-hop address into an LSA that never leaves the link is, in RFC 5340's word, *more efficient*: - routers elsewhere in the area never store addresses they cannot use; - link-local addresses, meaningless off the link, never appear in area-wide LSAs (RFC 5340 forbids them there); - a change on one link floods on that link only. ## Edge cases - **Suppression**: RFC 5340 defines a `LinkLSASuppression` interface parameter. When it is enabled on an interface that is neither broadcast nor NBMA, such as a point-to-point link, the router may skip the Link-LSA, and its neighbour takes the next hop from the Hello's source address instead. It is disabled by default and is implicitly disabled on broadcast and NBMA links, where the DR needs the prefixes and Options. - **Unknown types**: a Link-LSA's scope bits and unknown-type handling are coded in its LS type; any LSA type a router does not recognise and whose `U-bit` is clear is likewise treated as link-scoped. ## Mistakes that show up in interviews - Saying Link-LSAs are flooded through the area. - Saying only the DR originates one; every router on a multi-router link does. - Saying next hops are global addresses from Intra-Area-Prefix-LSAs. - Treating the Link-LSA as a substitute for Hellos; neighbour discovery is still the Hello protocol's job.

  • On an OSPFv3 point-to-point link, can a router do without its neighbour's Link-LSA?
    Yes, if the operator enables RFC 5340's `LinkLSASuppression` on that interface, which is allowed only when the interface is neither broadcast nor NBMA. The neighbour then takes the next-hop address from the IPv6 source of the router's Hellos. It is disabled by default, and it is implicitly disabled on broadcast and NBMA links, where the DR needs the prefixes and Options the Link-LSA carries.
  • A router on an OSPFv3 broadcast link lists a prefix in its Link-LSA but is not yet fully adjacent to the DR. Is the prefix advertised to the area?
    Not from that Link-LSA. RFC 5340 has the DR copy prefixes only from Link-LSAs whose advertising router is fully adjacent to it. The prefix reaches the area once that adjacency is full, or earlier if another fully adjacent router on the link lists the same prefix in its own Link-LSA.

saying these in an interview costs you the question

  • Link-LSAs are flooded throughout the area so every router knows each next hop.
  • OSPFv3 next hops are global addresses taken from Intra-Area-Prefix-LSAs.
  • On a broadcast link only the DR originates a Link-LSA.
  • A router can always learn a neighbour's link-local address from its Hellos, so the Link-LSA is redundant.
  • The Link-LSA replaced Hellos for discovering OSPFv3 neighbours.