PGW 2200 Full Reconfiguration in Live Networks

Document ID: 46160

PDF Downloads

Related Discussion

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Reconfiguring the PGW 2200
      Limitations and Warnings
      Step-by-Step Instructions
Verify
Troubleshoot
Cisco Support Community - Featured Conversations
Related Information

Introduction

This document describes an operative procedure to be used, under Cisco Technical Support control, when there are serious inconsistencies in the configuration of a Cisco PGW 2200 and there is the need to reconfigure the server from scratch and minimize the downtime during the process.

Prerequisites

Requirements

Before attempting this configuration, please ensure that you meet the following prerequisites:

The decision to use this procedure and the follow up to this procedure should only be completed under Cisco Technical Support supervision.
The customer needs to be familiar with the PGW 2200 installation and configuration for either release 7 or release 9.
The customer needs to be familiar with provisioning the PGW 2200 from a new configuration located in the Release Notes for the Cisco Media Gateway Controller Software Release 9.3(2).
Ensure that console access is available for the customer and the Technical Support to the secondary PGW 2200.

Components Used

The information in this document is based on the software and hardware versions:

PGW 2200 Software versions 7.4(11), 7.4(12), 9.2(2), and 9.3(2)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Reconfiguring the PGW 2200

The purpose behind this reconfiguration procedure is to rebuild a complete and fresh configuration on the PGW 2200 server normally used as a STANDBY server while it is isolated from the network, then reconnect it back to the network, and switch the traffic to it. The PGW 2200 that was previously active is then restarted with the new refreshed configuration.

It is assumed that:

One PGW 2200 is called PGW A and other is called PGW B.
When the procedure starts, the PGW A is in an active state.
The configuration is performed on the PGW B console directly or via a terminal server.
The customer is a UNIX user called "mgcusr" (unless otherwise specified).
The customer has previously transferred to Man-Machine Language (MML) batch files of the current PGW A configuration to the PGW B. These files were created using the mml command prov-exp:all:dirname="config-for-refresh".

For further information, refer to Exporting Configuration Data.

These file were transferred from PGW A to the same directory in PGW B.

Limitations and Warnings

During the reconfiguration, the PGW 2200 server normally used as a standby is not available to take over the current active PGW 2200 if it fails.
When the traffic is switched to a PGW 2200 with the refreshed configuration, there is a possibility that the calls will fail. The outage is significantly shorter than one that a full reconfiguration of both PGW 2200s cause.
The MML batch files for the configuration being refreshed needs to be the same as the one used for the current configuration.

Step-by-Step Instructions

This procedure demonstrates how to allow the PGW to rebuild a configuration database (.dat files) starting from an empty configuration to clean up any type of "corruption" that may happen.

caution Caution: The detection of the configuration database "corruption" and the decision to to use this procedure should be under Cisco Technical Support supervision.

Isolate the PGW B from the network.

Disconnect the Ethernet interfaces. Do not use the UNIX command ifconfig <int> down even if there are annoying messages on the console. Ensure that the MML batch file for reconfiguration is already transferred to the PGW B before isolating it.
Stop the PGW B (you need root privilege).
```
pgwb#/etc/init.d/CiscoMGC stop
```
Scratch the PGW B configuration (only) to a new (empty) configuration (for example, copy the configuration file from the new entry in configuration library).
1. In the PGW B, save a backup copy of XECfgParm.dat.
```
pgwb#cp /opt/CiscoMGC/etc/XECfgParm.dat 
/opt/CiscoMGC/etc/XECfgParm.dat.backup
```
2. In the PGW B, copy the new (empty) configuration .dat files into the current PGW configuration.
```
pgwb# cp /opt/CiscoMGC/etc/CONFIG_LIB/new/*.dat 
/opt/CiscoMGC/etc
```
3. In the PGW B, remove the pointer to the previous active configuration.
```
pgwb# rm /opt/CiscoMGC/etc/active_link 
pgwb# rm /opt/CiscoMGC/etc/prov_link 
```
4. In the PGW B, restore the saved XECfgParm.dat file.
```
pgwb#cp /opt/CiscoMGC/etc/XECfgParm.dat.backup 
/opt/CiscoMGC/etc/XECfgParm.dat
```
5. In the PGW B, edit the file /opt/CiscoMGC/etc/XECfgParm.dat and set the parameter pom.dataSync to false.
Reconnect the PGW B to the Ethernet interface and restart the application (from root user).
```
pgwb#/etc/init.d/CiscoMGC start
```
Because the pom.datasync is set to false, it does not copy the configuration from the active PGW A.
Reconfigure the PGW B with the saved MML batch files previously transferred.
```
pgwb# cd /opt/CiscoMGC/etc/custom_specific/config-for-refresh
pgwb# mml -b <config-file>


!--- Repeat for each configuration file.
```
Keep in mind that the dial plan MML batches should be entered in order from leaf batches to main batches.

Refer to PGW Configuration Guide with MML for further information. Do not forget to uninhibit all the links that are in the INB state after being configured.
Check that the PGW-B is standby (pgwb.mml> rtrv-ne) and that it has the call synched to the PGW A.
```
pgwb# echo rtrv-tc:all | mml | egrep '(IN|OUT)'

!--- For release 7.4(11).

pgwb# echo rtrv-ne-health | mml


!--- For release 9.x.
```
In the PGW B, the status of the C7 link and the RLM links is Out Of Service, Standby (OOS,STBY). In the PGW B, the status of the destination is In Service (IS). If these checks state that the PGW B is not OK, do not proceed until you fix any issue on the PGW B.
In the PGW A, edit the file /opt/CiscoMGC/etc/XECfgParm.dat file and set the parameter pom.dataSync to false (this is a precaution).
Switch to the PGW B.

Note: This is the critical point of the procedure and needs to be performed outside peak hours, when the impact of losing calls is minimal.

First try a proper switch-over from the PGW A to the PGW B using the pgwa.mml>sw-over::confirm command.

The switch-over may fail with a "Warm start" error message. If so, and if the check described in step 6 indicates that the PGW B is OK, you can force the switch-over stopping the PGW A (from the root user ).
```
pgwA#/etc/init.d/CiscoMGC stop
```
Check that the PGW B is active, that the links are active, and that it is receiving the new calls.

At this point, if the PGW B fails to handle the traffic, the backup plan is to stop it and restart the PGW A that still keeps the old configuration due to omdatasync=false.
If the PGW B is correctly handling all the traffic, in the PGW A, edit the file /opt/CiscoMGC/etc/XECfgParm.dat file and set the parameter pom.dataSync to true.
Restart the PGW A (from root) so that it copies the configuration from the PGW B.
```
pgwA#/etc/init.d/CiscoMGC start
```
Check that the PGW A is in standby (see step 6 above).
In the PGW B, edit the file /opt/CiscoMGC/etc/XECfgParm.dat and set the parameter pom.dataSync to true.
(Optional) Finish with a soft switch-over from the PGW B to PGW A to have the PGW A being the active PGW again as before.

Once the procedure is finished, both the PGWs have the same refreshed configuration.

Cisco PGW 2200 Softswitch