Table Of Contents
Configuring the Cisco MGC Software
Quick Guide to Configuring the Cisco MGC Software
Before You Start
Software Directory Structure
Initial Cisco MGC Software Configuration
Parameters Required for Initial Setup
Using the Cisco MGC Environment Configuration Tool
Configuring Groups and Users
Verifying the mgcgrp Group
Adding a User with Full MML Privileges
Adding a User with Minimal MML Privileges
Configuring SNMP Support Resources
Migrating the SNMP Configuration to a More Secure Environment (for MGC 9.3(2) or Later)
Basic Tasks
Before You Run the config-snmp Utility
Running the config-snmp Utility
Adding an SNMP Community Entry
Deleting an SNMP COMMUNITY
Adding a Trap Destination
Deleting a Trap Destination
Activating the New Settings
Verifying the SNMP Configuration Migration
Setting up the SNMP Community for Software Releases Before Cisco MGC 9.3(2)
Adding a New Community
Setting the Destination for Traps
Configuring SNMP Entries
Configuring the Execution Environment
Changing XECfgParm.dat File Parameters
Changing XECfgParm.dat File Parameters in a Running Fault Tolerant System
Configuring Basic System Information
Specifying IP Addresses
Configuring Engine Parameters
Enabling Call Screening
Configuring Call Detail Record File Output
Configuring the Clearing Location and Default Location Parameters
Configuring Switchover
Initializing the Provisioning Object Manager
Configuring SCP Queries
Before You Start
Configuring the trigger.dat File Attributes
Configuring the Global Title Translation Attribute
Configuring the Service Key Value Attribute
Configuring the Translation Type Attribute
Sample trigger.dat File
Initializing the Call Screening Database
.odbc.ini File Information
Setting Up Replication
Network Requirements
Initializing Database Replication
Verifying Database Replication
Troubleshooting the Main Memory Database Replication
Displaying the Main Memory Database Replication Status
Verifying Database Synchronization
Synchronizing Databases
Checking for Installation Errors
Reinstalling CSCOga002
Configuring Cisco SLTs
Configuring Disk Monitor During Initial Software Configuration
Configuring the Data Dumper
Configuring the Data Dumper to Support BAMS
Configuring the Cisco MGC Software
This chapter describes how to configure Release 9 of the Cisco Media Gateway Controller (MGC) software.
Quick Guide to Configuring the Cisco MGC Software
Note
The Cisco MGC software files and processes are located in the /opt/CiscoMGC directory.
The following table provides an overview of the configuration procedure. Go to the page indicated in the right most column for more detailed information.

Note
For further information on configuring the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Before You Start
Before you start, verify the following:
•
Have your company's internal support and Cisco support contact information readily available so you can get help with the installation if needed. (If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii of the Cisco support contact information.)
•
Ensure that you have access to the console port on your Cisco MGC host.
Caution 
The Cisco MGC software is case-sensitive. Ensure that you enter parameter names correctly, or the maximum number of configurations will not be modified.
Software Directory Structure
Table 5-2 shows the Cisco MGC software directory structure.
Caution 
Do not edit any .dat files (except for the XECfgParm.dat and trigger.dat files). Use MML or the GUI provisioning tool to make changes to your configuration. In addition, only make changes to the call screening database by using MML or the GUI provisioning tool.
Table 5-2 Software Directory Structure
Directory
|
Contents
|
/etc/init.d
|
Control scripts, including scripts used to stop and start the software.
|
/opt/CiscoMGC
|
Root location of base software installation.
|
/opt/CiscoMGC/local
|
User accounts home directory.
|
/opt/CiscoMGC/etc
|
Contains active configuration data files and the configuration library.
|
/opt/CiscoMGC/etc/CONFIG_LIB
|
Library of all configuration data files.
|
/opt/CiscoMGC/etc/CONFIG_LIB/new
|
The initial startup configuration supplied with a new installation of the software.
|
/opt/CiscoMGC/etc/active_link
|
The active running configuration that has been committed or deployed.
|
/opt/CiscoMGC/etc/prov_link
|
The latest provisioned configuration that has not yet been committed or deployed.
|
/opt/CiscoMGC/etc/cust_specific
|
Location of configurations that have been exported using the prov-exp MML command.
|
/opt/CiscoMGC/man
|
MML help files.
|
/opt/CiscoMGC/lib
|
System software libraries of *.so object files (including protocol and system libraries).
|
/opt/CiscoMGC/snmp
|
SNMP support directory. MIBs are named *.my and are in ASN.1 syntax.
|
/opt/CiscoMGC/var
|
Contains the log, spool, and trace file directories.
|
/opt/CiscoMGC/var/log
|
Default platform informational and error logs.
|
/opt/CiscoMGC/var/spool
|
Spool files for CDRs and measurements.
|
/opt/CiscoMGC/var/trace
|
Location of trace files created by using the sta-trc MML command.
|
/opt/TimesTen
|
Call screening database files. Do not edit the database.
|
/opt/Toolkit
|
The Toolkit application files.
|
/opt/sun_install
|
Contains the scripts used to install Solaris patches (part of the CSCh007.pkg).
|
Initial Cisco MGC Software Configuration
When configuring the Cisco MGC software for the first time, use the MGC Environment Configuration Tool XECfg program to modify the XECfgParm.dat file. The MGC Environment Configuration Tool is a utility that is based on the Tool Command Language/Toolkit (Tcl/Tk). This utility uses an initialization wizard to facilitate the initial configuration of the XECfgParm.dat file.
The following required configuration parameters in the XECfgParm.dat file (see Table 5-3) are critical to bringing up the system. For more information on XECfgParm.dat files, refer to the "Cisco MGC 9.x XECfgParm.dat File Parameter Definitions" section on page A-2.
Note
The XECfgParm.dat file must be provisioned with the installation of every system. The file consists of set of parameters that are necessary to bring up the system. This set of required parameters is configured via the MGC Environment Configuration Tool.
When you exit the MGC Environment Configuration Tool, the slave file is sent via FTP to the appropriate system.

Caution
During Initial Cisco MGC Configuration: We recommend that you put an initial configuration on the active
host, otherwise both the active and standby hosts will remain in the stopped state.
Do not start the standby host if the active host is not yet provisioned.
When the initial configuration on the active
host is deployed, you must change the
pom.dataSync parameter to true in the XECfgParm.dat file in the standby host. After setting this parameter to true, you can start the Cisco MGC on the standby host. As the Cisco MGC comes up, the data on the standby host is synchronized with the data on the active host. Initiate switchover to bring the active host to the standby state.
To accommodate failover conditions where the current active host can become the standby host, you must also set the pom.dataSync parameter to true on the current active host.
When Upgrading the Cisco MGC software: You must set the pom.dataSync parameter to false on the current active host to preserve configuration files.
Table 5-3 Configuration Parameters
Parameter
|
Description
|
*.CPUTimerInterval
|
Samples the frequency of CPU utilization.
Prior to Release 9.4(1), this parameter must be set to 0 during the initial configuration of any platform with a single CPU (including Sun Netra t 100/105, Sun Netra V 120, and Sun Netra 120).
For Release 9.4(1) and up, this parameter is set automatically when you specify a Cisco MGC type in the engine.SysVirtualSwitch parameter. Any attempt to modify this parameter is overwritten.
|
*.desiredPlatformState
|
Specifies the operating mode of the Cisco MGC.
|
*.ipAddr1 through ipAddr4
|
Specify the IP addresses being used by the system.
Note that *.ipAddrLocalA, and *.ipAddrLocal2 are the same as *.ipAddr1, and *.ipAddr2, respectively.
|
*.ownClli
|
Specifies ANSI CLLI code.
|
pom.dataSync
|
Indicates that the Provisioning Object Manager (POM) should synchronize the provisioning data at startup.
|
*.SyscheckpointEnabled
|
Specify true if the master/slave operating mode is being used.
|
*.SysConnectDataAccess
|
Controls whether data access is enabled or disabled (if the engine attempts to connect to the MMDB or to call screening database at startup).
Values:
• true = connect to MMDB or call screening database
• false = do not connect to MMDB or call screening database
Default: false
Note This parameter must be set to true in calling scenarios where Euro-LNP, A Number Screening, or other features requiring real time database access are required. Otherwise, it can remain false for an increase in the available system memory usable for call processing.
Note This parameter replaces the engine.sysScreeningCheck parameter in Cisco MGC 7.4.
|
engine.SysVirtualSwitch
|
Specifies the Cisco MGC type. Indicates whether the Cisco MGC host functions as a signaling controller or a virtual switch controller.
Values:
• 0 = signaling controller (nailed trunks, no auditing is initiated)
• 1 = virtual switch controller (switched trunks)
Default: 0
Note For Release 9.4(1) and up, the values of the parameters listed below are automatically set based on the Cisco MGC type you select, to maximize performance for that configuration. Any attempt to change the values of these parameters is overwritten.
engine.SysMdlMemoryReduction engine.CALL_MEM_BLOCK_SIZE engine.CALL_MEM_CHUNK_SIZE *.CPUTimerInterval *.numberOfThreads
|
Parameters Required for Initial Setup
The following table lists the parameter values that must be defined during the initial installation.
Note
These parameters are located at the top of the XECfgParm.dat file, thus making it easier to find the parameters required for initial setup.
Table 5-4 Parameters Required for Initial Setup
Item
|
Parameter Name
|
Default Value
|
Changed Values
|
1
|
PlatformId
|
1
|
1, if slave
|
2
|
TranspathId
|
01
|
02, if slave
|
3
|
DesiredPlatformState
|
Standalone
|
Master,slave,standalone
|
4
|
SyscheckpointEnabled
|
False
|
True, if redundant system
|
5
|
IpAddrLocalA
|
0.0.0.0
|
Ifconfig(hme0)
|
6
|
IpAddrLocalB
|
0.0.0.0
|
Ifconfig(hme1)
|
7
|
IpAddrPeerA
|
0.0.0.0
|
Slave(ifconfig(hme0))
|
8
|
IpAddrPeerB
|
0.0.0.0
|
Slave(ifconfig(hme1))
|
9
|
IPAddr1
|
0.0.0.0
|
Ifconfig(hme0)
|
10
|
IPAddr2
|
0.0.0.0
|
Ifconfig(hme1)
|
11
|
IPAddr3
|
0.0.0.0
|
Ifconfig(hme2)
|
12
|
IPAddr4
|
0.0.0.0
|
Ifconfig(hme3)
|
13
|
StPort
|
0
|
7000, if Master or 7001 if Slave
|
14
|
Engine.SysVirtualSwitch
|
0
|
1 for Switched solution
|
15
|
Foverd.ipLocalPortA (con 1)
|
0
|
1051, if Master or 1052 if Slave
|
16
|
Foverd.ipPeerPortA (con 1)
|
0
|
1052, if Master or 1051 if Slave
|
17
|
Foverd.ipLocalPortA (con 2)
|
0
|
1053, if Master or 1054 if Slave
|
18
|
Foverd.ipPeerPortA (con 2)
|
0
|
1054, if Master or 1053 if Slave
|
19
|
Pom.dataSync
|
False
|
True if Master or Slave, both sides
|
20
|
Diskmonitor.OptFileSys
|
<blank>
|
../var/log
|
21
|
NumberOfThreads
|
0
|
Prior to 9.4(1): 0,1,2 depends of CPUs in system
9.4(1) and up: Depends on the setting for engine.SysVirtualSwitch.
|
22
|
OwnClli
|
12233344445
|
ANSI(CLLI of Switch)
|
23
|
*.SysConnectDataAccess
|
False
|
call screening using the database
|

