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/8 on
> 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/8 prefix.
> 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
Blogs and organic groups at http://www.ccie.net