Contents

1   Alarm Description

This generic C-Diameter threshold based alarm indicates disturbances in egress request message delivery. That is, the message amount dropped due to time-out crossed the threshold defined by the related threshold job.

Note:  

C-Diameter does not deliver Threshold Job for its measurement types. It is up to the C-Diameter Applications to define and document these. Make sure, that the related application documentation is available.

Messages dropped by the diameter stack due to the increased Round Trip Time (RTT) can cause disturbances in diameter application level session handling as no answer messages are received or messages are received too late, for the sent egress request messages.

The alarm can be caused by various circumstances. Some of the most common ones are the following:

Erronous Routing Configuration	The routing table represented by the collection of OtpdiaSelector, OtpdiaCons and OtpdiaDomaincontains Managed Objects, contains erroneous or no routing entries. As result egress request messages are sent towards invalid destinations never reaching the valid destination node.
Configuration of requestTimeout	The requestTimeout attribute value of a service represented by OtpdiaService is set to a low value.
Network failure	Egress request messages are dropped by the network due to congestion or other reasons.

For more information about the above C-Diameter Managed Objects, refer to Otpdia Managed Object Model

The alarm was raised because at the end of the granularity period (GP) the measured value for one of the DiameterCC measurement types was higher than the configured threshold. The following C-Diameter measurement type is associated with this alarm:

• Diameter.EgressReqMsgDiscarded.TimeOut

In the subsequent GP the threshold based alarm is cleared automatically in the following cases:

• The observed measurement value is lower than the Low threshold of the smallest non-empty severity.
• No measurement result is available during the granularity period, that is, the time between the initiations of two successive gatherings of measurement data.

The alarm can also be cleared if the related Threshold Reader or its Threshold Monitor is deleted or disabled.

For more information about DiameterCC measurement types and their properties, see DiameterCC Measurements.

For more details on Performance Management alarms in CBA environment, see Reference [1].

2   Procedure

2.1   Handle Alarm C-Diameter, RTT to Remote Node Exceed Limits

Prerequisites

• This instruction references the following document:
  • C-Diameter Trouble Report and Support Case Writing Guideline
  • Otpdia Managed Object Model
  • C-Diameter, Configuration Incomplete
  • C-Diameter, Configuration Ambiguous
  • C-Diameter Application documentation related to the configured Threshold Job and to node dimensioning
• No tools are required.
• The following conditions must apply:
  • The alarm is raised.
  • Diameter configuration data are correctly defined.
  • Diameter Performance Management and Fault Management instance models are deployed.
  • An Ericsson Command-Line Interface (ECLI) session in exec mode is in progress.

Steps

1. Based on the information found in the alarm's fields, identify the C-Diameter Application which issued the alarm.

   Check the related PmJob and its MeasurementReader in the source attribute of the alarm, for example:

   >show all ManagedElement=1,SystemFunctions=1,Fm=1,FmAlarm=16 FmAlarm=16,source
   source="ManagedElement=1,SystemFunctions=1,Pm=1,PmJob=ApplicationThresholdJob,MeasurementReader=1:DiaNode=machine.source.server.realm.com,DiaPeer=machine.source.client.realm.com"

   Where PmJob identifies the threshold job of the C-Diameter Application.

   Observe the DiaNode and DiaPeer identifications after the MeasurementReader. The first show the AAA service implementation represented by OtpdiaService, the latter its related peer represented either by OtpdiaHost (static peer) or by OtpdiaDynamicHostAcceptor (dynamic peer) Managed Object (MO).

2. Locate the C-Diameter Application's documentation describing the appropriate measures for the situation.
3. Is there a specific Application OPI found?

   Yes: Follow the instructions mentioned in that document to clear the alarm. After performing the procedure defined by the C-Diameter Application for the above measurement, proceed with Step 26.

   No: Continue with the next step.

4. Navigate to the PmJob Managed Object (MO) indicated by alarm source attribute in Step 1, for example:

   >ManagedElement=1,SystemFunctions=1,Pm=1,PmJob=ApplicationThresholdJob

5. Check the value of attribute granularityPeriod:

   (PmJob=ApplicationThresholdJob)>show granularityPeriod

   The following is an example output:

   granularityPeriod=FIVE_MIN

6. Wait up to the time of the granularity period for the alarm to be cleared automatically.
7. Is the alarm cleared?

   Yes: The measurement peak was most probably caused by transient events. No manual intervention is required, proceed with Step 26.

   No: Continue with the next step.

