Open Short Path First Protocol Overview

The following sections provide a brief recap of the OSPF protocol specification and operation. It should be noted that detailed information on OSPF will not be included in the following sections. Instead, emphasis is placed only on the core concepts which you must understand in order to effectively troubleshoot and support OSPF networks. Additional detail and information can be found in the current ROUTE exam guide which is also available online.

OSPF Fundamentals

When OSPF is enabled in Cisco IOS software, operational data, configured parameters and statistics information is stored in the 4 (four) separate data structures shown in Figure 6-1:

Fig. 6-1. OSPF Data Structures

The Interface Table provides a list of all interfaces that have been enabled for OSPF. You can view the state of the interfaces in the Interface Table by using the show ip ospf interfacescommand. This command also includes additional information such as the network type, Hello and Dead timers, adjacent neighbors, as well as any configured authentication parameters; assuming that OSPF interface authentication has been configured.

The Neighbor Table tracks all active OSPF neighbors. The contents of this data structure can be viewed using the show ip ospf neighbor command. This command allows you to view information about all neighbors for all processes, or detailed information on individual neighbors, which includes, but is not limited to, neighbor uptime, as well as area designation.

The Link State Database (LSDB) contains information about the network topology. The LSDB is a collection of Link State Advertisements for all routers and networks. Each router in the OSPF network maintains an identical database, which ensures that all routers in the domain have a consistent view of the overall network topology. By default, the Link State Database is refreshed every 30 (thirty) minutes; however, LSA flooding occurs whenever there is a change in the OSPF topology, ensuring that the databases are synchronized.
The contents of the LSDB can be viewed using the show ip ospf database command. This command, when used without any additional keywords, prints information on all LSAs in the LSDB. However, Cisco IOS software allows administrators to view detailed information on a per-LSA basis using additional keywords such as external to view Type 5 LSAs for example. Additionally, you can also use the show ip ospf database database-summary command to view how many of each type of LSA for each area there are in the database, and the total number of each. Following is a sample output of this command:

R1#show ip ospf database database-summaryOSPF Router with ID (10.1.0.1) (Process ID 1) Area 0 database summary LSA Type      Count    Delete   Maxage Router        2        0        0 Network       0        0        0 Summary Net   2        0        0 Summary ASBR  0        0        0 Type-7 Ext    0        0        0 Prefixes redistributed in Type-7  0 Opaque Link   0        0        0 Opaque Area   0        0        0 Subtotal      4        0        0 Process 1 database summary LSA Type      Count    Delete   Maxage Router        2        0        0 Network       0        0        0 Summary Net   2        0        0 Summary ASBR  0        0        0 Type-7 Ext    0        0        0 Opaque Link   0        0        0 Opaque Area   0        0        0 Type-5 Ext    1        0        0 Prefixes redistributed in Type-5  1 Opaque AS     0        0        0 Total         5        0        0

And finally, the Routing Information Base (RIB) contains the results derived from the Shortest Path First calculation, the contents of which can be verified or viewed using the show ip route [ospf] [process ID] command. For example, to view all routes learned by OSPF process number 1, you would enter the following command on the router:

R1#show ip route ospf 1 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O IA    10.3.0.3/32 [110/65] via 172.16.0.2, 00:51:12, Serial0/0 150.1.0.0/24 is subnetted, 1 subnets O IA    150.1.1.0 [110/74] via 172.16.0.2, 00:51:12, Serial0/0

Multi-Area OSPF Fundamentals

OSPF is a hierarchical routing protocol that logically divides the network into sub-domains that are referred to as areas. This logical segmentation is used to limit the scope of Link State Advertisement (LSA) flooding throughout the OSPF domain. Link State Advertisements are special types of packets sent by routers running OSPF. Different types of Link State Advertisements are used within an area and between areas. By restricting the propagation of certain types of LSAs between areas, the OSPF hierarchical implementation effectively reduces the amount of routing protocol traffic within the OSPF network.

