Contents

1   Introduction

This instruction concerns alarm handling for the SAF, LOTC Disk Replication Consistency Failed alarm.

1.1   Alarm Description

This alarm is related to Service Availability Forum (SAF). For details, refer to LOTC Disk Replication Consistency, Reference [2].

This alarm is issued when the System Controllers (SCs) are operating in a non-redundant mode. The SCs have connection to each other, but the data is not consistent.

The possible alarm causes and the corresponding fault reasons, fault locations, and impacts are described in Table 1.

Table 1    Alarm Causes

Alarm Cause	Description	Fault Reason	Fault Location	Impact
The system is being installed.	During a CUDB node installation the second SC loses disk synchronization with the first SC.	No fault. The second installed SC is copying information from first SC.	None.	None.
An SC is being replaced or recovered(1).	After an SC is replaced or recovered, the new SC copies information from the peer SC.	No fault. The replaced or recovered SC is copying information from its peer SC.	None.	None.

(1)  Depending on whether the CUDB system is deployed on native BSP 8100 hardware, or in a cloud infrastructure

The alarm attributes are listed and explained in Table 2.

Table 2    Alarm Attributes

Attribute Name	Attribute Value
Auto Cease	Yes
Module	SAF
Error Code	9
Timestamp First	Date and time when the alarm was raised for the first time.
Repeated Counter	Number which indicates how many times the alarm was raised.
Timestamp Last	Date and time of the most recent alarm raise.
Resource ID	.1.3.6.1.4.1.193.169.9.9.<length>.<NOI>
Alarm Model Description	LOTC disk replication consistency, SAF
Alarm Active Description	SAF platform: LOTC disk replication consistency @<NON>
ITU Alarm Event Type	equipmentAlarm (5)
ITU Alarm Probable Cause	equipmentMalfunction (514)
ITU Alarm Perceived Severity	(3) – Critical
Originating source IP	Node IP where the alarm was raised.
Sequence Number	Number which indicates the order in which the alarms are raised.

In Table 2, the indicated variables are as follows:

• <NON> is the notifying object name that indicates where the component that generates the alarm is. For example:

  safNode=PL_2_3

• <NOI> is the notifying object identifier. It corresponds to NON in a dot-separated, ASCII-decimal-encoded, character-per-character format. For example:

  80.76.95.50.95.51 for safNode=PL_2_3.

• <length> is the number of characters in <NON>, which is equivalent to the number of octets in <NOI>. In the previous example, <length> is 6.

For further information about attribute descriptions, refer to CUDB Node Fault Management Configuration Guide, Reference [1].

1.2   Prerequisites

This section provides information on the documents, tools, and conditions that apply to the procedure.

1.2.1   Documents

Before starting this procedure, ensure that you have read the following documents:

• CUDB Node Fault Management Configuration Guide, Reference [1], regarding alarm configuration.
• System Safety Information, Reference [3]
• Personal Health and Safety Information, Reference [4]

1.2.2   Tools

Not applicable.

1.2.3   Conditions

Not applicable.

2   Procedure

If the alarm is raised, do the following:

1. Follow the instructions specified in LOTC Disk Replication Consistency, Reference [2].
2. If the alarm does not cease, consult the next level of maintenance support. Further actions are outside the scope of this Operating Instruction.

Reference List

CUDB Documents
[1] CUDB Node Fault Management Configuration Guide.

Other Ericsson Documents
[2] LOTC Disk Replication Consistency.
[3] System Safety Information.
[4] Personal Health and Safety Information.