The biggest advantage to summarization is the impact it has on both the routing table and convergence. Summarized routes may take the place of hundreds of specific routes. In addition, summarization can shield routers from flapping link overhead in a different area. This greatly increases the stability of the network—areas outside of the flapping route do not recalculate via the shortest path first (SPF) algorithm, nor do the routing tables change inside the shielded area.

Within each area, a single router is elected to be the designated router. The designated router, or DR, is selected by an election process that uses the highest IP address on the router. Most administrators use the loopback inter-face to override the highest IP address and manually manage the election of the DR. A Priority-ID may also be used to determine DR during election. It is preferable to use a router with the most memory and CPU capacity for the DR. In addition to the DR, a backup designated router (BDR) is also selected to provide redundancy in the event the primary router fails. The designated router provides an aggregation point for OSPF LSAs. Note that the command ip ospf priority may be used to make a router the DR. Under these circumstances, the IP address is used in the event of a tie.

One last consideration for designers is the configuration of stubby areas and totally stubby areas. (Don’t laugh, that’s what they’re called.)

A stubby area consolidates external links and forwards summary LSAs, specific LSAs, and the default external link, which is analogous to the default route of 0.0.0.0.

The concept of a totally stubby area is Cisco IOS-specific. Only the default link is forwarded into the area by the area border router. The command to configure this feature is area {N} stub no-summary. Because the totally stubby area receives only a default route, it is limited; however, it also works to control the total number of routes advertised into an area, which may benefit the designer in controlling routing propagation.

OSPF Link-State Advertisements

As a link-state protocol, OSPF relies on advertisements to announce information regarding the network. The link-state advertisements are given a sequence number and acknowledged, resulting in reliable information transfer. This feature aids in the fast convergence offered by the protocol. There are five primary types of OSPF link-state advertisements, as identified in Table 4.4.

There are two additional LSA types. Type 6 is for Multicast OSPF, or MOSPF. Type 7 is defined for NSSAs, or not-so-stubby areas. While both may gain popularity in the future, they are not commonly found in most networks.

OSPF Route Calculations

OSPF is an excellent protocol for calculating routes, and the actual process is quite simple. This process includes the incorporation of a calculated cost for each interface type. By default, cost is computed by taking 108 (100,000,000) and dividing by the manually configured bandwidth of the link. Table 4.5 presents some of the default OSPF calculated costs.

As shown in Table 4.5, OSPF’s default costs present a substantial negative for modern networks, as it fails to automatically account for bandwidths greater than 100Mbps. The lowest OSPF cost is a value of 1. By default, from the 100Mbps bandwidth point upwards, OSPF will regard any interface as being equal to any other interface of equal or greater bandwidth. Thus, by default, OSPF cannot consider the differences between an FDDI ring and a Gigabit Ethernet segment. The OSPF command OSPF AUTO-COST REFERENCE-BANDWIDTH <#> is commonly used to change the default computation of 10⁸ (100,000,000) to a higher number (so the computed cost is a value other than 1 on high-speed networks). Care should be taken, however, to confirm that this setting has been applied to all routers that will be affected by this links cost. Network designers will need to consider this issue when selecting OSPF for their networks. Under such circumstances, designers will likely alter these costs to account for faster media.

Each router in an OSPF area maintains a link-state database. This database is identical on each router in the area and is populated via link-state advertisements. As previously noted, there are different types of advertisements, but the information will appear in the form of specific links, summary links, and default links.

Based on the LSA advertisements, the router will recalculate to determine the best route via the shortest path first (SPF) algorithm. This is also called Dijkstra’s algorithm. The specifics of the algorithm are beyond the scope of the exam; however, the algorithm is interesting reading and is available in many distributions.

As with most network routing protocols, OSPF designers are frequently concerned with convergence time. OSPF is a very strong protocol in terms of convergence time—each router is aware of the entire topology in the area. This results in fast convergence. However, if a link flaps, or changes between up and down status quickly, a flood of LSAs may be generated. This may prevent the router from converging, and as a result, a command will be added to the IOS to limit the impact of flapping routes. Administrators may use the spf holdtime command to force OSPF into a waitstate before computing a new route.

OSPF convergence is determined by a number of factors and processes. The first step is link failure detection, which is dependent on each type of media. This may result from a carrier detect failure, the loss of keepalives, or a lack of OSPF hellos on the link. Depending on the detection method used, the delay may be negligible or significant—up to 40 seconds. Delay at this point will hinder the second step, which is the propagation of LSAs and the recalculation of the SPF algorithm. This process should take less than one second under most circumstances. In order to prevent flapping and other inappropriate fluctuations to the routing tables, OSPF adds an SPF hold timer of five seconds. Thus, convergence is fairly predictable—within a broad range. Link failures can take between six and 46 seconds to converge. The flow of this process is illustrated in Figure 4.8.

FIGURE 4.8  OSPF convergence