Filter
Top Products
Troubleshooting System for OS-6624/6648 and OS-7/8XXX Troubleshooting the Switch System
page 1-8 OmniSwitch Troubleshooting Guide September 2005
d on NI slot 1, GBIC port 2
MON AUG 21 23:28:39 2023 HSM-CHASSIS info == HSM == GBIC extraction detect
ed on NI slot 5, GBIC port 2
MON AUG 21 23:30:39 2023 HSM-CHASSIS info == HSM == GBIC Insertion detecte
d on NI slot 5, GBIC port 2
MON AUG 21 23:30:41 2023 HSM-CHASSIS info == HSM == GBIC extraction detect
ed on NI slot 1, GBIC port 1
MON AUG 21 23:30:45 2023 HSM-CHASSIS info == HSM == GBIC extraction detect
ed on NI slot 1, GBIC port 2
TUE AUG 22 00:05:45 2023 CSM-CHASSIS info == CSM == !!!ACTIVATING!!!
TUE AUG 22 00:05:45 2023 CSM-CHASSIS info == CSM == !!! REBOOT !!!
TUE AUG 22 00:05:53 2023 SYSTEM alarm System rebooted via ssReboot(),
restart type=0x2 (COLD)
The log message are kept in two log files: swlog1.log and swlog2.log in flash. In the above example, log
messages show that some GBICs were extracted and inserted at a particular time. In addition, the switch
was rebooted. This information helps to relate the time of the problem together with the events happening
at the switch. In addition, it also provides an idea about if the source of the problem was external or inter-
nal to the switch.
If the log messages do not show enough information then they can be changed for specific applications to
a higher log level or for all the applications running in the switch. For setting up different log levels in
switch log, please refer to the “Using Switch Logging” chapter in the appropriate OmniSwitch Network
Configuration Guide.
If the switch is running in redundant configuration make sure that the two CMMs are completely synchro-
nized. This can be done using the command:
-> show running-directory
Running CMM : PRIMARY,
Running configuration : WORKING,
Certify/Restore Status : CERTIFIED,
Synchronization Status : SYNCHRONIZED
If the two CMMs are not synchronized and the problem leads to the failure of Primary CMM then it will
result in re-initialization of all of the modules. If the two CMMs are properly synchronized and primary
CMM failed, the take over mechanism will be transparent to the end user. So, for complete redundancy
keep the two CMMs synchronized.
Look for any post-mortem dump files that may be created due to the problem with the switch. Post
Mortem Dump files have an extension of *.dmp and are created in /flash directory of the CMM (be sure to
check the secondary CMM, if running in redundant mode). System dump files are normally named as
“cs_system.dmp”, Memory related dump files are normally created as “MemMon000.dmp” and NI related
dump files are named as “SloXSliYver1.dmp”, where X is the slot number and Y is the slice number.
The creation of a dump file indicates a problem with the switch. System related dump files can be viewed
through CLI but other dump files cannot. For system related dump files use the command:
-> show log pmd cs_system.pmd
Capture the output of this command. In addition, if there are any dump files created in the switch, they
should be downloaded through FTP to forward them to technical support. Technical Support can have
them analyzed to find the source of the problem.