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
Triggered Updates
The routing loop problem we looked at in the previous topic occurred because Router B advertised Router A's route back to Router A. There's another aspect of the problem that is also significant: after Router A discovered that the link to Network 1 failed, it had to wait up to 30 seconds until its next scheduled transmission time to tell other routers about the failure.
For RIP to work well, when something significant happens we want to tell other routers on the internetwork immediately. For this reason, a new rule should be added to the basic RIP router operation: whenever a router changes the metric for a route it is required to (almost) immediately send out an RIP Response to tell its immediate neighbor routers about the change. If these routers, seeing this change, update their routing information, they are in turn required to send out updates. Thus, the change of any network route information causes cascading updates to be sent throughout the internetwork, significantly reducing the slow convergence problem. Note that this includes removal of a route due to expiration of its Timeout timer, since the first step in route removal is setting the route's metric to 16, which triggers an update.
You probably noticed that I said that triggered updates were sent almost immediately. In fact, before sending a triggered update a route waits a random amount of time, from 1 to 5 seconds. This is done to reduce the load on the internetwork that would result from many routers sending update messages nearly simultaneously.