I'll throw my hat into the ring...
First I don't believe there is way to disable poison-reverse.
Poison-reverse forces the removal of the bad route due to the infinite metric being advertised, without it you would be forced to wait the full amount amount of time for the timers to drop the route. This is going to be useful in a multi-hop environment with loops. Turn on debug ip rip and watch the routing updates. The poison reverse essentially confirms the update has been received and a bad route is not being passed along to other devices, speeding up convergence.
Sorry to open this back up, but I have considered a situation wherein poison reverse would help: Frame relay hub-and-spoke with multipoint instead of point-to-point subinterfaces.
R1 and R3 connect to R2 S0/0 interface (through a frame relay 'cloud'). They aren't connected directly to each other--R1 and R3 are only connected to R2 and it's through the same interface.
R1 sends out a routing update to let the other routers know that is has dropped a network. If R2 obeys split horizon, it won't send that update back out the same interface from whence it came. R3 will never know. With poison reverse, however, it would be pushed out that interface regardless of split-horizon.
If there's a flaw to this logic, let me know. I'm definitely not a CCIE or anything.
I don't see any flaw there but that would be rather an exception than a regular scenario. With split horizon rule the concern is valid routes.
Actually there is a flaw in your argument: if the split horizon in in place R3 will never learn about the route that just died behind R1 and R2 has no reasons to send a poison reverse out to R3 or any other router connected to the multipoint interface
WOW- this is so old that I didn't even relise I was opening one of my own posts!
@xeran - the case you have quoted is the quintessential "when you must not use split-horizon" case.
There is nothing wrong with your logic - apart from the fact that IF split horizon is in operation, R3 would NEVER have learned that the network on R1 existed in the first place (because R2 would have never advertised it back out the interface that it learned it on)
So the poison reverse bit is totally irrelevant. [Edit: I guess I was a bit slow - Christian already pointed this out]
@Justin - this thread just got resurrected so I thought I'd better explain your flaw:
without it you would be forced to wait the full amount amount of time for the timers to drop the route.
This is not so. I believe you are confusing a "Poisoned Route" with "Poisoned Reverse" When a router looses a route, it sends a triggered update advertising the cost to that network as 16. THIS IS NOT POISONED REVERSE.
Other routers receiving this update send a triggered update advertising the cost to that network as 16 - including an update back to the source. It is THIS update which is the poisoned reverse update.
This is going to be useful in a multi-hop environment with loops.
Why? What you haven't explained is how this update does anything to improve convergence - after all, you are only updating devices that already know that the route is unreachable.
The only scenario I can contemplate involves the fact that RIP is sent on UDP - an unreliable protocol. So it is conceivable that on a multi-access network (with R1, R2 and R3 sharing a common subnet) it could be that router (R1) missed a triggered poisoned update sent by R2 but then caught the poisoned-reverse update sent by R3.
Apart from that, as @xeran explains poisoned reverse updates are useful when we are NOT using split horizon, but my original query was related to finding an explanation of the statement in the RFC 1058 that says "split horizon with poisoned reverse is safer than simple split horizon".
Perhaps I am expecting too much. Perhaps it is only referring to the reliability factor that I mentioned above. I still don't have a good answer!