In a multi-area OSPF network, one area must be designated as the backbone area. The backbone is the logical center of the OSPF network. All other non-backbone areas must be physically connected to the backbone. However, because it is not always possible or feasible to have a physical connection between a non-backbone area and the backbone, the OSPF standard allows the use of virtual connections to the backbone, called virtual links.

Routers within each area store detailed topology information for the area in which they reside. Within each area one (or more) routers referred to Area Border Routers (ABRs) facilitate inter-area routing by advertising summarized routing information between the different areas. This functionality allows for the following within the OSPF network:

1. Reduces the scope of LSA flooding throughout the OSPF domain
2. Hides detailed topology information between areas
3. Allows for end-to-end connectivity within the OSPF domain
4. Creates logical boundaries within the OSPF domain

The backbone receives summarized routing information from ABRs.  Routing information is then disseminated to all other non-backbone areas within the OSPF network. When a change to the topology occurs, this information is disseminated throughout the entire OSPF domain, allowing all routers in all areas to have a consistent view of the network. ABRs maintain Link State Database (LSDB) information for all the areas that they are connected to by running the SPF algorithm for each area they belong to and generating Type 3 LSAs for these areas.

All routers within each area have detailed topology information pertaining to that specific area. The internal routers exchange intra-area routing information and use the Type 3 LSA information advertised by the ABRs to build a view of the topology outside the local area.

OSPF Network Types

OSPF uses different default network types for different media. These network types are:

1. Non-Broadcast
2. Point-to-Point
3. Broadcast
4. Point-to Multipoint

Non-Broadcast networks are network types that do not support natively Broadcast or Multicast traffic. The most common example of a non-Broadcast network type is Frame Relay. Non-Broadcast network types require additional configuration to allow for both Broadcast and Multicast support. On such networks, OSPF elects a Designated Router (DR) and/or a Backup Designated Router (DR). These two routers are described later in this chapter.

OSPF-enabled routers send Hello packets every 30 (thirty) seconds on non-Broadcast network types. If a Hello packet is not received in four times the Hello interval, or 120 seconds, the neighbor router is considered ‘dead’.

A point-to-point connection is simply a connection between only two endpoints. Examples of point-to-point connections include physical WAN interfaces using HDLC and PPP encapsulation, and Frame Relay and ATM point-to-point subinterfaces. No Designated Router (DR) or Backup Designated Router (BDR) is elected on OSPF point-to-point network types. By default, OSPF sends Hello packets out every 10 seconds on point-to-point network types.

Broadcast network types are those that natively support Broadcast and Multicast traffic; the most common example being Ethernet. As is the case with non-Broadcast networks, OSPF also elects a Designated Router (DR) and/or a Backup Designated Router (DR) on Broadcast networks. By default, OSPF sends Hello packets every 10 seconds on these network types and a neighbor is declared ‘dead’ if no Hello packets are received within 4 times the Hello interval, which is 40 seconds.

The point-to-multipoint network type is a non-default OSPF network type. In other words, this network type must be manually configured using the ip ospf network point-to-multipoint [non-broadcast] interface configuration command.  By default, the command defaults to a Broadcast point-to-multipoint network type. This default network type allows OSPF to use Multicast packets to dynamically discover neighbor routers. In addition to this, there is no DR/BDR election held on Broadcast point-to-multipoint network types.

The [non-broadcast] keyword configures the point-to-multipoint network type as a non-Broadcast point-to-multipoint network. This requires static OSPF neighbor configuration as OSPF will not use Multicast to dynamically discover neighbor routers. This network type does not require the election of a DR and/or BDR router for the designated segment. The primary use of this network type is to allow neighbor costs to be assigned to neighbors instead of using the interface assigned cost for routes received from all neighbors.

The point-to-multipoint network type is typically used in partial-mesh hub-and-spoke NBMA networks. However, it should also be noted that this network type can also be specified for other network types, such as Broadcast Multi-Access networks, such as Ethernet. By default, OSPF sends Hello packets every 30 seconds on point-to-multipoint networks. The default dead interval is four times the Hello interval, or 120 seconds.

OSPF Designated and Backup Designated Routers

