Introduction to OSPF | OSPF Network Design Solutions

Table of Contents

In Cisco IOS release 10.2 and earlier, OSPF assigned default metrics to a router’s interface, regardless of the bandwidth actually attached to the interface. For example, it would give a 64K and a T1 link the same metric. This required the user to override the default value in order to take advantage of the faster link. This overriding was accomplished through the use of the ip ospf cost [value] command, which would be placed on each interface as desired.

In Cisco IOS 10.3 and later, OSPF by default now calculates the cost (metric) for an interface according to the bandwidth of the interface. If needed, this feature can also be disabled through the use of the no ospf auto-cost-determination router command. You will then be able to customize the routing costs as needed.

Shortest Path Tree

Assume you have the network diagram as shown in Figure 5-1 with the indicated interface costs. To build the shortest path tree for the Headquarters router, you would have to make it the root of the tree and calculate the smallest cost for each destination.

The directions of the arrows in this figure are used to calculate the route’s cost. For example, the cost of the Manufacturing router’s interface to network 128.213.0.0 is not relevant when calculating the cost to 192.213.11.0.

Headquarters can reach 192.213.11.0 via the Manufacturing router with a cost of 20 (10+5+5). Headquarters can also reach 222.211.10.0 via the Sales router with a cost of 25 (10+15) or via the manufacturing router with a cost of 20 (10+5+5).

TIPS:
In case equal cost paths to the same destination exist, Cisco’s implementation of OSPF will keep track of up to six next hops to the same destination.

To build the shortest path tree for Headquarters, you would have to make Headquarters the root of the tree and calculate the smallest cost for each destination. After the router builds the shortest path tree, it will start building the routing table accordingly. Directly connected networks will be reached via a metric (cost) of 0 and other networks will be reached according to the cost as calculated in the tree.

OSPF Convergence

One of the most attractive features about OSPF is its capability to quickly adapt to topology changes. The two essential components to routing convergence are

• Detecting changes to the network topology

• Rapid recalculation of routes

Detecting Changes to the Network Topology

OSPF uses two mechanisms to detect topology changes. Interface status changes (such as carrier failure on a serial link) is the first mechanism. The second mechanism is the failure of OSPF to receive a hello packet from its neighbor within a timing window called a dead timer. After this timer expires, the router assumes the neighbor is down. The dead timer is configured using the ip ospf dead-interval interface configuration command. The default value of the dead timer is four times the value of the hello interval, which results in a dead timer default of 40 seconds for broadcast networks and 2 minutes for nonbroadcast networks.

To summarize, fault detection by OSPF can differ slightly depending upon the media type. In general, the failure of a hello packet can supersede the failure of keepalive packets. The media type will affect how OSPF detects a failure as shown in the following list:

• Serial interface faults are detected in one of two ways:

• Immediate detection of carrier (lmi) loss

• Two to three times the time of the keepalive packet (default 10 seconds)

• Token Ring and FDDI are detected immediately.

• Ethernet is detected after the keepalive packet fails two to three times.

Rapid Recalculation of Routes

After a failure has been detected, the router that detected the failure floods an LSA packet with the change information to all routers to which it is directly connected. The detecting router will continue to flood this information until each router to which it is directly connected acknowledges its receipt.

All of the routers will recalculate their routes using the Dijkstra (or SPF) algorithm. Remember that each router builds its routing table based upon the LSDB, and this change alters the contents of that database. Therefore, the router will rebuild its routing tables with it as the base of the route tree. The time required to run the algorithm depends on a combination of the size of the area and the number of routes in the database.

TIPS:
OSPF load balances along equal cost paths, this in turn allows for almost immediate convergence. OSPF can also load balance across four equal cost paths.

OSPF Design Guidelines

The OSPF protocol, as defined in RFC 1583 and RFC 2178, provides a high functionality open protocol that enables multiple vendor networks to communicate using the TCP/IP protocol family. Some of the benefits of OSPF are: fast convergence, VLSM, authentication, hierarchical segmentation, route summarization, and aggregation, all of which are needed to handle large and complicated networks.

Whether you are building an OSPF internetwork from the ground up or converting your internetwork to OSPF, the design guidelines highlighted in the following sections provide a foundation from which you can construct a reliable, scalable OSPF-based environment.

Different people have different approaches to designing OSPF networks. The important thing to remember is that any protocol can fail under pressure. The idea is not to challenge the protocol but rather to work with it in order to get the best performance possible from your network.

The OSPF RFCs 1583 and 2178 do not specify several very important considerations that are essential to a properly designed OSPF network. But RFC 2178 is a very good resource to consult when laying out the design of your OSPF network. It is also backward compatible with RFC 1583.

The two design activities that are critically important to a successful OSPF implementation are defining area boundaries and assigning addresses. Ensuring that these activities are properly planned and executed will make all the difference in your OSPF implementation.

Table of Contents