RIP Holddown Timer

I want to make sure that I'm understanding the RIP holddown timer correctly as some of the sourced I've used for it say different things, and none of them seem to describe the way that it actually works if I'm understanding it correctly. Here are a few scenarios and what a few of the sources I've used say about it.

R1---- 10.0.12.0/24 ----R2
|
|
10.0.13.0/24 10.0.24.0/24
|
|
R3---- 10.0.34.0/24 ----R4---- 4.4.4.0/24

Picture didn't exactly turn out right, anyway there's also a serial link between R2-R4, 10.0.24.0/24

R1 S0/0 to R2 S0/0
R2 S0/1 to R4 S0/0
R4 F0/0 to R3 F0/0
R3 S0/0 to R1 S0/1
R4 loopback = 4.4.4.0/24
All routers run RIPv2 w/ no auto-summary and all interfaces are advertised by RIP

From Routing TCP/IP Volume 1:
"If the distance to a destination increases (for example, the hop count increases from two to four), the router sets a holddown timer for that route. Until the timer expires, the router will not accept any new updates for the route."

and

"The third timer is the holddown timer, although RFC 1058 does not call for the use of holddowns. The Cisco implementation of RIP does use them. An update with a hop count higher than the metric recorded in the route table will cause the route to go into holddown for 180 seconds (again, six update periods)."

This to me sounds like if the metric from the current best source increases, the route is placed in holddown. R3 currently has a 1 hop route to 4.4.4.0/24 through R4. I offset the metric by 1 outbound on R4 but instead of placing it in holddown R3 accepts the route immediately:

R3#
Mar 1 00:36:44.639: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 00:36:44.639: 4.4.4.0/24 via 0.0.0.0 in 1 hops
Mar 1 00:36:44.643: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 00:36:44.643: 10.0.24.0/24 via 0.0.0.0 in 1 hops

R4(config-router)#access 1 p 4.4.4.0
R4(config)#router rip
R4(config-router)#offset-list 1 out 1 f0/0

R3#
Mar 1 00:37:11.047: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 00:37:11.047: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 00:37:11.047: RT: rip's 4.4.4.0/24 (via 10.0.34.4) metric changed from distance/metric [120/1] to [120/2]
Mar 1 00:37:11.051: RT: NET-RED 4.4.4.0/24
Mar 1 00:37:11.051: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 00:37:11.055: 10.0.24.0/24 via 0.0.0.0 in 1 hops
R3#
Mar 1 00:37:13.051: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:37:13.051: RIP: build flash update entries - suppressing null update
Mar 1 00:37:13.051: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.13.3)
Mar 1 00:37:13.055: RIP: build flash update entries
Mar 1 00:37:13.055: 4.4.4.0/24 via 0.0.0.0, metric 3, tag 0

R3#sh ip rou | b Gate
Gateway of last resort is not set

4.0.0.0/24 is subnetted, 1 subnets
R 4.4.4.0 [120/2] via 10.0.34.4, 00:00:02, FastEthernet0/0
10.0.0.0/24 is subnetted, 4 subnets
R 10.0.12.0 [120/1] via 10.0.13.1, 00:00:07, Serial0/0
C 10.0.13.0 is directly connected, Serial0/0
R 10.0.24.0 [120/1] via 10.0.34.4, 00:00:02, FastEthernet0/0
C 10.0.34.0 is directly connected, FastEthernet0/0

From 12.4 Command Reference:
Cisco IOS IP Routing Protocols Command Reference - RIP Commands [Support] - Cisco Systems

"A route enters into a holddown state when an update packet is received that indicates the route is unreachable. The route is marked inaccessible and advertised as unreachable. However, the route is still used for forwarding packets. When holddown expires, routes advertised by other sources are accepted and the route is no longer inaccessible."

This sounds to me like if an update is received advertising an infinite metric, the router should not accept updates from any source until the holddown expires. If I shut down R4's loopback and then bring it back up a few seconds later, R3 removes the route at the first flash update and then accepts the second flash update immediately and adds the route back again. Also the route does not stay in the route table or get used for routing after receiving an unreachable metric, it only stays in the RIP database:

R4(config-router)#int l0
R4(config-if)#sh
R4(config-if)#
Mar 1 00:55:27.095: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
Mar 1 00:55:28.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R4(config-if)#
R4(config-if)#no sh

