RIPv2 is probably one of the simplest routing protocols. Even its timers are often described as ‘basic’ – but how basic are they? I mean sure, we know ‘Update timer’ is 30 seconds, ‘Invalid After’ timer is 180 seconds, ‘Holddown’ timer is 180 seconds and finally ‘Flush After’ timer is 240 seconds. However, I found that those timers and their function are somewhat poorly, or even wrongly, documented in some online posts.

As always, no better way to understand any technology than run it in a lab. I’m going to explain, in details, RIPv2 timers. First, starting with this simple network:

Each one of those routers has a loopback interface matches the router number. For example, R1 has loopback1: 1.1.1.1/32, R2 has loopback2: 2.2.2.2/32 and so on. I will configure RIPv2 as below for all routers (while changing the loopback network statement accordingly):

Okay, so at this point, there is nothing special in the config. This is a snapshot of R1 routing table:

Let’s do a deep dive into RIPv2 timers:

1. Update timer: Default value is 30 seconds. RIPv2 routers will send (and expect) full routing update every 30 seconds.
2. Invalid After timer: Default value is 180 seconds. The receipt of a routing update will reset this timer. As long as the this timer is on, the router WILL NOT consider any other RIPv2 timers – This is very important as we will see later.
3. Holddown timer: Default value is 180 seconds. This timer starts when Invalid After timer expires.  The router will remove the route when this timer expires (IF Flush After timer is longer than this timer). As long as the this timer is on, a few things happen:
   1. The route is marked as “Possibly down” in the router table.
   2. The router starts advertising this route to other routers on all RIPv2-enabled interfaces (even overriding Split Horizon) as metric of 16 – inaccessible.
   3. The router will accept ABSOLUTELY NO routing updates for this route – even if a better metric is received. I’ve seen some online posts indicating that if a router receives a lower metric while in Holddown state, it will accept it and update its routing table. This is not what the official documentation says, as we will also see in this post.
4. Flush After timer: Default value is 240 seconds. The receipt of a routing update will reset this timer. The router will remove the router when this router expires (IF Holddown timer is longer than this timer).

So what does all the above mean exactly?! Here is the sequence of events so we can understand this better (assuming all timers are using default values):

• Let’s assume that a route has just been received (resetting Invalid and Flush timers) for the last time.
• Both Invalid and Flush timers start counting.
• Invalid timer expires after 180 seconds, Flush timer is also at 180 seconds – 60 seconds left to expire.
• Holddown timer starts. The router flags the route as ‘Possibly down”, advertises it as ‘inaccessible’ – metric of 16 and locks the route entry, accepting no update for it.
• Holddown timer reaches 60 seconds, Flush timer reaches 240 seconds and expires causing the route to be removed from the routing table.
• At this point, the router will install the new advertised route, if any.

Here’s a visual representation (think this helps) of those timers and how they overlap. The red line demonstrates when the route is going to get flushed.

Time for labs! I’m going to start with default values first, then will change them to make it easier to observe. Also, I’m going to show a couple of scenarios to cover all possible timer values. Throughout all scenarios, we’re going to focus on R1 and how it is receiving network 5.5.5.5 from R5 which is currently being learned via R4 with a metric of 2 hops.

I configured R4’s gig0/1 as passive, enabled ‘debug ip rip’ on both R1 and R4. So, let’s see what is happening:

Above, you can see that affected routes were last updated 44 seconds ago, network 5.5.5.5 is being received from the other end via R2, but R1 is not ready yet to use it.

Above, its been 3:05 since the last update for the affected routes, Invalid after timer expires, Holddown timer starts, and R1 start advertising network 5.5.5.5 with metric 16. Also as shown below, being received by R4.

Since the Holddown timer is still on, R1 shows 5.5.5.5 is ‘Possibly down’ now

Now as explained earlier, the route should be flushed when Flush after timer expires at 240 seconds (60 second for Holddown). As captured above, Holddown timer starts around 13:56:57 and as you can see below, the route has been flushed before 13:58:06 – roughly 60 seconds!

Finally – The router accepts 5.5.5.5 that is being advertised via R2, installed it in its routing table and sends “Flash” update to R4 as seen below:

There is one important note that I want to cover here before wrapping up part 1 of this post which I already referred to briefly earlier and that is, the Holddown timer will accept NO UPDATES WHATSOEVER even if a better metric is being received. Now I have left everything as it is above, R1 is still receiving 5.5.5.5 from R2 with a metric of 3.

What I’m going to do is configuring R2’s gig 0/0 as passive, to trigger the timers on R1 for missing this route, then I will immediately remove it and also remove the passive interface I configured earlier on R4 so that it starts advertising 5.5.5.5 with a better metric (of 2) than R2. Regardless of all of that, R1 should act the exact same way it did earlier and should only install 5.5.5.5 from R4 at the end of 240 seconds which is the Invalid after time.

Here, I added the passive interface command for R2, waited for the Invalid timer to expire, Holddown timer to start and removed the passive commands from both R2 and R4

As clearly shown below, R1 now is receiving 5.5.5.5 from both R2 and R4 (with a better metric than before) still, the router will NOT use any of them as long as the Holddown timer is on:

Now compare the time stamps when Holddown timer starts around 16:55:35 with the time stamp below 16:56:35 where the 5.5.5.5 route is flushed from the routing table. Exactly 60 seconds of Holdown timer, because Flush after timer has expired as explained earlier.

Finally, the new (and better) route is installed in the routing table, triggering flash updates on R1:

In the second part of this post, I will cover different scenarios when we have non-default values for those timers.