From: wing_lam@jossynergy.com
Date: Sun Aug 10 2003 - 09:24:51 GMT-3
Hi Daniel,
I think it really getinto the quite queue as the following debug shows
"moving to quite queue".
I have change the snap client to server and vice versa, the result still
the same, i.e. the quite time still 8 minutes.
It still a puzzle to me why the quite time not conform to the configured.
Thx a lot,
BBD (Big Blkac Dog)
R11#sh snap
Dialer1 is up, line protocol is upSnapshot client
Options: dialer support, stay asleep on carrier up
Length of active period: 5 minutes
Length of quiet period: 100000 minutes
Length of retry period: 8 minutes
For dialer address 1
Current state: client post active->quiet, remaining time: 0 minutes
R11#sh snap
Mar 4 13:33:53.139 GMT: SNAPSHOT: Dialer1[1]: retrying; no updates
exchanged
Mar 4 13:33:53.139 GMT: SNAPSHOT: Dialer1[1]: moving to quiet queue
Dialer1 is up, line protocol is upSnapshot client
Options: dialer support, stay asleep on carrier up
Length of active period: 5 minutes
Length of quiet period: 100000 minutes
Length of retry period: 8 minutes
For dialer address 1
Current state: quiet, remaining: 7 minutes
"Daniel Sheedy"
<dansheedy@gmx.ne To: <wing_lam@jossynergy.com>
t> cc:
Subject: Re: Snapshot routing quite time
08/08/2003 08:27
PM
Hi BBD,
If you look in your output from the "sh snap", it isnt the quiet time, but
the retry time that is 8 minutes.
If you go here...
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2021.htm
And scroll down to 12-2, it explains about the update process and also the
retry time.
Then, a little bit further, you can see the tabel 12-1, which shows that
the
retry time is not configurable.
Cheers,
Dan
----- Original Message -----
From: <wing_lam@jossynergy.com>
To: <ccielab@groupstudy.com>
Sent: Friday, August 08, 2003 11:50 AM
Subject: Snapshot routing quite time
> Hi group,
>
> I am configured the Snapshot routing between two router running RIP.
>
> I configured the quite time to be 100000 minutes, which is around 69
days.
>
> My problem is, although the router knows the quite time is 100000
minutes,
> everytime after the active perios finishes, it starts the quite period
> which only 8 minutes. The following is the scene just after the active
> perion finishes and it starts a 8 minutes quite time although it knows
the
> length of quite period is 100000 minutes:
>
> R11#sh snap
> Dialer1 is up, line protocol is upSnapshot client
> Options: dialer support, stay asleep on carrier up
> Length of active period: 5 minutes
> Length of quiet period: 100000 minutes
> Length of retry period: 8 minutes
> For dialer address 2
> Current state: client post active->quiet, remaining time: 0 minutes
> R11#sh snap
> Dialer1 is up, line protocol is upSnapshot client
> Options: dialer support, stay asleep on carrier up
> Length of active period: 5 minutes
> Length of quiet period: 100000 minutes
> Length of retry period: 8 minutes
> For dialer address 2
> Current state: client post active->quiet, remaining time: 0 minutes
> R11#sh snap
> Dialer1 is up, line protocol is upSnapshot client
> Options: dialer support, stay asleep on carrier up
> Length of active period: 5 minutes
> Length of quiet period: 100000 minutes
> Length of retry period: 8 minutes
> For dialer address 2
> Current state: quiet, remaining: 7 minutes
>
>
> Config as following, has anybody experience this and why the quite time
not
> conforms to what the route knows?
>
> Server's dialer interface
> interface Dialer1
> ip address 10.233.1.2 255.255.255.0
> no ip directed-broadcast
> encapsulation ppp
> load-interval 30
> dialer remote-name R11
> dialer idle-timeout 10
> dialer string 21
> dialer pool 1
> dialer watch-group 1
> dialer-group 1
> no peer neighbor-route
> no peer default ip address
> snapshot server 5
> ppp authentication chap
> !
>
> Client's dialer interface
> interface Dialer1
> ip address 10.233.1.1 255.255.255.0
> no ip directed-broadcast
> encapsulation ppp
> dialer remote-name R9
> dialer idle-timeout 10
> dialer fast-idle 1
> dialer string 20
> dialer snapshot 2
> dialer pool 1
> dialer-group 1
> no peer neighbor-route
> snapshot client 5 100000 suppress-statechange-update dialer
> ppp authentication chap
> end
>
>
> Thx,
> BBD (Big Black Dog)
> DISCLAIMER:- This email is confidential and intended only for the use of
> the individual or entity named above and may contain information that is
> privileged. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this email is strictly
> prohibited. If you have received this email in error, please notify us
> immediately by return email or telephone and destroy the original
message.
> Thank you.
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:53:57 GMT-3