This holddown processs is not clear, all sources contradict between themselves and with the tests I performed in GNS3/Dynamips:
R1<->R2<->R3<->R4<->R1(so 4 routers in ring)
and set 18.104.22.168/8 on R1-R2, 22.214.171.124/8 on R2-R3, 126.96.36.199/8 on R3-R4, 188.8.131.52/8 on R4-R1.
Then declared a loopback on R2 with 184.108.40.206/8 IP address, started rip debugging on all routers, performed a "shutdown" of the loopback interface and checked what happened till the 220.127.116.11/8 was removed from all routers and it was not advertised anymore by any router.
Then did "no shutdown" of the loopback interface and started again the test, just that now let's say that 10 seconds after the "shutdown" I did "no shutdown" to simulate that the network flips up/down.
I observed that immediately after the R2 detected that its loopback is down, it removed from its routing table the 18.104.22.168/8 network:
show ip route 22.214.171.124
% Network not in table
Then immediately R2 sent triggered updates containing only the subnet 126.96.36.199, with metric 16, to R1 and R3 and here's what was seen on R3:
RIP: received v1 update from 188.8.131.52 on FastEthernet0/0
184.108.40.206 in 16 hops (inaccessible)
RIP-DB: Remove 220.127.116.11/8, (metric 4294967295) via 18.104.22.168, FastEthernet0/0
RIP: Update contains 1 routes
Next, R2 and R3 removed from their routing table the subnet 22.214.171.124 and send as well triggered updates to their neighbors.
So in a matter of seconds the 126.96.36.199/8 network was removed from all routers' routing tables.
But then all the routers were sending periodic updates containing as well 188.8.131.52, with metric 16, during a period of 60 seconds.
After these 60 seconds, the route 184.108.40.206 was not advertised anymore by any router, the following message was in the debug info of all routers:
RIP-DB: garbage collect 220.127.116.11/8
As mentioned, I simulated as well the flipping up/down, by setting: shutdown, no shutdown, shutdown, and the update was quickly spread all over the routers each time, both for good news and for bad news.
The tests showed so that there is no hold-down mechanism at all... and this makes me unable to understand on my own the hold down mechanism.
That test showed as well something I was very surprised to see: that from the moment the subnet 18.104.22.168 went down till it was removed from the network and not advertised anymore by any router, passed only 60 seconds...hmmm where is this timer taken from ? 60 seconds could only happen after a route invalid timer expires till the route is flushed (240s -180s = 60s), but here we don't have anything to do with invalid timer etc...so in this case I'm completely puzzled about this behaviour.
An extra test when the new metric was higher but different than 16 showed the same behaviour. I simulated this metric increase by adding inside R2 an offset to the original metric when advertising it towards R3:
offset-list 1 out 3 f0/1
access-list 1 permit 22.214.171.124 0.255.255.255
Just to mention that the timers were the default ones:
timers basic 30 180 180 240
So to sum up:
- the theoretical part is contradictory, how hold-down process should work is not clear
- practical emulation test showed that no HOLD DOWN timer was started. Why this behavior? Additionally the route was flushed from the entire network 60 seconds after I typed "shutdown" command.