R3#
Mar 1 00:55:27.655: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 00:55:27.655: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 00:55:27.659: RT: del 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 00:55:27.659: RT: delete subnet route to 4.4.4.0/24
Mar 1 00:55:27.659: RT: NET-RED 4.4.4.0/24
Mar 1 00:55:27.663: RT: delete network route to 4.0.0.0
Mar 1 00:55:27.663: RT: NET-RED 4.0.0.0/8
R3#
Mar 1 00:55:29.663: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 00:55:29.663: RIP: build flash update entries
Mar 1 00:55:29.663: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 00:55:29.667: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.13.3)
Mar 1 00:55:29.667: RIP: build flash update entries
Mar 1 00:55:29.667: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
R3#
Mar 1 00:55:31.627: RIP: received v2 update from 10.0.13.1 on Serial0/0
Mar 1 00:55:31.631: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
R3#
Mar 1 00:55:35.183: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 00:55:35.183: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 00:55:35.187: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.34.4

Mar 1 00:55:35.187: RT: add 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 00:55:35.187: RT: NET-RED 4.4.4.0/24

R3#sh ip rou | b Ga
Gateway of last resort is not set

4.0.0.0/24 is subnetted, 1 subnets
R 4.4.4.0 [120/2] via 10.0.34.4, 00:00:01, FastEthernet0/0
10.0.0.0/24 is subnetted, 4 subnets
R 10.0.12.0 [120/1] via 10.0.13.1, 00:00:17, Serial0/0
C 10.0.13.0 is directly connected, Serial0/0
R 10.0.24.0 [120/1] via 10.0.34.4, 00:00:01, FastEthernet0/0
C 10.0.34.0 is directly connected, FastEthernet0/0

From Cisco Press ICND 2:
"After hearing a poisoned route, start a holddown timer for that one route. Until the timer expires, do not believe any other routing information about the failed route, because believing that information may cause a routing loop. However, information learned from the neighbor that originally advertised the working route can be believed before the holddown timer expires."

This sounds the same as the command reference, except that information from the original best source is accepted during the holddown. Because of the offset outbound from R4 to R3 for 4.4.4.0, R1's best route is through R2. I shut down R4 F0/0 so that R3 can't receive it's updates and then shut down the loopback again. R1 receives an unreachable advertisement for 4.4.4.0 from R2 and removes it. At R3's next periodic R1 again accepts the route immediately even though it did not come from the same source that advertised it as unreachable:

R4(config-if)#int f0/0
R4(config-if)#sh
R4(config-if)#int l0
R4(config-if)#sh

R1(config)#
Mar 1 01:07:47.531: RIP: received v2 update from 10.0.12.2 on Serial0/0
Mar 1 01:07:47.531: 4.4.4.0/24 via 0.0.0.0 in 16 hops (inaccessible)
Mar 1 01:07:47.535: RT: del 4.4.4.0/24 via 10.0.12.2, rip metric [120/2]
Mar 1 01:07:47.535: RT: delete subnet route to 4.4.4.0/24
Mar 1 01:07:47.535: RT: NET-RED 4.4.4.0/24
Mar 1 01:07:47.539: RT: delete network route to 4.0.0.0
Mar 1 01:07:47.539: RT: NET-RED 4.0.0.0/8
R1(config)#
Mar 1 01:07:49.539: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 01:07:49.539: RIP: build flash update entries
Mar 1 01:07:49.539: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:07:49.543: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.13.1)
Mar 1 01:07:49.543: RIP: build flash update entries
Mar 1 01:07:49.543: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
R1(config)#
Mar 1 01:07:53.587: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 01:07:53.587: RIP: build update entries
Mar 1 01:07:53.587: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:07:53.591: 10.0.13.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 01:07:53.591: 10.0.34.0/24 via 0.0.0.0, metric 2, tag 0
R1(config)#
Mar 1 01:07:56.451: RIP: received v2 update from 10.0.13.3 on Serial0/1
Mar 1 01:07:56.451: 4.4.4.0/24 via 0.0.0.0 in 3 hops
Mar 1 01:07:56.455: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.13.3

Mar 1 01:07:56.455: RT: add 4.4.4.0/24 via 10.0.13.3, rip metric [120/3]
Mar 1 01:07:56.455: RT: NET-RED 4.4.4.0/24
Mar 1 01:07:56.459: 10.0.24.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:07:56.459: 10.0.34.0/24 via 0.0.0.0 in 1 hops
R1(config)#
Mar 1 01:07:57.459: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (10.0.13.1)
Mar 1 01:07:57.459: RIP: build update entries
Mar 1 01:07:57.459: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 01:07:57.463: 10.0.24.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 01:07:58.459: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.12.1)
Mar 1 01:07:58.459: RIP: build flash update entries
Mar 1 01:07:58.459: 4.4.4.0/24 via 0.0.0.0, metric 4, tag 0
Mar 1 01:07:58.463: RIP: sending v2 flash update to 224.0.0.9 via Serial0/1 (10.0.13.1)
Mar 1 01:07:58.463: RIP: build flash update entries - suppressing null update

R1(config)#do sh ip rou | b Ga
Gateway of last resort is not set