8. In case no related application documentation is found and the alarm is not ceased automatically during the next granularity period, check the routing configuration.

   Note:  

   If there are other C-Diameter alarms that are related to configuration, for example C-Diameter, Configuration Incompleteor C-Diameter, Configuration Ambiguous solve them first. They can help to identify the incorrect configuration objects.

   
   

   Verify, that the routing configuration is valid and consistent. Navigate to the routing entries of the OtpdiaService identified in Step 1. Routing entries are represented by OtpdiaSelector instances and referred collection of OtpdiaCons and OtpdiaDomain instances.

   For detailed information, see chapter "Routing Specification" in Otpdia Managed Object Model.

   For example:

   >dn ManagedElement=1,XyzFunction=xyz

   Where XyzFunction=xyz depends on the value of DIACC_CMWAL_MOM_BASE_DN documented by the C-Diameter user application.

   (XyzFunction=xyz)>show OtpdiaProduct=CDiaApp,OtpdiaSelector=myRoutingEntry1

   (XyzFunction=xyz)>show OtpdiaProduct=CDiaApp,OtpdiaCons=myPeers1

   (XyzFunction=xyz)>show OtpdiaProduct=CDiaApp,OtpdiaDomain=myRealm1

   Check that the relations between the MOs are correctly defined and the configured DNs are valid. COM CLI helps to set these references and also checks their validity.

9. Contact the network administrator and check that the configured hosts and realms are all correct.
10. In case of any configuration change, wait up to the time of the granularity period for the alarm to be cleared.
11. Is the alarm cleared?

    Yes: Either the routing configuration has been corrected, or the alarm was of a transient nature. Proceed with Step 26.

    No: Continue with the next step.

12. Attribute requestTimeout is used by the stack to guard the egress request message deliveries.

    Navigate to the OtpdiaService instance identified in Step 1 and check the configured requestTimeout and increase it's value.

    >dn ManagedElement=1,XyzFunction=xyz,OtpdiaProduct=CDiaApp,OtpdiaService=MyService

    (OtpdiaService=MyService)>show -v

    (OtpdiaService=MyService)>configure

    (config-OtpdiaService=MyService)>requestTimeout=<myNewTimeout>

    (config-OtpdiaService=MyService)>commit

13. Wait up to the time of the granularity period for the alarm to be cleared.
14. Is the alarm cleared?

    Yes: The message delivery on this peer connection was probably slower then the configured timeout, or the alarm was of a transient nature. Proceed with Step 26.

    No: Continue with the next step.

15. The cause of the message timeouts is probably a network failure or some dimensioning fault.

    Contact the network administrator and check the network configurations. Verify the connection between the Own node and the Peer identified in Step 1. Verify that the network is properly dimensioned for the amount of traffic.

    Consult the application documentation about node dimensioning.

16. In case of any change on network level, wait up to the time of the granularity period for the alarm to be cleared.
17. Is the alarm cleared?

    Yes: The cause of the timeouts was probably the network, or the alarm was of a transient nature. Proceed with Step 26.

    No: Continue with the next step.

18. Check the configured threshold job.

    Navigate to the appropriate PmThresholdMonitoring MO, for example:

    (PmJob=ApplicationThresholdJob)>MeasurementReader=1,PmThresholdMonitoring=1

19. Check the values of attributes thresholdHigh and thresholdLow:

    (PmThresholdMonitoring=1)>show

    The following is an example output:

    PmThresholdMonitoring=1 pmThresholdMonitoringId="1" thresholdHigh=1 thresholdLow=0 thresholdSeverity=MINOR

20. Consult the application documentation about the configured threshold job. Are the attributes thresholdHigh and thresholdLow set to correct values?

    Yes: Proceed with Step 22.

    No: Continue with the next step.

21. Set appropriate values for attributes thresholdHigh and thresholdLow, for example:

    (PmThresholdMonitoring=1)>config

    (config-PmThresholdMonitoring=1)>thresholdHigh=20

    (config-PmThresholdMonitoring=1)>thresholdLow=15

    (config-PmThresholdMonitoring=1)>commit

22. Wait for the alarm to be cleared automatically after elapsing of two granularity periods.
23. Is the alarm cleared?

    Yes: Proceed with Step 26.

    No: Continue with the next step.

24. Perform data collection, refer to C-Diameter Trouble Report and Support Case Writing Guideline.
25. Consult the next level of maintenance support. Further actions are outside the scope of this instruction.
26. Job is completed.

Reference List

Documents
[1] Core MW Performance Management Description, 1/155 16-CAA 901 2624/1