VCO/4K Troubleshooting Guide
Checklists
Download this chapter
ChecklistsChecklists
give_us_feedback

Table of Contents

Checklists

Checklists

This appendix contains checklists to capture the information for a Cisco TAC to most efficiently address your problem.

VCO Subsystem

Data Checklist - General Questions for the VCO Subsystem

Before you start gathering information, consider the following high-level general questions:

  • Have any recent host application changes been made?

  • Has any hardware been recently added to or deleted from the switch?

  • Was tracing turned on?

  • Can tracing be turned on to gather data?

SS7 Subsystem

Data Checklist

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.

Data Collection

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:

CC_CONFIG = tup (to set environment as China)

cd $XNV

version ckint (version is displayed)

Step 4   Are you running TCAP (yes or no)?

1. If yes, then what version? Type:

sept (log in)

abc123 (password)

cd $XNV

version sept (tcap version is displayed)

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?

What is the VCO RLSS designation for this span?

What is the hex address of the first port of this span?

(Obtain this information from the VCO Diagnostic / Display Card Data screen)

Preparing the Information for Transmission

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?

  • If yes, then what side was the core file created on (cktint-A or cktint-B)?

  • If no, i.e., if cktint died but did not core, provide the following additional information:

SUN OS / Solaris version. Log in to cktint from the a-side (and then again from the b-side) and issue the following UNIX command: uname -a. Put the output into a text file. Call it solver-a.txt when you log in to the a-side and solver-b.txt when you log in to the b-side. Then type:
cd /var/adm
ls -l
Put the output into a text file. Call it varadm-a.txt when you log in to the a-side and varadm-b.txt when you log in to the b-side.
  • Send all the files under /var/adm from the a-side.

  • Send all the files under /var/adm from the b-side.

Step 6   When cktint died, was a VCO core file created?

  • If yes, then what side was the core file created on (VCO-A or VCO-B)?

Send the VCO core file and add an A or B to the filename.

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?

  • If yes, then logged into what side (cktint-A or cktint-B or both)?

  • What was the administrator doing and from what directory? (Be as precise as possible.)

Step 13   At the time that cktint died, was a system administrator logged in to the VCO system?

  • If yes, then logged in to what side (VCO-A or VCO-B or both)?

What was the administrator doing and from what VCO screen? (Be as precise as possible.)
Provide the following files in addition to the core files specified above.
  • isup.mml

  • mtp.mml

  • ckt_ss7_to_sds

  • grp_ss7_to_sds

  • cktint-mmmdd.log from the ss7 a-side

  • cktint-mmmdd.log from the ss7 b-side

  • a-mmmdd.log from the vco a-side

b-mmmdd.log from the vco a-side
  • b-mmmdd.log from the vco b-side

a-mmmdd.log from the vco b-side

Step 14   Log in to the SS7/cktint a-side and provide the following ls -l outputs:

%pwd

/export/home/cktint/sys/CktintAnEnv/log

%ls -l

(Put the output into a text file. Name the file alogls-l.txt.)

%pwd

/export/home/cktint/sys/CktintAnEnv

%ls -l

(Put the output into a text file. Name the file aXNVls-l.txt.)

Step 15   Log in to the SS7/cktint b-side and provide the following ls -l outputs:

%pwd

/export/home/cktint/sys/CktintAnEnv/log

%ls -l

(Put the output into a text file. Name the file blogls-l.txt.)

%pwd

/export/home/cktint/sys/CktintAnEnv

%ls -l

(Put the output into a text file. Name the file bXNVls-l.txt.)