Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've recently noticed problems with my 2621 router - it becomes unresponsive for about 10 minutes at a time, about 10 times a month. The router sits inbetween the outside world and servers which I routinely log in to - strangely, I've noticed that if I'm logged into my servers during these 10 minute outages, I remain logged in with no slowdown in responsivity. However, a ping from the server to the router hangs.

I'm not sure where to even being debugging the problem - I've enabled logging on the router but haven't noticed any messages which correlate strongly with the appearance of these events. Any suggestions on how to proceed would be greatly appreciated.

share|improve this question
Why is this a community wiki? – l0c0b0x Jun 30 '09 at 16:08
Looks like it was migrated from Stackoverflow. But I'm not sure. – splattne Jun 30 '09 at 16:19
@splattne It was. I found it closed over there with a link back here. – Joseph Jun 30 '09 at 16:37
@splattne and Joseph, I asked why some SO questions come here as wikis:… – l0c0b0x Jun 30 '09 at 17:17
Is there also a firewall anywhere in the mix? – sparks Jun 30 '09 at 19:13

Is there a correlation with High bandwidth usage when the router fails? I've seen these older 2621s starting to hang at 25-30Mbit usage (Most of the time using a lot of processes in the CPU, slowly increasing to 99% and deeming the router unable to attend more processes, even pings).

share|improve this answer

My first suggestion will be to learn to turn on accounting if this is a feature of the router. If this router does not have accounting as one of the features then, turn on snmp monitoring and download any snmp monitoring tool (free) and turn it on, until the next 10 minute period happens. In your snmp tool you will have a good indication on what is happening the minute before and after the issue.

You never mentioned on your message how you solve your issue. Is it by restarting, or it goes away or how else?

Also. Try to troubleshoot if this is due to the external link or internal, this will give you a good starting point.

I hope this helps.

share|improve this answer

This sounds like it might CPU spike. IOS will prioritise the switching of traffic over your login, so your through traffic may well be fine when your session becomes unresponsive. You can check for CPU spikes using the "show processes cpu history command" which will give up to 72 hours of history. For example, below shows a spike I had a couple of days ago:

        11111 1      9 1 1111      1 1111 1 1221  111 1 1 1 1 111  11 1 11
 90                  *
 80                  *
 70                  *
 60                  *
 50                  *
 40                  *
 30                  *                       *
 20                  *                       **
 10 *********** ************** *********************************************
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%

If you're logged in when the spike is happening then you can use "show processes cpu sorted 5min" to get an idea of what's eating all the CPU. It might also be worth enabling NetFlow or Flexible NetFlow to check if your router is getting port scanned or something at those times.

share|improve this answer

Assuming you have a CCO account, try doing a 'sh tech' and putting it through the Cisco Output Interpreter.

This will do a pretty good job diagnosing some some of the basics and is a good starting point. It should contain links to the bug tracker to help identify IOS bugs as were mentioned in some of the other posts, security recommendations and links to further documentation.

share|improve this answer

I'm the same 'Harry' as above - I decided to register an account for the site. I'm having trouble commenting on the responses above as I don't have enough reputation, but in response to the very helpful answers:

l0c0b0x - This was a great suggestion, it does appear to be correlated to bandwidth spikes. How would you suggest I proceed? I really am a newbie to Cisco router admin. I'm trying to investigate why the spikes are happening in the first place, but ideally I'd be able to set up the router to handle them without choking, if possible.

Geo - Will accounting affect performance? My hesitation in turning on features like this is I don't want to add an additional problem to the one I'm trying to fix... Also, the problem just goes away, seemingly when the bandwidth spikes go away.

Joseph - I appreciate the suggestion, but this isn't an option for me at this time.

share|improve this answer
Has the router been working without issue before or is this a new setup? – Joseph Jun 30 '09 at 20:47
Yes, the router had been working without issue before. I believe I've narrowed down the issue to bandwidth spikes - we run backup scripts to upload large datafiles offsite every so often, every network outage for the past two months has occurred at the same time. Any advice on the best way to solve this issue would be appreciated. – Harry Jul 1 '09 at 0:14

I would first update to the latest IOS. Most of the glitches I've seen on Cisco routers are related to faulty hardware or a bug in the IOS.

share|improve this answer
Do not change to the latest IOS, unless you have hit a known bug or the TAC center tells you to. Their is a false impression on having the latest code will solve all the bugs, but that is not completely true. – Geo Jun 30 '09 at 16:06
It will definitely not solve all the bugs. Each version introduces new bugs, but I've run into the wall where TAC says to update the IOS so many times, it's always my first step. I've had a good success rate just doing that. – Joseph Jun 30 '09 at 16:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.