Document ID: 47361
This document describes how to change the Cisco PGW 2200 alarm severities for signaling links to avoid inappropriate failovers. The document applies more specifically to Service Provider networks using the Cisco PGW 2200 Media Gateway Controller (MGC) with signaling links of mixed types.
Note: Signaling link types include ANSI/ITU Signaling System 7 (SS7), Sigtran MTP3 User Agent (M3UA), Sigtran SSCP User Agent (SUA), and Cisco PRI backhaul.
Readers of this document should have knowledge of these topics:
A UNIX operating system text editor
The information in this document is based on these software and hardware versions:
Cisco MGC Release 7
Cisco MGC Release 9
Note: This document has been written for Cisco MGC Release 9.4(1).
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.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
In the early implementations of the Cisco PGW 2200, the signaling link type used was almost exclusively SS7. When the PGW 2200 received an alarm that all the SS7 links were lost, and because the PGW 2200 was likely isolated from the signaling network, the designed behavior was to switch over to the standby PGW 2200 to try to recover the link to the signaling network.
The current PGW 2200 versions support a signaling link of multiple types concurrently. For backward compatibility, the behavior above has been retained. Therefore, the PGW 2200 attempts to switchover (among the other reasons) when any of these Critical Alarms are raised.
The following numbers are the alarm order numbers in the alarm file:
"All C7 IP Links Fail" - (239)
"All M3UA Assoc Fail" - (384)
"All SUA Assoc Fail" - (385)
Note: The failure of all PRI backhaul links does not trigger a PGW 2200 failover.
This behavior may be problematic in the following cases:
When there are mixed type signaling links, with most of the links being of one type and one or few links being of another type. The instability of the last type of link(s) may trigger the switchover.
When a customer is performing an initial installation and the link are not yet stable.
When the signaling links are brought into maintenance at the same time.
The solution to this problem is explained in detail in this procedure. The intent is to change the Alarm severity for the three types of alarms above from the value 3 - Critical (that trigger the switchover) to the value 2 - Major.
Login to the Standby PGW with the UNIX userID mgcusr.
With a UNIX editor like vi, open this file.
Note: Perform a backup copy of the file before opening and do not use PC editors.
cp /opt/CiscoMGC/etc/alarmCats.dat /opt/CiscoMGC/etc/alarmCats-backup.dat vi /opt/CiscoMGC/etc/alarmCats.dat
Change the third field value in the following line from 3 to 2
This is how they appear before the change.
Note: Please note that the lines have been wrapped in order to fit in the document.
239 "All C7 IP Links Fail" 3 Y "All Links transporting MPT3 messages to the Signal Terminal failed" "C7 IP Links Fail" 1 384 "All M3UA Assoc Fail" 3 Y "All M3UA Associations transporting SS7 signaling failed" "All M3UA Associations transporting SS7 signaling failed" 1 385 "All SUA Assoc Fail" 3 Y "All SUA Associations transporting SS7 signaling failed" "All SUA Associations transporting SS7 signaling failed" 1
This is how they appear after the change:
239 "All C7 IP Links Fail" 2 Y "All Links transporting MPT3 messages to the Signal Terminal failed" "C7 IP Links Fail" 1 384 "All M3UA Assoc Fail" 2 Y "All M3UA Associations transporting SS7 signaling failed" "All M3UA Associations transporting SS7 signaling failed" 1 385 "All SUA Assoc Fail" 2 Y "All SUA Associations transporting SS7 signaling failed" "All SUA Associations transporting SS7 signaling failed" 1
Here you can check that there was not an error in the file editing. For example, by comparing the backup version of the alarmCats.dat file with the current one using the UNIX diff command diff /opt/CiscoMGC/etc/alarmCats.dat /opt/CiscoMGC/etc/alarmCats-backup.dat.
Copy the modified files on the active and the provisioning directories:
cp /opt/CiscoMGC/etc/alarmCats.dat /opt/CiscoMGC/etc/active_link cp /opt/CiscoMGC/etc/alarmCats.dat /opt/CiscoMGC/etc/prov_link
Repeat steps 1 through 4 on the Active PGW.
Perform a double PGW switchover on both PGW 2200s to have the new alarm configuration file reread.
After the first switchover, check that the previously Active PGW goes back into Standby mode after a couple of minutes. If it is OK, perform the second switchover. If it is not OK, check the Out Of Service (OOS) PGW software status and alarms.
mml> rtrv-softw:all mml> rtrv-alms
You can also check that the file was edited correctly in step 3 above.
Check that PGW 2200 is correctly handling calls.
In Cisco PGW 9.4(1) System Patch 19 or later, the default behavior is changed to not generate these alarms and therefore not induce a failover.
239 "All C7 IP Links Fail" 384 "All M3UA Assoc Fail" 385 "All SUA Assoc Fail"
If a customer wants the original behavior, a new flag is introduced and must be manually added to XEcfgparm:
*.AllLinksFailCausesFailover = true
- Cisco Media Gateway Controller Software
- Cisco PGW 2200 Softswitch
- Voice Technology Support
- Voice and Unified Communications Product Support
- Troubleshooting Cisco IP Telephony
- Technical Support & Documentation - Cisco Systems
|Updated: Feb 02, 2006||Document ID: 47361|