|
|
This chapter contains recommended operating procedures for the Cisco Media Gateway Controller (MGC). In these procedures, the assumption is that all components have been correctly installed, configured, and provisioned in accordance with the instructions provided in the relevant documentation. All components are assumed to have been successfully started, as described in "System Startup and Shutdown."
This chapter contains the following sections:
Under normal conditions, the primary (active) Cisco MGC application processes all calls. In addition to normal call processing, in a continuous service configuration, the primary Cisco MGC also updates the standby Cisco MGC with call state information for established calls (calls for which an answer message has been received). This ensures that the call state is maintained in case of a failure of the active Cisco MGC.
The following subsections contain the normal operating procedures for the Cisco MGC:
You can use the Cisco MGC software and MML commands to manage signaling channels and lines. You can retrieve signaling channel attributes and change the states of signaling channels and lines.
Signaling channels are bidirectional transport mechanisms for call-control signaling between the Cisco MGC and other devices, such as the Cisco Signaling Link Terminals (SLTs), that provide necessary delivery reliability for higher-layer protocols. All types of signaling channels have basically the same functionality and are managed similarly. Unless otherwise noted, all commands, counters, and alarms apply to all types of signaling channels.
The basic types of signaling channels are
You can retrieve attributes for an individual signaling channel or linkset, or for all signaling channels and linksets.
To retrieve the attributes for an individual signaling channel or linkset, complete the following steps:
rtrv-sc:channel-id | C7_linkset
 |
Note You do not have to change to a subdirectory under $BASEDIR in Release 7.4 and up of the MGC software. |
For example, to retrieve attributes for the iplink1 signaling channel, enter the command:
rtrv-sc:iplink1
Step 2 The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 20:26:18 M RTRV "iplink1:nassvc1,LID=0:IS" ;
In this response,
To retrieve attributes for all of the signaling channels and linksets, perform the following steps:
rtrv-sc:all
Step 2 The system returns a message similar to the following, which shows the signaling links to and from the Cisco MGCs and Cisco Media Gateways (different solutions might use different media gateways).
Media Gateway Controller 2000-03-26 19:23:23 M RTRV "iplink1:nassvc1,LID=0:OOS" /* IP Link 1 for NAS 1 */ "iplink2:nassvc2,LID=0:OOS" /* IP Link 1 for NAS 2 */ "iplink3:nassvc3,LID=0:OOS" /* IP Link 1 for NAS 3 */ "iplink4:nassvc1,LID=0:OOS" /* IP Link 2 for NAS 1 */ "iplink5:nassvc2,LID=0:OOS" /* IP Link 2 for NAS 2 */ "iplink6:nassvc3,LID=0:OOS" /* IP Link 2 for NAS 3 */ "c7iplink1:ls01,LID=0:INB" /* Link 1 in Linkset 1 */ "c7iplink2:ls01,LID=1:INB" /* Link 2 in Linkset 1 */ "c7iplink3:ls02,LID=0:INB" /* Link 1 in Linkset 2 */ "c7iplink4:ls02,LID=1:INB" /* Link 2 in Linkset 2 */ ;
Signal channels comply with the Generic Service State model defined in the "Signaling Link Service States" section. You can change the desired service state of a signaling channel using the following transition requests. Note that there is a difference between a desired service state and an actual service state, and the Cisco MGC might not be able to honor the request. For example, a signal channel that is out-of-service due to an equipment failure cannot transition to an in-service state upon request. The Cisco MGC attempts to bring the channel in-service, but it fails. The failure must be fixed before the transition can succeed.
|
Note Changing the state of a signaling channel generates an alarm. For more information on retrieving and clearing alarms, see "Troubleshooting the Cisco MGC." |
To set the service state of a signaling channel to IS, perform the following steps:
set-sc-state:channel-id:IS
For example, to set the service state of the iplink1 signaling channel to IS, enter the following command:
set-sc-state:iplink1:IS
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 19:23:23 M COMPLD "iplink1" ;
Step 2 To verify that the state of the iplink1 signaling channel is now IS, enter the following command:
rtrv-sc:iplink1
The system returns a message similar to the following, which shows that the service state of the signaling channel is now IS:
Media Gateway Controller 2000-03-26 19:23:23 M RTRV "iplink1:nassvc1,LID=0:IS" ;
To set the service state of a signaling channel to OOS, perform the following steps:
set-sc-state:channel-id:OOS
For example, to set the service state of the iplink1 signaling channel to OOS, enter the following:
set-sc-state:iplink1:OOS
The system returns a message similar to the following:
Media Gateway Controller 2000-03-26 19:23:23 M COMPLD "iplink1" ;
Step 2 To verify that the service state of the iplink1 signaling channel is now OOS, enter the following command:
rtrv-sc:iplink1
The system returns a message similar to the following, which shows that the signaling channel is now in the forced out-of-service (FOOS) service state, and did not fail:
Media Gateway Controller 2000-03-26 19:23:23 M RTRV "iplink1:nassvc1,LID=0:FOOS" ;
If you want to check on the status of a specific signaling path or the status of a signaling destination (point code), enter the following command from the active Cisco MGC:
rtrv-dest: point_code | signal_path | all
Where:
For example, if you enter the command:
rtrv-dest: dpc1
The system returns a message similar to the following:
dpc1:PKG=SS7-ANSI,ASSOC=UNK,PST=IS
Where:
|
Note If this command is entered after a switchover has occurred, the state of some of the destinations might be listed as undefined (UND). UND is the default state for a destination when the system starts. In this instance, UNDs indicate that the Cisco MGC has not received a service state message from the associated destination since the switchover occurred. No user action is required. |
|
Note Refer to the Cisco Media Gateway Controller Software Release 7 Reference Guide for detailed information on all MML commands. |
Dynamic reconfiguration is a function in the Cisco MGC software that allows you to add, modify, or delete one or more network element (NE) components and invoke the appropriate subsystems to deploy the changes while the Cisco MGC system is still in service. Dynamic reconfiguration can be performed without shutting down or restarting either the Cisco MGC software or the Sun host platform.
The NE component types that can be dynamically reconfigured are listed below. No other NE component types can be dynamically reconfigured.
|
Note As of Release 7.4.9, MGCP and SGCP signaling services can be dynamically provisioned. For releases prior to Release 7.4.9, MGCP and SGCP signaling services can be reconfigured only during a system maintenance outage. |
Table 3-1 lists the preconditions that must be met for the NE component before any modification or deletion action can be performed as part of dynamic reconfiguration. There are no preconditions for adding NE components as part of dynamic reconfiguration.
| NE Component | Precondition |
Trunk circuits nailed and switched | Call state must be set to IDLE. Service state must be set to OOS for access ports or Block type must be locally blocked for SS7, and the mated NAS-side CIC must be set to OOS. |
Point codes (DPC, OPC, or APC) Physical link interfaces (TDM, ATM, or Ethernet) Signaling channel links (TDM, ATM, or C7IP) Signaling services SS7 subsystems and routes | Service state must be set to OOS |
Trunk groups Signaling service properties | None. |
For example, if you want to change the properties of a DPC or remove it altogether, you must first set the service state of the DPC to OOS, before attempting to make changes. If you do not set the service state to OOS, your dynamic reconfiguration request is rejected with an error message.
To change the current configuration of NE component using dynamic reconfiguration, you must use only the provisioning tools provided with the Cisco MGC:
Provisioning or configuring by using any other means can cause errors during the dynamic reconfiguration process. Using these tools is required because the dynamic reconfiguration process relies on the provisioning tools to validate the data values and, more importantly, to crosscheck the dependencies of the objects. For example, the provisioning tool ensures that adding a signal transfer point (STP) first requires the existence of the associated route.
 |
