Cisco Prime Nerk 43 User Guide
Have a look at the manual Cisco Prime Nerk 43 User Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 53 Cisco manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
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.