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 Book is Here... and Now On Sale!

Enjoy The TCP/IP Guide? Get the complete PDF!
The TCP/IP Guide

Custom Search







Table Of Contents  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

Previous Topic/Section
RIP General Operation, Messaging and Timers
Previous Page
Pages in Current Topic/Section
1
2
34
Next Page
RIP Special Features For Resolving RIP Algorithm Problems
Next Topic/Section

RIP Protocol Limitations and Problems
(Page 2 of 4)

“Counting To Infinity”

A special case of slow convergence can lead to a routing loop situation where one router passes bad information to another router, which sends more bad information to another router and so on. This causes a situation where the protocol is sometimes described as unstable.; the problem is called counting to infinity for reasons we will soon see.

To understand how this happens, let's modify the example we looked at in the topic describing the RIP algorithm (you may find it helpful to refer to Figure 174 as you follow this discussion). Suppose that the internetwork is operating properly for a while. Router B has an entry indicating it can reach Network 1 through Router A at a cost of 2. Now, say the link from Network 1 to Router A fails. After the Timeout timer for Network 1 expires on Router A, RA will change the metric for N1 to 16 to indicate that it is unreachable. In the absence of any mechanism to force RA to immediately inform other routers of this failure, they will remain “in the dark”. Router B will continue to think it can reach Network 1 through Router A.


Figure 174: The RIP “Counting To Infinity” Problem

This composite diagram shows part of the autonomous system illustrated in Figure 172. The top panel (#1) shows the normal state of the network, with RB able to reach N1 through RA at a cost of 2. In #2, the link between RA and N1 is broken. RA changes its cost to reach N1 to 16 (RIP infinity). In #3, Before RA can send out this update to RB, it receives a routine RIP message from RB indicating that N1 can be reached for a cost of 2. RA is then fooled into thinking it can use RB as an alternate route to N1, even though RB’s information originally came from RA in the first place. In #4, RA then sends this bogus information out, which is received by RB in #5. RB then increases its cost to 4, and on its next cycle will send this to RA, which will increase its cost to 5, and so on. This cycle will continue, with both routers “counting to infinity” (16).

 


Now, suppose RB's regular 30 second timer goes off before RA's next broadcast. RB will send its normal routing table, which contains a route to Network 1 at a cost of 2. Router A will see this and say “Hey, look, Router B has a route to Network 1 with a cost of 2! That means I can get there with a cost of 3, which sure beats my current cost of 16; let's use that!” So, Router A installs this route and cancels its Timeout timer. Of course, this is bogus information—Router A doesn't realize that Router B's claim of being able to reach Network 1 was based on old information from Router A itself!

It only gets worse from there. When it is time for Router A's regular routing table update, it will broadcast a route to Network 1 with a cost of 3. Now, Router B will then see this and say “Hmm. Well, my route to Network 1 is through Router A. Router A was saying before that its cost was 1, but now it says the cost is 3. That means I have to change my cost to 4”.

RB will later send back to RA, and back and forth they will go, each incrementing the cost two at a time. This won't stop until the value of “infinity” (16) is hit—thus the name counting to infinity. At this point both routers will finally agree that Network 1 is unreachable, but as you can see, it takes a long time for it to happen.


Previous Topic/Section
RIP General Operation, Messaging and Timers
Previous Page
Pages in Current Topic/Section
1
2
34
Next Page
RIP Special Features For Resolving RIP Algorithm Problems
Next Topic/Section

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!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.