I know our own Keith Barker was playing with these pesky timers recently on 12.4 T code and he wrote up his findings here:
I hope you find it helpful.
That is a very good read. I guess I'm totally confused now because I can emulate that. However, most books claim that a route goes into holddown when the metric increases. That is also the behavior I found in my older router. This article shows a route going into holddown after its invalid timer expired. So are both conditions a trigger for holddown?
Actually I do not think so. Without running my own tests - I think we can take the Command Reference at face value here - it states:
"A route enters into a holddown state when an update packet is received that indicates the route is unreachable."
I think the texts we read about the Holddown Timer are speaking generically about Holddown Timers - not the Cisco holddown timer addition to RIP (as I am sure you know - it is not in the RIP RFC).
Thanks for your help. I think there are some inconsistencies between different IOS versions. One of my references was Jeff Doyle's TCP/IP Vol1 second edition. As you mentioned, the first description of holddown timers was in a generic chapter talking about link state vs distance vector protocol features. However, the examples used were clearly rip. He has the following statement:
"If the distance to a destination increases (for example, the hop count increases from two to four), the router sets a holddown timer for that route. Until the timer expires, ther router will not accept any new updates for the route."
The other book that I've been referencing is the BSCN book by Catherine Paquet and Diane Teare. It has a clear example of a route going into holddown after a neighboring router sent a poison route. I can reproduce this on my older routers, but not my newer ones.
Keith example shows the route going into hold down when he brings a neighboring router interface into passive mode. I can reproduce this on the newer code. I guess I'm going with what the Command Reference says for how it is "supposed to" work. Thanks again for your help.
I thought I fully understood this, but I am having a couple of doubts. Additionally this should be a simple topic, but I see all sort of contradictions in the documentation I have read.
Some publications seem to say that a rip route goes into holddown when a downstream router advertises it as unaccessible (metric 16 or poison route). Other documentation states that if a downstream router advertises it with a worse (higher) metric. From what I can tell a router goes into holddown when it is has been advertised as inaccessible by the source of the route in the route table. Can someone confirm that is the only trigger to put the route into holddown?
The next clarification involves the behavior of a route in holddown. Some documenation states that it ignores all routes to the same destination. Other documents state that the router ignores any routes that are equal to or inferior to the route before it was placed into holddown. From what I am seeing, I believe that the router ignores all routes to the destination when the route is in holddown. The exception would be if the original router started advertising the route as reachable again.
My third (and last) question is in regards to RIP Holddown timers on current code. For example does it still work the same on 12.4T. I have a router running this code and when it receives a poisoned route, it is immediately flushed from the table. So there seems to be no concept of holddown in this version of code. Could be a bug or something. "show ip protocols" still shows a holddown timer. Has anyone seen this behavior?
Hello Paul -
I labbed this up using this topology:
With the assistance of syslog, and some patience, here is what I learned today.
Holddown timer begins when a route learned from a downstream router exceeds the upstream routers invalid timer.
When hold down starts on the upstream router it won't believe ANYTHING new about that route, better metric or worse from the original source, until the holddown timer expires.
I had started with R1 sending 184.108.40.206 with a metric of 10. After disabling the Fa0/0 on R1 and waiting for R2s invalid timer to expire, and then during holdown time on R2, enabled the Fa0/0 again on R1, and sent the 220.127.116.11 with a metric of 5, but R2 wouldn't budge, during it's holddown.
If a triggered update is sent from a downstream router, (R1 to R2, regarding 18.104.22.168, R2 will delete the route immediately (along with poison reverse, and pass on the bad news to R3).
If R1 simply stops talking, and R2 hits the invalid timer for that route, it will begin the holdown, and send a poisoned route to R3. Because R3 got the poisoned route from its downstream router (R2), R3 will delete the route, and not go into hold down.
I learned a ton today.
Let me know if you have other questions.
That is awesome. Thanks to both you and Anthony. That is exactly what I'm seeing on current code. There is a ton of documentation out there that is incorrect on this subject. Additionally, I think that old code (12.0 for example) placed poison routes in holddown. That no longer seems to be the case. As you stated if you trigger an invalid route, it will remove the route and poison the neighbors immediately. It's funny how a simple concept can be so complicated when the documentation is inconsistent and the behavior is different on different versions of code. I mean this is RIP, the simplest of all routing protocols. Thanks again.
I manipulated routes with offset-lists on the source router. If you specify "offset-list 0 out 5 <intf>" in router configuration mode, it will increase the metric by +5. I also filtered incoming rip from one neighbor or another using an ingress acl. I basically built a small lab of 3 routers and ran rip debugs for a few hours to test different scenarios.
Thank you very much, I´m studding to pass ICND2 with Wendell Odom book, and trying to test the hold down timer in a lab with GNS3. Nothing had sense to me when I was testing in the lab, what was explained in the book, because I saw how all the switches just deleted the routes when they received a trigger update with a poison route, without passing the hold down timer. Now I´ve found this discussion and everything is getting sense. But, as I told you, I want to pass the exam, and that’s why I ask you taking into consideration your experience in Cisco certifications exams. Should I answer a possible question in the exam with what is implemented really in actual Cisco IOS, or should I stay on line with the official certification study book (Wendell Odom 2nd Edition)? This is even a “Key Topic” in this book when it says:
“After hearing a poisoned route, start a holddown timer for that one route.
Until the timer expires, do not believe any other routing information about the
failed route, because believing that information may cause a routing loop.
However, information learned from the neighbor that originally advertised the
working route can be believed before the holddown timer expires.”
Thank you very much for your time,
Hello Alkuin, any router would start the hold down timer if it does not receive any update (by default during 180 seconds) to a route from its next hop (for that route). I mean, if R1 has any other router connected, and this router stops to listen updates to 22.214.171.124 from R1, it would start the hold down timer also, after 180 seconds.
Hello Joel, so if for ex link between R1 and R2 down. After invalid timer, the hold down timer on R2 will start, because R2 still sending the route of 126.96.36.199 to R3, hold down timer on R3 will not be activated. So, in this case only R2 activate the hold down timer. CMIIW. One more thing, once R2 activate the hold down timer, it will trigger a poisoned route to other router ("If R1 simply stops talking, and R2 hits the invalid timer for that route, it will begin the holdown, and send a poisoned route to R3.") . CMIIW