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
