-
Cisco Active Network Abstraction Fault Management User Guide Version 3.5.2
-
Cisco ANA 3.5.2 Fault Management User Guide - PDF of Entire Book
-
Fault Management Overview
-
Correlation Logic
-
Advanced Correlation Scenarios
-
Correlation Over Unmanaged Segments
-
Event and Alarm Configuration Parameters
-
Impact Analysis
-
Supported Service Alarms
-
Supported Traps and Syslogs
-
Event and Alarm Correlation Flow
-
Table Of Contents
Advanced Correlation Scenarios
IP Interface Failure Scenarios
IP Interface Status Down Alarm
Correlation of Syslogs and Traps
Ethernet, Fast Ethernet, Giga Ethernet Examples
ip interface status down Parameters
All ip interfaces down Parameters
Advanced Correlation Scenarios
This chapter describes the specific alarms which use advanced correlation logic on top of the root cause analysis flow:
•
Device Unreachable Alarm—Describes the device unreachable alarm, its correlation and provides various examples.
•
•
Device Unreachable Alarm
Connectivity Test
Connectivity tests are used to verify connectivity between the VNEs and managed network elements. The connectivity is tested using each protocol the VNE uses to poll the device. The supported protocols for connectivity tests are SNMP, Telnet and ICMP.
A device unreachable alarm will be issued if one or more of the connectivity test fails, that is, the device does not respond on this protocol. The alarm will be cleared when all the protocol connectivity test are passed successfully.
Note
Device Fault Identification
When a network element stops responding to queries from the management system, one of two things has happened:
•
•
Cisco ANA implements an algorithm that uses additional data to heuristically resolve the ambiguity and declare the root cause correctly. Refer to the following examples:
Device Unreachable Example 1
In this example, the router (R1) goes down. As a result the links, L2, L3, and L4 go down in addition to the R1 session.
Figure 3-1 Device Unreachable Example 1
In this case the system will provide the following report:
•
•
–
–
–
Device Unreachable Example 2
In this example, the router (R1) goes down. As a result the links, L2, L3, and L4 go down as well as the R1 session. The router R2, accessed by the link L3 is also unreachable.
Note
Figure 3-2 Device Unreachable Example 2
Note
In this case the system will provide the following report:
•
•
–
–
–
HSRP Alarms
When an active Hot Standby Router Protocol (HSRP) group's status changes, a service alarm is generated and a syslog is sent.
Note
HSRP Example
In this example the link between Router 2 and Switch 2 is shut down causing the HSRP standby group on Router 3 to become active, and a link-down service alarm is generated. The primary HSRP group on Router 2 is not active anymore. A service alarm is generated and correlated to the link-down alarm. Router 2 also sends a syslog which is correlated to the link-down alarm.
The secondary HSRP group configured on Router 3 now changes from standby to active. This network event triggers an IP-based active flow with the destination being the virtual IP address configured in the HSRP group. When the flow reaches its destination, a service alarm is generated and correlated to the link-down alarm. Router 3 also sends a syslog which is correlated to the link-down alarm.
Figure 3-3 HSRP Example 1
In this case the system provides the following report:
•
•
–
–
%HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak(source: Router 2)–
–
%STANDBY-6-STATECHANGE: Ethernet0/0 Group 1 state Standby -> Active(source: Router 3)HSRP Registry Parameters
The following "hsrp group status changed" parameters can be controlled through the registry for both primary and secondary service alarms:
•
•
The following "hsrp syslog" parameter can be controlled through the registry for both primary and secondary HSRP status change syslogs:
•
Note
IP Interface Failure Scenarios
This section includes:
•
•
IP Interface Status Down Alarm
Alarms related to subinterfaces, for example, line-down trap, line-down syslog, and so on, are reported on IP interfaces configured above the relevant subinterface. This means that in the system, subinterfaces are represented by the IP interfaces configured above them. All events sourcing from subinterfaces without a configured IP are reported on the underlying Layer 1.
An "ip interface status down" alarm is generated when the status of the IP interfaces (whether it is over an interface or a subinterface) changes from up to down or any other non-operational state. All events sourced from the subinterfaces correlate to this alarm. In addition an "All ip interfaces down" alarm is generated when all the IP interfaces above a physical port change state to down.
The alarm's description includes the full name of the IP interface, for example Serial0.2 (including the identifier for the subinterface if it is a subinterface) and the source of the alarm source points to the IP interface (and not to Layer1).
All syslogs and traps indicating changes in subinterfaces (above which an IP is configured) correlate to the "ip interface status down" alarm (if this alarm was supposed to be issued). The source of these events is the IP interface. Syslogs and traps that indicate problems in Layer1 (that do not have a subinterface qualifier in their description) are sourced to Layer1.
Note
For example:
•
•
For events that occur on subinterfaces:
•
•
•
In case the main interface goes down, all related subinterfaces' traps and syslogs are correlated as child tickets to the main interface parent ticket.
The following technologies are supported:
•
•
•
•
•
Correlation of Syslogs and Traps
When receiving a trap or syslog for the subinterface level, immediate polling of the status of the relevant IP interface occurs and a polled parent event (for example, ip interface status down) is created. The trap or syslog is correlated to this alarm.
Where there is a multipoint setup and only some circuits under an IP interface go down, and this does not cause the state of the IP interface to change to down, then no "ip interface status down" alarm is created. All the circuit down syslogs correlate by flow to the possible root cause, for exampl,e Device unreachable on a customer edge (CE) device.
All IP Interfaces Down Alarm
•
•
•
Note
The All ip interfaces down alarm is sourced to the Layer1 component. All alarms from "the other side", for example, device unreachable correlate to the All ip interfaces down alarm.
IP Interface Failure Examples
Note
If this is not the case, as in some Ethernet networks, and there is no change to the state of the IP interface, all the events on the subinterfaces that are capable of correlation flow will try to correlate to other possible root causes, including "cloud problem".
Interface Example 1
In this example there is multipoint connectivity between a PE and number of CEs through an unmanaged Frame Relay network. All the CEs (Router2 and Router3) have logical connectivity to the PE through a multipoint subinterface on the PE (Router10). The keep alive option is enabled for all circuits. A link is disconnected inside the unmanaged network that causes all the CEs to become unreachable.
Figure 3-4 Interface Example 1
The following failures are identified in the network:
•
•
The following correlation information is provided:
•
•
Interface Example 2
In this example there is point-to-point connectivity between a PE and a CE through an unmanaged Frame Relay network. CE1 became unreachable, and the status of the IP interface on the other side (on the PE1) changed state to down. The "keep alive" option is enabled. The interface is shut down between the unmanaged network and CE1.
Figure 3-5 Interface Example 2
The following failures are identified in the network:
•
•
The following correlation information is provided:
•
–
–
Interface Example 3
In this example there is a failure of multiple IP interfaces above the same physical port (mixed point-to-point and multipoint Frame Relay connectivity). CE1 (Router2) has a point-to-point connection to PE1 (Router10). CE1 and CE2 (Router3) have multipoint connections to PE1. The IP interfaces on PE1 that are connected to CE1, and CE2 are all configured above Serial0/0. The "keep alive" option is enabled. A link is disconnected inside the unmanaged network that has caused all the CEs to become unreachable.
Figure 3-6 Interface Example 3
The following failures are identified in the network:
•
•
The following correlation information is provided:
•
–
–
–
Interface Example 4
In this example there is a link down. In a situation where a link down occurs, whether it involves a cloud or not, the link failure is considered to be the most probable root cause for any other failures. In this example, a link is disconnected between the unmanaged network and the PE.
Figure 3-7 Interface Example 4
The following failures are identified in the network:
•
•
•
•
The following correlation information is provided:
•
•
•
•
Interface Example 5
In this example on the PE1 device that has multipoint connectivity, one of the circuits under the IP interface has gone down and the CE1 device which is connected to it has become unreachable. The status of the IP interface has not changed and other circuits are still operational.
Figure 3-8 General Interface Example
The following failures are identified in the network:
•
•
The following correlation information is provided:
•
–
ATM Examples
Similar examples involving ATM technology have the same result, assuming that a failure in an unmanaged network causes the status of the IP interface to change to down (ILMI is enabled).
Ethernet, Fast Ethernet, Giga Ethernet Examples
Interface Example 6
In this example there is an unreachable CE due to a failure in the unmanaged network.
Figure 3-9 Interface Example 5
The following failures are identified in the network:
•
•
The following correlation information is provided:
•
•
Note
Interface Example 7
In this example there is a link down on the PE that results in the CE becoming unreachable.
Figure 3-10 Interface Example 6
The following failures are identified in the network:
•
•
•
The following correlation information is provided:
•
–
–
–
Interface Registry Parameters
ip interface status down Parameters
The following ip interface status down parameters can be controlled through the registry:
•
•
•
•
•
•
•
•
•
Note
All ip interfaces down Parameters
The following All ip interfaces down parameters can be controlled through the registry:
•
•
•
•
•
•
•
•
Note
