Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Internet Layer (OSI Network Layer) Protocols            9  TCP/IP Routing Protocols (Gateway Protocols)                 9  TCP/IP Interior Routing Protocols (RIP, OSPF, GGP, HELLO, IGRP, EIGRP)                      9  TCP/IP Routing Information Protocol (RIP, RIP-2 and RIPng)                           9  RIP Fundamentals and General Operation

RIP General Operation, Messaging and Timers 1 2 3 4 RIP Special Features For Resolving RIP Algorithm Problems

“Small Infinity”

The use of a relatively small value of “infinity” limits the slow convergence problem. Even in a situation where we “count to infinity” as we just saw, the total amount of time elapsed is at least manageable; imagine if “infinity” were defined as say, 1000! Unfortunately, the drawback of this is that it limits the size of the internetwork that can be used for RIP.

Many people balk at the limit of a span of 15 routers in RIP, but to be honest I think it is much ado about, well, if not nothing, then at least “nothing much”. The 15 value is not a limit on the total number of routers you can use, just on the number of routers between any two networks. Consider that most internetworks are set up hierarchically; even if you have a rather complex four-level hierarchy you wouldn't be close to the 15-router limit. In fact, you could create a huge autonomous system with thousands of routers without having more than 15 routers between any two devices. So this is only a limitation for the very largest of autonomous systems.

On the other hand, RIP’s need to send out its entire routing table many times each hour makes it a potentially poor choice for a large internetwork regardless of the “infinity=16” issue. In an internetwork with many routers, the amount of traffic RIP generates can become excessive.

To be fair, these problems are mostly general to distance-vector routing algorithms and not RIP in particular. Some of them are corrected through the implementation of specific changes to the algorithm or the rules under which RIP messages are sent, as described in the next topic. According to RFC 2453, there was actually a proposal to increase RIP's “infinity” to a number larger than 16, but this would have caused compatibility problems with older devices (which would view any route with a metric of 16 or higher as unreachable) so it was rejected.

RIP General Operation, Messaging and Timers 1 2 3 4 RIP Special Features For Resolving RIP Algorithm Problems