OSPF elects a Designated Router (DR) and/or Backup Designated Router (BDR) on Broadcast and Non-Broadcast network types. It is important to understand that the BDR is not a mandatory component on these network types. In fact, OSPF will work just as well if only a DR is elected and there is no BDR; however, there will be no redundancy if the DR fails and the OSPF routers will need to go through the election process again to elect a new DR.

On the segment, each individual non DR/BDR router establishes an adjacency with the DR and, if one has also been elected, the BDR; but not with any other non-DR/BDR routers on the segment. The DR and BDR routers are fully adjacent with each other and all other routers on the segment. Non-DR/BDR routers never complete the database exchange and never reach the Full adjacency state with any other non-DR/BDR router on the segment.

The non-DR/BDR routers send messages and updates to the AllDRRouters Multicast group address 224.0.0.6. Only the DR/BDR routers listen to Multicast messages sent to this group address. The DR then advertises messages to the AllSPFRouters Multicast group address 224.0.0.5. This allows all other OSPF routers on the segment to receive the updates. In order for a router to be the Designated Router, or Backup Designated Router, for the segment, the router must be elected. This election is based on the following:

1. The highest router priority value
2. The highest router ID

By default, all routers have a default priority value of 1. This value can be adjusted using the ip ospf priority <0-255> interface configuration command. The higher the priority, the greater the likelihood the router will be elected DR for the segment. The router with the second highest priority will then be elected BDR. If a priority value of 0 is configured, the router will not participate in the DR/BDR election process.

When determining the OSPF router ID, Cisco IOS selects the highest IP address of configured Loopback interfaces. If no Loopback interfaces are configured, the software uses the highest IP address of all configured physical interfaces as the OSPF router ID. Cisco IOS software also allows administrators to manually specify the router ID using the router-id [address] router configuration command.

It is important to remember that with OSPF, once the DR and BDR have been elected, they will remain as DR/BDR routers until a new election is held. This will never change even if a router with a higher RID or priority is introduced to the segment. In order for the DR/BDR to be changed, the current DR/BDR routers must fail or be removed, or the administrator can manually reset the routers’ OSPF processes using the clear ip ospf process command.

Establishing Adjacencies

Routers running OSPF transition through several states before establishing an adjacency. The routers exchange different types of packets during these states. This exchange of messages allows all routers that establish an adjacency to have a consistent view of the network. Additional changes to the current network are simply sent out as incremental updates. These different states are the Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading and Full states.

1. The Down stateis the starting state for all OSPF routers. However, the local router may also show a neighbor in this state when no Hello packets have been received within the specified router dead interval for that interface.
2. The Attempt state is valid only for OSPF neighbors on NBMA networks. This state means that a Hello has been sent but no information has been received from the statically configured neighbor, however, some effort is being made to establish an adjacency with this neighbor.
3. The Init state is reached when an OSPF router receives a Hello packet from a neighbor but the local RID is not listed in the received Neighbor field. If OSPF Hello parameters, such as timer values, do not match, OSPF routers will never progress beyond this state.
4. The 2-Way state indicates bi-directional communication with the OSPF neighbor(s). This means that the local router has received a Hello packet with its own RID in the Neighbor field and Hello packet parameters are identical on the two routers. On multi-access networks, the DR and BDR routers are elected during this phase.
5. The Exstart state is used for the initialization of the database synchronization process. It is at this stage that the local router and its neighbor establish which router is in charge of the database synchronization process. The Master and Slave are elected in this state and the first sequence number for DBD exchange is decided by the Master in this stage.
6. The Exchange state is where routers describe the contents of their databases using DBD packets. Each DBD sequence is explicitly acknowledged, and only one outstanding DBD is allowed at a time. During this phase, LSR packets are also sent to request a new instance of the LSA.  The M (More) bit is used to request missing information during this stage. When both routers have exchanged their complete databases, they will both set the M bit to 0.
7. In the Loading state OSPF routers build an LSR and Link State Retransmission list. LSR packets are sent to request the more recent instance of an LSA that has not been received during the Exchange process. Updates that are sent during this phase are placed on the Link State Retransmission list until the local router receives an acknowledgement. If the local router also receives an LSR during this phase, it will respond with a Link State Update that contains the requested information.
8. The Full state indicates that the OSPF neighbors have exchanged their entire databases and both agree (have the same view) of the network. Both neighboring routers in this state add the adjacency to their local database and advertise the relationship in a Link State Update packet. At this point, the routing tables are calculated, or recalculated, if the adjacency was reset.

