| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RIP Special Features For Resolving RIP Algorithm Problems (Page 3 of 4) 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.
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. |