Notes on OSPF Database Exchanges

OSPF Message Types

Link-State Request (LR) (Type 3)
A packet that lists the LSIDs of LSAs the sender of the LSR would like the receiver of the LSR to supply during database exchange

Link-State Update (LSU) (Type 4)
A packet that contains fully detailed LSAs, typically sent in response to an LSR message

Link-State Acknowledgment (LSAck) (Type 5)
Sent to confirm receipt of an LSU message

OSPF Neighbor State Reference

Down: no hellos have been received from this neighbor for more than the dead intervall
Attempt: used when the neighbor is defined with the neighbor command, after sending a hello, but before receiving a hello from that neighbor.
Init: A hello has been received from the neighbor, but it did not have the local router’s RID in it or lists parameters that do not pass the neighbor verification checks. This is a permanent state when hello parameters do not match.
2Way: A hello has been received from the neighbor, it has the router’s RID in it, and all neighbor verification checks passed.
ExStart: Currently negotiating the DD sequence numbers and master/slave logic used for DD packets
Exchange: Finished negotiating the DD process particulars, and currently exchanging DD packets.
Loading: All DD packets are exchanged, and the routers are currently sending LSR, LSU, and LSAck packets to exchange full LSAs
Full: Neighbors are fully adjacent, meaning they believe that their LSDBs for that area are identical. Routing table (re)calculations can begin.

Database Exchange Without and With a DR

There are some differences with database exchange whether or not there is a DR. The most common case for which routers do not elect a DR occurs on point-to-point topologies.

When there is a DR the non-DR routers do not exchange their databases directly with all neighbors on a subnet. Instead, they exchange with the DR and then the DR exchanges with the rest of the OSPF routers.

This section of the book has a lot of rambling, and I am going to skip it over on the off-chance that it won’t be on the test.

Metric Tuning

There are three methods to tweak the values of the OSPF interface cost. This will change the best choice route.

Changing reference bandwidth
Setting the interface bandwidth
Setting OSPF cost directly

Changing the Reference Bandwidth

OSFP cost for an interface is equal to: reference bandwidth / interface bandwidth. Reference bandwidth can be set using the auto-cost reference-bandwidth <bandwidth> router sub-command. The recommendation is to use the same setting on all routers in an OSPF routing domain.

Setting the Interface Bandwidth

This can be configured using the interface sub-command bandwidth <speed>. It is also interesting to note that on serial links this bandwidth defaults to 1544. On sub-interfaces of those serial interfaces the same bandwidth is used (meaning you can over-commit bandwidth with multiple sub-interfaces).

Configuring Cost Directly

The cost can be configured manually using the command ip osfp cost <value> interface sub-command. This is obviously per interface, and is laborious.

Verifying OSPF Cost Settings

show ip ospf interface brief
show ip ospf interface <interface name>

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 for OSPF Adjacency Over WAN & Network Types

When forming adjacencies over WAN the requirements are the same.

Area number must match with each neighbor
IP subnet and mask must match
Authentication must pass

Etc. etc.

Implementation and Verification for OSPF over WAN

Will multicast OSPF hellos be implemented, or will neighbors be predefined?
Will a DR be elected, and if so which router will be the DR?
With which other routers should each router become an OSPF neighbor?

OSPF Network Types

Network type is a per-interface setting. The network type will help determine the following:

Whether the router will expect to discover neighbors using multicast hellos
Whether only two or more than two OSPF routers can exist in the subnet attached to the interface
Whether an attempt should be made to elect an OSPF DR router on that interface

The following are the OSPF network types

Braodcast
Point-to-point
Loopback
Nonbroadcast (NBMA)
Point-to-multipoint
Point-to-multipoint nonbroadcast

Network types are configured using the command: ip ospf network <type>

Here is a pretty good table demonstrating the various network types and their behaviors (click to enlarge). (credit: Odom, ROUTE Official Certification Guide)

each connection makes us stronger