Hi Jon,

An interesting idea! However, the router may receive various updates from different neighbors which may contain different metrics to the same network.

It would be logical to say that the route enter the holddown state when the router receives an update from the current next hop that contains a higher metric than currently recorded in the routing table.

However, even this explanation leaves me a bit confused. When a route enters the holddown state, it is - according to the Command Reference - advertised as unreachable by the router. This would mean that all upstream routers would remove this route from the routing table. I have never noticed this behavior, though.

I will check it on a testing topology and will be back in a while.

Thanks!

Peter

Peter

Yes apologes for that, i wasn't specific enough in what i said. You are quite right in that it would be an update from the current next hop otherwise it really wouldn't work that well :)

Jon

Hi Jon,

So I've made a simple experiment - three routers R1, R2, R3 interconnected in a row. The topology was running RIPv2. One of the edge routers, say R1, was also advertising a loopback network.

I have then applied the offset list on the R1 router to increase the metric of the advertised loopback network. The routers R2 and R3 have adapted immediately. No sign of any going through the holddown state appeared.

So the holddown in RIP appears to me to be... I don't know. I can't recreate the conditions under which it appears.

Best regards,

Peter

Peter,

As far as I can remember the hold down timer comes into play only when the router doesn't receive any updates for a network for 3 mins (default) from the router that originially advertised the best route to that network.

In your scenario make RIP passive on R1 and after 180 seconds, at which point both R2 & R3 would put the route for R1's loopback in holddown state, start advertising the same network from another router to R2 & R3 with a better metric and they would disregard that route till the route is purged from the routing table.

HTH

Sundar

Hello Sundar,

I have made exactly the same steps as you suggested here. The network which I expected to see in the holddown state is the 10.255.255.0/24. A strange sequence of events occured:

After the 180 seconds (the value of "invalid after" timer) passed, I repeatedly entered the "show ip route 10.255.255.0" command and saw this output:

R1#show ip route 10.255.255.0

Routing entry for 10.255.255.0/24

Known via "rip", distance 120, metric 1

Redistributing via rip

Last update from 10.0.0.6 on Serial1/1, 00:03:02 ago

Routing Descriptor Blocks:

* 10.0.0.6, from 10.0.0.6, 00:03:02 ago, via Serial1/1

Route metric is 1, traffic share count is 1

R1#show ip route 10.255.255.0

Routing entry for 10.255.255.0/24

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 10.0.0.6 on Serial1/1, 00:03:02 ago

Hold down timer expires in 0 secs

R1#show ip route 10.255.255.0

Routing entry for 10.255.255.0/24

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 10.0.0.6 on Serial1/1, 00:03:06 ago

Notice the line telling us that the holddown will expire in 0 seconds.

I have also changed the timers so that the holddown timer is significantly larger than the invalid timer. Absolutely no change has appeared: as soon as the invalid timer expired, the route went into holddown for 0 seconds (which frankly stayed there for around 4 seconds) and then the holddown state expired, no matter what value was set up using the "timers basic" command.

Any ideas? I'm stumped ;)

Best regards,

Peter

Peter,

I believe what you are seeing is the correct behavior as you were using the default values of '30 180 180 240'. In your setup the invalid and holddown timers are the same and therefore it doesn't stay in holddown state for more than a couple of seconds.

Try setting the RIP timer on all the routers to something like '10 30 60 90' and notice the behavior. I would expect the route should stay in hold down state for atleast 30 seconds.

HTH

Sundar

Hello Sundar,

In my previous post I have already noted that I did just that, with no difference. But I have repeated the experiment with the following timers:

timers basic 2 6 30 60

on all routers. Check the results:

R1#show ip route 10.255.255.0

Routing entry for 10.255.255.0/24

Known via "rip", distance 120, metric 1

Redistributing via rip

Last update from 10.0.0.6 on Serial1/1, 00:00:08 ago

Routing Descriptor Blocks:

* 10.0.0.6, from 10.0.0.6, 00:00:08 ago, via Serial1/1

Route metric is 1, traffic share count is 1

R1#show ip route 10.255.255.0

Routing entry for 10.255.255.0/24

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 10.0.0.6 on Serial1/1, 00:00:09 ago

Hold down timer expires in 0 secs

