I tested that out as well and can't get it accept better metrics during holddown. I tested with both regular and triggered updates, I'll have to read up on it to see if there is a caveat or not.
Cheers, Donald Robb Productive Networks / Network Consultant ______________________________________________________________ CCIE Written, CCIP, CCSP, CCDP, CCNP, CCNA: Voice, JNCIP, SCP, MCSA 2003, Security+, CCSE.R65, PACE Experts-Exchange: Guru - R&S -----Original Message----- From: Kim Pedersen [mailto:[email protected]] Sent: January-22-12 2:49 AM To: CCIE KID Cc: Donald Robb; [email protected]; [email protected] Subject: Re: [OSL | CCIE_RS] Correct Understanding the RIP timers! Hi, In my testing, when a route is in hold-down, you can't even get the router to accept the same route from anywhere else even though it has a _better_ metric. Fx.: R1 <-> R2 <-> R3 100.100.100.100/32 is advertised from R1 to R2 with a metric of 4. I stand by on R3 to insert the 100.100.100.100/32 with a standard metric of 1 I then apply a distribute list on R1 toward R2, causing the route to go into hold-down after a while. After the hold-down occurs, i insert the 100.100.100.100/32 network on R3, and view the rip debug on R2. It will _not_ insert this route even though it has a better metric. After it goes out of hold-down, it will insert this route. Sincerely, Kim Pedersen On Jan 22, 2012, at 10:23 AM, CCIE KID wrote: > The Invalid / Holdown starts at 180 seconds .. I have a doubt in it, > > THere is a route learned from RIP and u haven't got any updates for 60 > seconds , then the route goes into Invalid state for 180 ( so ie from > the > 60 seconds so Invalid TImer is actually 120 seconds ) and it doesnt > update for that 180 seconds if it gets any metric with a worse > metric.. And it waits for another 60 seconds to flush it. > > Am i getting it right this time :) > > > > > > On Sun, Jan 22, 2012 at 2:31 PM, Donald Robb <[email protected]> wrote: > >> It's not actually a 180 second period, the entire flush process will >> take >> 240 seconds.**** >> >> The invalid/holddown portion begins at 180 seconds and ends when the >> route is flushed at 240 seconds or if it is taken out of hold >> down.**** >> >> ** ** >> >> During the invalid/holddown 60 second period (by default) before the >> route is flushed the router won't believe any updates for the route >> unless it is a better metric.**** >> >> ** ** >> >> Cheers,**** >> >> Donald Robb**** >> >> Productive Networks / Network Consultant**** >> >> ______________________________________________________________**** >> >> CCIE Written, CCIP, CCSP, CCDP, CCNP, CCNA: Voice, JNCIP, SCP, MCSA >> 2003, >> Security+, CCSE.R65, PACE**** >> >> Experts-Exchange: Guru - R&S**** >> >> ** ** >> >> *From:* CCIE KID [mailto:[email protected]] >> *Sent:* January-22-12 1:35 AM >> *To:* Donald Robb >> *Cc:* Matthew P. Smith; [email protected]; >> [email protected] >> >> *Subject:* Re: [OSL | CCIE_RS] Correct Understanding the RIP >> timers!**** >> >> ** ** >> >> Donald, >> >> I got ur point man. So RIP wont accept any routes which are the >> worser metric than anyone..in the 180 sec period ... After 180 >> seconds if it again gets the worse update, it would update it. >> >> In that 180 second, all the stale information woul get flushed out in >> that time. so after that 180 sec it wont get that particular update >> and correct information will be passed. >> >> **** >> >> On Sun, Jan 22, 2012 at 1:39 PM, Donald Robb <[email protected]> >> wrote:**** >> >> The holddown timer is more or less a sanity check to the invalid >> timer, it guards against the router learning the same route from >> another update that has same or worse metric so the features complement each other. >> If you think about it that way, it make sense that would run at the >> same time as the invalid period. >> >> Hope that helps clear things up**** >> >> >> Cheers, >> Donald Robb >> Productive Networks / Network Consultant >> ______________________________________________________________ >> CCIE Written, CCIP, CCSP, CCDP, CCNP, CCNA: Voice, JNCIP, SCP, MCSA >> 2003, >> Security+, CCSE.R65, PACE >> Experts-Exchange: Guru - R&S >> >> -----Original Message----- >> From: [email protected]**** >> >> [mailto:[email protected]] On Behalf Of CCIE KID >> Sent: January-22-12 12:51 AM >> To: Matthew P. Smith >> Cc: [email protected]; [email protected] >> Subject: Re: [OSL | CCIE_RS] Correct Understanding the RIP timers! >> >> Hi >> >> >> Both the Holdown and Invalid run parallely. As far as i understood >> the logic. >> >> In Invalid Time period, if there is any other update for the same >> route is updated ( The metric can be worse or same ) can be updated >> >> But in Hold Time period, If there is any other worse update or the >> same metric update reaches, it would discard it, >> >> So my question is how can these two timers can run parallely, How can >> thsi solves the purpose >> >> Because both the timers have contrasting software feature, Because >> the trigger is different, >> >> In Invalid the trigger is to update even the worst metric, But in >> Hold Time the trigger is not to update the worst metric, >> >> How this can be parallel. Is there any demarcation point for this.. >> >> I may be wrong. >> Can any expert correct me. >> >> On Sun, Jan 22, 2012 at 3:02 AM, Matthew P. Smith >> <[email protected]>wrote: >> >>> Though debugs are good, you can test this just by shutting down the >>> interface while watching the clock. >>> >>> When I did this, the route got pulled from the routing table 3 >>> minutes after the last hello(invalid timer). >>> >>> The route got pulled from the rip database after another 60 >>> seconds(flush timer). Keep in mind that according to Cisco, the >>> flush timer is 4 minutes, not 60 seconds) >>> >>> The hold down timer lasts for 3 minutes and begins after the route >>> goes invalid. If an advertisement for the invalid route is heard >>> before the hold down timer expires, it will be ignored under certain >> circumstances. >>> >>> BUT I'm not 100% sure if this works. Will an update identified by >>> the hold down timer update the flush timer? Or what if the update >>> comes in through a different interface or from a different router >>> ID. Would the advertisement still be subject to the flush and/or hold down timers? >>> >>> I guess I need to lab this out again. >>> But this time from different router IDs and incoming interfaces. >>> And before and after the flush timer expires. >>> Only 4 more tests to put this to bed :) >>> >>> On Jan 20, 2012, at 5:58 PM, Bob McCouch <[email protected]> wrote: >>> >>>> The output from my lab below was from 'debug ip rip database' and >>>> 'debug ip routing'. >>>> >>>> Bob >>>> -- >>>> Sent from my iPhone, please excuse any typos. >>>> >>>> On Jan 20, 2012, at 1:15 PM, "[email protected]" >>>> <[email protected]> wrote: >>>> >>>>> Hello >>>>> >>>>> What is the output of debup ip rip ? >>>>> -----Original Message----- >>>>> From: Rostam Sohrab <[email protected]> >>>>> Sender: [email protected] >>>>> Date: Fri, 20 Jan 2012 09:31:35 >>>>> To: Bob McCouch<[email protected]> >>>>> Cc: [email protected]<[email protected]> >>>>> Subject: Re: [OSL | CCIE_RS] Correct Understanding the RIP timers! >>>>> >>>>> Thanks to Bob & Donald! >>>>> >>>>> Those were certainly superb explanations making the understanding >>> pretty clear for me! >>>>> >>>>> -RS >>>>> >>>>> >>>>> ________________________________ >>>>> From: Bob McCouch <[email protected]> >>>>> To: Rostam Sohrab <[email protected]> >>>>> Cc: "[email protected]" <[email protected]> >>>>> Sent: Friday, 20 January 2012 8:51 AM >>>>> Subject: Re: [OSL | CCIE_RS] Correct Understanding the RIP timers! >>>>> >>>>> >>>>> Best way to see this is to lab it up. I set up a very simple >>>>> network >>> with R1 and R2 connected via ethernet. I advertised a loopback from >>> R2 into RIP, and then on R2 set the ethernet interface passive to >>> stop routing updates without giving IOS any hints by dropping the >>> interface. Here's what >>> happened: >>>>> >>>>> R1#sh ip ro | b Gate >>>>> Gateway of last resort is not set >>>>> >>>>> 10.0.0.0/24 is subnetted, 2 subnets >>>>> R 10.1.0.0 [120/1] via 10.1.124.2, 00:00:12, FastEthernet0/0 >>>>> C 10.1.124.0 is directly connected, FastEthernet0/0 >>>>> >>>>> R1#sh clock >>>>> 22:03:17.475 UTC Wed Jan 19 2011 >>>>> R1#!This is when I set Fa0/0 passive on R2 >>>>> >>>>> R1# >>>>> Jan 19 22:05:56.975: RIP-DB: invalidated route of 10.1.0.0/24 via >>> 10.1.124.2 >>>>> Jan 19 22:05:56.979: RT: delete route to 10.1.0.0 via 10.1.124.2, >>>>> rip >>> metric [120/1] >>>>> Jan 19 22:05:56.979: RT: no routes to 10.1.0.0, entering holddown >>>>> Jan 19 22:05:56.987: RIP-DB: Remove 10.1.0.0/24, (metric >>>>> 4294967295) >>> via 10.1.124.2, FastEthernet0/0 >>>>> >>>>> R1#sh ip ro | b Gate >>>>> Gateway of last resort is not set >>>>> >>>>> 10.0.0.0/24 is subnetted, 2 subnets >>>>> R 10.1.0.0/24 is possibly down, >>>>> routing via 10.1.124.2, FastEthernet0/0 >>>>> C 10.1.124.0 is directly connected, FastEthernet0/0 >>>>> >>>>> R1# >>>>> Jan 19 22:06:56.991: RIP-DB: garbage collect 10.1.0.0/24 Jan 19 >>>>> 22:06:56.995: RT: delete subnet route to 10.1.0.0/24 >>>>> >>>>> R1#sh ip ro | b Gate >>>>> Gateway of last resort is not set >>>>> >>>>> 10.0.0.0/24 is subnetted, 1 subnets >>>>> C 10.1.124.0 is directly connected, FastEthernet0/0 >>>>> >>>>> >>>>> So 3 minutes after the last received update, the route was marked >>> invalid, and 60 seconds after that the route was flushed. So all >>> timers are running concurrently, the update timer, the >>> invalid/holddown timers, and the flush timer. >>>>> >>>>> >>>>> Bob >>>>> >>>>> >>>>> On Thu, Jan 19, 2012 at 6:56 AM, Rostam Sohrab >>>>> <[email protected]> >>> wrote: >>>>> >>>>> >>>>>> >>>>>> I have a little confusion in the understanding of RIP timers. >>>>>> >>>>>> First the basics... >>>>>> >>>>>> update timer is 30 secs --> Invalid timers should be 3 times of >>>>>> update >>> i.e 90secs but the default is 180secs --> Holddown timers should be >>> 3 times of update i.e, 90secs but the default is 180secs --> Flush >>> timer, default is 240 secs. >>>>>> >>>>>> Now there are three parts to my question... >>>>>> >>>>>> The first question might sound silly but for the sake of a clear >>> understanding I'll write it. >>>>>> >>>>>> >>>>>> 1. Does the RIP updates timers work is series? i.e after one >>>>>> elapses >>> the other starts? >>>>>> >>>>>> ex: once U-30sec is over --> Invalid starts and runs for 180 secs >>>>>> --> >>> Holddown starts and runs for another 180secs --> And finally flush >>> timer starts and runs for 240secs. >>>>>> >>>>>> Here the total time would be 30+180+180+240=630secs until a route >>>>>> is >>> flushed out which is looking quite unreasonable! >>>>>> >>>>>> 2. Does the Invalid, Holddown & flush timers work is parallel? >>>>>> >>>>>> ex: once U-30sec is over -> Invalid, Holddown runs for 180secs >>>>>> along >>> with the flushtimer which runs for 240secs? >>>>>> >>>>>> Here the total time would be 30+240=270secs until a route is >>>>>> flushed >>> out which looks very much acceptable. >>>>>> >>>>>> >>>>>> 3. And why does the Invalid & Holddown timers run in parallel, if >>>>>> all >>> they do? >>>>>> >>>>>> Because at the end of these two timers (IT & HDT) it would take >>> another 60secs for flush timer to flush out the route, which means >>> that all the timers IT/HDT/FT are kicking off at the same time >>> immediately after update timer expires! >>>>>> >>>>>> I think I'm just complicating what is supposed to be a simple >>> understanding!!! >>>>>> >>>>>> -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 >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> With Warmest Regards, >> >> CCIE KID >> CCIE#29992 (Security) >> _______________________________________________ >> 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**** >> >> >> >> >> -- >> With Warmest Regards, >> >> CCIE KID >> CCIE#29992 (Security) >> >> **** >> > > > > -- > With Warmest Regards, > > CCIE KID > CCIE#29992 (Security) > _______________________________________________ > 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 // Freedom Matters CCIE #29189 http://www.packet-forwarding.net _______________________________________________ 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
