|
This appendix contains checklists to capture the information for a Cisco TAC to most efficiently address your problem.
Before you start gathering information, consider the following high-level general questions:
This section deals with ckint software failure (with and without ckint core file). It guides you through a data collection process that requires you to enter commands at several points and to then paste the resulting information into a .txt file. Then send the .txt file to TAC for analysis.
This procedure is needed if the cktint software malfunctions, and is needed whether or not the core file was created.
Step 1 Is the VCO/SS7 platform a redundant or nonredundant platform?
Note Many questions that follow assume a redundant platform. Ignore these questions if you have a nonredundant platform. |
Note All data to be collected and provided to Cisco is obtained by logging into cktint on the "SS7/cktint system" (as specified) - unless stated otherwise. |
Step 2 Create a file stating the software version numbers of the following platform. Name this file versions.txt and list the versions in the following order and with the following labels:
a. VCO = (found by logging in to the VCO main menu)
b. CKTINT = (found by logging in to cktint)
Enter:
cd $XNV
version cktint
c. VARIANT = (cktint variant)
State which cktint variant you are running. This will be ANSI, ITU(CCITT), ITU(CCITT)-MSP (Multi Signaling Point), or Japan.
d. AMGR = (found by logging into cktint)
Enter:
cd $EBSHOME/access/dat
cat version.dat
e. SUN OS / Solaris = (found by logging into cktint)
Enter:
uname -a
Step 3 Are you running China-TUP?
a. If yes, then what version? Type:
Step 4 Are you running TCAP (yes or no)?
1. If yes, then what version? Type:
Step 5 Were new circuits brought into service within the last 60 days?
a. If yes, then approximately how many days ago did you turn up the last circuit/span/trunk/trunk group?
To prepare the data you have gathered, do the following:
Step 1 Encode (uuencode, optional) the cktint core file, if any.
Step 2 Compress the VCO core file, if any (Winzip).
Step 3 Compress any cktint log file that is over 0.5 MB.
Step 4 Compress any VCO log file that is over 0.5 MB.
Step 5 When cktint died, was a cktint core file created?
Step 6 When cktint died, was a VCO core file created?
Step 7 Log in to cktint and type ps -ef on the side that died.
a. Put the output into a text file. Name the file psef-died_x.txt (where "_x" is the side that you issued the command on).
b. Type px on the side that died.
c. Put the output into a text file. Name the file px-died_x.txt (where "_x" is the side that you issued the command on).
Step 8 When cktint died, did SS7/cktint properly switch over (yes or no)?
Step 9 When cktint died, did VCO/generic properly switch over (yes or no)?
Step 10 When cktint died and if a proper switchover occurred, then what event did the host application see, from its perspective, that caused it to decide to issue a switchover command (the host application switchover command, if issued, would be recorded in the VCO active-side log)?
Step 11 Analyze your host application logs and summarize what the host application was doing at the time of the switchover command.
Step 12 At the time that cktint died, was a system administrator logged in to cktint?
Step 13 At the time that cktint died, was a system administrator logged in to the VCO system?
Step 14 Log in to the SS7/cktint a-side and provide the following ls -l outputs:
Step 15 Log in to the SS7/cktint b-side and provide the following ls -l outputs:
Posted: Sat Sep 28 18:07:00 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.