SAF, LOTC Disk Replication Communication Failed

Ericsson Centralized User Database

1 Introduction

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

1.1 Alarm Description

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

This alarm is issued when one of the System Controllers (SCs) is down for more than 20 minutes.

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
An SC blade is being replaced.⁽¹⁾	If the SC blade is down for more than 20 minutes during the blade replacement procedure, then the alarm will be raised, because the disk replication cannot be done.	SC blade replacement	Replaced SC blade	Loss of redundancy in the SC blades.
An SC Virtual Machine (VM) is being recovered.⁽²⁾	If the SC VM is down for more than 20 minutes during the VM recovery procedure, then the alarm will be raised, because the disk replication cannot be done.	SC VM recovery	Recovered SC VM	Loss of redundancy in the SC VMs.
One SC is down for more than 20 minutes.	When the peer SC is down the disk replication can not be done. After 20 minutes of non-synchronization, the alarm is raised.	SC down	SC	Loss of redundancy in the SCs.

(1) For CUDB systems deployed on native BSP 8100.

(2) For CUDB systems deployed on 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	`7`
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.7.<length>.<NOI>`
Alarm Model Description	`LOTC disk replication communication, SAF`
Alarm Active Description	`SAF platform: LOTC disk replication communication @<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].

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

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

Not applicable.

Not applicable.

If the alarm is raised, do the following:

If the SC blade has been replaced (for CUDB systems deployed on native BSP 8100) or the SC VM has been recovered (for CUDB systems deployed on a cloud infrastructure), then wait for the replication to be done. The alarm must cease automatically after 5 hours.
If the alarm does not cease 5 hours after the blade replacement or VM recovery, then follow the instructions specified in LOTC Disk Replication Communication, Reference [2].
If the alarm does not cease, consult the next level of maintenance support. Further actions are outside the scope of this Operating Instruction.

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

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