Cisco Prime Nerk 43 User Guide

							 
C-39
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
Interface Example 6
Figure C-39 shows an unreachable CE due to a failure in the unmanaged network.
Figure C-39 Interface Example 6
The following failures are identified in the network: 
A Device Unreachable alarm is generated on the CE.
A Cloud Problem alarm is generated.
The following correlation information is provided:
No alarms are generated on a PE for Layer 1, Layer 2, or IP interface layers.
The Device Unreachable alarm is correlated to the Cloud Problem alarm.
Interface Example 7
Figure C-40 shows a Link Down alarm on a PE that results in a CE becoming unreachable.
Figure C-40 Interface Example 7
The following failures are identified in the network:
A Link Down alarm is generated on the PE.
An Interface Status Down alarm is generated on the PE.
A Device Unreachable alarm is generated on the CE. 
The following correlation information is provided:
Link Down on the PE: 
–The Interface Status Down alarm on the PE is correlated to the Link Down alarm.
–The Device Unreachable alarm on the CE is correlated to the Link Down alarm on the PE. 
–The traps and syslogs for the subinterface are correlated to the Link Down alarm on the PE. 
PE1
Ethernet
cloud
180438
Subinterface with 
IP interface configuredSubinterface with 
IP interface configured CE1 unreachable
PE1
Ethernet
clo
ud
180439
Subinterface with 
IP interface configuredSubinterface with 
IP interface configured Link is down CE1 unreachable 
						

							 
C-40
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
GRE Tunnel Down/Up
Generic routing encapsulation (GRE) is a tunneling protocol that encapsulates a variety of network layer 
packets inside IP tunneling packets, creating a virtual point-to-point link to devices at remote points over 
an IP network. It is used on the Internet to secure VPNs. GRE encapsulates the entire original packet 
with a standard IP header and GRE header before the IPsec process. GRE can carry multicast and 
broadcast traffic, making it possible to configure a routing protocol for virtual GRE tunnels. The routing 
protocol detects loss of connectivity and reroutes packets to the backup GRE tunnel, thus providing high 
resiliency.
GRE is stateless, meaning that the tunnel endpoints do not monitor the state or availability of other 
tunnel endpoints. This feature helps service providers support IP tunnels for clients who do not know the 
service provider’s internal tunneling architecture. It gives clients the flexibility of reconfiguring their 
IP architectures without worrying about connectivity.
GRE Tunnel Down/Up Alarm
When a GRE tunnel link exists, if the status of the IP interface of the GRE tunnel edge changes to down, 
a GRE Tunnel Down alarm is created. The IP Interface Status Down alarms of both sides of the link 
correlate to the GRE Tunnel Down alarm. The GRE Tunnel Down alarm initiates an IP-based flow 
toward the GRE destination. If an alarm is found during the flow, it correlates to it. 
NoteThe GRE Tunnel Down alarm is supported only on GRE tunnels that are configured with keepalive. If 
keepalive is configured on the GRE tunnel edge and a failure occurs in the GRE tunnel link, both 
IP interfaces of the GRE tunnel move to the Down state. If keepalive is not configured on the GRE tunnel 
edge, the GRE Tunnel Down alarm might not be generated because the alarm is generated arbitrarily 
from one of the tunnel devices when the IP interface changes to the Down state. 
When a failure occurs, the GRE tunnel link is marked orange. When the IP interface comes back up, a 
fixing alarm is sent, and the link is marked green. The GRE Tunnel Down alarm is cleared by a 
corresponding GRE Tunnel Up alarm.
GRE Tunnel Down Correlation Example 1
Figure C-41 illustrates an example of a GRE Tunnel Down correlation for a single GRE tunnel. 
In this example: 
Router 1 (R1) is connected to Router 3 (R3) through physical link L1. 
Router 3 is connected to Router 2 through physical link L2. 
Router 1 is connected to Router 2 through a GRE tunnel. 
						

							 
C-41
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
Figure C-41 GRE Tunnel Down Example 1 (Single GRE Tunnel)
When the link down occurs on L2, a Link Down alarm appears. A GRE Tunnel Down alarm is issued as 
the IP interfaces of the tunnel edge devices go down. The Interface Status Down alarms correlate to the 
GRE Tunnel Down alarm. The GRE Tunnel Down alarm correlates to the Link Down alarm.
The system provides the following report:
Root cause—[Link Down: L2 Router 2 < > Router 3]
Correlated events:
[GRE Tunnel Down, Router1:tunnel < > Router 2:tunnel]
–[Interface Status Down, Router 1:tunnel]
–[Interface Status Down, Router 2:tunnel]
GRE Tunnel Down Correlation Example 2
This example provides a real-world scenario in which multiple GRE tunnels cross through a physical 
link. When this link is shut down by an administrator, many alarms are generated. All of these alarms 
are correlated to the root cause ticket, Link Down Due to Admin Down ticket, as illustrated in 
Figure C-42.
Figure C-42 GRE Tunnel Down Example 2 (Multiple GRE Tunnels)
 GRE tunnel  GRE tunnel
