user manual
Table Of Contents
- Cisco Active Network Abstraction Fault Management User Guide Version 3.6 Service Pack 1
- Contents
- About This Guide
- Fault Management Overview
- Fault Detection and Isolation
- CiscoANA Event Correlation and Suppression
- Advanced Correlation Scenarios
- Device Unreachable Alarm
- IP Interface Failure Scenarios
- Multi Route Correlation
- Generic Routing Encapsulation (GRE) Tunnel Down/Up
- BGP Process Down Alarm
- MPLS Interface Removed Alarm
- LDP Neighbor Down Alarm
- Correlation Over Unmanaged Segments
- Event and Alarm Configuration Parameters
- Impact Analysis
- Supported Service Alarms
- Event and Alarm Correlation Flow

7-2
Cisco Active Network Abstraction Fault Management User Guide, Version 3.6 Service Pack 1
OL-14284-01
Chapter 7 Impact Analysis
Impact Report Structure
Note Each fault which has been identified as potentially service affecting triggers a generation of impact
analysis calculation event if it is reoccurring in the network.
This chapter describes the automatic impact analysis. For more information about proactive impact
analysis, refer to the Cisco Active Network Abstraction NetworkVision User Guide.
Impact Report Structure
The impact report contains a list of pairs of endpoints when the service between them has been affected.
Each endpoint has the following details:
• Endpoint physical or logical location—An endpoint can be a physical entity (for example, a port)
or a logical one (for example, a subinterface). The impact report contains the exact location of the
entity. All the location identifiers start with the ID of the device which holds the endpoint. The other
details in the location identifier are varied according to the endpoint type, for example VC, VP, IP
interface.
• Business tag properties—Key, name, type (if attached to the entity).
Note For specific information about the report structure in MPLS networks, refer to the Cisco Active Network
Abstraction MPLS User Guide.
Affected Severities
In automatic mode, the affected parties can be marked with one of the following severities:
• Potentially affected—The service might be affected but its actual state is not yet known.
• Real affected—The service is affected.
• Recovered—The service is recovered. This state relates only to entries that were marked previously
as potentially affected. It indicates only the fact that there is an alternate route to the service,
regardless of the service quality level.
• The initial impact report might mark the services as either potentially or real affected. As time
progresses and more information is accumulated from the network, the system might issue
additional reports to indicate which of the potentially affected parties are real or recovered.
• The indications for these states are available both through the API and in the GUI.
Note The reported impact severities vary between fault scenarios. For more information about fault scenarios
in an MPLS network see the Cisco Active Network Abstraction MPLS User Guide.
Note There is no clear state for the affected services when the alarm is cleared.