Connection issues, drops off after 2 minutes

Hi all
A strange one I am hoping someone may of seen. This only seems to be
happening with a Cisco 837. A Speedtouch pro does not present these
symptoms. I have a client who has connected their 837 to the ADSL line,
it connects gets a line sync and authenticates. After this occurs I
connect remotely via telnet. Within a minute the device starts slowing
down, where when you type a command it takes a long time for it to
present to the screen, then after about another minute I am no longer
able to type anything at the console. From the LNS I am now unable to
ping the device. After a few more minutes it simply drops off the
radius and I no longer see the user online, but the 837 still shows a
sync. All the line settings, noise attentuation appear to be OK and as
I said the Speedtouch works fine. I have sent another 837 to site with
the exact same results. Everything has been isloated from the line
Any suggestions would be welcome, I have attached the config.
Config
!
version 12.3
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
!
hostname organon0893047686
!
boot-start-marker
boot-end-marker
!
!
clock summer-time AEDST recurring last Sun Oct 2:00 last Sun Mar 3:00
no aaa new-model
!
!
enable secret <removed>
!
ip subnet-zero
!
ip cef
vpdn enable
!
!
interface Ethernet0
ip address 192.168.1.1 255.255.255.0
ip nat inside
no ip redirects
no ip proxy-arp
ip policy route-map clear-df
no keepalive
no cdp enable
hold-queue 100 in
hold-queue 100 out
no shut
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
no fair-queue
no shut
!
interface ATM0.3 point-to-point
description Swiftel Internet Network
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 3
!
!
interface Dialer3
description Swiftel Internet Network
ip address negotiated
encapsulation ppp
dialer pool 3
ip nat outside
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname <removed>
ppp chap password <removed>
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 dial3
ip route 202.154.86.91 255.255.255.255 dial3
ip route 202.154.79.0 255.255.255.248 dial3
ip route 202.154.92.76 255.255.255.252 dial3
ip route 202.154.92.228 255.255.255.255 dial3
no ip http server
!
!
ip nat inside source list 99 interface Dialer3 overload
!
access-list 1 permit 202.154.79.0 0.0.0.7
access-list 1 permit 202.154.92.76 0.0.0.1
access-list 5 permit any
access-list 90 permit 202.154.92.76
access-list 90 permit 202.154.92.77
access-list 90 permit 202.154.92.228
access-list 99 permit 192.168.1.0 0.0.0.255
dialer-list 1 protocol ip permit
no cdp run
route-map clear-df permit 10
match ip address 5
set ip df 0
!
snmp-server community <removed> RO 90
snmp-server enable traps tty
banner motd ^C

YOU DO NOT HAVE PERMISSION TO ACCESS THIS DEVICE


Unauthorized access to this device or the attached
networksis prohibited without express written permission all
Violators will be prosecuted to the fullest extent of both civil
and criminal law.
You must cease your access attempt immediately.
Your access is being logged.^C
!
line con 0
exec-timeout 120 0
password <removed>
login
transport preferred all
transport output all
stopbits 1
line vty 0 4
exec-timeout 240 0
password <removed>
login
length 0
transport preferred all
transport input telnet
transport output telnet
access-class 1 in
!
no scheduler max-task-time
!
end

 

Do you monitor logging while this begins to occur? Quite likely some
interesting log entries will appear leading you to a root cause.

If I was a gambling man I would be led to believe you may see positive
results by trimming down your MTU on the dialer interface. Try setting the
IP MTU to 1452 or even 1400. If you debug icmp and you see MTU errors the
MTU size set in your dialer is the root of your problems.

Generally I've seen most MTU problems with GRE due to the encapsulation of
the packet.

 

There was a recent posting about 837 and vpn problems ,search this
newgroup for 837 vpn


also see
http://groups.google.com/group/comp...3e37c405acd?q=837+cef&rnum=3#d47a03e37c405acd

 

Tried all of these suggestions, thanks to all those that contributed.
Still seeing this problem thou. I tried setting the MTU to as low as
1000 on the Dialler i/f and the ethernet i/f. When I ping using a 1000
byte packet payload it is successfull, but as soon as I try and ping
above this it fails and then I can't ping at all. I have tried using
pppoe rather than pppoa also.
Any other suggestions would be welcome. I ended up installing a Netcomm
which works a treat but will still need to install the 837 again at
some point in time.

 

Addition to my last post, just plugged the 837 in at the office and it
works fine. I suspect it must have something to do with the equipment
located at the Telstra exchange has anyone had similar problems to this
before?