Print Full Article Print This Page Download the PDF E-Mail This URL

The biggest problem with RIP is that the 15-hop ceiling often isn't enough for complex campus networks. Many networks are simply too large and distributed to fit within this scope. Furthermore, the use of hops as a distance metric does not always reflect actual cost or bandwidth. Also, a less efficient route may be chosen simply because it has fewer hops or because it has an equal number of hops (all the Internet routes are two hops removed from Router B, and the slower path through Router D could be chosen simply because that advertisement arrived first). Finally, because each router broadcasts its routing table every 30 seconds, RIP can suck up a considerable amount of valuable WAN bandwidth through normal operations, particularly with large networks.

For all these reasons, RIP is not a good choice as a global routing protocol for networks that span multiple distributed sites.

Although RIP 2 improves on some core aspects of RIP 1, it still suffers from most of the same architectural problems as RIP 1. The major improvements in RIP 2 include support for variable-length subnet masks and route aggregation, both of which allow for better address allocation policies and smaller routing messages. In addition, RIP 2 uses multicasting to reduce the impact of frequent updates on nonparticipating local systems, and RIP 2 provides rudimentary authentication support, allowing for a modicum of security in mixed-user installations. Despite these benefits, RIP 2 is still hampered by the same architectural limitations that penalize RIP 1, making it equally inappropriate for complex, multisegment networks.

RIP is useful for small to midsize networks, particularly when those networks have RIP-enabled workstations and servers, and RIP 2 is even better. Because RIP is a relatively simple protocol, it is often implemented as a listen-only daemon, letting devices learn about their local network without needing to maintain static routes. However, it does have problems on large-scale networks.

Enterprise Routing with OSPF

OSPF is based on the IS-IS (Intermediate System to Intermediate System) routing protocol but is optimized for IP networks in particular. Several IETF documents define the many iterative flavors of OSPF:

>> RFC 1131 defines OSPF 1 (field obsolete).

>> RFC 1583 is perhaps the most widely implemented rendition of OSPF 2.

>> RFC 2328 defines the most current version of OSPF 2 (and is the current source for Internet Standard 54).

With OSPF, every router maintains an independent database of an administrative routing area, including information about the available networks, the routers on the networks and the per-interface cost for each router's connections to each network. In this model, whenever a network, router or interface changes state, each of the routers within the area find out about it and incorporate the new information into the local database, then rebuild the routing maps accordingly. These calculations are performed according to the cost of the network paths for a specific destination, regardless of the number of hops that are required to get through the network. Taken as a whole, OSPF applies a cost-vector algorithm to a database of network objects and uses this information to determine optimum routes throughout an area.

This model opens the door for many compelling features (such as faster change synchronization), but it introduces significant memory and processor demands on the participating systems. For this reason, fewer OSPF-enabled devices are on the market than are RIP-enabled systems. For example, though many server-class operating systems provide OSPF daemons of some kind, not many network clients or low-end devices provide OSPF support, since even passive listeners have to implement the full database analysis engine for them to make use of the link-state data.

The central architectural concept in OSPF is the administrative routing area, which provides a scope control to the network database. All OSPF messages are bound to a specific area; the routers that participate in a shared area will exchange detailed information about that area with each other but will exchange only summary information with routers in remote areas. If an organization needs to use multiple areas, a special backbone area is required to exchange information between the multiple areas. Edge areas must exchange their summary information through the backbone area, meaning OSPF imposes a mandatory two-tier hierarchy on interarea route exchanges (this applies only to the route-control messages, not to all network traffic).

Areas have 32-bit identifiers (which are normally written as IPv4 network addresses), while the backbone area is always numbered 0. Routers can participate in multiple areas simultaneously, but each area will have its own link-state database in the router and require its own memory and processor cycles. In OSPF lingo, a router that participates in multiple areas simultaneously is an ABR (Area Border Router), while a router that exchanges data with foreign routing protocols is known as an ASBR (Autonomous System Border Router).

Remember that routers must make forwarding decisions only one hop at a time. In this regard, OSPF routers do not need to have detailed information about every network in the world (a default route is good enough to move the packets closer to an off-site destination). As such, OSPF uses the detailed information to build routing maps for the local area, but once a router has learned routes for other areas, that information will be used to forward packets to the remote areas directly.