Re: RIP Timers

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
Received on Sat Mar 20 2010 - 22:00:36 ART