4.0.0.0/24 is subnetted, 1 subnets
R 4.4.4.0 [120/3] via 10.0.13.3, 00:00:14, Serial0/1
10.0.0.0/24 is subnetted, 4 subnets
C 10.0.12.0 is directly connected, Serial0/0
C 10.0.13.0 is directly connected, Serial0/1
R 10.0.24.0 [120/1] via 10.0.12.2, 00:00:25, Serial0/0
R 10.0.34.0 [120/1] via 10.0.13.3, 00:00:14, Serial0/1

The only way that I have seen holddown occur is if the invalid expires. In that case, the route is kept for the lesser of holddown or (flush - invalid). With all interfaces up again, if I shutdown R4 F0/0 and then shutdown R4 loopback, R3 waits till the invalid expires then puts the route in holddown and does not accept updates from either R1 or R4 until the flush timer expires even if it comes back up:

R3#
Mar 1 01:17:50.231: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 01:17:50.231: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:17:50.231: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:17:50.235: 10.0.24.0/24 via 0.0.0.0 in 1 hops

R4(config-if)#int f0/0
R4(config-if)#sh
R4(config-if)#int l0
R4(config-if)#sh

<after invalid expires>

R3#
Mar 1 01:20:50.811: RT: delete route to 4.4.4.0 via 10.0.34.4, rip metric [120/2]
Mar 1 01:20:50.811: RT: SET_LAST_RDB for 4.4.4.0/24
OLD rdb: via 11.13.11.13

Mar 1 01:20:50.815: RT: no routes to 4.4.4.0, entering holddown
Mar 1 01:20:50.815: RT: NET-RED 4.4.4.0/24
Mar 1 01:20:50.815: RT: delete route to 10.0.24.0 via 10.0.34.4, rip metric [120/1]
Mar 1 01:20:50.819: RT: SET_LAST_RDB for 10.0.24.0/24
OLD rdb: via 11.13.11.13

Mar 1 01:20:50.819: RT: no routes to 10.0.24.0, entering holddown
Mar 1 01:20:50.819: RT: NET-RED 10.0.24.0/24
R3#
Mar 1 01:20:52.815: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 01:20:52.815: RIP: build flash update entries
Mar 1 01:20:52.815: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:20:52.819: 10.0.24.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:20:52.819: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.0.13.3)
Mar 1 01:20:52.819: RIP: build flash update entries
Mar 1 01:20:52.819: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:20:52.823: 10.0.24.0/24 via 0.0.0.0, metric 16, tag 0

R4(config-if)#int lo0
R4(config-if)#no sh
R4(config-if)#int f0/0
R4(config-if)#no sh

R3#
Mar 1 01:21:29.123: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 01:21:29.123: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:21:29.127: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:21:29.127: 10.0.24.0/24 via 0.0.0.0 in 1 hops
R3#
Mar 1 01:21:33.059: RIP: received v2 update from 10.0.13.1 on Serial0/0
Mar 1 01:21:33.059: 4.4.4.0/24 via 0.0.0.0 in 3 hops
Mar 1 01:21:33.063: 10.0.12.0/24 via 0.0.0.0 in 1 hops
Mar 1 01:21:33.063: 10.0.24.0/24 via 0.0.0.0 in 2 hops
R3#
Mar 1 01:21:38.099: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.34.3)
Mar 1 01:21:38.099: RIP: build update entries
Mar 1 01:21:38.099: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:21:38.103: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
Mar 1 01:21:38.103: 10.0.13.0/24 via 0.0.0.0, metric 1, tag 0
Mar 1 01:21:38.103: 10.0.24.0/24 via 0.0.0.0, metric 16, tag 0
R3#
Mar 1 01:21:44.047: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (10.0.13.3)
Mar 1 01:21:44.047: RIP: build update entries
Mar 1 01:21:44.047: 4.4.4.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:21:44.051: 10.0.24.0/24 via 0.0.0.0, metric 16, tag 0
Mar 1 01:21:44.051: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
R3#
Mar 1 01:21:50.823: RT: delete subnet route to 4.4.4.0/24
Mar 1 01:21:50.823: RT: NET-RED 4.4.4.0/24
Mar 1 01:21:50.827: RT: delete network route to 4.0.0.0
Mar 1 01:21:50.827: RT: NET-RED 4.0.0.0/8
Mar 1 01:21:50.827: RT: delete subnet route to 10.0.24.0/24
Mar 1 01:21:50.831: RT: NET-RED 10.0.24.0/24
R3#
Mar 1 01:21:54.611: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
Mar 1 01:21:54.611: 4.4.4.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:21:54.615: RT: SET_LAST_RDB for 4.4.4.0/24
NEW rdb: via 10.0.34.4

