Advanced RIP Timers and Debugging Mechanics
To truly understand how RIP reacts to network failures, you must analyze its internal timers. The way RIP handles dead routes, holddown states, route poisoning, and database flushing is where many troubleshooting mistakes begin.
Advanced RIP Timers and Debugging Mechanics: Quick Summary
RIP uses four key timers: update, invalid, holddown, and flush. The classic Cisco IOS behavior can feel strange because the invalid and flush timers begin counting at the same time. With default values, the route enters holddown at 180 seconds but is flushed at 240 seconds, so the apparent holddown window is only 60 seconds.
Advanced RIP Timers and Debugging Mechanics: Table of Contents
1. The Four Core RIP Timers
RIP relies on four primary timers to maintain routing table stability. You can view the active timer values with show ip protocols.
- Update Timer (30 seconds): The interval at which the router sends its entire routing table out RIP-enabled interfaces.
- Invalid Timer (180 seconds): If no refresh update arrives for a route within 180 seconds, the route is marked invalid or possibly down.
- Holddown Timer (180 seconds): Once a route is invalid, the router places it in holddown and refuses new updates for that route.
- Flush Timer (240 seconds): The maximum time a route remains in the database without a valid update before it is deleted.
2. The Default Behavior: The 60-Second Holddown Anomaly
The most confusing part of RIP timer behavior is that the invalid and flush timers start at the same time. They do not run one after the other.
- 0 to 180 seconds: R2 waits after R1 goes offline. It misses several 30-second updates but does not immediately delete the route.
- At 180 seconds: The invalid timer expires. R2 marks the route possibly down, enters holddown, and sends a route poison update with metric 16.
- At 240 seconds: The flush timer expires. The route is removed from the routing table and database.
3. Debugging Scenarios: What Happens During Holddown?
Scenario A: The Original Router Comes Back with a Better Metric
R1 comes back online while R2 is in holddown and advertises the same network with a much better hop count. Modern IOS may log the received update, but the RIP process refuses to install it while the route is locked in holddown.
Scenario B: A Completely Different Router Advertises the Route
R1 is dead, but R3 advertises a path to the same network with a metric of 1 hop while R2 is still in holddown.
4. Modifying Timers to Reveal True Holddown Behavior
To see the holddown timer run to completion, manually extend the flush timer so the route is not deleted too early.
R2 - Extend Flush Timer
! Command format: timers basic [update] [invalid] [holddown] [flush]
R2(config)# router rip
R2(config-router)# timers basic 30 180 180 400
By pushing the flush timer to 400 seconds, the holddown timer has enough room to run its full 180-second cycle.
Debug Output - Route Leaves Holddown
! Debug output showing the route coming out of holddown naturally
Sep 3 16:31:58.515: RT: 1.1.1.0 came out of holddown
Sep 3 16:31:58.515: RT: add 1.1.1.0/24 via 192.168.23.3, rip metric [120/11]
Once the holddown timer naturally expires, the defensive lock is lifted. If the router receives a new update, even from a different neighbor with a worse metric, it can accept the route.
Summary of RIP Timer Mechanics
- RIP ignores updates for a route while that route is in holddown, even if the new update has a better metric or comes from a different neighbor.
- With default timers, holddown is effectively cut short to 60 seconds because the flush timer deletes the route at 240 seconds.
- Using
timers basiclets you extend the flush timer and observe true holddown behavior in a lab.