RIP/v2 triggered route poisoning and holddown time

[de-doctor]

Hello all,

This question may have already been asked a couple of times, but I would just like to confirm my (still basic) understanding of the RIP timers.

Currently I'm reading the ICND2 section about routing loops in a redundant internetwork.

I understand that a holddown timer is to prevent a router from believing any incoming updates about a particular subnet (except from the original router who poisoned the subnet in the first place) which has been previously advertised as down (metric 16).

I know there are 4 timers: update interval (30), invalid (180), holddown (180), and flush (240).

This is my understanding of what will happen if a subnet suddenly goes down (correct me if I made a mistake somewhere) :

1) When a directly connected subnet (10.3.1.0/24) on R1 goes down, R1 immediately sends a triggered update to it's neighbouring routers and poisons that down subnet by setting the metric for that subnet to 16.

2) When R2 receives this triggered poisoned update about subnet 10.3.1.0/24, the RIP process on R2 skips the invalid time and places the route for subnet 10.3.1.0/24 into a holddown timer. By doing this, R2 immediately removes the route for subnet 10.3.1.0/24 from it's routing table (?). However, this route is still present in the RIP database (show ip rip database) for the duration of the holddown time (180).

3) During the holddown time, R2 will not believe any incoming updates about subnet 10.3.1.0/24 with a lower metric then 16, UNLESS these updates are coming from R1.

I know that the neighbouring routers will also send a poisoned reverse, but I didn't mention that to reduce clutter (:P). Is my understanding correct?

Thanks for reading.

[Peter Paluch]

Hello,

I understand that a holddown timer is to prevent a router from believing
 any incoming updates about a particular subnet (except from the 
original router who poisoned the subnet in the first place) which has 
been previously advertised as down (metric 16).

This is not correct. The holddown timer prevents unwanted changes to a route if and only if that route has not been received from its current next hop in the seconds. In essence, when seconds elapse since the last time the route was received in a RIP update, the route is declared invalid and is put into the holddown state which can last seconds. A route in holddown state is announced to other neighboring routers as unreachable (using the metric of 16), and all received updates about the network are ignored, regardless of their metric value or their advertising router.

However, if a router receives an update about a previously reachable network from its current next hop and the metric is set to 16, the route is immediately flushed from the routing table and further announced as unreachable. There is no waiting for any timers. If a route is flushed from the routing table, all timers concerning that route are removed as well. Thus, a flushed route does not go through holddown states. It is interesting how many textbooks seem to be wrong on the subject.

What is valid, however, is that even though the route is indeed immediately removed from the routing table, it remains in the RIP database to be further advertised as unreachable for some time, and it remains in the RIP database for the period of - . Note that this is very similar to a situation if a route is not received for seconds - it would enter the holddown state, and if it was still not received from any neighbor, it would gradually age until the timer fires. Thus, since the route entered the holddown state, it would require - seconds to be completely flushed. Still note, however, that we are not talking about the holddown timer and the value setting here!

1) When a directly connected subnet (10.3.1.0/24) on R1 goes down, R1 immediately sends a triggered update to it's neighbouring routers and poisons that down subnet by setting the metric for that subnet to 16.

Correct.

2) When R2 receives this triggered poisoned update about subnet 10.3.1.0/24, the RIP process on R2 skips the invalid time and places the route for subnet 10.3.1.0/24 into a holddown timer.
 By doing this, R2 immediately removes the route for subnet 10.3.1.0/24 
from it's routing table (?). However, this route is still present in the
 RIP database (show ip rip database) for the duration of the holddown time (180).

Not entirely correct. After a poisoned update about a network is received, the route will be removed from the routing table immediately and from the RIP database after 240 (flush) - 180 (invalid) = 60 seconds.

3) During the holddown time, R2 will not believe any incoming updates about subnet 10.3.1.0/24 with a lower metric then 16, UNLESS these updates are coming from R1.

Not correct. If a route is in holddown state, all incoming updates about it are totally ignored, and it is absolutely irrelevant whether they come with a better metric, even better that the original, and from whichever neighbor they come.

Best regards,

Peter

[de-doctor]

Thanks for answer, but what if there was a scenario like this:

10.3.1.0/24

|

R1---R2

\      /

  \   /

   R3

Subnet 10.3.1.0/24 off R1 suddenly went down. R1 immediately triggers poisoned route for 10.3.1.0/24 to R2 and R3.

R3 receives this poisoned route from R1.

But before R2 receives this poisoned route, R2 sends it's normal RIP update for subnet 10.3.1.0/24 to R3 with a metric of 2 (as normal).

R3 receives this update from R2, and adds this route for 10.3.1.0/24 to it's routing table, with a metric of 2.

Next R3 forwards this update about subnet 10.3.1.0/24 to R1, with a metric of 3. So a counting to infinity begins at this point.

Back to the beginning: when R3 first receives the poisoned route for 10.3.1.0/24 from R1, R3 immediately removes the entry for 10.3.1.0/24

from it's routing table (but not from the RIP database). After this, R3 ignores any future updates from other routers about subnet 10.3.1.0/24 as you

said.

In the ICND2 book, it is said that when a router (R3 in this case) receives a poisoned route, it sets this route (10.3.0.1/24) into holddown time.

And during this holddown time, ignores any updates from other routers about 10.3.1.0/24.

So if I understand you correctly, this is not holddown?

[Peter Paluch]

Hi,

But before R2 receives this poisoned route, R2 sends it's normal RIP 
update for subnet 10.3.1.0/24 to R3 with a metric of 2 (as normal).
R3 receives this update from R2, and adds this route for 10.3.1.0/24 to it's routing table, with a metric of 2.
Next R3 forwards this update about subnet 10.3.1.0/24 to R1, with a metric of 3. So a counting to infinity begins at this point.

I do not believe this scenario is correct. The R3 may receive first a poisoned update from R1 and a normal update from R2, and thus start pointing towards R2. However, the R2 still has to process the poisoned route from R1, and when it does, it will flush the network from its routing table and send out its own poisoned update, causing the R3 to remove the route via R2 and ultimately erasing this network from all routers in the topology.

The counting to infinity between R2 and R3 moreover assumes that the split horizon has been deactivated. Normally, routers would not advertise a network to its own next-hop.

In the ICND2 book, it is said that when a router (R3 in this case) 
receives a poisoned route, it sets this route (10.3.0.1/24) into holddown time.
And during this holddown time, ignores any updates from other routers about 10.3.1.0/24.

We usually talk about a holddown only when a route remains in the routing table but all updates regarding this route are ignored. Receiving a poisoned route causes the route to be removed from routing table immediately, and therefore, talking about holddown in such cases is simply incorrect. Once again - a route can be in holddown state only if it is in the routing table. If the route is not in routing table, no holddown comes into play.

In the RIP database, a route for which a poisoned update was received is declared invalid - yes - but this invalid state is not identical to a holddown because this "garbage" entry in the RIP database can be updated at any time by any router advertising any non-infinite metric. A route in holddown state would not allow itself to be updated, which is clearly not the case here. Moreover, this route is removed from the RIP database after - seconds, not taking the timer into any account.

So if I understand you correctly, this is not holddown?

With respect to receiving a poisoned update, no, there is no holddown. The holddown would come into play if we missed 180/30=6 RIP updates in a row about a network but not if a poisoned update about that network was received.

Best regards,

Peter

[Iluvnetwork]

I have been looking for this info for more than two weeks and finally found the Truth. Thank you very very much Peter :) You are my Network Hero.