I labbed this up with a simple 4 router lab and used distribute-lists to
block R4's loopback 150.8.4.4/32
R2 has two connections to R4 using f1/0 and f2/0.
*note forgive the timestamps, my buffer overran so it'll look a bit out of
order.
At just before 180 seconds, the route is still normal.
R2(config-router)#do sh ip route 150.8.4.4
Routing entry for 150.8.4.4/32
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 139.8.23.3 on FastEthernet1/0, 00:02:57 ago
Routing Descriptor Blocks:
* 139.8.23.3, from 139.8.23.3, 00:02:57 ago, via FastEthernet1/0
Route metric is 2, traffic share count is 1
And is also sending the update as normal.
*Mar 1 01:20:04.515: RIP: build update entries
*Mar 1 01:20:04.515: 139.8.23.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:20:04.515: 139.8.24.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:20:04.519: 139.8.34.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:20:04.519: 150.8.2.2/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:20:04.519: 150.8.3.3/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:20:04.519: 150.8.4.4/32 via 0.0.0.0, metric 2, tag 0
After 3 minutes the route is marked as possibly down/inaccessible, and the
holddown timer starts counting down from 180 seconds
R2(config-router)#do sh ip route 150.8.4.4
Routing entry for 150.8.4.4/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 139.8.23.3 on FastEthernet1/0, 00:03:02 ago
Hold down timer expires in 177 secs
The router then starts poisoning the update with a metric of 16 to its
neighbors
*Mar 1 01:19:51.443: 150.8.4.4/32 via 0.0.0.0 in 16 hops
(inaccessible)
*Mar 1 01:19:58.487: RIP: sending v2 update to 224.0.0.9 via Loopback0
(150.8.2.2)
*Mar 1 01:19:58.487: RIP: build update entries
*Mar 1 01:19:58.487: 139.8.12.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:19:58.491: 139.8.23.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:19:58.491: 139.8.24.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:19:58.491: 139.8.34.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:19:58.491: 150.8.1.1/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:19:58.495: 150.8.3.3/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:19:58.495: 150.8.4.4/32 via 0.0.0.0, metric 16, tag 0
At around 4:00 minutes, 60 seconds later, the route is flushed from the
table and the router will accept new updates
R2(config-router)#do sh ip route 150.8.4.4
Routing entry for 150.8.4.4/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 139.8.23.3 on FastEthernet1/0, 00:04:00 ago
Hold down timer expires in 120 secs
R2(config-router)#do sh ip route 150.8.4.4
% Subnet not in table
*Mar 1 01:20:00.675: RIP-DB: garbage collect 150.8.4.4/32
*Mar 1 01:20:04.039: RIP: received v2 update from 139.8.24.4 on
FastEthernet2/0
*Mar 1 01:20:04.043: 139.8.34.0/24 via 0.0.0.0 in 1 hops
*Mar 1 01:20:04.043: RIP-DB: network_update with 139.8.34.0/24 succeeds
*Mar 1 01:20:04.043: RIP-DB: adding 139.8.34.0/24 (metric 1) via 139.8.24.4
on FastEthernet2/0 to RIP database
*Mar 1 01:20:04.043: 150.8.3.3/32 via 0.0.0.0 in 2 hops
*Mar 1 01:20:04.047: 150.8.4.4/32 via 0.0.0.0 in 1 hops
*Mar 1 01:20:04.047: RIP-DB: network_update with 150.8.4.4/32 succeeds
*Mar 1 01:20:04.047: RIP-DB: adding 150.8.4.4/32 (metric 1) via 139.8.24.4
on FastEthernet2/0 to RIP database
*Mar 1 01:20:04.051: RIP-DB: add 150.8.4.4/32 (metric 1) via 139.8.24.4 on
FastEthernet2/0
*Mar 1 01:20:04.051: RIP-DB: Adding new rndb entry 150.8.4.4/32
*Mar 1 01:20:04.515: RIP: sending v2 update to 224.0.0.9 via
FastEthernet0/0 (139.8.12.2)
*Mar 1 01:20:04.515: RIP: build update entries
*Mar 1 01:20:04.515: 139.8.23.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:20:04.515: 139.8.24.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:20:04.519: 139.8.34.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:20:04.519: 150.8.2.2/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 01:20:04.519: 150.8.3.3/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 01:20:04.519: 150.8.4.4/32 via 0.0.0.0, metric 2, tag 0
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 2:24 AM
To: Donald Robb
Cc: Matthew P. Smith; [email protected];
[email protected]
Subject: Re: [OSL | CCIE_RS] Correct Understanding the RIP timers!
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