Physical links
L1
L2 R1
R2R3
183047 
						

							 
C-42
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
Figure C-43 shows the Correlation tab of the Ticket Properties dialog box that displays all the alarms 
that are correlated to the ticket, including the correlation for each GRE tunnel and its interface status. 
Figure C-43 Alarm Correlation to GRE Tunnel Down Ticket 
As illustrated, the system provides the following report:
Root cause—Link Down Due to Admin Down
Correlated events:
[GRE Tunnel Down, ME-6524AGRE:Tunnel2 < > ME-6524B GRE:Tunnel2]
–[Interface Status Down, ME-6524A IP:Tunnel2]
–[Interface Status Down, ME-6524B IP:Tunnel2]
[GRE Tunnel Down, ME-6524AGRE:Tunnel3 < > ME-6524B GRE:Tunnel3]
–[Interface Status Down, ME-6524A IP:Tunnel3]
–[Interface Status Down, ME-6524B IP:Tunnel3]
and so on.
Link down due to admin downME-6524A#:GigabitEthernet1/...
ME-6524A IP:GigabitEthernet1/25
ME-6524B IP:GigabitEthernet1/25
Event Correlation Hierarchy Location
Interface status  down
Interface status  down
GRE tunnel downME-6524A GRE: Tunnel2ME-...
ME-6524A IP: Tunnel2
ME-6524B IP: Tunnel2 Interface status  down
Interface status  down
GRE tunnel downME-6524A GRE: Tunnel3ME-...
370854
ME-6524A IP: Tunnel3
ME-6524B IP: Tunnel3 Interface status  down
Interface status  down
GRE tunnel downME-6524A GRE: Tunnel9ME-...
ME-6524A IP: Tunnel9
ME-6524B IP: Tunnel9 Interface status  down
Interface status  down
GRE tunnel down
ME-6524A GRE: Tunnel6ME-...
ME-6524A IP: Tunnel6
ME-6524B IP: Tunnel6 Interface status  down
Interface status  down
GRE tunnel down
ME-6524A GRE: Tunnel7ME-...
ME-6524A IP: Tunnel7
ME-6524B IP: Tunnel7 Interface status  down
Interface status  down 
						

							 
C-43
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
Q-in-Q Subinterface Down Correlation Scenarios
Q-in-Q technology refers to the nesting of a VLAN header in an Ethernet frame in an already existing 
VLAN header. Both VLAN headers must be of the type 802.1Q. When one VLAN header is nested 
within another VLAN header, they are often referred to as stacked VLANs. 
A subinterface is a logical division of traffic on an interface, such as multiple subnets across one physical 
interface. A subinterface name is represented as an extension to an interface name using dot notation, 
such as Interface Gigabit Ethernet 0/1/2/3.10. In this example, the main interface name is Gigabit 
Ethernet 0/1/2/3 and the subinterface is 10.
Q-in-Q Subinterface Down Correlation Example 1
Figure C-44 shows an example of devices connected via a stacked VLAN.
Figure C-44 Q-in-Q Subinterface Down Example 1
In this example: 
A physical link (Gi0/3 < > Gi4/3) is established between 7201-P1 and 6504E-PE3.
On device 7201-P1 on Gi0/3, a subinterface (Gi0/3.100) is configured for IEEE 802.1Q 
encapsulation.
A stacked VLAN is created across the link between 7201-P1 and 6504-PE3.
When the physical link between the interfaces is shut down, the following are generated:
Link Down alarm on the interface.
Subinterface Down alarm on Gi03/.100. 
Subinterface Down syslogs.
Link Down syslogs (LINK-3-UPDOWN).
Related faults.
The following correlation information is provided:
The root cause is the Link Down alarm. 
The Subinterface Down alarm is correlated to the Link Down alarm. 
The subinterface syslogs are correlated to the Subinterface Down alarm.
The syslogs and other related faults are correlated to the Link Down Alarm.
Gi0/3 Gi4/3 Fa0/0 7210-P1
10.56.101.1266504E-PE3
10.56.101.133
195071 
						

							 
C-44
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
Q-in-Q Subinterface Down Correlation Example 2
In this example, using the devices in Figure C-44:
On device 7201-P1 on Gi0/3, the following subinterfaces are configured: 
–Gi0/3.100
–Gi0/3.101
A local pseudowire tunnel is configured and links Gi0/3.100 with Gi0/3.101 for local switching. 
When the Gi0/3.100 subinterface is shut down by the administrator, the following are generated:
Subinterface Down alarm of the type Subinterface Admin Down.
Subinterface Down syslogs.
Local Switching Down.
Related faults.
The Subinterface Admin Down event does not search for the root cause through the correlation 
mechanism. 
Q-in-Q Subinterface Down Correlation Example 3
Figure C-45 shows an example of devices connected via a pseudowire tunnel configured on 
subinterfaces.
Figure C-45 Q-in-Q Subinterface Down Example 3
In this example: 
On device 7201-P1 on Gi0/3, a subinterface (Gi0/3.100) is configured for IEEE 802.1Q 
encapsulation.
The subinterface (Gi0/3.100) is connected to a pseudowire tunnel. 
When the Gi0/3.100 subinterface is shut down by the administrator, the following are generated:
Subinterface Down alarm of the type Subinterface Admin Down.
Subinterface Down syslogs.
Pseudowire Tunnel Down.
Related faults.
The Subinterface Admin Down event does not search for the root cause through the correlation 
mechanism. 
Gi0/3 Gi4/3 Fa0/0 7210-P1
10.56.101.1266504E-PE3
10.56.101.133
195072PW 
						

							 
C-45
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Correlation Scenarios
VSI Down Correlation Scenarios
Virtual Private LAN Service (VPLS) is a type of Layer 2 VPN that provides Ethernet-based 
multipoint-to-multipoint communication over MPLS networks. It allows geographically dispersed sites 
to share an Ethernet broadcast domain by connecting sites through pseudowires. Emulating the function 
of a LAN switch or bridge, VPLS connects the different customer LAN segments to create a 
single-bridged Ethernet LAN. Virtual switching instances (VSIs, also known as virtual forwarding 
instances, or VFIs), are the main component in the PE router that constructs the logical bridge. All VSIs 
that build a provider logical bridge are connected with MPLS pseudowires. 
VSI Down Correlation Example 1
Figure C-46 shows an example of devices with VSI connected through pseudowires.
Figure C-46 VSI Down Example 1
In this example: 
A VSI is configured on PE1.
The VSI uses pseudowire 1 (PW 1) and PW 2.
The VSI is shut down. The expected alarm hierarchy is:
VSI Down >
–Pseudowire tunnel 1 down > Pseudowire tunnel 1 syslogs
–Pseudowire tunnel 2 down > Pseudowire tunnel 2 syslogs
–Other related faults
NoteFor more information about the VSI Down alarm.
P3
10.56.101.124
P2
10.56.101.125 10.56.101.126P3
10.56.101.133
P4
10.56.101.132 ementGi0/0 Fa0/0
Gi0/1 POS 3/3/0
.13 172.31.255.12/30 .14.6 172.31.255.4/30 .5
.54 172.31.255.52/30 .53
Bundle 1 IMA
.42 172.31.255.40/30 .41
.50 172.31.255.48/30 .49 .46 172.31.255.44/30 .45
.9 172.31.255.8/30 .10 POS 1/1Gi0/1Fa0/0
Gi0/3
Gi0/3Gi4/3
Ten 2/1 Ten 2/
Ten 3/1 Ten 3/
Gi2/3 Gi0/1PE1
101.137 
						

							 
C-46
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  Root Cause Across Frame Relay, ATM, or Ethernet Clouds
VSI Down Correlation Example 2
In this example, using the devices in Figure C-46, the VSI attachment circuit (the interface VLAN) is 
shut down. The expected alarm hierarchy is the same as in Example 1:
VSI Down >
–Pseudowire tunnel 1 down > Pseudowire tunnel 1 syslogs
–Pseudowire tunnel 2 down > Pseudowire tunnel 2 syslogs
–Other related faults
However, because Prime Network does not model the attachment circuit state, the VNE cannot issue an 
alarm when the interface VLAN state changes to Down. Therefore, the VSI Down alarm is the highest 
root cause. 
VSI Down Correlation Example 3
In this example, using the devices in Figure C-46: 
A VSI is configured on PE4.
The VSI uses the pseudowire tunnels 2 and 3.
The VSI is connected to bridge 100; the binding to the VSI is done on interface VLAN 100. 
Two physical interfaces, Gi1/1 and Gi1/2, are associated to bridge 100.
Interfaces Gi1/1 and Gi1/2 are shut down.
NoteThe attachment circuit connected to bridge 100 has two physical interfaces. As long as one interface is 
up, bridge 100 will be up. Bridge 100 will go down when the last interface switches from up to down.
The expected alarm hierarchy:
Port Down/Link Down due to administrative down (Gi1/2) > Port Down/Link Down syslogs 
VSI Down > 
–Pseudowire tunnel 3 down > Pseudowire tunnel 1 syslogs
–Pseudowire tunnel 2 down > Pseudowire tunnel 2 syslogs
Other related faults
Root Cause Across Frame Relay, ATM, or Ethernet Clouds 
When a Layer 3 or Layer 2 event (for example, reachability problem, neighbor change, Frame Relay 
DLCI down, ATM PVC down) occurs, it triggers a flow along the physical and logical path modeled on 
the VNEs. This is done in order to correlate to the actual root cause of this fault. If the flow passes over 
a cloud along the path flow, it marks it as a potential root cause for the fault. If there is no other root 
cause found on the managed devices, then the cloud becomes the root cause. A ticket is then issued and 
the original event correlates to it. 
						

							 
C-47
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  MPLS Fault Scenarios
Cloud Problem Alarm and Correlation Example 
For some events, when there is no root cause found, a special Cloud Problem alarm is created. These 
events are then correlated to the alarm. If several events trigger the creation of a Cloud Problem alarm, 
one alarm instance is created and all events correlate to it. 
In the example in Figure C-47, two devices that have OSPF configured are connected through a cloud. 
A malfunction occurs inside the unmanaged network that causes the OPSF Neighbor Down alarm to be 
generated. In this case, the OSPF Neighbor Down alarm is correlated to the Cloud Problem alarm.
Figure C-47 Cloud Correlation Example
On the PE1 device, the OSPF Neighbor Down alarm was received, and no root cause was detected in any 
of the managed devices. A disconnected link inside the unmanaged network caused the OSPF Neighbor 
Down alarm. The Cloud Problem service alarm is generated, and the OSPF Neighbor Down alarm on the 
PE1 is correlated to the Cloud Problem alarm.
MPLS Fault Scenarios 
The following fault scenarios trigger automatic impact analysis calculation:
Link Down Scenario, page C-48
Link Overutilized/Data Loss Scenario, page C-48
BGP Neighbor Loss Scenario, page C-49
Broken LSP Discovered Scenario, page C-51
MPLS TE Tunnel Down Scenario, page C-51
Pseudowire MPLS Tunnel Down Scenario, page C-51
The following criteria are used in the tables that are described in the sections that follow:
Impact Calculation—Describes the way in which the affected parties are calculated by system flows.
Reported Affected Severity—Describes the kind of severity generated by the alarm.
NoteProactive impact analysis is performed only for links.
ISDN
BackupFrame Relay
CE1
60.60.60.4PE1
80.80.80.69
Point-to-point
interface
State down Interface Serial
1/0.500
point-to-point
102.0.0.2Interface Serial
1/0.100
point-to-point
102.0.0.2Routing Protocol
neighbor down syslog
180456 
						

							 
C-48
Cisco Prime Network 4.3.2 User Guide
Appendix C      Event Correlation Examples
  MPLS Fault Scenarios
