Actually I'm not even sure that the metric is set to 16 inside the routing table, I tend to think that it remains unchanged.

So I'd better ask for the complete view:

1) What triggers the start of hold-time timer?

Is it a RIP Response message that contains the corresponding subnet with metric greater than the existing one in the routing table, but lower than 16 ?

Or is it a RIP Response message that contains the corresponding subnet with metric greater than the existing one in the routing table, including 16 ?

Or is it a RIP Response message that contains the corresponding subnet with metric equal to 16 ?

2) What actions performs a router when the hold down time is triggered?

Once the condition to trigger the start of hold down timer was fulfilled, what changes performs the router in its routing table? And as well what changes performs the router in the next RIP Response messages, compared to RIP Response message it sent before receiving that trigger for hold down timer?

Hello Petru,

1) e 2)

when metric for a route changes with an increase of metric the router starts the holddown timer for the route: the new update is not accepted immediately.

>> Is it a RIP Response message that contains the corresponding subnet with metric greater than the existing one in the routing table, but lower than 16 ?

yes

This is seen a safety measure: it is better to wait some time before accepting new updates for the route: the update could contain a false information and so in order to improve safe convergence is better to wait.

during hold down the route is still shown in the routing table with the original metric but with a line that says

possibly down and the holddown timer is showed too.

Hope to help

Giuseppe

And the route is still advertised with the metric from the routing table ?

Hello Petru,

what is sure is that the metric cannot be the new higher one because that route is not accepted by the local router.

Advertising the old lower metric could be wrong too or it may be the best thing to do to isolate the topology change: if downstream routers cannot detect a change they are not involved in the routing process.

I didn't find a clear example so a lab should be done for this

Hope to help

Giuseppe

Edison you blew away our understanding of the hold down timer :-)

It means that according to you:

1) The start of hold-time timer is triggered by a RIP Response message that contains the corresponding subnet with metric greater than the existing one in the routing table, INCLUDING also 16 ?

2) Once the condition to trigger the start of hold down timer was fulfilled, the router does not change the metric in the routing table BUT it advertises the route in the next RIP Response message with a metric of 16 (or with the metric received from the neighbour ??? - in your example these 2 are the same, but if the metric were not 16, which would be the situation?).

I'm really confused now, I need to simulate this hold down case.

1) On my test, the hold down timer was triggered by shutting down the interface.

The router sent the interface IP address to all RIP routers with a metric of 16. The metric of 16 causes each RIP router to declare that route as inaccessible. This route won't be installed in the routing table due to its metric but this route will be advertised for the duration of the hold timer with a metric of 16.

2) Once the hold down timer expires, the RIP routers will no longer advertise the route at all. If the interface recovers, the route will be added and sent on a RIP triggered update.

Let's split then the problem in 2 different cases:

A) the router receives a RIP Response from a neighbour, containing a subnet with a higher metric than the router has in its routing table, but still lower than 16

B) the router receives a RIP Response from a neighbour, containing a subnet with a metric of 16, and the route to that subnet exists in the routing table.

You checked the case B) and the 2 conclusions are (please confirm):

B1) the router still keeps in its routing table the route to the subnet that was advertised with metric 16, but with the metric that was in the routing table before the router received the metric of 16.

B2) the router advertises that subnet with a metric of 16 during the hold down period to all its neigbours (including the neighbour it received the subnet with metric 16 ?)

For Case A there was a partial answer from Giuseppe:

A1) the router still keeps in its routing table the route to the subnet that was advertised with higher metric, but with the metric that was in the routing table before the router received the higher metric.

A2) ??? During the hold down period the router advertises that subnet with the old lower metric to all its neigbours (except to the neighbour it received the subnet with higher metric, as it advertises to this neighbour a metric of 16, in accordance with split horizon with route poisoning feature) ??? Or it advertises the higher metric ???

If to generalize your observations from case B) it should then advertise the higher metric, but needs to be confirmed.

Petru,

You have accomplished a very hard task. You just gave me a headache :)

I'll try to address your query and sorry this will be the last time, here we go:

A) the router receives a RIP Response from a neighbour, containing a subnet with a higher metric than the router has in its routing table, but still lower than 16

Ok, I'm assuming this is a higher metric route from another router. I follow you so far.

