Re: RIP holddown timer ?

Hello,
I tried this but still the same behavior. Here is the debug output on R4.
Right after successful update from R1, I turned on passive interface serial
1/0 on R1.
175 seconds later, route 1.1.1.0 is invalidated
7 seconds later route 1.1.1.0 is added to database.

It looks like R4 did not even wait for flush timer to expire and it
installed new route as soon as update was received on F0/0.

00:40:16: RIP: received v2 update from 10.1.14.1 on Serial1/0
00:40:16: RIP-DB: network_update with 1.1.1.0/24 succeeds
00:40:16: RIP-DB: adding 1.1.1.0/24 (metric 1) via 10.1.14.1 on Serial1/0 to
RIP database

00:43:35: RIP-DB: invalidated route of 1.1.1.0/24 via 10.1.14.1
00:43:35: RIP-DB: Remove 1.1.1.0/24, (metric 4294967295) via 10.1.14.1,
Serial1/0

00:43:42: RIP: received v2 update from 10.1.34.3 on FastEthernet0/0
00:43:42: RIP-DB: network_update with 1.1.1.0/24 succeeds
00:43:42: RIP-DB: adding 1.1.1.0/24 (metric 3) via 10.1.34.3 on
FastEthernet0/0 to RIP database
00:43:42: RIP-DB: add 1.1.1.0/24 (metric 3) via 10.1.34.3 on FastEthernet0/0

On Fri, Mar 18, 2011 at 12:04 PM, Yandy Ramirez <yandyr_at_gmail.com> wrote:

> shutting down the directly connected link removes the route from the
> routing table and does not go into hold-down. Since that interface is no
> longer participating in routing cause of the down/down state. All other
> announcements will be accepted.. better test would be to advertise the route
> out R1 and then put the interface into passive-state with the
> "passive-interface" command.. and watch the timers do their thing.
>
> ------
> yandy
>
>
> On Fri, Mar 18, 2011 at 11:42, Jacek <q.192.168.1.0_at_gmail.com> wrote:
>
>> Hello Experts,
>>
>> Can someone please help me understand how RIP holddown timer works? The
>> definition in the tcp/ip vol1 1 is:
>> "If a route is declared unreachable or if the metric increases beyond a
>> certain threshold, a router will not accept any other information about
>> that
>> route until the holddown timer expires."
>>
>> I have this topology to test it:
>>
>> /---R2----R3---\ <- eth
>> R1 R4
>> \--------------/ <- FR
>>
>>
>> R1 advertises 1.1.1.0/24
>> All interfaces are UP
>> R4 installs 1.1.1.0 in the routing table with metric 1 via R1
>>
>> If R1 shuts Serial int (direct to R4), R4 will set the route as
>> un-reachable
>> after the "invalid timer" expires and marks then the route as "possibly
>> down". At this point hold timer kick in.
>>
>> My problem is that R4 will NOT WAIT until hold timer expires before
>> installing new route (via R3 and R2). R4 will install 1.1.1.0 with metric
>> 3
>> immediately when it receives next updated from R3.
>>
>> What is wrong ?
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Mar 18 2011 - 17:18:13 ART