Link Down Scenario 
Ta b l e C - 4 lists the impact calculations and reported affected severities for a link down fault scenario.
Link Overutilized/Data Loss Scenario 
Ta b l e C - 5 lists the impacted calculations and reported affected severities for a link overutilized/data loss 
fault scenario.
Table C-4 Link Down Scenario
Impact and Affected Severity Description
Impact calculation Initiates an affected flow to determine the affected parties using the 
LSPs traversing the link.
Reported affected severity
The Link Down alarm creates a series of affected severity updates 
over time. These updates are added to the previous updates in the 
Oracle database. In this case, the system provides the following 
reports:
–The first link down report shows “X< >Y” as Potentially 
Affected. 
–Over time, the VNE identifies that this service is Real 
Affected or Recovered and generates an updated report (this 
applies only to cross-MPLS networks). 
–The Affected Parties tab of the Ticket Properties dialog box 
displays the latest severity, for example, Real Affected. 
–The Affected Parties Destination Properties dialog box 
displays both reported severities.
This functionality is supported for Link Down only.
Table C-5 Link Overutilized/Data Loss Scenario
Impact and Affected Severity Description
Impact calculation Initiates an affected flow to determine the affected parties using the 
LSPs traversing the link. 
Reported affected severity Only reports on potentially affected.