From: Omer Ansari (omer@xxxxxxxxxx)
Date: Sun Jun 30 2002 - 20:37:27 GMT-3
I should correct myself:
> using legacy snapshot routing, with Rtr1 as client, and Rtr2 as server.
> note that my quiet time is 8 min. and active time is 5min. that
> essentially means, I am not going to have 33.1/16 for more than 3.5
> minutes in Rtr2's routing table. (3 minutes of quiet time since last RIP
> update in the activetime + max 30 seconds for last RIP update in active
> time)
in the above I meant to say I am not going to see this route STALE for
more than 3.5 in Rtr2's routing table.
sorry about that!
On Mon, 1 Jul 2002, Omer Ansari wrote:
> All,
>
>
> 33.1/16--[lo10](Rtr1)[bri0/0]---{isdn_cloud}--[bri0/0](Rtr2)
>
> config snippets at the end of the email.
>
> using legacy snapshot routing, with Rtr1 as client, and Rtr2 as server.
> note that my quiet time is 8 min. and active time is 5min. that
> essentially means, I am not going to have 33.1/16 for more than 3.5
> minutes in Rtr2's routing table. (3 minutes of quiet time since last RIP
> update in the activetime + max 30 seconds for last RIP update in active
> time)
>
> problem happens when I shut down lo0 (33.1/16) on Rtr1.
>
> RIP does not make any effort in telling the other side if 33.1/16 is down
> and is completely out of the Rtr1's routing table.
>
> thus all it sends during the Next active time is:
> *Mar 4 00:07:49.074: RIP: sending v1 update to 255.255.255.255 via BRI0/0
> (12.0.1.1)
> *Mar 4 00:07:49.074: RIP: build update entries - suppressing null update
>
>
> meanwhile, R2, since it never got an [33.0.0.0 in 16 hops (inaccessible)]
> update (that it WOULD have received if Rtr1 had atleast one more route to
> tell rtr2 about) happily thinks it still has a route to 33.1/16 via Rtr1:
>
> R2#
> R2#sh ip route rip
> R 33.0.0.0/8 [120/1] via 12.0.1.1, 00:11:03, BRI0/0
> R2#
>
> note: its 11+minutes since the last update.
>
> So the questions are:
>
> 1. is this a corner case/ weakness of snapshot routing for RIP? or am I
> missing something?
>
> 2. is there _any_ expiry timer for snapshot routes in case the router
> responsible for sending the updates for those routes is having problems
> communicating their down status?
> If not, Rtr2 could keep the route indefinitely if Rtr1 is having problems
> sending its updates to Rtr2 (say b/c of encapsulation failure)
>
>
> thanks in advance!
> Omer
>
>
>
>
> Rtr1:
> -----
> !
> interface BRI0/0
> ip address 12.0.1.1 255.255.255.0
> encapsulation ppp
> no ip route-cache cef
> dialer idle-timeout 60
> dialer map snapshot 10 broadcast 4724821
> dialer map ip 12.0.1.2 broadcast 4724821
> dialer-group 1
> isdn switch-type basic-ni
> isdn spid1 919472482200 4724822
> snapshot client 5 8 suppress-statechange-update dialer
> ppp authentication chap
> end
> !
> dialer-list 1 protocol ip permit
> !
> router rip
> network 12.0.0.0
> network 33.0.0.0
> !
>
> Rtr2:
> -----
> !
> interface BRI0/0
> ip address 12.0.1.2 255.255.255.0
> encapsulation ppp
> no ip route-cache
> no ip mroute-cache
> dialer idle-timeout 300
> dialer map ip 12.0.1.1 broadcast 4724822
> dialer-group 1
> isdn switch-type basic-5ess
> snapshot server 5 dialer
> ppp authentication chap callin
> end
> !
> dialer-list 1 protocol ip permit
> !
> router rip
> network 12.0.0.0
> !
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:15 GMT-3