In order an OSPF adjacency to be successfully established, certain parameters on both routers must match. These parameters include the following:

1. The interface MTU values
2. The Hello and Dead Timers
3. The Area ID
4. The Authentication Type and Password
5. The Stub Area flag
6. IP Subnet and Subnet Mask

OSPF LSAs and the Link State Database (LSDB)

As stated in the previous section, OSPF uses several types of Link State Advertisements. Each LSA begins with a standard 20-byte LSA header. This header contains the following:

1. Link State Age
2. Options
3. Link State Type
4. Link State ID
5. Advertising Router
6. Link State Sequence Number
7. Link State Checksum
8. Length

NOTE: These fields are described in detail in the ROUTE guide that is available online. Please refer to that guide for additional information on each of these fields.

While OSPF supports 11 different types of Link State Advertisements, only LSAs Type 1, 2 and, 3, which are used to calculate internal routes, and LSAs Type 4, 5, and 7, which are used to calculate external routes are within the scope of the TSHOOT exam. These LSAs are described in the sections that follow:

1. Type 1 (Router) LSAs are generated by each router for each area it belongs to. The Type 1 LSA lists the originating router’s router ID (RID). Each individual router will generate a Type 1 LSA for the area in which it resides. For each Type 1 LSA, an ABR will both generate and advertise a Type 3 LSA. In other words, there is a one-to-one correlation between a Type 1 and Type 3 LSA. Type 1 LSAs are flooded within a single area and all routers within the area receive these LSAs from all other routers in the same area
2. OSPF uses the Network Link State Advertisement (Type 2 LSA) to advertise the routers on the multi-access segment. This LSA is generated by the DR and is flooded only within the area. Because the other non-DR/BDR routers do not establish adjacencies with each other, the Network LSA allows those routers to know about the other routers on the multi-access segment. As is the case with a Type 1 LSA, the ABR will also generate and advertise a Type 3 LSA for each Type 2 LSA
3. The Network (Type 3) LSA is a summary of destinations outside of the local area, but within the OSPF domain. In other words, this LSA advertises inter-area routing information. The Network LSA does not carry any topological information. Instead, the only information contained in the LSA is an IP prefix. Type 3 LSAs are generated by ABRs and are flooded to all adjacent areas. Each Type 3 LSA matches a single Router or Network LSA on a one-for-one basis. In other words, a Type 3 exists for each individual Type 1 and Type 2 LSA. Type 3 LSAs are advertised from a non-backbone area to the OSPF backbone for intra-area routes, i.e. for Type 1 and Type 2 LSAs and they are advertised from the OSPF backbone to other non-backbone areas for both intra-area, i.e. area 0 Type 1 and Type 2 LSAs, and inter-area routes, i.e. for the Type 3 LSAs flooded into the backbone by other ABRs
4. The Type 4 LSA describes information about an Autonomous System Boundary Router. This LSA contains the same packet format as the Type 3 LSA and performs the same basic functionality, with some notable differences. Like the Type 3 LSA, the Type 4 LSA is generated by the ABR. For both LSAs, the advertising router field contains the RID of the ABR that generated the summary LSA. However, the Type 4 LSA is created by the ABR for each ASBR reachable by a Router LSA. The ABR then injects the Type 4 LSA into the appropriate area. This LSA provides reachability information on the ASBR itself
5. The External Link State Advertisement is used to describe destinations that are external to the autonomous system. In other words, Type 5 LSAs provide the network information necessary to reach the external networks. In addition to external routes, the default route for an OSPF routing domain can also be injected as a Type 5 Link State Advertisement. The External LSA has a domain-flooding scope. This means that the ABR no longer stops the flooding process, but instead continues it into its respective areas. The only areas that External LSAs are not flooded to are any stub-type areas. Before Type 5 LSAs are installed into the routing table, the router calculating the Type 5 LSA must have a Type 4 LSA for the ASBR and the router must know about the forwarding address contained in the Type 5 LSA
6. The Type 7 LSA is used for external routing information from the ASBR in an NSSA. The external routing information within the LSA is converted by the ABR into Type 5 LSA at the area boundary. The ABR then floods the Type 5 LSA into the OSPF domain, and other routers in the network are aware of the external networks. Type 7 LSAs have an area flooding scope, so only routers in the NSSA receive the Type 7 LSA

