Table Of Contents
Advanced Correlation Scenarios
IP Interface Failure Scenarios
IP Interface Status Down Alarm
Ethernet, Fast Ethernet, Giga Ethernet Examples
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.
HSRP Alarms describes the HSRP alarms and provides various examples.
IP Interface Failure Scenarios describes the "ip interface status down" alarm and its correlation. In addition, it describes the "all ip interfaces down" alarm, its correlation and provides several examples.
Device Unreachable Alarm
Connectivity Test
Connectivity tests are used to verify connectivity between the Cisco ANA VNEs and managed network elements. The connectivity is tested per each protocol through which the VNE polls the device. The supported protocols for connectivity test are SNMP, Telnet and ICMP.
Device unreachable alarm will be issued if one or more of the connectivity test fails. i.e. the device does not respond on this protocol. The alarm will be cleared when all the protocol connectivity test are passed successfully.
Note
The ICMP connectivity test is enabled in the Cisco ANA Manage.
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 examples that follow.
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, 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 1
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 the following:
•
•
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 actually 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 Layer1.
An "ip interface status down" alarm is generated when the status of the ip interfaces (whether it is over an interface or a sub interface) changes from "Up" to "Down", or any other non-operational state. All events sourcing from the subinterfaces correlate to this alarm. In addition an "All ip interfaces down" alarm is generated when all of the ip interfaces above a physical port change state to "Down".
The alarm's description includes the full name of the IP interface, e.g. Serial0.2 (including the identifier for the sub interface if it is a sub interface) and the source of the alarm source points to the IP interface (and not to Layer1).
All syslogs and traps indicating changes in sub interfaces (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 IPInterface. 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 sub-interfaces traps and syslogs are correlated as child tickets to the main interface parent ticket.
The following technologies are supported:
•
•
•
•
•
Correlation of Syslogs/Traps
When receiving a trap/syslog for the sub interface 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/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 of the circuit down syslogs correlate by flow to the possible root cause, for example "Device unreachable" on a 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 of the events on the sub interfaces that are correlation flow capable, 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 of the CEs (Router2 and Router3) have logical connectivity to the PE through a multipoint sub interface 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 of 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"
The following "ip interface status down" parameters can be controlled through the Registry:
•
•
•
•
•
•
•
•
•
Note
"All ip interfaces down"
The following "All ip interfaces down" parameters can be controlled through the Registry:
•
•
•
•
•
•
•
•
Note
