Avaya WLAN Security Switch 2300 Series, Troubleshooting And Debug Manual, Page: 22 / 74

22
NN47250-700 (Version 04.01)
Check for core files
Do a “dir” command and check for the presence of core files. Use the command “
Copy core:<file>
tftp://<ip>/<file>
”
to transfer the core files to the tftp server. Then contact NETS and provide the
output of the “show tech” command.
Check the frequency of the cores for patterns
If the switch is crashing with a fairly regular period it is probably a memory leak. Periodically log the output
of the command “show mem summary proc netsys” (replace netsys with whichever process is named in the
corefile) to get a sample of memory usage on the switch over time, and send the logs to Avaya ATS. If the
cores are happening at a regular interval, increase the frequency you run the command on the day when the
core would be expected. The memory leak could be in a process other than the one which cores, so it may be
necessary to repeat this with other processes as well.
Capture serial console output during a crash
If possible, setup a laptop to log all output from the serial port and leave it running until the switch crashes
again. This is especially important if the switch isn’t leaving core files, or if the corefiles aren’t revealing
much information about the crash.
Investigate possible causes
Try undoing the most recent configuration changes to see if they are related to the crashing. Attempt to
identify what event is causing the crash (this may not be possible on a production network). TFTP the
“command_audi.cur” file from the switch and look for configuration changes prior to the first crash.
Check CPU Load
Run the command “show load” and then wait for a few minutes and run it again. The “delta” value the
second time you run the command will indicate the average CPU load for the period between the commands
being run. CPU loads higher than 50% over a 5 minute period are likely indicators of a problem. If the CPU
is pegged at 100% there is definitely a problem, and you should run the command “show fsm statistics”
every couple of minutes and provide the output to NETS. This command will display CPU activity used for
specific portions of the code and allows Engineering to narrow down which portion of the code is causing
the CPU load.
WMS service database corruption
Typical symptoms:
NOTE: The file “command_audit.cur” is not a core file from a crash, even though it has the
“core:” prefix.