In Cisco IOS release 10.2 and earlier, OSPF assigned default metrics to a routers 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 routes cost. For example, the cost of the Manufacturing routers interface to network 126.96.36.199 is not relevant when calculating the cost to 188.8.131.52.
Headquarters can reach 184.108.40.206 via the Manufacturing router with a cost of 20 (10+5+5). Headquarters can also reach 220.127.116.11 via the Sales router with a cost of 25 (10+15) or via the manufacturing router with a cost of 20 (10+5+5).
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.
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
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:
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.
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.