Peeling the OSPF LSA Onion

OSPF LSAs tend to give people some heartache - but why is that? I'm not immune to it either - it's a topic for which I've personally had multiple "a-ha" experiences over the years, as things become clearer. I'm sure part of it is that many of us have jobs with networks that just don't use OSPF. Even if you use it, it's not like you're trouncing through the OSPF database every day when troubleshooting problems. You might design with areas, know about the need for virtual links, sizing your areas, etc, but you don't have to be able to quote the rules around the world of LSAs. So when it comes to exam prep, the LSA world can be a bit troublesome.

(Before I get too far - if you can think of more reasons why LSAs give you trouble, post them! I'd be curious to read your thoughts.)

When I picked the example we're walking through for these last few hosts, I purposefully picked an example that used at most 2 LSA types: Types 1 and 2. I've planned another thread, with pictures and enough detail to make it interesting, to get the rest of the LSA types out on the table. For now though, here's what we have:

  • R1 and R3 are OSPF neighbors on a LAN.
  • R2 won't become neighbors with R1 or R3 due to a mismatched IP subnet (see this post).
  • R1 has OSPF enabled on its LAN, plus it's only loopback (IP 5.5.5.5/32)
  • R3 has OSPF enabled on its LAN, plus 1 loopback (loop 2, IP 3.3.3.3/24), but not another (loop 4, IP 2.2.2.2)
  • All interfaces are in area 0

The net result is that only one area (area 0) exists, so there are no Area Border Routers (ABRs), and there are no external routes. As a result, there will only be 2 types of LSAs:

Type 1: A ROUTER LSA. Each router creates an LSA for itself, listing its own RID, its interface IP addresses/masks in that area, and the status of each interface (up/down). Each router floods the LSA to the other.

Type 2: A NETWORK LSA. For each subnet for which a Designated Router (DR) has been elected, the DR creates a type 2 LSA. This LSA lists the subnet number/mask, and a list of the routers connected to that subnet.

Ignoring R2 for now, R1 and R3 end up with identical LSDB's, each with the following LSAs:

  • 1 Type 1 Router LSA for R1
  • 1 Type 1 Router LSA for R3
  • 1 Type 2 Network LSA for the 10.1.1.0/26 LAN subnet

There are two particularly interesting facts about these LSAs that I think surprise people who don't think about LSAs a whole lot. First, for type 1 LSAs, there's enough information in the LSA for routers to calculate routes for the subnets connected to the routers. For example, R3 will have a host route for 5.5.5.5/32 by analyzing R1's type 1 LSA. For type 2 LSAs, the LSA is only formed if a DR is elected, and the DR is only elected if there are at least 2 routers in the subnet that meet all the neighbor requirements. For example, a branch router that connects to a LAN, but for which no other routers connect to the LAN, does not create a type 2 LSA.

Given that, R1 will have these routes:

  • 10.1.1.0/26 (connected)
  • 5.5.5.5/32 (connected)
  • 3.3.3.0/24 (OSPF)

R3 will have these:

  • 10.1.1.0/26 (connected)
  • 5.5.5.5/32 (OSPF)
  • 3.3.3.0/24 (connected)
  • 2.2.2.0/24 (connected)

To really get into the broader issues with LSAs, we need a more detailed figure with more routers. I'll do a few posts in the near future.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2008 IDG Communications, Inc.