
14
Chapter 1 Overview
1.9.6 Alarm Log
The Signaling Server is able to detect a number of events or alarm conditions relating to either the hardware
or the operation of the protocols. Each alarm condition is assigned a severity/class (3 = Critical, 4 = Major,
5 = Minor) and a category and ID, which give more detail about the alarm. There are a number of
mechanisms described below, by which these conditions can be communicated to management systems, and
ultimately to the system operator (see Chapter 8, “Alarm Fault Code Listing” for a full list of alarm types, and
their reporting parameters):
• Active alarms are indicated on the front panel of the Signaling Server, (except SS7G31), with three LEDs
identifying severity; CRT, MJR, MNR.
• Active alarms may be indicated remotely from the Signaling Server, (except SS7G31), when the alarm
relay outputs are connected to a remote management system.
• Alarm events, configuration changes and system status may be reported to an SNMP manager(s). Refer
to Chapter 10, “Signaling Server SNMP”.
• A system operator can obtain a listing of the current alarm status (ID, class, fault title, occurrence time
and title) using the ALLIP management terminal command described in Section 6.4.4, “ALLIP” on
page 51.
• A system operator can access a log of the current and previous alarms using the ALLOP management
terminal command described in Section 6.4.5, “ALLOP” on page 52. The Alarm Log has the capacity for
up to 200 entries, each entry detailing the ID, title, alarm class, fault title, occurrence time, status
(active or cleared), and cleared time (if appropriate). If a new fault occurs when the log is full, the oldest
entry that is either cleared, of lower class, or equal class is overwritten, in that order of preference. The
operator may request a display of the log at any time and may remove entries that have cleared status.
• The alarm log may also be reported to a Remote Data Center (RDC). See Section 9, “Remote Data
Center Operation” on page 153 for the configuration and operation of an RDC and for the format of the
alarm log records.
1.9.7 Diagnostic Log Files
Upon restart, the Signaling Server generates a number of diagnostic files. These files may aid the support
channel in the analysis of severe errors, such as an unexpected system restart or particular alarms. The text
files, restart_gct.log, restart_top.log, restart_sensor.log, restart_ip.log and restart_disk.log can be
recovered from the syslog directory using FTP protocol as described below.
ftp 123.123.123.123
user siuftp
password siuftp (or the ftppwd as set by the CNSYS command)
cd syslog
ascii
get restart_gct.log
get restart_top.log
get restart_sensor.log
get restart_ip.log
get restart_disk.log
bye
1.9.8 M3UA Backhaul Operation
The Signaling Gateway can use the SIGTRAN protocol M3UA to “backhaul” SS7 information to an IP resident
Remote Application Server (RAS) operating on one or more Application Server Processes (ASPs). Examples
of Application Servers are Media Gateway Controllers or IP resident databases. In both cases, the Application
Server can operate as a Signaling End Point (SEP), where SS7 User Part Protocols, such as SCCP or ISUP,
operate above a M3UA layer on the host.
Kommentare zu diesen Handbüchern