Mar 1 01:21:54.615: RT: add 4.4.4.0/24 via 10.0.34.4, rip metric [120/2]
Mar 1 01:21:54.619: RT: NET-RED 4.4.4.0/24
Mar 1 01:21:54.619: 10.0.12.0/24 via 0.0.0.0 in 2 hops
Mar 1 01:21:54.619: 10.0.24.0/24 via 0.0.0.0 in 1 hops
Mar 1 01:21:54.623: RT: SET_LAST_RDB for 10.0.24.0/24
NEW rdb: via 10.0.34.4

Mar 1 01:21:54.623: RT: add 10.0.24.0/24 via 10.0.34.4, rip metric [120/1]
Mar 1 01:21:54.623: RT: NET-RED 10.0.24.0/24

If I'm understanding each of these sources correctly, it seems to work much differently than what they say so I just wanted to know if anyone can confirm that this is the way that it works/should work?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

kpjungle

BennyLava wrote: »

I want to make sure that I'm understanding the RIP holddown timer correctly as some of the sourced I've used for it say different things, and none of them seem to describe the way that it actually works if I'm understanding it correctly. Here are a few scenarios and what a few of the sources I've used say about it.

If I'm understanding each of these sources correctly, it seems to work much differently than what they say so I just wanted to know if anyone can confirm that this is the way that it works/should work?

I see what you are saying, and im not seeing the expected results either.
I have R1 <-> R2 <-> R3, Both R1 and R3 have a loopback of 4.4.4.0, but only one of them advertises it (R3), R1 is set up with an offset of 4, making it a less attractive route.

If R2 receives the route unaccessible from R3, it sends a poison reverse back to R3, and sends out a flash to R1 as well. It also contradictory to texts, flush the route from the routing table. If R1 then starts advertising 4.4.4.0 with a worse metric, it installs it immediately.

So far I cant recreate the behavior I expect.

If you can somehow reproduce the results im very interested in knowing about it.

BennyLava

kpjungle wrote: »

So far I cant recreate the behavior I expect.

If you can somehow reproduce the results im very interested in knowing about it.

Which behavior are you trying to recreate? If you are trying to see the holddown timer occur, the only time I've found that it is used is after the invalid expires. This can be done by shutting down the interface of the opposite router or filtering the route from updates.

kpjungle

BennyLava wrote: »

Which behavior are you trying to recreate? If you are trying to see the holddown timer occur, the only time I've found that it is used is after the invalid expires. This can be done by shutting down the interface of the opposite router or filtering the route from updates.

Yeah I can see that too. What I would like to demonstrate is the behavior stated in several documentation, namely that after receiving a notification of an unreachable route (metric = 16), the route will do poison reverse, and then put the holddown timer into effect. While this timer is in effect, no new updates regarding this route is accepted. I cant recreate this.

Edit:
Okay, ive read alot of stuff now. And even though its stated that when a route is received with an unreachable metric, the route should go into holddown. There's no way I can get it to do this. The router sends out the inaccessible metric for the route, the neighbor receives it, sends out poison reverse, and deletes it from its routing table. Done.

Its annoying when the theory doesnt match reality.

BennyLava

kpjungle wrote: »

Its annoying when the theory doesnt match reality.

Yeah I know what you mean, I try not to believe anything I read anymore until I can test it myself and see that it works that way. It makes it hard to know what to do on an exam though, especially one based more on the implementation than the theory like the CCIE lab, do you configure something based on how Cisco says it works or based on how you've seen it work?

Also to add to what you said about routers that receive an unreachable metric for a route, they seem to keep the route in the RIP database after deleting it from the route table for (flush - invalid), which seems kind of strange since their invalid didn't expire to begin with. If flush is less than or equal to invalid they keep it just long enough to send out 1 flash update and then delete it.

Mrock4

BennyLava wrote: »

do you configure something based on how Cisco says it works or based on how you've seen it work?

No matter how many times cisco says it *should* work, reachability is reachability! If it works, it works, IMO.

kpjungle

BennyLava wrote: »

Yeah I know what you mean, I try not to believe anything I read anymore until I can test it myself and see that it works that way. It makes it hard to know what to do on an exam though, especially one based more on the implementation than the theory like the CCIE lab, do you configure something based on how Cisco says it works or based on how you've seen it work?

Also to add to what you said about routers that receive an unreachable metric for a route, they seem to keep the route in the RIP database after deleting it from the route table for (flush - invalid), which seems kind of strange since their invalid didn't expire to begin with. If flush is less than or equal to invalid they keep it just long enough to send out 1 flash update and then delete it.

Well, it depends. I am pretty sure that in the written, (even though RIP is not on the blueprint anymore), you need to know the official meaning of stuff, even though in reality it does something completely different. In my study notes, i write down what i have read and think will be good to know/review, and then also note down how it behaved in the lab. That way I always know what to expect on the routers, but also the theory behind it.

But no matter what, i still stand behind the obvious, that when theory doesnt match actual behavior, the learning of the technology gets kind of screwed up.