From: Earl Aboytes (earl@xxxxxxxxxxxx)
Date: Mon Jul 17 2000 - 06:10:17 GMT-3
Keith,
I am experiencing the same thing with PAP. I do not have this problem with
CHAP.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Earl Aboytes
Senior Technical Conultant
GTE Managed Solutions
805-381-8817
earl.aboytes@telops.gte.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of Keith
Kruepke
Sent: Sunday, July 16, 2000 7:45 PM
To: ccielab@groupstudy.com
Subject: PPP callback (yes, again)
Well, my efforts with PPP callback have not been any more successful the
second time around. I have modified my configs so that they look almost
identical to those in the documentation. Still I am having this one
problem.
Let me start by saying that PPP is working in most senses of the word--it's
just not working the way I want it to or would expect. So I don't plan on
spending much more time on this. But I thought I would put up one last
request to the group, just in case something will jump out at someone about
this config. Some of the stuff in here is probably not necessary, but I
have been adding stuff to see if it helps. My configs are at the bottom of
this message.
With these configs, I try to ping from R5 to R3. R5 dials, authenticates,
and disconnects, as it should. However, it does this five times before
giving up. Usually, this repeated dialing prevents R3 from finding an
available interface to dial out on. If I do an extended ping and select to
send only one packet, then it works fine.
Note that if I remove the 'dialer enable-timeout' command from R3, R3 waits
to dial until all five of R5's dial attempts. In this case, it works, but
by then all five pings have timed out. If I were to send an even bigger
flood of traffic (such as would happen in the real world), then the problem
would probably still happen, as R5 would dial many more times over. The
sample configs show an enable timeout of 2, which makes sense, because you
want the server to dial back right away, rather than making the traffic
wait.
So as I see it, this is a problem with R5, not R3. R5 should wait after
requesting a callback, not dial again immediately. (I would have thought
that to be the default behavior of callback...) But I've tried all sorts of
things (including 'dialer enable-timeout', 'isdn fast-rollover-delay',
'dialer hold-queue'), none of which have done the trick.
If anyone can help me out, that would be great. If anyone has a working
PPP callback config, feel free to send that if it is easier.
Thanks all,
Keith
-----
R5 (callback client) v12.1(2):
interface BRI0/0
ip address 130.130.101.21 255.255.255.252
encapsulation ppp
dialer enable-timeout 30
dialer map ip 130.130.101.22 name R3 broadcast XXXXXXX
dialer hold-queue 100 timeout 60
dialer-group 1
isdn switch-type basic-ni
isdn spid1 XXXXXXXXXX0101
isdn spid2 XXXXXXXXXX0101
isdn fast-rollover-delay 45
ppp callback request
ppp authentication pap callin
ppp pap sent-username R5 password 7 1306181C055957
-----
R3 (callback server) v11.3(3a)T1:
interface BRI0/0
ip address 130.130.101.22 255.255.255.252
encapsulation ppp
dialer callback-secure
dialer idle-timeout 60
dialer enable-timeout 2
dialer map ip 130.130.101.21 name R5 class cllbck broadcast XXXXXXX
dialer hold-queue 50 timeout 60
dialer-group 1
isdn switch-type basic-ni
isdn spid1 XXXXXXXXXX0101
isdn spid2 XXXXXXXXXX0101
ppp callback accept
ppp authentication pap callin
ppp pap sent-username R3 password 7 02050B5505555A
hold-queue 75 in
!
map-class dialer cllbck
dialer callback-server username
-----
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:54 GMT-3