Table Of Contents
The Event Management Challenge
Sequence Association vs. Root-Cause Analysis
Fault Management Overview
This chapter describes the challenge of managing an overabundance of events, and introduces some of the key concepts of Cisco ANA alarm management.
The Event Management Challenge describes the event management challenge and how this challenge is met.
Basic Concepts and Terms describes the basic concepts and terms used throughout this guide.
Severity Propagation describes the concept of severity and how severity is propagated.
Sources of Alarms on a Device describes the four basic alarm sources that indicate problems in the network.
Event Processing Overview describes the process for identifying and processing raw events.
Event Suppression describes enabling or disabling port down/up and link down/up alarms on a selected port.
Alarm Integrity describes what happens when a VNE shuts down that has associated open alarms.
The Event Management Challenge
The challenge of dealing effectively with events and alarms is to know how to understand and efficiently process and organize bulks of raw events that may be generated as a result of single root-cause events.
Figure 1-1 Event Flood
Meeting the event management challenge is done by correlating related events into a sequence that represents the alarm lifecycle, and using the network dependency model to determine the causal inter-relationship between alarms.
Cisco ANA offers extensive fault analysis and management capabilities that ensure quick and accurate fault detection, isolation and correlation capabilities. Once a fault is identified, the system uses the auto-discovered virtual network model to perform fault inspection and correlation in order to determine the root cause of the fault and, if applicable, to perform service impact analysis.
Basic Concepts and Terms
Alarm
An Alarm represents a scenario which involves a fault occurring in the network or management system. Alarms represent the complete fault lifecycle, from the time that the alarm is opened (when the fault is first detected) until it is closed and acknowledged. Examples of alarms include:
•
Link down
•
•
•
Event
An Event is an indication of a distinct occurrence that occurred at a specific point in time. Events are derived from incoming traps/notifications and from detected status changes. Examples of events include:
•
•
•
•
•
Events are written to the Cisco ANA database once and never change.
The collected events are displayed in the Cisco ANA EventVision. Please refer to the Cisco ANA EventVision Guide for more information.
Event Sequence
An Event Sequence is the set of related events, which composes a single alarm. For example, Link down - Ack - Link up.
Figure 1-2 Event Sequence Example
Typically, a complete event sequence includes three mandatory events:
•
•
•
Optionally, there can be any number of Alarm Change events, which can be triggered by new severity events, affected services update events, etc.
Note
An event sequence can consist of a single event (for example, "Device Reset")
The set of events that should participate in Cisco ANA alarm processing can be configured in the system registry.
Repeating Event Sequence
If a new opening event arrives within a (configurable) timeout after the clearing event (of the same alarm), the alarm is updatable and a Repeating Event Sequence is created, i.e.the event is attached to the existing sequence, and updates its severity accordingly. If the new opening event occurs after the timeout, it opens a new alarm (new event sequence).
Figure 1-3 Repeating Event Sequence
Flapping Events
If a series of events that are considered to be of a same sequence occurs in the network in a certain configurable time-window a certain (configurable) amount of times, the VNE may (upon configuration) reduce further the number of event, and will issue a single event which will be of type "Event Flapping". Only when the alarm "stabilizes", i.e. the event frequency is reduced, another update to the event sequence will be issued as "Event stopped flapping", and then another update will be issued with the most up-to-date event state.
Figure 1-4 Flapping Event
Correlation by Root-Cause
Root-cause correlation is determined between alarms (i.e. between event sequences). It represents a causal relationship between an alarm and the consequent alarms that occurred because of it.
For example, a Card-out alarm can be the root-cause of several Link-down alarms, which in turn can be the root-cause of multiple Route-lost and Device unreachable alarms, and so on (a consequent alarm can serve as the root-cause of other consequent alarms).
Figure 1-5 Root-Cause Correlation Hierarchy Example
Ticket
A Ticket represents the complete alarm correlation tree of a specific fault scenario. It can be also identified by the topmost ("root of all roots") Alarm. Both Cisco ANA NetworkVision and Cisco ANA EventVision display tickets and allow drilling down to view the consequent alarm hierarchy.
From an operator's point of view, the managed entity is always a complete ticket. Operations such as Acknowledge, Force-clear or Remove are always applied to the whole ticket. The ticket also assumes an overall, propagated severity.
Sequence Association vs. Root-Cause Analysis
It is important not to confuse between the two types of relationships in Cisco ANA alarm management:
•
•
The following figure shows how both types of relations are implemented in the ticket hierarchy:
Figure 1-6 Sequence Association vs. Root-Cause Analysis
In the above figure, the "clouds" represent alarms, which are correlated into a hierarchy according to root-cause. Within each alarm is its respective event sequence, representing the lifecycle of the alarm.
Severity Propagation
Each event has an assigned severity (user-configurable). For example, a Link-up event may be assigned Critical severity, while its corresponding Link-up event will have Normal severity.
The propagated severity of the alarm (i.e. the whole event sequence) is always determined by the last event in the sequence. Thus, in the above example, when the Link-down alarm is open it will have Critical severity, and when it clears it move to Normal severity. An exception to this rule is the informational event (severity level of Info) such as "User acknowledge" event, which does not change the propagated severity of the sequence (i.e. the alarm).
Each ticket assumes the propagated severity of the alarm with the topmost severity, within all the alarms in the correlation hierarchy (at any level).
Note
Sources of Alarms on a Device
There are four basic sources for alarms which indicate a problem in the network that are currently supported by the platform:
•
vpn leakalarm.•
•
•
–
–
–
For information about TCA alarms, refer to the Cisco ANA Customization User's Guide.
Event Processing Overview
Cisco ANA provides a customizable framework for identifying and processing raw events. The raw events are collected into the Event Manager, forwarded to their respective VNE, and then processed as follows:
Step 1
Step 2
Step 3
Step 4
•
•
•
Event Suppression
The user can enable or disable the port down/up and link down/up alarms on a selected port. By default, alarms are enabled on all ports. When the alarms are disabled on a port, no alarms will be generated for the port and they will not be displayed in the Ticket pane. Using the advanced tools (Registry Editor) it is possible to enable or disable Service Alarms on network entities other then ports, such as the MPBGP (for enabling/disabling BGP neighbor down service alarm.), or the MPLS TE Tunnel (for TE-Tunnel down service alarm) etc. It is also possible to enable or disable alarm specific types, without regard to a specific network entity.
To disable/enable a port alarm:
Refer to the Cisco Active Network Abstraction NetworkVision User's Guide for information about disabling or enabling a port alarm.
Alarm Integrity
When the VNE shuts down and still has open alarms associated with it, "fixing" events which occur during the down period will be consolidated when the VNE is reloaded.
Related Documentation
For more information, refer to the following publications:
•
•
•
•
