Re: RIP Timers

Simplify, here is quate from a nice book i recommend

*CCIE Professional Development Routing TCP/IP, Volume I, Second Edition
By Jeff Doyle - CCIE No. 1919, Jennifer Carroll - CCIE No. 1402*

"The third timer is the holddown timer, although RFC 1058 does not call for
the use of holddowns. The Cisco implementation of RIP does use them. An
update with a hop count higher than the metric recorded in the route table
will cause the route to go into holddown for 180 seconds (again, six update
periods)."

On Mon, Mar 22, 2010 at 9:46 AM, Cristian Matei <cristian.matei_at_datanets.ro>
wrote:
> Hi Shiran,
>
> If you read my *book* you'll understand. Holddown timer NEVER kicks
> in just when the metric for a prefix increases; maximum hop count of 15 is
> the protection for it.
>
> Regards,
> Cristian.
>
> -----Original Message-----
> From: shiran guez [mailto:shiranp3_at_gmail.com]
> Sent: Monday, March 22, 2010 9:34 AM
> To: cristian.matei_at_datanets.ro
> Cc: Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> tosara_at_gmail.com
> Subject: Re: RIP Timers
>
> Hi Cristian
>
> Sorry I do not have the time to read your book bellow, but I think you
> missed my point the basic rule is that when an update shows the metric
> for an existing route to have increased sufficiently, there is a loop.
> The route should be removed and put into holddown.
>
> Dont think there is a real need to get into the full story, and you
> are correct as I said what is happening in Sarad scenario perfectly
> normal.
>
>
> On Sun, Mar 21, 2010 at 9:39 PM, Cristian Matei
> <cristian.matei_at_datanets.ro> wrote:
>> Hi Shiran,
>>
>> HOLDDOWN timer is NOT when you suddenly get a higher metric for an
>> already installed route. See below my initial post on this thread. To
>> quickly answer the question still, the problem you're seeing here is a
>> normal behavior: basically RIP is NOT using holddown timer to converge in
>> the case of direct "neighbor" failures. Read my post below, and if things
>> are still unclear let me know where exactly.
>>
>> ####################################################
>> Hi Sarad,
>>
>>
>> First of all you're confusing the invalid timer with the hold down timer.
>> Secondly , I believe we're speaking about RIPv1/v2 for IPv4 as RIPnG for
>> IPv6 behaves a little bit differently. Now, each routing protocol needs
to
>> know how to converge in any of the 2 failure cases:
>>
>>
>> 1. direct failures, meaning a prefix advertised inside the
>> routing domain is down; here the router owning the prefix will start
>> advertising this(depends on the routing protocol what exactly and how
it's
>> advertised) and all routers inside the routing domain need to converge
> asap.
>> 2. indirect failures, meaning a interconnect link between
>> routers inside the routing domain is down (routing protocol runs over
that
>> interconnect), thus invalidating some prefixes; here each router needs a
> way
>> to determine that a "neighbor"/routing protocol speaker is not reachable
> any
>> longer, thus making some prefixes no longer reachable.
>>
>>
>> RIP makes no difference and needs ways to converge in both cases.
>>
>> For the first case, the convergence is based on a combination of flash
>> routing updates (known incorrectly as triggered updates) and
> split-horizon,
>> poison-reverse with split-horizon rules. Basically in this case the
>> convergence is almost instant. So to detail a bit, in RIP when a prefix
is
>> down, the owner will advertise it as unreachable with metric 16; all the
> RIP
>> speakers receiving this will instantly remove the prefix from RT, send
> flash
>> updates on all RIP enabled interfaces for that prefix with a metric of
16;
>> the prefix is no longer used for packet forwarding (as is no longer
> present
>> in the RT); RIP speakers (except the router that owned the prefix) will
>> still keep the prefix in their databases and the prefix will be included
> in
>> the following regular updates (at each 30 second by default) for the
>> FLUSH-INVALID amount of seconds (by default for 240-180=60 seconds which
>> means 2 regular updates). Since the hold down timer is not used, any
>> following update for that prefix, with any metric (lower or higher than
> the
>> initial one) is accepted by the RIP speakers. So here no timers are
needed
>> for RIP speakers to remove the unreachable prefix from RT; invalid and
> flush
>> timers are important for how long the prefix is kept in the RIP database
> but
>> NOT for RT convergence.
>>
>> For the second case, the convergence is based on INVALID timer, HOLD DOWN
>> timer and FLUSH timer. When an update about a prefix is no longer
received
>> by a RIP speaker from the next-hop it has in its RT (so actually the RIP
>> speaker that advertised the prefix) for as long as the INVALID timer this
> is
>> the point where the things start to happen; so first of all a router will
>> still forward packets towards that destination, although unreachable for
> 180
>> seconds (the default INVALID timer); after the invalid timer reaches 0
>> seconds, the prefix enters in the hold-down state (this means all updates
>> about that prefix, regardless of having a lower or higher metric are
>> ignored); the router will KEEP this time the prefix in the RT but in the
>> "possibly down state" and in the RIP database as well in the same state
>> (this means the router still uses that path for packet forwarding). Also
> it
>> will start advertising the prefix as unreachable on all enabled RIP
>> interfaces by a flash update and following regular updates. The prefix
> will
>> remain in the hold down state for the minimum (HOLD DOWN timer, FLUSH
> timer
>> - INVALID timer); by default this means minimum (180,240-180)= minimum
>> (180,60) means 60 seconds. After 60 seconds the router will remove the
>> prefix from both RT and RIP database, stop advertising the prefix as
>> unreachable and stop ignoring updates about that prefix (meaning at this
>> point any updates about that prefix will be subject for the RT).
>>
>>
>> Just for fun, another RIP topic which is unclear is the split-horizon.
Lot
>> of people "know" that if RIP receives an update about prefix 10.0.0.0/8on
>> its Fa0/0 interface, the router will not send regular updates about
>> 10.0.0.0/8 out that interface; this is somehow true but not entirely; the
>> router will NOT send updates about 10.0.0.0/8 out on Fa0/0 ONLY and ONLY
> if
>> it prefers(puts in the RT) that route in order to reach 10.0.0.0/8prefix.
>> For example if you have R1 that receives updates about 10.0.0.0/8 on
Fa0/0
>> with metric of 3 and about 10.0.0.0/8 on Fa0/1 with metric of 4, it will
> put
>> in the RT the one with metric 3. This means it will send regular RIP
> updates
>> about 10.0.0.0/8 out on Fa0/1 but NOT out on Fa0/0 which is its best
path.
>>
>>
>> I hope the post was not too long, but clear enough.
>>
>>
>> ##################################################
>>
>> Regards,
>> Cristian.
>>
>>
>>
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> shiran guez
>> Sent: Sunday, March 21, 2010 8:45 PM
>> To: Erwin van Harrewijn
>> Cc: kebramccie_at_gmail.com; ccielab_at_groupstudy.com; tosara_at_gmail.com
>> Subject: Re: RIP Timers
>>
>> I think you are a little bit confused with the timers
>>
>> invalidate timer is when you didn't get a route update on a route that
>> is in your table for ~180 sec (that is the status you are in)
>> holdown timer is when suddenly you get a higher metric for an already
>> installed route (lets say you have 1.1.1.0/24 with metric of 2 and
>> suddenly you get that route with a metric of 3 then your router will
>> start to count the hold down timer)
>>
>> between the invalidate and the flash timer if you receive an update
>> for your route with a better metric your router immediately update the
>> routing table and that is exactly what happened in your scenario
>>
>> hope that sort your mind a Little
>>
>>
>> On Sun, Mar 21, 2010 at 8:30 PM, Erwin van Harrewijn <erwin_at_f1x0r.nl>
> wrote:
>>> Hi Shiran,
>>>
>>> I would have expected that the hold-down timer would have prevented
>>> the newly learned route to the 1.1.1.0/24 network to be installed in
>>> the routing table "already"
>>> Since there is only 16 seconds between the moment the route was
>>> invalidated and the newly learned route was received. The hold-down
>>> timer could not have been expired yet.
>>>
>>> So why is that route installed in the routing-table?
>>>
>>> Thanks,
>>> Erwin
>>>
>>
>>
>>
>> --
>> Shiran Guez
>> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
>> http://cciep3.blogspot.com
>> http://www.linkedin.com/in/cciep3
>> http://twitter.com/cciep3
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
>

-- 
Shiran Guez
MCSE CCNP NCE1 JNCIA-ER CCIE #20572
http://cciep3.blogspot.com
http://www.linkedin.com/in/cciep3
http://twitter.com/cciep3
Blogs and organic groups at http://www.ccie.net