Caution Do not attempt to edit .dat files unless specifically instructed to do so. |
Once you complete the changes to the NE components, you can invoke the dynamic reconfiguration function to commit your new configuration in the Cisco MGC. The following procedure lists the sequence of actions you must perform (actual steps to take depend on the provisioning tool you use):
Step 2 If you are changing or deleting NE components, you might have to meet certain preconditions, such as changing the Service state of the NE components to OOS using MML commands (as mentioned in Table 3-1).
Refer to the Cisco Media Gateway Controller Software Release 7 Reference Guide for the MML commands that modify the state of an NE component.
Step 3 Complete changing the NE components as desired.
Refer to the Cisco Media Gateway Controller Software Release 7 Provisioning Guide for provisioning guidelines.
Step 4 Commit or deploy the new configuration.
The commit function is used to apply changes locally. The deploy function is used to apply changes locally and on the peer Cisco MGC. Commit/deploy invokes the dynamic reconfiguration process.
|
Note After completing a dynamic reconfiguration operation on the Cisco MGC, you must issue a service message from the associated media gateway to invoke the changes throughout your solution. |
During dynamic reconfiguration, the system goes through two phases. First, it validates the service states of all objects being changed. If any error is encountered, no reconfiguration takes place on any of the objects. Error messages indicate which NE components are in error. The format of the error message is "NE component's MML name, process rejecting change, reason for rejecting the change, remedy."
If no errors are encountered during the validation phase, the update phase proceeds. This is where the new configuration data is loaded by all of the processes. At the beginning of the update phase, an SNMP alarm is displayed to indicate update starting. At the end of the update phase, the alarm clears, and, if commit/deploy was initiated by MML, the MML response is returned.
In a continuous service Cisco MGC configuration, it is recommended that you commit or deploy the configuration data from the active Cisco MGC. On a standby Cisco MGC, the state of all components is OOS, so effectively there is no validation. If the configuration data is committed locally on the active Cisco MGC, use the synchronization mechanism to commit the configuration changes on the standby Cisco MGC.
You can also use the Cisco MGC software and MML commands to retrieve traffic channel attributes and change the states of traffic channels. Traffic channels are transport mechanisms for handling bearer traffic. Traffic channels are controlled by call-control signals sent from the Cisco MGC over signaling channels to the Cisco MGW.
The basic types of traffic channels (bearer channels) available depend on the type of media gateway employed. For detailed information, refer to the documentation for your media gateway.
You can retrieve the number and status of (1) all traffic channels controlled by a specific signaling channel, (2) a specific set of signaling channels, or (3) all signaling channels. To retrieve the attributes of all traffic channels controlled by a specific signaling channel or a specific set of signaling channels, enter the following command, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-tc:all | channel-id&channel-id&...
For example, to retrieve the attributes of the traffic channels associated with the destination point code 1 (dpc1) signaling channel, enter the command:
rtrv-tc:dpc1
The system returns a different set of responses, depending on which release of the MGC software you are running and the type of configuration you are using on the Cisco Media Gateway.
For Release 7.3 of the MGC software the system returns a message similar to the following:
Media Gateway Controller - MGC-01 2000-04-05 08:26:36 M RTRV "dpc1:CIC=1,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=2,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=3,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=4,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=5,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=6,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=7,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=8,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=9,PST=IS,CALL=IDLE,BLK=NONE"
For Release 7.4 and up of the MGC software used on a switched network, the system returns a message similar to the following:
Media Gateway Controller - MGC-04 2000-04-05 08:05:54 M RTRV "dpc1:CIC=1,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=2,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=3,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=4,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=5,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=6,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=7,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=8,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE" "dpc1:CIC=9,PST=IS,CALL=IDLE,GW_STAT=CXN_IS,BLK=NONE"
For Release 7.4 and up of the MGC software used on a nailed up network, the system returns a message similar to the following:
Media Gateway Controller - MGC-67 2000-04-05 08:08:12 M RTRV "dpc1:CIC=1,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=2,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=3,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=4,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=5,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=6,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=7,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=8,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=9,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=10,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=11,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=12,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=13,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=14,PST=IS,CALL=IN,BLK=NONE" "dpc1:CIC=15,PST=IS,CALL=IN,BLK=NONE"
The command rtrv-tc:all returns information similar to that shown above for all traffic channels. Depending on the number of individual traffic channels that are provisioned on your system, the response could be quite lengthy.
You can retrieve the status of one or more bearer channels that are identified by a DPC. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
rtrv-cic:point_code:CIC=number[,RNG=slaves]
Where:
For example, the MML command listed below retrieves bearer channel information for CICs 10-15 on destination point code dpc1:
RTRV-CIC:dpc1:cic=10,rng=5
The system returns a message similar to the following:
Media Gateway Controller - MGC-04 2000-04-05 08:05:54 M RTRV "dpc1:CIC=10,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=11,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=12,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=13,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=14,PST=IS,CALL=IDLE,BLK=NONE" "dpc1:CIC=15,PST=IS,CALL=IDLE,BLK=NONE"
Cisco MGCs can be arranged in an Active-Standby configuration in which one MGC host runs active traffic while checkpointing information to the standby Cisco MGC. In the continuous service configuration, the active Cisco MGC is paired with an identical standby Cisco MGC that automatically takes over if a failure or switchover occurs. The continuous service architecture of the Cisco MGC increases the reliability, availability, and failure-aversion capabilities of the system.
The primary goal of the Cisco MGC failover subsystem is to ensure call preservation when there is a system failure. This is achieved by interconnecting two Cisco MGCs while the system carries out the logical functions of call control. At any point, one Cisco MGC is in the active role and the other Cisco MGC is in the standby role. The active Cisco MGC carries out the call control function and updates the standby Cisco MGC about call-processing events. The standby Cisco MGC maintains the same system state (from the call-processing point of view) as the active Cisco MGC. In the event of a critical failure on the active Cisco MGC, the standby switches to the active role and takes over the call control function, ensuring that all established calls are preserved.
|
Note If your system is using a simplex configuration (a single Cisco MGC), or is functioning in standalone mode (the standby Cisco MGC is in the OOS service state), the system cannot perform a switchover. In these instances, the active Cisco MGC remains in the active service state when a critical failure occurs. |
Switchovers can occur automatically (also known as failovers) when a critical alarm is generated, or a switchover can be performed manually, typically as part of a maintenance or troubleshooting procedure. For more information on performing a manual switchover, refer to the "Manual Switchover" section.
You can determine whether a switchover (automatic or manual) was successfully completed by retrieving the status of each Cisco MGC. To do this, complete the following steps:
rtrv-ne
The system should return a message, similar to the following, that indicates that it is currently the active Cisco MGC:
Media Gateway Controller 2000-03-29 14:15:22 M RTRV "Type:VSC" "Hardware platform:sun4u sparc SUNW,Ultra-5_10" "Vendor:"Cisco Systems, Inc."" "Location:Virtual Switch Controller" "Version:"7.3(8)"" "Platform State:ACTIVE"
Step 2 Start an MML session on the newly standby Cisco MGC, and enter the following command:
rtrv-ne
The system should return a message, similar to the following, that indicates that it is currently the standby Cisco MGC:
Media Gateway Controller 2000-03-29 14:15:22 M RTRV "Type:VSC" "Hardware platform:sun4u sparc SUNW,Ultra-5_10" "Vendor:"Cisco Systems, Inc."" "Location:Virtual Switch Controller" "Version:"7.3(8)"" "Platform State:STANDBY"
If the platform state of both Cisco MGCs was as expected, the switchover was successfully completed.
If one of the Cisco MGCs does not return the expected platform state, the switchover was not successfully completed. Refer to the "Recovering from a Switchover Failure" section.
The following component processes of the Cisco MGC are fault-tolerant. In other words, each of these processes knows its own state (Active/Standby/Out-of-Service) and the corresponding state of its peer process on the standby system.
The active Cisco MGC runs the procM process. ProcM automatically starts when the Cisco MGC is booted and, in turn, starts the alarm manager, configuration manager, call engine, IOCCs, and other processes, including foverd.
The continuous service architecture is controlled by the failover daemon. The failover daemons on both Cisco MGC hosts coordinate the active, standby, and OOS states of those hosts.
The alarm manager process also plays a significant role in a continuous service system. The alarm manager raises the alarm when a critical event occurs and clears the alarm when the condition that caused the alarm is cleared. See the Cisco Media Gateway Controller Software Release 7 Reference Guide for detailed information regarding alarms, specifically which alarms are critical.
The foverd process directs manual switchovers. The switchover configuration provides the following:
A critical event is typically a critical process dying or the failure of a subsystem or component that can critically affect call processing. A forced failover occurs automatically when the conditions governing it are met; it is system-initiated and not user-initiated. When a critical event occurs, the alarm manager sends a specific message to the foverd process, indicating the occurrence of the critical event.
When the failover daemon receives notification that a critical event has occurred on the active Cisco MGC, the failover daemon initiates a forced switchover to the standby Cisco MGC. The standby Cisco MGC transitions immediately to the active state; established calls are maintained, but calls still in the process of being set up are lost.
The occurrence of a critical event on system A results in its peer, system B, becoming active while system A goes to an OOS state. Until the critical event that triggered the failover on system A is cleared, its state remains OOS. When the critical event is cleared, the alarm manager sends another message, known as a Clear Alarm message, to the foverd process. The foverd process drives system A to a standby state (if the peer system (B) is still in the active state).
When the critical event is cleared, the failed controller (A) comes back online. It can then become the standby for the currently active Cisco MGC (B). Initially, system A is still OOS. The platform state of system A continues to be OOS until the critical event is cleared.
Established calls are maintained during a switchover because the Call Engine checkpoints call information from the active Cisco MGC to the standby Cisco MGC. In addition, the state of the SS7 network is checkpointed by the MTP3 IOCC. The MTP2 terminal functionality resides on the Cisco SLTs to enable the fault-tolerant MTP3 solution.
The Cisco SLTs are responsible for SS7 MTP2 message processing. The Cisco SLTs communicate directly with the Cisco MGC hosts (active and standby) using RUDP, but they send SS7 traffic only to the active Cisco MGC.
|
Note The number of Cisco SLTs is dependent on the SS7 network traffic load and on link and linkset requirements. It is generally recommended that a minimum of two links per linkset, one link per Cisco SLT, be used to provide SS7 reliability. To further enhance redundancy, it is recommended that the links in a linkset be spread across multiple Cisco SLTs so that any single unit can be removed, added, or serviced without disrupting the SS7 network. |
An auditing process discovers discrepancies in circuit states between the Cisco MGC and the media gateways it controls. During a switchover, discrepancies might exist as to the state of bearer circuits (CICs) between the newly active Cisco MGC and the bearer devices it controls. Discrepancies in circuit states between the active Cisco MGC and the bearer devices could also occur as the result of control messages to the bearer devices that get lost.
The circuit auditing mechanism can be run periodically at configured intervals or after a failover or switchover. It can also be initiated manually using the MML command, sw-over::confirm. The audit capability is always initiated automatically on indication of critical error conditions from solution components, adjacent SS7 switches, or when critical Cisco MGC conditions occur. The circuit-auditing mechanism detects and resolves circuit state discrepancies that it discovers and resynchronizes the Cisco MGC and the bearer devices.
|
Caution During a switchover operation, the formerly active Cisco MGC attempts to transition to the standby platform state. To do this, the MGC attempts to synchronize its system configurations (stored in the configuration library) with the system configurations for the active Cisco MGC. If you are storing a large number of system configurations, the state transition fails and the Cisco MGC goes to an OOS state. To avoid this failure, you should store no more than 64 configuration versions in the library. For more information about administering the configuration library, refer to the "Config-Lib Viewer" section. |
The circuit auditing mechanism is a function of the call engine process in the active Cisco MGC. The call engine subsystem starts a thread to perform the circuit-auditing function upon notification of a switchover event from the fault manager.
The circuit auditing mechanism commands the bearer devices to reflect the circuit state of the Cisco MGC. If a bearer device believes the circuit to be in use and the Cisco MGC does not, the Cisco MGC releases the circuit. However, if the Cisco MGC shows that a bearer circuit is in use and discovers that the bearer device does not show that circuit as in use, the Cisco MGC does not attempt to rebuild the call, but releases all associated resources. Even though the Cisco MGC is the controlling authority, the only course of action when a discrepancy is discovered during a circuit audit is to release all of the allocated resources, which means dropping the call.
Checkpointing of calls ensures that established calls are preserved in the event of a switchover. The Call Engine sends checkpoint events to the local checkpoint process at one point during call setup and at one point in the call release phase.
Checkpointing is also applied to the following protocol supervisory messages and MML commands that change the logical state of the bearer circuits:
The local checkpointing process is responsible for securing these events to disk if the standby Cisco MGC is unavailable and for forwarding those events to the remote checkpointing process once it does become available. If the standby Cisco MGC is running, checkpoint events are batched and forwarded to the remote checkpointing process.
The remote checkpointing process is responsible for handling the checkpoint events from the active Cisco MGC, delivering only established calls to the remote call engine. The remote call engine process begins checkpointing events for calls when it begins active call processing.
The following scenarios are supported:
Checkpointing is also implemented to support forward Cisco MGC software migration by one release. You can manually take the standby Cisco MGC out of service, upgrade the software to the new release, and resynchronize calls with the active Cisco MGC. For detailed procedures on upgrading the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 7 Installation Guide.
In the continuous service configuration, you can swap the roles of the active Cisco MGC and the standby Cisco MGC by invoking the appropriate MML command from the management interface of the active Cisco MGC. A switchover can be done only from the active Cisco MGC, because only the active Cisco MGC can command the standby Cisco MGC to take over. If there is only one Cisco MGC processing all calls, a manual switchover request is rejected.
Manual switchovers are typically performed for the following reasons:
When you need to order a manual switchover to perform maintenance or upgrade procedures on one or both of the Cisco MGCs, use the following steps or all calls might be killed by the Call Engine. Starting with both the active and standby Cisco MGCs operating normally, you can invoke a manual switchover from one system to the other by completing the following steps:
Step 2 Determine whether any alarms are pending on either system.
If any alarms are pending, you must correct the situation that caused the alarms. Refer to "Troubleshooting the Cisco MGC," for actions to clear alarms.
Step 3 Ensure that the replication of calls from the active Cisco MGC to the standby Cisco MGC is happening. Designate the active Cisco MGC as system A and designate the standby as system B.
For example, check CIC states, for a few CICs (approximately 10 to 15 randomly chosen CICs) using the following MML command, on the active as well as the standby Cisco MGC:
rtrv-cic:point_code:cic=number
The respective CICs on the two Cisco MGCs should be in the same state.
Step 4 Issue a provisioning synchronization command (from either of the two Cisco MGCs):
prov-sync
This synchronizes the provisioning of the standby Cisco MGC with respect to the active system and also ensures that the communication link between the two systems is functional.
|
Caution During a provisioning synchronization operation, the standby Cisco MGC attempts to synchronize its system configurations (stored in the configuration library) with the system configurations for the MGC. If you are storing a large number of system configurations, the provisioning synchronization fails and the standby Cisco MGC goes to an OOS state. To avoid this failure, you should store no more than 64 configuration versions in the library. For more information about administering the configuration library, refer to the "Config-Lib Viewer" section. |
Step 5 Log in to one of the two Cisco MGCs, start an MML session, and enter the following command:
rtrv-ne
The system returns a message, similar to the following, that indicates whether it is currently the active or standby Cisco MGC:
Media Gateway Controller 2000-03-29 13:42:39 M RTRV "Type:VSC" "Hardware platform:sun4u sparc SUNW,Ultra-30" "Vendor:"Cisco Systems, Inc."" "Location:Media Gateway Controller" "Version:"7.4(7)G"" "Platform State:ACTIVE" ;
Step 6 Check that all the processes on the active Cisco MGC are in the running state by the following MML command:
rtrv-softw:all
The system returns different sets of messages depending on which release of the Cisco MGC software you are running. For Release 7.3 of the MGC software, the system returns a message similar to the following:
Media Gateway Controller - MGC-01 2000-04-05 08:11:02 M RTRV "CFM-01:RUNNING" "ALM-01:RUNNING" "MM-01:RUNNING" "AMDMPR-01:RUNNING" "CDRDMPR-01:RUNNING" "DSKM-01:RUNNING" "MMDB-01:RUNNING" "POM-01:RUNNING" "MEASAGT:RUNNING" "OPERSAGT:RUNNING" "PROVSAGT:RUNNING" "MGCP-1:RUNNING " "Replic-01:RUNNING " "ENG-01:RUNNING " "IOCM-01:RUNNING " "TCAP-01:RUNNING " "FOD-01:RUNNING " "EISUP-1:RUNNING " "SS7-A-1:RUNNING " "LOG-01:RUNNING "
This message shows the status of all processes.
For Release 7.4 and up of the MGC software, the system returns a message similar to the following:
Media Gateway Controller - MGC-04 2000-04-05 08:06:03 M RTRV "CFM-01:RUNNING ACTIVE" "ALM-01:RUNNING ACTIVE" "MM-01:RUNNING ACTIVE" "AMDMPR-01:RUNNING ACTIVE" "CDRDMPR-01:RUNNING ACTIVE" "DSKM-01:RUNNING IN N/A STATE" "MMDB-01:RUNNING IN N/A STATE" "POM-01:RUNNING ACTIVE" "MEASAGT:RUNNING ACTIVE" "OPERSAGT:RUNNING ACTIVE" "PROVSAGT:RUNNING ACTIVE" "MGCP-1:RUNNING IN N/A STATE" "Replic-01:RUNNING ACTIVE" "ENG-01:RUNNING ACTIVE" "IOCM-01:RUNNING ACTIVE" "TCAP-01:RUNNING IN N/A STATE" "FOD-01:RUNNING IN N/A STATE" "EISUP-1:RUNNING IN N/A STATE" "SS7-A-1:RUNNING IN N/A STATE" "LOG-01:RUNNING IN N/A STATE" ;
This message shows the status of all processes.
|
Caution The next step forces a manual switchover to the standby Cisco MGC. Ensure that the standby Cisco MGC is fully operational and that debugging is turned off before taking the active Cisco MGC OOS, or there might be a total interruption of service. Switchover (or failover) can also cause call processing to fail if debugging is turned on. |
|
Caution During a switchover operation, the formerly active Cisco MGC attempts to transition to the standby platform state. To do this, the MGC attempts to synchronize its system configurations (stored in the configuration library) with the system configurations for the active Cisco MGC. If you are storing a large number of system configurations, the state transition fails and the Cisco MGC goes to an OOS state. To avoid this failure, you should store no more than 64 configuration versions in the library. For more information about administering the configuration library, refer to the "Config-Lib Viewer" section. |
Step 7 Log in to the active Cisco MGC, start an MML session, and enter the following command:
sw-over::confirm
The system returns a message similar to the following:
Media Gateway Controller 2000-03-29 13:54:15 M COMPLD "Proc Mgr"
Site alarms are automatically set until the OOS Cisco MGCD is returned to an IS state.
Step 8 Verify that the switchover has been successfully performed. To do this, follow the procedure described in the "Verifying Successful Completion of a Switchover" section.
If the Cisco MGC has a failure, or some component has been replaced or updated, it might be necessary to reset the system clock. To do this, complete the following steps:
/etc/init.d/CiscoMGC stop
This forces the standby Cisco MGC into the FOOS service state.
Step 2 With the standby Cisco MGC in the FOOS service state, enter the following command:
/etc/rc2.d/K90timestend32.32 stop
This command stops the clock on the standby Cisco MGC.
Step 3 Perform the necessary date and time changes on the Cisco MGC.
Refer to the Sun documentation for the procedures for resetting the system time.
Step 4 Restart the clock on the standby Cisco MGC by entering the following command:
/etc/rc2.d/K90timestend32.32 start
Step 5 Return the standby CiscoMGC to the IS service state by entering the following command:
/etc/init.d/CiscoMGC start
Ensure that the standby Cisco MGC becomes fully operational and that the replication of calls in progress has been completed by performing the following steps:
|
Caution The following command retrieves the current status of all provisioned traffic channels. If you have a large number of traffic channels, you might want to limit the command to a subset of the provisioned channels. |
rtrv-tc:all
Each system returns a response, similar to the following, that lists the current status of all of the traffic channels that have been provisioned on the associated gateways:
Media Gateway Controller 2000-03-29 15:35:31 M RTRV "dpc1:CIC=1,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=2,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=3,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=4,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=5,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=6,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=7,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=8,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=9,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=10,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=11,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=12,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=13,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=14,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=15,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=16,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=17,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=18,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=19,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=20,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=21,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=22,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=23,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=24,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=25,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=26,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=27,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=28,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=29,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=30,PST=OOS,CALL=IDLE,BLK=NONE" "dpc1:CIC=31,PST=OOS,CALL=IDLE,BLK=NONE" (more) ...
Step 2 Verify that the CICs in both systems are in sync and show the same status.
Calls in progress should say CALL=IN for both systems.
If necessary, you can force the active Cisco MGC to do a maintenance switchover (see the "Managing Switchover" section) and repeat the above procedure for that system.
This section describes the various components of the Cisco MGC viewer toolkit, a standalone diagnostic component available in Release 7.4 and up of the MGC software. The Cisco MGC viewer toolkit is used to view different types of files on the Cisco MGC. This section describes the various components and the toolkit concept as a whole.
The Cisco MGC viewer toolkit is a suite of viewing tools that were developed to run on the Cisco MGC to provide quick and efficient access to diagnostic and troubleshooting information.
The following viewers are discussed in the following subsections:
The Cisco MGC toolbar (Figure 3-1) is a graphical user interface (GUI) application used to launch the various viewers in the toolkit. Each application runs independently of the others, and there is a button for launching each application in the toolbar.
You can run multiple instances of the Cisco MGC toolbar at one time, but only one instance of each tool can be running at a time, and different tools can be run simultaneously. If the selected application is already running, a message is displayed stating that your user ID and the application are already running. There is also a Close button on the toolbar, which is used to close the toolbar; however, closing the toolbar does not stop toolkit applications that are already running.
|
Caution The potential exists for foreground (text) and background (non-text) settings to conflict because your local display settings might conflict with the toolkit's color settings, thus rendering the text within various fields in the toolkit applications unreadable. If you have problems reading text on any of the toolkit screens, please change the foreground color to a darker color on your display to see if that solves the problem. |
To launch the Cisco MGC toolbar, complete the following steps:
cd /opt/CMM/bin
Step 2 Enter the following command to launch the Cisco MGC toolbar:
./start.sh tool
The MGC Toolbar window is displayed.
The alarm and measurement viewer helps you view and search records that reside in the alarm and measurement record logs. The formats of the various alarm and measurement records are specified in the Cisco Media Gateway Controller Software Release 7 Reference Guide. These records are not designed for user reading, but for database loading. These viewers can help you understand these records, and they also provide useful searching functions based on the components and categories you select.
The alarm and measurement viewer offers a help file, which contains information about the viewer. To access the information, click the Help menu, select ReadMe, and the help text is displayed. You can also use this viewer to determine the current timestamp. To do this, click the Time menu, select TimeStamp. The current timestamp is displayed in a window.
You can exit the Alarm and Measurement Viewer in one of two ways: in the Query Criteria portion of the window, click Exit, or from the File menu, select Exit.
Complete the following steps to view and search various system measurement files:
Step 2 Select the system measurement file(s) you want to display from the field to the right of the Query Criteria portion of the window.
You can select multiple files in this field using any of the following techniques:
Step 3 To search by a component, select a component type from the CompType drop-down list box. If you do not want to search by a component or you want to view the entire content of the file(s), select the NO_SPECIFIC entry.
Click CompList to acquire the configured components for the type you selected. The results are displayed in the drop-down list box next to the button. Select a component from that list box.
Step 4 To search by a category, select a category type from the catType drop-down list box. If you do not want to search by a category or you want to view the entire content of the file(s), select the NO_SPECIFIC entry.
Click measList to acquire the configured categories for the type you selected. The results are displayed in the drop-down list box next to the button. Select a category from that list box.
Step 5 Click Execute to search the selected system measurement file(s). The results of the search are displayed as blue text in the field at the bottom of the window.
Step 6 If you want to perform additional searches, repeat steps 2 to 5. The color of the text from the old search changes from blue to black and the newly requested search data is inserted as blue text, appearing after the old data. Scroll down through the field to view the data you have added (You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data).
Step 7 If you want to save the displayed data, click Save. The contents of the field are saved to a file with the following directory path:
/opt/CiscoMGC/etc/cust_specific/toolkit/measRec.log
If you perform another search and save the resulting content, the contents of the field are added into the measRec.log file, after the previously saved data. If you do not want the data to be added onto the previous data, you must change the name of the measRec.log file before you save again. To change the name of a file, refer to the procedures in the "File Options Viewer" section.
If you do not find your desired data, you can update the list of system measurement files by clicking Refresh. Repeat the above steps to search through the newest files.
Complete the following steps to view and search various system alarm files:
Step 2 Click the Alarm Record View tab. The Alarm Record View tab window displays (Figure 3-3).
Step 3 Select the alarm file(s) you want to display from the field to the right of the Query Criteria portion of the window.
You can select multiple files in this field using any of the following techniques:
Step 4 To search by a component, select a component type from the CompType drop-down list box. If you do not want to search by a component or you want to view the entire contents of the file(s), select the NO_SPECIFIC entry.
Click CompList to acquire the configured components for the type you selected. The results are displayed in the drop-down list box next to the button. Select a component from that list box.
Step 5 To search by a category, select a category type from the alarm category drop-down list box. If you do not want to search by a category or you want to view the entire contents of the file(s), select the NO_SPECIFIC entry.
Step 6 Click Execute to display the contents of the selected alarm file(s). The contents are displayed as multicolored text in the field at the bottom of the window.
The following list describes the text colors associated with the alarm types
Step 7 If you want to perform additional searches, repeat steps 2 to 6. The color of the text from the old search changes from multicolored to blue and the newly requested search data is inserted as multicolored text, appearing after the old data. Scroll down through the field to view the data you have added. You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data.
Step 8 If you want to save the displayed data, click Save. The contents of the field are saved to a file with the following directory path:
/opt/CiscoMGC/etc/cust_specific/toolkit/alarmRec.log
If you perform another search and save that content again, the contents of the field are added into the alarmRec.log file, after the previously saved data. If you do not want the data to added onto the previous data, you must change the name of the alarmRec.log file before you save again. To change the name of a file, refer to the procedures in the "File Options Viewer" section.
If you do not find your desired data, you can update the list of alarm files by clicking Refresh. Repeat the above steps to search through the newest files.
CDRs contain basic call billing information, such as date and time, duration, and the calling number and called number. CDR records are written into files that contain information about telephone activity. CDR files are saved in a comma-delimited format (called a "Tag-Length-Value" or TLV file). The TLV file is a generic format that can be easily imported into most third-party mediation applications.
The CDR dumper (see Figure 1-1) provides logging capabilities on the Cisco MGC for all CDRs. Also, the CDR dumper supports external user application programming interfaces (APIs). The APIs allow users to get a real-time feed of CDRs and call detail blocks (CDBs) from the Cisco MGC that can be routed to a third-party mediation application for use in billing.
The CDR dumper operates according to the configuration set up in the XECfgParm file. When certain thresholds are met, the CDR dumper closes and saves the generated CDB records into the $BASEDIR/var/spool directory. It then passes the filename and fork to the TLV Converter application described in the "Using the TLV Converter" section.
The CDR viewer is designed to help you view and search call detail records that reside in the CDR logs. The formats of the CDRs are specified in the Cisco Media Gateway Controller Software Release 7 Reference Guide. These records are designed for database loading, not user reading. The CDR Viewer can help you understand these records, and it also provides useful searching functions based on the search criteria you select.
|
Note Your screen might be slightly different from this example, depending on which release of the software you are running. |
You can exit the CDR viewer in one of two ways: in the Query Criteria portion of the window, click Exit, or from the File menu, select Exit.
Whenever you start the CDR viewer, you must select several configuration settings before you can view or search the CDR files. To do this, complete the following steps.
Step 2 Click the Config tab. The Config tab window displays (Figure 3-4).
The first five fields in the window cannot be modified. These fields list the directory paths and file names for the related data files.
Step 3 You can modify the directory path and file name for the file in which any CDR search results can be saved. To do this, click in the Search Result Log File field and change the displayed information.
|
Note We recommend that you not use this field to change the directory information for the CDR search results file. |
Step 4 You can also set the source for your CDR information to either a local or remote host.
If you want to use a local host as your source for CDR information, click the Source CDRs From Local check box and proceed to Step 5.
If you want to use a remote host as your source for CDR information, click the Source CDRs From Remote check box and proceed to Step 6.
|
Note If you change your CDR source from local to remote, the tab for the ConnHost window (Figure 3-5) appears. If you change your CDR source from remote to local, the tab for the ConnHost window disappears. |
Step 5 You can modify the CDR source directory on your local host. To do this, click in the CDR Data Dictionary on Local Host field and change the displayed information.
Proceed to Step 11 to select the message type(s) for which you are searching.
Step 6 You can modify the CDR source directory on your remote host. To do this, click in the CDR Directory on Remote Host field and change the displayed information.
Step 7 Click the ConnHost tab to display the ConnHost tab window (Figure 3-5).
Step 8 You can add or modify the name of the remote host. To do this, select the From Remote Host field and enter the name of the remote host you want to use a source for your CDR files.
Step 9 If you add or modify a remote host name, you must enter user account information for the viewer to use in accessing the host. To do this, enter the appropriate user name and password data in the User Name and Password fields, respectively.
Step 10 You can modify how frequently the CDR viewer checks the remote host for new CDB files. To do this, enter the value you want (in minutes) in the Remote Host CDR Collection Interval(Min) field.
If you set the interval value above zero, after you click Connect, you are notified by a popup message box when new CDB files are deposited on the remote host. You can click OK in the message box to dynamically update the CDB files on the local host, or you can click NO to keep the local CDB file directory as it is.
If you set the interval value to zero, you are not notified of file changes on the remote host, and the CDB files on the local host are not dynamically updated.
The FileDumpCriteria(0=NoLimit) field displays the configuration information for CDRs on the Cisco MGC. This content of this field cannot be modified.
Step 11 You must specify the message type(s) for which you are searching. To do this, click the Config tab to display the Config tab window (Figure 3-4), and select the message type(s) you are looking for in the All Possible Message Types field. Click the right arrow button and the specified message type(s) are displayed in the Selected filtering field.
You can select multiple files in this field using any of the following techniques:
You can remove message type(s) from your search criteria by selecting the desired message type(s) in the Selected filtering field and clicking the left arrow button.
You can search through the various alarm files by component and category. To do this, complete the following steps:
If you have just opened the viewer, you must configure it before you can search the CDR files. Refer to "Configuring the CDR Viewer" section.
Step 2 If your CDR files are coming from a local host, proceed to Step 8.
If your CDR files are coming from a remote host, proceed to Step 3.
Step 3 Click the ConnHost tab to open the ConnHost tab window.
Step 4 If the fields in the window are properly data filled, click Connect to establish contact with the remote host.
If the fields in the window are not properly data filled, perform the configuration steps for this window as described in the "Configuring the CDR Viewer" section. Once you have completed this, resume this procedure.
Step 5 Select the file(s) you want to search from the file on the remoteHost field.
You can select multiple files in this field using any of the following techniques:
Step 6 Click Manual Transfer to copy your selected file(s) to the local host.
If you want to remove the files from your local host, you can click Clear Local Files. If you want to update the listed files in the file on the localHost field, you can click Refresh Local Dir.
Step 7 Click the Query tab to display the Query tab window.
Step 8 Select the CDR file(s) you want to search from the field to the right of the Query Criteria portion of the window.
You can select multiple files in this field using any of the following techniques:
Step 9 If you want to view your selected CDR file(s) in their entirety, proceed to Step 13.
If you want to search through your selected CDR file(s) for particular type(s) of CDRs, proceed to Step 10.
Step 10 You can search through your selected CDR files based on six different field values:
To select a field value, click the check box next to the name. You can select as few or as many field values as you require.
Step 11 Enter a search qualifier and related string for each of the field values you selected. To do this, choose a search qualifier, as defined below, for the search string from the drop-down list box to the right of a field value you have selected.
Enter a search string in the field to the right of the search qualifier you just choose.
Repeat this step for all field values that you have selected for your search.
Step 12 Choose a query operator (AND or OR) for your search. You can search for CDBs that have all of the field values you selected (AND) or you can search for CDBs that have any of the field values you selected (OR). The default value is AND. Click the appropriate check box to specify your query operator.
Step 13 Click Execute to display the contents of the selected alarm file(s). A popup window displays while the contents load. The contents are displayed as multicolored text in the field at the bottom of the window.
Step 14 If you want to perform additional searches, repeat steps 2 to 13. The color of the text from the old search changes from multicolored to black and the newly requested search data is inserted as multicolored text, appearing after the old data. Scroll down through the field to view the data you have added. You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data.
Step 15 If you want to save the displayed data, click Save. The contents of the field are saved to the file you specified in the Config tab window.
If you perform another search and save that content again, the contents of the field are added to the same file, after the previously saved data. If you do not want the data to added to the previous data, you must change the name of the file before you save again. To change the name of a file, refer to the procedures in the "File Options Viewer" section.
Step 16 If you do not find your desired data, you can update the list of alarms files by clicking Refresh. Repeat the above steps to search through the newest files.
You can use the Config-Lib viewer (Figure 3-7) to manage the contents of the configuration library. The configuration library stores the various system configurations that you created while you provisioned your Cisco MGC.
Click CONFIG-LIB on the Cisco MGC toolbar to open an xterm window and execute the config-lib script. To quit the Config-Lib Viewer, enter q at the prompt.
The Config-Lib Viewer enables you to do the following functions
|
Note We recommend that you not attempt to restore an old configuration version without the assistance of the Cisco Technical Assistance Center (TAC). |
|
Note We recommend that you store no more than 64 configuration versions in the library, because that prevents possible switchover failure. If you are storing more than 64 configuration versions, we recommend deleting some of your configuration versions. |
The Log Viewer (Figure 3-8) offers selection and reporting capabilities that allow you to retrieve and display log messages from the system log files.
You can exit the Log Viewer in one of two ways: click Exit, or select Exit from the File menu.
Complete the following steps to search through various system log files:
Step 2 Select the log file you want to display from the Log Files field.
|
Note If the log file you want to view are not displayed in the Log Files field, refresh the list by clicking Refresh Log File List, or by clicking the File menu and selecting Refresh. If the desired file is still not displayed, you might need to change the directory path used by the viewer. To do this, click the File menu and select Log Directory. Enter the appropriate directory path in the Log Directory field and click Modify to save the new settings. The log files contained in the directory path you specified are displayed in the Log Files field. |
Step 3 You can search for logs that occurred between a certain dates and times, specifying month, day, year, hour, and minute settings. To do this, select a starting date and time from the Start Date/Time drop-down list boxes and then select a stopping date and time from the Stop Date/Time drop-down list boxes.
The current date and time are the default values for both the start and stop values for the time period; however, using these values results in a null search (no records).
The Use Current Time as Stop Time check box, if selected, disables the Stop Date/Time drop-down list boxes and allows searching to continue to the end of the file.
Step 4 You can search for logs of certain log categories. To do this, select your desired category or categories by clicking one or more entries in the Category list box. To select multiple entries, hold down either the Ctrl or Shift key while clicking. The available categories are
Click the right arrow to enter your selected categories into the search. The selected categories appear in the list box to the right of the arrow buttons. To deselect a category, click one or more entries in the right list box and click the left arrow.
Step 5 You can search for logs of certain severities. To do this, select a severity or severities by clicking one or more entries in the Severity list box. To select multiple entries, hold down either the Ctrl or Shift key while clicking.
The severity choices are cumulative—each level selected also displays all levels below it. For example, the ERR selection displays both ERR (error) and CRIT (critical) messages. The severity levels are
Click the right arrow to enter your selected categories into the search. The selected categories appear in the list box to the right of the arrow buttons. To deselect a category, click one or more entries in the right list box and click the left arrow.
Step 6 You can search for logs that contain a particular text string. To do this, enter the desired search string in the Text String field. The text is case-sensitive, and all characters are allowed.
Step 7 You also can choose to display debug messages. Debug messages do not conform to the log message format. If you select this option, the debug messages are filtered only on date/time and text string. To do this, click the Show Debug Messages check box. Debug messages similar to the following are displayed:
platform.log : currently active log Fri Apr 14 17:57:19:253 2000 | ProcessManager (PID 24929) <Debug> initialized process info for 'POM-01' Fri Apr 14 17:57:25:908 2000 | ProcessManager (PID 24929) <Debug> Received heartbeat response from process CFM-01
Step 8 Click Execute to display the results from the selected alarm file(s). The results are displayed in the field at the bottom of the window, in 5-MB blocks.
While the application is searching through the log files, a dialog box appears. This dialog box displays the progression of the search. It also allows you to stop searching by pressing Stop.
Your results may be lengthy, resulting in several pages of information. You can use several buttons to navigate through your results. To go to the end of your results, click Bottom. To go to the next 5-MB page of results, click More. To go to the beginning of your results, click Top.
Step 9 If you want to save the displayed data, click the File menu and select Save. A popup window lists the default save directory (/opt/CiscoMGC/etc/cust_specific/toolkit). Enter a file name for your data in the File Name field and click Save to save your data.
Step 10 If you want to perform additional searches, repeat steps 2 to 9. The old search data is replaced by the new search data. You can clear the display field by clicking Clear before you click Execute.
You can use the trace viewer as part of performing a call trace. Clicking Trace Viewer in the MGC Toolbar creates a list box of trace files for you to choose from (Figure 3-9). When you select a file, you can click View to run the get_trc.sh UNIX shell script utility, which allows you to view a number of different types of files. Get_trc.sh uses the Conversion Analyzer and SimPrint utilities to give a common interface to all the trace tools. Get_trc.sh makes considerable use of the UNIX less utility for displaying file output and it is assumed that it is available on your system. For more information about call traces, refer to the "Call Tracing" section.
The translation verification viewer offers a means of interfacing with the translation verification tool. The translation verification tool provides you with a means to understand how calls are being processed based on your system's dial plan. This tool creates a simulation of a call being processed by your system's dial plan.
You can exit the Translation Verification Viewer by clicking on the File menu and selecting Exit.
Complete the following steps to verify a dial plan translation:
Step 2 Enter the incoming trunk group number for your simulated call in the trunk group number field.
Step 3 Specify an ISDN preference for the selecting of the outgoing trunk by choosing a value from the message specific ISDN preference drop-down list box. The following values are valid for this field.
Step 4 Specify the Nature Of Address (NOA) setting for the called party by selecting a value from the called party's Nature of Address drop-down list box. The following values are valid for this list.
Step 5 Specify the Numbering Plan Indicator (NPI) setting for the called party by selecting a value from the called party's Numbering Plan Indicator drop-down list box. The following values are valid for this field.
Step 6 Specify the called number in the called numbers field.
Step 7 Specify the calling number in the calling numbers field.
Step 8 Specify the level of the trace by selecting a value from the trace level drop-down list box. The following values are valid for this list.
Step 9 Click Execute to perform a dial plan translation verification. The results are displayed in the field at the bottom of the window.
Step 10 If you want to perform additional searches, repeat steps 2 to 9. The newly requested search data is inserted after the old data. Scroll down through the field to view the data you have added. You can clear the display field by clicking Clear before you click Execute, if you no longer require the previously requested data.
Step 11 If you want to save the displayed data, click SaveinFile. The contents of the field are saved to a file specified in the XECfgParms.dat file.
Complete the following steps to view the dial plan translation configuration data:
Step 2 Click the Config tab to display the Config tab window (Figure 3-11). The fields in this window display the directory paths to the files used by this viewer. The values in these fields cannot be modified.
The file options viewer (Figure 3-12) enables you to manage (rename, delete) the files within the $BASEDIR/etc/cust_specific/toolkit directory. This directory contains all files created by the various toolkit applications. It also enables you to manage subdirectories created under the cust_specific directory. These subdirectories are created through the MML export feature and contain configuration information in the form of MML commands.
The Cisco MGC Software Release 7 currently offers only a Tag-Length-Value (TLV) binary CDB file format for customer billing systems. The TLV converter application allows the operator to configure the Cisco MGC to convert binary records from the CDR billing files to ASCII automatically. Each file resides in the /opt/CiscoMGC/var/spool directory, and has the same prefix as its binary counterpart, but the file extension ".csv" is appended, rather than ".bin".
The converter processes only three types of message tags:
There is no correlation effort done by the TLV converter application, which means that the mediation application has to correlate the lines to generate the complete CDR for a particular call.
The output format of the TLV converter is as follows, with each comma representing a certain field in the CDR:
The output is position-sensitive. If there is no value for a field in the TLV message, that position is blank, as evidenced by two (or more) commas in succession (for example, ...,4104,,4106,....).
|
Note The TLV format is a generic ASCII, comma-delimited (comma-separated values) format. |
|
Note When started, this application cannot be turned off unless you reset the Cisco MGC. If you want to look at raw data, use the cdrView utility (TCL/TK based) and get all of the correlated messages. |
To operate the TLV converter, if the application is located in the default directory /opt/CiscoMGC/bin/converter, complete the following steps:
vi /opt/CiscoMGC/etc/XECfgParm.dat
Step 2 Find the following line in the XECfgParm.dat file:
dmpr.callDetail = /opt/CiscoMGC/bin/converter
If the line is commented out, remove the comment character.
Make sure that the tags 1110 and 1060 are in the MDL message tag list.
Step 3 Find or create the line LongCallTime = in the XECfgParm.dat file.
Step 4 To turn off the TLV Converter, enter the command:
vi /opt/CiscoMGC/etc/XECfgParm.dat
Step 5 Comment out the following line in the XECfgParm.dat file and restart the Cisco MGC:
dmpr.callDetail = /opt/CiscoMGC/bin/converter
This section describes maintenance procedures that should be performed regularly to keep Cisco MGC operations running smoothly. These maintenance procedures include
|
Note This section does not include information on maintaining the Sun host server hardware. You should routinely perform general maintenance tasks and diagnostic checks on the host hardware. See the documentation provided by Sun Microsystems, the hardware manufacturer, for detailed information on these types of procedures. |
The Cisco MGC software includes a disk monitor program that periodically checks the amount of disk space used within the configurable set of disk partitions. This ensures that there is sufficient disk space available in each disk partition for the system to continue to operate at peak performance.
If any disk partition exceeds the configurable usage threshold, the Cisco MGC generates a DISK alarm (a major alarm), a warning of a disk partition overrun, and a warning of insufficient disk space. See the Cisco Media Gateway Controller Software Release 7 Reference Guide for information about alarms.
The disk monitor program deletes (trims) the older log files in the /opt/CiscoMGC/var/log and /opt/CiscoMGC/var/spool directories until the disk space usage is within the designated threshold.
The disk monitor is installed with default values for the usage threshold; however, you can configure the disk monitor program to match your site-specific requirements. To configure the program, refer to the XECfgParms.dat section of the Cisco Media Gateway Controller Software Release 7 Installation and Configuration Guide.
You may have to periodically delete configuration and call trace files. The configuration library stores the various configurations that have been created for your Cisco MGC. To ensure proper functioning of your Cisco MGC, you should not store any more than 64 configurations in your library. For more information about deleting configuration files, refer to the "File Options Viewer" section.
Call trace files are created when you perform call traces as part of troubleshooting a problem. These files can be rather large, and leaving them on your disk could cause problems. For more information about deleting call trace files, refer to the "Deleting Call Trace Files" section.
In addition, you should periodically back up the full system to capture information about the setup and configuration of the Cisco MGC. If a catastrophic failure occurs, it is much easier to restore system information from backup data than to recreate it. Furthermore, such a failure could cause critical configuration information to be lost if it has not been backed up.
The following sections provide the backup procedures:
|
Note Always perform backup operations from the active Cisco MGC. |
Use this procedure to store the results of a full backup operation (everything under the base directory) to a tape inserted in the local tape drive. To do this, complete the following steps:
console login: root Password: Mar 17 10:21:34 va-blade login: ROOT LOGIN /dev/console Last login: Thu Mar 16 10:16:34 on console Sun Microsystems Inc. SunOS 5.6 Generic August 1997 # cd /opt/CiscoMGC/local
Step 2 Run the backup.sh script:
# ./backup.sh
MGC backup utility
-----------------------------
Destination currently set to Local tape (/dev/rmt/0h)
Enter:
<N> set destination to remote NFS server
<L> set destination to Local tape (/dev/rmt/0h)
<F> for Full (everything you have)
<P> for Partial (changable part of the system)
<Q> to quit
Select backup mode:
Step 3 Select F to start the full backup.
Select backup mode: F a ./ 0 tape blocks a ./var/ 0 tape blocks a ./var/log/ 0 tape blocks a ./var/log/platform.log 1 tape blocks a ./var/log/mml.log 1 tape blocks a ./var/spool/ 0 tape blocks a ./var/trace/ 0 tape blocks a ./var/audit_cron.log 1 tape blocks . . .#
Step 4 When the backup operation has finished, remove the tape, engage the write-protect tab, and label the tape "Full MGC Backup." Specify the machine name and the time and date.
Use this procedure to store a partial backup operation (the contents of the etc, local, var, and dialPlan subdirectories under the MGC base directory) to a tape inserted in a local tape drive. To do this, complete the following steps:
va-blade console login: root Password: Mar 17 10:21:34 va-blade login: ROOT LOGIN /dev/console Last login: Thu Mar 16 10:16:34 on console Sun Microsystems Inc. SunOS 5.6 Generic August 1997 # cd /opt/CiscoMGC/local
Step 2 Run the backup.sh script:
# ./backup.sh
MGC backup utility
-----------------------------
Destination currently set to Local tape (/dev/rmt/0h)
Enter:
<N> set destination to remote NFS server
<L> set destination to Local tape (/dev/rmt/0h)
<F> for Full (everything you have)
<P> for Partial (changable part of the system)
<Q> to quit
Select backup mode:
Step 3 Select P to start the partial backup.
Select backup mode: P a ./ 0 tape blocks a ./var/ 0 tape blocks a ./var/log/ 0 tape blocks a ./var/log/platform.log 1 tape blocks a ./var/log/mml.log 1 tape blocks a ./var/spool/ 0 tape blocks a ./var/trace/ 0 tape blocks a ./var/audit_cron.log 1 tape blocks . . . #
Step 4 When the backup operation has finished, remove the tape, engage the write-protect tab, and label the tape "Partial MGC Backup." Specify the machine name and the time and date.
Use this procedure to store a full backup operation (everything under the MGC software base directory) to an NFS mountable directory on a remote machine. The remote machine must be set up with an NFS mountable directory that can be written to by the machine being backed up. The NFS setup of the remote machine is beyond the scope of this procedure.
To back up the entire Cisco MGC software directory to a remote machine, complete the following steps:
va-blade console login: root Password: Mar 17 10:21:34 va-blade login: ROOT LOGIN /dev/console Last login: Thu Mar 16 10:16:34 on console Sun Microsystems Inc. SunOS 5.6 Generic August 1997 # cd /opt/CiscoMGC/local
Step 2 Run the backup.sh script:
# ./backup.sh
MGC backup utility
-----------------------------
Destination currently set to Local tape (/dev/rmt/0h)
Enter:
<N> set destination to remote NFS server
<L> set destination to Local tape (/dev/rmt/0h)
<F> for Full (everything you have)
<P> for Partial (changable part of the system)
<Q> to quit
Select backup mode:
Step 3 Select N to define the remote NFS server.
Step 4 Enter the name of the remote NFS server.
Enter server name: remote hostname
Step 5 Enter the directory name on the remote NFS server.
Enter remote directory : remote directory name
Step 6 Select F to start the full backup:
Select backup mode: F a ./ 0 tape blocks a ./var/ 0 tape blocks a ./var/log/ 0 tape blocks . . . backup to va-panthers:/backup/va-blade20000317105337.tar complete #
The filename on the remote NFS server is the host name of the machine with the date in YYYYMMDDHHMMSS format and ".tar" appended.
Use this procedure to store a partial backup operation (the contents of the etc, local, var, and dialPlan subdirectories under the MGC base directory) to an NFS mountable directory on a remote machine. The remote machine must be set up with an NFS mountable directory that can be written to by the machine being backed up. The NFS setup of the remote machine is beyond the scope of this procedure.
To back up a portion of the Cisco MGC software directory to a remote machine, complete the following steps:
va-blade console login: root Password: Mar 17 10:21:34 va-blade login: ROOT LOGIN /dev/console Last login: Thu Mar 16 10:16:34 on console Sun Microsystems Inc. SunOS 5.6 Generic August 1997 # cd /opt/CiscoMGC/local
Step 2 Run the backup.sh script:
# ./backup.sh
MGC backup utility
-----------------------------
Destination currently set to Local tape (/dev/rmt/0h)
Enter:
<N> set destination to remote NFS server
<L> set destination to Local tape (/dev/rmt/0h)
<F> for Full (everything you have)
<P> for Partial (changable part of the system)
<Q> to quit
Select backup mode:
Step 3 Select N to define the remote NFS server.
Step 4 Enter the name of the remote NFS server.
Enter server name: remote hostname
Step 5 Enter the directory name on the remote NFS server.
Enter remote directory : remote directory name
Step 6 Select P to start the partial backup:
Select backup mode: P a ./ 0 tape blocks a ./var/ 0 tape blocks a ./var/log/ 0 tape blocks . . . backup to va-panthers:/backup/va-blade20000317105337P.tar complete #
The filename on the remote NFS server is the host name of the machine with the date in YYYYMMDDHHMMSS format and "P.tar" appended.
Posted: Tue Sep 12 11:40:34 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.