This topic is to discuss the following lesson:
Hi Rene,
I’ve been waiting for your debugging, Thank you very much about this, that’s was very Interesting to me.
Can you also do debugging about Flash Update Threshhold timer and Sleep Timer, please?
If I have some spare time I’ll see if I can debug these two.
The flash update threshold timer is apparently used to suppress the flash update (triggered update) when it’s X seconds within the scheduled routing update (which is sent every 30 seconds).
The sleeptime is a funny one…it sets the delay in milliseconds how long we wait to send the scheduled routing update when a flash update is sent. I looked around for this and even though the RIP command supports it, it doesn’t seem to work.
Rene
Brilliant as always, the Cisco docs are just confusing, thanks for this clarification.
Rene,
that’s a very detailed explanation. Thanks buddy, you are genius 
Ammar,
Awesome article. I have a question though: what happens if you change the timer for a router and not for others? While it’s better to have same timers; still, since no adjacency is needed to form, is it recommended if you change timer on one device only? I had seen such case where you have linux (unmanaged) router on one end and CISCO router at other and update timer being shortened in CISCO router only. Not sure about the consequences, then. Any thoughts?
-Deep
By unmanaged, I meant Linux router running RIP v2 but timers not changeable, at least on operational level.
Hi Deep,
RIP doesn’t form a neighbor adjacency so you could change the timers on one end only if you want. The only thing I can think of why you want to do this is if you want your linux router to learn routes ASAP. In that case, you could reduce the timers on your Cisco router only.
To keep things simple, it’s probably best to use the same timers everywhere
Rene
Hello Rene,
It’s brilliant explanation. There is one thing i dont uderstand.
When holdown timer activates R2 starts sending poison routes messages.
And R3 as you said immediately remove the route from the routing table. Also as you said R3 send back to R2 poison route message.
The question is ---- why does R2 not remove the route from routing table in spite R2 get poison route message from R3 ?
Hi Aleksandr,
This probably happens because R2 has learned the route through R1. It receives the poison reverse from R3 but that’s not where we learned the route from…
it wouldn’t make sense if we used this information to remove the route from the routing table
Rene
Hello,
I have one quick question with respect to RIPv1
Once Fa 0/0 is shut on R1, does the invalid and flush timer start immediately or or at next due of the update timer, because RIPv1 does not support triggered update
For example I am shutting down the interface where the next update is scheduled after 25 seconds
Thanks,
Thulasi
Hello Thulasi
The invalid and flush timers always start counting from the last update that has been received. The actual shutdown of the interface has no direct affect on these timers.
If you shut down the interface when the next update is scheduled after 25 seconds, 5 seconds have already expired on both the flush and invalid timers. At the moment of shutdown, the invalid timer will be at 175 seconds and the flush timer will be at 235.
I hope this has been helpful!
Laz
Thank you Laz. Its clear now
1 Like
Hey, Does Route Poisoning overrides the Split Horizon rule?
Hello Pamod
The quick answer is yes. Now let me explain further…
Route Poisoning, when implemented with Poison Reverse, overrides the Split Horizon rule in RIP. To fully understand this, we need to clarify the relationship between three related concepts:
- Split Horizon: The basic rule that prevents a router from advertising a route back out the same interface from which it was learned. This prevents simple two-router routing loops.
- Route Poisoning: When a route becomes unreachable, the router marks it as invalid by setting its metric to 16 (infinity in RIP). This is an explicit signal that the route has failed.
- Poison Reverse: The mechanism that sends the poisoned route (metric 16) back to the neighbor that originally advertised it, intentionally overriding the Split Horizon rule for that specific poisoned route.
Under normal operation, Split Horizon applies. However, when Network X fails, Route Poisoning kicks in. Router B marks the route with metric 16. Through Poison Reverse, Router B sends the poisoned route (metric 16) back to Router A, even though Split Horizon would normally prevent this. This explicit notification ensures Router A immediately knows the route is unreachable, rather than waiting for timers to expire.
So, when a route is poisoned, that poisoned route IS sent back to the source router with metric 16, effectively overriding Split Horizon for that specific advertisement. This provides faster convergence and more explicit loop prevention than Split Horizon alone.
I hope this has been helpful!
Laz
1 Like