I see the same. I just did this with the following: R1---R3---R2 (happened to match an existing .net file better for me).
I originated 8.8.8.8/32 into RIP from R1 with an outbound offset so I could make the same route from R2 show up both better and worse than R1's version of the route. I swapped offset lists on R2 to change the option it was offering to R3, and used an outbound distribute list on R1 to block the route from that side to simulate failure. I also altered R1's offset list for a few tests to make the route get advertised from the original source with same, better, and worse metrics. Update period is 30 seconds. Invalid timer is 180 seconds. Flush timer is 240 seconds. The router indicates it's entering hold down after the invalid timer has expired and claims it's 180 seconds of hold down. Here's what I'm observing: Will accept worse metric from alternate source during update interval: No (obvious) Will accept better metric from alternate source during update interval: Yes (obvious) Will accept worse metric from alternate source during invalid interval (between 30-180 sec): No (obvious) Will accept better metric from alternate source during invalid interval (between 30-180 sec): Yes (obvious) Will accept worse metric from alternate source during holddown (btwn 180-240 sec): No Will accept better metric from alternate source during holddown (btwn 180-240 sec): No Will accept worse metric from original source during holddown (btwn 180-240 sec): No Will accept better metric from original source during holddown (btwn 180-240 sec): No Will accept any metric from any source after flush at approx 240 sec: YES Once the invalid timer expires, the router starts sending out poisoned updates to all neighbors. From that point unit the flush timer fires (60 seconds later), the router will effectively accept no updates on that route. That includes better or worse metrics, either from alternate sources or from the router the "lost" route originally came from. After the flush occurs and the route is completely removed from the route table, the next update that comes in for that route is accepted. So practically speaking, the holddown time seems to be 60 seconds, not 180. I also tried setting the offset from R1 to 15 so the route arrived at R3 as inaccessible (simulating a failure further upstream and the adjacent router hitting the invalid expiration), and R3 immediately flushed the route from the table upon hearing of the inaccessible route, and then accepted the next route advertisement from the alternate path. So it seems to me that the hold down interval is really just a short moratorium on accepting any updates to a route from the period after it's been declared invalid until the garbage collection comes around and flushes the route. From a standpoint of loop prevention (with respect to counting to infinity) I can see that it gives a little window for everyone in the network to agree the route is gone and flush it, and whatever path is still being advertised at the end of that must really be an alternate route, but I just don't see where the 180 second claim comes from. Does anyone have an example case where the route *remains* in hold down for more than 60 seconds after the invalid timer has expired? On Sun, Jan 22, 2012 at 4:49 AM, Kim Pedersen <[email protected]> wrote: > 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 > _______________________________________________ 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
