13. Routed limited routing updates to a maximum of once every 30 seconds. Xerox's RIP did not have this feature. Thus, routed were more networks friendly and could scale upward more gracefully.
48. Lack of support for dynamic load balancingHop Count Limit<br /> RIP was designed for use in relatively small autonomous systems. As such, it enforces a strict hop count limit of 15 hops, assuming that the default values for cost metrics aren't modified. As packets are forwarded by a routing device, their hop counters are incremented by the cost of the link that it is being transmitted over. If the hop counter hits 15 and the packet aren’t at its addressed destination, that destination is considered unreachable and the packet is discarded. <br /> This effectively fixes maximum network diameter at 15 hops. Therefore, if your network has a diameter of more than 15, RIP probably isn't the right routing protocol to use.<br />Fixed Metrics<br /> The discussion about hop counts nicely sets the stage for an examination of RIP's next fundamental limitation: its fixed cost metrics. Although the administrator can configure cost metrics, they are static in nature. RIP cannot update them in real-time to accommodate changes it encounters in the network. The cost metrics defined by the administrator remain fixed until updated manually.<br /> This means that RIP is particularly unsuited for highly dynamic networks where route calculations must be made in real-time in response to changes in the network's condition. If a network supports time-sensitive applications, for example, it is reasonable to use a routing protocol that can calculate routes based on the measured delay of its transmission facilities or even the existing load on a given facility. RIP uses fixed metrics. Therefore, it cannot support real-time route calculation.<br />Network Intensity of Table Updates<br /> A RIP node broadcasts its routing tables Omni directionally every 30 seconds. In large networks with many nodes, this can consume a fair amount of bandwidth.<br />Slow Convergence<br /> In human terms, waiting 30 seconds for an update is hardly inconvenient. Routers and computers, however, operate at much faster speeds than humans. Therefore, having to wait 30 seconds for an update can have demonstrably adverse effects. This point is demonstrated in the section titled quot;
Topology Changesquot;
earlier in this chapter.<br /> Much more damaging than merely waiting 30 seconds for an update, however, has to wait up to 180 seconds to invalidate a route. And this is just the amount of time needed for just one router to begin convergence. Depending on how many routers are internetworked, and their topology, it may take repeated updates to completely converge on a new topology. The slowness with which RIP routers converge creates a wealth of opportunities for vestiges of invalid routes to be falsely advertised as still available. Obviously, this compromises the performance of the network, both in the aggregate and in the perception of individual users.<br /> This chapter should have amply demonstrated the dangers inherent in RIP's slow convergence.<br />Lack of Load Balancing<br /> Another of RIP's significant limitations is its inability to dynamically load balance. Figure 28 illustrates a router with two serial connections to another router in its internetwork. Ideally, the router in this illustration would split the traffic as evenly as possible between the two serial connections. This would keep congestion to a minimum on both links and would optimize performance.<br />Figure SEQ Figure ARABIC 28 Figure 28: A router with redundant serial connections.<br /> Unfortunately, RIP cannot perform such dynamic load balancing. It would use whichever of the two physical connections that it knew about first. RIP would forward all its traffic over that connection even though the second connection was available for use. This scenario would change only if the router in Figure 28 received a routing update informing it of a change in the metrics to any given destination. If this update meant that the second link was the lowest-cost path to a destination, it would begin using that link and cease using the first link.<br /> RIP's inherent lack of load-balancing capability reinforces its intended use in simple networks. Simple networks, by their very nature, tend to have few (if any) redundant routes. Consequently, load balancing was not perceived as a design requirement, and support for it was not developing.<br />Summary<br /> RIP's ease of configuration, flexibility, and ease of use have made it a highly successful routing protocol. Since its development, there have been tremendous advances in computing, networking, and internetworking technologies. The cumulative effects of these advances have taken their toll on RIP's popularity. In fact, many other routing protocols in use today are technically superior to RIP. Despite the success of these protocols, RIP remains a highly useful routing protocol, provided you understand the practical implications of its limitations and use it accordingly.<br />