Contents
1 Introduction
This document gives an overview of the notification Configuration Fault.
2 Notification Description
The notification is issued when Evolved VIP (eVIP) discovers a faulty configuration.
The possible causes are as follows:
- A faulty configuration is entered.
- eVIP starts, or restarts, with a faulty configuration.
- An Abstract Load Balancer (ALB) or a Front-end Element (FEE) is activated with a faulty configuration.
OpenSAF, and thereby Core Middlware (Core MW), has no defined way of giving feedback when a faulty configuration is entered. The desired behavior is shown in Figure 1.
A general "operation failed" can be returned and some expected feedback is missing for most semantic faults. An operator may require more information to correct the input given.
To overcome this shortcoming eVIP issues a stateless alarm (a notification) when a faulty configuration is discovered. There is no way to issue a notification to only one listener, so as an undesired side-effect all alarm listeners will receive the notification. Even those who is not entering the faulty configuration, or are even unaware that a reconfiguration is going on. The use case is shown in Figure 2.
2.1 Notification Attributes
This notification is compliant with Ericsson SNMP Fault Management MIB, which conforms to X.733 alarm reporting function. However, the following X.733 parameters are not supported; Correlated Notifications, Additional Info, Monitored Attributes, Proposed Repair Action, Trend Indication, Threshold Information, Backed Up Object, and State Change Definition.
The most essential statical attributes of this notification and their values are described as follows:
|
Major type |
193 |
|
Minor type |
2129526884 (0x7eee0064) |
|
Specific Problem |
eVIP, Configuration Fault |
The Alarm Type of the alarm is identified by the two integers, Major Type and Minor Type, and is unique within the system type and maps to X.733 Managed Object Instance. The Event Type, Probable Cause, and Specific Problem are always the same for a given Alarm Type.
3 Procedure
The configuration faults can be divided into two types:
- Syntax faults, for example, a malformed IP address is
used.
This type of fault can be detected immediately when the configuration is entered and the faulty configuration is not stored in the Information Model Management (IMM).
- Semantic faults. The configuration is syntactically
correct but can not be processed by eVIP.
For this type of fault, the faulty configuration is stored in the IMM and the fault is detected at a later point in time when eVIP is notified to read the new configuration.
The <Managed Object> passed in the notification with its Distinguished Name is the object where the fault was detected. The additionalText field contains information on what was wrong.
To clear the alarm, do the following: