-
Cisco PGW 2200 Softswitch Release 9 Operations, Maintenance, and Troubleshooting Guide
-
Preface
-
Chapter 1 - Cisco PGW 2200 Softswitch Platform Overview
-
Chapter 2 - Cisco PGW 2200 Softswitch Platform Component System Startup and Shutdown
-
Chapter 3 - Cisco PGW 2200 Softswitch Platform Operations
-
Chapter 4 - Maintenance and Troubleshooting Overview
-
Chapter 5 - Maintaining the Cisco PGW 2200 Softswitch
-
Chapter 6 - Maintaining the Cisco IP Transfer Point LinkExtender
-
Chapter 7 - Maintaining the Cisco Catalyst 5500 Multiswitch Router
-
Chapter 8 - Troubleshooting the Cisco PGW 2200 Softswitch Platform
-
Appendix A - Configuring Cisco PGW 2200 Softswitch Log Files
-
Appendix B - Troubleshooting Cisco ITP-L Signaling
-
Appendix C - Troubleshooting Cisco Switch Signaling
-
Appendix D - Cisco PGW 2200 Softswitch Measurements
-
Table Of Contents
Troubleshooting the Cisco PGW 2200 Softswitch Platform
Cisco PGW 2200 Softswitch Failure
Troubleshooting Using Cisco PGW 2200 Softswitch Alarms
Alarm Troubleshooting Procedures
ANAL: BNum_MdfyBFail_ AnnounceID
ANAL: Cause_GetFail_InvldRsltType
ANAL:Cause_InvldRslts_CauseTbl
ANAL: Cause_MdfyBFail_AnnounceID
ANAL: Cause_MdfyBFail_AppPtInvld
ANAL: Prof_MdfyBFail_AppPtInvld
ANAL: RteTableFail_GetTrkAttrdata
ANAL: RteTableFail_GetTrkGrpdata
ANAL: RteTableFail_GetTrunkList
ANAL: TableFail_BearerCapTable
ANAL: TableFail_CondRouteDescTable
ANAL: TableFail_CondRouteTable
ANAL: TableFail_PercRouteTable
Call Back Feature Insertion Failure
Call Back Feature Deletion Failure
MeterPulseTariff Table Load Failure
OLC: Leg1chanSeizedUnpackError
OLC: Leg1chanModifiedUnpackError
OLC: Leg1chanDeletedUnpackError
OLC: Leg1deleteChanUnpackError
OLC: Leg1notifyRequestAckUnpackError
TALI: Invalid Protocol Version
TLC: Leg2chanSeizedUnpackError
TLC: Leg2chanModifiedUnpackError
TLC: Leg2chanDeletedUnpackError
TLC: Leg2deleteChanUnpackError
TLC: Leg2notifyRequestAckUnpackError
Troubleshooting with System Logs
Understanding System Log Messages
Changing the Log Level for Processes
Creating a Diagnostics Log File
Collecting System Data for Cisco TAC
Resolving SS7 Network Related Problems
Signaling Destination Problems
SS7 Destination is Out of Service
SS7 Destination is Unavailable
Signaling Channel Troubleshooting Procedures
Setting the Service State of a Signaling Service
Setting the Service State of an SS7 Signaling Service
Setting the Service State of a C7/SS7 Link or Linkset
Setting the Service State of an IP Link
Setting the Service State of an IP Route
Setting the Service State of a D-channel
Setting the Service State of a Local Subsystem Number
Setting the Service State of an Association
Managing Japanese SS7 Signaling Link Tests
Managing Japanese SS7 Signaling Route Tests
Verifying Proper Loading of a Dial Plan
Verifying Configuration to Support Multiple Versions of SS7
Resolving an Association Alarm
Converting Stored and Transmitted Point Code Values
Resolving Bearer Channel Connection Problems
Setting the Administrative State
Setting the Administrative State of a Cisco PGW 2200 Softswitch
Setting the Administrative State of a Media Gateway
Setting the Administrative State of a Trunk Group
Setting the Administrative State of a Signaling Service
Setting the Administrative State of Spans
Setting the Administrative State of CICs
Querying Local and Remote CIC States
Resolving Local and Remote CIC State Mismatch
Performing CIC Validation Tests
Resolving ISDN D-Channel Discrepancies
Unblocking Locally Blocked CICs
Unblocking Remotely Blocked CICs
Stopping Calls on a Cisco PGW 2200 Softswitch
Stopping Calls on a Media Gateway
Stopping Calls on a Trunk Group
Stopping Calls on a Signaling Service
Auditing an MGCP Media Gateway
Starting an MGCP Media Gateway Audit
Retrieving an MGCP Media Gateway Audit
Running a Manual Continuity Test
Verifying Continuity Test Settings
Media Gateway IP Destination/Link Out-of-Service
Calls Fail at the Cisco PGW 2200 Softswitch
3.1 KHz (ISDN Category 3) Calls are Failing
Resolving SIP Communication Problems
Starting A Call Trace (on Release 9.7(3) Patch 8)
Retrieving Names of Open Call Trace Files
Performing an Abnormal Call Termination Trace
Verifying Cisco PGW 2200 Softswitch Ethernet Operation
Deleting Unnecessary Files to Increase Available Disk Space
Recovering from a Switchover Failure
Recovering from Cisco PGW 2200 Softswitch(es) Failure
Recovering from a Cisco PGW 2200 Softswitch Failure in a Simplex System
Recovering from a Single Cisco PGW 2200 Softswitch Failure in a Continuous Service System
Recovering from a Dual Cisco PGW 2200 Softswitch Failure in a Continuous Service System
Restoring Stored Configuration Data
Restoring Procedures for Cisco PGW 2200 Softswitch Software
Verifying Proper Configuration of Replication
Configuration Export Failed Due to MMDB
Measurements Are Not Being Generated
Call Detail Records Are Not Being Generated
Resolving a Failed Connection to a Peer
Rebooting Software to Modify Configuration Parameters
NTP is Not Used and Cisco PGW 2200 Softswitch is Not the Source of the CDRs
NTP is Not Used and Cisco PGW 2200 Softswitch is the Source of the CDRs
NTP is Used and Cisco PGW 2200 Softswitch is the Source of the CDRs
Securing the Cisco PGW 2200 Softswitch
Troubleshooting the Cisco PGW 2200 Softswitch Platform
Revised: July 22, 2009, OL-0800-10
This chapter describes troubleshooting methods for the Cisco PGW 2200 Softswitch platform. It includes the following sections to help you isolate system problems:
•
Troubleshooting Using Cisco PGW 2200 Softswitch Alarms
•
•
•
•
Troubleshooting Overview
This chapter uses the alarms and logs that appear at the Cisco PGW 2200 Softswitch as the basis for isolating problems within the system. You can find a complete listing of alarms and logs in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.
Typically, suggested corrective actions start with simple troubleshooting tasks and become increasingly more complex. It is easier, for example, to check LEDs and cabling than to perform a call trace. The suggested corrective actions point to other chapters in this manual, as well as to troubleshooting tools including the Cisco PGW 2200 Softswitch software, the Cisco WAN Manager, the Cisco Media Gateway Controller Node Manager (CMNM), and CiscoWorks.
Additionally, you will find examples of troubleshooting typical problems. The examples provide a logical sequence for troubleshooting that you can use as a model.
Note
The following sections contain various equipment failure scenarios for the solution, including
•
Cisco ITP-L Failure
Each Cisco IP Transfer Point LinkExtender (ITP-L) has an Reliable User Datagram Protocol (RUDP)/User Datagram Protocol (UDP)/IP connection to each Cisco PGW 2200 Softswitch for the transfer of Message Transfer Part (MTP) Level 3 (MTP3), ISDN User Part (ISUP), and Transaction Capabilities Application Part (TCAP) information. A Cisco ITP-L platform failure results in the surviving Cisco ITP-L platforms taking over the distribution of messages to the active Cisco PGW 2200 Softswitch. Cisco ITP-L platforms should be provisioned so that half of the platforms can support the entire signaling load. The result is that a Cisco ITP-L platform failure has no significant effect on call processing.
There are several Cisco ITP-L failure scenarios to consider:
•
•
•
Cisco PGW 2200 Softswitch Failure
Cisco PGW 2200 Softswitches run in active-standby mode. The call-processing application is active on only one Cisco PGW 2200 Softswitch at a time, and the application switches to the standby platform when a critical alarm occurs. The result is that Cisco PGW 2200 Softswitch failure and switchover events are invisible to the SS7 signaling network.
Cisco PGW 2200 Softswitch alarms can be configured as minor, major, or critical. Critical alarms are generated whenever any significant failure occurs. Any critical alarm causes a switchover to occur. For example, if the call engine or I/O channel controller (IOCC)-MTP in the active Cisco PGW 2200 Softswitch should fail, there is a disconnection from the process manager and a switchover to the standby Cisco PGW 2200 Softswitch.
Operating System Failure
An operating system (OS) or hardware failure in the active Cisco PGW 2200 Softswitch can also cause a switchover to the standby Cisco PGW 2200 Softswitch. The failover daemon in the standby Cisco PGW 2200 Softswitch detects the failure of the active Cisco PGW 2200 Softswitch and instructs the process manager to initiate a switchover. The standby Cisco PGW 2200 Softswitch then takes over all call-processing functions. The switchover is transparent to all the Cisco ITP-Ls.
Troubleshooting Using Cisco PGW 2200 Softswitch Alarms
The Cisco PGW 2200 Softswitch generates alarms to indicate problems with processes, routes, linksets, signaling links, and bearer channels. The Cisco PGW 2200 Softswitch Release 9 Messages Reference lists all of the Cisco PGW 2200 Softswitch alarms and logs, and provides descriptions, possible causes, and suggested actions. You can find procedures for alarms that require you to take corrective action in the "Alarm Troubleshooting Procedures" section.
The active alarm log files reside in the /opt/CiscoMGC/var/log directory. These alarm log files are archived based on the criteria set in the dmprSink.dat file. For more information on the dmprSink.dat file, see the "Configuring the Data Dumper" section on page A-2.
Troubleshooting using Cisco PGW 2200 Softswitch alarms is described in the following sections:
•
Retrieving All Active Alarms
To retrieve all active alarms, log in to the active Cisco PGW 2200 Softswitch, start a Man-Machine Language (MML) session, and enter the following command:
rtrv-almsThe system returns a response that shows all active alarms, in a format similar to the following:
Media Gateway Controller 2000-02-26 11:41:01M RTRV"LPC-01: 2000-02-26 09:16:07.806,""LPC-01:ALM=\"SCMGC MTP3 COMM FAIL\",SEV=MJ""IOCM-01: 2000-02-26 09:17:00.690,""IOCM-01:ALM=\"Config Fail\",SEV=MN""MGC1alink2: 2000-02-26 09:17:47.224,ALM=\"SC FAIL\",SEV=MJ""MGC1alink3: 2000-02-26 09:17:47.225,ALM=\"SC FAIL\",SEV=MJ""MGC1alink4: 2000-02-26 09:17:47.226,ALM=\"SC FAIL\",SEV=MJ""MGC2alink1: 2000-02-26 09:17:47.227,ALM=\"SC FAIL\",SEV=MJ""MGC2alink2: 2000-02-26 09:17:47.227,ALM=\"SC FAIL\",SEV=MJ""MGC2alink4: 2000-02-26 09:17:47.229,ALM=\"SC FAIL\",SEV=MJ""dpc5: 2000-02-26 09:17:47.271,ALM=\"PC UNAVAIL\",SEV=MJ""ls3link1: 2000-02-26 09:16:28.174,""ls3link1:ALM=\"Config Fail\",SEV=MN""ls3link1: 2000-02-26 09:18:59.844,ALM=\"SC FAIL\",SEV=MJ"Acknowledging Alarms
Acknowledging an alarm does not clear the alarm. You can still retrieve it with the rtrv-alm MML command. To acknowledge an alarm, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
ack-alm:comp:"alarmCategory"Where:
•
•
For example, to acknowledge a signaling channel fail alarm (SC FAIL) that occurred on the link MGC2alink1, enter the following command:
ack-alm:MGC2alink1:"SC FAIL"Alarm Troubleshooting Procedures
This section contains alarms that require you to take corrective action. A complete list of alarms, including those that do not require you to take corrective action, can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.
All Conn Cntl Links Fail
This alarm occurs when the MGCP session loses a heartbeat, indicating that the session is down.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step3.
Note
Step 3
If the MGCP sessions are not operating normally, return the MGCP sessions to normal operations, as described in the documentation for the affected media gateway. Otherwise, proceed to Step 3.
Step 4
All C7 IP Links Fail
This alarm occurs when communication is lost to all Cisco ITP-Ls of every configured protocol family. This defaults to a critical alarm, and causes an automatic switchover, if a standby Cisco PGW 2200 Softswitch is present.
Note
*.AllLinksFailCausesFailover. When this parameter is set to false (the default value), this alarm is not generated when the alarm condition occurs. If you want this alarm to be generated, you must set the parameter to true, using the procedure defined in the "Rebooting Software to Modify Configuration Parameters" section.
If your Cisco PGW 2200 Softswitches are in separate geographic locations, we recommend that you set the value of *AllLinksFailCausesFailover to true.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 5.
Note
Step 5
Cisco PGW 2200 Softswitch, use the prov-rtrv MML command, as described in the "Retrieving Provisioning Data" section on page 3-68. To verify the provisioning data for the Cisco ITP-Ls, use show commands, as described in the "Using the Cisco ITP-L Operating System to Check Status" section on page 6-5.If the configuration of your Cisco PGW 2200 Softswitch is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration of your Cisco ITP-Ls is incorrect, modify the provisioning data for your system. See the Cisco Signaling Link Terminal document for more information.
If the configuration of both the Cisco PGW 2200 Softswitch and the Cisco ITP-Ls are correct, then proceed to Step 6.
Step 6
All ISDN BRI IP Conn Fail
This alarm occurs when all IP connections supporting an ISDN BRI data pathway has failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the media gateway is working correctly, proceed to Step 3.
If the media gateway is not healthy, restore it using the procedures in the user documentation for the media gateway. If those procedures restore the media gateway and this alarm clears, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
If the cables are functioning properly, proceed to Step 4.
If you find bad cable(s), replace them. If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 4.
Step 4
If the switch is functioning properly, proceed to Step 5.
If the switch is not functioning properly, see the appropriate troubleshooting procedures in the documentation for the switch. If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 5
If the IP connectivity is good, proceed to Step 6.
If the IP connectivity is bad, restore the IP connectivity. If the alarm clears after the IP connectivity is restored, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If the provisioning data is correct, proceed to Step 7.
If the provisioning data is not correct, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
Step 7
All ISDN IP Conn Fail
This alarm occurs when communication is lost to all ISDN IP connections. The severity of this alarm is Critical, which causes an automatic switchover if a standby Cisco PGW 2200 Softswitch is present.
Note
This property should be set to true if your Cisco PGW 2200 Softswitches are in separate geographic locations. You can also set this parameter to true if your system is not processing SS7 calls and you want your system to perform an automatic switchover should all of the ISDN IP connections fail. To change the value of this parameter, use the procedure defined in the "Rebooting Software to Modify Configuration Parameters" section.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 2.
Note
Step 4
Cisco PGW 2200 Softswitch, use the prov-rtrv MML command, as described in the "Retrieving Provisioning Data" section on page 3-68. To verify the provisioning data for the media gateways, use show commands, as described in the associated documentation.If the configuration of your Cisco PGW 2200 Softswitch is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration of your media gateways is incorrect, modify the provisioning data for the media gateways. See the documentation associated with the media gateway for more information.
If the configuration of the Cisco PGW 2200 Softswitch and the media gateways are correct, then proceed to Step 5.
Step 5
All M3UAKEY Ack Pending
This alarm occurs when the Cisco PGW 2200 Softswitch cannot send or receive traffic for the identified SS7 signaling service associated with a Cisco ITP.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
All M3UA Assoc Fail
This alarm occurs when all M3UA associations transporting SS7 signaling have failed.
Note
*.AllLinksFailCausesFailover. When this parameter is set to false (the default value), this alarm is not generated when the alarm condition occurs. If you want this alarm to be generated, you must set the parameter to true, using the procedure defined in the "Rebooting Software to Modify Configuration Parameters" section.
If your Cisco PGW 2200 Softswitches are in separate geographic locations, we recommend that you set the value of *AllLinksFailCausesFailover to true.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If you find that the Cisco ITPs are operating normally, proceed to Step 3. Otherwise, correct the problems.
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 4.
Note
Step 4
If the provisioning data is correct, proceed to Step 6. Otherwise, proceed to Step 5.
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
All SUAKEY Ack Pending
This alarm occurs when the Cisco PGW 2200 Softswitch cannot send or receive traffic for the identified SS7 subsystem.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
All SUA Assoc Fail
This alarm occurs when all SUA associations transporting SS7 signaling have failed.
Note
*.AllLinksFailCausesFailover. When this parameter is set to false (the default value), this alarm is not generated when the alarm condition occurs. If you want this alarm to be generated, you must set the parameter to true, using the procedure defined in the "Rebooting Software to Modify Configuration Parameters" section.
If your Cisco PGW 2200 Softswitches are in separate geographic locations, we recommend that you set the value of *AllLinksFailCausesFailover to true.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If you find that the Cisco ITPs are operating normally, proceed to Step 3. Otherwise, correct the problems.
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 4.
Note
Step 4
If the provisioning data is correct, proceed to Step 6. Otherwise, proceed to Step 5.
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
ANAL: ALoopCtrExceeded
This alarm occurs when an A-number analysis operation has gone into an infinite loop. The purpose of the alarm is to limit the number of passes spent in the analysis tree to 30.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If there are infinite loops in your A-number dial plan, modify the settings in your A-number dial plan to remove the infinite loops, using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64.
If their are no infinite loops in your A-number dial plan, then proceed to Step 3.
Step 3
ANAL: ATableFail_GetDigMod
This alarm occurs when a retrieval of a modification string failed during A-number analysis. The problem occurs when the modification table is not loaded or a pointer to a nonexistent location in the modification table is given.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: ATableFail_GetResult
This alarm occurs when access to the result table failed during A-number analysis. The problem occurs if the result table is not loaded or a pointer to a nonexistent location in the result table is given.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: ATableFlt_DgtRangeError
This alarm occurs when the A-number analysis digit tree has been accessed with a digit that is out of range for the digit tree table. This alarm could occur if the system was incorrectly configured to support a base 10 dial plan, and an overdecadic digit was received from the line and passed to analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If the setting for the parameter is correct, proceed to Step 3. Otherwise, reboot your software using the procedure described in the "Rebooting Software to Modify Configuration Parameters" section.
Step 3
If the setting for the parameter is true, proceed to Step 5.
Step 4
If the documentation indicates that overdecadic digits are supported, change the setting for the *.OverdecadicDigitsEnabled XECfgParm.dat parameter to true on both hosts, using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
If the documentation indicates that overdecadic digits are not supported, proceed to Step 5.
Step 5
ANAL: BLoopCtrExceeded
The alarm occurs when a B-number analysis operation has gone into an infinite loop. The purpose of the alarm is to limit the number of passes spent in the analysis tree to 30.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If there are infinite loops in your B-number dial plan, modify the settings in your B-number dial plan to remove the infinite loops, using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64.
If their are no infinite loops in your B-number dial plan, then proceed to Step 3.
Step 3
ANAL: BNum_GetFail_SrvcTbl
This alarm occurs during B-number analysis when a screening result is encountered and an attempt to read the service table to determine the name of the service performing the screening fails. This is due to corruption of either the result table or the service table.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: BNum_MdfyBFail_ AnnounceID
This alarm occurs during B-number analysis when an announcement result is encountered and analysis is unable to replace the last 4 digits of the B-number with the announcement ID. This is commonly caused by an out-of-range announcement Id (it should be 0-9999) or a B-number less than 4 digits long.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If any of the announcement IDs are outside of the range, modify its value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: BTableFail_GetDigTree
This alarm occurs when an invalid path for B-number analysis has been given or that the B-number analysis table is not loaded. The problem occurs when an invalid path has been specified for B-number analysis or the B-number analysis table is not loaded.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: BTableFail_GetDigMod
This alarm occurs when retrieval of a modification string failed during B-number analysis. The problem occurs if the modification table is not loaded or a pointer to a nonexistent location in the modification table is given.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: BTableFail_GetResult
This alarm occurs when access to the result table failed during B-number analysis. The problem occurs if the result table is not loaded or a pointer to a nonexistent location in the result table is given.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: BTableFlt_DgtRangeError
This alarm occurs when the B-number analysis digit tree has been accessed with a digit that is out of range for the digit tree table. This alarm could occur if the system was incorrectly configured to support a base 10 dial plan, and an overdecadic digit was received from the line and passed to analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If the setting for the parameter is correct, proceed to Step 3. Otherwise, update the parameter settings in the XECfgParm.dat files using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
Step 3
If the setting for the parameter is true, proceed to Step 5.
Step 4
If the documentation indicates that overdecadic digits are supported, change the setting for the *.OverdecadicDigitsEnabled XECfgParm.dat parameter to true on each host using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
If the documentation indicates that overdecadic digits are not supported, proceed to Step 5.
Step 5
ANAL: Cause_GetFail_CauseTbl
This alarm occurs during cause analysis when the cause table is unreadable. This can be due to the cause table being corrupted, a failure in the underlying software, or the cause table being built without all the existing call context cause values.
Corrective Action
Step 1
Step 2
If the cause table is incomplete, modify its value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL:Cause_GetFail_DigModTbl
This alarm occurs during cause analysis when a B-number modification result is encountered and the digit modification string is unreadable. This can be due to the digit modification table being corrupted or an incorrect digit modification index being stored in the B-number modification result's data.
Corrective Action
Step 1
Step 2
If the information in the B-number digit modification table is incorrect, modify its value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: Cause_GetFail_InvldRsltType
This alarm occurs during cause analysis when a result is encountered that is not supported in cause analysis. This is due to corruption of the cause or location tables or the result table.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL:Cause_GetFail_LocTbl
This alarm occurs during cause analysis when the location table is unreadable. This can be due to the location table being corrupted, a failure in the underlying software, or the location table not being fully populated with all possible references from the cause table.
Corrective Action
Step 1
Step 2
If the location table does not contain all of the references, modify its value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL:Cause_GetFail_RsltTbl
This alarm occurs during cause analysis when the result table is unreadable. This can be due to the result table being corrupted, a failure in the underlying software, or the result table not being fully populated with all possible references from the cause and location tables.
Corrective Action
Step 1
Step 2
If the result table does not contain all of the references, modify its value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL:Cause_InvldRslts_CauseTbl
This alarm occurs when cause analysis successfully reads the cause table but the value returned is logically invalid. Cause analysis gets two values from the cause table: an immediate result index and a location index. The immediate result index indicates that analysis should start reading results now, but the location index indicates that another table read is required to find the correct result table index. These results are logically incompatible. Most likely this results from a failure of the underlying software or a corruption of the cause table.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: Cause_MdfyBFail_AnnounceID
This alarm occurs during cause analysis when an announcement result is encountered and analysis is unable to replace the last 4 digits of the B-number with the announcement ID. This is commonly caused by an out-of-range announcement ID (it should be 0 to 9999) or a B-number less than 4 digits long.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the announcement ID is outside of the range, modify its value using the numan-ed MML command and proceed to Step 3. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Otherwise, proceed to Step 3.
Step 3
If the affected B-number is less than 4 digits long, modify its value using the numan-ed MML command. Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Otherwise, proceed to Step 4.
Step 4
Step 5
ANAL: Cause_MdfyBFail_AppPtInvld
This alarm occurs during cause analysis when a B-number modification result is encountered and the application point (where digits are inserted) specified is beyond the end of the digit string. This is caused by an incorrect application point being specified in the result data, a corrupt result table, or incorrectly constructed cause analysis values.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If any of the application points are incorrect, modify their value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: Cause_Rte_LoopDetected
This alarm occurs during cause analysis when a route or announcement result is encountered. In these cases, the indicated route identifier is checked against a list of previously provided results. If a match is found, this alarm is raised and an error is returned to call processing. This is done to prevent calls from endlessly routing to a single route or series of routes infinitely due to cause analysis interactions.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: CustId/StartIdx Missing
This alarm occurs when the property CustGrpId is not present on the identified trunk group. This is required to find the correct place to begin analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
prov-rtrv:trnkgrpprop:name="comp_name"Where comp_name is the MML name for the affected trunk group.
For example, if you wanted to verify the properties for an trunk group called 1001, you would enter the following command:
prov-rtrv:trnkgrpprop:name="1001"If your system has been properly configured for dial plan use, the system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-06-01 10:09:47M RTRV"session=active:trnkgrpprop"/*...CustGrpId=2222...Step 3
Step 4
Note
prov-ed:trnkgrp:name="comp_name", CustGrpId=numberWhere:
•
•
Step 5
If the alarm clears, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
ANAL:DataBaseAccessFail
This alarm occurs when certain functions in generic analysis has failed. Failure of any of the following general analysis functions causes this alarm to be triggered:
•
•
•
•
•
Corrective Action
Step 1
Step 2
If correcting the setting does not clear the alarm, proceed to Step 4.
Step 3
Step 4
ANAL: Data Failure Rcvd
This alarm occurs when during analysis, a data failure is found in the external routing engine.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL:dpselection_table_fail
This alarm occurs when the correct dial plan selection could not be determined.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL:getDialplanBase_fail
This alarm occurs when the Cisco PGW 2200 Softswitch could not load or generate the dial plan.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: InvalidtrkGrpType
This alarm occurs when the analysis module has not provided a valid trunk group type. The problem occurs if the route analysis table specifies an invalid trunk group type.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
If the alarm clears, the procedure is complete. Otherwise, proceed to Step 4.
Step 4
ANAL: Prof_GetFail_DigModTbl
This alarm occurs during profile analysis when a B-number modification result is encountered and the digit modification string is unreadable. This can be due to the digit modification table being corrupted or an incorrect digit modification index being stored in the B-number modification result's data.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: Prof_GetFail_InvldRslt
This alarm occurs during profile analysis when a result is encountered that is not supported in profile analysis. This is due to corruption of either the NOA or NPI tables or the result table.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: Prof_GetFail_NOATbl
This alarm occurs during profile analysis when the NOA table is unreadable. This can be due to the NOA table being corrupted, a failure in the underlying software, or the NOA table being built without all the existing call context NOA values.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the NOA table is missing any of the existing call context NOA values, add them using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: Prof_GetFail_NOATbl_A
This alarm occurs during profile analysis when the NOA table is unreadable. This can be due either to the NOA table being corrupted, or to a failure in the underlying software.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: Prof_GetFail_NPITbl
This alarm occurs during profile analysis when the NPI table is unreadable. This can be due to the NPI table being corrupted, a failure in the underlying software, or the NPI table not being fully populated with all the possible references from the NOA table.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the NPI table is missing any of the references from the NOA table, add them using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: Prof_GetFail_NPITbl_A
This alarm occurs during profile analysis when the NPI table is unreadable. This can be due either to the NOA table being corrupted, or to a failure in the underlying software.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: Prof_GetFail_RsltTbl
This alarm occurs during profile analysis when the result table is unreadable. This can be due to the result table being corrupted, a failure in the underlying software, or the result table not being fully populated with all the possible references from the NOA or NPI tables.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the result table is missing any of the references from the NOA and NPI tables, add them using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: Prof_InvldNPAValue
This alarm occurs during profile analysis when a 7-digit B-number is encountered and the NPA property is set against the originating trunk group. An NPA string of more or less than 3 characters is invalid. This is most likely caused by data corruption.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the NPA values are incorrect, modify them using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 3.
Step 3
ANAL: Prof_InvRslts_NOATbl
This alarm occurs when profile analysis successfully reads the NOA table but the value returned is logically invalid. Profile analysis gets two values from the NOA table: an immediate result index and an NPI index. An immediate result index indicates that analysis should start reading results now but an NPI index indicates that another table read is required to find the correct result table index. These results are logically incompatible. Most likely this results from a failure of the underlying software or a corruption of the NOA table.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: Prof_InvRslts_NOATbl_A
This alarm occurs when profile analysis successfully reads the NOA table but the value returned is logically invalid. Profile analysis gets two values from the NOA table, an immediate result index and an NPI index. The immediate result index indicates that analysis should start reading results now but the NPI index indicates that another table read is required to find the correct result table index. These results are logically incompatible. Most likely, this alarm results from a failure of the underlying software or a corruption of the NOA table.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: Prof_MdfyBFail_AppPtInvld
This alarm occurs during profile analysis when a B-number modification result is encountered and the specified application point (where digits are inserted) is beyond the end of the digit string. This is caused by an incorrect application point being specified in the result data, a corrupt result table, or incorrectly constructed Profile analysis values.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If any of the application points are incorrect, modify their value using the numan-ed MML command. See the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide for more information. Save and activate your dial plan changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. Otherwise, proceed to Step 2.
Step 3
ANAL: RteStartIndexInvalid
This alarm occurs when the start index for the route analysis table is invalid.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
prov-rtrv:rtlist:"all"Step 3
Step 4
ANAL: Rte_TableHopCtrExceeded
This alarm occurs when generic analysis fails due to excessive number of routing table changes.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
a.
b.
If the import fails, proceed to Step 3. Otherwise, proceed to Step 4.
Step 3
Step 4
ANAL: RteTableFail_GetRteList
This alarm occurs when access to the route list failed. The problem occurs if the index to the route list is not valid or if the route list is not loaded.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: RteTableFail_GetTrkAttrdata
This alarm occurs when access to the trunk group attribute data table failed. The problem occurs if the index to the trunk group attribute data table is not valid or if the table is not loaded.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: RteTableFail_GetTrkGrpdata
This alarm occurs when access to the trunk group data failed. The problem occurs if the index to the trunk group data is not valid or if the trunk group data table is not loaded.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: RteTableFail_GetTrunkList
This alarm occurs when access to the trunk group list failed. The problem occurs if the index to the trunk group list is not valid or if the trunk group list is not loaded.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
ANAL: TableFail_BearerCapTable
This alarm occurs when the bearer capability table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TableFail_CondRouteDescTable
This alarm occurs when the conditional route description table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TableFail_CondRouteTable
This alarm occurs when the conditional routing table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If that procedure resolves the problem, the procedure is finished. Otherwise, proceed to Step 2.
Step 3
Step 4
ANAL: TableFail_CPCTable
This alarm occurs when the calling party category (CPC) table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TableFail_RouteHolTable
This alarm occurs when route holiday table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TableFail_PercRouteTable
This alarm occurs when the percentage route holiday table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TableFail_TMRTable
This alarm occurs when the transmission medium requirements (TMR) table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TableFail_TNSTable
This alarm occurs when the transit network selection (TNS) table could not be read during generic analysis.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
ANAL: TrunkGrpRsltCtrExceeded
This alarm occurs when the analysis module has provided the maximum number of candidate trunk groups allowed. The maximum number is 20. The purpose of the alarm is to limit the time spent searching for candidate trunk groups.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
Association Degraded
This alarm occurs when one of the destination addresses for an SCTP association has failed, but the association is still in-service (IS).
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an Association Alarm" section.
Association Fail
This alarm occurs when an SCTP association has failed due to an IP connectivity failure or an out-of-service (OOS) destination.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an Association Alarm" section.
C7LNK ALGNMT LOST
This alarm occurs when the MTP2 for the C7 link between a Cisco ITP-L and an associated APC has lost alignment.
Corrective Action
To correct the problem identified by this alarm, use the diagnostics on the affected Cisco ITP-L to determine why the link has lost alignment, as described in the "Verifying the Link Alignment Status" section on page B-6.
C7DPC CONGESTION
This alarm occurs when a link in a signaling route towards a given DPC becomes congested or when a DPC is congested and has sent a congestion indication to the Cisco PGW 2200 Softswitch.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If none of the links are out-of-service, this alarm has occurred because the DPC is congested. In this instance, corrective action is not necessary, and you must wait for the congestion condition to clear.
If any of the links are out-of-service, proceed to Step 2.
Step 3
If that does not resolve the problem, proceed to Step 3.
Step 4
C7LNK CONGESTION
This alarm occurs when an SS7 MTP2 link becomes congested and it cannot receive any more messages.
Corrective Action
If this alarm occurs repeatedly, perform the following steps to correct the problem:
Step 1
Step 2
If that clears the alarm, the procedure is complete. Otherwise, proceed to Step 2.
Step 3
If that does not resolve the problem, proceed to Step 3.
Step 4
C7LNK INHIBIT
This alarm occurs when a C7 link has been inhibited for maintenance.
Corrective Action
To correct the problem identified by this alarm, uninhibit the specified C7 link, as described in the "Setting the Service State of a C7/SS7 Link or Linkset" section, when the maintenance is complete.
C7SLTLnkCong
This alarm occurs when an SS7 link on a 4-link Cisco ITP-L is congested.
Corrective Action
If this alarm occurs repeatedly, perform the following steps to correct the problem:
Step 1
Step 2
If that does not resolve the problem, proceed to Step 3.
Step 3
Call Back Feature Insertion Failure
This alarm occurs when an attempt to insert a call back feature entry in the main memory database fails. When this insertion fails, the call back feature does not work.
Corrective Action
Contact the Cisco TAC to analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xx.
Call Back Feature Deletion Failure
This alarm occurs when an attempt to delete a call back feature entry from the main memory database fails. When this deletion fails, the call back feature does not work.
Corrective Action
Contact the Cisco TAC to analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xx.
Charge Table Access Failure
This alarm occurs when the Cisco PGW 2200 Softswitch could not access the charge table.
Corrective Action
To correct the problem identified by this alarm, check for the presence of the Charge Table Load Failure alarm, using the procedure in "Retrieving All Active Alarms" section. If this alarm is present, perform the corrective action for that alarm. Otherwise, the procedure is complete.
Charge Table Load Failure
This alarm occurs when a Cisco PGW 2200 Softswitch process is unable to load the charge table.
Corrective Action
Step 1
Step 2
prov-rtrv:charge:"all"The system responds with a list of elements in the charge table, or with an error indicating that a charge table does not exist.
If a charge table is not present, provision a charge table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
If a charge table is present, verify that the information returned is correct. If the information is correct, proceed to Step 3. Otherwise, correct the contents of the charge table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
Step 3
Comm Srvc Creation Error
This alarm occurs when an error occurred while creating or opening a communication service.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Warning
Step 5
Step 6
Step 7
Warning
If this does not resolve the alarm, proceed to Step 7.
Step 8
Config Fail
This alarm occurs when the configuration has failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If there are no logs that indicate errors in the content of your provisioning data, proceed to Step 3.
If there are logs that indicate errors in the content of your provisioning data, start a dynamic reconfiguration session to change the settings for the component(s) identified in the log message(s), as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
CTI Connection Failed
This alarm occurs when the CTI connection to the Cisco CallManager cluster has failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
You can determine the status of the Ethernet interfaces on the Cisco PGW 2200 Softswitch using the Cisco IPT Platform Administration application. See the on-line help topic for this subject for more information. You can find information on verifying the proper functioning of an Ethernet interface on the Cisco CallManager cluster in the associated documentation.
If the Ethernet connections are working correctly, proceed to Step 4. Otherwise, proceed to Step 3.
Step 3
Information on removing and replacing an Ethernet interface card on either platform can be found in the documentation that came with the platform.
Step 4
If the MGCP sessions are not operating normally, return the MGCP sessions to normal operations, as described in the documentation for the affected Cisco CallManger cluster. Otherwise, proceed to Step 5.
Step 5
CTI Version Mismatch
This alarm occurs when the CTI version of the CTI Manager component configured on Cisco PGW 2200 Softswitch is not compatible with the version on the CTI Manager.
Corrective Action
Check the version of CTI Manager and install appropriate patches on the Cisco PGW 2200 Softswitch to make it compatible with the version on CTI Manager.
Dial Plan Loading Failed
This alarm occurs when a dial plan has not loaded properly.
Corrective Action
To correct the problem identified by this alarm, verify that the dial plan file was loaded correctly, using the procedure described in "Verifying Proper Loading of a Dial Plan" section.
DISK
This alarm occurs when the system disk is running out of space.
Corrective Action
To correct the problem identified by this alarm, delete any unnecessary files from your Cisco PGW 2200 Softswitch, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section.
EISUP: Unexpected Msg/Par
This alarm occurs when the EISUP module has received an unsupported message or parameter. This alarm is most likely to occur when the local EISUP version is older than the EISUP version used by the Cisco PGW 2200 Softswitch or Cisco H.323 Signaling Interface (HSI) on the other end.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
The steps required to upgrade your Cisco PGW 2200 Softswitch software are found in the Cisco PGW 2200 Softswitch Release 9 Software Installation and Configuration Guide.
If upgrading the Cisco PGW 2200 Softswitch software clears the alarm, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
ENGINE CONFIG FAIL
This alarm occurs when a component in the engine configuration has failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If there are logs that indicate a failed component, proceed to Step 2.
If there are no logs that indicate a failed component, proceed to Step 3.
Step 3
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 3.
Step 4
FAIL
This alarm occurs when the component referenced in the alarm has failed. The failure may be service affecting, in which case other alarms are raised.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the component identified in the alarm text is a piece of system hardware, proceed to Step 3.
Step 3
Step 4
Step 5
Warning
Step 6
Step 7
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 8.
Step 8
Step 9
FailoverPeerLost
This alarm occurs when the failover daemon on the standby Cisco PGW 2200 Softswitch is not reachable.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 3.
Note
Step 3
FailoverPeerOOS
This alarm occurs when the failover daemon goes out-of-service in the standby Cisco PGW 2200 Softswitch.
Corrective Action
To correct the problem identified by this alarm, check the alarms on the standby Cisco PGW 2200 Softswitch, using the procedure in the "Retrieving All Active Alarms" section, and resolve those alarms.
FAIL REMOTE STANDBY
This alarm occurs on the active Cisco PGW 2200 Softswitch when a synchronization operation between the active and standby Cisco PGW 2200 Softswitches fails. This alarm is automatically cleared if a successful synchronization operation occurs after the failure. As a result, the Standby Warm Start alarm is triggered. See the "Standby Warm Start" section for more information.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the standby Cisco PGW 2200 Softswitch is in the standby platform state, proceed to Step 3. Otherwise, proceed to Step 4.
Step 3
Step 4
Step 5
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
FORCE NODE RESTART
This alarm occurs on the standby Cisco PGW 2200 Softswitch when a new SS7 IOCC is added to the configuration of the system. This alarm causes the Cisco PGW 2200 Softswitch software on the standby Cisco PGW 2200 Softswitch to be rebooted. This alarm does not affect the active Cisco PGW 2200 Softswitch.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the standby Cisco PGW 2200 Softswitch is in the standby platform state, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
Gen Fail
This alarm occurs when a failure has occurred due to resource exhaustion or configuration problems, including:
•
•
•
•
•
Log messages in the active system log file indicate the nature of the failure. For the majority of the failures, this alarm is informational and no user action is required. When this alarm is generated because an IPC file cannot be opened, you must take corrective action.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If there are no logs that indicate that an IPC file cannot be opened, no further action is required.
If there are logs that indicate that an IPC file cannot be opened, proceed to Step 3.
Step 3
Step 4
Step 5
Warning
Step 6
Step 7
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 8.
Step 8
Holiday Table Access Failure
This alarm occurs when the Cisco PGW 2200 Softswitch could not access the holiday table.
Corrective Action
To correct the problem identified by this alarm, check for the presence of the Holiday Table Load Failure alarm, using the procedure in "Retrieving All Active Alarms" section. If this alarm is present, perform the corrective action for that alarm. Otherwise, the procedure is complete.
Holiday Table Load Failure
This alarm occurs when a Cisco PGW 2200 Softswitch process is unable to load the holiday table.
Corrective Action
Step 1
Step 2
prov-rtrv:holiday:"all"The system responds with a list of elements in the holiday table, or with an error indicating that a holiday table does not exist.
If a holiday table is not present, provision a holiday table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
If a holiday table is present, verify that the information returned is correct. If the information is correct, proceed to Step 2. Otherwise, correct the contents of the holiday table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
Step 3
INVALID M3UA RC
This alarm occurs when an M3UA message is received from the identified Cisco ITP with a routing context that has not been provisioned on the Cisco PGW 2200 Softswitch.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
INVALID SUA RC
This alarm occurs when there is a mismatch between SUA routing keys defined on the Cisco PGW 2200 Softswitch and the signaling gateway.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 5.
Step 6
Invalid Virtual_IP_Addr
This alarm occurs when the configured virtual IP address is not part of the networks associated with the IP addresses set for the IP_Addr1 or IP_Addr2 parameters in the XECfgParm.dat file.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If the setting for the parameter is correct, proceed to Step 3. Otherwise, reboot your software using the procedure described in the "Rebooting Software to Modify Configuration Parameters" section.
Step 3
IP CONNECTION FAILED
This alarm occurs when the Cisco PGW 2200 Softswitch loses network (IP) connectivity to a Cisco ITP-L. This alarm is generated for each SS7 link associated with the affected Cisco ITP-L.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the affected Cisco ITP-L is not up and running, start it using the procedure in the "Cisco SS7 Interface Startup Procedure" section on page 2-3. If this does not resolve the problem, replace the affected Cisco ITP-L as described in the "Replacing a Cisco ITP-L" section on page 6-6.
If the affected Cisco ITP-L is up and running, proceed to Step 3.
Step 3
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 4.
Note
Step 4
IP RTE CONF FAIL
This alarm occurs when an IP route cannot access the local interface defined by its IP address parameter.
Corrective Action
Collect system data as described in the "Collecting System Data for Cisco TAC" section and contact the Cisco TAC to further analyze the problem and determine a solution. For more information about contacting the Cisco TAC, see the "Obtaining Documentation and Submitting a Service Request" section on page xx.
IP RTE FAIL
This alarm occurs when an IP route is in the OOS state with a cause other than off-duty or commanded out-of-service.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
ifconfig -aThe system returns a response indicating the IP addresses of your local interfaces.
Step 3
If the settings for the local IP addresses are not the same, proceed to Step 4.
If the settings for the local IP addresses are the same, proceed to Step 12.
Step 4
cd /opt/CiscoMGC/etcStep 5
Step 6
Step 7
Step 8
/etc/init.d/CiscoMGC stop
Note
Step 9
/etc/init.d/CiscoMGC startStep 10
sw-over::confirmStep 11
If the problem has not been resolved after you have completed those steps, proceed to Step 12.
Step 12
ISUP: COT Failure
This alarm occurs when a COT message was received indicating a failed continuity test.
Corrective Action
To correct the problem identified by this alarm, run a manual COT test, as described in the "Running a Manual Continuity Test" section.
License server unreachable
This alarm appears if the license server is unavailable. The Cisco PGW 2200 Softswitch looks at the local license files to retrieve the configuration time TDM ports/ the run time license information. At the same time, a timer is started.
If the license server is still unreachable after 1 week, the license number will be half of the license number in license files.
If the license server is still unreachable after 8 weeks, the license number will be the number of demo licenses.
Corrective Action
If you see the license server unreachable alarm, you can use the rtrv-lics output to determine how many days license server has been unreachable.
Follow these steps to resolve this problem.
Step 1
Step 2
a.
b.
c.
LIF BER
This alarm occurs when an excessive bit error ratio is detected from a frame alignment signal. This might be caused by any source of electrical noise; for example, degraded transmission line, degraded line connectors, high-voltage electrical source located in proximity of line.
Corrective Action
To correct the problem identified by this alarm, isolate the source by testing the connections and transmission line for the identified component. When you have identified the source, resolve as necessary.
LIF FAIL
This alarm occurs when a local Ethernet interface has failed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Note
Step 1
Step 2
Note
If a GEN_ERR_IPINTF_FAIL log message is found, proceed to Step 3. Otherwise, proceed to Step 7.
Step 3
If the cause in the log message is "Admin Down", the interface was taken down using an administrative command. Proceed to Step 4.
If the cause in the log message is "Link Down", the Ethernet path has failed. Proceed to Step 5.
Step 4
ifconfig interface upWhere interface is the IP address of the affected interface.
If the interface is restored and is working fine, the procedure is complete. Otherwise, proceed to Step 7.
Step 5
If the cable is working correctly, proceed to Step 6.
If the cable is not working correctly, replace it. If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If the Ethernet switch is working correctly, proceed to Step 7.
If the Ethernet switch is not working correctly, trouble shoot the problem as indicated in the documentation for your switch. If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
LIF LOF
This alarm occurs when a loss of T1/E1 framing has been detected on the LIF. The physical line has a signal but has lost the framing pattern.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the framing formats are different, change the framing format on the port to the other framing format. Otherwise, proceed to Step 3. If the alarm does not clear, proceed to Step 3.
Step 3
Step 4
If you find evidence of a bad line, perform loopback tests on the line to isolate the problem. Otherwise, proceed to Step 5. Once you have isolated the problem, resolve as necessary. If the alarm does not clear, proceed to Step 5.
Step 5
LIF LOS
This alarm occurs when the transmitted signal is lost in the T1/E1. The receiving end does not receive the signal. The physical line might have a break in it.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the cable was built on-site, check the cable connectors. A reversal of transmit and receive pairs or an open receive pair can cause this condition.
If the cable connections appear correct, then proceed to Step 3.
Step 3
If the alarm does not clear, then proceed to Step 3.
Step 4
LIF SES
This alarm occurs when the LIF is automatically set to the out-of-service state because of severely errored seconds. The TDM line has a large amount of noise, causing an error rate greater than 10-3. Framing and signal are within tolerance. This indicates a degraded but functioning line.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
LIF YELLOW
This alarm occurs when the receiving end is reporting a loss of the transmitted signal. This is reported for T1/E1 facilities only.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If no alarms are produced, proceed to Step 3.
If alarms are produced, the port is causing the error. Replace the hardware component associated with the port. See the associated media gateway documentation for more information on replacing the component.
Step 3
If you find a wiring problem, replace the cable. If that does not clear the alarm, proceed to Step 4.
If you do not find a wiring problem, then proceed to Step 4.
Step 4
If that does not clear the alarm, proceed to Step 5.
Step 5
LIF: IDLE CHANGE
This alarm occurs when the physical line has failed because its cable is broken or not plugged in. This is reported for V.35 facilities only.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If you find a problem with a V.35 cable, replace the cable. If that does not correct the problem, proceed to Step 3.
If you do not find a problem with the V.35 cables, proceed to Step 3.
Step 3
LIF: LOST CD
This alarm occurs when the physical line has failed because its cable is broken or not plugged in. This is reported for V.35 facilities only.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If you find a problem with a V.35 cable, replace the cable. If that does not correct the problem, proceed to Step 3.
If you do not find a problem with the V.35 cables, proceed to Step 3.
Step 3
LIF: LOST CTS
This alarm occurs when the physical line has failed because its cable is broken or not plugged in. This is reported for V.35 facilities only.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If you find a problem with a V.35 cable, replace the cable. If that does not correct the problem, proceed to Step 3.
If you do not find a problem with the V.35 cables, proceed to Step 3.
Step 3
M3UAKEY Ack Pending
This alarm occurs when the Cisco PGW 2200 Softswitch cannot send or receive traffic for the identified SS7 signaling service via the Cisco ITP that has not acknowledged the M3UAKEY.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
MeterPulseTariff Table Load Failure
This alarm occurs when the Cisco PGW 2200 Softswitch failed to load the meter pulse tariff table.
Corrective Action
Step 1
Step 2
prov-rtrv:metertariff:"all"The system responds with a list of elements in the meter pulse tariff table, or with an error indicating that the meter pulse tariff table does not exist.
If the meter pulse tariff table is not present, provision a meter pulse tariff table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
If a meter pulse tariff table is present, verify that the information returned is correct. If the information is correct, proceed to Step 3. Otherwise, correct the contents of the meter pulse tariff table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
Step 3
MMDB: Database unavailable
This alarm occurs when the main memory database is currently unavailable to provide any services. Recovery is attempted and the alarm clears when or if the database becomes available.
Corrective Action
To correct the problem identified by this alarm, delete any unnecessary files from your Cisco PGW 2200 Softswitch, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section.
MMDB: Database cause failover
This alarm occurs when the main memory database is currently unavailable on a redundant system and is indicating that the system should failover. Recovery is attempted and the alarm clears when or if the database becomes available.
Corrective Action
To correct the problem identified by this alarm, delete any unnecessary files from your standby
Cisco PGW 2200 Softswitch, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section.MMDB: Database nearly full
This alarm occurs when the main memory database has detected that allocated resources for data storage are nearly all utilized.
Corrective Action
To correct the problem identified by this alarm, delete any unnecessary files from your Cisco PGW 2200 Softswitch, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section.
NAS: AuditResponse Failure
This alarm occurs when the identified media gateway fails to send a RESYNC RESP message back to the Cisco PGW 2200 Softswitch within the audit time interval.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the affected media gateway is in-service, proceed to Step 3. Otherwise, proceed to Step 4.
Step 3
If that does not resolve the problem, proceed to Step 4.
Step 4
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 5.
Note
Step 5
NAS: CommsFailure
This alarm occurs when the Cisco PGW 2200 Softswitch cannot communicate with the identified media gateway.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the affected media gateway is not up and running, restore it to service. See the documentation for the media gateway for more information.
If the affected media gateway is up and running, proceed to Step 3.
Step 3
Note
If the configuration of your Cisco PGW 2200 Softswitch is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration of the affected media gateway is incorrect, modify the provisioning data for your system. See the documentation for the media gateway for more information.
If the configuration of both the Cisco PGW 2200 Softswitch and the affected media gateway are correct, then proceed to Step 3.
Step 4
NAS: ResourceFailure
This alarm occurs when a continuity test (COT) has not been acknowledged by the indicated media gateway.
Corrective Action
To correct the problem identified by this alarm, run a manual COT on the indicated media gateway, as described in the Running a Manual Continuity Test.
OLC: Leg1chanSeizedUnpackError
This alarm occurs when an Seized Channel (CRCX) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OLC: Leg1chanModifiedUnpackError
This alarm occurs when an Modify Channel (MDCX) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OLC: Leg1chanDeletedUnpackError
This alarm occurs when a Delete Channel (DLCX) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OLC: Leg1notifyUnpackError
This alarm occurs when a Notify (NTFY) message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OLC: Leg1deleteChanUnpackError
This alarm occurs when a Delete Channel (DLCX) message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OLC: Leg1notifyRequestAckUnpackError
This alarm occurs when an Request Notify (RQNT) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OLC: Leg1chanOpsFailed
This alarm occurs when the Cisco PGW 2200 Softswitch has detected an internal error or a media gateway related problem.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
OOS TRAFFIC RE-ROUTE
This alarm occurs when the traffic channels (bearer channels, IP network) on one side of the Cisco PGW 2200 Softswitch have been lost, causing the Cisco PGW 2200 Softswitch to reroute channels away from the affected component. This is generally due to a network or equipment failure, but might be due to a provisioning failure.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If resolving those alarms does not clear this alarm, proceed to Step 3.
Step 3
Note
If the configuration of your Cisco PGW 2200 Softswitch is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration of the affected media gateway is incorrect, modify the provisioning data for your system. See the documentation for the media gateway for more information.
If the configuration of both the Cisco PGW 2200 Softswitch and the affected media gateway are correct, then proceed to Step 4.
Step 4
OverloadHeavy
This alarm occurs when the system has reached the threshold for overload level 3. The system performs an automatic switchover operation. If the call rejection percentage setting for overload level 3 is unchanged from its default value, all new calls are rejected until the abate threshold for overload level 3 is reached. This alarm is automatically cleared at that time. For more information, see the "Managing Automatic Congestion Control" section on page 3-76.
Corrective Action
If this alarm is caused by a rare spike in traffic, corrective action is not necessary. If this alarm occurs regularly, you should ensure that your links and routes are properly configured for load sharing, as described in the "SS7 Load Sharing Malfunction" section, and re-route some of your traffic to other Cisco PGW 2200 Softswitches.
Note
OverloadMedium
This alarm occurs when the system has reached the threshold for overload level 2. A percentage of new calls, based on the call rejection percentage setting for overload level 2, are rejected until the abate threshold for overload level 2 is reached. This alarm is automatically cleared at that time. For more information, see the "Managing Automatic Congestion Control" section on page 3-76.
Corrective Action
If this alarm is caused by a rare spike in traffic, corrective action is not necessary. If this alarm occurs regularly, you should ensure that your links and routes are properly configured for load sharing, as described in the "SS7 Load Sharing Malfunction" section, and re-route some of your traffic to other Cisco PGW 2200 Softswitches.
Note
OverloadLight
This alarm occurs when the system has reached the threshold for overload level 1. A percentage of new calls, based on the call rejection percentage setting for overload level 1, are rejected until the abate threshold for overload level 1 is reached. This alarm is automatically cleared at that time. For more information, see the "Managing Automatic Congestion Control" section on page 3-76.
Corrective Action
If this alarm is caused by a rare spike in traffic, corrective action is not necessary. If this alarm occurs regularly, you should ensure that your links and routes are properly configured for load sharing, as described in the "SS7 Load Sharing Malfunction" section, and re-route some of your traffic to other Cisco PGW 2200 Softswitches.
Note
OverResIncomingThreshold
This alarm occurs when the percentage of idle CICs in a trunk group is less than or equal to the configured threshold.
Corrective Action
This alarm may occur occasionally during periods of congestion. However, if this alarm occurs repeatedly, you may need to adjust the value of the parameter that controls the percentage of idle CICs for the affected trunk group. To do this, perform the following steps:
Step 1
Step 2
prov-rtrv:rttrnkgrp:name="trnkgrp_name"Where trnkgrp_name is the name of the affected trunk group.
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2002-09-20 15:38:02.892 ESTM RTRV"session=NOA_SPAIN:rttrnkgrp"/*name type reattempts queuing cutThrough resIncomingPerc---------- ---- ---------- ------- ---------- ----------111 1 2 120 2 0*/The parameter, ResIncomingPerc, controls the percentage of idle CICs for the trunk group. In the above example the value is 0.
Step 3
Step 4
prov-ed:rttrnkgrp:name="1000", resIncomingPerc="30"
Note
Step 5
If the alarm clears, the procedure is complete. Otherwse, proceed to Step 6.
Step 6
PC UNAVAIL
This alarm occurs when a destination point code (DPC) is unavailable. This can be due to a network failure causing the DPC to become isolated, a local failure equipment failure causing a loss of connectivity, or a local provisioning failure causing the DPC or routes to it to be configured improperly.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If resolving those alarms does not clear this alarm, proceed to Step 3.
Step 3
If the configuration data associated with the DPC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration data associated with the DPC is correct, then proceed to Step 4.
Step 4
Peer IP Links Failure
This alarm occurs when the IP links to the peer Cisco PGW 2200 Softswitch are removed or down.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 3.
Note
Step 3
PEER LINK A FAILURE
This alarm occurs either because a communication path between peer modules was lost or a peer module has stopped communicating.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving a Failed Connection to a Peer" section.
PEER LINK B FAILURE
This alarm occurs either because a communication path between peer modules was lost or a peer module has stopped communicating.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving a Failed Connection to a Peer" section.
PEER MODULE FAILURE
This alarm occurs when communications to a peer module are lost, indicating failure.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving a Failed Connection to a Peer" section.
POM INACTIVITY TIMEOUT
This alarm occurs when the current provisioning session had been idle for 20 minutes without input any provisioning commands. If there is still no provisioning activity within the next five minutes, the session is terminated.
Corrective Action
To correct the problem identified by this alarm, enter some provisioning MML commands, or stop the provisioning session as described in the "Saving and Activating your Provisioning Changes" section on page 3-64. For more information about provisioning your Cisco PGW 2200 Softswitch, see the Cisco PGW 2200 Softswitch Release 9.8 Provisioning Guide.
POM SESSION TERMINATE
This alarm occurs when a provisioning session is terminated. Any additional provisioning commands are not accepted.
Corrective Action
If you want to restart your provisioning session, perform the steps listed in the "Starting a Provisioning Session" section on page 3-63, using the same source version set equal to the destination version name.
POM: DynamicReconfiguration
This alarm occurs when a dynamic reconfiguration procedure is started. It is cleared once the dynamic reconfiguration is successfully completed. See the "Invoking Dynamic Reconfiguration" section on page 3-65 for more information.
Corrective Action
If necessary, you can complete the dynamic reconfiguration procedure, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
POM: PEER_SYNC_ERR
This alarm occurs when the standby Cisco PGW 2200 Softswitch attempts to synchronize the contents of its configuration library while a provisioning session is in progress on the active Cisco PGW 2200 Softswitch.
Corrective Action
To correct the problem identified by this alarm, either stop the provisioning session as described in the "Ending a Provisioning Session Without Activating your Changes" section on page 3-65, or save and activate your changes as described in the "Saving and Activating your Provisioning Changes" section on page 3-64.
PRI: B-Channel not available
This alarm occurs when the Cisco PGW 2200 Softswitch has received a PRI "setup" message, and the requested B channel is not available or cannot be allocated to the call.
Corrective Action
If necessary, you can save and activate your provisioning session, as described in the "Saving and Activating your Provisioning Changes" section on page 3-64.
ProcM No Response
The process manager is not responding to state information changes from the failover daemon.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Warning
Step 5
Step 6
If this does not resolve the problem, proceed to Step 7.
Step 7
ProtocolFileMissing
This alarm occurs when the protocol file(s) associated with your system configuration have not been installed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If there are logs that indicate that a *.mdo or *.so file cannot be found, proceed to Step 3.
If there are no logs that indicate that an IPC file cannot be opened, proceed to Step 5.
Step 3
Step 4
http://www.cisco.com/public/sw-center/sw-voice.shmtl
Step 5
Step 6
REPL: all connections failure
This alarm occurs when the Cisco PGW 2200 Softswitch cannot establish communication to the peer Cisco PGW 2200 Softswitch.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Note
If an element of the Ethernet connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 3.
Note
Step 3
If that does not resolve the alarm, proceed to Step 4.
Step 4
RSET CONFIG FAIL
This alarm occurs when the provisioning data for the SS7 route set to a DPC has invalid or incompatible parameter values. This does not occur due to a mismatch between the network topology and the DPC data.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the configuration data associated with the DPC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration data associated with the DPC is correct, then proceed to Step 3.
Step 3
SC CONFIG FAIL
This alarm occurs when the provisioning parameters for the data link layer of a signaling channel are inconsistent or invalid. The signaling channel may already be provisioned. The configuration file might be corrupted and cannot be read by the system.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
If that does not resolve the problem, proceed to Step 8.
Step 8
SC FAIL
This alarm occurs when the signaling channel is down and unable to process traffic. As a result, the signaling channel is failing to negotiate a D-channel session, automatic restarts are not able to recover the session, and the data link-layer has failed. This can occur when SS7 SLTM/SLTA fails or when a PRI D-channel fails.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the near-end or far-end data link terminations are not operating, fix as necessary.
If the near-end and far-end data link terminations are operating, proceed to Step 3.
Step 3
If the configuration data for the signaling channel is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration data for the signaling channel is correct, then proceed to Step 4.
Step 4
SC M-OOS
This alarm occurs when a signaling channel has been manually taken out of service.
Corrective Action
To correct the problem identified by this alarm, restore the affected signaling channel to the in-service state, using the appropriate procedure. Procedure for modifying the state of signaling channels are described in the "Setting the Service State of a C7/SS7 Link or Linkset" section, the "Setting the Service State of an IP Link" section, and the "Setting the Service State of a D-channel" section.
SG Node Interface Fail
This alarm occurs when all IP connections to a signaling gateway (SG) node are out of service.
Corrective Action
To correct the problem identified by this alarm, check the configuration of the SG node and, if necessary, configure it to connect to the Cisco PGW 2200 Softswitch. See the Tekelec documentation for more information.
SG Pair Interface Fail
This alarm occurs when all IP connections to both SGs of a pair or a single non-paired SG are out of service.
Corrective Action
To correct the problem identified by this alarm, check the configuration of the affected SG and, if necessary, configure it to connect to the peer SG. See the Tekelec documentation for more information.
SIP: DNS CACHE NEARLY FULL
This alarm occurs when the domain name service (DNS) cache is nearly full.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
prov-rtrv:dnsparam:"all"The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 1999-12-30 14:27:48M RTRV"session=test:dnsparam"/**.DnsCacheSize = 500*.DnsKeepAlive = 30*.DnsPolicy = HIERARCHY*.DnsQueryTimeout = 1000*.DnsServer1 = 172.22.1.1*.DnsServer2 = 143.83.1.1*DnsTTL = 3600*/Make note of the value of the *.DnsCacheSize parameter.
Step 3
If this alarm occurs repeatedly despite increasing the size of the cache, then proceed to Step 4.
Step 4
SIP: DNS SERVICE OOS
This alarm occurs when the DNS servers are not responding to queries. The DNS servers may be out of service or the access to them is lost.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
prov-rtrv:dnsparam:"all"The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 1999-12-30 14:27:48M RTRV"session=test:dnsparam"/**.DnsCacheSize = 500*.DnsKeepAlive = 30*.DnsPolicy = HIERARCHY*.DnsQueryTimeout = 1000*.DnsServer1 = 172.22.1.1*.DnsServer2 = 143.83.1.1*DnsTTL = 3600*/Make note of the value of the *.DnsServer1 and *.DnsServer2 parameters.
Step 3
If this alarm occurs repeatedly despite selecting new DNS servers, then proceed to Step 4.
Step 4
SIP: OOS
This alarm occurs when an IP link used by the SIP is out of service.
Corrective Action
To correct the problem identified by this alarm, attempt to restore the IP link to service using the procedure described in the "Setting the Service State of an IP Link" section.
SIP Service Fail Over
This alarm is caused by the failure of switch interfaces, due to either physical failure or administrative shut down.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the failure is caused by a physical failure, proceed to Step 2.
If the failure is caused by an administrative shutdown, check for this alarm again once the interface has been restored. If this alarm is still active, proceed to Step 3.
Step 3
Note
If an element of the switch connection (such as a cable or an Ethernet interface card) is not working properly, replace it. Otherwise, proceed to Step 4.
Note
Step 4
Standby Warm Start
This alarm occurs on the active Cisco PGW 2200 Softswitch when a synchronization operation between the active and standby Cisco PGW 2200 Softswitches begins. This alarm clears automatically when the synchronization operation is completed. This alarm also occurs on the standby Cisco PGW 2200 Softswitch when the prov-sync MML command is entered on the active Cisco PGW 2200 Softswitch. In that case, the alarm clears automatically when the synchronization of provisioning data is complete. If a synchronization operation should fail, this alarm is automatically cleared and a FAIL REMOTE STANDBY alarm is generated. See the "FAIL REMOTE STANDBY" section for more information.
Corrective Action
Corrective action is only required when the alarm does not clear automatically. If this alarm does not clear automatically, verify that the pom.dataSync parameter in the XECfgParm.dat is set to true on each host, using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
SS7 RTE KEY FAIL
This alarm occurs when one or more routing keys for an SS7 signaling service associated with an SG has failed; the signaling service cannot receive some ISUP messages. The maximum number of routing keys supported by the associated SG might have been exceeded.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the configuration data associated with the bearer channels is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65. If this clears the alarm, the procedure is complete. Otherwise, proceed to Step 3.
If the configuration data associated with the bearer channels is correct, then proceed to Step 3.
Step 3
Step 4
For example, if 990 CICs and 10 SS7 subsystems were associated with the SG, then 1000 routing keys would be in use by the Cisco PGW 2200 Softswitch.
Step 5
Step 6
If this clears the alarm, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
SS7 SIG SRVC CONFIG FAIL
This alarm occurs when the identified SS7 signaling service associated with an SG is not configured correctly.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
prov-rtrv:SS7SGPath:name="sig_srv"Where sig_srv is the MML name of the identified SS7 signaling service.
The system returns a response that lists all of the properties associated with the selected SS7 signaling service.
Step 3
If it is correct, proceed to Step 5. Otherwise, proceed to Step 4.
Step 4
If this clears the alarm, the procedure is complete. Otherwise, proceed to Step 5.
Step 5
SS7 SIG SRVC UNAVAIL
The identified SS7 signaling service is unavailable.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the state is OOS,FLD, the signaling service is out of service due to failure of the MTP3 transport. Perform a prov-rtrv:SS7PATH or a prov-rtrv:SS7SUBSYS on the signaling service object.
a.
b.
If the state is OOS,FLD&UPU, the signaling service is out of service due to failure of the user part layer at the destination. This remote destination should be examined to determine the cause of the failure.
Step 3
SSN FAIL
This alarm occurs when the SCP located by subsystem number (SSN) is not available.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If the configuration data associated with the SSN is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65.
If the configuration data associated with the SSN is correct, then proceed to Step 3.
Step 3
If the SCP is not reachable, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section on page 3-65, and reprovision your data for an SCP that is reachable, or remove the SSN and its associated data.
If the SCP is reachable, proceed to Step 4.
Step 4
SUAKEY Ack Pending
This alarm occurs when the Cisco PGW 2200 Softswitch cannot send or receive traffic for the identified SS7 subsystem via the Cisco ITP that has not acknowledged the SUAKEY.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If this corrects the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
SUPPORT FAILED
This alarm occurs when the identified entity cannot provide service because a supporting entity is not providing service. The supporting entity may be hardware or software.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
If the alarms clear, the procedure is complete. Otherwise, proceed to Step 4.
Step 4
SwitchoverFail
This alarm occurs when a switchover operation from the active Cisco PGW 2200 Softswitch to the standby Cisco PGW 2200 Softswitch has failed.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Recovering from a Switchover Failure" section.
TALI: Invalid Protocol Version
This alarm occurs when the software on the associated SG does not support TALI version 3.0.
Corrective Action
To correct the problem identified by this alarm, you must upgrade the software on the identified SG to support TALI version 3.0. See your Tekelec documentation for information on upgrading your SG software.
TALI: Invalid State
This alarm occurs when the associated SG is not in the allowed connection state.
Corrective Action
To correct the problem identified by this alarm, you must set the connection state of the identified SG to allowed. See your Tekelec documentation for more information.
Tariff Table Access Failure
This alarm occurs when the Cisco PGW 2200 Softswitch could not access the tariff table.
Corrective Action
To correct the problem identified by this alarm, check for the presence of the Tariff Table Load Failure alarm, using the procedure in "Retrieving All Active Alarms" section. If this alarm is present, perform the corrective action for that alarm. Otherwise, the procedure is complete.
Tariff Table Load Failure
This alarm occurs when a Cisco PGW 2200 Softswitch process is unable to load the tariff table.
Corrective Action
Step 1
Step 2
prov-rtrv:tariff:"all"The system responds with a list of elements in the tariff table, or with an error indicating that a tariff table does not exist.
If a tariff table is not present, provision a tariff table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
If a tariff table is present, verify that the information returned is correct. If the information is correct, proceed to Step 3. Otherwise, correct the contents of the tariff table, as described in the Cisco PGW 2200 Softswitch Release 9.8 Dial Plan Guide.
Step 3
TLC: Leg2chanSeizedUnpackError
This alarm occurs when a Seize Channel (CRCX) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
TLC: Leg2chanModifiedUnpackError
This alarm occurs when a Modify Channel (MDCX) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
TLC: Leg2chanDeletedUnpackError
This alarm occurs when a Delete Channel (DLCX) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
TLC: Leg2notifyUnpackError
This alarm occurs when a Notify (NTFY) message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
TLC: Leg2deleteChanUnpackError
This alarm occurs when a Delete Channel (DLCX) message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
TLC: Leg2notifyRequestAckUnpackError
This alarm occurs when an Request Notify (RQNT) acknowledge message received from the media gateway could not be unpacked.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
TLC: Leg2chanOpFailed
This alarm occurs when the Cisco PGW 2200 Softswitch has detected an internal error or a media gateway related problem.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
UCM: CCodeModfailed
This alarm occurs when the country code prefix could not be applied or removed.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
If country code prefix processing should not be performed, proceed to Step 4.
If country code prefix processing should be performed, proceed to Step 8.
Step 4
numan-rtrv:resulttable:custgrpid=T002If the result set does have a result type of CC_DIG configured, use the numan-dlt MML command to remove the CC_DIG result set. For example:
numan-dlt:resulttable:custgrpid="T002", name="result46", resulttype="CC_DIG"Otherwise, proceed to Step 5.
Step 5
prov-rtrv:trnkgrpprop:name="trnkgrp1"If the BDigitCCPrefix property in the associated trunk group is not set to 0, use the prov-ed MML command to modify the value of the property. For example:
prov-ed:trnkgrp:name="trnkgrp1", BDigitCCPrefix=0Otherwise, proceed to Step 6.
Step 6
prov-rtrv:trnkgrpprop:name="trnkgrp1"If the BDigitCCrm property in the associated trunk group is not set to NULL, use the prov-ed MML command to modify the value of the property. For example:
prov-ed:trnkgrp:name="trnkgrp1", BDigitCCrm=nullOtherwise, proceed to Step 7.
Step 7
numan-rtrv:digmodstring:custgrpid="T002"If the associated B-number analysis configuration allows country code digit removal, use the numan-dlt MML command to remove the digit string. For example:
numan-dlt:digmodstring:custgrpid="T002", name="ccspain"Otherwise, proceed to Step 13.
Step 8
If the log indicates that the country code prefix could not be applied, proceed to Step 9.
If the log indicates that the country code prefix could not be removed, proceed to Step 11.
Step 9
If the result set does not have a result type of CC_DIG configured, use the numan-ed MML command to add the CC_DIG result set. For example:
numan-ed:resulttable:custgrpid="T002", name="result46", resulttype="CC_DIG", dw1=ccspain, setname="setname1"Otherwise, proceed to Step 10.
Step 10
prov-rtrv:trnkgrpprop:name="trnkgrp1"If the BDigitCCPrefix property in the associated trunk group is not set to 1, use the prov-ed MML command to modify the value of the property. For example:
prov-ed:trnkgrp:name="trnkgrp1", BDigitCCPrefix=1Otherwise, proceed to Step 13.
Step 11
prov-rtrv:trnkgrpprop:name="trnkgrp1"If the BDigitCCrm property in the associated trunk group is not set to the correct number string, use the prov-ed MML command to modify the value of the property. For example:
prov-ed:trnkgrp:name="trnkgrp1", BDigitCCrm=34Otherwise, proceed to Step 12.
Step 12
numan-rtrv:digmodstring:custgrpid="T002"If the associated B-number analysis configuration does not allow for country code digit removal, use the numan-ed MML command to modify of the setting. For example:
numan-ed:digmodstring:custgrpid="T002", name="ccspain", digstring="34"Otherwise, proceed to Step 13.
Step 13
If that procedure resolves the problem, the procedure is finished. Otherwise, proceed to Step 13.
Step 14
Step 15
UCM: MGCPDIALAuthFail
This alarm occurs when an MGCP dial call fails after an automatic switchover takes place, due to the expiration of a timer waiting for a Notify message from the associated media gateway.
Note
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5. Otherwise, fix the identified IP path problems.Step 5
Step 6
Virtual_IP_Addr Mismatch
This alarm occurs when the virtual IP addresses configured in XECfgParm.dat files on the active and the standby Cisco PGW 2200 Softswitches do not match.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Step 3
If the parameter values match, proceed to Step 10. Otherwise, proceed to Step 4.
Step 4
cd /opt/CiscoMGC/etcStep 5
Step 6
Step 7
Step 8
Step 9
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 10.
Step 10
Wrong IP Path
This alarm occurs when an IP route or local interface associated with the identified component cannot be used. This can happen when one of the following occurs:
•
•
•
•
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
netstat -rnvThe system returns a response similar to the following:
IRE Table: IPv4 Destination Mask Gateway Device Flags ----------------- ---------------- -------------- ------ ----- 10.82.80.0 255.255.255.0 10.82.82.1 UGH 10.82.81.0 255.255.255.0 10.82.83.1 UGH 10.82.82.0 255.255.255.0 10.82.82.112 hme0 U 10.82.83.0 255.255.255.0 10.82.83.112 hme1 U default 0.0.0.0 10.82.82.1 UG 224.0.0.0 240.0.0.0 10.82.82.112 hme0 U 127.0.0.1 255.255.255.255 127.0.0.1 lo0 UHStep 3
Step 4
Step 5
Step 6
If the provisioned settings for your IP link are correct, proceed to Step 8.
If the provisioned settings for your IP link are incorrect, proceed to Step 7.
Step 7
Step 8
XE Rsrc Fail
This alarm occurs when memory resources have been exhausted on the active Cisco PGW 2200 Softswitch. If this alarm occurs frequently you may need to add additional memory to your Cisco PGW 2200 Softswitch. See the Sun Microsystems documentation for your Cisco PGW 2200 Softswitch for more information about adding additional memory.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
Warning
Step 3
Step 4
If this resolves the problem, the procedure is complete. Otherwise, proceed to Step 5.
Step 5
Troubleshooting with System Logs
You can use system logs in conjunction with alarms to provide vital information that you can use in troubleshooting problems. A complete listing of system logs can be found in the Cisco PGW 2200 Softswitch Release 9 Messages Reference.
The active system log files reside in the /opt/CiscoMGC/var/log directory. These system log files are archived based on the criteria set in the dmprSink.dat file. For more information on the dmprSink.dat file, see the "Configuring the Data Dumper" section on page A-2.
Note
Viewing System Logs
The best method to use to view logs is to use the log viewer, which is part of the Cisco MGC viewer toolkit. The log viewer enables you to search for specific log information, accounts for log rotations, and makes new logs available. The log server is responsible for log rotation. The log server closes the current file, and creates a new file for current logging. The log viewer also has an option for exporting the results of a log file search to a UNIX file.
For more information on using the log viewer, see the "Using the Log Viewer" section on page 3-128.
To view a log file when you do not have the Cisco MGC viewer toolkit installed on your system, complete the following steps:
Step 1
cd /opt/CiscoMGC/var/logStep 2
lsThe system returns a response similar to the following:
alm.csv platform.logcdr.bin platform_20010516141831.logmeas.csv platform_20010517040508.logmml.log platform_20010518040508.logmml_20010516141831.log platform_20010519040508.logmml_20010517040508.log platform_20010520040508.logmml_20010518040508.log platform_20010521040508.logStep 3
cat log_file_name | moreWhere log_file_name is the name of the log file you want to view.
Note
You might prefer to print the file to find the information you need.For example, you would enter the following command to view a specific platform log file:
cat platform_20010516141831.log | moreThe system returns a response similar to the following:
Tue May 8 13:35:32:920 2001 EST | cdrDmpr (PID 15526) <Error>GEN_ERR_GETCFGPARM: cdrDmprSink::readObj: Failed to get MGC_CDR_NODE_ID for facility *Tue May 8 13:35:32:921 2001 EST | cdrDmpr (PID 15526) <Error>GEN_ERR_GETCFGPARM: cdrDmprSink::readObj: Failed to get MGC_CDR_NODE_ID for facility *Tue May 8 13:35:32:922 2001 EST | cdrDmpr (PID 15526) <Error>GEN_ERR_GETCFGPARM: cdrDmprSink::readObj: Failed to get MGC_CDR_NODE_ID for facility *Process id is 15517 and thead id is 1 in set the destinationTue May 8 13:37:13:201 2001 EST | unknown (PID 15663) <Info>/tmp/almM_input: installed time handler, hdlrId = 1Tue May 8 13:37:31:786 2001 EST | engine (PID 15590) <Error>CP_ERR_START_GWAY_AUDIT: engProcEvtHdlr::handleGoActiveLocal Failed to start GWAY auditProcess id is 15508 and thead id is 1 in set the destinationProcess id is 15509 and thead id is 1 in set the destination--More--
Understanding System Log Messages
Each system log message uses the following format:
Timestamp, Process Name, Process ID, <Log Level>, Log ID:<Message Text>•
•
•
•
•
•
Changing the Log Level for Processes
In order to control the types of log messages being written to the system log file, you can use the set-log MML command to change the logging level for system processes. The Cisco PGW 2200 Softswitch can generate a large number of logged events, which can result in large numbers of archived system log files in the opt/CiscoMGC/var/spool directory. For example, if the maxTime parameter in the dmprSink.dat file is set to 15 minutes, over 2000 files are created in the opt/CiscoMGC/var/spool directory daily. Therefore, you might want to limit the number of logs being created by changing the logging level of the Cisco PGW 2200 Softswitch software processes.
Table 8-1 lists the logging levels that can be selected for the Cisco PGW 2200 Softswitch software processes without severely degrading system performance.
Caution
To change the log level of a single process, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
set-log:process_name:log_level[,confirm]Where:
•
•
–
–
–
–
–
–
•
Note
For example, to change the log level of the engine, enter the following command:
set-log:eng-01:infoTo change the log level of all processes, log in to the active Cisco PGW 2200 Softswitch, start an MML session, and enter the following command:
set-log:all:log_levelWhere log_level is the desired logging level. Valid log levels are as follows:
•
•
•
•
•
Note
For example, to change the log level of all processes to warning, enter the command:
set-log:all:warn
Note
Note
Note
Creating a Diagnostics Log File
You can create a diagnostics log file that records the MML commands and responses that you execute. To do this, perform the following steps:
Step 1
diaglog:filename:startWhere filename is the name of your diagnostics log file. Enter the name only, do not enter a suffix, such as .log.
Step 2
Step 3
diaglog:filename:stopThe file, which is given the name you entered in Step 1, without a suffix, can be found in the $BASEDIR/var/log directory. You can view the file using a text editor, such as vi.
Collecting System Data for Cisco TAC
Cisco PGW 2200 Softswitch software has a data collection script. When you run this script, a data snapshot of your system is saved into a log file. You should run this script shortly after you discover a problem, and prior to taking any corrective action.
This script collects the following information in the log file:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
To collect your system data snapshot, perform the following steps:
Step 1
cd /opt/CiscoMGC/localStep 2
collectdataThe system returns a response that indicates the name of the file and the data path to the file.
Note
Step 3
Resolving SS7 Network Related Problems
The Cisco PGW 2200 Softswitch platform is considered to be a standard Service Switching Point (SSP) in an SS7 network. The SS7 network carries two types of signals:
•
•
The signals involved in the setup and teardown of bearer circuits are circuit-related. Non-circuit-related signals are used for all the ancillary services provided by the SS7 network, including database access and network management.
The SS7 protocol is composed of several levels or "parts," including the following:
•
•
•
•
•
•
•
There are many variations of different parts of the SS7 protocol stack. MTP has ANSI, ITU, Bellcore, and a number of national variations. Each country and each major carrier may have slightly different variations of a part to fit its particular needs.
The SS7 network needs to have the highest degree of reliability. Each switch with access to the SS7 network must be configured to a preconceived set of network parameters. There is some risk that the person configuring a switch will not use the correct set of parameters or values. This is the root cause of most SS7 problems at both the MTP layers and upper layers of the SS7 protocol. A single parameter value, such as an incorrect timer value, can cause SS7 connectivity to act improperly or fail completely.
The first, and most important, step in troubleshooting SS7 related problems is to understand, and fully document, the SS7 network topology and protocols. The protocol documents are used as a reference over the months and years of maintenance on the SS7 network.
Troubleshooting SS7 network problems is described in the following sections:
•
•
Signaling Channel Problems
The Cisco PGW 2200 Softswitch software generates signaling alarms if it detects problems with the transportation of data on a signaling channel or at a signaling destination.
Signaling alarms have four classifications of severity:
•
•
•
•
Note
Signaling links are the dedicated communication channels that the Cisco PGW 2200 Softswitch uses to transfer signaling information among itself, the Cisco ITP-Ls, and the Signal Transfer Points (STPs). Signaling links provide the necessary delivery reliability for higher-layer SS7 signaling protocols.
You can use the Cisco PGW 2200 Softswitch software and MML commands to manage signaling channels and lines. You can retrieve signaling channel attributes, change the states of signaling channels, and change the state of signaling lines. See Chapter 3, "Cisco PGW 2200 Softswitch Platform Operations," for detailed information.
Note
Because all types of signaling channels have basically the same functionality, they are managed similarly. Unless otherwise noted, all commands, counters, and alarms mentioned here are applicable to all types of signaling channels.
Signaling channel problems are described in the following sections:
SS7 Link is Out-of-Service
If an SS7 link is out-of-service on your system, perform the following steps:
Step 1
Step 2
If the SS7 link returns to service, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
If MTP1 is working correctly on the affected Cisco ITP-L, proceed to Step 3. Otherwise, correct the MTP1 problems as described in the "Resolving MTP1 Communication Problems" section on page B-12.
Repeat Step 2. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 7.
Step 4
If MTP2 is working correctly on the Cisco PGW 2200 Softswitch, proceed to Step 8. Otherwise, correct the MTP2 problems as described in the "Resolving MTP2 Communication Problems" section on page B-13.
Repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 5.
Step 5
If MTP2 is working correctly on the affected Cisco ITP-L, proceed to Step 8. Otherwise, correct the MTP2 problems as described in the "Resolving MTP2 Communication Problems" section on page B-13.
Repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 6.
Step 6
If no problems can be found, proceed to Step 7. Otherwise, repeat Step 2. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
SS7 Load Sharing Malfunction
If load sharing on your SS7 links and/or routes is not working properly, perform the following steps:
Step 1
Step 2
prov-rtrv:c7iplnk:"all"The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-07-24 12:11:44M RTRV"session=active:c7iplnk"/*NAME LNKSET PRI SLC TIMESLOT SESSIONSET---- ------ --- --- -------- -----------ls1link1 ls1 1 0 0 c7-slt1ls1link2 ls1 1 1 0 c7-slt2The PRI field in the response shows the priority settings for your SS7 links. For load sharing to work properly, the priority settings for all of your links should be set to 1.
Step 3
prov-rtrv:ss7route:"all"The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-07-24 12:25:05M RTRV"session=active:ss7route"/*NAME OPC DPC LNKSET PRI---- --- --- ------ ---route1 opc1 dpc1 ls1 1rout2 opc1 dpc2 ls2 1rt3 opc2 scp2 ls-itu 1rt1 opc2 stp1 ls-itu 1rt2 opc2 scp1 ls-itu 1*/The PRI field in the response shows the priority settings for your SS7 routes. For load sharing to work properly, the priority settings for all of your routes should be set to 1.
Step 4
Step 5
Step 6
prov-ed:c7iplnk:name="lnkname",pri=1Where lnkname is the name of an SS7 link that does not have a priority of 1.
Repeat this step for each link that does not have a priority of 1.
Step 7
Step 8
prov-ed:ss7route:name="rtname",pri=1Where rtname is the name of an SS7 route that does not have a priority of 1.
Repeat this step for each route that does not have a priority of 1.
Step 9
If the conditions clears, the procedure is complete. Otherwise, proceed to Step 10.
Step 10
Physical Layer Failures
The major issues with the physical layer of an SS7 signaling link are related to cabling, clock source, and connector pinouts. The cable should be of high quality (shielded) and the connectors should be attached and crimped solidly. Since SS7 links are synchronous, one side of the link must provide the clock source and the other side must use this clock signal to read the bits.
Finally, the most common mistake is to use the wrong cable pinouts for a specific physical configuration. Make sure that the connector has the correct number of pins (RJ-45, DB-25) and that each pin maps to the correct signal. A number of different physical layers are supported, including ANSI T1, CEPT E1, and V.35. Make sure that the cable complies with the connector and the physical protocol being used.
If the configuration appears to be valid and the cable pinout is good, check that the signal is being sent and received correctly. Use a Bit Error Rate Tester (BERT) or perform a signal loopback on the interface. It is possible that the cable is bad, so try to replace it. Finally, it is possible that the line card is bad, so you might try replacing it too.
Configuration Errors
The most common mistake in SS7 signal link configuration is to misconfigure the Signal Link Code (SLC) for the SS7 link. This is a preconfigured code on both ends of the link. If the SLC or the point codes do not match, the link does not align and no transmission can take place.
