unusually slow telnet into 3640 and ping loss

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.

Peter wrote:

mismatch.

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...

Understood...

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...

1. 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...

~ 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.