Chapter 8: Troubleshooting the Cisco MGC
Available Languages
Table Of Contents
Troubleshooting the Cisco MGC Node
Troubleshooting Using Cisco MGC Alarms
Troubleshooting with System Logs
Understanding System Log Messages
Changing the Log Level for Processes
Creating a Diagnostics Log File
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
Signaling Destination Problems
SS7 Destination is Out of Service
SS7 Destination is Unavailable
SS7 Network Troubleshooting Procedures
Setting the Service State of a Signaling Channel
Setting the Service State of a Destination
Setting the Service State of a Signaling Point Code
Setting the Service State of a Link or Linkset
Setting the Service State of a Local Subsystem Number
Managing Japanese SS7 Signaling Link Tests
Managing Japanese SS7 Signaling Route Tests
Verifying Proper Loading of a Dial Plan
Bearer Channel Connection Problems
Troubleshooting Bearer Channel Connection Procedures
Setting the Administrative State
Querying Local and Remote CIC States
Resolving Local and Remote CIC State Mismatch
Performing CIC Validation Tests
Resolving ISDN D-Channel Discrepancies
Auditing an MGCP Media Gateway
Running a Manual Continuity Test
Verifying Continuity Test Settings
Media Gateway IP Destination/Link Out-of-Service
Modifying Redundant Link Manager Timers
Retrieving Names of Open Call Trace Files
Performing an Abnormal Call Termination Trace
Deleting Unnecessary Files to Increase Available Disk Space
Recovering from a Switchover Failure
Recovering from Cisco MGC Host(s) Failure
Recovering from a Cisco MGC Host Failure in a Simplex System
Recovering from a Single Cisco MGC Host Failure in a Continuous Service System
Recovering from a Dual Cisco MGC Host Failure in a Continuous Service System
Restoring Stored Configuration Data
Restoring Procedures for Cisco MGC Software up to Release 7.4(10)
Restoring Procedures for Cisco MGC Software Release 7.4(11) and up
Verifying Proper Configuration of Replication
Measurements Are Not Being Generated
Call Detail Records Are Not Being Generated
Rebooting Your System to Modify Properties
Rebooting Software to Modify Configuration Parameters
Resolving a Failed Connection to a Peer
Troubleshooting the Cisco MGC Node
This chapter describes troubleshooting methods for the Cisco Media Gateway Controller (MGC) node. It includes the following sections to help you isolate system problems:
•
Troubleshooting Using Cisco MGC Alarms
•
Troubleshooting Overview
This chapter uses the alarms and logs that appear at the Cisco MGC as the basis for isolating problems within the system. You can find a complete listing of alarms and logs in the Cisco Media Gateway Controller Software Release 7 Messages Reference Guide.
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 MGC software, the Cisco WAN Manager, 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 SLT Failure
Each Cisco Signaling Link Terminal (SLT) has an Reliable User Datagram Protocol (RUDP)/User Datagram Protocol (UDP)/IP connection to each Cisco MGC for the transfer of Message Transfer Part (MTP) Level 3 (MTP3), ISDN User Part (ISUP), and Transaction Capabilities Application Part (TCAP) information. A Cisco SLT platform failure results in the surviving Cisco SLT platforms taking over the distribution of messages to the active Cisco MGC. Cisco SLT platforms should be provisioned so that half of the platforms can support the entire signaling load. The result is that a Cisco SLT platform failure has no significant effect on call processing.
There are several Cisco SLT failure scenarios to consider:
•
Cisco SLT.•
•
Cisco MGC Failure
Cisco MGC hosts run in active-standby mode. The call-processing application is active on only one Cisco MGC platform at a time, and the application switches to the standby platform when a critical alarm occurs. The result is that Cisco MGC failure and switchover events are invisible to the SS7 signaling network.
Cisco MGC 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 MGC should fail, there is a disconnection from the process manager and a switchover to the standby Cisco MGC.
Operating System Failure
An operating system (OS) or hardware failure in the active Cisco MGC can also cause a switchover to the standby Cisco MGC. The failover daemon in the standby Cisco MGC detects the failure of the active Cisco MGC and instructs the process manager to initiate a switchover. The standby Cisco MGC then takes over all call-processing functions. The switchover is transparent to all the Cisco SLTs.
Troubleshooting Using Cisco MGC Alarms
The Cisco MGC generates alarms to indicate problems with processes, routes, linksets, signaling links, and bearer channels. The Cisco Media Gateway Controller Software Release 7 Messages Reference Guide lists all of the Cisco MGC 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, refer to the "Configuring the Data Dumper" section.
Troubleshooting using Cisco MGC alarms is described in the following sections:
•
•
Retrieving All Active Alarms
To retrieve all active alarms, log in to the active Cisco MGC, 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 MGC, 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"Clearing Alarms
You can clear an alarm for a affected component. Clearing the alarm removes it and any associated alarms from the internal processes list maintained by the Cisco MGC. To clear an alarm, log in to the active Cisco MGC, start an MML session, and enter the following command:
clr-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:
clr-alm:MGC2alink1:"SC FAIL"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 Media Gateway Controller Software Release 7 Messages Reference Guide.
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, refer to the "Configuring the Data Dumper" section.
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, refer to the "Using the Log Viewer" section.
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 | 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 | 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 | 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 | unknown (PID 15663) <Info>/tmp/almM_input: installed time handler, hdlrId = 1Tue May 8 13:37:31:786 2001 | 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 MGC 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 MGC software processes.
Table 8-1 lists the logging levels that can be selected for the Cisco MGC software processes without severely degrading system performance.
Caution
To change the log level of a single process, log in to the active Cisco MGC, 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 MGC, 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.
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 Media Gateway Controller Software Release 7 Messages Reference Guide.
All Conn Cntl Links Fail
This alarm occurs when the MGCP/SRCP 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
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 2
If the MGCP/SRCP sessions are not operating normally, return the MGCP/SRCP sessions to normal operations, as described in the documentation for the affected media gateway. Otherwise, proceed to Step 3.
Step 3
All C7 IP Links Fail
This alarm occurs when communication is lost to all Cisco SLTs of a single protocol family. This defaults to a critical alarm, and causes an automatic switchover, if a standby Cisco MGC is present.
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 2.
Note
Step 3
Cisco MGC, use the prov-rtrv MML command, as described in the "Retrieving Provisioning Data" section. To verify the provisioning data for the Cisco SLTs, use show commands, as described in the "Using the Cisco SLT Operating System to Check Status" section.If the configuration of your Cisco MGC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration of your Cisco SLTs is incorrect, modify the provisioning data for your system. Refer to the Cisco Signaling Link Terminal document for more information.
If the configuration of both the Cisco MGC and the Cisco SLTs are correct, then proceed to Step 4.
Step 4
All ISDN IP Conn Fail
This alarm occurs when communication is lost to all access servers. This alarm causes an automatic switchover, if a standby Cisco MGC is present.
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 2.
Note
Step 3
Cisco MGC, use the prov-rtrv MML command, as described in the "Retrieving Provisioning Data" section. To verify the provisioning data for the media gateways, use show commands, as described in the associated documentation.If the configuration of your Cisco MGC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration of your media gateways is incorrect, modify the provisioning data for the media gateways. Refer to the documentation associated with the media gateway for more information.
If the configuration of the Cisco MGC and the media gateways are correct, then proceed to Step 4.
Step 4
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
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 and reload the dial plan file, using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information.
If their are no infinite loops in your A-number dial plan, then proceed to Step 2.
Step 2
ANAL: ATableFail_GetDigTree
This alarm occurs when an invalid path for A-number analysis has been given or that the A-number analysis table is not loaded. The problem is caused when an invalid path has been specified for A-number analysis or the A-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: 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: 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
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 and reload the dial plan file, using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information.
If their are no infinite loops in your B-number dial plan, then proceed to Step 2.
Step 2
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
If any of the announcement IDs are outside of the range, modify its value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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: 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
If the cause table is incomplete, modify its value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the information in the B-number digit modification table is incorrect, modify its value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the location table does not contain all of the references, modify its value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the result table does not contain all of the references, modify its value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the announcement ID is outside of the range, modify its value using the numan-ed MML command and proceed to Step 2. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
If the affected B-number is less than 4 digits long, modify its value using the numan-ed MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 3.
Step 3
Step 4
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
If any of the application points are incorrect, modify their value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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 or BOrigStartIndex are not present on the associated SS7 signaling service or trunk group. These are 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
prov-rtrv:component:name="comp_name"Where:
•
–
–
•
For example, if you wanted to verify the properties for an SS7 signaling service called ss7svc1, you would enter the following command:
prov-rtrv:sigsvcprop:name="ss7svc1"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:sigsvcprop"/*adjDestinations = 16AlarmCarrier = 0BOrigStartIndex = 0BothwayWorking = 1BTermStartIndex = 1CctGrpCarrier = 2CGBA2 = 0CircHopCount = 0CLIPEss = 0CotInTone = 2010CotOutTone = 2010CotPercentage = 0CustGrpId=2222dialogRange = 0ExtCOT = LoopForwardCLIinIAM = 1ForwardSegmentedNEED = 1GLARE = 0GRA2 = 0GRSEnabled = falseInternationalPrefix = 0layerRetries = 2layerTimer = 10MaxACL = 3maxMessageLength = 250mtp3Queue = 1024NationalPrefix = 0NatureOfAddrHandling = 0Normalization = 0OMaxDigits = 24OMinDigits = 0OOverlap = 0OwnClli = naRedirMax = 3ReleaseMode = AsyncrestartTimer = 10RoutePref = 0sendAfterRestart = 16slsTimer = 300srtTimer = 300sstTimer = 300standard = ANSI92SwitchID = 0TMaxDigits = 24TMinDigits = 0TOverlap = 0variant = SS7-ANSIVOIPPrefix = 0Step 2
Step 3
prov-ed:component:name="comp_name",BOrigStartIndex=1Where:
•
–
–
•
Step 4
Note
prov-ed:component:name="comp_name",CustGrpId=numberWhere:
•
–
–
•
•
Step 5
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: 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
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
If the NOA table is missing any of the existing call context NOA values, add them using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the NPI table is missing any of the references from the NOA table, add them using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the result table is missing any of the references from the NOA and NPI tables, add them using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
If the NPA values are incorrect, modify them using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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_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
If any of the application points are incorrect, modify their value using the numan-ed MML command and reload the dial plan file using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information. Otherwise, proceed to Step 2.
Step 2
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
prov-rtrv:rtlist:"all"Step 2
Step 3
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: 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.
C7LNK ALGNMT LOST
This alarm occurs when the MTP2 for the C7 link between a Cisco SLT and an associated APC has lost alignment.
Corrective Action
To correct the problem identified by this alarm, use the diagnostics on the affected Cisco SLT to determine why the link has lost alignment, as described in the "Verifying the Link Alignment Status" section.
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 MGC.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
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 2
If that does not resolve the problem, proceed to Step 3.
Step 3
C7LNK CONGESTION
This alarm occurs when that the SS7 MTP2 link has encountered congestion such that it cannot receive any more messages. This alarm applies only to SS7 links that are terminated on I/O cards.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
Step 2
If that does not resolve the problem, proceed to Step 3.
Step 3
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 Link or Linkset" section, when the maintenance is complete.
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
If there are no logs that indicate errors in the content of your provisioning data, proceed to Step 2.
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.
If that corrects the problem, the procedure is complete. Otherwise, proceed to Step 2.
Step 2
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 MGC, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section.
Ext Node Interface Fail
This alarm is generated when an SRCP session loses heartbeats with the remote gateway, indicating that the link to the gateway is down.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the remote gateway is not up and working, restore it to service using the procedures found in the documentation associated with the remote media gateway.
If the remote gateway is up and running, proceed to Step 2.
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
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
If the component identified in the alarm text is a piece of system hardware, you should restart the component's software. Procedures for stopping and restarting the software of any of the elements of the Cisco MGC node can be found in "Cisco MGC Node Component Startup and Shutdown Procedures". If that does not resolve the problem, proceed to Step 2.
Step 2
Step 3
FailoverPeerLost
This alarm occurs when the failover daemon on the standby Cisco MGC is not reachable.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
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 2
FailoverPeerOOS
This alarm occurs when the failover daemon goes out-of-service in the standby Cisco MGC.
Corrective Action
To correct the problem identified by this alarm, check the alarms on the standby Cisco MGC, using the procedure in the "Retrieving All Active Alarms" section, and resolve those alarms.
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
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 2.
Step 2
Step 3
Step 4
Step 5
Step 6
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
IP CONNECTION FAILED
This alarm occurs when the Cisco MGC loses network (IP) connectivity to a Cisco SLT. This alarm is generated for each SS7 link associated with the affected Cisco SLT.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the affected Cisco SLT is not up and running, start it using the procedure in the "Cisco Signaling Link Terminal Startup Procedure" section. If this does not resolve the problem, replace the affected Cisco SLT as described in the "Replacing a Cisco SLT" section.
If the affected Cisco SLT is up and running, proceed to Step 2.
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
IP RTE CONF FAIL
This alarm occurs when a signaling channel is not using the route that it is was configured to use.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the provisioned settings for your IP route are correct, proceed to Step 2.
If the provisioned settings for your IP route are incorrect, start a dynamic reconfiguration session to change the settings, as described in the "Invoking Dynamic Reconfiguration" section.
Step 2
IP RTE FAIL
This alarm occurs when a signaling channel that is provisioned with a next hop address if the system failed to add the required route.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the provisioned settings for your IP route are correct, proceed to Step 2.
If the provisioned settings for your IP route are incorrect, start a dynamic reconfiguration session to change the settings, as described in the "Invoking Dynamic Reconfiguration" section.
Step 2
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.
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 line interface (LIF) has failed. All physical lines to the Cisco MGC can raise this alarm.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the provisioned settings for your line interface are correct, proceed to Step 4.
If the provisioned settings for your line interface are incorrect, proceed to Step 2.
Step 2
Start a dynamic reconfiguration session to change the settings, as described in the "Invoking Dynamic Reconfiguration" section.
Step 3
If that does not resolve the problem, proceed to Step 4.
Step 4
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
If the framing formats are different, change the framing format on the port to the other framing format. Otherwise, proceed to Step 2. If the alarm does not clear, proceed to Step 2.
Step 2
Step 3
If you find evidence of a bad line, perform loopback tests on the line to isolate the problem. Otherwise, proceed to Step 4. Once you have isolated the problem, resolve as necessary. If the alarm does not clear, proceed to Step 4.
Step 4
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
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 2.
Step 2
If the alarm does not clear, then proceed to Step 2.
Step 3
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
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
If no alarms are produced, proceed to Step 2
If alarms are produced, the port is causing the error. Replace the hardware component associated with the port. Refer to the associated media gateway documentation for more information on replacing the component.
Step 2
If you find a wiring problem, replace the cable. If that does not clear the alarm, proceed to Step 3.
If you do not find a wiring problem, then proceed to Step 3.
Step 3
If that does not clear the alarm, proceed to Step 4.
Step 4
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
If you find a problem with a V.35 cable, replace the cable. If that does not correct the problem, proceed to Step 2.
If you do not find a problem with the V.35 cables, proceed to Step 2.
Step 2
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
If you find a problem with a V.35 cable, replace the cable. If that does not correct the problem, proceed to Step 2.
If you do not find a problem with the V.35 cables, proceed to Step 2.
Step 2
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
If you find a problem with a V.35 cable, replace the cable. If that does not correct the problem, proceed to Step 2.
If you do not find a problem with the V.35 cables, proceed to Step 2.
Step 2
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 MGC, 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 MGC, 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 MGC, 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 MGC within the audit time interval.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the affected media gateway is in-service, proceed to Step 2. Otherwise, proceed to Step 3.
Step 2
If that does not resolve the problem, proceed to Step 4.
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
NAS: CommsFailure
This alarm occurs when the Cisco MGC cannot communicate with the identified media gateway.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
If the affected media gateway is not up and running, restore it to service. Refer to the documentation for the media gateway for more information.
If the affected media gateway is up and running, proceed to Step 2.
Step 2
Note
If the configuration of your Cisco MGC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration of the affected media gateway is incorrect, modify the provisioning data for your system. Refer to the documentation for the media gateway for more information.
If the configuration of both the Cisco MGC and the affected media gateway are correct, then proceed to Step 3.
Step 3
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.
OOS TRAFFIC RE-ROUTE
This alarm occurs when the traffic channels (bearer channels, IP network) on one side of the Cisco MGC have been lost, causing the Cisco MGC 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
If resolving those alarms does not clear this alarm, proceed to Step 2.
Step 2
Note
If the configuration of your Cisco MGC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration of the affected media gateway is incorrect, modify the provisioning data for your system. Refer to the documentation for the media gateway for more information.
If the configuration of both the Cisco MGC and the affected media gateway are correct, then proceed to Step 3.
Step 3
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, refer to the "Managing Automatic Congestion Control" section.
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 MGCs.
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, refer to the "Managing Automatic Congestion Control" section.
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 MGCs.
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, refer to the "Managing Automatic Congestion Control" section.
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 MGCs.
Note
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
If resolving those alarms does not clear this alarm, proceed to Step 2.
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.
If the configuration data associated with the DPC is correct, then proceed to Step 3.
Step 3
Peer IP Links Failure
This alarm occurs when the IP links to the peer Cisco MGC are removed or down.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
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 2
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. For more information about provisioning your Cisco MGC, refer to the Cisco Media Gateway Controller Software Release 7 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, 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. Refer to the "Invoking Dynamic Reconfiguration" section for more information.
Corrective Action
If necessary, you can clear the alarm, as described in the "Clearing Alarms" section, or you can complete the dynamic reconfiguration procedure, as described in the "Invoking Dynamic Reconfiguration" section.
POM: PEER_SYNC_ERR
This alarm occurs when the standby Cisco MGC attempts to synchronize the contents of its configuration library while a provisioning session is in progress on the active Cisco MGC.
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, or save and activate your changes as described in the "Saving and Activating your Provisioning Changes" section.
PRI: B-Channel not available
This alarm occurs when the Cisco MGC 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 clear the alarm, as described in the "Clearing Alarms" section, or you can save and activate your provisioning session, as described in the "Saving and Activating your Provisioning Changes" section.
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
Step 5
REPL: all connections failure
This alarm occurs when the Cisco MGC cannot establish communication to the peer Cisco MGC.
Corrective Action
To correct the problem identified by this alarm, perform the following steps:
Step 1
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 2
If that does not resolve the alarm, proceed to Step 3.
Step 3
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
If the configuration data associated with the DPC is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration data associated with the DPC is correct, then proceed to Step 3.
Step 2
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
If that does not resolve the problem, proceed to Step 8.
Step 7
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
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 2.
Step 2
If the configuration data for the signaling channel is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration data for the signaling channel is correct, then proceed to Step 3.
Step 3
SC M-OOS
This alarm occurs when the signaling channel has been manually set to the out of service state.
Corrective Action
To correct the problem identified by this alarm, return the signaling channel to the in-service state as described in the "Setting the Service State of a Signaling Channel" section.
srcpAudit: GwBackhaulProto
This alarm occurs when the returned backhaul protocol is different from what the Cisco MGC expects, which is a value of none. A mismatch here might cause minimal, partial, or complete signaling/call-control failure.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwBackhaulSes
This alarm occurs when the number of backhaul sessions is different from what the Cisco MGC expects. The Cisco MGC is expecting the value to match the provisioned value. Each backhaul session to the same IP address as the SRCP counts as 1. Some signaling information might be lost, leading to lost or failed calls.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwControlProto
This alarm occurs when the control protocol is different from what the Cisco MGC expects, which is a value of MGCP. A mismatch here might cause minimal, partial, or complete signaling failure.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwCoordProto
This alarm occurs when the coordination protocol is different from what the Cisco MGC expects, which is a value of SRCP 1.0. A mismatch here might cause alarms to be raised erroneously.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwCuIpAddr
This alarm occurs when the IP address of the media gateway (CU) reported by the media gateway is different from that configured in the Cisco MGC. The Cisco MGC is expecting the IP address to match the value provisioned for the remote IP address entry of the signaling channel path. This can lead to a communication failure by the control protocol.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwCuIpPort
This alarm occurs when the value of the IP port reported by the media gateway (CU) is different from that configured in the Cisco MGC. The Cisco MGC is expecting the IP port to match the provisioned value for the remote port entry for this signaling channel or signaling service.This can lead to a communications failure by the control protocol.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwNumOfLines
This alarm occurs when the number of lines in the media gateway partition is different from what the Cisco MGC expects. The Cisco MGC is expecting the number of lines to match the value provisioned for the total number of bearer lines associated with this signaling service. This may affect service if a call are made on nonexistent lines. Another error should be raised elsewhere in the system if a call is placed to a nonexistent line.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwSlotNum
This alarm occurs when the hardware for the media gateway is in a different slot than the Cisco MGC expects, which is a value of 0. This should not affect service but might be an issue in hardware troubleshooting.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwSulpAddr
This alarm occurs when the IP address of the call agent (SU or MGC) reported by the media gateway is different from that configured in the Cisco MGC. The Cisco MGC is expecting the IP address to match the value provisioned for the local IP address entry for this signaling channel or signaling service. This can lead to a communications failure by the control protocol.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwSulpPort
This alarm occurs when the IP port of the call agent (SU or Cisco MGC) reported by the media gateway is different from that configured in the Cisco MGC. The Cisco MGC is expecting the IP port value to match the value provisioned for the local port entry for this signaling channel or signaling service. This can lead to a communications failure by the control protocol.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: GwType
This alarm occurs when the media gateway is of a different type than the Cisco MGC expects, which is a value of VISM. This may or may not affect service depending on whether the Cisco MGC has media gateway-specific coding.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: LineCoding
This alarm occurs when the line coding used by the media gateway for that line is different from that configured in the Cisco MGC for that line, which is a value of Unknown. This might lead to corrupted data on the B-channels.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: LineLoopback
This alarm occurs when the line loopback for that line used by the media gateway is different from that configured in the Cisco MGC for that line, which is a value of n. A line may be in a loopback state when the Cisco MGC believes it is available.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: LineSigProto
This alarm occurs when the signaling protocol used by the media gateway for that line is different from that configured in the Cisco MGC for that line. The Cisco MGC is expecting the signaling type associated with the backhaul signaling to the same remote IP address as the SRCP for this signaling channel. Some signaling information might be lost, leading to lost or failed calls.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
srcpAudit: LineState
This alarm occurs when the line state for the line used by the media gateway is different from that configured in the Cisco MGC for that line, which is a value of e. A line might be disabled by the media gateway when the Cisco MGC believes it is available.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Resolving an SRCP Audit Alarm" section.
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
If the configuration data associated with the SSN is incorrect, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section.
If the configuration data associated with the SSN is correct, then proceed to Step 2.
Step 2
If the SCP is not reachable, begin a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section, 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 3.
Step 3
Standby Warm Start
This alarm occurs on the active Cisco MGC when a warm start process begins in the IOCM. This alarm clears automatically when the warm start process completes successfully. This alarm also occurs on the standby Cisco MGC when the prov-sync MML command is entered on the active Cisco MGC. In that case, the alarm clears automatically when the synchronization of provisioning data is complete.
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.
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
If the alarms clear, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
SwitchoverFail
This alarm occurs when a switchover operation from the active Cisco MGC to the standby Cisco MGC has failed.
Corrective Action
To correct the problem identified by this alarm, perform the procedure in the "Recovering from a Switchover Failure" section.
XE Rsrc Fail
This alarm occurs when memory resources have been exhausted on the active Cisco MGC host. If this alarm occurs frequently you may need to add additional memory to your Cisco MGC. Refer to the Sun Microsystems documentation for your Cisco MGC host 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
Step 3
SS7 Network Related Problems
The Cisco MGC node 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 MGC 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 MGC uses to transfer signaling information among itself, the Cisco SLTs, and the Signal Transfer Points (STPs). Signaling links provide the necessary delivery reliability for higher-layer SS7 signaling protocols.
You can use the Cisco MGC 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 "Cisco MGC Node 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
If the SS7 link returns to service, the procedure is complete. Otherwise, proceed to Step 2.
Step 2
If your system is using Cisco SLTs to terminate the SS7 link, proceed to Step 4.
Step 3
a.
If both LEDs are green proceed to Step 5. Otherwise, proceed to Step 3b.
b.
Perform the corrective actions for the alarm. These can be found in the "Alarm Troubleshooting Procedures" section.
Repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 4.
Step 4
If MTP1 is working correctly on the affected Cisco SLT, proceed to Step 6. Otherwise, correct the MTP1 problems as described in the "Resolving MTP1 Communication Problems" section.
Repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 6.
Step 5
If MTP2 is working correctly on the Cisco MGC, proceed to Step 8. Otherwise, correct the MTP2 problems as described in the "Resolving MTP1 Communication Problems" section.
Repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 8.
Step 6
If MTP2 is working correctly on the affected Cisco SLT, proceed to Step 7. Otherwise, correct the MTP2 problems as described in the "Resolving MTP2 Communication Problems" section.
Repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
If no problems can be found, proceed to Step 8. Otherwise, repeat Step 1. If the link returns to service, the procedure is complete. Otherwise, proceed to Step 8.
Step 8
SS7 Load Sharing Malfunction
If load sharing on your SS7 links and/or routes is not working properly, perform the following steps:
Step 1
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 IF IPADDR PORT PEERADDR PRI SLC TIMESLOT NEXTHOP NETMASK---- ------ -- ------ ---- -------- --- --- -------- ------- -------ls1link1 ls1 enif1 IP_Addr1 7000 172.24.200.9 1 0 0 0.0.0.0 255.255.255.255ls2lnk1 ls2 enif1 IP_Addr1 7000 172.24.200.9 1 0 1 0.0.0.0 255.255.255.255ls1link2 ls1 enif1 IP_Addr1 7000 172.24.200.10 1 1 0 0.0.0.0 255.255.255.255ls2lnk2 ls2 enif1 IP_Addr1 7000 172.24.200.10 1 1 1 0.0.0.0 255.255.255.255lk-3 ls-itu enif1 IP_Addr1 7001 172.24.237.254 1 0 2 0.0.0.0 255.255.255.255*/The 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 2
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 3
Step 4
Step 5
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 6
Step 7
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 8
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.
For T1 and E1 connectors, an SS7 signaling link is carried in a single 56- or 64-kbps time slot. The time slot that is used must also agree on both sides of the link.
Make sure the MTP2 timers and thresholds agree with the network defaults. Confirm that the far-end switch or STP has the same values as your system.
When a Cisco SLT is used to terminate MTP2, confirm that the RUDP parameters agree on both sides and are consistent with the documentation.
Supporting Entity Failures
An SS7 signaling link has a hierarchy of network element entities that must be functioning before the link can function. These include the physical interface (discussed above) and the control software for the link. If any of these fail, the link also fails.
Incomplete Signaling
Link failures between the Cisco SLT and the Cisco MGC can be caused by
•
•
•
•
In each of the above cases, it is impossible to transfer MTP3 signaling messages from the Cisco SLT to the Cisco MGC. Cisco SLT platform failure (which is equivalent to MTP2 failure) causes signaling messages to be unable to go to MTP3. The MTP2 layer on the Cisco SLT is supposed to transmit SIPO messages to the STP mated pair to initiate the changeover procedure. Cisco SLT platform failure on the SS7 network is detected by the mated STP pair, which detects timer expiration and link unavailability.
Changing Service States
Signal channels comply with the Generic Service State model defined in the "Physical Layer Failures" section. You can change the desired service state of a signaling channel using the following transition requests. Note that there is a difference between a desired service state and an actual service state, and the Cisco MGC might not be able to honor the request. For example, a signal channel that is out-of-service due to an equipment failure cannot transition to an in-service state upon request. The Cisco MGC attempts to bring the channel in-service, but it fails. The failure must be fixed before the transition can succeed.
•
•
For some protocols, this request is accepted, but not granted until after all calls have been released. During the interim period, the channel's service state appears as OOS, PEND.
•
•
In this state, the channel is active but does not provide service for call processing. If the signaling channel is the last one in the signal path, the inhibit request is denied and an error is returned.
•
Use this option (UNH), rather than the IS option, to return an inhibited signaling channel to service.
Note
Signaling Destination Problems
Signaling destinations refer to the endpoints of a network. Typically, if signaling links are in service, the signaling destinations should also be in service.
For ISDN signaling, the signaling channel is in service if the Cisco MGC can talk to the media gateway and ISDN backhaul is configured. The destination is in service if the signaling channel is in service and the remote ISDN device is up.
Apparent mismatches can occur due to
•
•
•
•
An SS7 STP is treated as an adjacent point code (APC) to the Cisco MGC. SS7 MTP uses a message exchange called Signaling Link Test Message (SLTM)/Signaling Link Test Acknowledgment (SLTA) to confirm that the far-end point code is the one configured. The SLTM consists of the originating point code (OPC) of the Cisco MGC, an APC number, and an SS7 network indicator. If the values for these parameters match with the values used for these at the far-end switch, an SLTA is returned. If the value for any of these parameters do not match, the far-end switch does not send an SLTA. The Cisco MGC drops the link and tries to realign it. This process continues until the SLTM parameters match on both sides. The problem is manifested by the SS7 links dropping and recovering in roughly 30-second cycles (this is referred to as bouncing).
The following sections describe signaling destination problems:
•
•
Bouncing SS7 Links
Usually, this condition is caused by mismatched signaling link codes (SLCs) or DPCs/OPCs between the Cisco MGC and the far end. To resolve a bouncing SS7 condition, perform the following steps:
Step 1
If the provisioning settings for the SLC, OPC, and DPC match with those used on the far end, proceed to Step 2. Otherwise, modify the settings to match with those used on the far end. Refer to the "Invoking Dynamic Reconfiguration" section for more information about modifying the settings of a provisioned component. If that clears the problem, the procedure is complete. Otherwise, proceed to
Step 2.Step 2
If the local MTP3 timer settings match the network defaults, proceed to Step 3. Otherwise, contact the far-end to determine whether their timer settings can be changed to match your settings. If that clears the problem, the procedure is complete. Otherwise, proceed to Step 3.
Step 3
Step 4
Configuration Errors
If the SS7 DPC is fully associated, it can have the same SLTM/SLTA problems as described above.
If the SS7 DPC is quasi-associated, the most common cause for failure is a route misconfiguration. Review the route information between the Cisco MGC and the DPC to make sure that the APCs are valid, the route priorities are set correctly, and the route uses the appropriate linkset.
Traffic Restart
Make sure that the MTP3 traffic restart timers and thresholds agree with the network defaults. Confirm that the far-end switch or STP also has the same values.
SS7 Destination is Out of Service
A signaling destination is typically out of service when all of the SS7 links from the Cisco MGC to the destination or APC are out of service, or when all of the SS7 links from the destination to the APC are out of service.
To restore an SS7 destination to service, perform the following steps:
Step 1
Step 2
If any of the SS7 links are out-of-service, restore the links as described in the "SS7 Link is Out-of-Service" section. If all of the SS7 links to a destination are out-of-service, restore the destination as described in the "SS7 Destination is Out of Service" section.
SS7 Route is Out of Service
To restore an SS7 route to service, perform the following steps:
Step 1
If the destination goes into service, the procedure is complete. Otherwise, proceed to Step 2.
Step 2
If none of the SS7 links are in-service, proceed to Step 3. If all or at least one of the SS7 links to the destination are in-service, then contact your SS7 provider and have them verify the links from the DPC to the associated STP.
Step 3
SS7 Destination is Unavailable
An SS7 destination is unavailable when all of the routes to the destination are out-of-service. Perform the procedure defined in the "SS7 Route is Out of Service" section.
SS7 Network Troubleshooting Procedures
The following sections are procedures used to resolve problems associated with the Cisco MGC node's connection to the SS7 network:
•
•
•
•
•
•
•
•
Setting the Service State of a Signaling Channel
To set the service state of a signaling channel or linkset, perform the following steps:
Step 1
set-sc-state:sig_chan:serv_stateWhere:
•
•
–
–
Note
–
–
–
For example, to set the service state of a signaling channel called iplink1 to IS, enter the following command:
set-sc-state:iplink1:ISStep 2
Setting the Service State of a Destination
To set the service state of a destination, perform the following steps:
Caution
Step 1
set-dest-state:dest:serv_stateWhere:
•
•
–
–
Note
For example, to set the service state of a destination called dpc1 to IS, enter the following command:
set-dest-state:dpc1:ISStep 2
Setting the Service State of a Signaling Point Code
To set the service state of a signaling point code, perform the following steps:
Caution
Step 1
set-spc-state:sig_pc:serv_stateWhere:
•
•
–
–
For example, to set the service state of signaling point code called stp1 to IS, enter the following command:
set-spc-state:stp1:ISStep 2
Setting the Service State of a Link or Linkset
To set the service state of a link or linkset, perform the following steps:
Step 1
set-lnk-state:lname:serv_stateWhere:
•
•
–
–
Note
–
–
–
For example, to set the service state of a link called ls1-link1 to IS, enter the following command:
set-sc-state:ls1-link1:ISStep 2
Setting the Service State of a Local Subsystem Number
To set the service state of a local subsystem number (LSSN), perform the following steps:
Step 1
set-lssn-state:ssn:serv_stateWhere:
•
•
–
–
For example, to set the service state of an LSSN called lnp to IS, enter the following command:
set-lssn-state:lnp:ISStep 2
Verifying MTP Timer Settings
When resolving signaling problems between the Cisco MGC and an associated SS7 network element (such as an STP), you may need to verify that the MTP2 and MTP3 timer settings used by the Cisco MGC conform to settings used by the associated SS7 network element. MML commands are used to retrieve the settings for the MTP2 and MTP3 timers on the Cisco MGC. The following subsections describe methods for verifying the MTP timer settings on the Cisco MGC.
Note
The procedure used to verify the settings for MTP2 timers varies based on how SS7 signaling is terminated for your Cisco MGC. If you are using Cisco SLTs to terminate SS7 signaling, refer to the "Verifying MTP2 Timers for Cisco SLTs" section. If you are using I/O cards to terminate SS7 signaling, refer to the "Verifying MTP2 Timers for I/O Cards" section. The procedure to verify MTP3 timers is the same for both SS7 signaling termination methods.
If you find, after you verify the settings, that you need to modify the settings for the MTP timers, proceed to the "Modifying MTP Timer Settings" section.
Verifying MTP2 Timers for Cisco SLTs
To verify the values used for the MTP2 timers when you are using Cisco SLTs to terminate SS7 signaling, complete the following steps:
Step 1
Router #show SS7 mtp2 timer channelWhere: channel specifies a channel, 0 through 3.
The system returns a message similar to the following:
SS7 MTP2 Timers for channel 0 in millisecondsProtocol version for channel 0 is Japan NTT Q.703 Version 1-1T1 aligned/ready = 15000T2 not aligned = 5000T3 aligned = 3000T4 Emergency Proving = 3000T4 Normal Proving = 3000T5 sending SIB = 200T6 remote cong = 3000T7 excess ack delay = 2000T8 errored int mon = 0TA SIE timer = 20TF FISU timer = 20TO SIO timer = 20TS SIOS timer = 20Step 2
If the MTP2 timers settings match, your signaling problem has different cause. Continue troubleshooting the problem.
If the MTP2 timers settings do not match, perform the procedure in the "Modifying MTP2 Timers for Cisco SLTs" section.
Verifying MTP2 Timers for I/O Cards
To verify the values used for the MTP2 timers when you are using I/O cards to terminate SS7 signaling, complete the following steps:
Step 1
Note
prov-rtrv:sigsvcprop:name="protocol"Where protocol is the MML name for the SS7 protocol family being used, such as SS7-ANSI or SS7-ITU.
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2001-06-01 10:31:00M RTRV"session=active:lnksetprop"/*mtp2AermEmgThr = 1mtp2AermNrmThr = 4mtp2CongDiscard = falsemtp2LssuLen = 1mtp2MaxAlignRetries = 5mtp2MaxMsuFrmLen = 272mtp2MaxOutsFrames = 127mtp2ProvingEmgT4 = 6mtp2ProvingNormalT4 = 23mtp2SuermThr = 64mtp2T1 = 130mtp2T2 = 115mtp2T3 = 115mtp2T5 = 1mtp2T6 = 30mtp2T7 = 10mtp3ApcMtpRstrtT28 = 30mtp3DlnkConnAckT7 = 10mtp3FrcUnhT13 = 10mtp3InhAckT14 = 20mtp3LocInhTstT20 = 900mtp3MaxSltTries = 2mtp3MsgPriority = 2mtp3MtpRstrtT24 = 100mtp3RepeatRstrtT26 = 150mtp3TfrUsed = falsemtp3TraSntT29 = 600mtp3tstSltmT1 = 60mtp3tstSltmT2 = 600mtp3UnhAckT12 = 10reference = ANSI92rudpAck = enablerudpKeepAlives = enablerudpNumRetx = 2rudpRetxTimer = 6rudpSdm = enablerudpWindowSz = 32Step 2
If the MTP2 timers settings match, your signaling problem has different cause. Continue troubleshooting the problem.
If the MTP2 timers settings do not match, perform the procedure in the "Modifying MTP2 Timers for I/O Cards" section.
Verifying MTP3 Timers
To verify the values used for the MTP3 timers, complete the following steps:
Step 1
prov-rtrv:sigsvcprop:name="protocol"Where protocol is the MML name for the SS7 protocol family being used, such as SS7-ANSI or SS7-ITU.
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2001-06-01 10:31:00M RTRV"session=active:lnksetprop"/*mtp2AermEmgThr = 1mtp2AermNrmThr = 4mtp2CongDiscard = falsemtp2LssuLen = 1mtp2MaxAlignRetries = 5mtp2MaxMsuFrmLen = 272mtp2MaxOutsFrames = 127mtp2ProvingEmgT4 = 6mtp2ProvingNormalT4 = 23mtp2SuermThr = 64mtp2T1 = 130mtp2T2 = 115mtp2T3 = 115mtp2T5 = 1mtp2T6 = 30mtp2T7 = 10mtp3ApcMtpRstrtT28 = 30mtp3DlnkConnAckT7 = 10mtp3FrcUnhT13 = 10mtp3InhAckT14 = 20mtp3LocInhTstT20 = 900mtp3MaxSltTries = 2mtp3MsgPriority = 2mtp3MtpRstrtT24 = 100mtp3RepeatRstrtT26 = 150mtp3TfrUsed = falsemtp3TraSntT29 = 600mtp3tstSltmT1 = 60mtp3tstSltmT2 = 600mtp3UnhAckT12 = 10reference = ANSI92rudpAck = enablerudpKeepAlives = enablerudpNumRetx = 2rudpRetxTimer = 6rudpSdm = enablerudpWindowSz = 32Step 2
If the MTP3 timers settings match, your signaling problem has different cause. Continue troubleshooting the problem.
If the MTP3 timers settings do not match, perform the procedure in the "Modifying MTP3 Timers" section.
Modifying MTP Timer Settings
As of Release 7.4(12), you can modify the settings for the MTP timers. For more information, refer to the Release Notes for the Cisco Media Gateway Controller Software.
When resolving signaling problems between the Cisco MGC and an associated SS7 network element (such as an STP), you may need to modify the MTP2 and MTP3 timer settings on the Cisco MGC, so that they conform to the settings used by that SS7 network element. You use MML commands to modify the settings for the MTP2 and MTP3 timers. The following subsections describe methods for modifying the settings of the MTP timers on the Cisco MGC.
The procedure used to modify the settings for MTP2 timers varies based on how SS7 signaling is terminated for your Cisco MGC. If you are using Cisco SLTs to terminate SS7 signaling, refer to the "Modifying MTP2 Timers for Cisco SLTs" section. If you are using I/O cards to terminate SS7 signaling, refer to the "Modifying MTP2 Timers for I/O Cards" section. The procedure for modifying MTP3 timers is the same for both SS7 signaling termination methods.
Note
You might want to verify the new settings after the modification is complete. To do this, refer to the procedure in the "Verifying MTP Timer Settings" section.
Modifying MTP2 Timers for Cisco SLTs
Use the following MML commands at the Cisco SLT to modify the settings for the MTP2 timers:
Router (config)#ss7 mtp-variant standard channelRouter(config-standard)# parametersWhere:
•
•
•
Note
In the following example, the aligned/ready timer duration on channel 0 is set to 30,000 milliseconds:
Router(config)# ss7 mtp2-variant Bellcore 0Router(config-Bellcore)# T1 30000In the following example, the aligned/ready timer is restored to its default value of 13,000 milliseconds:
Router(config)# ss7 mtp2-variant Bellcore 0Router(config-Bellcore)# no T1You might want to verify the new settings after the modification is complete. To do this, refer to the procedure in the "Verifying MTP2 Timers for Cisco SLTs" section.
Modifying MTP2 Timers for I/O Cards
To modify the settings for the MTP2 timers when you are using I/O cards to provide SS7 signaling links, perform the following steps:
Step 1
Step 2
prov-ed:lnkset:name="protocol",param_name=param_valueWhere:
•
•
•
Note
In the following example, the MTP2 T2 timer, maximum period in a Not Aligned state before returning to an OOS state, is set to 120 tenths of a second:
prov-ed:lnkset:name="SS7-ANSI",mtp2T2=120Step 3
Step 4
Modifying MTP3 Timers
To modify the settings for the MTP3 timers, perform the following steps:
Step 1
Step 2
prov-ed:lnkset:name="protocol",param_name=param_valueWhere:
•
•
•
Note
In the following example, the MTP3 T1 timer, waiting for signaling link test acknowledgment message, is set to 65 tenths of a second:
prov-ed:lnkset:name="SS7-ANSI",mtp3tstSltmT1=65Step 3
Step 4
Managing Japanese SS7 Signaling Link Tests
The following subsections detail the procedures used to manage the tests that can be run on a signaling link configured for Japanese SS7:
•
•
Starting an Japanese SS7 Signaling Link Test
To start a signaling link test on a link configured for Japanese SS7, log in to the active Cisco MGC, start an MML session, and enter the following command:
sta-ss7-slt:linkWhere link is the MML name of a link configured for Japanese SS7.
For example, to start a signaling link test on a link called ls1-link1, you would enter the following command:
sta-ss7-slt:ls1-link1Retrieving Results for a Japanese SS7 Signaling Link Test
To retrieves the results of a Japanese SS7 signaling link test, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-ss7-slt:linkWhere link is the MML name of a link configured for Japanese SS7.
For example, to retrieve the results of a signaling link test run on a link called ls1-link1, you would enter the following command:
rtrv-ss7-slt:ls1-link1The system returns a result that indicates the name of the link and the status of the signaling link test. The valid status responses are listed below:
•
•
–
–
–
–
–
–
–
–
•
•
For example, here is a sample response to a signaling link test run on a link called ls1-link1:
Media Gateway Controller - MGC-01 2000-01-12 15:18:41M RTRV"ls1link1:TEST PASSED; COMPLETED 15:18:34"Managing Japanese SS7 Signaling Route Tests
The following subsections detail the procedures used to manage the tests that can be run on a signaling route configured for Japanese SS7:
•
•
Starting a Japanese SS7 Signaling Route Test
To start a signaling route test on a route configured for Japanese SS7, log in to the active Cisco MGC, start an MML session, and enter the following command:
sta-ss7-srt:pt_code:lset="linkset"Where:
•
•
For example, to start a signaling route test on a point code called dpc1 associated with a linkset called ls1, you would enter the following command:
sta-ss7-srt:dpc1:lset="ls1"Retrieving Results for a Japanese SS7 Signaling Route Test
To retrieves the result of a Japanese SS7 signaling route test, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-ss7-srt:pt_code:lset="linkset"Where:
•
•
For example, to retrieve the results of a signaling route test run on a point code called dpc1 associated with a linkset called ls1, you would enter the following command:
rtrv-ss7-srt:dpc1:lset="ls1"The system returns a result that indicates the name of the link and the status of the signaling route test. The valid status responses are listed below:
•
•
–
–
–
–
–
–
–
–
•
•
For example, here is a sample response to a signaling route test run on a point code called dpc1 associated with a linkset called ls1:
Media Gateway Controller - MGC-01 2000-01-12 15:20:09M RTRV"dpc1:TEST FAILED; TEST TIMEOUT; COMPLETED 15:20:01"
Verifying Proper Loading of a Dial Plan
Step 1
If the dial plan was not loaded correctly, reload the dial plan using the chg-dpl MML command. Refer to the Cisco Media Gateway Controller Software Release 7 Dial Plan Guide for more information.
If there are no logs that indicate that the dial plan was loaded incorrectly, then proceed to Step 2.
Step 2
Bearer Channel Connection Problems
Bearer channels are the focus of everything that the Cisco MGC does. The main function of the
Cisco MGC is to ensure that an ingress bearer channel at one endpoint can be successfully connected to an egress bearer channel at another endpoint.The state of the bearer channels is often a good indicator of the overall health of the system. Procedures for determining the state of your bearer channels can be found in the "Verifying CIC States" section.
Troubleshooting Bearer Channel Connection Procedures
The following sections contains procedures that are related to resolving problems associated with the Cisco MGC node's bearer channel connections:
•
•
•
•
•
•
•
•
•
•
Setting the Administrative State
You can use the set-admin-state MML command to change the administrative state of various components. A platform info log is generated every time the set-admin-state MML command is entered. An alarm is generated every time the set-admin-state MML command is entered at either the Cisco MGC, media gateway, signaling service, or trunk group level.
The procedures that describe how to use this command are listed below:
•
•
•
•
•
•
Setting the Administrative State of a Cisco MGC
To set the administrative state of a Cisco MGC, perform the following steps:
Step 1
set-admin-state:mgc:stateWhere:
•
•
–
–
–
For example, to set the administrative state of a Cisco MGC called mgc1 to unlock, enter the following command:
set-admin-state:mgc1:unlockStep 2
Setting the Administrative State of a Media Gateway
To set the administrative state of an associated media gateway, perform the following steps:
Step 1
set-admin-state:gway:stateWhere:
•
Note
•
–
–
–
For example, to set the administrative state of a media gateway called sfgway to lock, enter the following command:
set-admin-state:sfgway:lockStep 2
Setting the Administrative State of a Trunk Group
To set the administrative state of an trunk group, perform the following steps:
Step 1
set-admin-state:trkgrp:stateWhere:
•
Note
•
–
–
–
For example, to set the administrative state of a trunk group called trunkgrp1 to lock, enter the following command:
set-admin-state:trunkgrp1:lockStep 2
Setting the Administrative State of a Signaling Service
To set the administrative state of a signaling service, perform the following steps:
Step 1
set-admin-state:sig_srv:stateWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
–
–
For example, to set the administrative state of a signaling service called nassrv1 to lock, enter the following command:
set-admin-state:nassrv1:lockStep 2
Setting the Administrative State of Spans
To set the administrative state of a single span, perform the following steps:
Step 1
set-admin-state:sig_srv:span=x:stateWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
•
–
–
For example, to set the administrative state of span number 2 associated with a signaling service called ss7svc1 to unlock, you would enter the following command:
set-admin-state:ss7svc1:span=2:lockStep 2
To set the administrative state of a bearer channel or a range of bearer channels in a span, perform the following steps:
Step 1
rtrv-admin-state:sig_srv:span=x,bc=y[,rng=range]:stateWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
•
•
•
–
–
For example, to set the administrative state of bearer channels numbers 2 through 6, associated with a signaling service called ss7svc1, to unlock, you would enter the following command:
rtrv-admin-state:ss7svc1:span=2,bc=2,rng=5:unlockStep 2
Setting the Administrative State of CICs
To set the administrative state of a CIC or a range of CICs, perform the following steps:
Step 1
set-admin-state:sig_srv:cic=number[,rng=range]:stateWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
•
•
–
–
–
For example, to set the administrative state of CICs 2 through 11, associated with a signaling service called ss7svc1, to lock, you would enter the following command:
set-admin-state:ss7svc1:cic=2,rng=9:lockStep 2
Querying Local and Remote CIC States
In the course of troubleshooting problems with your bearer channels, you may need to query the local and remote states of the related CICs, to verify that they match. To query the local and remote states of a single CIC or a range of CICs, log in to the active Cisco MGC, start an MML session, and enter the following command:
query-cic:pt_code:cic=number[,rng=range]Where:
•
•
•
Note
Note
For example, to query the state of CICs 20 through 24, associated with a point code called dpc1, you would enter the following command:
query-cic:dpc1:cic=20,rng=4The system responds with a message similar to the following:
Media Gateway Controller - MGC-01 2000-01-12 15:19:51M RTRV"dpc1:CIC=20;LPST=IS;LSST=IDLE;RPST=IS;RSST=IDLE""dcp1:CIC=21;LPST=IS;LSST=IDLE;RPST=IS;RSST=IDLE""dpc1:CIC=22;LPST=IS;LSST=IDLE;RPST=IS;RSST=IDLE""dpc1:CIC=23;LPST=IS;LSST=IDLE;RPST=IS;RSST=IDLE""dpc1:CIC=24;LPST=OOS;LSST=IDLE_LOC_BLOC;RPST=IS;RSST=IDLE"The response lists the local and remote primary and secondary states of the requested CICs. If the response indicates that the mismatch is due to a problem on the local side, you can attempt to resolve the state mismatch using the instructions in the "Resolving Local and Remote CIC State Mismatch" section. If the response indicates that the mismatch is due to a problem on the remote side, you must contact the personnel at the remote site to resolve the problem.
The valid values for the fields found in the response to this command are as follows:
•
–
–
–
•
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Resolving Local and Remote CIC State Mismatch
When the local and remote states for CICs do not match and the problem lies with the local CIC states, you can attempt to resolve the mismatch using an MML command. To do this, log in to the active
Cisco MGC, start an MML session, and enter the following command:query-cic:pt_code:cic=number[,rng=range],rslvWhere:
•
•
•
Note
Note
If the command fails in its attempt to resolve the local and remote CIC state mismatch, contact the
Cisco TAC for assistance. Refer to the "Obtaining Technical Assistance" section for more information about contacting the Cisco TAC.Performing CIC Validation Tests
When performing initial turn-up of circuits or in troubleshooting certain problems with your bearer channels, you may want to perform a circuit validation test to verify that the properties defined in the Cisco MGC for the affected bearer channels match the associated properties defined in the far-end exchange.
Note
To perform a circuit validation test, complete the following steps:
Step 1
vld-cic:dest_pc:cic=numberWhere:
•
•
If the circuit validation test is passed, the system returns a message similar to the following:
Media Gateway Controller - MGC-01 2000-03-07 09:35:19M RTRV"dms100-pc:CIC=105,PASSED"If the circuit validation test is failed, the system returns a message similar to the following:
Media Gateway Controller - MGC-01 2000-03-07 09:35:19M RTRV"dms100-pc:CIC=105,FAIL"LOC: GRP=DIG,SEIZ=EVEN,ALM=UNK,COT=NONELOC: TRK=1003,A_CLLI=dms1003****,Z_CLLI=na*********REM: GRP=DIG,SEIZ=ODD,ALM=SOFT,COT=STATThe fields in the LOC line are values associated with the Cisco MGC. The fields in the REM line are values associated with the far-end exchange. The valid values for those fields are described below.
•
–
–
–
–
•
–
–
–
–
•
–
–
–
•
–
–
–
–
•
•
•
If the circuit validation test passes, proceed to Step 14.
If the circuit validation test fails, proceed to Step 2.
Step 2
Step 3
If the settings on the Cisco MGC need to be modified to resolve the error, proceed to Step 4.
If the settings on the associated far-end exchange need to be modified to resolve the error, contact the provider that operates the switch and work with them to resolve the configuration error.
Step 4
prov-rtrv:ss7path:"all"The system returns a message similar to the following:
mgc-01 - Media Gateway Controller 2000-09-26 15:55:17M RTRV"session=active:ss7path"/*NAME DPC MDO CUSTGRPID CUSTGRPTBL SIDE---- --- --- --------- ---------- ----ss7am401a am401a-pc ANSISS7_STANDARD 0000 0101 networkss7am702b am702b-pc ANSISS7_STANDARD 0000 0101 networkss7inet1 inetsp1-pc ANSISS7_STANDARD 0000 0101 networkss7am408a am408a-pc ANSISS7_STANDARD 0000 0101 networkss7am408b am408b-pc ANSISS7_STANDARD 0000 0101 networkss7inet2 inetsp2-pc ANSISS7_STANDARD 0000 0101 networkss7dms dms100-pc ANSISS7_STANDARD 0000 0101 networkss7am401b am401b-pc ANSISS7_STANDARD 0000 0101 networkss7am608b am608b-pc ANSISS7_STANDARD 0000 0101 networkss7sc2200 sc2200-pc ANSISS7_STANDARD 0000 0101 networkThe response lists the SS7 signaling services and their associated DPCs. Search for the DPC associated with the trunk to identify the name of the SS7 signaling service. In the example, dms100-pc is the name of the DPC associated with the trunk. The SS7 signaling service names are in the column to the immediate left of the DPCs, so the name of the associated SS7 signaling service in the example is ss7dms.
Step 5
prov-rtrv:sigsvcprop:name="sig_serv"Where sig_serv is the MML name of the affected signaling service.
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2000-09-26 15:57:29M RTRV"session=active:sigsvcprop"/*adjDestinations = 16AlarmCarrier = 0BOrigStartIndex = 0BothwayWorking = 1BTermStartIndex = 0CctGrpCarrier = 2CGBA2 = 0CircHopCount = 0CLIPEss = 0CotInTone = 2010CotOutTone = 2010CotPercentage = 0dialogRange = 0ExtCOT = LoopForwardCLIinIAM = 1ForwardSegmentedNEED = 1GLARE = 0GRA2 = 0GRSEnabled = falseInternationalPrefix = 0layerRetries = 2layerTimer = 10maxMessageLength = 250mtp3Queue = 1024NationalPrefix = 0NatureOfAddrHandling = 0Normalization = 0OMaxDigits = 24OMinDigits = 0OOverlap = 0OwnClli = naRedirMax = 3restartTimer = 10RoutePref = 0sendAfterRestart = 16slsTimer = 300srtTimer = 300sstTimer = 300standard = ANSI92SwitchID = 0TMaxDigits = 24TMinDigits = 0TOverlap = 0variant = SS7-ANSIVOIPPrefix = 0The response above can be mapped to the response to the circuit validation test in Step 1, as listed below:
•
–
–
–
–
•
–
–
–
•
–
–
–
•
–
–
–
–
Step 6
Step 7
prov-ed:sigsvcprop:name="sig_svc",param_name="param_value",param_name="param_value",...Where:
•
•
•
For example, to change the settings for the COT to per call and seizing (glare) to no circuit control for the ss7dms signaling service, you would enter the following command:
prov-ed:sigsvcprop:name="ss7dms",ExtCOT="Loop", CotPercentage="100",GLARE="0"Step 8
If you need to modify the trunk group properties, proceed to Step 9.
If you do not need to modify the trunk group properties, proceed to Step 12.
Step 9
prov-rtrv:trnkgrp:svc="sig_serv"Where: sig_serv—The MML name of the SS7 signaling service identified in Step 4.
The system returns a message similar to the following:
MGC-01 - Media Gateway Controller 2000-09-26 15:55:17M RTRV"session=active:trnkgrp"/*NAME CLLI SVC TYPE SELSEQ QABLE---- --- --- ----- ------ ------1003 DMS100CLLI ss7dms TDM_ISUP ASC NThe response lists the trunk group associated with the affected SS7 signaling service. The MML name of the trunk group is found in the NAME column. In the example, ss7dms is the name of the SS7 signaling service associated with the trunk. The trunk group names are in the first column, so the name of the associated trunk group in the example is 1003.
Step 10
prov-rtrv:trnkgrpprop:name="trnk_grp"Where: trnk_grp—The MML name of the affected trunk group.
The system returns a message similar to the following:
mgc-01 - Media Gateway Controller 2000-09-26 15:57:29M RTRV"session=active:trnkgrpprop"/*BOrigStartIndex = 1BTermStartIndex = 2CarrierIdentity = 0333CLLI = GR31764KB5CompressionType = 1CotPercentage = 1CustGrpId = V123EchoCanRequired = 0ExtCOT = LoopGLARE = 2Npa = 919RingNoAnswer = 100000SatelliteInd = 0ScreenFailAction = 0*/Step 11
prov-ed:trnkgrp:name="trnk_grp",param_name="param_value",param_name="param_value",...Where:
•
•
•
Note
For example, to change the settings for the COT to per call and seizing (glare) to no circuit control for the trnkgrpdms trunk group, you would enter the following command:
prov-ed:ztrnkgrp:name="trnkgrpdms",ExtCOT="Loop", CotPercentage="100",GLARE="0"Step 12
Step 13
If the response indicates that the test has passed, proceed to Step 14.
If the response indicates that the test has failed, resume performing this procedure from Step 2 and modify the mismatched settings identified in the latest command response.
Step 14
Resolving ISDN D-Channel Discrepancies
When there is a mismatch between the D-channels configured on the Cisco MGC and those configured on the associated media gateway, an ISDN log message is generated. To resolve the log message, complete the following steps:
Step 1
cd $BASEDIR/etcStep 2
For example, if the log message contains the following text:
PROT_ERR_ISDN:Error message from ISDN:Receive MGMT_ERROR_IND for set 1, channel 2854The D-channel number in the example is 2854. Therefore, you would search for occurrences of D-channel 2854 in the data files.
Enter the following command to search the data files for the identified D-channel number:
grep d_num *.datWhere d_num is the D-channel number identified in the alarm message.
The system returns a message similar to the following:
sigChanDev.dat:001002bd 00160002 1 0034015e 00030011 00060001 2854sigChanDev.dat:001002be 00160002 1 0034015e 00030011 00060002 2854The response lists the data file(s) in which the D-channel number found, along with the associated properties. In the example above, the D-channel number, 2854, is found twice in the sigChanDev.dat file. The component IDs are in the column immediately following the data file name. So, in this example, the component IDs are 001002bd and 001002be.
Step 3
Step 2 using the following command:grep comp_ID components.datWhere: comp_ID — A component ID identified in Step 2.
The system returns a message similar to the following:
001002bd 0034015e "bh531-31" "IP link-backhaul svc mgx8260 EAST"The response lists the properties associated with your selected component ID. The MML name for the IP link is in the third column in the response. In the above example, "bh531-31" is the MML name for the IP link.
Step 4
Step 5
prov-rtrv:iplnk:name="ip_link"Where: ip_link — The MML name for an IP link(s) identified in Step 3.
The system returns a message similar to the following:
Media Gateway Controller 2000-06-08 13:49:53M RTRV"session=active:iplnk"/*NAME = bh531-31DESC = IP link-backhaul svc mgx8260 EASTSVC = bh531-3IF = enif1IPADDR = IP_Addr1PORT = 7007PEERADDR = 10.15.26.20PEERPORT = 7007PRI = 1SIGSLOT = 11SIGPORT = 38*/The response lists the properties associated with your selected IP link. The MML name for the signaling service associated with the link is in the SVC field. In the above example, bh531-3 is the MML name for the signaling service. Note the values in the SIGSLOT and SIGPORT fields. These values are used later to determine whether the D-channel is defined on the media gateway.
Step 6
rtrv-dest:sig_servWhere sig_serv is the MML name for a signaling service identified in Step 5.
The system returns a message similar to the following:
Media Gateway Controller 2000-06-08 13:50:26M RTRV"bh531-3:PKG=ISDNPRI,ASSOC=SWITCHED,PST=OOS,SST=UND"Step 7
For example, to determine whether a D-channel is defined for a Cisco MGX8260 media gateway, you would enter the following command:
lsdchan 12.39The values, 12.39, specify the D-channel. These numbers are determined by adding 1 to the SIGSLOT and SIGPORT values identified in Step 5.
The media gateway responds with a message that indicates whether the D-channel is defined.
Step 8
If your provisioning records indicate that the D-channel should exist, proceed to Step 9.
If your provisioning records indicate that the D-channel should not exist, proceed to Step 10.
Step 9
The procedure is finished.
Step 10
Step 11
prov-dlt:iplnk:name="ip_link",...Where ip_link is the MML name(s) for an IP link identified in Step 3.
For example, to delete a D-channel named bh531-31, you would enter the following command:
prov-dlt:iplink:name="bh531-31"Step 12
prov-dlt:ipfaspath:name="sig_serv"Where sig_serv is the MML name for a signaling service identified in Step 5.
For example, to delete a signaling service named bh531-3, you would enter the following command:
prov-dlt:ipfaspath:name="bh531-3"Step 13
Unblocking CICs
You may need to unblock a CIC or a range of CICs on your Cisco MGC. There are two types of blocking on a CIC, local and remote.
Unblocking Locally Blocked CICs
To unblock a single CIC, log in to your active Cisco MGC, start an MML session and enter the following command:
unblk-cic:dest_pc:CIC=numberWhere:
•
•
For example, to unblock CIC number 2, which is associated with a DPC called dpc1, you would enter the following command:
unblk-cic:dpc1:CIC=2To unblock a range of CICs, log in to your active Cisco MGC, start an MML session, and enter the following command:
unblk-cic:dest_pc:CIC=number,RNG=rangeWhere:
•
•
•
Note
For example, to unblock CIC number 1 through 20, which are associated with a DPC called dpc1, you would enter the following command:
unblk-cic:dpc1:cic=1,rng=20To verify that the CIC(s) have been successfully unblocked, retrieve the status of the affected CICs as described in the "Verifying CIC States" section. If the CIC(s) are still blocked, proceed to the "Resetting CICs" section.
Unblocking Remotely Blocked CICs
Generally, you cannot unblock a CIC that has been blocked remotely, because the block was set on the far-end. However, in some instances, a remotely blocked CIC is misreported, and you can fix this by resetting the CIC as described in the "Resetting CICs" section.
Resetting CICs
When trying to clear a blocked CIC or range of CICs, you may need to perform a reset on the affected CIC(s). To reset a single CIC, log in to your active Cisco MGC, start an MML session and enter the following command:
reset-cic:dest_pc:CIC=numberWhere:
•
•
For example, to reset CIC number 2, which is associated with a DPC called dpc1, you would enter the following command:
reset-cic:dpc1:CIC=2To reset a range of CICs, log in to your active Cisco MGC, start an MML session, and enter the following command:
reset-cic:dest_pc:CIC=number,RNG=rangeWhere:
•
•
•
Note
For example, to reset CICs number 1 through 20, which are associated with a DPC called dpc1, you would enter the following command:
reset-cic:dpc1:cic=1,rng=20To verify that the CIC(s) have been successfully reset, retrieve the status of the affected CICs as described in the "Verifying CIC States" section. If the CIC(s) are still blocked, proceed to the "Resolving Stuck CICs" section.
Resolving Stuck CICs
A stuck or hung CIC is a condition that occurs when one or more bearer channels associated with a single call instance refuses to return to the idle call state, despite attempts to manually clear it down using the reset-cic MML command. Stuck CICs are generally caused when transient network glitches or configuration errors trigger protocol state machine errors. Typically these conditions result in a mismatch between the CIC's call state on the Cisco MGC and the call state for the associated span and bearer channel (also known as timeslot) on the media gateway.
The Cisco MGC is capable of automatically detecting and terminating stuck CICs. Refer to the Release Notes for the Cisco Media Gateway Controller Software for more information. With the addition of this functionality, the system runs an audit cron job once a day that verifies, using the sta-aud MML command, that the call states for the CICs on the Cisco MGC match the associated states for the spans and bearer channels on the media gateway. If the audit finds that the Cisco MGC call states on a CIC show that a call is in progress while the associated media gateway span and bearer channel states are idle, the system attempts to release the identified CIC using the stp-call MML command. The stp-call MML command monitors for the release of the CIC. If the CIC is not released within 1 to 2 minutes, the CIC is forcefully released. When a CIC is forcefully released, a minimal CDR is written, with a cause of Temporary Failure.
Note
Note
If you want to run the audit cron job more than once a day, increase the frequency of the audit in the mgcusr crontab entry. You must have system administration authority to use crontab. For more information on crontab, enter the UNIX command, man crontab, on your Cisco MGC.
Note
If you are running a release prior to Release 7.4(11), you must contact the Cisco TAC for assistance in clearing stuck CICs. Refer to the "Obtaining Technical Assistance" section for more information about contacting the Cisco TAC.
Manually Resolving Stuck CICs
If you want to manually resolve stuck CICs, perform the follow steps:
Step 1
Step 2
When you search the active system log file, look for a CP_INFO_CHAN_STATE message containing the following text:
NAS is idle, SC is busyAn example of this log message appears below:
Fri May 25 13:27:45:384 2001 | engine (PID 14217) <Info>CP_INFO_CHAN_STATE:Mismatch in channel state, NAS is idle, SC is busy, span 0, channel 2If you find this kind of CP_INFO_CHAN_STATE message in the active system log file, proceed to
Step 3. Otherwise, contact the Cisco TAC for assistance. Refer to the "Obtaining Technical Assistance" section for more information about contacting the Cisco TAC.Step 3
Audit:failed to audit end pointAn example of these messages appears below:
Fri May 25 13:27:45:384 2001 | engine (PID 14217) <Error>CP_ERR_AUEP:Audit:failed to audit end point nassvc1[00140001]/0/2Fri May 25 13:27:45:384 2001 | engine (PID 14217) <Error>CP_ERR_AUEP:Audit:failed to audit end point dpc1[00130002]/ffff/2In the first message, which contains information on the affected span and bearer channel, the text that immediately follows the word "point" identifies the following:
•
•
•
•
In the second message, which contains information on the affected CIC, the text that immediately follows the word "point" identifies the following:
•
•
•
•
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
If the previously identified CICs are still stuck, proceed to Step 10. Otherwise, proceed to Step 13.
Step 10
kill-call:dest_pc:cic=num,confirm
Caution
Where:
•
•
For example, to forcefully stop a call on CIC 215, which is associated with a DPC called dpc1, you would enter the following command:
kill-call:dpc1:cic=215,confirmRepeat this step for each CIC you have identified as being stuck.
Step 11
kill-call:sig_srv:span=span_num,bc=bear_chan,confirm
Caution
Where:
•
•
•
For example, to forcefully stop a call on bearer channel 2, which is on span 2, and is associated with a signaling service called nassvc1, you would enter the following command:
kill-call:nassvc1:span=2,bc=2,confirmRepeat this step for each bearer channel you have identified as being stuck.
Step 12
If the previously identified CICs are no longer stuck, proceed to Step 13. If these CICs are still stuck, perform a call trace as described in "Performing a Call Trace" section, and contact the Cisco TAC for assistance. Refer to the "Obtaining Technical Assistance" section for more information about contacting the Cisco TAC.
Step 13
Auditing Call States
To run a call state audit, which compares the call states of the CICs on the Cisco MGC with the associated states of the spans and bearer channels on the media gateway, perform the following steps:
Step 1
sta-aud
Note
The results of the call state audit are sent to the active system log file.
Step 2
Step 3
stp-aud
Stopping Calls
You can use the stp-call MML command to stop calls gracefully on all traffic channels associated with a specified system resource. The stp-call MML command is described in the following sections:
Note
•
•
•
•
Stopping Calls on a Cisco MGC
To stop all active calls on all traffic channels on a Cisco MGC, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-call:mgc,confirmWhere mgc is the MML name of the desired Cisco MGC.
For example, to stop all active calls on all traffic channels on a Cisco MGC called mgc1, enter the following command:
stp-call:mgc1,confirmStopping Calls on a Media Gateway
To stop all active calls on all traffic channels on a media gateway, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-call:gway,confirmWhere gway is the MML name of the desired media gateway.
Note
For example, to stop all active calls on all traffic channels on a media gateway called sfgway, enter the following command:
stp-call:sfgwayStopping Calls on a Trunk Group
To stop all active calls on all traffic channels associated with a trunk group, log in to the active
Cisco MGC, start an MML session, and enter the following command:stp-call:trkgrp,confirmWhere trkgrp is the MML name of the desired trunk group.
Note
For example, to stop all active calls on all traffic channels associated with a trunk group called trunkgrp1, enter the following command:
stp-call:trunkgrp1,confirmStopping Calls on a Signaling Service
To stop all active calls on all traffic channels associated with a signaling service, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-call:sig_srv,confirmWhere sig_srv is the MML name of the desired signaling service. The following signaling service types are valid for this command:
•
•
•
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).•
•
For example, to stop all active calls on all traffic channels associated with a signaling service called nassrv1, enter the following command:
stp-call:nassrv1,confirmStopping Calls on Spans
To stop all active calls on all bearer channels associated with a single span, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-call:sig_srv:span=x,confirmWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
For example, to stop all active calls on all bearer channels on a signaling service called ss7svc1 associated with span number 1, enter the following command:
stp-call:ss7svc1:span=1,confirmTo stop all active calls on a bearer channel, or a range of bearer channels, for a span associated with a signaling service, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-call:sig_srv:span=x,bc=y[,rng=range],confirmWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
•
•
For example, to stop all active calls on all bearer channel numbers 2 through 6, associated with a signaling service called ss7svc1, enter the following command:
stp-call:ss7svc1:span=2,bc=2,rng=5,confirmStopping Calls on CICs
To stop all active calls on a CIC, or a range of CICs, associated with a signaling service, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-call:sig_srv:cic=number[,rng=range],confirmWhere:
•
–
–
–
Cisco MGC over IP (that is, FE box<-sig/tdm->media gateway<-NI2/IP-> Cisco MGC).–
–
•
•
For example, to stop all active calls on CICs 2 through 11, associated with a signaling service called ss7svc1, enter the following command:
stp-call:ss7svc1:cic=2,rng=9,confirmAuditing an MGCP Media Gateway
You can audit an MGCP media gateway from the Cisco MGC. The procedure to audit an MGCP media gateway is described in the following sections:
•
•
Starting an MGCP Media Gateway Audit
You can run an audit on a single MGCP media gateway, or on all of your provisioned MGCP media gateways. The Cisco MGC does not prompt you to indicate when the audit is complete. Please wait a few moments before retrieving the audit results as described in the "Retrieving an MGCP Media Gateway Audit" section.
To run an audit on a single MGCP media gateway, log on to the active Cisco MGC, start an MML session, and enter the following command:
sta-aud-gw:MGCP_sig_srvWhere MGCP_sig_srv is the MML name of the MGCP signaling service associated with the MGCP media gateway.
For example, to start an audit on an MGCP media gateway associated with an MGCP signaling service called T-1-16, you would enter the following command:
sta-aud-gw:T-1-16To run an audit all of your MGCP media gateways, log on to the active Cisco MGC, start an MML session, and enter the following command:
sta-aud-gw:allRetrieving an MGCP Media Gateway Audit
You can retrieve an audit for a single MGCP media gateway, or for audits on all of your MGCP media gateways. To retrieve an audit for a single MGCP media gateway, log on to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-aud-gw:MGCP_sig_srvWhere MGCP_sig_srv is the MML name of the MGCP signaling service associated with the MGCP media gateway.
For example, to retrieve an audit on an MGCP media gateway associated with an MGCP signaling service called T-1-16, you would enter the following command:
rtrv-aud-gw:T-1-16The system returns a response similar to the following:
Media Gateway Controller - MGC-01 2000-01-12 15:19:51M COMPLD"SP1-MGCP1:Audit gw received at 2000-01-12 15:19:51Audit GW PASSEDpass pnpass pt - not alarmedpass sl - not alarmedpass nlpass bppass cppass rppass nbpass ucpass icpass uspass is"The response indicates whether the audit has passed or failed. If the audit has failed, refer to the documentation for the associated MGCP media gateway for more information on troubleshooting the identified problem.
To retrieve audits run on all of your MGCP media gateways, log on to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-aud-gw:allThe system returns a response similar to the one shown above, with a set of data for every MGCP media gateway associated with your system.
Running a Manual Continuity Test
To run a manual continuity test (COT) on a specified remote switch CIC, log in to the active Cisco MGC, start an MML session, and enter the following command:
tst-cot:pt_code:cic=numberWhere:
•
•
For example, to run a manual COT on CIC number 5 of a DPC named dpc1, you would enter the following command:
tst-cot:dpc1:cic=5If the manual COT test should fail, verify the COT settings for the Cisco MGC and the associated media gateway, as described in the "Verifying Continuity Test Settings" section.
Verifying Continuity Test Settings
Step 1
prov-rtrv:component:name="comp_name"Where:
•
–
–
•
For example, if you wanted to verify the properties for an SS7 signaling service called ss7svc1, you would enter the following command:
prov-rtrv:sigsvcprop:name="ss7svc1"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:sigsvcprop"/*adjDestinations = 16AlarmCarrier = 0BOrigStartIndex = 0BothwayWorking = 1BTermStartIndex = 1CctGrpCarrier = 2CGBA2 = 0CircHopCount = 0CLIPEss = 0CotInTone = 2010CotOutTone = 2010CotPercentage = 0CustGrpId=2222dialogRange = 0ExtCOT = LoopForwardCLIinIAM = 1ForwardSegmentedNEED = 1...Step 2
Step 3
prov-ed:component:name="comp_name",cot_prop=value,cot_prop=value,...Where:
•
–
–
•
•
•
Step 4
Step 5
If debugging the COT settings on the media gateway does not reveal any problems, or does not fix the COT failure, proceed to Step 6.
Step 6
Resolving an SRCP Audit Alarm
If an SRCP audit alarm should occur on your Cisco MGC, use the following procedure to resolve the problem:
Step 1
If the SRCP heartbeat is up and working, proceed to Step 2.
If the SRCP heartbeat is not up and working, restart the SRCP heartbeat. If that does not resolve the alarm, proceed to Step 3.
Step 2
If the configuration of your media gateway is incorrect, modify the configuration. The procedures for modifying the configuration of the media gateway can be found in the documentation for the media gateway.
If the configuration of the media gateway is correct, proceed to Step 3.
Step 3
Media Gateway IP Destination/Link Out-of-Service
If an IP link or destination to a media gateway is out-of-service, perform the following steps:
Note
Step 1
ping link_addrWhere link_addr is the IP address of the affected MGC link.
Repeat this step if the second link for the destination is also out-of-service.
If the links are unreachable, proceed to Step 2. Otherwise, proceed to Step 3.
Step 2
If your system is using Cisco SLTs to terminate the SS7 link, proceed to Step 4.
Step 3
Step 4
If the MGCP interface on your media gateway is working properly, proceed to Step x. Otherwise, correct the problems with the MGCP interface as described in the documentation associated with the media gateway.
Step 5
Step 6
If the RLM group is defined, proceed to Step 7. Otherwise, add the RLM group to the D-channel serial interface. Refer to the documentation associated with the media gateway for more information.
If the link(s) returns to service, the procedure is complete. Otherwise, proceed to Step 7.
Step 7
If the link(s) return to service, the procedure is complete. Otherwise, proceed to Step 8.
Step 8
If RLM messages are being acknowledged by the Cisco MGC, proceed to Step 10. Otherwise, proceed to Step 9.
Step 9
prov-rtrv:iplnk:"all"The system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-07-26 12:57:48M RTRV"session=active:iplnk"/*NAME SVC IF IPADDR PORT PEERADDR PEERPORT PRI SIGSLOT SIGPORT NEXTHOP NETMASK---- --- -- ------ ---- -------- -------- --- ------ ------- ------- -------va-5300-202-1 va-5300-202 enif1 IP_Addr1 3001 172.24.200.19 3001 1 0 0 0.0.0.0 255.255.255.255va-5300-202-2 va-5300-202 enif1 IP_Addr1 3001 172.24.200.19 3001 1 0 0 0.0.0.0 255.255.255.255va-5300-203-1 va-5300-203 enif1 IP_Addr1 3001 172.24.200.20 3001 1 0 0 0.0.0.0 255.255.255.255va-5300-203-2 va-5300-203 enif1 IP_Addr1 3001 172.24.200.20 3001 1 0 0 0.0.0.0 255.255.255.255*/Ensure that the IP addresses (IPADDR and PEERADDR) and the ports (PORT and PEERPORT) match the values used by the media gateway. If the values match, proceed to Step 10.
Otherwise, if the changes need to be made on the media gateway, refer to the documentation for your media gateway for more information. If the changes need to be made on the Cisco MGC, start a dynamic reconfiguration session to make your changes, as described in the "Invoking Dynamic Reconfiguration" section.
If the changes resolve the problem, the procedure is complete. Otherwise, proceed to Step 10.
Step 10
CIC Mismatch (One-Way Audio)
If there is a mismatch between the CICs on your system and the far-end, perform the following steps:
Step 1
prov-rtrv:trnktype:"all"Where trnktype is the type of trunk used on your system. Valid values are:
•
•
Note
For a nailed trunk configuration, the system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2001-07-26 14:21:40M RTRV"session=active:nailedtrnk"/*NAME SRCSVC SRCSPAN SRCTIMESLOT(CIC) DSTSVC DSTSPAN DSTTIMESLOT(CIC)---- ------ ------- ---------------- ------ ------- ----------------1 ss7svc1 ffff 1 va-5300-202 0 12 ss7svc1 ffff 2 va-5300-202 0 23 ss7svc1 ffff 3 va-5300-202 0 34 ss7svc1 ffff 4 va-5300-202 0 45 ss7svc1 ffff 5 va-5300-202 0 56 ss7svc1 ffff 6 va-5300-202 0 67 ss7svc1 ffff 7 va-5300-202 0 78 ss7svc1 ffff 8 va-5300-202 0 89 ss7svc1 ffff 9 va-5300-202 0 910 ss7svc1 ffff 10 va-5300-202 0 1011 ss7svc1 ffff 11 va-5300-202 0 1112 ss7svc1 ffff 12 va-5300-202 0 1213 ss7svc1 ffff 13 va-5300-202 0 1314 ss7svc1 ffff 14 va-5300-202 0 14For a switched trunk configuration, the system returns a response similar to the following:
MGC-100 - Media Gateway Controller 2001-07-30 09:47:28M RTRV"session=cotegress:switchtrnk"/*NAME SPAN CIC TRNKGRPNUM CU ENDPOINT---- ---- --- ---------- -- --------1 ffff 1 3005 mgx-7-6 vism/e1-1/1@mgx7-62 ffff 2 3005 mgx-7-6 vism/e1-1/2@mgx7-63 ffff 3 3005 mgx-7-6 vism/e1-1/3@mgx7-64 ffff 4 3005 mgx-7-6 vism/e1-1/4@mgx7-65 ffff 5 3005 mgx-7-6 vism/e1-1/5@mgx7-66 ffff 6 3005 mgx-7-6 vism/e1-1/6@mgx7-67 ffff 7 3005 mgx-7-6 vism/e1-1/7@mgx7-68 ffff 8 3005 mgx-7-6 vism/e1-1/8@mgx7-69 ffff 9 3005 mgx-7-6 vism/e1-1/9@mgx7-610 ffff 10 3005 mgx-7-6 vism/e1-1/10@mgx7-611 ffff 11 3005 mgx-7-6 vism/e1-1/11@mgx7-612 ffff 12 3005 mgx-7-6 vism/e1-1/12@mgx7-613 ffff 13 3005 mgx-7-6 vism/e1-1/13@mgx7-614 ffff 14 3005 mgx-7-6 vism/e1-1/14@mgx7-6If these settings do not match those used by the far-end, start a dynamic reconfiguration session, as described in the "Invoking Dynamic Reconfiguration" section, and correct your settings. Otherwise, proceed to Step 2.
If that resolves the mismatch, the procedure is complete. Otherwise, proceed to Step 2.
Step 2
Calls Fail at the Cisco MGC
If calls appear to be failing at the Cisco MGC, and the calls are not appearing on the associated media gateway, perform the following steps:
Step 1
If the calls in question do not appear on the media gateway, proceed to Step 2. Otherwise, resolve the problems with the interface as described in the documentation for the associated media gateway.
Step 2
If any of the signaling channels are out-of-service, attempt to bring them into service using the appropriate procedures. Otherwise, proceed to Step 3.
Step 3
Modifying Redundant Link Manager Timers
As of Release 7.4(12), you can modify the values of your Cisco MGC's redundant link manager (RLM) timers. Refer to the Release Notes for Cisco Media Gateway Controller Software for more information.
If you want to change these timers, you must change them on the Cisco MGC and on the associated media gateway(s). To change the RLM timers, perform the following steps:
Note
Step 1
Cisco MGC, starting an MML session, and entering the following command:prov-rtrv:lnksetprop:name="mgc_name"Where mgc_name is the MML name of the Cisco MGC host.
The system returns a response similar to the following:
MGC-01 - Media Gateway Controller 2001-07-27 11:00:06M RTRV"session=active:lnksetprop"/*linkEchoRetry = 3linkLatencyTest = 600linkOpenWait = 30linkRecovery = 120linkSwitch = 50linkUpRecoveredMin = 600port = 3000PropagateSvcMsgBlock = falsetimerCmdAck = 10timerLinkDownMin = 100timerLinkEcho = 10unstableLink = 10*/All of the properties listed, except for port and PropagateSvcMsgBlock, are RLM timer properties.
Step 2
Step 3
prov-ed:lnkset:name="mgc_name",prop_name="value",prop_name="value",...Where:
•
•
•
Step 4
Step 5
Tracing
Tracing on the Cisco MGC is described in the following sections:
Performing a Call Trace
After checking all physical connections, signal links, bearer channels, and destinations, the person who is troubleshooting the Cisco MGC begins to suspect that the call engine is part of the problem. Performing a call trace while making a call provides details about what is occurring inside the call engine and indicates where the breakdown is occurring (if it is occurring within the call engine).
Call tracing is described in the following sections:
•
Starting A Call Trace
To start the call trace, perform the following steps:
Step 1
This command can be entered in any one of five different formats:
1.
2.
3.
4.
5.
Where:
•
•
•
If no log= parameter is used, default filenameprefix values are used for each sta-sc-trc command. For example:
–
sig_path_yyyymmddhhmmss.btr
–
trkgrp_sig_path_yyyymmddhhmmss.btr
Where the filename (yyyymmddhhmmss) is a time stamp, organized as follows:
–
–
–
–
–
–
•
•
•
•
•
•
The following paragraphs present examples of each of the five possible command variations:
1.
sta-sc-trc:sig_path:log="filenameprefix", prd=600, confirmIn this form of the command, the confirm parameter is required.
2.
sta-sc-trc:sig_path:span=xThe confirm parameter is not needed in this form of the command because the volume of the trace file should not be an issue, nor should system performance.
3.
sta-sc-trc:sig_path:span=x,tc=y4.
sta-sc-trc:trkgrp:confirmThis form of the command requires the confirm parameter.
5.
sta-sc-trc:trkgrp:trk=w
Note
Step 2
Stopping A Call Trace
You can stop a call trace session using the stp-sc-trc MML command. To stop a call trace session on a particular signaling service, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-sc-trc:sig_srv|trkgrpWhere:
•
•
For example, to stop a call trace session on a trunk group called T-1-1, you would enter the following command:
stp-sc-trc:T-1-1To stop all call trace sessions, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-sc-trc:allThe system returns a response similar to the following:
Media Gateway Controller 2000-03-21 15:28:03M COMPLD"ALL:Trace stopped for the following files:../var/trace/_dpc1_20000321152752.btr"Retrieving Names of Open Call Trace Files
To retrieve the names of call trace files for sessions that are in progress, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-sc-trcThe system returns a response similar to the following:
Media Gateway Controller 2000-03-21 15:28:03M RTRV"RTRV-SC-TRC:Trace in progress for the following files:../var/trace/_dpc1_19991221131108.btr../var/trace/sigtest_dpc2_19991221131109.btr"Viewing the Call Trace
The MML command sta-sc-trc produces .btr (binary trace) files, which cannot be viewed with a text editor. The main part of the file name is set up in the sta-sc-trc command, as explained in the "Starting A Call Trace" section, and the Cisco MGC adds the .btr extension to these files. The .btr files can contain tracings from many calls all mixed together. Each tracing record in the file has a specific record type and records information of the type that relates to that record. Each record has a unique call ID that relates it to a specific call and is a recording of the external events that the MDL call model was exposed to while the recording was made. Each tracing record is not a recording of the actual MDL.
You can use the trace viewer to view and navigate through call trace outputs. For more information on using the trace viewer, refer to the "Using the Trace Viewer" section.
You can also view the call trace output data using the get_trc.sh UNIX script. Get_trc.sh uses the Conversion Analyzer and SimPrint utilities in combination to give a single common interface to all the trace tools. Get_trc.sh makes considerable use of the UNIX less utility for displaying file output and it is assumed that less is available on the system. You can start the script by entering the following UNIX command:
get_trc.sh filenameWhere filename is the name of the call trace output data file (.btr) you want to view.
The script then displays a list of commands and prompts you to enter a command. The following commands are listed:
•
•
•
•
•
•
•
•
•
•
•
Deleting Call Trace Files
Call trace files can be rather large, and leaving these files on your disk after you no longer require them could raise capacity issues. Call trace files are deleted using UNIX commands, as described in the "Deleting Unnecessary Files to Increase Available Disk Space" section.
Understanding the Call Trace
Call traces record information in a trace file that shows how the Cisco MGC processed a specific call. Traces are most useful when you can be sure that a problem call is reaching the call engine and starting an instance of a Message Definition Language (MDL) state machine. You can determine whether the problem call is reaching the call engine by looking for the presence of non-idle circuits (rtrv-cic) or "new cmgCall" entries in the debug logs.
After you start a trace, all call-processing activity for calls originating from the specified destination is captured. This allows you to follow the call through the Cisco MGC to see where it fails.
The trace output is in binary format. It shows:
•
•
•
Using call trace logs is easy if you remember how to locate the record of a call:
•
•
If you are experiencing problems with call processing and need to contact Cisco for support, you should run a call trace before contacting Cisco's TAC. The trace file helps the Cisco TAC troubleshoot the problem more effectively. For some problems, the Cisco TAC cannot begin troubleshooting the problem until you supply the trace file, so it is a good practice to create this file before contacting them.
Understanding the Conversion Analyzer
The Conversion Analyzer is a viewer utility for .btr trace files. The Conversion Analyzer displays each record from a .btr file in a readable form (ASCII text) that can be viewed with any text editor; however, some useful sorting and display options are also available.
The .btr files serve as source files for .ca files. The .ca files are ASCII text output from the Conversion Analyzer obtained by redirection of the standard output to a file. There are two main sections in a .ca file. The header section contains a list of every signaling path defined on the Cisco MGC and a list of the message definition object (MDO) modules that are loaded. The main body contains a printout of every record. Each record has a record number, a timestamp, a call ID, and the print data that the record contains.
Understanding the Simulator Utility
The Simulator is a powerful MDO file processing utility that uses .mdo files to replay the events recorded in a .btr file. The front end of the Simulator reads the .btr file. The interpreter in the Simulator utility that loads the .mdo files and replays the events (.btr files) through the MDO, is the same interpreter used by the call engine in the Cisco MGC when .mdo files are used. As the interpreter steps through each line of object code (and the action of each object is interpreted) in the .mdo file, each object's print method is activated, which forms the next line of text in the .trc file.
The print method for each object contains text that directly relates to the appearance of the .mdl source code that produced the object in the .mdo file (through compilation of the .mdl source code with the MDL compiler). The .mdo files used with the Simulator when it is processing a .btr file to create a .trc file, must be the same .mdo files that were in use when the .btr file was originally recorded on the
Cisco MGC. This is why the conversion from a .btr file to a .trc file is usually done on the Cisco MGC that originated the .btr file.The interpreter is not used with .so files because those files interact directly with the call engine in the Cisco MGC, but the tracer can record a .btr file regardless of whether .mdo or .so files were used to process the call. The Simulator can, however, replay .btr files using .so files in place of .mdo files. This is a way of checking that the .so and .mdo files perform in exactly the same way, although .so is faster.
Because .so files do not contain MDO objects, there are no print methods available to the Simulator, so no .trc output is possible. When a .btr file is produced by a Cisco MGC using .so files, the replay in the Simulator must be done with the .mdo files that were used to produce the .so files in order to produce an accurate .trc file.
Understanding Trace Files
Trace files (.trc files) are text files that are produced by the Simulator utility. They contain detailed line by line trace information from the MDO code that was run in the simulation replay that produced the file, thus they contain MDL traces. The .trc extension is added by the get_trc.sh script if the source of the trace is a .btr file.
Trace files are source files for the SimPrint (SP) utility. They are text files and can be viewed with a text editor. The .trc file should be sent to Cisco TAC if expert analysis is required.
Understanding SimPrint
SimPrint (SP) is a viewing utility for .trc files. SP converts a .trc file into a sequence diagram that shows all of the external and internal events that occur in a .trc file. This is useful for getting an overview of what is occurring in the trace.
The following list defines the terms used in the call flow printouts generated by the SimPrint tool:
•
•
•
•
•
•
•
•
•
Alternatives to Call Tracing
Performing call traces to identify problems can be difficult due to the large amount of data the trace may gather before the error occurs, and the negative impact performing call traces has on system performance. The Cisco MGC software has MML commands that can be used to diagnose problems with hung calls and abnormal call termination. The following sections describe those commands.
Diagnosing Hung Calls
You can print the diagnostic information about hung calls to a file using the prt-call MML command. The contents of the file include all of the previous states of the call and a history of occurrences leading up to the call being stuck in its current state.
To print diagnostic information on a hung call, complete the following steps:
Step 1
prt-call:sig_path:cic=number [,log=xyz]or
prt-call:sig_path:span=phys, bc=bchan [,log=xyz]Where:
•
–
–
–
–
–
Note
•
•
•
•
For example, the following MML command prints call data for a signaling path called dms100-pc using a CIC of 124:
prt-call:dms100-pc:cic=124The output for this command is stored in a file called pc_timestamp.prt, where timestamp is the time of the file's creation.
Step 2
cd /opt/CiscoMGC/var/traceStep 3
Performing an Abnormal Call Termination Trace
You can print the global variable information from the state machine and external event information for a call to a file using the sta-abn-trc MML command. To print this information, complete the following steps:
Step 1
sta-abn-trc:sig_path|all[,log=xyz] [,prd=n],confirmWhere:
•
–
–
–
–
–
Note
•
•
•
For example, the following MML command prints call data for a signaling path called dms100-pc to a file named trace1 (since the period parameter, n, is not entered, the trace lasts for the default period, 30 seconds):
sta-abn-trc:dms100-pc,log=trace1,confirmStep 2
cd /opt/CiscoMGC/var/traceStep 3
Stopping an Abnormal Call Termination Trace
You can stop an in-progress abnormal call termination trace using the stp-abn-trc MML command. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-abn-trc:sig_srvWhere sig_srv is the MML name for a signaling service on which an abnormal call termination trace is being run.
For example, to stop an abnormal call termination trace being run on a signaling service called ss7srv1, you would enter the following command:
stp-abn-trc:ss7srv1The system responds with a response similar to the following:
Media Gateway Controller 2000-05-26 07:02:11M COMPLD"Trace stopped for the following file:../var/trace/_20000526070211.abn"To stop all in-progress abnormal call termination traces, log in to the active Cisco MGC, start an MML session, and enter the following command:
stp-abn-trc:allThe system returns a response similar to the following:
Media Gateway Controller 2000-05-26 07:02:11M COMPLD"ALL:Trace stopped for the following files:../var/trace/_20000526070211.abn"Performing a TCAP Trace
To run a TCAP trace on your system, perform the following steps:
Step 1
sta-tcap-trcThe system begins sending TCAP trace messages to the active system logs file.
Step 2
Step 3
stp-tcap-trc
Platform Troubleshooting
The following sections contain procedures related to resolving problems with the Cisco MGC platform:
•
•
•
•
•
•
•
•
•
•
Deleting Unnecessary Files to Increase Available Disk Space
You may need to delete call trace files, archived log files, or configurations from your system to create more available disk space on your Cisco MGC.
The following procedure steps you through the process of deleting all three file types.
Step 1
cd /opt/CiscoMGC/var/tracelsThe system responds with a list of files in the directory. If the command response indicates that there are *.btr and *.trc files stored in this directory, then proceed to Step 2. Otherwise, proceed to Step 4.
Note
Step 2
rm -i filenameWhere filename is the name of the call trace file (either *.btr or *.trc) you have identified for deletion.
Step 3
Step 4
cd /opt/CiscoMGC/var/spoollsThe system responds with a list of files in the directory. Review the listed files. If there are archived log files listed that are no longer required, proceed to Step 5. Otherwise, proceed to Step 7.
Note
Step 5
rm -i filenameWhere filename is the name of the archived log file you have identified for deletion.
Step 6
Step 7
Recovering from a Switchover Failure
Use the procedure in this section to recover from a failed switchover operation. You would typically use this procedure when the standby Cisco MGC is unavailable to process calls and a critical alarm occurs on the active Cisco MGC.
To recover from a switchover failure, complete the following steps:
Step 1
Step 2
If there is only one critical alarm listed, that alarm caused the switchover attempt.
If there is more than one critical alarm listed, compare the timestamp of the critical alarms with the timestamp of the alarm indicating that a switchover began. The critical alarm that occurred before the switchover was begun is the alarm that caused the switchover attempt.
Step 3
Step 4
Step 5
If resolving the alarms does not stabilize the standby Cisco MGC, proceed to Step 6.
Step 6
ping standby_addrWhere standby_addr is the IP address of the standby Cisco MGC.
If the ping fails, proceed to Step 7. Otherwise, proceed to Step 8.
Step 7
If an element of the Ethernet interfaces between the active Cisco MGC and the standby Cisco MGC is found to be faulty, replace it. Otherwise, proceed to Step 8. Refer to the Sun Microsystems documentation that came with your system for more information.
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 8.
Step 8
# echo host_name > /etc/hostWhere host_name is a unique name for the Cisco MGC host.
Step 9
•
•
•
•
•
•
•
If the IP address settings are correct, proceed to Step 10. Otherwise, update the IP address parameters for each host , using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 10.
Step 10
foverd.conn1Type = socketfoverd.ipLocalPortA = 1051foverd.ipPeerPortA = 1052foverd.conn2Type = socketfoverd.ipLocalPortB = 1053foverd.ipPeerPortB = 1054foverd.conn3Type = serialfoverd.conn3Addr = /dev/nullfoverd.abswitchPort = (/dev/null)foverd.heartbeatInterval = 4000If the foverd settings are correct, proceed to Step 11. Otherwise, update the foverd settings in the XECfgParm.dat files using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 11.
Step 11
Recovering from Cisco MGC Host(s) Failure
There are situations, such as a replacement of a failed disk drive, natural or man-made disaster, or software corruption, that make it necessary for you to recover the software configuration data for a failed Cisco MGC host or hosts. (for example, if the Cisco MGC software has become corrupted or you have replaced a failed disk drive).
Note
Note
The following sections contain the procedures that describe how to recover from Cisco MGC host(s) failure:
•
•
•
Recovering from a Cisco MGC Host Failure in a Simplex System
To recover from a Cisco MGC host failure in a system equipped with only one Cisco MGC, perform the following steps:
Step 1
Step 2
Step 3
Note
Note
Step 4
Recovering from a Single Cisco MGC Host Failure in a Continuous Service System
To recover from a single Cisco MGC host failure in a system equipped with two Cisco MGCs, perform the following steps:
Step 1
Step 2
Step 3
Note
Step 4
Step 5
Step 6
Step 7
Step 8
Cisco MGCs. Refer to the "Obtaining Technical Assistance" section for more information on contacting the Cisco TAC.h
Recovering from a Dual Cisco MGC Host Failure in a Continuous Service System
To recover from a dual Cisco MGC host failure in a system equipped with two Cisco MGCs, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Note
Step 12
Step 13
Step 14
Step 15
Step 16
Cisco MGCs. Refer to the "Obtaining Technical Assistance" section section for more information on contacting the Cisco TAC.
Restoring Stored Configuration Data
Typically, restoration of stored configuration data is performed in severe troubleshooting situations where the Cisco MGC is not functioning properly, due to hardware failure, natural disaster, or software corruption. The procedures in this section describe how to restore the Cisco MGC configuration data stored either on a tape drive or on a remote network server.
There are two restoration methods available for the Cisco MGC software, one for software releases up to 7.4(10), and another for software releases from 7.4(11) and above. These restoration procedures are mutually exclusive. You cannot use the restoration procedures for one software release to restore files backed up using the procedures specific to the other release.
These restoration methods are described in the following sections:
•
•
Restoring Procedures for Cisco MGC Software up to Release 7.4(10)
This restoration method uses a script to restore the configuration data for the Cisco MGC software from either a local tape drive or on to a remote machine. Restoration of the Main Memory Database (MMDB) is performed by a separate script.
The following sections provide the restoration procedures:
•
•
•
Note
Restoring Data from a Local Tape Drive
This procedure restores everything on a tape in a local tape drive to the Cisco MGC base directory.
Caution
To restore the contents of the entire Cisco MGC software directory from a local tape, complete the following steps:
Step 1
./restore.shThe system returns a response similar to the following:
MGC restore utility-----------------------------Source currently set to Local tape (/dev/rmt/0h)Enter:<N> set source to remote NFS server<L> set source to Local tape (/dev/rmt/0h)<R> for Restore<Q> to quitSelect restore mode:Step 2
Are you sure you want to restore a backup.Current data in the MGC directory will be overwritten and lost.Answer(Y/N):Step 3
Answer(Y/N): yx ., 0 bytes, 0 tape blocksx ./var, 0 bytes, 0 tape blocksx ./var/log, 0 bytes, 0 tape blocksx ./var/log/platform.log, 117 bytes, 1 tape blocksx ./var/log/mml.log, 187 bytes, 1 tape blocks....#Step 4
Step 5
Step 6
Restoring Data from a Remote Machine over the Network
This procedure restores files to the Cisco MGC software base directory from a file on an NFS mountable directory on a remote machine. The remote machine must be set up with an NFS mountable directory that can be written to by the machine being backed up. The NFS setup of the remote machine is beyond the scope of this procedure.
To restore the contents of the Cisco MGC software directory from a remote machine, complete the following steps:
Step 1
./restore.shThe system returns a response similar to the following:
MGC restore utility-----------------------------Source currently set to Local tape (/dev/rmt/0h)Enter:<N> set source to remote NFS server<L> set source to Local tape (/dev/rmt/0h)<R> for Restore<Q> to quitSelect restore mode:Step 2
Step 3
Enter server name: remote_hostnameWhere: remote_hostname—Name of the remote server where the backups are stored.
The system then prompts you to enter the name of the associated directory on the remote server.
Step 4
Enter remote directory : remote_directory_nameWhere: remote_directory_name—Name of the directory path on the remote server where the backups are stored.
The system returns a response similar to the following:
Enter server name: va-panthersEnter remote directory : /backupMGC restore utility-----------------------------Source currently set to remote NFS server (va-panthers:/backup)Enter:<N> set source to remote NFS server<L> set source to Local tape (/dev/rmt/0h)<R> for Restore<Q> to quitThe system then prompts you to select the restore mode.
Select restore mode:Step 5
mount -F nfs -o retry=3 va-panthers:/backup /mntAvailable files:va-blade20000317105201P.tarva-blade20000317105337.tarThe system then prompts you to enter the filename to be restored.
Enter filename to restore from:Step 6
Note
The system then asks you if you really want to restore a backup:
Are you sure you want to restore a backup.Current data in the MGC directory will be overwritten and lost.Answer(Y/N):Step 7
x etc, 0 bytes, 0 tape blocksx etc/Copyright, 545 bytes, 2 tape blocksx etc/CONFIG_LIB, 0 bytes, 0 tape blocksx etc/CONFIG_LIB/new, 0 bytes, 0 tape blocks..restore from va-panthers:/backup/va-blade20000317105337.tar complete#Step 8
Step 9
Restoring Data to the Main Memory Database
Use this procedure to restore dial plan data, which was stored in the MMDB, in a single file as described in the "Performing a Backup Operation on the Main Memory Database" section on page 3-32.
Step 1
cd /opt/CiscoMGC/localStep 2
ttreplicStep 3
./restoreDb.sh filenameWhere filename is the name of the database backup file.
For example, to restore the contents of a file called dplan to the MMDB, you would enter the following command:
./restoreDb.sh dplanThe system returns a response similar to the following:
Restoring database contents for DSN=howdydb into dplanThe Restore process is being initiated for the datastore howdydbFiles for /opt/TimesTen32/datastore/howdydb are being restored up onto standard outputRestore CompleteStep 4
ttreplic
Restoring Procedures for Cisco MGC Software Release 7.4(11) and up
This restoration method uses a script to restore the configuration data for the Cisco MGC software, select UNIX administrative files, and the Main Memory Database (MMDB).
Note
The following sections provide the restoration procedures:
•
•
Note
Listing Backup Files
To list the backup files in a particular directory path, enter the following UNIX command on the
Cisco MGC:mgcrestore -d path -lWhere path is the directory path in which you have stored backup files, such as a directory on a remote server or a local tape drive.
The system returns a response similar to the following:
Backup files in /var/cisco--------------------------------------------------mgc_venus_20011010_153003_backup.tarmgc_venus_20011011_153003_backup.tarmgc_venus_20011012_153003_backup.tarRestoring a Backup File
To restore the configuration data stored in a particular backup file, enter the following UNIX command on the affected Cisco MGC to run the restore script:
mgcrestore -d path -f filenameWhere:
•
•
For example, to restore a backup file called mgc_venus_20011012_153003_backup.tar stored in a directory path called /var/cisco, you would enter the following command:
mgcrestore -d /var/cisco -f mgc_venus_20011012_153003_backup.tar
Verifying Proper Configuration of Replication
If calls are not being preserved when your system performs a switchover, you should verify that your system is properly configured for replication of call data. To do this, verify that the value of the parameters in the XECfgParm.dat file on each host match the settings listed below, using the procedure in the "Rebooting Software to Modify Configuration Parameters" section.
*.SyscheckpointEnabled = truereplicator.portDataChannelSend = 2968replicator.portDataChannelRecv = 2970replicator.portCommChannelSend = 2972replicator.portCommChannelRecv = 2974replicator.reconnectInterval = 15replicator.numberReadThreads = 1Measurements Are Not Being Generated
If your Cisco MGC is not generating system measurements, perform the following procedure:
Step 1
If the amdmpr process is not running, proceed to Step 2. Otherwise, proceed to Step 3.
Step 2
Step 3
Call Detail Records Are Not Being Generated
If call detail records are not being generated on your Cisco MGC, perform the following steps:
Step 1
If the dmpr-01 process is not running, proceed to Step 2. Otherwise, proceed to Step 4.
Step 2
If that clears the alarm, the procedure is finished. Otherwise, proceed to Step 3.
Step 3
cdrDmpr.openCDR = truecdrDmpr.callDetail = /opt/CiscoMGC/local/cdbscript.shcdrDmpr.seqFile = ../var/.cdr.seqdiskmonitor.CdrRmFinished = 0 # remove "finished" cdrs after X days (0 = immediate)engine.CDRencodingFormat = AnsiCDBengine.CDRtimeStamp = Sengine.CDRmessageTypes = "1010,1020,1030,1040,1050,1060,1070"Step 4
Rebooting Your System to Modify Properties
When you are modifying certain properties on the Cisco MGC, it is required that you reboot your system as part of the modification process. To reboot your system as part of a property modification process, perform the following steps:
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
prov-syncStep 9
Step 10
cd /opt/CiscoMGC/etcStep 11
Step 12
Step 13
Step 14
Step 15
Rebooting Software to Modify Configuration Parameters
Sometimes you may need to change your configuration settings in the XECfgParm.dat file while the system is in-service. To do this, perform the following procedure:
Caution
Step 1
cd /opt/CiscoMGC/etcStep 2
Step 3
Step 4
Step 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
Resolving a Failed Connection to a Peer
If you have lost connection to a peer component in your network, perform the following procedure to resolve the problem:
Step 1
If the destination is in-service, or there is no destination associated with the peer, proceed to Step 2.
If the destination associated with the peer is out-of-service, bring the destination back into service, as described in the "SS7 Destination is Out of Service" section.
Note
If that resolves the problem, this procedure is complete. Otherwise, proceed to Step 2.
Step 2
traceroute ip_addrWhere ip_addr is the IP address of the affected peer.
The system responds with a listing of the peers that are passed through on route to the identified peer.
If the system response indicates that the identified peer was reached with no problems, proceed to Step 4.
If the system response indicates that you were unable to reach the identified peer, proceed to Step 3.
Step 3
If the Ethernet interfaces are working properly, proceed to Step 4.
If the Ethernet interfaces are not working properly, replace the element that is not working properly. Refer to the documentation of the peer for more information. If that resolves the problem, the procedure is complete. Otherwise, proceed to Step 4.
Step 4
Feedback