Notes on OSPF LSAs and LSA/Topology Database

As stated in an earlier post every router in an OSPF area should learn the same topology. This data is composed of individual LSAs (link state advertisements), which are stored in the LSDB (link state database). Sometimes this is referred to as the OSPF topology table, although the proper term would be LSDB. The term topology table is only used comparably to EIGRPs topology table.

The Dijkstra Algorithm is used to compute the lowest cost path for each route or reachable subnet. The Dijkstra Algorithm is also known as the Shortest Path First Algorithm, or “SPF”.

LSA Types

1 – Router
2 – Network
3 – Net Summary
4 – ASBR Summary
5 – AS External
6 – Group Membership (currently not supported by Cisco IOS)
7 – NSSA External
8 – External Attributes (not implemented in Cisco routers)
9-11 – Opaque

All LSAs contain a link state ID (LSID). Depending on the LSA type, the LSID will contain specific information. For example, with type 1 LSAs the LSID will be the RID value of a specific router.

Types 1 – 3 are used to calculate the best routes for all routes inside the OSPF routing domain. Types 4, 5, and 7 are used to calculate routes for external (routes redistributed in to OSPF). Types 9-11 are used as generic LSAs to allow for easy future extension of OSPF. For example, type 10 has been adapted for MPLS traffic engineering.

LSA Type 1 – Router

Each router creates a type 1 LSA for itself, which is defined by its RID (router ID). The LSID (link state ID) is in fact the RID. This LSA is flooded throughout the area. The type 1 LSA is forwarded by neighboring routers until every router in the area has a copy of it.

In addition to RID the type 1 LSA also contains:

Routers interfaces subnet number and mask with OSPF cost for each interface on which no DR has been elected
The IP address of the DR and a notation that the link attaches to a transit network (meaning that a type 2 LSA exists for the network) for each interface on which a DR has been elected
Neighbor ID of router interfaces in which no DR is present, but a neighbor is reachable

For routers that are connected to multiple areas (ABR) a type 1 LSA is created for each area, with only the appropriate LSA for an area being flooded out an interface. In other words, LSAs for area 0 will not be flooded out area 1 from the ABR generating type 1 LSAs. Instead, only the type 1 LSA for area 0 will be flooded out interfaces connected to area 0, and type 1 LSAs for area 1 will be flooded out interfaces connected to area 1.

The use of RID in type 1 LSA is an important reason why it is recommended that RIDs are manually configured using router-id command, or by creating a unique loopback interface with appropriate IP to be assigned as RID.

Verifying Type 1 LSA

show ip ospf database: displays a summary of the LSAs known to the router
show ip ospf database router <RID>: displays the detailed information of a routers type 1 LSA. This will show neighbor IDs and interface on which neighbors can be reached. Since routers exchange these type 1 LSAs then this router will have the same information from the other routers advertised LSAs.

LSA Type 2 – Network

These LSAs are required on multi-access networks (more than 2 routers connected to the same subnet) where the router must model the topology with nodes (the routers) and connections between nodes. Each connection must be between a pair of nodes. The type 2 LSA is used to handle this.

First, the routers will set a transit network (or pseudonode) in their type 1 LSA. Then, the type 2 LSA (managed by the DR) will model this by listing references back to each type 1 router LSA connected to it.

Important to note that the elected DR in a subnet creates the type 2 LSA for that subnet. The LSID on the type 2 LSA will be the connected interface IP address of the DR. The type 2 LSA will also have the DRs RID listed as the “advertising” router. See the command show ip ospf database network command below.

Routers choose wether or not to use type 2 LSAs for multi-access networks based on whether a DR (designation router) has or has not been elected on an interface.

Remember that a DR is used to 1) create and flood a type 2) network LSA for a particular subnet, and 2) aid in the detailed process of database exchange over that subnet.

Verifying Type 2 LSA

Here are some commands that can be used to verify type 2 LSA configuration.

show ip ospf database: lists a single line for each LSA (as discussed for type 1). The type 2 LSAs will be listed under “Net Link States” with interface IP address of the DR that creates the type 2 LSA
show ip ospf database router <RID>: type 2 LSA are listed as “connected to: Transit Network”
show ip ospf database network <LSID>: the LSID here is the IP address of the interface on the DR connecting to the subnet

LSA Type 3 – Summary

By design OSPF ABRs (routers connected to more than 1 area) will not forward type 1 and type 2 LSAs across areas. This is a strategic implementation to limit the scope of SPF and save precious CPU and RAM. Regardless, routers need to be aware of subnets in other areas. These are advertised using the type 3 LSA. ABRs generate a type 3 LSA for each subnet in one area, and then advertises these LSAs to other areas.

A type 3 LSA does not contain the amount of detail found in type 1 or type 2. Instead, they summarize. This is not the same as route summarization. A type 3 LSA will appear to be another subnet connected to the ABR that created and advertised the type 3 LSA. It is a “summary” in the sense that it lacks the details types 1 and 2 LSAs have.

The ABR assigns the LSID based on the subnet number being advertised, and ads its own RID to the LSA as well.

Limiting the Scope of LSAs

The maximum number of LSAs learned from other routers can be limited by using the max-lsa <number> subcommand. What happens when a router hits a configured limited number of LSAs to learn?

Issue log messages, ignore, rewarn, etc. (ignore time and number of times to ignore are configurable with max-lsa)
Close all neighborships, discard LSDB, and then start adding neighbors again (essentially reload OSPF)

Summary

LSA types 4, 5, and 7 will be covered within redistribution section – since these apply to routing outside of the OSPF domain.

Notes on OSPF Fundamentals…

