Hello Tomasz,
I remember one thread created by Nicolas or Petrus some mounths ago that was about the real meaning of the holddown timer. He had done his own tests and his findings were in line with what is written in the CCIE study guide.
He was surprised that he had found this that actually was not present in previous forum threads.
I can only say as a partial justification of this lack of knowedge that RIP is not used often nowdays.
Also the implementation of Cisco RIP may be different in this aspect from that described in the original Bell-Ford algorithm.
Probably in another implementation a single holddown timer that is 6-7 times the update interval is enough instead of having flush timer, invalid timer and holddown timer. Take this is as a qualitative guess because I cannot find at the moment a comparison between Cisco implementation and other vendor implementations.
Actually, in RFC 1058 that describes RIPv1 it speaks of marking a route as invalid but it doesn't mention an invalid timer
http://www.faqs.org/rfcs/rfc1058.html
It reports:
>>
If we don't hear from G for 180 seconds, we can assume
that either the gateway has crashed or the network connecting us to
it has become unusable. Thus, we mark the route as invalid. When we
hear from another neighbor that has a valid route to N, the valid
route will replace the invalid one. Note that we wait for 180
seconds before timing out a route even though we expect to hear from
each neighbor every 30 seconds.
if we look for invalid timer inside the RFC we don't find it.
And this is probably the root cause of this common misunderstanding.
the command reference and most CCNA courses use the standard defined description.
One should perform a test may be with the help of an offset list to create an artificial increase in metric to observe reaction of downstream router receiving the modified update.
This should show if an holddowm timer is triggered on downstream router.
Edit:
I see that the cisco ninja blog has used the offset list as a method to test holddown.
Edit2:
I've found the thread I was meaning:
https://supportforums.cisco.com/message/606498#606498
as you can see this issue has caused headaches to some other interested colleagues
Hope to help
Giuseppe
