Tracking Mysterious Reload

Mar 15, 2006 4 Replies
T
Tracking Mysterious Reload open original image

This switch reloaded and I cannot figure out how.



From the show version (inserted below), it appears someone issued a 'reload'

-Only 2 people have login access to this device, both claim they did not issue a reload.


-Physical access to this room is monitored and I verified noone was in the room when this device reloaded (besides, resaet by switch would show return to rom by power)


-Device never lost power (besides, that would show return to rom by power)


-SNMP pub and priv are running with CiscoWorks


-I checked output interpreter, nothing seems out of the ordinary. I do not see any bugs for this device/IOS that will reload device. I see some that *crash*, but none that *reload* I enabled syslogging in case this happens again, but I was wondering if anyone has any suggestions to determine how this device reloaded? TIA for any assistance.


------------- sw1#sho ver Cisco Internetwork Operating System Software IOS (tm) C2900XL Software (C2900XL-C3H2S-M), Version 12.0(5)WC3b, RELEASE SOFTWA RE (fc1) Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 15-Feb-02 10:14 by antonino Image text-base: 0x00003000, data-base: 0x00337600 ROM: Bootstrap program is C2900XL boot loader usd-control-sw1 uptime is 1 week, 1 day, 16 hours, 58 minutes System returned to ROM by reload System restarted at 01:51:23 UTC Tue Mar 7 2006 System image file is "flash:c2900XL-c3h2s-mz.120-5.WC3b.bin" cisco WS-C2924C-XL (PowerPC403GA) processor (revision 0x11) with


8192K/1024K byt es of memory. Processor board ID , with hardware revision 0x01 Last reset from warm-reset Processor is running Enterprise Edition Software Cluster command switch capable Cluster member switch capable
24 FastEthernet/IEEE 802.3 interface(s)
32K bytes of flash-simulated non-volatile configuration memory. Model revision number: A0 Motherboard revision number: C0 Model number: WS-C2924C-XL-EN Configuration register is 0xF

---------------------------

Vote
Twitter Facebook LinkedIn
C

Post the output from the "show stack" command. If the switch actually crashed but somehow the reload cause is not being reflected correctly (due to a bug) in shpw version, you might see some system context from the crash.

Cisco da Gama

formatting link

Vote
Twitter Facebook LinkedIn
T

Thanks for your reply Cisco da Gama. Here is show stack. Just for fun I ran this through Output Interpreter, which claims "There are no software or hardware bugs to report"

-------------------- sw1#sh stack Minimum process stacks: Free/Size Name 5036/6000 mflash init 5068/6000 CPU Interface POST 1856/3000 Switch Parameters Initialization Process 2332/3000 Module Management Process 7032/12000 malibu static front-end post 2760/3000 Address Aging Init 1932/3000 Address Table Init 5500/6000 malibu post 5648/6000 VTP Malibu Shim Process 5588/6000 Frank Mainboard Init 4932/6000 Del Mar Init 8624/12000 Init 2624/3000 Inline Power 5488/6000 atm Init 5424/6000 Ethernet Controller Init 5516/6000 malibu init 9228/12000 HTTP Server 8752/12000 Virtual Exec 7808/9000 DHCP Client

Interrupt level stacks: Level Called Unused/Size Name 4 462335221 8228/9000 CPU NETWORK INTERFACE CHIP 6 0 9000/9000 403 SERIAL VECTOR

-----------------------

Vote
Twitter Facebook LinkedIn
C

The "show stack" output looks clean and indicates no prior crash. I guess you will just have to wait until it happens again and you catch it happening if indeed this was not a manually initiated reload.

Cisco da Gama

formatting link

Vote
Twitter Facebook LinkedIn
T

I suspected as much. Thanks for your time Cisco da Gama.

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required