How do you know which routing protocol you should employ in your organization? This tip, excerpted from Managing IP Networks with Cisco Routers, by Scott
You may have a preference for either a link-state or a distance-vector protocol. But deciding what kind of protocol to use without considering other options can severely limit your choices, depending on what your router vendor supports. A more useful approach is to consider which protocol or protocols best suit your needs, and then use a preference for one type over another as a weighing factor later in the decision.
One of the most important criteria is how quickly the protocol adapts to changes in the network. [This is] convergence time, [and] it is the amount of time between a change in the network and the reestablishment of consistent and correct routing tables. Ideally you want this time to be small enough to be unnoticed by users.
Traditionally the next most important criterion is resource consumption. However, with the current push for more efficient use of the IP address space, it is likely that you plan to use variable-length subnet masks. If this is the case, then support for variable-length masks is probably the most important feature your routing protocol must have. After all if your routing protocol doesn't support your use of variable-length subnets masks, they won't do you much good.
The third criterion you should consider is how much of your network resources the routing protocol consumes. Consider not only the network bandwidth consumed by the protocol messages, but also how much processing power and memory is required in your routers. A link-state protocol will typically do better on the bandwidth consumption, and a distance-vector protocol will do better with processor and memory consumption, but this isn't always the case.
Next, consider how well your prospective protocols deal with multiple paths to a destination. This may or may not be critical in your network, and how much weight you give it depends on your network design. If you have no redundant paths, you probably won't care about how well your protocol supports them. Still, while you may not have redundant paths today, you may add them in the future. And you might need to change protocols to support them. Even if one of your prospective protocols doesn't normally support multiple paths, consider whether your router vendor's implementation does anyway. For example, RIP doesn't normally support multiple paths to a destination network, but the ROP implementation in a Cisco router does handle such redundancy and will even do load sharing across multiple paths with equal costs (metrics).
This was first published in November 2001