Note
For an example of an updated configuration file, see the "Updated Configuration File Sample" section on page D-10.
Using the Cisco MGC Environment Configuration Tool
You must configure the basic parameters required to bring the system to an operational mode. To use the MGC Environment Configuration Tool XECfg program:
Step 1
Run the MGC Environment Configuration Tool. Log in as mgcusr, type the following at the command prompt, and press Enter:
A dialog box is displayed, warning that the MGC Environment Configuration Tool is for initial system set up only and asks if you wish to continue running the XECfg program.
Step 2
Select Yes.
A screen similar to the following is displayed:
Figure 5-1 MGC Environment Configuration Tool
Optionally, you can run the MGC Environment Configuration Tool in detail mode by selecting the detail parameter at the command line.
a.
Type the following command and press Enter:
A dialog box is displayed, warning that the MGC Environment Configuration Tool is for initial system set up only, and asks if you wish to continue running XECfg.
b.
Select Yes.
The MGC Environment Configuration Tool screen expands to provide detailed information from the XECfgParm.dat file (see Figure 5-2).
Figure 5-2 MGC Environment Configuration Tool—Detail Mode
Step 3
You can configure your system to operate either as a standalone system or as a fault-tolerant system.
If you configure your system to be in fault-tolerant mode, you must do the following:
a.
Supply a set of IP addresses for the back-up/standby machine. By default, these backup IP addresses are set to 0.0.0.0.
b.
Type the backup IP addresses in the Slave IP field in the Master-Slave IP Map section of the MGC Environment Tool screen.
Step 4
Click the Commit button to implement changes after you have completed configuring the parameters.
Note
The required parameters are the Cisco MGC type and its operating mode. There are no default parameters defined when you bring up the XECfg program.
After committing the changes, the XECfg program backs up the current XECfgParm.dat file into XECfgParm.dat.xyz, where xyz can be between 0 and 19. The earliest version of the XECfgParm.dat file is version 0 and the latest is version 19.
If the operating mode is stand-alone, the XECfgParm.dat file is updated with new parameters. If the operating mode is fault-tolerant, the XECfgParm.dat file is updated and the XECfgParm.data.slave file is generated, based on the XECfgParm.dat file. There is no backup for the XECfgParm.dat.slave file.
Old parameters are commented out and new parameters are inserted. Use the comment line to keep file history. A history line is inserted every time a change is made against parameters. All required parameters are moved up to the top of the file for ease of use. However, the configuration tool does not depend on the location of the parameters.
Step 5
When you exit the application, the XECfg program prompts you to determine whether you wish to transfer the XECfgParm.dat.slave file to the remote machine (this is done through the FTP operation). If you choose to transfer the file to the remote machine, you must enter a password before the FTP is performed successfully. Alternately, you can exit the application without performing the FTP operation.
Configuring Groups and Users
You must set up groups and users for the Cisco MGC software on each host server. A user must be a member of the "mgcgrp" group to use certain Cisco MGC software functions, such as Man-Machine Language (MML). (MML is an interface that enables you to communicate with the Cisco MGC. Users with full MML privileges have monitor and control access; users with minimal MML privileges have only monitor access. For more information on MML, see the Cisco Media Gateway Controller Software Release 9 Provisioning Guide and the Cisco Media Gateway Controller Software Release 9 MML Command Reference.)
Verifying the mgcgrp Group
To verify the mgcgrp group, complete the following steps:
Step 1
Log in to the Cisco MGC host as root.
Step 2
Change to the /etc directory.
Step 3
Edit the group file to verify the entry for the mgcgrp group. The file should contain the following line:
Step 4
Save and close the group file.
Step 5
Edit the passwd file to verify the entry for the mgcusr user. The file should contain the following line:
mgcusr:x:20000:20000::/opt/CiscoMGC/local:/bin/csh
If the file does not contain the line, add it.
Step 6
Save and close the password file.
This completes the procedures for verifying the mgcgrp group.
Adding a User with Full MML Privileges
To add a user with full MML privileges, complete the following steps.
Caution 
If your user's home directory differs from /opt/CiscoMGC/local, you must perform
Step 6 through
Step 9 before using MML.
Step 1
Log in to the Cisco MGC host as root.
Step 2
Enter the following command:
# useradd -u UID -g mgcgrp -d /opt/CiscoMGC/local -s /bin/csh -m username
UID is a user ID that is an integer from 0 through 2147483647 (excluding the numbers 0, 1, 2, 3, 4, 5, 9, 37, 71, 60001, 60002, and 65534, because they are used by the operating system).
Step 3
Add the new username to the mgcgrp group in the group file:
Note
The group file is a comma-separated list of user names. If you add more than one user, use commas (with no spaces) to separate one name in the list from another.
Step 4
Enter the following command and press Enter:
Step 5
Type the user's password and press Enter twice when prompted.
Step 6
If your user's home directory differs from /opt/CiscoMGC/local: Log in to the Cisco MGC.
Step 7
Enter the following command and press Enter:
Step 8
Enter the following command and press Enter:
Step 9
Enter the following command and press Enter:
This completes the procedures for adding a user with full MML privileges.
Adding a User with Minimal MML Privileges
To add a user with minimal MML privileges, follow the steps in the "Adding a User with Full MML Privileges" section, but do not add the user to the mgcgrp group.
This completes the group and user configuration. Continue to the "Configuring SNMP Support Resources" section. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Configuring SNMP Support Resources
The Cisco MGC software includes a Simple Network Management Protocol (SNMP) agent subsystem that provides an alarm management interface on the Cisco MGC. It uses SNMP to report events, or traps (such as alarms), to your SNMP Manager and to provide access to the Cisco MGC Management Information Base (MIB).
Note
SNMP MIB measurements are only valid on the active node. They are not replicated on the standby node.
The SNMP agent subsystem reports the following event categories to your SNMP Manager:
1.
Communications
2.
Quality of Service
3.
Processing
4.
Equipment
5.
Environment
In a fault tolerant configuration, the SNMP agent subsystem runs on both the active and standby machines.
Note
If your system is running Cisco MGC software 9.3(2) or later, go to the "Migrating the SNMP Configuration to a More Secure Environment (for MGC 9.3(2) or Later)" section for SNMP configuration procedures.
If your system is running an earlier version of Cisco MGC software 9.3(2), such as version 7.4(x), go to the "Setting up the SNMP Community for Software Releases Before Cisco MGC 9.3(2)" section for SNMP configuration procedures.
Note
For a sample snmpd.cnf file, see the "Sample Configured snmpd.cnf File" section on page D-11.
Note
Use any of the following to configure SNMP community names and trap destinations:
- config-snmp utility (for Cisco MGC software 9.3(2) or later)
- vi editor (for Cisco MGC software 9.2(2) or earlier)
Note
SNMP managers such as the Cisco Media Gateway Controller Node Manager (MNM) or HP OpenView can be used to receive traps.
Note
The config-snmp utility is case-sensitive. It will accept "name1" and "NAME1" as two different entries.
Migrating the SNMP Configuration to a More Secure Environment (for MGC 9.3(2) or Later)
If your system is running Cisco MGC software version 9.3(2) or later, Cisco recommends that your SNMP configuration be migrated to a more secure environment by running the config-snmp utility. Use the config-snmp utility to perform the following:
•
Modify the snmpd.cnf file to automatically migrate old configuration files to a secure environment.
•
Facilitate the addition or deletion of the community string and trap destination.
Note
There is no limit to the number of community strings that can be added to the configuration.
Note
The config-snmp script only allows you to add or delete an entry to your snmpd.cnf file.
Basic Tasks
The following is an overview of the major tasks you must perform to get the SNMP security provided by the config-snmp utility:
1.
Run config-snmp utility. See the "Running the config-snmp Utility" section.
2.
Add a new snmpCommunityEntry. See the "Adding an SNMP Community Entry" section
3.
Make sure that the new snmpCommunityEntry string is recognized and can communicate with your Cisco MGC hosts. See the "Activating the New Settings" section.
4.
Delete the old entry that you were using. See the "Deleting an SNMP COMMUNITY" section.
Before You Run the config-snmp Utility
Note
If you have completed a first-time installation of the Cisco MGC softare with Release 9.6(1) and its associated patches, you must copy the snmpd.cnf.tmpl to snmpd.cnf before your run the config-snmp utility. Users who have upgraded to Release 9.6(1) from a previous release do not have to perform this procedure. To copy the snmpd.cnf.tmpl to the snmp.cnf, perform the following steps:
1. Log in as root and enter the following UNIX commands:
cd /opt/CiscoMGC/snmp
cp snmpd.cnf.tmpl snmpd.cnf
2. Enter the following UNIX commands to restart the snmp daemon:
ps -ef |grep snmpdm
The system will display the process ID for the snmp daemon. Restart the daemon using the
following command:
kill -9 snmpdm_pid
Where snmpdm_pid is the process ID for the snmp daemon.
Note that the first instance of ReadAndNotifyToAll in the snmpCommunityEntry will be the only CommunityName used in the Trap.
For example, if your snmpd.cnf file has the following snmpCommunityEntry, you will find only the CommunityName of Iron1 in the Trap.
#Entry type: snmpCommunityEntry
#Format: snmpCommunityIndex (text)
# snmpCommunityName (text)
# snmpCommunitySecurityName (text)
# snmpCommunityContextEngineID (octetString)
# snmpCommunityContextName (text)
# snmpCommunityTransportTag (text)
# snmpCommunityStorageType (nonVolatile, permanent, readOnly)
snmpCommunityEntry Iron1 ron1 ReadAndNotifyToAll localSnmpID - - nonVolatile
snmpCommunityEntry Iron2 ron2 ReadWriteAll localSnmpID - - nonVolatile
snmpCommunityEntry Iron3 ron3 ReadAndNotifyToAll localSnmpID - - nonVolatile
snmpCommunityEntry admin WBnAGZ54 PGWInternalSignal localSnmpID - localAccess \
snmpCommunityEntry readonly public ReadAndNotifyToAll localSnmpID - - \
Running the config-snmp Utility
Perform the following steps to run the config-snmp utility:
Step 1
Make sure your system has the latest Cisco MGC patches on both Host A and Host B. Refer to the Release Notes for Cisco Media Gateway Controller Software Release 9 for the patches' installation procedures.
Step 2
On Host A, log in as root user.
Step 3
Check whether the snmpdm or critagt process is running.
Note
If snmpdm or critagt are not running, call Cisco TAC or contact your Field Engineer for assistance.
Type one of the following commands and press Enter:
a.
To check snmpdm:
If the snmpdm process is running, text similar to the following is displayed:
root 12098 27888 0 Jun 16 ?
0:00 /opt/CiscoMGC/snmp/snmpdm -tcplocal -d
b.
To check critagt:
If the critagt process is running, text similar to the following is displayed:
0:15 /opt/CiscoMGC/snmp/critagt -d
Step 4
To start the config-snmp utility, type the following command and press Enter:
The following screen is displayed:
Migrating snmpd.cnf into a more secure setting...
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit:
Step 5
To view the configuration entries, type 1 and press Enter.
The Entries Menu is displayed and you are prompted to make a selection:
=================== Entries Menu ===================
17. vacmSecurityToGroupEntry
18. vacmViewTreeFamilyEntry
21. snmpTargetParamsEntry
22. snmpNotifyFilterProfileEntry
23. snmpNotifyFilterEntry
Enter a selection (1 through 24) or 'q' to quit to Main Menu:
Step 6
Enter your selection number (1 through 24) to view your configuration entries.
Adding an SNMP Community Entry
Continuing from Step 6, above (of the section Running the config-snmp Utility):
Step 1
Enter 12 to select snmpCommunityEntry and view the entries:
Text similar to the following and the SNMPD Configuration Main Menu are displayed.
#Entry type: snmpCommunityEntry
#Format: snmpCommunityIndex (text)
# snmpCommunityName (text)
# snmpCommunitySecurityName (text)
# snmpCommunityContextEngineID (octetString)
# snmpCommunityContextName (text)
# snmpCommunityTransportTag (text)
# snmpCommunityStorageType (nonVolatile, permanent, readOnly)
snmpCommunityEntry IT555 T555 ReadWriteAll localSnmpID - - nonVolatile
snmpCommunityEntry Ijammmy jammmy ReadAndNotifyToAll localSnmpID - - nonVolatile
snmpCommunityEntry admin za8RQzBg PGWInternalSignal localSnmpID - localAccess
nonVolatile
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit:
Step 2
You are prompted to make a selection. Enter 2 to add an SNMP Community.
The Add CommunityString Menu is displayed and you are asked if you would like to proceed with adding a community string:
=================== Add CommunityString Menu ===================
SnmpCommunityName CommunitySecurityName
jammmy ReadAndNotifyToAll
CommunitySecurityName SecurityModel Read Write Notification
ReadWriteAll snmpv1 AllMibObjects AllMibObjects -
ReadWriteAll snmpv2c AllMibObjects AllMibObjects -
ReadAndNotifyToAll snmpv1 AllMibObjects - AllMibObjects
ReadAndNotifyToAll snmpv2c AllMibObjects - AllMibObjects
Would you like to proceed with the Add [n]/[y]?
Step 3
Enter y to proceed (if you enter n to cancel the addition, you return to the SNMPD Configuration Main Menu).
The following text is displayed, prompting you to enter an snmpCommunityName.
Note
The snmpCommunityName should be at least three characters in length. The snmpCommunityName can contain numeric characters, but should begin with an alpha character.
Step 4
Enter an snmpCommunityName (the following name is an example):
Text similar to the following is displayed:
Enter CommunitySecurityName (ReadAndNotifyToAll or ReadWriteAll):
Step 5
Enter a community security name (the following security name entry is an example):
Note
The CommunitySecurityName (ReadAndNotifyToAll or ReadWriteAll) is case sensitive.
Text similar to the following text is displayed:
snmpCommunityName: comname1 is about to be added. Are you sure that you want to add this
snmpCommunity Name [y]/[n]?
Step 6
Enter y to add the snmpCommunityName (if you enter n to cancel the addition, you return to the SNMPD Configuration Main Menu):
Text similar to the following is displayed:
snmpCommunityEntry Icomname1 comname1 ReadAndNotifyToAll localSnmpID - - nonVolatile
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit:
Step 7
Enter a selection number, 1 through 6. For steps on how to execute the selections from the SNMPD Configuration Main Menu, refer the following sections:
•
Adding an SNMP Community Entry
•
Deleting an SNMP COMMUNITY
•
Adding a Trap Destination
•
Deleting a Trap Destination
•
Activating the New Settings
•
Verifying the SNMP Configuration Migration
Note
To complete the migration of the SNMP configuration to a more secure environment, see the "Activating the New Settings" section.
The procedure for adding an SNMP Community Entry is now complete.
From the SNMPD Configuration Main Menu, choose option 6 (Activate the New Settings) to commit the changes, or select other options (1 through 5) to add or delete a community name or trap.
Deleting an SNMP COMMUNITY
From the SNMPD Configuration Main Menu:
Step 1
If you select 3 (Delete an SNMP Community) from the SNMPD Configuration Main Menu, the delete CommunityString Menu is displayed:
Note
The SNMP Community Names listed in the following display are examples.
=================== Delete CommunityString Menu ===================
SnmpCommunityName CommunitySecurityName
comname1 ReadAndNotifyToAll
jammmy ReadAndNotifyToAll
CommunitySecurityName SecurityModel Read Write Notification
ReadWriteAll snmpv1 AllMibObjects AllMibObjects -
ReadWriteAll snmpv2c AllMibObjects AllMibObjects -
ReadAndNotifyToAll snmpv1 AllMibObjects - AllMibObjects
ReadAndNotifyToAll snmpv2c AllMibObjects - AllMibObjects
Would you like to proceed with the Delete [n]/[y]?
Step 2
Enter y to delete SNMP Community (if you enter n to cancel the deletion, you return to the SNMPD Configuration Main Menu):
Text similar to the following is displayed:
Step 3
Enter an SnmpCommunityName. Select an SnmpCommunityName from the list that is displayed in Step 1. The SnmpCommunityName T555, is an example:
Text similar to the following is displayed:
snmpCommunityName: T555 is about to be deleted. Are you sure that you want to delete this
snmpCommunity Name [y]/[n]?
Step 4
Enter y to confirm the deletion (if you enter n to cancel the deletion, you return to the SNMPD Configuration Main Menu).
Text similar to the following is displayed and you are returned to the SNMPD Configuration Main Menu:
Deleting snmpCommunity= T555
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit:
Step 5
Enter your selection. For detailed procedures for your selection, refer to the following list:
•
Adding an SNMP Community Entry
•
Deleting an SNMP COMMUNITY
•
Adding a Trap Destination
•
Deleting a Trap Destination
•
Activating the New Settings
•
Verifying the SNMP Configuration Migration
The procedure for deleting an SNMP Community Entry is now complete. Proceed to the selection you entered in the SNMPD Configuration Main Menu.
Adding a Trap Destination
From the SNMPD Configuration Main Menu:
Step 1
Select option 4 (Add a Trap Destination) from the SNMPD Configuration Main Menu and press Enter to add a Trap Destination.
The Add Trap Menu is displayed:
Note
The IP Address (Target Address) listed below is an example of existing Trap entries.
=================== Add Trap Menu ===================
1. TargetAddress: 6.6.6.6:0 , TargetAddrParams: v1ExampleParams , IP Mask:
255.255.255.255:0
Would you like to proceed with the Add [n]/[y]?
Step 2
Enter y to add a Trap Destination (if you enter n to cancel the addition, you return to the SNMPD Configuration Main Menu).
Text similar to the following is displayed:
Enter IP Address (x.x.x.x):
Step 3
Enter the IP address listed in Step 1:
7.7.7.7
Text similar to the following is displayed:
Enter Trap Type (v1 or v2c):
Step 4
Enter the Trap Type based on your SNMP manager. The following entry is an example:
Text similar to the following is displayed:
'snmpTargetAddrEntry 483 snmpUDPDomain 6.6.6.6:0 100 3 TrapSink v1ExampleParams
nonVolatile 255.255.255.255:0 2048
' is about to be added. Are you sure that you want to add this Trap Entry [n]/[y]?
Step 5
Enter y to add a Trap Destination (if you enter n to cancel the addition, you return to the SNMPD Configuration Main Menu).
Text confirming the addition of the Trap Destination is displayed, followed by the SNMPD Configuration Main Menu:
Adding Trap: snmpTargetAddrEntry 483 snmpUDPDomain 7.7.7.7:0 100 3 TrapSink
v1ExampleParams nonVolatile 255.255.255.255:0 2048
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit:
Step 6
Enter your selection. For detailed procedures for your selection, go to the section listed below:
•
Adding an SNMP Community Entry
•
Deleting an SNMP COMMUNITY
•
Adding a Trap Destination
•
Deleting a Trap Destination
•
Activating the New Settings
•
Verifying the SNMP Configuration Migration
The procedure for adding a Trap Destination is now complete. Proceed to the selection you entered in the SNMPD Configuration Main Menu.
Deleting a Trap Destination
From the SNMPD Configuration Main Menu:
Step 1
To delete a Trap Destination, enter 5 (Delete a Trap Destination):
Text similar to the following is displayed:
=================== Delete Trap Menu ===================
1. TargetAddress: 7.7.7.7:0 , TargetAddrParams: v1ExampleParams ,
IP Mask: 255.255.255.255:0
2. TargetAddress: 6.6.6.6:0 , TargetAddrParams: v1ExampleParams ,
IP Mask: 255.255.255.255:0
Would you like to proceed with the Delete [n]/[y]?
Step 2
Enter y to delete a Trap Destination (if you enter n to cancel the deletion, you return to the SNMPD Configuration Main Menu):
Text similar to the following is displayed:
Enter a selection (1 through 2):
Note
The Target Addresses (1 through 2) shown above are examples only.
Step 3
Enter 1 to select the TargetAddress to be deleted:
Text similar to the following is displayed:
Trap is about to be deleted. Are you sure that you want to delete this Trap Entry
[n]/[y]?
Step 4
Enter y to confirm the deletion (if you enter n to cancel the deletion, you return to the SNMPD Configuration Main Menu).
Text confirming the deleted Trap Entry is displayed and you are returned to the SNMPD Configuration Main Menu. Note that 483 (below) is an internal Trap snmpTargetAddrName.
Deleting Trap snmpTargetAddrName = 483
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit:
Step 5
Enter your selection. For detailed procedures for your selection, refer to the following list:
•
Adding an SNMP Community Entry
•
Deleting an SNMP COMMUNITY
•
Adding a Trap Destination
•
Deleting a Trap Destination
•
Activating the New Settings
•
Verifying the SNMP Configuration Migration
The procedures for deleting a Trap Destination is now complete. Proceed to the selection you entered in the SNMPD Configuration Main Menu.
Activating the New Settings
From the SNMPD Configuration Main Menu:
Step 1
Enter 6 to activate the new settings:
Text similar to the following is displayed:
Backing up the current snmpd.cnf to snmpd.cnf.backup.
snmpd.cnf.backup already exists. Do you want to overwrite the file [y]/[n]?
Note
If you choose n, your backup file will not be updated.
Step 2
Enter y to activate the new settings.
Are you sure you would like to Activate the New Settings [y]/[n]?
Note
If you choose y, your SNMPD.dat file will be updated and you will be exited from the utility.
If you choose n, your SNMPD.dat file will not be updated and you will be exited from the utility.
Step 3
Enter y to activate the new settings (if you enter n to cancel the activation, you return to the SNMPD Configuration Main Menu).
Text similar to the following is displayed:
snmpd.cnf file has been updated.
The procedure for activating the new settings is now complete and you are exited from the config-snmp utility. Proceed to the following section, "Verifying the SNMP Configuration Migration".
Verifying the SNMP Configuration Migration
Perform the following steps to verify that your changes were applied by running the config-snmp utility:
Step 1
To start the config-snmp utility, type the following command and press Enter:
Text similar to the following is displayed:
Migrating snmpd.cnf into a more secure setting...
When the SNMPD Configuration Main Menu is displayed, you are prompted to make a selection:
=================== SNMPD Configuration Main Menu ===================
1. View Configuration Entries
3. Delete an SNMP Community
4. Add a Trap Destination
5. Delete a Trap Destination
6. Activate the New Settings
Enter a selection (1 through 6) or 'q' to quit: 1
Step 2
Enter 1 to view the configuration entries.
The Entries Menu is displayed and you are prompted to make a selection:
=================== Entries Menu ===================
17. vacmSecurityToGroupEntry
18. vacmViewTreeFamilyEntry
21. snmpTargetParamsEntry
22. snmpNotifyFilterProfileEntry
23. snmpNotifyFilterEntry
Enter a selection (1 through 24) or 'q' to quit to Main Menu:
a.
If you select 12 from the SNMPD Configuration Main Menu, the snmpCommunityEntry is displayed, showing the changes you made:
Note
The following entries are examples only.
#Entry type: snmpCommunityEntry
#Format: snmpCommunityIndex (text)
# snmpCommunityName (text)
# snmpCommunitySecurityName (text)
# snmpCommunityContextEngineID (octetString)
# snmpCommunityContextName (text)
# snmpCommunityTransportTag (text)
# snmpCommunityStorageType (nonVolatile, permanent, readOnly)
snmpCommunityEntry Icomname1 comname1 ReadWriteAll localSnmpID - - nonVolatile
snmpCommunityEntry Ijammmy jammmy ReadAndNotifyToAll localSnmpID - - nonVolatile
snmpCommunityEntry admin VD6FZbov PGWInternalSignal localSnmpID - localAccess
nonVolatile
b.
If you select 20 from the SNMPD Configuration Main Menu, the Trap Destination information is displayed, showing the changes you made:
Note
The following entries are examples only.
#Entry type: snmpTargetAddrEntry
#Format: snmpTargetAddrName (text)
# snmpTargetAddrTDomain (snmpUDPDomain, snmpIPXDomain, etc.)
# snmpTargetAddrTAddress (transport address,i.e. 192.147.142.254:0)
# snmpTargetAddrTimeout (integer)
# snmpTargetAddrRetryCount (integer)
# snmpTargetAddrTagList (text)
# snmpTargetAddrParams (text)
# snmpTargetAddrStorageType (nonVolatile, permanent, readOnly)
# snmpTargetAddrTMask (transport mask, i.e. 255.255.255.255:0)
# snmpTargetAddrMMS (integer)
snmpTargetAddrEntry 531 snmpUDPDomain 6.6.6.6:0 100 3 TrapSink v1ExampleParams
nonVolatile 255.255.255.255:0 2048
snmpTargetAddrEntry local snmpUDPDomain 127.0.0.1:0 100 3 localAccess -
nonVolatile 255.255.255.255:0 2048
The SNMP support resource configuration is now complete. Continue to the "Configuring the Execution Environment" section to configure the execution environment. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Setting up the SNMP Community for Software Releases Before Cisco MGC 9.3(2)
If your software release is earlier than Cisco MGC software release 9.3(2), you must edit your files using the vi editor. You can either use the existing SNMP community (public) or create your own.
To create a new SNMP community, log in to the Cisco MGC as root and use the vi editor to modify the /opt/CiscoMGC/snmp/snmpd.cnf file. This file has three default access security levels:
•
Guest (read-only)
•
User (read-write for most of the MIBS)
•
SuperUser (read-write).
Adding a New Community
To add a new community called myCommunity (for example, a community with an access level of User), do the following procedures:
Step 1
Add a line in the snmpCommunityEntry as follows:
snmpCommunityEntry myUser myCommunity private localSnmpID - - nonvolatile
Step 2
Change the access level. To change the access level to Guest, replace "private" by "public". To change the access level to SuperUser, replace "private" by "mgcusr".
Setting the Destination for Traps
Do the following procedures to add a trap destination, which is a machine named manager-host with the IP address of 10.10.10.5. Traps will be sent to this destination by the MGC SNMP agent.
Step 1
In the snmpNotifyEntry section, add the following line:
snmpNotifyEntry 50 myTrap trap nonvolatile
Note
You can replace the number 50 with any unique number. You can also use any unique name in place of myTrap. To send inform instead of traps, replace trap by inform.
Step 2
In the snmpTargetAddrEntry section, add the following two lines:
snmpTargetAddrEntry 51 snmpUDPDomain 10.10.10.5:0 100 3 myTrap \
v2cExampleParams nonVolatile 255.255.255.255:0 2048
There must be nothing (not even a space or any other invisible characters) after the \ on the first line. You can change the following entries in the above line:
•
51 is a unique index of the snmpTargetAddEntry. Use a different number if 51 is already in use; make sure you are using a unique number.
•
10.10.10.5 is the IP address of the snmp manager.
•
100 specifies the round trip timeout of 1 second (100 of 100th second) for an inform. This number is not used for traps.
•
3 is the number of retries the agent will attempt to retransmit an inform when a response is not received. This number is not used for traps.
•
myTrap is the name defined in the snmpNotifyEntry.
•
v2cExampleParams specifies that SNMP v2c traps will be sent. To send v1 traps, use v1cExampleParams.
Configuring SNMP Entries
To configure the SNMP resources, perform the following steps:
Step 1
Log in to the Cisco MGC and change to the /etc directory.
Step 2
Using FTP, transfer the following MIBs (located in /opt/CiscoMGC/snmp) from the Cisco MGC to the machine on which the SNMP Manager runs:
•
CISCO-SMI.my
•
v3-tgt.my
•
tp.my
•
measurement.my
Step 3
Load the MIBs into the SNMP Manager.
For example, you can use the xnmnloadmib -load command from HP OpenView.
Tip
For more detailed information about configuring HP OpenView, see Appendix B, "HP OpenView Sample SNMP Configuration."
Note
See your SNMP Manager documentation for more information. We do not recommend an SNMP Manager; however, this chapter gives examples using the Hewlett-Packard (HP) OpenView Network Node Manager.
Example 5-1 HP OpenView Example
If you are using HP OpenView Network Node Manager as your SNMP manager, follow
these procedures to load your MIB:
(a) Select Options from the File Menu and choose Load/Unload MIBs:SNMP.
(b) From the Load/Unload MIBs: SNMP window (on the lower left of your screen).
(c) Click the Load... button.
(c) From the "Load/Unload MIBs:SNMP /Load MIB from File" window, select the MIB to
load (for example, tp.my).
Step 4
Connect the SNMP events to an event category to display the event. As Cisco MGC events are connected, you can alter the format of the event messages for easier viewing.
Note
On many SNMP Managers, event categories can be added so that customer-specific events can be mapped to corresponding categories.
Example 5-2 HP OpenView Event Configuration Example
If you are using HP OpenView Network Node Manager, follow these procedures to
configure an event:
(a) Select Options from the File Menu and choose Event Configuration.
(b) From the Event Configuration window, in the Enterprise Identification list,
select transpath.
(c) In the Event Identification list, double click on each of the event types, one
at a time.
(d) If desired, change the event information display. To change the format of an
event, from the Event Configurator / Modify Event window, enter a format in the
Event Log Message Box to change the format and labels for received events of this
type.
The following example shows how an event can be reformatted using the HP OpenView
Network Node Manager.
ID# $13 Name $12 Set $10 MMLname $4 CatDesc $11 \nCompDesc $3
Severity $8 CompID $6 CompType $5 CatID $14\nAlarmNotify $9 AlarmTime$1
ParentID $2 AlarmReported $7\n$o
Tip
For more detailed information about configuring HP OpenView, see Appendix B, "HP OpenView Sample SNMP Configuration."
Step 5
Configure where to set Cisco MGC traps using any of the following:
–
Cisco MNM
–
HP OpenView
–
vi editor
Step 6
Verify that your SNMP Manager shows the traps from the Cisco MGC. If you do not see the events in your SNMP Manager, you might have a port mismatch or an incorrect IP address in your configuration.
This completes the SNMP support resource configuration. Continue to the following section, "Configuring the Execution Environment", to configure the execution environment. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Configuring the Execution Environment
This section provides instructions for configuring the Cisco MGC execution environment and contains the following topics:
•
Configuring Basic System Information
•
Specifying IP Addresses
•
Configuring Engine Parameters
•
Enabling Call Screening
•
Configuring Call Detail Record File Output
•
Configuring the Clearing Location and Default Location Parameters
•
Configuring Switchover
•
Initializing the Provisioning Object Manager
The configuration data file, or XECfgParm.dat file (located in /opt/CiscoMGC/etc/XECfgParm.dat), lists all the components in the Cisco MGC and defines how it operates. You must edit the execution environment parameters in the XECfgParm.dat file to initialize and configure the Cisco MGC software application. For more detailed information on XECfgParm.dat parameters, refer to Appendix A, "XECfgParm.dat File Parameters" and the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
For samples of configured XECfgParm.dat files, see the "Sample Configured Cisco MGC 9.2(2) XECfgParm.dat Files" section on page D-14.
Caution 
To ensure that your system works as intended,
edit only the XECfgParm.dat file parameters which are listed below, and remember that all parameters are case-sensitive.
Do not modify the
processes.dat file. This XECfgParm.dat file should remain unmodified, as delivered with the MGC software. If this file is modified, procM may core dump when you start the MGC software.
Changing XECfgParm.dat File Parameters
For a complete list of the parameters found in the XECfgParm.dat file and how they are used by the Cisco MGC, see Appendix A, "XECfgParm.dat File Parameters."
If you have a fault tolerant system with two Cisco MGC hosts, the XECfgParm.dat files are different for each host. For examples of these XECfgParm.dat files, see the "Sample Configured Cisco MGC 9.2(2) XECfgParm.dat Files" section on page D-14 and the "Sample Configured Cisco MGC 9.1(5) XECfgParm.dat Files" section on page D-21.
To change the XECfgParm.dat file parameters, perform the following steps:
Step 1
Log in as root and go to the # prompt.
Step 2
If the Cisco MGC software is running, enter the following command:
/etc/init.d/CiscoMGC stop
Wait until the system returns the following response:
Signalling procM to shut down
Step 3
Change to the /opt/CiscoMGC/etc directory, which contains the XECfgParm.dat file used by your system.
Step 4
Open the XECfgParm.dat file with any text editor, such as vi.
Step 5
Save your changes and close the editor.
Step 6
Restart the Cisco MGC software by entering the following command:
/etc/init.d/CiscoMGC start
Note
Do not restart the software yet if you need to configure SCP queries or initialize the call screening database. Complete the instructions in the appropriate sections of this chapter before restarting the software.
Continue to "Changing XECfgParm.dat File Parameters in a Running Fault Tolerant System" to change parameters without call interruption. Continue to the "Configuring SCP Queries" section to configure Service Control Point (SCP) queries using transaction capabilities application part (TCAP). If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Changing XECfgParm.dat File Parameters in a Running Fault Tolerant System
To change parameters in a running fault tolerant system without call interruption, perform the following steps:
Step 1
Log in to the active host (Host X) and make your changes. See "Changing XECfgParm.dat File Parameters" section for more specific instructions.
Step 2
Log in to the standby host (Host Y) and stop the Cisco MGC software by entering the following command:
/etc/init.d/CiscoMGC stop
Step 3
Restart the Cisco MGC software on the standby box (Host Y) by entering the following command:
/etc/init.d/CiscoMGC start
Step 4
Perform switchover on the active host (Host X). Log in to the active host (Host X) and stop the Cisco MGC software by entering the following command:
/etc/init.d/CiscoMGC stop
Stopping the software on Host X causes switchover to the standby, Host Y. Host Y becomes active and takes over call processing.
Tip
If Host Y does not take over call processing after switchover, restart the software on Host X to take over the calls. Check the parameters you changed on Host Y and make sure you have the correct values.
Step 5
Restart the Cisco MGC software on the now standby host, Host X, by entering the following command:
/etc/init.d/CiscoMGC start
Step 6
On Host Y, the currently active host, enter the following MML command to switch call processing from Host Y to the newly changed Host X. Host X becomes active:
Tip
If Host X does not take over call processing after switchover, restart the software on Host Y to take over the calls. Check the parameters you changed on Host X and make sure you have the correct values.
Configuring Basic System Information
Note
For descriptions of the parameters found in the XECfgParm.dat file and how they are used by the Cisco MGC, see Appendix A, "XECfgParm.dat File Parameters."
To configure basic system information required for your system to function, modify the following parameters in the first section of the XECfgParm.dat file:
Parameter
|
Modification
|
*.transpathId
|
To identify the local Cisco MGC host in a fault tolerant system, enter any one- or two-digit integer.
Note If you have two Cisco MGC hosts in a fault tolerant system, this number must be different in the XECfgParm.dat file for each host.
|
*.ownTranspathId
|
To identify the local Cisco MGC host in a fault tolerant system, enter the same value that you used for *.transpathID.
Note If you have two Cisco MGC hosts in a fault tolerant system, enter this value in the *.peerTranspathID field in the XECfgParm.dat file on the second host server. If you have a simplex system, leave this value blank.
|
*.peerTranspathId
|
To identify the peer Cisco MGC host in a fault tolerant system, enter any one- or two-digit integer. The IDs must be unique in an active and standby pair.
Note If you have two Cisco MGC hosts in a fault tolerant system, enter the same value that you used for *.transpathID in the XECfgParm.dat file of the second host server in this field. If you have a simplex system, leave it blank.
|
*.desiredPlatformState
|
To determine the desired platform state at initialization, enter one of the following values:
• master—If you have two (active and standby) Cisco MGC hosts, and you are editing the file on the active host
• slave—If you have two (active and standby) Cisco MGC hosts, and you are editing the file on the standby host
• standalone—If you have a simplex system
Note If you have two Cisco MGC hosts in a fault tolerant system, make sure that the active Cisco MGC is set to master and the standby host is set to slave.
|
*.SyscheckpointEnabled
|
To enable or disable checkpointing, enter one of the following values:
• false—Disables checkpointing. Calls are not preserved during a switchover, and status messages are not sent to the replicator (default).
• true—Enables checkpointing. Calls that are in the talking state are preserved and survive a control switchover. All status checkpointing information is sent to the replicator on the active side.
Note If you have two Cisco MGC hosts in a switchover configuration, enter true. If you have a standalone configuration, enter false.
|
*.numberOfThreads
|
Prior to Release 9.4(1), the number of threads generated by multithreaded processes such as the engine and the log master, is specified by entering one of the following values:
• 0—Single CPU (default)
• 1—Two CPUs
• 2—Four CPUs
Note If you have a multi-CPU system, the engine.SysGeneratedCode parameter must be left as true (the default).
For Release 9.4(1) and up, this parameter is set automatically when you specify a Cisco MGC type in the engine.SysVirtualSwitch parameter. Any attempt to modify this parameter is overwritten.
|
*.OverdecadicDigitsSupported
|
This parameter controls the method of loading dial plan tables and instructs the system whether to expect overdecadic (base 16) or regular decadic (base 10) digits in dial plans, routing, and other digit streams.
Correct setting of this parameter depends on local network interconnect agreements and the expected data format.
Enter true to use overdecadic digits (0-F).
|
*.stPort
|
Port number used between peer components or processes.
Enter any unused port number (for example, 7000). If your configuration uses a Cisco SLT, enter the port number on the Cisco SLT.
Note If you have two Cisco MGC hosts in a failover configuration, enter a different number for this value in the XECfgParm.dat file on the secondary host (for example, 7001).
Note On a new configuration, we recommend that this parameter be set to 0. This value allows the SLT port to be defined using the PEERPORT parameter of the SESSIONSET.
Note SESSIONSET reads the port value that is defined. However, if an *.stPort value other than 0 is defined in XECfgParm.dat (for example, *.stPort=7001), the SESSIONSET value gets overridden by the value in XECfgParm.dat.
|
*.OwnClli
|
Common language location identifier. To initiate circuit query validation if circuit queries are supported, enter an alphanumeric string of as many as 24 characters.
Default: TTT-SS-BB-XXX
Example: 1-22-33-444
|
Specifying IP Addresses
To specify IP addresses, modify the following parameters in the first section of the XECfgParm.dat file:
Note
If there are two Ethernet interfaces defined on the Cisco MGC, it is mandatory to have these on distinct subnets.
For example, consider the following configuration:
*.ipAddrLocalA = 172.22.119.108
*.ipAddrLocalB = 172.22.119.54
This is not a valid combination because they are on the same subnet. The following example illustrates a valid combination:
*.ipAddrLocalA = 172.22.119.108
*.ipAddrLocalB = 172.22.120.54
In this example, the subnet mask is 255.255.255.0 (or 255.255.255.128).
If the two Ethernet interfaces are on the same subnet, then one of them must be physically disconnected from the existing subnet and then connected to a different subnet. The new IP address must be appropriately configured on the system. Refer to the manual pages for the UNIX command ifconfig for more information.
Parameter
|
Modification
|
*.ipAddrLocalA
|
Enter the first local IP address; used for checkpointing and switchover heartbeats.
Caution  This address is the same value as *.IP_Addr1, and is the hme0 interface.
Caution  No other machine on the network should have *.ipAddrLocalA set to 0.0.0.0.
|
*.ipAddrPeerA
|
Enter the first corresponding peer IP address; used for checkpointing and switchover heartbeats.
Note If you have two Cisco MGC hosts in a fault tolerant configuration, this value is set to the IP address of the second host.
|
*.ipAddrLocalB
|
Enter the second local IP address; used for checkpointing and switchover heartbeats. This is the address of the hme1 interface.
Note If your configuration does not use a secondary Ethernet adapter, leave this address set to the default value, 0.0.0.0.
|
*.ipAddrPeerB
|
Enter the second corresponding peer IP address; used for checkpointing and switchover heartbeats. This is the address of the hme1 interface on the second host.
Note If your configuration does not use a secondary Ethernet adapter, leave this address set to the default value, 0.0.0.0.
|
*.IP_Addr1
|
Enter the IP address of the hme0 interface.
|
*.IP_Addr2
|
Enter the IP address of the hme1 interface (if configured).
|
*.IP_Addr3
|
Enter the IP address of the hme2 interface (if configured).
|
*.IP_Addr4
|
Enter the IP address of the hme3 interface (if configured).
|
Configuring Engine Parameters
For the engine to run correctly, you must modify the following parameters in the Engine section of the XECfgParm.dat file:
Parameter
|
Modification
|
engine.CALL_MEM_BLOCK_SIZE
|
Block of memory allocated per call.
Used by MDL.
Default:
Prior to Release 9.4(1): 0
• For memory-critical configurations, use the default value.
• For performance-critical configurations, set this value to 110000.
Release 9.4(1) and up: set automatically based on the type of Cisco MGC selected in engine.SysVirtualSwitch. Any attempt to modify this value is overwritten.
|
engine.CALL_MEM_CHUNK_SIZE
|
Memory chunks allocated from the block of memory designated with engine.CALL_MEM_BLOCK_SIZE.
Default:
Prior to Release 9.4(1): 0
• For memory-critical configurations, use the default value.
• For performance-critical configurations, set this value to 110000.
Release 9.4(1) and up: set automatically based on the type of Cisco MGC selected in engine.SysVirtualSwitch. Any attempt to modify this value is overwritten.
|
engine.SendHardwareBlock
|
To enable the Cisco MGC to send hardware-oriented blocking messages for any blocks that originate from the media gateways:
• true—Sends hardware-oriented blocking messages for any blocks that originate from the media gateways.
• false—Sends only maintenance-oriented blocking messages for all blocking cases (default).
Note The functionality for this parameter is added in a patch for Release 9.3(2) and up. If your system is running Release 9.3(2) or Release 9.4(1) you must enter this parameter in the XECfgParm.dat file manually after installing the patch. If your system is running Release 9.5(2), the parameter is automatically added to the XECfgParm.dat file during the patch installation.
|
engine.SysCdrCollection
|
To designate the format of call detail records (CDRs), enter one of the following values:
• true—Generates old-style non-tagged CDRs
• false—Generates new tag, length, and value (TLV) format CDRs (default)
Note Typically, this value should be false.
|
engine.SysVirtualSwitch
|
To indicate whether the Cisco MGC host functions as a signaling controller or a virtual switch controller, enter one of the following values:
• 0—Signaling controller (nailed trunks, no auditing is initiated)
• 1—Virtual switch controller (switched trunks)
Note For Release 9.4(1) and up, the values of the parameters listed below are automatically set based on the Cisco MGC type you select, to maximize performance for that configuration. Any attempt to change the values of these parameters is overwritten.
engine.SysMdlMemoryReduction engine.CALL_MEM_BLOCK_SIZE engine.CALL_MEM_CHUNK_SIZE *.CPUTimerInterval *.numberOfThreads
|
engine.SysGRSTimerInterval
|
To specify the interval between blocks of Circuit Group Reset (GRS) messages when the engine.SysGRSBlockSize parameter is used, set to the value required (in milliseconds).
|
engine.SysGRSBlockSize
|
Many Circuit Group Reset (GRS) messages can become due for sending at the same time. This situation occurs if you have set the *.GRSEnabled parameter to true during provisioning. The *.GRSEnabled parameter is a property that is set on an SS7 signaling service (in the CMM) or an SS7 path (in MML).
GRS messages can be staggered by sending in blocks. Set the engine.SysGRSBlockSize parameter to the number of messages to be sent in each block. Use the engine.SysGRSTimerInterval parameter to set the time from the start of one block to the start of the next.
Default: 0
Note This parameter operates independently for each SS7 route (each OPC/DPC pair).
|
engine.SysGeneratedCode
|
To determine whether compiled or interpreted code is used, enter one of the following values:
• true—System uses compiled code (default).
• false—System uses interpreted code (used only for engineering and debugging).
Note Compiled code runs faster than interpreted code. Typically, this value should be true. If your configuration uses multiple CPUs, this value must be true.
|
*.SysConnectDataAccess
|
This parameter controls if data access is enabled or disabled and if the engine attempts to connect to the MMDB at startup.
Set this parameter to true for calling scenarios where European LNP, A-number screening, or other features requiring real-time database access are used.
If you do not need real-time database access, set this parameter to false to increase the available system memory that can be used for call processing.
|
Enabling Call Screening
To initialize the database that stores call screening information, modify the following parameter in the Engine section of the XECfgParm.dat file:
Parameter
|
Modification
|
*.SysConnectDataAccess
|
Controls whether data access is enabled or disabled (whether the engine attempts to connect to the MMDB at startup.
Values:
• true = connect to MMDB
• false = do not connect to MMDB
Default: false
Note In calling scenarios where Euro-LNP, A Number Screening, or other features requiring real time database access are required, this parameter must be set to true. Otherwise, it can remain false for an increase in the available system memory usable for call processing.
Note This parameter replaces the SysScreeningCheck parameter.
|
Configuring Call Detail Record File Output
To configure call detail record (CDR) file output, modify the following parameters in the Data Dumper and Engine sections of the XECfgParm.dat file:
Parameter
|
Modification
|
engine.CDRencodingFormat
|
To specify the call detail record (CDR) file encoding format, enter one of the following values:
• AnsiCDB—North American (default)
• ItuCDB—European
|
engine.CDRmessageTypes
|
To specify the Call Detail Blocks (CDBs are the accounting records written at various points in a call) that are generated during a call, enter one of the following sets of values (each number represents a point in a call):
• 1010, 1020, 1030, 1040, 1050, 1060, 1070, 1080—These are considered the "event-based" set of values. Use this event-based list when you want to receive all CDR records at predefined points in the call. Although each of these CDBs can be specified independently, Cisco suggests that you use the event-based set as a "package" of CDBs for full accounting purposes.
Note The event-based setting is required when operating the Cisco MGC in conjunction with the BAMS adjunct.
• 1060, 1110—Use this value if you want end-of-call summary-type records only.
• 1071—Use this set of values for BAMS measurements.
Refer to the chapter "Detailed CDB Description" in the Cisco Media Gateway Controller Software Release 9 Billing Interface Guide for details on each CDB.
|
engine.CDRtimeStamp
|
Specifies the time stamp unit in seconds or milliseconds.
To specify the CDR file time-stamp unit, enter one of the following values:
• S—Seconds (default).
• M—Milliseconds. Use this parameter if your configuration uses TCAP or if you want the millisecond granularity in all of your CDR records.
Note The M setting is mandatory when operating the Cisco MGC in conjunction with the BAMS adjunct.
|
cdrDmpr.callDetail
|
Specifies that call detail record (CDR) files may be automatically converted from binary format to ASCII, comma-delimited format.
Default: /opt/CiscoMGC/local/cdbscript.sh
Optional: /opt/CiscoMGC/bin/converter (if binary CDR files need to be converted to ASCII)
Note The default CDR file format has changed from an ASCII format in Release 4 to a binary format in Release 7. The ASCII file has a .csv extension.
For more information on generating and viewing CDR files, see the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
|
dmpr.openCDR
|
Specifies whether the standard data dumper should write out CDR files.
Values:
• true = Standard data dumper opens a CDR file and log the call data blocks (CDB).
• false = Standard data dumper does not open a CDR file and does not log CDBs.
Default: true
Note The default format for CDR files has been changed since release 4 from an ASCII format to a binary format. Use the dmpr.callDetail parameter to convert the files to an ASCII format, if necessary.
|
Configuring the Clearing Location and Default Location Parameters
This property overrides the Clearing Location and Default Location fields in Call Context. Change the clearing location value if you need a value other than the default to be sent to the switch. Change the default location value if you need to define a customer-specific default location for your system that can differ from the default location set in the type definition of the protocol.
Parameter
|
Modification
|
ClearingLocation
|
This property overrides the Clearing Location field in Call Context. Change this value if you need a value other than the default to be sent to the switch. Valid values are:
• 0—The Cisco MGC software uses the default Clearing Location in Call Context.
• 1—The Cisco MGC software overrides the Clearing Location in Call Context with LOCATION_USER
• 2—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PRIVATE_LOCAL
• 3—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PUBLIC_LOCAL
• 4—The Cisco MGC software overrides the Clearing Location in Call Context with LOCATION_TRANSIT
• 5—The Cisco MGC software overrides the Clearing Location in Call Context with LOCATION_ PUBLIC_REMOTE
• 6—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PRIVATE_REMOTE
• 7—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ INTERNATIONAL
• 8—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ INTERWORKING
• 9—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ LOCAL_INTERFACE
• 10—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ LOCAL_LOCAL
• 11—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ LOCAL_REMOTE
• 12—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ PACKET_MANAGER
• 13—The Cisco MGC overrides the Clearing Location in Call Context with LOCATION_ UNKNOWN
|
DefaultLocation
|
This property overrides the Default Location field in Call Context. Change this value if you need to define a customer-specific default location for your system that can differ from the default location set in the type definition of the protocol. Valid values are:
• 0—The Cisco MGC software uses the Default Location in Call Context
• 1—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_USER
• 2—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PRIVATE_LOCAL
• 3—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PUBLIC_LOCAL
• 4—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_TRANSIT
• 5—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PUBLIC_REMOTE
• 6—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PRIVATE_REMOTE
• 7—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ INTERNATIONAL
• 8—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ INTERWORKING
• 9—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ LOCAL_INTERFACE
• 10—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ LOCAL_LOCAL
• 11—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ LOCAL_REMOTE
• 12—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ PACKET_MANAGER
• 13—The Cisco MGC software overrides the Default Location in Call Context with LOCATION_ UNKNOWN
|
Configuring Switchover
To configure switchover, modify the following parameters in the foverd section of the XECfgParm.dat file.
Parameter
|
Modification
|
foverd.conn1Type
|
To set the connection type for connection number 1, enter serial or socket.
Note Typically, set this value to socket.
|
foverd.ipLocalPortA
|
To define the local port number used for IP communication, enter a unique number, keeping the following in mind:
• Typically, if Type is socket, set this value to 1051.
• If you have two Cisco MGC hosts in a fault tolerant configuration, enter the foverd.ipLocalPortA value in the foverd.ipPeerPortA field in the XECfgParm.dat file on the secondary host.
Caution The value of foverd.ipLocalPortA must be unique for every host on the network. Otherwise, active and standby hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipLocalPortA set to 1051. If that happens, the active and standby hosts cannot perform proper switchover.
|
foverd.ipPeerPortA
|
To define the peer port number used for IP communication, enter a unique number, keeping the following in mind:
• Typically, if Type is socket, set this value to 1052.
• If you have two Cisco MGC hosts in a switchover configuration, enter the foverd.ipPeerPortA value in the foverd.ipLocalPortA field in the XECfgParm.dat file on the secondary host.
Caution The value of foverd.ipPeerPortA must be unique for every host on the network. Otherwise, active and standby hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipPeerPortA set to 1052. If that happens, the active and standby hosts cannot perform proper switchover.
|
foverd.conn2Type
|
To set the connection type for connection number 2, enter serial or socket.
Note Typically, set this value to socket.
|
foverd.ipLocalPortB
|
To define the secondary local port number used for IP communication, enter a unique number, keeping the following in mind:
• Typically, if Type is socket, set this value to 1053.
• If you have two Cisco MGC hosts in a switchover configuration, enter this value in the foverd.ipPeerPortB field in the XECfgParm.dat file on the secondary host.
Caution The value of foverd.ipLocalPortB must be unique for every host on the network. Otherwise, active and standby hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipLocalPortB set to 1053. If that happens, the active and standby hosts cannot perform proper switchover.
|
foverd.ipPeerPortB
|
To define the secondary local port number used for IP communication, enter a unique number, keeping the following in mind:
• Typically, if Type is socket, set this value to 1054.
• If you have two Cisco MGC hosts in a switchover configuration, enter this value in the foverd.ipLocalPortB field in the XECfgParm.dat file on the secondary host.
Caution The value of foverd.ipPeerPortB must be unique for every host on the network. Otherwise, master and slave hosts cannot communicate properly. In the instance discussed here, no other machine on the network can have foverd.ipPeerPortB set to 1054. If that happens, the master and slave hosts cannot perform proper switchover.
|
foverd.conn3Type
|
To set the connection type for connection number 3, enter serial or socket.
Note Typically, set this value to serial.
|
foverd.conn3Addr
|
To specify the address of the peer system, enter a location; for example, /dev/term/a.
If your configuration does not use connection number 3, enter /dev/null (default).
Note If your configuration uses an 8-port connector as a serial connection for switchover, you must modify the read-write permissions for the connection.
|
foverd.abswitchPort
|
To specify the port used for communication with the A/B switch, enter a location; for example, /dev/term/a.
Note If your configuration does not use an A/B switch, use the default value (/dev/null).
|
foverd.heartbeatInterval
|
Specifies the maximum time in milliseconds between heartbeat messages from the peer switchover daemon. This interval defines the frequency with which the switchover daemon exchanges heartbeat messages with its peer.
Default: 1000 milliseconds (1 second).
|
:
Note
For more information on switchover, see Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Initializing the Provisioning Object Manager
To configure the Provisioning Object Manager (POM), modify the following parameters in the POM section of the XECfgParm.dat file:
Parameter
|
Modification
|
pom.dataSync
|
Used in a fault tolerant system to indicate that the POM should synchronize the provisioning data at startup.
• If you have a standalone system, set this value to false.
• If you have a fault tolerant system, set this value to true.
Caution  If pom.dataSync is set to true for a fault tolerant system, you must ensure that you are running the same version of the Cisco MGC software on both active and standby machines. Otherwise, the wrong version of your data files may be copied to the other machine.
Note When the initial Cisco MGC configuration on the active host is deployed, you must change the pom.dataSync parameter to true in the XECfgParm.dat file in the standby host. After setting this parameter to true, you can start the Cisco MGC on the standby host. As the Cisco MGC comes up, the data on the standby host is synchronized with the data on the active host and the active host goes into the standby state.
To accommodate failover conditions where the current active host can become the standby host, you must also set the pom.dataSync parameter to true on the current active host.
|
pom.port
|
Used in a fault tolerant configuration to indicate the port number that the POM uses to communicate with its peer. Enter any integer from 4001 through 4050, or default.
Note This is a platform-specific value and depends on your system installation. You should modify this value only if the default port (4001) is being used by another process or application.
|
Configuring SCP Queries
The SCP translates routing information for the Advanced Intelligent Network (AIN) database queries over TCAP. This section provides instructions for selecting the type of translation you use to enable SCP database queries. If your site or network requires changes, you can enable SCP queries by manually editing the parameters in the trigger.dat file. The trigger.dat file (located in /opt/CiscoMGC/etc) contains the message-sending table that contains translation values.
This section contains the following topics:
•
Before You Start
•
Configuring the trigger.dat File Attributes
•
Sample trigger.dat File
Warning
Do not edit trigger.dat file parameters that are not listed below, and remember that all parameters are case-sensitive. Otherwise, your system might not work as intended.
Note
The following Bellcore Standards are supported for US 800 toll-free services:
IN/1 Toll Free Service support : GR-1428
AIN 0.1 Toll Free Service support : GR-2902
Before You Start
If you are changing an ANSI query and you need a different Translation Type, you need to know the Translationtype value from the Global Title Translation tables on the Signal Transfer Point (STP). Get this value from the administrator of your STP.
Configuring the trigger.dat File Attributes
Note
The trigger.dat file is not overwritten during software installation. All changes to the trigger.dat file are contained in a file called trigger.template that is installed with the new software. If you modify the trigger.dat file after installing a new software release, you need to view the trigger.template file and copy any changes in that file to your trigger.dat file.
Caution 
Improper editing of the trigger.dat file can cause service interruption and prevent the Cisco MGC from correctly performing SCP database queries.
You can configure the following Cisco MGC trigger.dat file attributes to perform a Transaction Capabilities Application Part (TCAP) query:
•
Global Title Translation
•
Service Key Value
•
Translation Type
Configuring the Global Title Translation Attribute
Perform the following steps to configure the Global Title Translation attribute:
Step 1
Back up the trigger.dat file.
Step 2
Determine the Trigger Number that you need to edit. You can get this information from your network administrator.
Step 3
Navigate to directory /opt/CiscoMGC/etc.
Step 4
Open the trigger definition file in an ASCII text editor and search for the string $TriggerTable.
Step 5
Starting after the $TriggerTable line, count the number of rows equal to the TriggerType beginning from the number 1.
Note
Do not count any row that is blank or that begins with a pound sign (#).
Step 6
When you find your row, note down the second number in that row. This number is the index to the $MessageSending table.
Step 7
Edit the file as follows:
a.
In the $MessageSending table, select column 9, gtSsn (see Table 5-5).
b.
In the table for your translation type, change the Global Title Translation value (column F9) to either 0 or 1. You can get this information from your network administrator. If the number is 0, use GTT. If the number is 1, use PC/SSN.
c.
If you change the gtSsn value to 0, you must go to gtFormat in column 16 and reset the value to 0. If you set the value to 1, you must also set column 16 to a non-zero value.
Note
See Table 5-5 for table values.
Step 8
Save your changes and close the editor.
Step 9
For your changes to take effect you must reboot the Cisco MGC by entering the following command:
# /etc/init.d/CiscoMGC start
Note
If you have installed the Solaris DiskSuite package (CSCOh016) on your system, the messages below are displayed during system boot-up. They are normal Solaris DiskSuite start-up messages and do not indicate any problem with your system.
WARNING force load of misc /md-trans failed
WARNING force load of misc /md-raid failed
WARNING force load of misc /md-hotspares failed
WARNING force load of misc /md-sp failed
Configuring the Service Key Value Attribute
Perform the following steps to configure the Service Key Value (tcv_sk) attribute:
Step 1
Back up the trigger.dat file.
Step 2
Determine the Trigger Number that you need to edit. You can get this information from your network administrator.
Step 3
Navigate to directory /opt/CiscoMGC/etc.
Step 4
Open the trigger.dat file in an ASCII text editor and search for the string $TriggerTable.
Step 5
Starting after the $TriggerTable line, count the number of rows equal to the TriggerType beginning from the number 1.
Note
Do not count any row that is blank or that begins with a pound sign (#).
Step 6
When you find your row, note down the second number in that row. This number is the index to the $MessageSending table.
Caution
Do not change TCVs. You must verify that column 2 is equal to 1 before changing tcv_sk. If column 2 is not equal to 1, this is not an ETSI trigger and column 6 is a TCV, not an SK.
Step 7
Edit the trigger.dat file as follows:
a.
In the $MessageSending table, select tcv_sk, in column 6 (see Table 5-5).
b.
In the table, change the value for tcv_sk to a value from 0 through 255. You can get this information from your network administrator.
Step 8
Save your changes and close the editor.
Step 9
Restart the Cisco MGC software by entering the following command:
# /etc/init.d/CiscoMGC start
Configuring the Translation Type Attribute
Perform the following steps to configure the Translation Type (translationType) attribute:
Step 1
Back up the trigger.dat file.
Step 2
Determine the Trigger Number that you need to edit. You can get this information from your network administrator.
Step 3
Navigate to directory /opt/CiscoMGC/etc.
Step 4
Open the trigger definition file in an ASCII text editor and search for the string $TriggerTable.
Step 5
Starting after the $TriggerTable line, count the number of rows equal to the TriggerType beginning from the number 1.
Note
Do not count any row that is blank or that begins with a pound sign (#).
Step 6
When you find your row, note down the second number in that row. This number is the index to the $MessageSending table.
Caution 
You must verify that column 2 is equal to 2 or 3 before changing Translation Type. If column 2 is not equal to 2 or 3, this is not an ANSI trigger and Translation Type is not used.
Step 7
Edit the file as follows:
a.
In the $MessageSending table, select translationType, in column 7 (see Table 5-5).
b.
In the table for your translation type, change the value for translationType to a value from 0 through 255. You can get this information from your network administrator.
Step 8
Save your changes and close the editor.
Step 9
For your changes to take effect you must reboot the Cisco MGC by entering the following command:
# /etc/init.d/CiscoMGC start
Note
If you have installed the Solaris DiskSuite package (CSCOh016) on your system, the messages below are displayed during system boot-up. They are normal Solaris DiskSuite start-up messages and do not indicate any problem with your system.
WARNING force load of misc /md-trans failed
WARNING force load of misc /md-raid failed
WARNING force load of misc /md-hotspares failed
WARNING force load of misc /md-sp failed
Table 5-5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Transport
|
tcapType
|
stpScpGroupIndex
|
msg
|
asn1Encoding
|
tcv_sk
|
translationType
|
tcapBodyType
|
gtSsn
|
dpcPres
|
ssnPres
|
dpcNetwork
|
dpcCluster
|
dpcMember
|
ssn
|
gtFormat
|
OS1
|
OS2
|
OS3
|
OS4
|
OS5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
$MessageSending Table Values
Sample trigger.dat File
#--//******************************************************************************
#--//* (c) 1999-2000 CISCO SYSTEMS, INC. ALL RIGHTS RESERVED. *
#--//* THIS SOFTWARE CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF *
#--//* CISCO SYSTEMS, INC. USE, DISCLOSURE, OR REPRODUCTION IS PROHIBITED *
#--//* WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF THE CISCO SYSTEMS, INC. *
#--//******************************************************************************
# "$Id: Table_9.trigger,v 1.11.2.3 1999/09/20 18:20:51 xxxxxxxx Exp $";
# "(c) 1999-2000 Cisco Systems, Inc. All Rights Reserved."
# All fields are pointers to records of other types
# MA MS RR1 RR2 RR3 RR4 RR5
#----------------------------------
#----------------------------------
#----------------------------------
#----------------------------------
#----------------------------------
#----------------------------------
#----------------------------------
#----------------------------------
#----------------------------------
# TT 5: ANSI AIN 800 NPA-NXX
#----------------------------------
#----------------------------------
# TT 6: ANSI AIN 800 NPA-NXX-XXXX
#----------------------------------
#----------------------------------
# TT 7: ANSI AIN 800 Termination Information
#----------------------------------
#----------------------------------
# TT 8: ANSI PRE AIN AIN 800
#----------------------------------
#----------------------------------
# TT 9: ANSI PRE AIN 800 Termination Information
#----------------------------------
# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10
# ACT1 REQ ACT2 REQ ACT3 REQ ACT4 REQ ACT5 REQ
#-------------------------------------------------
#-------------------------------------------------
#-------------------------------------------------
#-------------------------------------------------
#-------------------------------------------------
#-------------------------------------------------
#-------------------------------------------------
# MA 4: ANSI AIN 800 / ANSI PRE AIN 800
#-------------------------------------------------
#-------------------------------------------------
# MA 5: ANSI AIN 800 Termination Information / PRE AIN 800 Termination Information
#-------------------------------------------------
# GTFORMAT_DO_NOT_USE_GLOBAL_TITLE := 0
# GTFORMAT_USE_GLOBAL_TITLE_TRANSLATION_TYPE_NUMBERING_SCHEME_ENCODING_SCHEME := 1
# GTFORMAT_USE_GLOBAL_TITLE_TRANSLATION_TYPE := 2
# GTFORMAT_USE_GLOBAL_TITLE_ONLY := 3
Note
To see proper formatting for the table below, see Table 5-5.
# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 F17 F18 F19 F20 F21
# transport tcapType stpScpGroupIndex msg asn1Encoding tcv_sk translationType tcapBodyType
gtSsn dpcPres ssnPres dpcNetwork dpcCluster dpcMember ssn gtFormat OS1 OS2 OS3 OS4 OS5
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
1 2 0 6 0 0 255 1 0 0 1 0 0 0 0 2 1 0 0 0 0
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
1 2 6 37 255 0 1 0 0 2 0 0 0 0
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
1 2 0 6 0 4 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0
#----------------------------------------------------------------------------------------
# MS 5: ANSI AIN 800 NPA-NXX
#----------------------------------------------------------------------------------------
1 2 0 0 255 0 1 0 0 4 0 0
#----------------------------------------------------------------------------------------
# MS 6: ANSI AIN 800 NPA-NXX-XXX
#----------------------------------------------------------------------------------------
1 2 0 6 0 8 255 1 0 0 1 0 0 0 0 2 4 0 0 0 0
#----------------------------------------------------------------------------------------
# MS 7: ANSI AIN 800 Termination information
#----------------------------------------------------------------------------------------
1 2 0 5 0 0 255 1 0 0 1 0 0 0 0 2 5 0 0 0 0
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
1 3 0 6 0 0 254 2 0 0 1 0 0 0 0 2 6 0 0 0 0
#----------------------------------------------------------------------------------------
# MS 9: ANSI PRE AIN 800 Termination information
#----------------------------------------------------------------------------------------
1 3 0 5 0 0 254 2 0 0 1 0 0 0 0 2 7 0 0 0 0
# componentType opClass opCodeFamily opCodeSpecifier opCodeFlag
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# OS 5: ANSI AIN 800 Termination Information Should have correlationRequired = 1
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# OS 7: ANSI PRE AIN 800 Termination Information
#----------------------------------------------------------------------------------------
# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16 F17 F18
# PA1 REQ PA2 REQ PA3 REQ PA4 REQ PA5 REQ PA6 REQ PA7 REQ PA8 REQ PA9 REQ
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
100 1 101 1 102 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
100 1 101 1 102 1 103 1 0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
200 1 201 1 202 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PS 4: ANSI AIN 800 (All types)
#----------------------------------------------------------------------------------------
100 1 101 1 102 1 103 1 104 1 109 0 110 0 111 0 112 0 113 0
#----------------------------------------------------------------------------------------
# PS 5: ANSI AIN 800 Termination Information
#----------------------------------------------------------------------------------------
105 1 106 1 107 0 108 0 0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
17 1 2 1 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PS 7: ANSI PRE AIN 800 Termination Information
#----------------------------------------------------------------------------------------
21 1 20 1 22 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# RR 1: xxxxxx LNP / Generic LNP Default
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 2: xxxxxx LNP 1st expected
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 3: Generic LNP 1st expected
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 4: xxxxxxx 800 1st expected (Result)
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 5: xxxxxxx 800 2st expected (Error)
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 6: ANSI AIN 800 With termination status notification
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 8: ANSI PRE AIN 800 With termination status notification
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# RR 10: ANSI AIN 800 / PRE AIN 800 Default
#----------------------------------------------------------------------------------------
# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11
# MSG OR1 REQ OR2 REQ OR3 REQ OR4 REQ OR5 REQ
#------------------------------------------------------
# MR 1: xxxxxx LNP / Generic LNP
#------------------------------------------------------
#------------------------------------------------------
# MR 2: xxxxxxx 800 (Result)
#------------------------------------------------------
#------------------------------------------------------
# MR 3: xxxxxxx 800 (Error)
#------------------------------------------------------
#------------------------------------------------------
# MR 4: ANSI AIN 800 with termination status notification
#------------------------------------------------------
#------------------------------------------------------
#------------------------------------------------------
#------------------------------------------------------
# MR 6: ANSI PRE AIN 800 with termination status notification
#------------------------------------------------------
#------------------------------------------------------
#------------------------------------------------------
# componentType opClass opCodeFamily opCodeSpecifier opCodeFlag PR
#----------------------------------------------------------------------
# OR 1: xxxxxx LNP / Generic LNP
#----------------------------------------------------------------------
#----------------------------------------------------------------------
# OR 2: xxxxxxx 800 (Result)
#----------------------------------------------------------------------
#----------------------------------------------------------------------
# OR 3: xxxxxxx 800 (Error)
#----------------------------------------------------------------------
#----------------------------------------------------------------------
#----------------------------------------------------------------------
#----------------------------------------------------------------------
# OR 5: ANSI AIN 800 Request for status notification
#----------------------------------------------------------------------
#----------------------------------------------------------------------
#----------------------------------------------------------------------
#----------------------------------------------------------------------
# OR 7: ANSI PRE AIN 800 Request for status notification
#----------------------------------------------------------------------
# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15 F16
# PA1 REQ ACT PA2 REQ ACT PA3 REQ ACT PA4 REQ ACT PA5 REQ ACT PA6
REQ F17 F18 F19 F20 F21 F22 F23 F24 F25 F26 F27 F28 F29 F30
ACT PA7 REQ ACT PA8 REQ ACT PA9 REQ ACT PA10 REQ ACT
#----------------------------------------------------------------------------------------
# PR 1: xxxxxx LNP / Generic LNP
#----------------------------------------------------------------------------------------
102 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PR 2: xxxxxxx 800 (Result)
#----------------------------------------------------------------------------------------
205 1 1 206 1 1 204 1 3 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PR 3: xxxxxxx 800 (Error)
#----------------------------------------------------------------------------------------
205 1 1 206 1 1 204 1 3 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PR 4: ANSI AIN 800 Result
#----------------------------------------------------------------------------------------
102 1 1 110 0 2 113 0 2 114 1 2 115 1 2 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PR 5: ANSI AIN 800 Status request
#----------------------------------------------------------------------------------------
105 1 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PR 6: ANSI PRE AIN 800 Result
#----------------------------------------------------------------------------------------
8 0 2 4 1 1 18 0 2 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
#----------------------------------------------------------------------------------------
# PR 7: ANSI PRE AIN 800 Status request
#----------------------------------------------------------------------------------------
20 1 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
# F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15
# ACT1 REQ DAT ACT2 REQ DAT ACT3 REQ DAT ACT4 REQ DAT ACT5 REQ DAT
#--------------------------------------------------------------------------
# RA 1: xxxxxx LNP Default & Generic LNP Default
#--------------------------------------------------------------------------
4 1 2 0 0 0 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
# RA 2: xxxxxx LNP 1st Expected
#--------------------------------------------------------------------------
4 1 2 0 0 0 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
# RA 3: Generic LNP 1st Expected
#--------------------------------------------------------------------------
1 1 0 4 1 2 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
#--------------------------------------------------------------------------
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
# RA 5: ANSI AIN 800 with termination status notification
#--------------------------------------------------------------------------
2 0 1 4 1 3 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
#--------------------------------------------------------------------------
4 1 3 0 0 0 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
# RA 7: ANSI PRE AIN 800 with termination status notification
#--------------------------------------------------------------------------
2 0 4 4 1 3 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
#--------------------------------------------------------------------------
4 1 3 0 0 0 0 0 0 0 0 0 0 0 0
#--------------------------------------------------------------------------
#--------------------------------------------------------------------------
4 1 3 0 0 0 0 0 0 0 0 0 0 0 0
# AD 1: ANSI AIN 800 Data for RESULT_ACTION_RE_TRIGGER_VIA_LCM (to send termination
information)
#--------------------------
# AD 2: ANSI LNP Data for RESULT_ACTION_SEND_ACTION_TO_LCM
# Act Null Null Null NULL
#--------------------------
# AD 3: ANSI AIN / PRE AIN 800 Data for RESULT_ACTION_SEND_ACTION_TO_LCM
# Act Null Null Null NULL
#--------------------------
# AD 4: ANSI PRE AIN 800 Data for RESULT_ACTION_RE_TRIGGER_VIA_LCM (to send termination
information)
#--------------------------
This completes the SCP configuration. Continue to the next section to initialize the call-screening database. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Initializing the Call Screening Database
This section contains the following topics:
•
.odbc.ini File Information
•
Setting Up Replication
•
Troubleshooting the Main Memory Database Replication
Caution 
Cisco does not support the direct use of TimesTen commands (files found in
/opt/TimesTen/32/bin). Incorrect use of these commands can cause database corruption.
During installation, the installation script (install.sh) installs and initializes the Main Memory Database (MMDB) that the Cisco MGC can use for the following:
•
Store call-screening information for calling- and called-number analysis
•
Ported Numbers
•
Number Termination
•
Multiple Dial Plan
•
Advice of Charge II
You might want to perform white and black list screening to include or exclude calls from certain numbers. You can provision white lists that specify allowed A-numbers (calling numbers) or B-numbers (called numbers). Black lists block specified A-numbers (calling numbers) or B-numbers (called numbers). For more details, see the Cisco MGC Software Release 9 Dial Plan Guide.
The call screening database is stored in the /opt/TimesTen/datastore directory. The database name is howdydb. The maximum database size, 256 MB, is specified in the .odbc.ini file shown in the .odbc.ini File Information section, below.
Caution 
Do not change the database name.
.odbc.ini File Information
The .odbc.ini file specifies the location of the database storage. Unless you installed the software to other than the default directory, the .odbc.ini file is located in the /opt/CiscoMGC/local directory. The following is an example of an .odbc.ini file:
howdydb=TimesTen 4.1 Driver
Driver=/opt/TimesTen4.1/32/lib/libtten.so
DataStore= /opt/TimesTen4.1/datastore/howdydb
Installdir=/opt/TimesTen4.1/32
Setting Up Replication
If you have two Cisco MGC hosts in a fault tolerant system, you must set up database replication between the two hosts. During replication, any updates applied to the database on one host are replicated on the other. Data is transferred real time and does not require committing or deploying a configuration.
Replication copies data changes to either database after the initial setup. If you have data in one database and want to retain it, go to the host that has the data that you want to retain (usually this is the active host), then follow the procedures below, "Initializing Database Replication" section.
Note
Before you can initialize the databases, you must install the Cisco MGC software on both machines.
Network Requirements
In most replication schemes, you need to identify the name of the host machine on which your data store resides. The operating system translates this host name to an IP address. This section describes how to configure your host names to ensure they use the correct IP addresses.
Identifying data store hosts (UNIX and VxWorks)
If your Unix or VxWorks host has a single IP address and hostname, you can use the host name returned by the hostname command on UNIX or the hostname() call on VxWorks. If a host contains multiple network interfaces (with different IP addresses), TimesTen replication tries to connect to the IP address in the same order as returned by the gethostbyname() call on UNIX or the hostGetByName() call on VxWorks. It will try to connect using the first address; if a connection cannot be established, it tries the remaining addresses in order until a connection is established. TimesTen replication uses this same sequence each time it establishes a new connection to a host. If a connection to a host fails on one IP address, TimesTen replication attempts to re-connect (or fall back) to another IP address for the host in the same manner described above.
There are two basic ways you can configure a host to use multiple IP addresses on UNIX platforms: DNS or /etc/hosts files. On VxWorks platforms you use the hostAdd() call. For example, the following entry in the /etc/hosts file on a UNIX platform describes a server named Machine1 with two Ethernet IP addresses:
To specify the same configuration for DNS, your entry in the domain zone file would look like:
Machine1 IN A 10.10.98.102
In either case, you only need to specify Machine1 as the hostname in your replication scheme and replication will use the first available IP address when establishing a connection. In an environment in which multiple IP addresses are used, you can also assign multiple host names to a single IP address in order to restrict a replication connection to a specific IP address. For example, you might have an entry in your /etc/hosts file that looks like:
192.168.1.102 Machine1 RepMachine1
Or a DNS zone file that looks like:
Machine1 IN A 10.10.98.102
RepMachine1 IN A 192.168.1.102
Should you want to restrict replication connections to IP address 192.169.1.102 for this host, you can specify RepMachine1 as the hostname in your replication scheme. (Another option is to simply specify the IP address as the hostname in the CREATE REPLICATION statement used to configure your replication scheme.)
The following are example hosts files from an active PGW host and an associated peer PGW host:
Active PGW Host /etc/hosts
192.168.11.1 UK-A-Netra1125-1 loghost
192.168.12.1 UK-A-Netra1125-1.hme1
192.168.11.2 UK-A-Netra1125-2
192.168.12.2 UK-A-Netra1125-2.hme1 UK-A-Netra1125-2 <----- Peer PGW hostname
Peer PGW Host /etc/hosts
192.168.11.2 UK-A-Netra1125-2 loghost
192.168.12.2 UK-A-Netra1125-2.hme1
192.168.11.1 UK-A-Netra1125-1 1
92.168.12.1 UK-A-Netra1125-1.hme1 UK-A-Netra1125-1 <----- Peer PGW hostname
Initializing Database Replication
To set up the initial replication, perform the following steps:
Step 1
Log in to the active host as mgcusr and enter the following command:
setup_replication.sh standbyhost active
Where standbyhost is the name (not IP address) of your standby host. In the example below, the active host is hostx and the standby host is hosty.
Caution 
Do not use IP addresses when setting up database replication. If you do, replication will fail.
Example 5-3 Initializing Database Replication on the Active Host
hostx% setup_replication.sh hosty active
Setting up replication to node hosty for DSN howdydb
Adding cisco.portednumbers
RAM Residence Policy : inUse
RAM Residence Grace (Secs) : 0
Manually Loaded In Ram : False
Purge Logs for Data Store : True
Replication Manually Started : True
Step 2
Log in to the standby host as the root user and stop the MGC software by entering the following UNIX command:
/etc/init.d/CiscoMGC stop
Step 3
Log back in to the standby host as mgcusr.
Step 4
At the standby host, enter the following command:
setup_replication.sh activehost standby
where activehost is the name (not IP address) of your active host. In the example below, the active host is hostx and the standby host is hosty.
Caution 
Do not use IP addresses when setting up database replication. If you do, replication will fail.
Example 5-4 Initializing Database Replication on the Standby Host
Configuring replication for DSN=howdydb
Restoring file /opt/TimesTen4.1/datastore/howdydb.ds0 from backup
Restoring file /opt/TimesTen4.1/datastore/howdydb.log0 from backup
RAM Residence Policy :inUse
Manually Loaded In Ram :False
Replication Agent Policy :manual
Replication Manually Started :True
Oracle Agent Policy :manual
Oracle Agent Manually Started :False
Replication setup completed.
Step 5
Start the Cisco MGC by entering the following command:
/etc/init.d/CiscoMGC start
Proceed to "Verifying Database Replication".
Verifying Database Replication
To verify that replication is working, perform the following steps:
Step 1
Log in to the active host and start an MML session by entering mml.
Step 2
Add an entry into the B white list database using the numan-add MML command. For example:
hostx mml> numan-add:bwhite:custgrpid="S018",svcname="testsvc",cli="9998"
VSC-01 - Media Gateway Controller 2000-08-30 11:31:25
Step 3
Log in to the standby host and start an MML session by entering mml.
Step 4
Enter the numan-rtrv MML command to verify that the entry you added in Step 3 was replicated to the database on the standby host. For example:
hosty mml> numan-rtrv:bwhite:custgrpid="S018",svcname="testsvc",cli="9998"
VSC-01 - Media Gateway Controller 2000-08-30 11:33:52
/* The cli :9998: exists. */
Troubleshooting the Main Memory Database Replication
If you have problems during replication, try stopping and restarting the replication as follows:
Step 1
Stop the replication by entering:
# /etc/init.d/ttreplic stop
Step 2
Restart the replication by entering:
# /etc/init.d/ttreplic start
Displaying the Main Memory Database Replication Status
The script replication_status.sh displays the status of the MMDB replication, if it is configured.
Run the script by typing the following command:
The output shows the following replication status:
Peer name Host name Port State Proto
---------------- ------------------------ ------ ------- -----
HOWDYDB VA-DEALE Auto Start 5
Last Msg Sent Last Msg Recv Latency TPS RecordsPS Logs
------------- ------------- ------- ------- --------- ----
Note
If the value for Last Msg Recv is more than a few seconds, or Logs is more than 1, then this indicates that replication is not occurring.
Verifying Database Synchronization
The script db_count.sh provides the number of records configured in each of the database tables. This is useful for checking whether two machines have the same database data configured in them.
Run the script by typing the following command:
The output shows the rows counted in each database table:
CISCO.A_CHARGE_ORIGIN < 0 >
CISCO.A_NUMBERDIALPLANSELECTION < 0 >
CISCO.PORTEDNUMBERS < 0 >
Synchronizing Databases
If you have data in the databases in the active and standby hosts, but both databases are out of synch or do not match, re-synchronize both databases by following the steps listed below. Otherwise, contact Cisco TAC for assistance in merging the databases.
Assuming the active host is the "better" database, do the following on the standby host:
Step 1
Log in as mgcusr.
Step 2
Stop the Cisco MGC software by entering the following command:
/etc/init.d/CiscoMGC stop
Step 3
Stop MMDB replication by entering the following command:
/etc/init.d/ttreplic stop
Step 4
Copy the active host database to the standby host database by entering the following command:
setup_replication <active host> standby
Step 5
Start the Cisco MGC by entering the following command:
/etc/init.d/CiscoMGC start
Checking for Installation Errors
If you still have problems, retry the commands listed in the "Verifying Database Replication" section. If your output differs from the example in that section, or if you suspect problems or errors in the database installation, try the following:
Step 1
Ensure that the database is installed in the /opt/TimesTen directory.
Step 2
Check the log file for installation errors. (The log file is in the directory /var/adm/MGC.install.log.)
Reinstalling CSCOga002
If necessary, remove and reinstall the CSCOga002 package, as follows:
Step 1
Remove the CSCOga002 package using the pkgrm command. To remove the package file, enter the following command:
Step 2
Reinstall the package using the pkgadd command by entering the following command:
# pkgadd -d CSCOga002.pkg
This completes the Cisco MGC software installation. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii. If you do not need to install or remove patches, proceed to configure your Cisco SLTs.
Configuring Cisco SLTs
Note
For configuration information, refer to the document Cisco Signaling Link Terminal and the Release Notes for the Cisco Media Gateway Controller Software Release 9.
Configuring Disk Monitor During Initial Software Configuration
The setting of the disk monitor parameters in the XECfgParm.dat file typically occurs while you are performing the initial configuration procedures for your Cisco MGC software. To configure the disk monitor settings in the XECfgParm.dat file during initial software configuration, perform the following steps:
Step 1
While configuring your settings in the XECfgParm.dat file, find the disk monitor parameters in the file (they are near the end of the file).
Step 2
To change the number of days to preserve logged data before trimming is initiated, modify the value of the diskmonitor.Limit parameter. The default value is 7.
Step 3
To change the list of optional file systems that are checked by the disk monitor script, modify the value of the diskmonitor.OptFileSys parameter.
Note
Files in optional directories are not trimmed by disk monitor.
Step 4
To change the percentage of disk usage at which alarming and disk trimming is initiated, modify the value of the diskmonitor.Threshold parameter. The default value is 80.
Step 5
To change the number of days that finished CDR files are kept in the log directory, modify the value of the diskmonitor.CdrRmFinished parameter. The default value is 0, which means that finished CDRs are immediately sent to the spool directory.
Step 6
If you want to change what action is taken once the number of days threshold set in the diskmonitor.Limit parameter is reached, change the value of the diskmonitor.SoftLimit parameter. If this parameter is set to true, disk monitor decrements the value in the diskmonitor.Limit parameter one day at a time (that is, from 7 down to 6 then down to 5 and so on), until the utilization level drops below the threshold. If this parameter is set to false, disk monitor exits and the system generates a DISK alarm. The default value is true.
Step 7
To change the number of days that core dump files are kept in the log directory, modify the value of the diskmonitor.CoreRmDays parameter. The default value is 1, which means that core dump files are kept for one day before disk monitor removes them automatically.
Step 8
You can control the maximum number of configurations that can be stored in the configuration library using the diskmonitor.CfgRmDirs parameter. The valid values are the range of integers from 3 through 64. The default value is 64. This parameter is not present in the XECfgParm.dat file initially. If you want to modify the value, you must enter the parameter manually into the file.
Note
If you want to ensure the proper functioning of the prov-sync MML command, set this parameter to a value between 50 and 60.
Note
Entering a value outside of the range of valid values (3 through 64) disables monitoring of the number of entries stored in the configuration library.
Step 9
Save your changes.
This completes the procedures for configuring disk space monitoring. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Configuring the Data Dumper
The data dumper is a Cisco MGC software function that controls the destinations for active and archived log files for CDRs, measurements, and alarms, and controls when the active files are archived. The data dumper runs automatically and works correctly with a default configuration. However, you can customize the dumper settings by editing the dmprSink.dat file.
The following is an example of the contents of the dmprSink.dat file:
"callDetail" bin "cdr" "../var/log" "../var/spool" 1000 0 15
"measReport" csv "meas" "../var/log" "../var/spool" 500 0 15
"almState" csv "alm" "../var/log" "../var/spool" 500 0 15
Table 5-6 lists the fields that can be modified depending on your needs.
Table 5-6 Dumper Sink Log File Parameters
Field Name
|
Default Value
|
Description
|
maxRecs
|
1000
|
The maximum number of records a file can contain before it is flushed or moved to the spool area. If this value is set to 0, the number of records is unlimited. You can improve system performance by increasing the value of this record to a larger value, such as 50000. This results in fewer log record files being generated during periods of high call volume.
|
maxSize
|
0
|
The maximum size of the file in bytes before it is moved to the spool area. If this value is set to 0, the size of the file is limited only by the disk space available.
|
maxTime
|
15
|
The maximum time, in minutes, the file is allowed to remain open, before it is flushed or moved to the spool area. If there is no data in the file, it will not be flushed when the time limit expires. If this value is set to 0, there is no time limit.
|
| |
|
Note One or more of the above fields MUST be set to a value other than zero (0) for each record in the dmprSink.dat file.
|
Caution Do not modify or change any of the following log file configuration values.
|
recordFormat
|
csv
|
The translation of the records being placed in the capture file. Valid values are csv (comma-separated values) or bin (binary).
|
logDirectory
|
/var/log
|
The directory where the current dumper logs reside.
|
logSpoolDir
|
/var/spool
|
The directory to which historic logs are copied after being closed.
|
To configure the dmprSink.dat file fields, use the following procedure:
Step 1
If you are not already logged in, log into a Cisco MGC as root.
Step 2
Change to the /opt/CiscoMGC/etc directory by entering the following UNIX command:
Step 3
Use a text editor, such as vi, to open and edit the dmprSink.dat file fields you want to change.
Note
If you are going to use the BAMS to collect CDRs, proceed to the "Configuring the Data Dumper to Support BAMS" section, for information on how to configure the data dumper to support BAMS.
Step 4
Save your changes and exit the text editor.
Step 5
Change to the /opt/CiscoMGC/etc/CONFIG_LIB/new directory by entering the following UNIX command:
cd /opt/CiscoMGC/etc/CONFIG_LIB/new
Step 6
Stop and start the standby host.
Step 7
Perform sw-over on the active host.
Step 8
Stop and start the newly-standby host (formerly active host).
Step 9
Repeat Step 3 and Step 4 for the version of dmprSink.dat stored in this directory.
Step 10
Change to the /opt/CiscoMGC/etc/active_link directory by entering the following UNIX command:
cd /opt/CiscoMGC/etc/active_link/
Step 11
Repeat Step 3 and Step 4 for the version of dmprSink.dat stored in this directory.
Step 12
If your system is equipped with a second Cisco MGC, repeat Step 1 through Step 10 on this second Cisco MGC.
This completes the procedures for configuring the data dumper. If your system uses BAMS, continue to the "Configuring the Data Dumper to Support BAMS" section. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.
Configuring the Data Dumper to Support BAMS
If your system will use BAMS to retrieve CDRs from the Cisco MGC, perform the following procedure to configure the data dumper to support BAMS:
Step 1
If you are not already logged in, log into a Cisco MGC as root.
Step 2
Change to the /opt/CiscoMGC/etc directory by entering the following UNIX command:
Step 3
Use a text editor, such as vi, to open and edit the dmprSink.dat file fields you want to change.
Step 4
Save your changes and exit the text editor.
Step 5
Change to the /opt/CiscoMGC/etc/CONFIG_LIB/new directory by entering the following UNIX command:
cd /opt/CiscoMGC/etc/CONFIG_LIB/new
Step 6
Stop and start the standby host.
Step 7
Perform sw-over on the active host.
Step 8
Stop and start the newly-standby host (formerly active host).
Step 9
Repeat Step 3 and Step 4 for the version of dmprSink.dat stored in this directory.
Step 10
Change to the /opt/CiscoMGC/etc/active_link directory by entering the following UNIX command:
cd /opt/CiscoMGC/etc/active_link/
Step 11
Repeat Step 3 and Step 4 for the version of dmprSink.dat stored in this directory.
Step 12
If your system is equipped with a second Cisco MGC, repeat Step 1 through Step 10 on this second Cisco MGC.
This completes the procedures for configuring the data dumper to support BAMS. If you have questions or need assistance, see the "Obtaining Documentation, Obtaining Support, and Security Guidelines" section on page xvii.