RIP is Routing Information Protocol, one of the IGP or Interior Gateway Porotocols called also a vector-based routing protocol in contrast with link-state, hybrid or path-based protocols. The function of this protocol is very simple, send updates about known networks through local interfaces enabled for this sending…
In this lab we use a standard version of Cisco IOS router.
RIP updates
By default RIP sends updates each 30 seconds.
in the snapshot showing the result of show ip protocols command, we can check that: sending of updates is every 30 second, in RIP version 2 (support for VLSM, etc.). The record shows also what networks, the R1 router is routing for and some sources of routing information he has received so far.
In this lab we change the value of the invalid timer to 90 seconds
to change RIP times we use the command timers basic, under router rip configuration mode
And let’s check what happens if we filter RIP updates R2 sends over fa0/0 link? (thus stopping sending updates about R2 routes)
Filter the updates about the first path
Before the filter
Before the filter, we check that route 2.2.2.2/32 has been adverstised twice from R2 in R1 routing table: the first route is 25 seconds old (via fastethernet1/1) and the second is only 14 seconds old (via fastethernet0/0)
Because R1 receives no updates about 2.2.2.2/32 on path fa0/0, the path is invalidated after the invalid timer
after the invalid timer (90 seconds), the route is no more in the router routing (default) table.
Filter the last path to the route
Let’s do the same thing of the other path (the last)
we filter at R2 updates about all routes on the second interface fa1/1
Because the last path to the 2.2.2.2/32 has been lost, the route in the routing table is marked as being inaccessible (after 40 seconds) and enter the holddown state (for 180 seconds)
in information about this route was expected in 30 seconds. but after 40 seconds, the route is marked as inaccessible (with infinity metric) and hold down for 180 seconds.
the hold down time expires in 180 seconds
In RIP database the route is marked as possibly down,
in hold down state does router accepts route updates?
as soon as the route enters the holddown state
first, we check using debug ip rip on router R1 that no updates are being received from R2
Are updates accepted during holddown? We send an update during holddown and check that the udpate is not accepted as the holddown counter keep counting down
when in hold down state the received update is not taken into consideration in the routing table, the timer continues…
flush timer into play
let’s stop our route advertising and try to understand when flush timer enters into play? Let’s configure the holddown timer (such as to have no effect) to be equal to 300 seconds to a period that is larger than the flush time which is by default 240 seconds
the new configuration is reflected in the show ip protocols command
The route is flushed after 240 seconds
after being flushed, the route is no more present in the routing table
As soon as an update is received, the timers (for the last path): flush and invalid timers are initiated to 240 and 90 seconds respectively.
If no update is received for the invalid timer, the route (last path) is put into the holddown state for the duration of the holddown timer
What happens if invalid+holddwon total time is lower than flush time?
If the invalid+holddown total time is lower than the flush time then the route disappears from the routing table before the flush timer expiration?!
Let’s confirm this hypothesis by recording the time of the next update and applying the distribute-list to stop udpates
the debug command show the time of updating rip route
After invalid “path” time the route is put into holddown state
after last path is lost the route is deleted (entering holddown state)
After 240 seconds the route is deleted
after flush time the route is deleted from the routing table (no more present)
Let’s now change the holddown timer to a value less, so that invalid+holddown time is less than the flush time
the new holddown time is 30 seconds (instead of 180 seconds)
We record the time of the last update before applying the distribute-list
the debug command show the time of updating rip route
After 90 seconds (1 minute and 30 seconds of the invalid time) the route enter the holddown state (lost the last path to destination subnet)
after 1 minute and 30 seconds the last path is invalidated
After only 30 seconds the route is NOT deleted
after 2 minutes and 40 seconds (160 seconds) the route is still in the routing table
But the hold down counter is (still) put to 0
Would it be able to be updated in this state? We suppress the filter so that update flow again…
as soon as the update is received the route is taken out of the hold down state
And yes, as soon as an update is received the route came out of the holddown state (that has expired)
It has not to wait to be flushed before being installed again in the routing table… show that flushing time and hold down operate separately!
As conclusion
in this lab we’ve checked the operation of RIP timers: update (path), invalid (path), hold down (route) and flush (route).
the timers update and invalid in our understanding are more tight to the notion of “path” that is a possibility ot reach a route: to reach a route we could have multiple paths, invalidating one path does not affect the reachability of the route (being served by other valid paths).
timers update, invalid and flush are tight: as soon as we receive an update all of these times get updated to the inital down counter value (30 second, 90 seconds and 240 seconds by default).
the holddown is triggered if the updated time +10 seconds has expired for the last path (by default 30+10+180=240 seconds). we checked that in case the total time (invalid+holddown) is less that the flush time, the holddown is marked with value 0 (ready to be updated) and the route is flushed after the flush time! in hold down state (have not reached 0 yet) no received update of the route path is accepted…
[…] help understand more the operation of those timers please consider our post: RIP time(r)s: let’s understand the flush operation (time) you’ll have the ability to reproduce the same test network and observe how real routers […]