Troubleshooting guide
3-99
Cisco PGW 2200 Softswitch Release 9.8 Operations, Maintenance, and Troubleshooting Guide
OL-0800-14
Chapter 3 Cisco PGW 2200 Softswitch Platform Operations
Regular Operations
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 switchover 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 PGW 2200, the failover daemon initiates a forced switchover to the standby Cisco PGW 2200. The
standby Cisco PGW 2200 transitions immediately to the active state. For approximately 3 seconds, all
messaging is lost. This messaging loss affects established and new calls.
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 switchover on system A is
cleared, its state remains OOS. When the critical event is cleared, the alarm manager sends another
message (a Clear Alarm message) to the foverd process. The foverd process directs system A to a standby
state (if the peer system B is still in the active state).
When the critical event clears, the failed Cisco PGW 2200 Softswitch (A) comes back online. It can then
become the standby for the currently active Cisco PGW 2200 Softswitch (B). Initially, system A is still
OOS. The platform state of system A continues to be OOS until the critical event is cleared.
The Call Engine checkpoints call information from the active Cisco PGW 2200 to the standby
Cisco PGW 2200. In addition, the MTP3 IOCC checkpoints the state of the SS7 network. The MTP2
terminal functionality resides on the Cisco ITP-Ls to enable the fault-tolerant MTP3 solution.
The Cisco ITP-Ls are responsible for SS7 MTP2 message processing. The Cisco ITP-Ls communicate
directly with the Cisco PGW 2200 Softswitches (active and standby) using RUDP, but they send SS7
traffic only to the active Cisco PGW 2200 Softswitch.
Note The number of Cisco ITP-Ls depends on the SS7 network traffic load and on link and linkset
requirements. Generally, you should have a minimum of two links per linkset. One link per Cisco ITP-L
provides SS7 reliability. To further enhance redundancy, you should spread the links in a linkset across
multiple Cisco ITP-Ls so that any single unit can be removed, added, or serviced without disrupting the
SS7 network.
Circuit Auditing
An auditing process discovers discrepancies in circuit states between the Cisco PGW 2200 Softswitch
and the media gateways it controls. During a switchover, discrepancies might exist about the state of
bearer circuits (CICs) between the newly active Cisco PGW 2200 Softswitch and the bearer devices it
controls. Discrepancies in circuit states between the active Cisco PGW 2200 Softswitch and the bearer
devices could also occur if control messages to the bearer devices get lost.
The circuit auditing mechanism can be run periodically at configured intervals or after an automatic or
manual switchover. It can also be initiated manually using the MML command, sw-over::confirm. The
audit capability always initiates automatically upon indication of critical error conditions from solution
components, adjacent SS7 switches, or when critical Cisco PGW 2200 Softswitch conditions occur. The
circuit-auditing mechanism detects and resolves circuit state discrepancies that it discovers and
resynchronizes the Cisco PGW 2200 and the bearer devices.
The circuit auditing mechanism is a function of the call engine process in the active Cisco PGW 2200
Softswitch. 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
PGW 2200 Softswitch. If a bearer device considers the circuit in use and the Cisco PGW 2200 Softswitch
does not, the Cisco PGW 2200 releases the circuit. However, if the Cisco PGW 2200 Softswitch shows