R1#show ip route 10.255.255.0

Routing entry for 10.255.255.0/24

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 10.0.0.6 on Serial1/1, 00:00:10 ago

No change whatsoever...

Best regards,

Peter

Weird. It seems to work though in my lab. It's two routers, R1 & R2, directly connected to each other. I have the timers set for '10 30 40 60'.

See below.

R1#show ip route 2.2.2.2

Routing entry for 2.0.0.0/8

Known via "rip", distance 120, metric 1

Redistributing via rip

Last update from 172.30.1.12 on Ethernet0/0, 00:00:33 ago

Routing Descriptor Blocks:

* 172.30.1.12, from 172.30.1.12, 00:00:33 ago, via Ethernet0/0

Route metric is 1, traffic share count is 1

R1#show ip route 2.2.2.2

Routing entry for 2.0.0.0/8

Known via "rip", distance 120, metric 1

Redistributing via rip

Last update from 172.30.1.12 on Ethernet0/0, 00:00:35 ago

Routing Descriptor Blocks:

* 172.30.1.12, from 172.30.1.12, 00:00:35 ago, via Ethernet0/0

Route metric is 1, traffic share count is 1

R1#show ip route 2.2.2.2

Routing entry for 2.0.0.0/8

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 172.30.1.12 on Ethernet0/0, 00:00:40 ago

Hold down timer expires in 37 secs

R1#show ip route 2.2.2.2

Routing entry for 2.0.0.0/8

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 172.30.1.12 on Ethernet0/0, 00:00:46 ago

Hold down timer expires in 31 secs

R1#show ip route 2.2.2.2

Routing entry for 2.0.0.0/8

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 172.30.1.12 on Ethernet0/0, 00:01:00 ago

Hold down timer expires in 17 secs

R1#show ip route 2.2.2.2

Routing entry for 2.0.0.0/8

Known via "rip", distance 120, metric 4294967295 (inaccessible)

Redistributing via rip

Last update from 172.30.1.12 on Ethernet0/0, 00:01:05 ago

Hold down timer expires in 13 secs

R1#show ip route 2.2.2.2

% Network not in table

R1#show ip prot

Routing Protocol is "rip"

Sending updates every 10 seconds, next due in 6 seconds

Invalid after 30 seconds, hold down 40, flushed after 60

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Redistributing: rip

Default version control: send version 1, receive any version

Interface Send Recv Triggered RIP Key-chain

Ethernet0/0 1 1 2

Automatic network summarization is in effect

Maximum path: 4

Routing for Networks:

172.30.0.0

Routing Information Sources:

Gateway Distance Last Update

172.30.1.12 120 00:01:43

Distance: (default is 120)

HTH

Sundar

Hi Sundar,

Thank you very much for spending your time and effort with my problem.

I have tried a different set of routers (a different platform, a different IOS) and on the second topology, it seems to work. So the behavior described by me earlier is either a feature or a bug of the particular IOS (I assume the latter).

So to summarize and to go back to the original question: the holddown state WILL be entered after no update for the network has been received for past "invalid interval" timer value. Is there any other way for a route to enter the holddown state? I think there is none.

Best regards and many thanks,

Peter

Peter,

Glad you were able to see what the holddown function did that it's supposed to do :-)

I can't think of any other reason for the route to enter holddown state other than the one that you stated.

HTH

Sundar

Hi Sundar,

Thank you very much!

My last question is: The IP Routing Protocols Command Reference states following:

"A route enters into a holddown state when an update packet is received that indicates the route is unreachable."

So far we have come to the conclusion that RIP does not behave this way: the RIP uses the metric of 16 to advertise that a network is unreachable, and upon receiving this advertisement, a router removes the network from its routing table immediately. The only way for a route to enter the holddown state is by missing the advertisements for this network for a certain period of time.

Do you think this is a factual error in documentation?

Best regards,

Peter

Hi Peter,

Honestly I don't understand how that could be true. Yes if the network is advertised as unreachable, with a hop count of 16, then the recipient would remove the route from the routing table instantly.

HTH

Sundar

Hello Sundar,

Thanks again! Okay, I'm glad that we share the opinion :)

Thanks to anyone for your efforts and guidance!

Best regards,

Peter