3640, NAS, MICA, PRI, Telnet Delay, Dialup

I have been tying to set up a NAS server using a cisco 3640 equipped
with digital modems and a PRI link for our local business use. The
specs from the cisco web site were originally used. Everything worked
great except there was an initial delay when packet transfer starts.
When doing a file transfer, the data-rates are fine, but in a Telnet
session, there is delay between characters.
Initially the system was configured using no loopback interface(used
the fastethernet to reference the async group and dialer). It seemed
to work fine other than the delay on telnet(even into the 3640 from the
dialup) and the fact that ping would only work when doing data
transfers or web browsing. Now I have tried the Loopback, and I have
reached the point of diminishing eturns--it doesn't seem to work at
all. You can log on and be verified and get an IP address, but you
can't ping anything or access anything on the 192.168.2 network or
beyond. I have deleted my usernames/passwords and the 4 csu/dsu T1/E1
serial ports out of the config post since are turned down.

Any help is appreciated.

Sincerely,
Newbie.

no aaa new-model
ip subnet-zero
!
!
ip cef
no ip domain lookup
!
async-bootp dns-server 192.168.1.22
isdn switch-type primary-ni
!
!
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
!
interface Loopback0
ip address 192.168.4.1 255.255.255.0
!
interface Ethernet0/0
no ip address
logging event subif-link-status
half-duplex
!
interface FastEthernet1/0
ip address 192.168.2.6 255.255.255.0
speed auto
half-duplex
!
interface Serial1/0:23
no ip address
encapsulation ppp
dialer rotary-group 0
dialer-group 1
isdn switch-type primary-ni
isdn incoming-voice modem
no keepalive
no fair-queue
no cdp enable
!
!
interface Group-Async1
ip unnumbered Loopback0
encapsulation ppp
no ip mroute-cache
async mode interactive
peer default ip address pool dialin
no fair-queue
ppp authentication chap pap dialin
group-range 97 120
!
interface Dialer0
ip unnumbered Loopback0
encapsulation ppp
no ip mroute-cache
dialer in-band
dialer-group 1
peer default ip address pool dialin_pool
no fair-queue
no cdp enable
ppp authentication chap pap dialin
ppp multilink
!
router eigrp 1
passive-interface Dialer0
network 192.168.4.0
no auto-summary
!
ip local pool dialin 192.168.4.2 192.168.4.12
ip default-gateway 192.168.2.1
no ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.2.1
!
!
dialer-list 1 protocol ip permit
!
line con 0
exec-timeout 0 0
logging synchronous
line 97 120
exec-timeout 0 0
no vacant-message
modem Dialin
transport preferred telnet
transport input all
autoselect during-login
autoselect ppp
line aux 0

!

 

Do you see any eigrp neighbors here??? (do a 'sh ip eigrp nei').

 

Hi,

I experienced the same delay's you are experiencing. I wasn't using PRI
though, just ordinary analog modem modules. My problem lay in the fact
Windows dial-in clients didn't negotiate compression protocols correctly.
Try a "compression ..." statement on your group-async interface and see if
that helps. Disabling compression on the client-side also "solves" the
problem but obviously isn't going to give you a real solution.
All of this occured to me using an older IOS, 12.0(7)T, and should be have
been fixed in later versions. (according to Cisco, haven't tried yet).

Erik

 

It was compression. After the compression was turned off in the PC the
delay in the telnet sessions disappeared. Does anyone have a solution
in which compression can remain? The IOS is 12.3(9).

Thanks again.

 

Add the statement "compress mppc" to interface group-async1. This will also
fix the problem and you will still have compression enabled. This is a bug
in the MS PPP stack, where it acknologes it will do stac compression (cisco
default), when in fact it is really doing mppc comppression.

Scott

 

Thanks again for all the help-- when I added "compress mppc" to the
interface, the same old problem still exists. Ping -t looks good for
about 8 or nine pings and then starts timing out. Data transfer rates
are good once it starts going. Telnet is fine as long as you don't let
the session sit idle for more than a few seconds...if you do there is a
two or three second delay when you start typing before the first
character echos. With modem compression disabled in XP, it works fine
for telnet, but the data rate suffers.

Thanks.