B) the router receives a RIP Response from a neighbour, containing a subnet with a metric of 16, and the route to that subnet exists in the routing table.

It eliminates that route from the routing table but continues to advertise it to other neighbors with a metric of 16 during its hold-down state. If there is similar route from another neighbor with a metric lower than 16, this route will be chosen and installed in the RIB.

I hope this is clear enough.

Edison, thanks for your patience, you could put the headache pill on my account :-)

Regarding this topic: the information on the net, inside the networking books, on Cisco site, the answers provided by different persons etc...well all these were contradictory.

Here are my conclusions after this long investigation:

1) A route enters into a hold-down state when a RIP Response packet is received indicating that a route's metric (route received from the same neighbour as the recorded route in the routing table) is higher than the metric recorded in the routing table. (here it is included the case when the new metric is 16)

2) Internally inside the routing table the router changes the metric for that route, so it updates it with the new higher metric. And also it marks that route as being inaccessible.

3) Then the router sends RIP Responses to the other neighbour routers, containing that route with the higher metric.

4) Routes in the hold-down state are however used for packet forwarding. In the worst case, packets are forwarded toward the router that was previously

connected to the destination network, which drops them. In the best case, they are forwarded along a potentially suboptimal but valid path.

5) If during the hold-down state the router receives an update for that subnet, with a lower metric, then:

-> if it comes from the same neighbour: the route is set back to accessible, the hold time timer is stopped and the lower metric is recorded.

-> if it comes from a different neighbour: the new route is discarded, it does NOT replace the hold down route.

I hope my synthesis is correct.

Thanks for the detailed description.

Mat

Hello,

Sorry to dig up this old post that seems to be a headache to many including me but i'm seeing something else with the Holddown timer. I was under the assumption that holddown timer works as described here until I ran into two sources and started testing. The sources are CCIE Routing and Switching Exam Certification Guide, 3rd Edition page 192 and blog post from CiscoNinja at http://cisconinja.wordpress.com/2009/04/27/rip-timers/

Ok so basically the Exam Cert Guide say that holddown timer will only be started after the invalid timer expires. The CiscoNinja blog say the same thing but actually does a very detailed lab writeup on it (it is really amazing you should read it). Basically the blog post states:

"So what exactly causes holddown to occur?  Earlier when we looked atthe invalid timer, we saw the route placed into holddown when theinvalid timer expired.  As it turns out, this is the only time that the holddown timer is used."

So going to your previous post:

1) A route enters into a hold-down state when a RIP Response packet is received indicating that a route's metric (route received from the same neighbour as the recorded route in the routing table) is higher than the metric recorded in the routing table. (here it is included the case when the new metric is 16)

Actually that does not seem to be right. When a neighbor receives an triggered update marking a router inaccessible that router will advertise it for duration (advertise inaccessible duratoin sec = flash timer sec - invalid timer sec) and then delete it. If during that time anyone gets a better router that route is accepted! I know that doens't sound right but that's what i see in the lab. The only time you will get a router in a hold down state is if you are using timers to detect that a route went down. Therefore an invalid timer would have to expire (that's when the route is "possibly down" but still forwarding traffic that way) , after the invalid timer expires holddown timer starts.

2) Internally inside the routing table the router changes the metric for that route, so it updates it with the new higher metric. And also it marks that route as being inaccessible.

I agree with that just marks it as 16 which is an infinite metric in RIP which is converted to 4294967295 in the routing table.

3) Then the router sends RIP Responses to the other neighbour routers, containing that route with the higher metric. Yes this is called a triggered update.

4) Routes in the hold-down state are however used for packet forwarding. (Yes) In the worst case, packets are forwarded toward the router that was previously

connected to the destination network, which drops them. In the best case, they are forwarded along a potentially suboptimal but valid path.

5) If during the hold-down state the router receives an update for that subnet, with a lower metric, then:

-> if it comes from the same neighbour: the route is set back to accessible, the hold time timer is stopped and the lower metric is recorded. Based on my testing the Cisco Ninja blog this is not true. All routes no matter who they come from are discarded during the hold down timer.

-> if it comes from a different neighbour: the new route is discarded, it does NOT replace the hold down route.

I know that's a lot of stuff to read, but there is so much information out there that's contradicting itself or showing something else in the lab.

Thank you.