unusually slow telnet into 3640 and ping loss

I've just replaced a 2610 router with a 3640 router supporting 2 T1
circuits. The configuration for the 3640 was copied from the 2610
(it's a very basic config). The 3640 is running IOS 12.1(1)T with
128MB RAM and 8MB flash.

Telnet sessions TO the router (for remote management) are VERY slow.
The cursor lags my typing to the point that I can't tell if it got the
keystrokes or not for several (5-10) seconds. Responses from the
router (say, from a show ver command) come back in chunks of text with
5-15 seconds between chunks.

I'm also seeing intermittent ping response when I try to ping the
FastEthernet0/0 port from either inside or outside my network; every
other packet is dropped.

Traffic through the router is fine (http, ftp, telnet, ping, etc.).
The problem seems to only be when I'm accessing the router itself.

Any ideas?

 

Hi Mike,

I can think of 2 immediate things to check -
1. It sounds like the 3640 Ethernet interface mode may not match
what the 2611 interface Mode was using and you have a duplex mismatch.
That can cause this type of issue...
2. Less likely is that the Ethernet segment is VERY busy. If so, then
try enabling NAGLE compression as that may make a difference

This is why I suggest you check that you do not have a Speed/Duplex
mismatch, the 2611 had ETHERNET ports (10MB) while the 3640 has
FASTETHERNET ports.

Cheers....................pk.

 

Peter,

Thanks. I already reconfigured my router and associated switch port to
both be 100FDx so that shouldn't be the issue. I'm not familiar with
NAGLE compression and Cisco's website just lists it as an unsupported
feature. Considering that this is my company's primary e-commerce
router and there's no discernable impact on traffic THROUGH the router
(just TO the router) I'm leery of turning something on that Cisco
doesn't fully endorse.

Thanks again.

 

You mentioned you were droping packets while doing ping.
If you direct connect to this device can you check your cpu and memory
utilization.

 

Hi Mike,

If you display the FE interface on the Router, does it look "clean"
with no errors? How do the input queues look, hopefully something
like this -
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
0
In particular are you seeing any drops?

If you are seeing drops then you may be pushing resources on your
Router to service that interface, in which case a "sh proc cpu" may
point to a task consuming plenty of CPU... It may also pay the clear
the counters for that interface and let things run for a while if they
haven't been cleared for less than 24 hours, just to make sure the
readings are current and relevant..

NAGLE is (was????) an option that can be useful for making telnet
connections TO the router run smoother over heavily utilised links.
It effectively buffers slowly typed characters (instead of telnets
default mode of character at a time) to pass them as a block of text,
giving the end user the impression of much smoother operation over
congested links. I was not aware that it had been removed from IOS,
however its use is limited over FastEthernet and full duplex links,
its really designed for heavily used slow speed WAN interfaces... Its
not important as 100FDX should be fine...

Nothing much else is springing to mind at the moment though.

Cheers................pk.

 

I only mention this because I have had it several times - I doubt it si the
issue especially as you get packet loss but do you have say TACACS+
authentication running with not TACACS server. THis makes telnet etc slow as
it timing out to the TACACS server.

or Even logging to a non existent server - Did the IP of the router change
with the upgrade somehow and this is now being rejected somewhere.

G

 

Thanks for the suggestions. The FE interface does look "clean" with no
drops or errors.

CPU utilization is low: 28% 5 sec (due to my telnet session), 7% 1 min,
7% 5 min. The only processes taking more than 1% are ARP Input (1.06%)
and Virtual Exec (36.10%). (Both of these are the 5sec numbers; ARP is
under 1% prior).

Memory utilization is also low: it looks like I have over 100MB free of
my 122MB/6MB installed.

I'll do some more checking into NAGLE; it's the most promising sounding
option I've heard.

 

"Telnet sessions TO the router (for remote management) are VERY slow."

I have seen this when there was a lot of packet loss on the line.
The telnet session to the router can be affected more that
other traffic in the case where the router does not
do selective acks (the default) and the other traffic
does.

If the slow sessions are affecting your troubleshooting
you can try turning on selective acks.

tcp sel........ ?

"supporting 2 T1 circuits.
.....
every other packet is dropped. "

Well!
Maybe your are doing per packet load sharing and
one of the Ts is not working for whatever reason.

 

If one of the T1's wasn't working I should see the packet loss on every
other packet THROUGH the router as well, shouldn't I? In my case,
pinging to a device through the router is fine; it's just connections
that end on the router that result in packet loss.

Turning on service nagle didn't seem to help. If anything it actually
slowed things down so I've turned it back off.

Not running TACACS.

IP of the new router is the same as the old router. The old router is
no longer connected to my network (would have been an IP address
conflict).

Thanks all.

 

Hi Mike,

If you have a fast link then that is probably the case, NAGLE buffers
the character data into blocks, hence with speed it may appear
slower....

Here's a couple of really long shots.........;-)
1. What is the Switch/Device the Router is connecting to?
Over the years I have seen 2 instances of separate Servers that were
incapable of operating their built in (IE motherboard based) 100Mb
NIC's at full speed, in fact both were slower at 100Mb than at 10Mb.
In one case reducing the NIC speed to 10Mb cured that one (no loss
there all data was heading out a 2Mb WAN so 10MB was plenty), in the
other case we put a new NIC into a PCI slot and that solved the 100Mb
issue over the built in NIC. Both these cases were about 3-4 years
ago so newer H/W shouldn't have any such problem now...

2. Is the entire path of the "slow" traffic operating at the same
LINK speed?
The "same speed" question relates to issues with "cut-through" mode
Etherswitches and speed conversions being required in them. Changing
the Router interface from 10Mb to 100Mb may have triggered this type
of effect if a speed change is now being applied that wasn't before.
Going back to 10Mb may restore this inequity... Again this is a really
old type problem and highly unlikely...

 

On 22 Apr 2005 13:05:40 -0700, wrote:

~ I've just replaced a 2610 router with a 3640 router supporting 2 T1
~ circuits. The configuration for the 3640 was copied from the 2610
~ (it's a very basic config). The 3640 is running IOS 12.1(1)T with
~ 128MB RAM and 8MB flash.
~
~ Telnet sessions TO the router (for remote management) are VERY slow.
~ The cursor lags my typing to the point that I can't tell if it got the
~ keystrokes or not for several (5-10) seconds. Responses from the
~ router (say, from a show ver command) come back in chunks of text with
~ 5-15 seconds between chunks.
~
~ I'm also seeing intermittent ping response when I try to ping the
~ FastEthernet0/0 port from either inside or outside my network; every
~ other packet is dropped.
~
~ Traffic through the router is fine (http, ftp, telnet, ping, etc.).
~ The problem seems to only be when I'm accessing the router itself.
~
~ Any ideas?

If your two T1s are running MLPPP, then I recall (but cannot find)
a bug way back in approx. your IOS' timeframe where, on TCP
connections terminated in the router, you would lose lots of segments
if they came in via a multilink bundle.

12.1(1)T was pretty sketchy ... I would recommend that you run
instead 12.1(large) or 12.2(large) mainline if you can.

Aaron

 

Thanks for the suggestions. I changed the link speed from 100FDx to
10FDx (the router is connected to an older firewall) and the overall
performance of the network seems to have improved slightly. However,
I'm still seeing packet loss and slow telnet response.

I have a work-around for now: if I telnet to the IP of my serial
interface (where the T1's connect) I get fast response and no packet
loss. At least I can manage like that until I resolve this issue
(which is now much less critical).

Thanks again.