Re: RIP Timers

inaccessible mean that the route will be with metric 16 there is no
worse in RIP then metric 16

> *Mar 1 05:14:00.694: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
...
> *Mar 1 05:14:02.706: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
...
# once you received an update from 10.0.34.4 with metric of 3 you installed it
> *Mar 1 05:14:16.686: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
> *Mar 1 05:14:16.686: 1.1.1.0/24 via 0.0.0.0 in 3 hops
> *Mar 1 05:14:16.686: RIP-DB: network_update with 1.1.1.0/24 succeeds
> *Mar 1 05:14:16.686: RIP-DB: adding 1.1.1.0/24 (metric 3) via

...
On Sat, Mar 20, 2010 at 11:00 PM, Erwin van Harrewijn <erwin_at_f1x0r.nl> wrote:
> Hi All,
>
> Has anyone succesfully build a lab-setup to demonstrate the working of
> the holddown-timer?
> I have run sevaral tests, but to me it appears as if the router simply
> ignores the holddown timer.
>
> Even if the router has the route as "inaccessible" in it's database,
> as soon as it learns a new (even worse) route to the same network, it
> is directly installed in the routing table
>
> Does anyone have a good test, or can someone explain what I did wrong
> in my test below
>
>
> ==========================
> MY TEST:
> ==========================
>
> I tried to build a setup with 4 routers:
> On R1 I created a loopback network 1.1.1.0/24
>
> L1
> |
> |
> R1 - - - - R2
> | |
> | |
> R3 - - - - R4
>
>
>
> STEP 1:
> On R1 I shut the interface f0/0 to R2 and waited 180 sec (see below)
>
> L1
> |
> |
> R1x - -R2
> | |
> | |
> R3 - - - - R4
>
> -> All routers learn the network to 1.1.1.0/24 via R3
>
>
> STEP 2:
> I shutdown the loopback interface on R1
> -> All routers receive a flash-update invalidating the route to 1.1.1.0/24
> -> All routers have the route as "inaccesible" in the rip database
>
> L1
> x
> |
> R1x - -R2
> | |
> | |
> R3 - - - - R4
>
> STEP 3:
> a) I quickly shutdown f0/1
> b) I quickly no shut the loopback to 1.1.1.0/24
> c) I quickly no shut the f0/0 to R2
>
> L1
> |
> |
> R1 - - - - R2
> x |
> | |
> R3 - - - - R4
>
> -> R3 learns the route to 1.1.1.0/24 via R4 directly. I would have
> expected the holddown timer to prevent R3 learning a inferior route
> from R4.
>
> DEBUGGING OF RIP ON ROUTER R3:
> *Mar 1 05:14:00.694: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
> *Mar 1 05:14:00.694: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
> *Mar 1 05:14:00.698: RIP-DB: Remove 1.1.1.0/24, (metric 4294967295)
> via 10.0.34.4, FastEthernet0/0
> *Mar 1 05:14:00.702: RIP-DB: adding 0.0.0.0/0 (metric 4294967295) via
> 0.0.0.0 on Null0 to RIP database
> *Mar 1 05:14:02.702: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet0/0 (10.0.34.3)
> *Mar 1 05:14:02.706: RIP: build flash update entries
> *Mar 1 05:14:02.706: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
> *Mar 1 05:14:02.710: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet0/1 (10.0.13.3)
> *Mar 1 05:14:02.710: RIP: build flash update entries
> *Mar 1 05:14:02.710: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
> *Mar 1 05:14:02.710: RIP: sending v2 flash update to 224.0.0.9 via
> Loopback3 (3.3.3.3)
> *Mar 1 05:14:02.710: RIP: build flash update entries
> *Mar 1 05:14:02.710: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
> *Mar 1 05:14:02.710: RIP: ignored v2 packet from 3.3.3.3 (sourced
> from one of our addresses)
> *Mar 1 05:14:11.154: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/1 (10.0.13.3)
> *Mar 1 05:14:11.158: RIP: build update entries
> *Mar 1 05:14:11.158: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
> *Mar 1 05:14:11.162: 3.3.3.0/24 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:14:11.162: 4.4.4.0/24 via 0.0.0.0, metric 2, tag 0
> *Mar 1 05:14:11.166: 10.0.24.0/24 via 0.0.0.0, metric 2, tag 0
> *Mar 1 05:14:11.170: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:14:16.014: RIP: sending v2 update to 224.0.0.9 via
> Loopback3 (3.3.3.3)
> *Mar 1 05:14:16.014: RIP: build update entries
> *Mar 1 05:14:16.014: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
> *Mar 1 05:14:16.014: 2.2.2.0/24 via 0.0.0.0, metric 3, tag 0
> *Mar 1 05:14:16.014: 4.4.4.0/24 via 0.0.0.0, metric 2, tag 0
> *Mar 1 05:14:16.018: 10.0.12.0/24 via 0.0.0.0, metric 2, tag 0
> *Mar 1 05:14:16.022: 10.0.13.0/24 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:14:16.022: 10.0.24.0/24 via 0.0.0.0, metric 2, tag 0
> *Mar 1 05:14:16.026: 10.0.34.0/24 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:14:16.026: RIP: ignored v2 packet from 3.3.3.3 (sourced
> from one of our addresses)
> *Mar 1 05:14:16.686: RIP: received v2 update from 10.0.34.4 on FastEthernet0/0
> *Mar 1 05:14:16.686: 1.1.1.0/24 via 0.0.0.0 in 3 hops
> *Mar 1 05:14:16.686: RIP-DB: network_update with 1.1.1.0/24 succeeds
> *Mar 1 05:14:16.686: RIP-DB: adding 1.1.1.0/24 (metric 3) via
> 10.0.34.4 on FastEthernet0/0 to RIP database
> *Mar 1 05:14:16.686: RIP-DB: add 1.1.1.0/24 (metric 3) via 10.0.34.4
> on FastEthernet0/0
> *Mar 1 05:14:16.686: RIP-DB: adding 0.0.0.0/0 (metric 4294967295) via
> 0.0.0.0 on Null0 to RIP database
> *Mar 1 05:14:18.686: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet0/0 (10.0.34.3)
> *Mar 1 05:14:18.686: RIP: build flash update entries - suppressing null update
> *Mar 1 05:14:18.686: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet0/1 (10.0.13.3)
> *Mar 1 05:14:18.690: RIP: build flash update entries
> *Mar 1 05:14:18.690: 1.1.1.0/24 via 0.0.0.0, metric 4, tag 0
>
>
> Any guru has a clue?
>
> Thanks,
> Erwin
>
>
> On 20 February 2010 06:45, <kebramccie_at_gmail.com> wrote:
>> Hi sarad,
>>
>> The holddown timer specifies the time duration updates regarding better paths are surpressed. A route enters a hold down state when an update packet is received that a route is unreachable. The routes hop count will be increased to 16 hence marked unreachable to other neighbors. However, rip running routers will continue to forward packets until an update is received with a better metric or until the hold down timer expires. When hold down expires, routes advertised by other sources are accepted and the route is no longer accessible.
>>
>> Answering your question I think new routes are added after the hold down period. More experienced guys should please let me know if my reasoning is wrong as I have nt labbed this up.
>>
>> HTH (that's if this helps.. :)
>>
>> Kabir
>> ------Original Message------
>> From: Sarad
>> Sender: nobody_at_groupstudy.com
>> To: groupstudy
>> ReplyTo: Sarad
>> Subject: RIP Timers
>> Sent: Feb 20, 2010 03:53
>>
>> Hi All,
>>
>> I have some concerns on RIP timers. Would like to clear it out, As per RIP
>> default timers, Update = 30, Invalid = 180, holddown=180, flush = 240
>> Let say a router got an update saying particular destination is down. Ok
>> then it will go to invalid after 180 seconds time between the Invalid (180)
>> to flush(240) router still route the packet to destination ie its still in
>> the routing table. It's only will be removed after flush timer expires.
>>
>> My question is Ok if I get a new route with larger metric to the same
>> destination it will not be install to the routing table untill holddown
>> timer expires let say when hold down timer expires it will add the new route
>> to the Routing table but my question is as Holddown timer is less than the
>> flush timer how can a router can add a route with a higher distance before
>> flush timer expire. Or will hold down timer will trigger the flush timer.
>>
>> Whats the best debug or show command to monitor this set up?
>>
>> Thanks
>> Sara
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Sent from my BlackBerry wireless device from MTN
>>
>>
>> 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
>
> _______________________________________________________________________
> 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