OSPF Areas

In addition to the backbone (area 0) and other non-backbone areas the OSPF specification also defines several ‘special’ types of areas. The configuration of these areas is primarily used to reduce the size of the LSDB on routers residing within those areas by preventing the injection of different types of LSAs (primarily Type 5 LSAs) into certain areas. These areas are:

1. Not-so-stubby Areas
2. Totally Not-so-stubby Areas
3. Stub Areas
4. Totally Stubby Areas

Not-so-stubby Areas (NSSAs) are a type of OSPF stub area that allows the injection of external routing information by an ASBR using an NSSA External LSA (Type 7). The Type 7 LSA is used for external routing information from the ASBR within the NSSA. The external routing information within the LSA is converted by the ABR into Type 5 LSA at the area boundary. The ABR then floods the Type 5 LSA into the OSPF domain, and other routers in the network are aware of the external networks. Type 7 LSAs have an area flooding scope, so only routers in the NSSA receive the Type 7 LSA.

Totally Not-so-stubby Areas (TNSSAs) are an extension of NSSAs. Like NSSAs, Type 5 LSAs are not allowed into a TNSSA. However, unlike NSSAs, Summary LSAs are not allowed into a TNSSA. In addition to this, when a TNSSA is configured, the default route is injected into the area as a Type 7 LSA.  TNSSAs have the following characteristics:

1. Type 7 LSAs are converted into Type 5 LSAs at the NSSA ABR
2. They do not allow Network Summary LSAs
3. They do not allow External LSAs

Stub areas are somewhat similar to NSSAs with the major exception being that external routes (Type 5 or Type 7) are not allowed into Stub areas.  It is important to understand that Stub functionality in OSPF and EIGRP is not at all similar. In OSPF, the configuration of an area as a Stub area reduces the size of the routing table and the OSPF database for the routers within the Stub area by preventing external LSAs from being advertised into such areas without any further configuration. Stub areas have the following characteristics:

1. The default route is injected into Stub area by the ABR as a Type 3 LSA
2. Type 3 LSAs from other areas are permitted into these areas
3. External route LSAs, i.e. Type 4 and Type 5 LSAs are not allowed
4. The default route is injected as a Summary LSA

Totally Stubby Areas (TSAs) are an extension of Stub areas. However, unlike Stub areas, TSAs further reduce the size of the LSDB on routers in the TSA by restricting Type 3 LSAs in addition to the external LSAs. TSAs are typically configured on routers that have a single ingress and egress point into the network, for example in a traditional hub-and-spoke network. The area routers forward all external traffic to the ABR. The ABR is also the exit point for all backbone and inter-Area traffic to the TSA. TSAs have the following characteristics:

1. The default route is injected into Stub areas as a Type 3 Network Summary LSA
2. Type 3, 4, and 5 LSAs from other areas are not permitted into these areas

OSPF Virtual Links

A virtual link is a logical extension of the OSPF backbone. As we learned earlier in this chapter, when implementing a multi-area OSPF network, one area must be designated as the backbone area and all non-backbone areas must be connected to the backbone area. In most cases, a physical link is used to connect the non-backbone area to the backbone area; however, this is not always possible or feasible. In addition to being used to connect areas that have no physical connection to the OSPF backbone, virtual links can also be used for redundancy as well as connecting a discontinuous or partitioned backbone.