ERICSSON-ALARM-XPATH-MIB
AI MIB Summary
The ERICSSON-ALARM-XPATH-MIB enables SNMP-based monitoring of Ericsson network elements by exposing active stateful alarms and stateless alerts mapped to 3GPP IRP and X.733 standards, specifically tracking unique alarm instances defined by the combination of YANG resource nodes and alarm types. It facilitates fault correlation and resynchronization through sequence numbers, timestamps, and severity-specific notifications while restricting management functions to resource state observation rather than administrative actions like acknowledgment.
This MIB Module is an Ericsson-wide SNMP interface for managing alarms. Main inputs to the MIB design are the 3GPP Alarm IRP and X.733. However, an important restriction is that the MIB only represents the resource view and not management activities like acknowledgment, etc. It describes generic notifications used to send alarm state changes and a table which represents the current active alarms in the system. The MIB supports both stateful alarms and stateless alerts.
It is important to identify clearly what is to be considered the same alarm object instance. All unique alarm *types* are identified by 'AlarmType'. An AlarmType is a one-to-one mapping with X.733 EventType, ProbabableCause and SpecificProblem. A pair of integers are used to specify the alarm type.
A unique alarm object *instance* is the combination of YangNodeInstance and AlarmType. In this way, there is no ambiguity about how alarm and alarm clear correlation should be performed: the same YANG resource instance and AlarmType shall be used. The same is true for changing existing alarm states. Severity, Additional Text and Additional Info can be changed on an existing alarm.
For stateful alarms there are notifications to report a new alarm and a cleared alarm. Changing an alarm is done via the new alarm notification. The management system shall match the alarm by using alarm type and YangNodeInstance in the same way as for clear notifications.
The MIB has different notifications for different severities in order to support SNMP managers which maps severities based on notification identifiers. For stateless alerts, there are generic notifications to send the alerts with different severities.
NOTE - Updated Definition of Alerts in TEA (The Ericsson Architecture):
Alerts are used by service management systems to evaluate service impact, and are only applicable to very specific state changes with potential service impact like restart and redundancy shifts.
Alerts SHALL NOT be used for fault indication.
Alerts should always have Perceived Severity Indeterminate, and should only be sent using eriAlarmXIndAlert notification. The other severity alert notifications should not be used, and are only present in this specification for backward compatibility reasons.
A table lists all active alarms so that a manager can read an initial state and also perform an alarm resynchronization procedure. There is also a table of latest stateless alarms. Since the stateless alarms do not have a corresponding clear message, the table size is limited by the agent instrumentation.
The MIB supports two approaches for detecting lost notifications:
- sequence numbers are used in the alarm
notifications, and are shown in the active alarm table. The last used sequence number can be read in a scalar variable
- a time stamp indicates the last time alarm
tables were updated.
Heartbeat mechanisms are supported both in pull and push mode:
- Pull: the classical SNMP polling where a
manager polls a scalar variable, for example the last sequence number used
- Push: the agent can be configured to send
heartbeat notifications. These contains the last used sequence numbers.
Document number: 11/196 03-CXC 172 7549.
Main OID:
ericssonAlarmXpathMIB.1.3.6.1.4.1.193.183.6
79
Objects
Active
Status
13
Dependencies
Imported Objects
Objects
79 total| Object Name |
|---|
ericssonAlarmXpathMIBThis MIB Module is an Ericsson-wide SNMP
interface for managing alarms. Main inputs to
the MIB design are the 3GPP Alarm IRP and X.733.
However, an important restriction is that the MIB
only represents the resource view and not
management activities like acknowledgment, etc.
It describes generic notifications used to send
alarm state changes and a table which represents
the current active alarms in the system. The MIB
supports both stateful alarms and stateless
alerts.
It is important to identify clearly what is to be
considered the same alarm object instance. All
unique alarm *types* are identified by
'AlarmType'. An AlarmType is a one-to-one
mapping with X.733 EventType, ProbabableCause and
SpecificProblem. A pair of integers are used to
specify the alarm type.
A unique alarm object *instance* is the
combination of YangNodeInstance and AlarmType.
In this way, there is no ambiguity about how alarm
and alarm clear correlation should be performed:
the same YANG resource instance and AlarmType
shall be used. The same is true for changing
existing alarm states. Severity, Additional Text
and Additional Info can be changed on an existing
alarm.
For stateful alarms there are notifications to
report a new alarm and a cleared alarm. Changing
an alarm is done via the new alarm notification.
The management system shall match the alarm by
using alarm type and YangNodeInstance
in the same way as for clear notifications.
The MIB has different notifications for different
severities in order to support SNMP managers
which maps severities based on notification
identifiers. For stateless alerts, there are
generic notifications to send the alerts
with different severities.
NOTE - Updated Definition of Alerts in TEA (The
Ericsson Architecture):
Alerts are used by service management systems
to evaluate service impact, and are only applicable
to very specific state changes with potential service
impact like restart and redundancy shifts.
Alerts SHALL NOT be used for fault indication.
Alerts should always have Perceived Severity
Indeterminate, and should only be sent using
eriAlarmXIndAlert notification. The other severity
alert notifications should not be used, and are
only present in this specification for
backward compatibility reasons.
A table lists all active alarms so that a manager
can read an initial state and also perform an
alarm resynchronization procedure. There is also
a table of latest stateless alarms. Since the
stateless alarms do not have a corresponding
clear message, the table size is limited by the
agent instrumentation.
The MIB supports two approaches for detecting
lost notifications:
- sequence numbers are used in the alarm
notifications, and are shown in the active
alarm table. The last used sequence number can
be read in a scalar variable
- a time stamp indicates the last time alarm
tables were updated.
Heartbeat mechanisms are supported both in pull
and push mode:
- Pull: the classical SNMP polling where a
manager polls a scalar variable, for example
the last sequence number used
- Push: the agent can be configured to send
heartbeat notifications. These contains the
last used sequence numbers.
Document number: 11/196 03-CXC 172 7549. MODULE-IDENTITY .1.3.6.1.4.1.193.183.6 |
eriAlarmXObjects OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.1 |
eriAlarmXSummary OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.1.1 |
eriAlarmXSumIndeterminateThis object shows the number of currently active
alarms with perceived severity 'indeterminate'.
Note that only stateful alarms are included.ro Gauge32 .1.3.6.1.4.1.193.183.6.1.1.1 |
eriAlarmXSumCriticalThis object shows the number of currently active
alarms with perceived severity 'critical'. Note
that only stateful alarms are included.ro Gauge32 .1.3.6.1.4.1.193.183.6.1.1.2 |
eriAlarmXSumMajorThis object shows the number of currently active
alarms with perceived severity 'major'. Note
that only stateful alarms are included.ro Gauge32 .1.3.6.1.4.1.193.183.6.1.1.3 |
eriAlarmXSumMinorThis object shows the number of currently active
alarms with perceived severity 'minor'. Note
that only stateful alarms are included.ro Gauge32 .1.3.6.1.4.1.193.183.6.1.1.4 |
eriAlarmXSumWarningThis object shows the number of currently active
alarms with perceived severity 'warning'. Note
that only stateful alarms are included.ro Gauge32 .1.3.6.1.4.1.193.183.6.1.1.5 |
eriAlarmXNotifObjects OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.1.2 |
eriAlarmXNObjAdditionalTextThis is a scalar variable only used in
notifications. It is size ranged with a smaller
size than the corresponding type used in the
active alarm table. This is in order to make sure
that all alarm information will fit into one UDP
packet. The additional text can be further
appended by using the dedicated append
notification.ro EriAdditionalText (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.2.1 |
eriAlarmXNObjMoreAdditionalTextThis is a scalar variable only used in
notifications. It tells the management system
that the additional text will be appended by
subsequent append additional text notifications.
NOTE: this object exists simply because of the
limitations of PDU size inherent in SNMP over
UDP, which limits the size of the PDU+headers to
under 1500 octets. Otherwise, the notification
will be fragmented.ro TruthValue (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.2.2 |
eriAlarmXNObjResourceIdThis is a scalar variable only used in
notifications. It tells the management system
that there is an SNMP-based Resource ID (OID)
that identifies the alarming resource. NOTE:
this object exists simply because of the
limitations of PDU size inherent in SNMP over
UDP, which limits the size of the PDU+headers to
under 1500 octets. Otherwise, the notification
will be fragmented.ro TruthValue (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.2.3 |
eriAlarmXNObjAdditionalInfoThis is a scalar variable only used in
notifications. It is size ranged with a smaller
size than the corresponding type used in the
active alarm table. This is in order to make sure
that all alarm information will fit into one UDP
packet. The additional info can be further
appended by using the dedicated append
notification.ro EriAdditionalInfo .1.3.6.1.4.1.193.183.6.1.2.4 |
eriAlarmXNObjMoreAdditionalInfoThis is a scalar variable only used in
notifications. It tells the management system
that the additional info will be appended by
subsequent append additional info notifications.
NOTE: this object exists simply because of the
limitations of PDU size inherent in SNMP over
UDP, which limits the size of the PDU+headers to
under 1500 octets. Otherwise, the notification
will be fragmented.ro TruthValue (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.2.5 |
eriAlarmXNObjRecordTypeThis is a scalar variable only used in
notifications. It tells the management system
whether the alarm record being reported in the
notification represents a new alarm instance
or an update of an existing alarm instance.ro EriAlarmRecordType .1.3.6.1.4.1.193.183.6.1.2.6 |
eriAlarmXNObjAppendedAdditionalInfoThis scalar variable is used for spillover of
the additional info in the append trap.ro EriAppendedAdditionalInfo .1.3.6.1.4.1.193.183.6.1.2.7 |
eriAlarmXActiveAlarms OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.1.3 |
eriAlarmXActiveNumberThis object shows the total number of currently
active alarms, i.e. the total number of entries
in the Alarm Table.ro Unsigned32 .1.3.6.1.4.1.193.183.6.1.3.1 |
eriAlarmXActiveLastChangedA timestamp when the active alarm table was last
changed. The value can be used by a manager to
initiate an alarm resynchronization procedure.
NOTE: All fields of the DateAndTime MUST be
filled out, including the hours and minutes from
UTC. As such, the value should be 11 octets
long.ro DateAndTime (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.3.2 |
eriAlarmXActiveLastSequenceNoThe last used sequence number for a alarm state
change notification. A management system can poll
this variable in order to detect lost alarm
change notifications.ro EriAlarmSequenceNumber (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.3 |
eriAlarmXActiveTableURLA URL pointing to a location where the contents
of the alarm table can be retrieved as a file.
The actual format of the file is out of the scope
of this MIB and can be found in the system
documentation. A Uniform Resource Locator in
accordance with RFC 4248. A string of length
zero means that the agent does not have a URL to
provide.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.193.183.6.1.3.4 |
eriAlarmXActiveAlarmTableThis table list all active alarms in the system.
The aspect is the resource view of the alarms,
not the administrative states and processes
performed by users. The number of entries,
active alarms, can be read in
eriAlarmXActiveNumber. Entries are created when a
resource has a new alarm state. If the same
resource has several active alarms, with
different Alarm Types, this will be represented
as separate rows. Rows disappear whenever the
alarm is cleared in the resource.
Rows can be changed when an alarm changes severity,
additional text or additional info. Alarms where
the clear state cannot be detected by the resource
are not represented in this table.
The contents of the active alarm table can also
be fetched using file transfer.
eriAlarmXActiveTableURL provides a URL to the
file. SEQUENCE OF EriAlarmXActiveAlarmEntry .1.3.6.1.4.1.193.183.6.1.3.5 |
eriAlarmXActiveAlarmEntryOne entry in the table holds one active alarm
for a given resource. Entries are created by the
system when a resource has a new alarm state.
Entries are deleted by the system when a resource
alarm state is cleared.
Alarm severity, additional text and additional
info can later be changed in a row. EriAlarmXActiveAlarmEntry .1.3.6.1.4.1.193.183.6.1.3.5.1 |
eriAlarmXActiveIndexA unique value, greater than zero, for each
alarm. It is recommended that values are
assigned contiguously starting from 1. The value
for each alarm must remain constant at least from
one re-initialization of the entity to the next
re-initialization. Note that this index should
not be used for alarm synchronization purposes
since the 'logical' index for an alarm is
- eriAlarmXActiveMajorType
- eriAlarmXActiveMinorType
- eriAlarmXActiveYangNodeInstance EriAlarmIndex (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.1 |
eriAlarmXActiveMajorTypeIn combination with eriAlarmXActiveMinorType,
this provides a unique identification of the
fault type. Different YANG Schema Nodes and
instances can share alarm types, but if the same
YANG resource instance reports the same alarm type,
it is to be considered as the same alarm state.
The alarm type is a simplification of the different
X.733 and 3GPP alarm IRP alarm correlation
mechanisms based on EventType, ProbableCause,
SpecificProblem and NotificationId. For systems
where eriAlarmXActiveMajorType is not needed for
identification purposes, it is not used and MUST
be zero-valued.ro EriAlarmType (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.2 |
eriAlarmXActiveMinorTypeIn combination with with
eriAlarmXActiveMajorType, this provides a unique
identification of the fault type, not including
the YANG Schema Node. Different YANG Schema Nodes
and instances can share alarm types, but if the
same YANG resource instance reports the same alarm
type it is to be considered as the same alarm
state. The alarm type is a simplification of the
different X.733 and 3GPP alarm IRP alarm
correlation mechanisms based on EventType,
ProbableCause, SpecificProblem and
NotificationId.ro EriAlarmType (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.3 |
eriAlarmXActiveSpecificProblemThis is a clear-text unique identification of
the alarm type. There is a one-to-one mapping
between eriAlarmXActiveSpecificProblem and
[eriAlarmXActiveMajorType,eriAlarmXActiveMinorType]ro EriAlarmSpecificProblem (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.4 |
eriAlarmXActiveYangNodeInstanceAn Abridged YANG Instance-Identifier that references
the alarming resource within the Managed Element.ro EriPath .1.3.6.1.4.1.193.183.6.1.3.5.1.5 |
eriAlarmXActiveEventTypeThe event type as defined in X.733/X.736.ro IANAItuEventType (IANA-ITU-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.6 |
eriAlarmXActiveEventTimeA time stamp of the alarm state change event.
Note that this variable represents the last
change of the alarm state, like changed severity
or additional text/info. If the alarm has not changed
state this variable represents the alarm raise
time and will be the same as originalEventTime.
NOTE: All fields of the DateAndTime MUST be
filled out, including the hours and minutes from
UTC. As such, the value should be 11 octets
long.ro DateAndTime (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.3.5.1.7 |
eriAlarmXActiveOriginalEventTimeThe time-stamp of the original alarm raise
notification.
NOTE: All fields of the DateAndTime MUST be
filled out, including the hours and minutes from
UTC. As such, the value should be 11 octets
long.ro DateAndTime (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.3.5.1.8 |
eriAlarmXActiveProbableCauseThe probable cause for the alarm originally
defined by X.733 and subsequent standards. See
also the ERICSSON-ALARM-PC-MIB. Due to the
history of problems in maintaining a standardized
probable cause the probable cause is not unique.
A best effort mapping of the alarm to existing
probable causes are used.ro EriProbableCause (ERICSSON-ALARM-PC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.9 |
eriAlarmXActiveSeverityThe severity of the alarm as defined by X.733.
Note that this may not be the original severity
since the alarm may have changed severity.ro ItuPerceivedSeverity (ITU-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.10 |
eriAlarmXActiveOriginalSeverityThe original severity as reported by the alarm
raise notification.ro ItuPerceivedSeverity (ITU-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.11 |
eriAlarmXActiveAdditionalTextA user friendly text describing the alarm. The
text is both static depending on the alarm type
(probable cause), and dynamic depending on
YANG resource instance and other conditions.
This string is longer than the corresponding
varbind in the notification in order to manage
large strings.ro EriLargeAdditionalText (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.12 |
eriAlarmXActiveOrigAdditionalTextA user-friendly text describing the alarm. The
text is both static depending on the alarm type
(probable cause), and dynamic depending on
YANG resource instance and other conditions. This is the
original text as reported by the first alarm
notification, after which it is not altered.ro EriLargeAdditionalText (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.13 |
eriAlarmXActiveResourceIdIn case the alarm refers to an object which is
instrumented by SNMP this variable indicates the
corresponding OID for the YANG resource instance.ro ResourceId (ALARM-MIB) .1.3.6.1.4.1.193.183.6.1.3.5.1.14 |
eriAlarmXActiveAdditionalInfoAdditional Information for the alarm,
structured in a way that is suitable for
machine to machine communication.
This string is longer than the corresponding
varbind in the notification in order to manage
large strings.ro EriLargeAdditionalInfo .1.3.6.1.4.1.193.183.6.1.3.5.1.15 |
eriAlarmXAlerts OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.1.4 |
eriAlarmXAlertNumberThe number of rows in the alert table.ro Unsigned32 .1.3.6.1.4.1.193.183.6.1.4.1 |
eriAlarmXAlertLastChangedA timestamp when the alert table was last
changed. Can be used by a manager to initiate a
an update of alerts procedure.
NOTE: All fields of the DateAndTime MUST be
filled out, including the hours and minutes from
UTC. As such, the value should be 11 octets
long.ro DateAndTime (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.4.2 |
eriAlarmXAlertLastSequenceNoThe last sequence number used in alert
notifications. This can be used to detect a lost
notification.ro EriAlarmSequenceNumber (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.3 |
eriAlarmXAlertTableURLA URL pointing to a location where the contents
of alert table can be retrieved as a file. The
format of the file is out of the scope of this
MIB and system dependant. A Uniform Resource
Locator in accordance with RFC 4248.ro SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.193.183.6.1.4.4 |
eriAlarmXAlertTableThis table lists the last alerts in the system.
An alert is a stateless event, that is no clear
notification will be sent. Rows in this table are
created when a new alert event is detected. Rows
are deleted by the instrumentation at a
predefined size or age. SEQUENCE OF EriAlarmXAlertEntry .1.3.6.1.4.1.193.183.6.1.4.5 |
eriAlarmXAlertEntryOne entry in the table holds one alert for a
given resource. Rows in this table are created
when a new alert is detected. Rows are deleted
by the instrumentation at a predefined size or
age. EriAlarmXAlertEntry .1.3.6.1.4.1.193.183.6.1.4.5.1 |
eriAlarmXAlertIndexIndex in the alert table. EriAlarmIndex (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.1 |
eriAlarmXAlertMajorTypeIn combination with eriAlarmXAlertMinorType, this
provides unique identification of the alert.
This is a simplification of the different X.733
and 3GPP alarm IRP alarm correlation mechanisms
based on EventType, ProbableCause,
SpecificProblem and NotificationId.ro EriAlarmType (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.2 |
eriAlarmXAlertMinorTypeIn combination with eriAlarmXAlertMajorType, this
provides a unique identification of the alert.
This is a simplification of the different X.733
and 3GPP alarm IRP alarm correlation mechanisms
based on EventType, ProbableCause,
SpecificProblem and NotificationId.ro EriAlarmType (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.3 |
eriAlarmXAlertSpecificProblemThis is a clear-text unique identification of
the alert type. There is a one-to-one mapping
between eriAlarmXAlertSpecificProblem and
[eriAlarmXAlertMajorType, eriAlarmXAlertMinorType]ro EriAlarmSpecificProblem (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.4 |
eriAlarmXAlertYangNodeInstanceAn Abridged YANG Instance-Identifier that references a
resource within the Managed Element.ro EriPath .1.3.6.1.4.1.193.183.6.1.4.5.1.5 |
eriAlarmXAlertEventTypeThe event type as defined in X.733/X.736.ro IANAItuEventType (IANA-ITU-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.6 |
eriAlarmXAlertEventTimeA time stamp of the alert. NOTE: All fields of
the DateAndTime MUST be filled out, including the
hours and minutes from UTC. As such, the value
should be 11 octets long.ro DateAndTime (SNMPv2-TC) .1.3.6.1.4.1.193.183.6.1.4.5.1.7 |
eriAlarmXAlertProbableCauseThe probable cause, originally defined by X.733
and subsequent standards.
See also the ERICSSON-ALARM-PC-MIB. Due to the
history of problems in maintaining a standardized
probable cause the probable cause is not unique.
A best effort mapping of the alert to existing
probable causes are used.ro EriProbableCause (ERICSSON-ALARM-PC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.8 |
eriAlarmXAlertSeverityThe severity of the alert as defined by X.733ro ItuPerceivedSeverity (ITU-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.9 |
eriAlarmXAlertAdditionalTextA user friendly text describing the alert. The
text is both static depending on the alert type
and dynamic depending on YANG resource instance
and other conditions.ro EriLargeAdditionalText (ERICSSON-ALARM-TC-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.10 |
eriAlarmXAlertResourceIdIn case the alert refers to an object which is
instrumented by SNMP this variable indicates the
corresponding OID for the YANG resource instance.ro ResourceId (ALARM-MIB) .1.3.6.1.4.1.193.183.6.1.4.5.1.11 |
eriAlarmXAlertAdditionalInfoAdditional Information for the alert,
structured in a way that is suitable for
machine to machine communication.
This string is longer than the corresponding
varbind in the notification in order to manage
large strings.ro EriLargeAdditionalInfo .1.3.6.1.4.1.193.183.6.1.4.5.1.12 |
eriAlarmXHeartBeat OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.1.5 |
eriAlarmXHbIntervalThe notification eriAlarmXHeartBeatNotif will be
sent every eriAlarmXHbInterval. Managers can
subscribe to the notification using the SNMP
framework MIBS by using the snmpNotifyName
'heartbeat'. (SNMP-NOTIFICATION-MIB,
snmpNotifyTable)rw Unsigned32 .1.3.6.1.4.1.193.183.6.1.5.1 |
eriAlarmXNotifications OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.2 |
eriAlarmXNotifsPrefix OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.2.0 |
eriAlarmXIndeterminateThis notification is sent when a resource
detects a new alarm state with severity
indeterminate. The notification is also used to
change severity, additional text and/or additional
info of an alarm. The eriAlarmXNObjRecordType
varbind will indicate whether this is a new alarm
instance or a change to an existing alarm instance.
The combination of YangNodeInstance
and MajorType/MinorType is always unique and can be
used by management systems to correlate alarm,
alarm change, and alarm clear. A corresponding
row will be created in the Alarm Table. The
sequence number will increase for every
notification and can be used to detect lost
notifications.
A management system should be prepared for
appending text to additional text, indicated by
the eriAlarmXNObjMoreAdditionalText varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional text.)
A management system should be prepared for
appending text to additional info, indicated by
the eriAlarmXNObjMoreAdditionalInfo varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional info.)
A management system should also be prepared to
receive a resource ID (OID) identifying the
alarming resource if the system sending the
notification can provide that information. In
that case, eriAlarmXNObjResourceId will be set to
'true' and the resource ID will be sent in an
eriAlarmXAppendInfo notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.1 |
eriAlarmXWarningThis notification is sent when a resource
detects a new alarm state with severity warning.
The notification is also used to change severity,
additional text and/or additional info
of an alarm. The eriAlarmXNObjRecordType
varbind will indicate whether this is a new alarm
instance or a change to an existing alarm instance.
The combination of YangNodeInstance and
MajorType/MinorType is always unique and can be
used by management systems to correlate alarm,
alarm change, and alarm clear. A corresponding
row will be created in the Alarm Table,
(eriAlarmXActiveAlarmTable). The sequence number
will increase for every notification and can be
used to detect lost notifications.
A management system should be prepared for
appending text to additional text, indicated by
the eriAlarmXNObjMoreAdditionalText varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional text.)
A management system should be prepared for
appending text to additional info, indicated by
the eriAlarmXNObjMoreAdditionalInfo varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional info.)
A management system should also be prepared to
receive a resource ID (OID) identifying the
alarming resource if the system sending the
notification can provide that information. In
that case, eriAlarmXNObjResourceId will be set to
'true' and the resource ID will be sent in an
eriAlarmXAppendInfo notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.2 |
eriAlarmXMinorThis notification is sent when a resource
detects a new alarm state with severity minor.
The notification is also used to change severity,
additional text and/or additional info
of an alarm. The eriAlarmXNObjRecordType
varbind will indicate whether this is a new alarm
instance or a change to an existing alarm instance.
The combination of YangNodeInstance and
MajorType/MinorType is always unique and can be
used by management systems to correlate alarm,
alarm change, and alarm clear. A corresponding
row will be created in the Alarm Table,
(eriAlarmXActiveAlarmTable). The sequence number
will increase for every notification and can be
used to detect lost notifications.
A management system should be prepared for
appending text to additional text, indicated by
the eriAlarmXNObjMoreAdditionalText varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional text.)
A management system should be prepared for
appending text to additional info, indicated by
the eriAlarmXNObjMoreAdditionalInfo varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional info.)
A management system should also be prepared to
receive a resource ID (OID) identifying the
alarming resource if the system sending the
notification can provide that information. In
that case, eriAlarmXNObjResourceId will be set to
'true' and the resource ID will be sent in an
eriAlarmXAppendInfo notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.3 |
eriAlarmXMajorThis notification is sent when a resource
detects a new alarm state with severity major.
The notification is also used to change severity,
additional text and/or additional info
of an alarm. The eriAlarmXNObjRecordType
varbind will indicate whether this is a new alarm
instance or a change to an existing alarm instance.
The combination of YangNodeInstance and
MajorType/MinorType is always unique and can be
used by management systems to correlate alarm,
alarm change, and alarm clear. A corresponding
row will be created in the Alarm Table,
(eriAlarmXActiveAlarmTable). The sequence number
will increase for every notification and can be
used to detect lost notifications.
A management system should be prepared for
appending text to additional text, indicated by
the eriAlarmXNObjMoreAdditionalText varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional text.)
A management system should be prepared for
appending text to additional info, indicated by
the eriAlarmXNObjMoreAdditionalInfo varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional info.)
A management system should also be prepared to
receive a resource ID (OID) identifying the
alarming resource if the system sending the
notification can provide that information. In
that case, eriAlarmXNObjResourceId will be set to
'true' and the resource ID will be sent in an
eriAlarmXAppendInfo notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.4 |
eriAlarmXCriticalThis notification is sent when a resource
detects a new alarm state with severity critical.
The notification is also used to change severity,
additional text and/or additional info
of an alarm. The eriAlarmXNObjRecordType
varbind will indicate whether this is a new alarm
instance or a change to an existing alarm instance.
The combination of YangNodeInstance and
MajorType/MinorType is always unique and can be
used by management systems to correlate alarm,
alarm change, and alarm clear. A corresponding
row will be created in the Alarm Table,
(eriAlarmXActiveAlarmTable). The sequence number
will increase for every notification and can be
used to detect lost notifications.
A management system should be prepared for
appending text to additional text, indicated by
the eriAlarmXNObjMoreAdditionalText varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional text.)
A management system should be prepared for
appending text to additional info, indicated by
the eriAlarmXNObjMoreAdditionalInfo varbind, and
sent with eriAlarmXAppendInfo. (Note do not
confuse this with a change of additional info.)
A management system should also be prepared to
receive a resource ID (OID) identifying the
alarming resource if the system sending the
notification can provide that information. In
that case, eriAlarmXNObjResourceId will be set to
'true' and the resource ID will be sent in an
eriAlarmXAppendInfo notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.5 |
eriAlarmXClearedThis notification is sent when a resource
detects a cleared alarm state. The combination of
YangNodeInstance and MajorType/MinorType is
always unique and shall be used by management
systems to correlate alarm and alarm clear.
The corresponding row in the alarm table will be
deleted, (eriAlarmXActiveAlarmTable). The
sequence number will increase for every
notification and can be used to detect lost
notifications.
Note that it should not be required to send an
append trap for a cleared alarm. Those varbinds
which flag that an append trap will follow are
kept here for backward compatibility reasons. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.7 |
eriAlarmXAppendInfoThis notification is sent in order to append
further info to an alarm notification. It might be
additional text, additional info or a resource ID
(OID) identifying the alarming resource using an OID.
If additional text/info is sent, do not confuse this
with an actual change of additional text/info which
is reported using the eriAlarmX<severity>
notification.
A zero-length string value for
eriAlarmXNObjAdditionalText means that no
additional text is being sent in this
notification.
A zero-length string value for
eriAlarmXNObjAppendedAdditionalInfo means that no
additional info is being sent in this
notification.
A null OID (0.0) value for
eriAlarmXActiveResourceId means that no resource
ID is being sent in this notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.8 |
eriAlarmXIndAlertThis notification is sent when a resource
detects a new alert with severity indeterminate.
A corresponding row will be created in the Alert
Table. The sequence number will increase for
every notification and can be used to detect lost
notifications. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.10 |
eriAlarmXWarnAlertThis notification is sent when a resource
detects a new alert with severity warning. A
corresponding row will be created in the Alert
Table. The sequence number will increase for
every notification and can be used to detect lost
notifications. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.11 |
eriAlarmXMinorAlertThis notification is sent when a resource
detects a new alert with severity minor. A
corresponding row will be created in the Alert
Table. The sequence number will increase for
every notification and can be used to detect lost
notifications. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.12 |
eriAlarmXMajorAlertThis notification is sent when a resource
detects a new alert with severity major. A
corresponding row will be created in the Alert
Table. The sequence number will increase for
every notification and can be used to detect lost
notifications. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.13 |
eriAlarmXCriticalAlertThis notification is sent when a resource
detects a new alert with severity critical. A
corresponding row will be created in the Alert
Table. The sequence number will increase for
every notification and can be used to detect lost
notifications. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.14 |
eriAlarmXAppendAlertInfoThis notification is sent in order to append
further info to an alert notification. It might be
additional text or a resource ID (OID)
identifying the alarming resource using an OID.
This complements information sent in a previous
notification.
If additional text/info is sent, do not confuse this
with an actual change of additional text/info which is
reported using the eriAlarmXAlert<severity>
notification.
A zero-length string value for
eriAlarmXNObjAdditionalText means that no
additional text is being sent in this
notification.
A zero-length string value for
eriAlarmXNObjAppendedAdditionalInfo means that no
additional info is being sent in this
notification.
A null OID (0.0) value for
eriAlarmXAlertResourceId means that no resource
ID is being sent in this notification. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.15 |
eriAlarmXHeartBeatNotifThis is a heartbeat notification with interval
according to the eriAlarmXHbInterval. It contains
the last sequence numbers used for alarms and
alarm events. These varbinds can be used to
detect lost notifications.
The notification eriAlarmXHeartBeatNotif will be
sent every eriAlarmXHbInterval. Managers can
subscribe to the notification using the SNMP
framework MIBS by using the snmpNotifyName
'heartbeat'. (SNMP-NOTIFICATION-MIB,
snmpNotifyTable). NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.20 |
eriAlarmXAlarmListRebuiltThis notification is sent when the active alarm
list has reached a stable situation after a
restart or after a system internal audit process.
It is an indication to the manager to perform a
alarm resynchronization procedure. NOTIFICATION-TYPE .1.3.6.1.4.1.193.183.6.2.0.30 |
eriAlarmXConformance OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.4 |
eriAlarmXCompliances OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.4.1 |
eriAlarmXGroups OBJECT IDENTIFIER .1.3.6.1.4.1.193.183.6.4.2 |