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.
|
|
|
|
RIP Protocol Limitations and Problems
(Page 4 of 4)
Problems With RIP's Metric
In addition to these concerns with
the algorithm itself, RIP is also often criticized because of its choice
of metric. There are two related issues here:
- Hop Count As A Distance Metric: Simply
put, hop count is a poor metric of the cost of sending a datagram between
two networks. I believe the use of hop count as the metric in RIP is
partially due to the desire for simplicity (it's easy to make the protocol
work when hop count is all the routers need to consider) and partially
an artifact of RIP being a 20-plus-year-old protocol. Decades ago computers
were slow, so each time a datagram passed through a router there was
probably a significant delay. Hop count was not a perfect metric even
then, but I think it had more correspondence with how long it took to
move a datagram across an internetwork than it does today.
Modern routers are lightning fast, making hop count a flawed way of
measuring network distance. The number of hops taken often has no correlation
with the actual amount of time it takes to move data across a route.
To take an extreme case, consider two networks that are connected by
a direct dial-up telephone networking link using 56K modems, and also
connected by a sequence of three routers using high-speed DS-3 lines.
RIP would consider the 56K link a better route because it has fewer
hops, even though clearly it is much slower.
- Lack Of Support For Dynamic (Real-Time) Metrics:
Even if RIP were to use a more meaningful metric than hop count, the
algorithm requires that the metric be fixed for each link. There is
no way to have RIP calculate the best route based on real-time data
about various links the way protocols like OSPF
do.
These problems are built into RIP
and cannot be resolved easily. Interestingly, some RIP implementations
apparently do let administrators fudge certain routes to
compensate for the limitations of the hop count metric. For example,
the routers on either end of the 56K link mentioned above could be configured
so they considered the 56K link to have a hop count of 10 instead of
1. This would cause any routes using the link to be more expensive
than the DS-3 path. This is clever, but hardly an elegant or general
solution.
Note: In addition to the rather long list of problems above, there were also some specific issues with the first version of RIP. Some of the more important of these include lack of support for CIDR, lack of authentication, and the performance reduction caused by the use of broadcasts for messaging. These were mostly addressed through extensions in RIP-2. |
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|