Atlantixglobal
asked on
Cisco 2821 Crashing (Crash Info log)
Hey guys, I have a Cisco 2821VK9 router that is crashing periodically. Can you take a look at the crash info log and give me some advice? (See attached)
crashinfo-20100819-143437-EDT crashinfo-20100819-150027-EDT
Here is my sh ver
Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 15.1(1)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Mon 22-Mar-10 01:25 by prod_rel_team
ROM: System Bootstrap, Version 12.3(8r)T7, RELEASE SOFTWARE (fc1)
ATLVIP1 uptime is 18 hours, 43 minutes
System returned to ROM by bus error at PC 0x0, address 0x0 at 15:00:28 EDT Thu Aug 19 2010
System restarted at 15:02:00 EDT Thu Aug 19 2010
System image file is "flash:c2800nm-spservicesk 9-mz.151-1 .T.bin"
Last reload type: Normal Reload
Cisco 2821 (revision 53.51) with 249856K/12288K bytes of memory.
Processor board ID FTX0912A12T
2 Gigabit Ethernet interfaces
144 Serial interfaces
6 Channelized T1/PRI ports
8 Voice FXS interfaces
DRAM configuration is 64 bits wide with parity enabled.
239K bytes of non-volatile configuration memory.
500472K bytes of ATA CompactFlash (Read/Write)
crashinfo-20100819-143437-EDT crashinfo-20100819-150027-EDT
Here is my sh ver
Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 15.1(1)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Mon 22-Mar-10 01:25 by prod_rel_team
ROM: System Bootstrap, Version 12.3(8r)T7, RELEASE SOFTWARE (fc1)
ATLVIP1 uptime is 18 hours, 43 minutes
System returned to ROM by bus error at PC 0x0, address 0x0 at 15:00:28 EDT Thu Aug 19 2010
System restarted at 15:02:00 EDT Thu Aug 19 2010
System image file is "flash:c2800nm-spservicesk
Last reload type: Normal Reload
Cisco 2821 (revision 53.51) with 249856K/12288K bytes of memory.
Processor board ID FTX0912A12T
2 Gigabit Ethernet interfaces
144 Serial interfaces
6 Channelized T1/PRI ports
8 Voice FXS interfaces
DRAM configuration is 64 bits wide with parity enabled.
239K bytes of non-volatile configuration memory.
500472K bytes of ATA CompactFlash (Read/Write)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>Possible software fault. Upon reccurence, please collect
crashinfo, "show tech" and contact Cisco Technical Support.
Pretty clear that this is potential IOS bug...
>6 Channelized T1/PRI ports
On a 2821? That's working it really hard. What else is this router doing besides being a voice gateway? Is it MGCP gateway, or other?
crashinfo, "show tech" and contact Cisco Technical Support.
Pretty clear that this is potential IOS bug...
>6 Channelized T1/PRI ports
On a 2821? That's working it really hard. What else is this router doing besides being a voice gateway? Is it MGCP gateway, or other?
ASKER
I just found out that the following debugs were running prior to the crash. It's nice to have that info before hand.
ATLVIP1#sh deb
TCP:
TCP special event debugging is on
The following ISDN debugs are enabled on all DSLs:
debug isdn error is ON.
debug isdn q931 is ON. (filter is OFF)
H.225:
H.225 ASN1 Messages debugging is on
H.245:
H.245 ASN1 Messages debugging is on
CCH323 SPI: H245 State Machine tracing is enabled (filter is OFF)
CCAPI:
debug voip ccapi inout is ON (filter is OFF)
I'm pretty sure this is what started hogging CPU time and ultimately caused the router to crash.
ATLVIP1#sh deb
TCP:
TCP special event debugging is on
The following ISDN debugs are enabled on all DSLs:
debug isdn error is ON.
debug isdn q931 is ON. (filter is OFF)
H.225:
H.225 ASN1 Messages debugging is on
H.245:
H.245 ASN1 Messages debugging is on
CCH323 SPI: H245 State Machine tracing is enabled (filter is OFF)
CCAPI:
debug voip ccapi inout is ON (filter is OFF)
I'm pretty sure this is what started hogging CPU time and ultimately caused the router to crash.
It is good that you have found those detailed call processing debugs were turned on. Excessive amounts of terminal output can create issues especially if console logging is turned on. Turning off console logging using "no logging console" is a good practice. Logging messages to the console port generates non maskable interrupts, its impact gets worse especially if those messages are debug messages, which are high priority than other log types. Instead you can log to the buffer or to a syslog server or to telnet (terminal monitor) if logging is required.
ASKER