I covered EIGRP in 3 posts. OSPF will probably be twice that. I will also update flash cards once I finish reading the material and composing the study notes.

This post will cover most the fundamental stuff and slightly more (by fundamental I mean CCNA level). As I get in to the more advanced topics I will probably try to keep the posts smaller so they are easier to chew. This post will probably be long though.

Links State Qualities

OSPF is a link state routing protocol. This means that it exchanges link state updates (LSUs) rather than full routing tables. These updates contain link state advertisements (LSAs). The LSAs contain subnet mask information, which allows OSPF to support variable length subnet masks (VLSM). The LSAs are placed in to a link state database (sometimes called the topology database/table). An algorithm is used to create the routing table, based on the LSAs contained in the link state database (topology database). This algorithm is the Dijkstra Algorithm (also referred to as the Shortest Path First Algorithm). This algorithm will create a “shortest path tree”. From that shortest path tree a a routing table is created. The databases between routers should be synchronized.

It is important to note that similar to EIGRP OSPF has a topology table (the link state database), a neighbor table, and a routing table.

Distance vector protocols (such as RIP) exchange protocol information over a given set of time, regardless if an update is required. Link state protocols will only send an update when one is necessary (a topology change). Although, there is a summary LSA sent every 30 minutes.

Multicast Addresses

OSPF uses 2 addresses for communication

224.0.0.5 to communicate to all OSPF routers. Updates by the DR and BDR are sent, and also hello packets, etc.
224.0.0.6 to update the DR and BDR upon topology change. The DR/BDR listen on this address, but they do not broadcast on it.

Verify OSPF Database

show ip ospf database will verify the contents of the link state database. In the output of this command you will find

Link ID
Advertising Router
Age
Sequence Number
Checksum

LSA Sequence Numbers

LSAs are assigned sequence numbers to ensure consistency / timeliness (basically, the most current information). The sequence number is used by the router to verify whether a received LSA is older or more current than one it already has in the link state database. In the event that the LSA does not already exist in the database, the router will add it, and flood the LSA out every OSPF enabled interface interface (except the one it was received on).

When there is an LSA entry already in the database one of three things will happen.

If the sequence number is lower the router ignores the update and sends a link state update (LSU) to the router that sent it.
If the sequence number is unchanged the LSU is ignored
If the sequence number is higher the LSA is added to the database and an LSAcknowledgement is sent. The updated LSA will be flooded, while also updating its own database.

Adjacency Requirements

In order to exchange LSAs routers must form an adjacency first. There are some requirements in order for an adjacency to be successful. The following must be agreed upon between the routers:

Area number
Hello and Dead Timer settings
Whether the area is a stub area
If configured, authentication (kinda obvious…)
IP addresses must be in the same subnet
Unique router IDs
IP MTU must match

It is important to note that an MTU mismatch between neighbors will prevent successful exchanging of topology data. The neighbor will be listed under show ip ospf neighbors, but state will become DOWN.

To verify adjacency:

show ip ospf neighbor: will show show status of the database loading
show ip ospf interface

OSPF Router Roles

Within OSPF there are 3 types of routers.

DR (Designated Router): the router that received topology change notifications from other OSPF routers. It listens on multicast address 224.0.0.6, but it sends the updates it receives to 224.0.0.5.
BDR (Backup Designated Router): the backup to the DR. As the BDR it will never send updated, but it does listen for updates on 224.0.0.6
DROther: any router that is not a DR or BDR on a segment is considered a DROther.

Verifying Roles

show ip ospf neighbor will identify which routers are assigned which roles are assigned to which routers

DR Election Process

Typically, the router with the highest priority value will become the DR. The default priority is 1. A priority of 0 will disqualify a router from being able to take place in election. Therefore, 1 is the minimum value. This priority value can be configured using the command ip ospf priority. If all routers are configured with default values then the tie breaker comes down to the RID. The router with the highest RID will win. This same process is used for BDR election. Obviously, this makes the RID critical in the election process. The RID is determined according to the following rules:

The RID will be the highest IP address assigned to a loopback interface. The interface does not need to be OSPF enabled, and this interface network is not automatically advertised by OSPF.
If there is not loopback interface, then the highest IP address assigned to a physical interface will be used. Again, regardless whether or not it is OSPF enabled.
The RID can be set manually with the router-id command. Note that the router must be reloaded, or the OSPF process cleared before the command will take effect.

With this information in hand, you should know that there are 3 ways to manually manipulate DR/BDR election

Change the priority using ip ospf priority command
Configure RID manually with router-id command
Configure a loopback interface with the appropriate value

Hello and Dead Timers

OSPF uses 2 times to monitor neighbors. The first is hello time, and the second is dead time. They are used much like the hello and hold timers for EIGRP, only their default values are different depending on the network.

Hello Timer: used to notify a neighbor that the router is still alive. As long as a router received hellos from the neighbor the adjacency should stay up. In a default LAN setting the hello is 10.
Dead Timer: used to monitor whether a neighbor is alive. If a hello is not received from a neighbor within the dead timer value then it is assumed that the neighbor is down, and adjacency is torn down. In a default LAN setting the dead timer is 40.

If a routers interface goes down the router will assume all adjacencies attached to it are down too. It will not wait for the dead timer (this is kind of a no brainer).

Adjacency States

More might be said of this later, but for now (fundamental) – when issuing the command show ip ospf neighbors you will find the following common states for neighbors (this list is not exhaustive):

2WAY: normal, stable, working state for neighbor with which topology data was not exchanged directly
FULL: fully adjacent neighbor; topology has been fully exchange with that neighbor

I think I am going to stop here and move in to more advanced stuff. The next post will cover OSPF authentication.

each connection makes us stronger