Routing Information Protocoll – RIP Timers

Sometimes its the simple things that are struggled with. RIP is one of those. Most CCIE candidates understand that we can change the interface or global parameters for updates, unicast, multicast, etc. What does take some time, is figuring out the global timers, especially if a person is not sure how they interact.

In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.

Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)

Here is our topology.  Keep your attention on R2, and that will be the focal point for this lesson.


Let’s set up some unique values, so we can see the results.
Defaults are:

Update: 30
Invalid: 180
Hold Down: 180
Flush: 240

We will use 30,  40, 10 and 90 respectively.

We can see the results of our changes with show ip protocols.

We can see that R2 is learning 2 routes from R3, the and R2 received the last update 7 seconds ago, based on the output.

Let’s enable debugging so we can see the play by play.

Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned network with a hop count of 8.

After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process.   While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing  updates being sent from R2, at 30 second intervals.

It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2  for the, R2 would use it. (In our example, had a metric of 8. If R2 learned about the with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)

R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.

R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.

Another normal update, being sent by R2, including the poisoned routes.

While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.

So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.

Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.

Another update clicks off, and then we approach the 90 second flush timer

Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.

Now the routes don’t show up in the routing table either.

If we use context sensitive help, we find one more parameter for the timers: