Operating Instructions 25/1543-CSH 109 067/10 Uen C

SAF, LOTC Disk Replication Consistency Failed
Ericsson Centralized User Database

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.

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, 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.

1.2 Prerequisites

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

1.2.1 Documents

This instruction references the following documents:

1.2.2 Tools

Not applicable.

1.2.3 Conditions

Not applicable.

2 Procedure

If the alarm is raised, do the following:

Steps

  1. Follow the instructions specified in LOTC Disk Replication Consistency.
  2. If the alarm does not cease, contact the next level of maintenance support. Further actions are outside the scope of this Operating Instruction.
Legal |© Ericsson AB 2016-2018