Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-1941983.1
Update Date:2017-06-29
Keywords:

Solution Type  Problem Resolution Sure

Solution  1941983.1 :   Call Failures for a Few Minutes  


Related Items
  • Oracle Communications EAGLE (Software)
  •  
Related Categories
  • PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec Eagle 5
  •  




In this Document
Symptoms
Changes
Cause
Solution


Created from <SR 3-9771403261>

Applies to:

Oracle Communications EAGLE (Software) - Version EAGLE 41.x and later
Information in this document applies to any platform.

Symptoms

There were call failures seen. They took a few minutes.

Changes

 

Cause

2 platforms went down and led to some congestions and discards on the site.
There was an important increase of network management messages leading to an excess of the SCCP capacity :

CARD XXXX IPLIMI REPT-NMTSK-DSCD: SNM Discard Onset
System SCCP TPS Threshold exceeded
GFLEX SERVICE           Service abnormal
GPORT SERVICE          Service abnormal

The excess of traffic for the SCCP cards and the excess of traffic for some linksets (IPTPS very high) indicate a peak of traffic :

LSN xxxxx     Linkset IP TPS threshold exceeded

Many alarms indicating MSU discards :

8357.0272

SLK

xxxx,B

REPT-LINK-CGST:

discard

level

2

to

3

Maybe should you reconsider the way the network messages are broadcasted ? Check the configuration of some linksets depending on the destination : the “BEI” parameter can be set to “yes” to inhibit the network management messages broadcast, knowing that the response method will still be working.

You can also reconsider the dimension of some Sigtran links in case of such events so that they are able to support a peak load of traffic.

For the SCCP cards, you could add additional cards

Solution

Recommendations for future during this type of issue (in addition of the commands you have captured for this issue) :
If possible capture during the issue :
1. several rept-stat-sccp
2. rept-stat-rte:dpcn=<faulty destination>
3. rept-stat-iptps:lsn=<linkset having the issue>
4. rept-imt-lvl1:r=summary:sloc=1201:eloc=1115
5. aud-data:type=ddb:display=all
For the rtrv-log command, no need to indicate slog=act and type=alarm, as these parameters are the default ones
At the end of the issue, capture
  - rtrv-log:type=uim:sdate=<day of the issue>:stime=<10 min before the issue>:etime=<stime+20 min>
  - rtrv-log:sdate=<day of the issue>:stime=<10 min before the issue>:etime=<end of the issue>
  - rtrv-trbl:loc=<active MASP>
  - rtrv-obit:loc=<active MASP>

Also, some configuration information about congestion :

For the congestion and discard levels, Eagle is compliant to the ITU and ANSI recommendations. Please refer to the recommendations for more details.
Fyi, the ITU does not handle the level 1 and 2 for the MSU discard, it means the discard only occurs when the max level of discard is reached.
The principle is that when the system exceeds the maximum congestion level, then the discard mode is started.
The way the congestion is detected is not described in the recommendations and is a proprietary information.

Please read also the Eagle documentation located in Oracle's Online Documentation for Tekelec Products: Database Administration -> SS7
In the SS7 part of the Eagle documentation, you can also consider the TFC option for ITU network:

Configuring the Options for Handling TFCs on ITU-I and ITU-N Networks

This procedure is used to configure the options for handling TFCs on ITU-I and ITU-N networks using the chg-ss7opts command with these two parameters:
:discardtfci – This parameter specifies that the EAGLE 5 ISS discards TFC traffic received from an ITU-I network (discardtfci=on), or does not discard TFC traffic received from an ITU-I network
(discardtfci=off). The system default value for this parameter is off.
:discardtfcn – This parameter specifies that the EAGLE 5 ISS discards TFC traffic received from an ITU-N network (discardtfcn=on), or does not discard TFC traffic received from an ITU-N
network (discardtfcn=off). The system default value for this parameter is off

Also in the commands manual :

- chg-sg-opts : ipgwabate (optional)
Enable or disable IPGWx SS7 congestion abatement procedures. This parameter specifies whether the TFC is forwarded to the system’s true point code, to allow MSUs to be
discarded as part of abatement procedures on all cards running the IPGWx application. When set to yes, the system will maintain and abate congestion on behalf of IPGWx-connected nodes.

- chg-ss7opts : discardtfci (optional)

This parameter enables and disables the handling of TFC traffic from ITU-I networks. If enabled, TFC traffic from ITU-I networks will be discarded.
discardtfcn (optional) : This parameter enables and disables the handling of TFC traffic from ITU-N networks. If enabled, TFC traffic from ITU-N networks will be discarded.

- chg-stpopts :

mtpt31ctl (optional) : MTP T31 congestion trigger level. The signaling link congestion level at which the system starts the level 3 t31 timer. When the level 3 t31 timer expires, the associated signaling link is removed from service for realignment.

tfatfrpr : TFA/TFR pacing rate. The amount of time, in milliseconds, between partial broadcasts of up to 20 percent increments of the number of TFAs/TCAs or TFRs/TCRs to be broadcast by the STP when an affected destination becomes accessible using its primary route rather than an alternate route. The STP uses this pacing to prevent congestion on the newly recovered linksets.

- chg-uaps

 


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback