One thing I'd like to add is that testing anything time-related on emulated/simulated devices may not yield predictable results due to the internal clock representation in those emulators/simulators.
-- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor / Managing Partner - IPexpert On Sat, Aug 31, 2013 at 5:52 PM, <[email protected]> wrote: > At the risk of beating a dead horse, I labbed up a few different > scenarios, and I think I finally got it... I (poorly) put together a post > about about it here: > > http://bippydu.wordpress.com/2013/08/31/rip-holddown-timer/ > > Thanks guys for your help! > > Doug > > --------- Original Message --------- Subject: Re: [OSL | CCIE_RS] RIPv2 > Holddown > From: [email protected] > Date: 8/31/13 6:29 pm > To: "Chuck Ryan (chryan)" <[email protected]> > Cc: "IPexpert Online Study List" <[email protected]> > > Chuck, > > The original hop count was not 4294967295, it was 1. That's the metric > I'm talking about. If the metric of the route immediately goes to infinity > when the invalid timer ends (which it evidently does), then of course no > other route could be worse. So what good is a hold down timer that won't > allow a worse route into the routing table, if there cannot possibly be a > worse route? It also evidently doesn't let in a better route... So would it > be better to say that during the hold down period, absolutely no new > information about the route will be admitted? > > I believe I have it figured out: > > The invalid timer (180 sec) and flush timer (240 sec) are reset each time > an update arrives. > > At 180 seconds of no updates, the invalid timer ended, the metric went to > infinity, the route went into holdown, and the holdown timer (180 sec) > started. > -During this stage, ALL updates to the route are ignored (I think, need > to lab up and verify) > > At 240 seconds, (60 seconds after the invalid timer expired and the hold > down timer started), the flush timer deleted the route. > -At this point, even though the holddown timer never expired, it doesn't > matter, because the route is deleted, and the new route is allowed. > > Does this sound right? It seems silly that I am spending so much energy > trying to make sure I understand this silly piece of a protocol hardly > anybody uses anymore :) > > Doug > > > --------- Original Message --------- Subject: Re: [OSL | CCIE_RS] RIPv2 > Holddown > From: "Chuck Ryan (chryan)" <[email protected]> > Date: 8/31/13 5:15 pm > To: "[email protected]" <[email protected]> > Cc: "IPexpert Online Study List" <[email protected]> > > Doug, > > Why do you keep saying that the route learned from R5 has a worse metric? > How is 2 hops worse than 4294967295 ? R3 advertises the route with a metric > of 4294967295 because the route no longer exists on R3. R5 advertises the > route with a metric of 2, because it has a valid route to the > 10.0.3.0/24network. Right now, R5 has the best (and only) path to that > network, which > is 2 hops away (in the eyes of R4). Nothing else is available, this is why > it gets installed. > > Now when the loopback on R3 is re-enabled, then YES, R3 has the better > path and not R5. > > Chuck > > > > > From: "[email protected]" <[email protected]> > Date: Saturday, August 31, 2013 3:46 PM > To: Chuck Ryan <[email protected]> > Cc: IPexpert Online Study List <[email protected]> > Subject: RE: Re: [OSL | CCIE_RS] RIPv2 Holddown > > Chuck, > > Look at the timestamps... At 02:50:55.441, the route first went into > holdown and had the holddown timer 169 secs left on timer: > > >>>*Mar 2 02:50:55.441: RT: no routes to 10.0.3.0, entering holddown > >>>*Mar 2 02:50:55.441: RT: NET-RED 10.0.3.0/24 > >>> > >>>R4#sh ip route 10.0.3.0 > >>>Routing entry for 10.0.3.0/24 > >>> Known via "rip", distance 120, metric 4294967295 (inaccessible) > >>> Redistributing via rip > >>> Last update from 192.168.34.3 on Ethernet0/0, 00:03:13 ago > >>> Hold down timer expires in 169 secs > > At only about 60 second later, though, at 02:51:55.857, the route is > replaced, even though the holddown timer hasn't expired... > > >>>*Mar 2 02:51:45.449: RIP: Update sent via Ethernet1/0 > >>>R4#sh ip route 10.0.3.0 > >>>Routing entry for 10.0.3.0/24 > >>> Known via "rip", distance 120, metric 4294967295 (inaccessible) > >>> Redistributing via rip > >>> Last update from 192.168.34.3 on Ethernet0/0, 00:03:59 ago > >>> Hold down timer expires in 124 secs > >>> > >>>R4# > >>>*Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 > >>>*Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 > >>>*Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on > >>>Ethernet1/0 > >>>*Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 > >>> NEW rdb: via 192.168.45.5 > >>>*Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric > >>>[120/2] > >>>*Mar 2 02:51:55.857: RT: NET-RED 10.0.3.0/24 > >>>Routing entry for 10.0.3.0/24 > >>> Known via "rip", distance 120, metric 2 > >>> Redistributing via rip > >>> Last update from 192.168.45.5 on Ethernet1/0, 00:00:08 ago > >>> Routing Descriptor Blocks: > >>> * 192.168.45.5, from 192.168.45.5, 00:00:08 ago, via Ethernet1/0 > >>> Route metric is 2, traffic share count is 1 > > How can the route be deleted and a new route with a worse metric be > installed if the holddown timer isn't done? > > --------- Original Message --------- Subject: Re: [OSL | CCIE_RS] RIPv2 > Holddown > From: "Chuck Ryan (chryan)" <[email protected]> > Date: 8/31/13 2:51 pm > To: "Doug Koobs" <[email protected]> > Cc: "IPexpert Online Study List" <[email protected]> > > Doug, > > > R4 did not install the new route to 10.0.3.0/24 that it learned from R5 > until the previous route from R3 was deleted. See the debugs below. > > R4# > *Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 <=== this is > the old route from R3 that is being deleted > *Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 > *Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on > Ethernet1/0 ><=== new route received from R5 > *Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 > NEW rdb: via 192.168.45.5 > *Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric > [120/2] ><==== metric of 2 > > > Remember, when we are comparing the route learned from R3 with that > learned from R5, the R3 metric (4294967295) is the absolute worst compared > to that of R5 (2 hops). That R3 metric means the route is not reachable > via R3. Once the hold down timer expires, the route is deleted from the > routing table, and then the new prefix learned from R5 can be installed. > > Chuck > > > On 8/30/13 4:24 PM, "Doug Koobs" ><[email protected]> wrote: > > >Chuck, > > > >Lo2 on R6 was enabled while the route was still in hold down, so it > >should not have been used, right? Isn't that the purpose of hold down, to > >not allow routes with worse metrics to be installed, thus preventing > >loops? > > > >Does the hold down time apply if the route is coming in from another > >source? > > > >"Chuck Ryan (chryan)" <[email protected]> wrote: > > > >>Doug, > >> > >>R4 installed the route to 10.0.3.0/24 via R5 because this network is > not > >>reachable via R3 anymore. It is reachable via R5 in 2 hops, not 1. See > >>the > >>advertisement here: > >> > >>R4# > >>*Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 > >>*Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 > >>*Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on > >>Ethernet1/0 > >>*Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 > >> NEW rdb: via 192.168.45.5 > >>*Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric > >>[120/2] <==== metric 120, 2 hops > >> > >>This is why when both R3 and R6 (Lo2) are up, R4 installs the route > known > >>via R3 only, and not via R5. The path via R3 is reachable in 1 hop, the > >>path via R5 is reachable in 2 hops. R3 has the better path based on > lower > >>metric (fewer hops). > >> > >>The holddown timer worked exactly as expected. The extremely high metric > >>given by R3 is because the route is no longer reachable, so it doesn't > >>want you to forward traffic to that router anymore. That's by design. > The > >>route will continue to show up with the "show ip route" command until > the > >>hold down timer expires, at which time, it will be removed completely > >>from > >>the routing table. The "inaccessible" keyword tells the router that this > >>network is no longer reachable via R3, so don't send me any traffic for > >>this network. > >> > >>R4#sh ip route 10.0.3.0 > >>Routing entry for 10.0.3.0/24 > >> Known via "rip", distance 120, metric 4294967295 (inaccessible) > >> Redistributing via rip > >> Last update from 192.168.34.3 on Ethernet0/0, 00:03:59 ago > >> Hold down timer expires in 124 secs > >> > >> > >> > >>When you enabled Lo2 on R6, that's when R4 received an advertisement > from > >>R5 saying that he could reach the 10.0.3.0/24 network in 1 hop, which > is > >>much shorter than 4294967295. R4 then installs the route to 10.0.3.0/24 > >>with a hop count of 2 (R5, R6), and life is good. > >> > >> > >>Does that help? > >> > >>Chuck > >> > >> > >>On 8/29/13 5:07 AM, "[email protected]" <[email protected]> wrote: > >> > >>>I did some experimenting to make sure my understanding of the holddown > >>>timer is correct, and evidently it isn't... I thought it's purpose was > >>>to > >>>prevent a loop from forming when a route isn't updated for 180 seconds > >>>(by default) by not accepting updates about the route that have a worse > >>>metric. > >>> > >>>However, I found that when a route goes into holddown, its metric goes > >>>to > >>>4294967295, so how could there be a worse route? > >>> > >>>So I set up a small topology to test: > >>> > >>>Lo1 10.0.3.3 > >>> Lo2 10.0.3.6 > >>> > > >>>R3-------------------------R4-----------------------------R5------------ > >>>-- > >>>-------------R6 > >>> 192.168.34.0 192.268.45.0 > >>>192.168.56.0 > >>> > >>>All router are running RIPv2 in all interfaces, timers are default, > >>>autosummary disabled, but on R6, Lo2 is shut down. R4 installs a route > >>>to > >>>10.0.3.0/24 with metric 1 and next-hop of R3: > >>> > >>>R4#sh ip route > >>>... > >>>C 192.168.45.0/24 is directly connected, Ethernet1/0 > >>>R 192.168.56.0/24 [120/1] via 192.168.45.5, 00:00:02, Ethernet1/0 > >>> 10.0.0.0/24 is subnetted, 4 subnets > >>>R 10.0.3.0 [120/1] via 192.168.34.3, 00:00:00, Ethernet0/0 > >>>R 10.0.6.0 [120/2] via 192.168.45.5, 00:00:02, Ethernet1/0 > >>>C 10.0.4.0 is directly connected, Loopback1 > >>>R 10.0.5.0 [120/1] via 192.168.45.5, 00:00:02, Ethernet1/0 > >>>C 192.168.34.0/24 is directly connected, Ethernet0/0 > >>> > >>>Now, I enable "passive-interface default" on R3, and wait for the route > >>>to go into holddown on R4, which it does in 180 seconds: > >>> > >>>*Mar 2 02:50:55.437: RT: delete route to 10.0.3.0 via 192.168.34.3, rip > >>>metric [120/1] > >>>*Mar 2 02:50:55.441: RT: SET_LAST_RDB for 10.0.3.0/24 > >>> OLD rdb: via 11.13.11.13 > >>>*Mar 2 02:50:55.441: RT: no routes to 10.0.3.0, entering holddown > >>>*Mar 2 02:50:55.441: RT: NET-RED 10.0.3.0/24 > >>> > >>>R4#sh ip route 10.0.3.0 > >>>Routing entry for 10.0.3.0/24 > >>> Known via "rip", distance 120, metric 4294967295 (inaccessible) > >>> Redistributing via rip > >>> Last update from 192.168.34.3 on Ethernet0/0, 00:03:13 ago > >>> Hold down timer expires in 169 secs > >>> > >>>Now I bring up Lo2 (10.0.3.6) on R6, which advertises 10.0.3.0.24 to > R5. > >>>When R5 advertises this route to R4, it does so with a metric of 1, > >>>which > >>>is worse than the original metric that R3 was advertising.. However, R4 > >>>still installs the route, even though it is in holddown: > >>> > >>>*Mar 2 02:51:45.449: RIP: Update sent via Ethernet1/0 > >>>R4#sh ip route 10.0.3.0 > >>>Routing entry for 10.0.3.0/24 > >>> Known via "rip", distance 120, metric 4294967295 (inaccessible) > >>> Redistributing via rip > >>> Last update from 192.168.34.3 on Ethernet0/0, 00:03:59 ago > >>> Hold down timer expires in 124 secs > >>> > >>>R4# > >>>*Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 > >>>*Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 > >>>*Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on > >>>Ethernet1/0 > >>>*Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 > >>> NEW rdb: via 192.168.45.5 > >>>*Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric > >>>[120/2] > >>>*Mar 2 02:51:55.857: RT: NET-RED 10.0.3.0/24 > >>>Routing entry for 10.0.3.0/24 > >>> Known via "rip", distance 120, metric 2 > >>> Redistributing via rip > >>> Last update from 192.168.45.5 on Ethernet1/0, 00:00:08 ago > >>> Routing Descriptor Blocks: > >>> * 192.168.45.5, from 192.168.45.5, 00:00:08 ago, via Ethernet1/0 > >>> Route metric is 2, traffic share count is 1 > >>> > >>> > >>>What am I missing here? It seems the holddown didn't do anything... > >>> > >>>Doug > >>>_______________________________________________ > >>>For more information regarding industry leading CCIE Lab training, > >>>please > >>>visit www.ipexpert.com > >>> > >>>Are you a CCNP or CCIE and looking for a job? Check out > >>>www.PlatinumPlacement.com > >>> > >>>http://onlinestudylist.com/mailman/listinfo/ccie_rs > >> > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
