What scenario does RIP holddown timer prevent from?

johnifanx98

It is said to prevent flapping router like serial link. However, I feel it's prevented by invalid timer. Any typical example for holddown timer?

REMOVED UNNECESSARY QUOTED REPLY FROM PREVIOUS POST

I've made one like this. Comments welcomed!

Router A ---- Router B ---- Router C

And the connection between B and C is a serial link. At a time, the B-C connection becomes flapping, then A's holddown timer takes effect. But here is a thing. When will router B declare routes from C invalid, after invalid timeout, or, immediately when router B detected the serial link down?

johnifanx98

I'm trying to simulate a flapping router by power down routerC or shut down routerC's serial interface in packet tracer. However, on routerB the route entries from routerC are instantly deleted. Is this expected?

mohamedshajid

HoldDown Timer is not a part of RFC RIP (Protocol) at all it's from cisco which enhance the security indeed. So you should think it's not based on Routing Protocol (RIP).

If an new route, or indeed the downed route, come back up during the hold-down time, then obviously the route is no longer invalid. However, the hold-down timer must completely count to 180 before the route will be again deemed up, and therefore usable. This behavior of the hold-down timer is what causes RIP to have an slow convergance time

https://learningnetwork.cisco.com/thread/4893

johnifanx98

Thanks. I went through your link and found a Keith's blog,

How basic are RIP timers? Test your knowledge now.

It seems like we can use passive-interface to simulate a flapping interface. However, with debug enable for rip, I could not see tracing like "entering holddown...". Maybe this is a limitation to packet tracer.

NetworkVeteran

johnifanx98 wrote: »

However, with debug enable for rip, I could not see tracing like "entering holddown...". Maybe this is a limitation to packet tracer.

To see the "entering holddown" message, you need to enable "debug ip routing", not "debug ip rip".

(This is an old thread but with some nifty links for those studying RIP!)

NetworkVeteran

mohamedshajid wrote: »

HoldDown Timer is not a part of RFC RIP (Protocol) at all it's from cisco... the hold-down timer must completely count to 180 before the route will be again deemed up, and therefore usable.

Correct that the RIP RFC only refers to Cisco's "update" (30s), "invalid" (180s), and "flush" (240s) timers. There's no mention of the additional "hold-down" (180s) timer. While this hold-down state is quite important, a fourth timer is rather unnecessary. JunOS for example chose not to implement it, and by default IOS actually ignores it!

Consider this sequence--

T=0s (route goes down)
T=180s (no updates received; the invalid timer expires and the router's marked "possibly down")
T=240s (the hold-down timer expires and the route's flushed from the routing table)
T=360s (if the route weren't already flushed, this is when the hold-down timer would expire!)

Once a route is flushed, it's gone. For the hold-down timer to ever actually expire and the fourth timer to have an impact, it would have to expire before the route was flushed! Customer RIP timer values would be needed.

NetworkVeteran

This behavior of the hold-down timer is what causes RIP to have an slow convergance time

If you entirely eliminated the hold-down state and timer, RIP would still take three minutes to converge upon the loss of a best route. I would argue that the heart of RIP's slow convergence lies elsewhere.

What RIP really lacks is a hello protocol to detect the addition or disappearance of neighbors. It uses its update/response messages to more or less fill that role. When your "hello" message includes your entire routing database, it's not feasible to send it every second or two as you would with other routing protocols. You thus end up settling for what amounts to a hello-interval of 30s and a dead-interval of 180s, or perhaps 90s with some tuning.