Cisco Prime Nerk 43 User Guide

							  
10-11
Cisco Prime Network 4.3.2 User Guide
Chapter 10      How Prime Network Handles Incoming Events
  How Prime Network Calculates and Reports Affected Parties (Impact Analysis)
To check a Trap, Syslog, or Service event’s default is-ticketable setting, see Checking An Event’s 
Registry Settings, page 10-15.
How Prime Network Calculates and Reports Affected Parties 
(Impact Analysis)
Prime Network performs impact analysis for some Service events. This means Prime Network 
automatically calculates any service resources (pairs) that are affected by a ticket, or the specific events 
in a ticket. These service pairs are called affected parties and are listed in the tickets Affected Parties tab.
Because tickets can be quite complex—for example, a ticket can include both discrete events and events 
that have been grouped into event sequences (alarms)—Prime Network provides several ways to view 
affected parties: 
To see the parties affected by a single event, check the event’s Affected Parties tab.
To see the parties affected by all of the events in an event sequence (alarm), check the alarm’s 
Affected Parties tab.
To see the parties affected by all event sequences (alarms) in a ticket, check the ticket’s Affected 
Parties tab.
These topics explain the information that is displayed in the Affected Parties tab, and how 
Prime Network calculates the information:
Impact Analysis and Affected Status: Potential, Real, Recovered, page 10-11
Accumulating the Affected Parties in an Event Sequence (Alarms), page 10-12
Accumulating the Affected Parties in the Correlation Tree, page 10-12
Impact Analysis and Affected Status: Potential, Real, Recovered
For each resource pair, the Affected Parties tab will displays an affected status, which indicates the 
degree of certainty that the pair will be impacted. Affected status can be one of the following:
Potential—The service might be affected (for example, rerouting may prevent any problem).
Real—The service is affected.
Recovered—A service that was potentially affected has recovered. This only indicates that an 
alternate route was establish (not the service level quality).
N/A—Not Applicable.
NoteIf any entries begin with the word Misconfigured, it means the flow has stopped unexpectedly between 
the source and destination points. An unexpected termination point can be a routing entity, bridge, or VC 
switching entity. Because the link does not terminate as expected, the link is not actually impacted. 
Check the configuration and status of the affected termination points to make sure there are no errors. 
Using the example from How Prime Network Calculates and Reports Affected Parties (Impact 
Analysis), page 10-11, assume that X and Y are the OIDs of edge points in the network, and a service is 
running between them. Link (B) Down and BGP Neighbor Loss report on the pair X < > Y as affected: 
Link (B) Down reports on X < > Y as potentially affected.
BGP Neighbor Loss reports on X < > Y as real affected. 
						

							  
10-12
Cisco Prime Network 4.3.2 User Guide
Chapter 10      How Prime Network Handles Incoming Events
  Clearing, Archiving, and Purging and the Oracle Database
The affected severity priorities are:
Real—Priority 1
Recovered—Priority 2
Potential—Priority 3
Card Out reports on X < > Y as real, affected only once.This information is embedded in the ticket along 
with all of the correlated events. For a list of Service events for which Prime Network performs impact 
analysis, refer to the Cisco Prime Network 4.3.2 Supported Cisco VNEs.
In some cases (such as the link-down scenario in MPLS networks), Prime Network updates the affected 
status of the same event sequence over time because it cannot determine the fault’s effect on the network 
until the network has converged. For example, a Link Down alarm creates a series of affected severity 
updates over time. These updates are added to the previous updates in the system database. In this case, 
the system provides the following reports: 
The first report of a link down reports on X < > Y as potentially affected. 
Over time, the VNE identifies that this service is real affected or recovered, and generates an 
updated report. 
The Affected Parties tab of the Ticket Properties dialog box displays the latest severity as real 
affected. 
The Affected Parties Destination Properties dialog box displays both reported severities. 
Accumulating the Affected Parties in an Event Sequence (Alarms)
Event sequences (alarms) can be nested. If two events form part of the same event sequence in a specific 
alarm, the recurring affected pairs are displayed only once in the Affected Parties tab. If different 
affected severities are reported for the same pair, the pair is marked with the severity that was reported 
by the latest event, according to the time stamp. 
Accumulating the Affected Parties in the Correlation Tree 
If two or more event sequences that are part of the same correlation tree report on the same affected pair 
of edge points but have different affected severities, the affected pairs are displayed only once in the 
Affected Parties tab. If different affected severities are reported for the same pair, the pair is marked with 
the highest severity. 
Clearing, Archiving, and Purging and the Oracle Database
NoteThe Event Archive is no longer used as of Prime Network 4.1. For more information, see the Cisco Prime 
Network 4.3.2 Administrator Guide.
The Oracle database contains information about all ticket, standard, and upgraded events. Standard 
events are events from which a VNE cannot extract adequate information. As a result, the VNE only 
performs basic parsing and then archives the events in the database. Upgraded event are events that a 
VNE recognizes, parses, and attempts to correlate to other events (see Standard and Upgraded Events, 
page 10-4). If Prime Network is configured to handle notifications from unmanaged devices, those 
events are also stored in the Oracle database. 
						

							  
10-13
Cisco Prime Network 4.3.2 User Guide
Chapter 10      How Prime Network Handles Incoming Events
  Clearing, Archiving, and Purging and the Oracle Database
When a ticket is cleared, that means its root cause and all of its associated events have been cleared, and 
the problem no longer exists. A cleared ticket is still considered active because new events can still 
associate to it, which would cause the ticket to be reopened. Finally, if a ticket is unchanged for 1 hour, 
it is archived. Prime Network will not perform any more actions on it, and the ticket is considered 
inactive. Archived tickets and events are eventually purged from the database.
Viewing Archived Events in the Vision Client
In general, a limited number of archived events can be viewed from the Vision client— in the device 
inventory view under the Network Events tab, and in a map or list view under the Latest Events tab. 
You can see archived events in these cases:
An event is associated with a ticket that was recently archived. Cleared, unchanged tickets are 
archived and removed from the Tickets tab after 1 hour. But the Vision client displays events from 
the past 6 hours, so the ticket’s events may still be available. 
An event is a standard event, which means a VNE can only perform basic parsing of the event. 
Standard events are immediately archived. (Standard events only appear in the Latest Events tab if 
this has been enabled from the Administration client. Because there can be 3 times as many standard 
events as upgraded events, they are not shown by default to protect system performance.) 
An event is not ticketable and did not correlate to any existing events. These events are also archived.
These topics explain in more depth how ticket and event information is cleared, archived, and purged in 
Prime Network:
How Events and Tickets are Cleared and Archived, page 10-13
How Events and Tickets are Purged from the Oracle Database, page 10-14
How Events and Tickets are Cleared and Archived
When a ticket is cleared, that means its root cause and all of its associated events have cleared. Because 
a new event could still associate to the ticket (for example, if the root cause recurs), a cleared ticket is 
still considered active. When a ticket is archived, the ticket and its associated events are moved from an 
active database partition to an archive database partition and the ticket is considered inactive. Archived 
tickets are generally removed from the clients but can be retrieved using the Events client Find in 
Database tool (see Finding Archived Tickets, Service Events, Syslogs, and Traps, page 12-12).
Clearing Fault Data
When an event, alarm, or ticket is cleared, it means it is no longer a problem. For a ticket, this means its 
root cause and all of its associated events have cleared. When an item is cleared, its severity icon changes 
to a green check mark, providing a visual indication that the problem has been addressed. 
(Acknowledging an event is different. Acknowledging indicates that someone is aware of the issue. 
Acknowledging does not change the severity icon; it just changes its Acknowledged value to Tr u e.) 
Because a new event could still associate to the ticket (for example, if the root cause recurs), a cleared 
ticket is still considered active. 
Tickets can be manually cleared from the Vision client or the Events client by right-clicking the ticket 
and choosing Clear. The ticket description changes to Cleared due to Force Clear and all events are 
marked as acknowledged. The ticket’s Audit tab will display the name of the user who cleared the ticket. 
Once a ticket is cleared, you can manually archive it and remove it from the client display by 
right-clicking a ticket and choosing Remove. To perform both operations at the same time, choose Clear 
and Remove. But keep the following in mind: 
						

							  
10-14
Cisco Prime Network 4.3.2 User Guide
Chapter 10      How Prime Network Handles Incoming Events
  Clearing, Archiving, and Purging and the Oracle Database
The remove operation cannot be reversed. After you remove a ticket, it can only be viewed from the 
Events client using the Find in Database tool.
If any of the ticket’s associated events recur, Prime Network will open a new ticket instead of 
reopening the ticket your removed. 
Tickets are also auto-cleared by Prime Network. Every 60 seconds, a special mechanism checks to see 
if uncleared tickets can be cleared. The mechanism looks for the following:
If the ticket’s events are cleared, or
If the tickets root cause is cleared, and its other events are configured for auto-clearing (the event’s 
auto-cleared registry key is set to true or false). To check a Trap, Syslog, or Service event’s default 
auto-cleared setting, see Checking An Event’s Registry Settings, page 10-15.
If either of these cases is true and the ticket has not been modified in the last 4 minutes, Prime Network 
clears the ticket. When an event is auto-cleared, the Vision client displays an event description with Auto 
Cleared in the text—for example, Auto Cleared - Link Down due to Admin Down. 
Administrators can also customize the following, which are disabled by default (refer to the Cisco Prime 
Network 4.3.2 Administrator Guide):
Clear a ticket based on its severity and the number of days since it was last modified. (In this case, 
the ticket description would say Cleared due to time expiration.)
Adjust when a cleared ticket is locked (no new events can associate to it).
Archiving Fault Data
A ticket is archived if no new events are associated to it for 1 hour (by default). When a ticket or event 
is archived, it means the ticket or event is no longer active. Archived data is moved to an archive partition 
in the Fault Database. Some data is immediately archived in the Fault Database—standard events, new 
alarms and upgraded events that are not ticketable, and (if enabled) events from unmanaged devices. 
(Standard and upgraded events are described in.)
An auto-archiving mechanism runs every 60 seconds and archives tickets if they are unchanged for 
1 hour. This protects system performance and stability. Cleared and uncleared tickets may be also 
archived if their number or size could adversely affect system stability. This table describes the 
auto-archive criteria:
How Events and Tickets are Purged from the Oracle Database
By default, Prime Network purges (deletes) event data from the Oracle database after 14 days—that is, 
14 days from the event’s creation time. This purge setting is configured in the Administration client. 
However, events that are associated with uncleared tickets are never purged, regardless of their age. Auto-Archive Criteria Ticket is archived if:
Age of ticket Archive cleared ticket if no new events were associated to it in the past 
1 hour.
Size of ticket Archive a ticket that has more than 150 events associated with one of its 
alarms. (Prime Network also generates a System event 15 minutes before 
it archives the ticket.)
Prime Network found more than 1500 large tickets. (Prime Network also 
generates a System event as it approaches this number.)
Total of tickets in Oracle 
database active partitionThe total number of tickets exceeds 16,000. 
						

							  
10-15
Cisco Prime Network 4.3.2 User Guide
Chapter 10      How Prime Network Handles Incoming Events
  Checking An Event’s Registry Settings
For more information on managing the Prime Network database, refer to the Cisco Prime Network 4.3.2 
Administrator Guide.
Checking An Event’s Registry Settings
The following documents list the default registry settings that control how Prime Network processes 
incoming events. All of these documents are available from Cisco.com:
Document on Cisco.com Provides registry settings for:
Cisco Prime Network 
Supported Service AlarmsNotifications that are generated by Prime Network; normally you will 
find the information you need in this document.
Cisco Prime Network 
Supported SyslogsSyslogs received from devices (IOS syslogs, ACE syslogs, Nexus syslogs, 
ASR syslogs, UCS syslogs, and so forth) and handled by Prime Network.
Cisco Prime Network 
Supported TrapsSNMPv1, v2, and v3 traps received from devices (ASR traps, IOS, traps, 
MIB 2 traps, Nexus traps, CPT traps, and so forth) and handled by 
Prime Network. 
						

							  
10-16
Cisco Prime Network 4.3.2 User Guide
Chapter 10      How Prime Network Handles Incoming Events
  Checking An Event’s Registry Settings 
						

							CH A P T E R
  
11-1
Cisco Prime Network 4.3.2 User Guide
11
Managing Tickets with the Vision Client
Tickets represent attention-worthy fault scenarios that can consist of one event or a complete hierarchy 
of correlated events that all relate to the same fault. The Vision client provides extensive information on 
tickets and other network events of interest. These topics explain how to view and manage tickets and 
network events using the Vision client:
Ways You Can View Tickets and Events, page 11-1
Interpreting the Badges and Colors of an NE, page 11-9
Letting Others Know You Are Working on the Ticket (Acknowledging a Ticket), page 11-12
Troubleshooting a Ticket, page 11-12
Letting Others Know What is Being Done to Fix a Ticket, page 11-25
Letting Others Know the Problem Was Fixed (Clearing a Ticket), page 11-25
Removing a Ticket from the Vision Client Display (Archiving a Ticket), page 11-26
Changing the Vision Client Behavior, page 11-27
Ways You Can View Tickets and Events
Tickets represent attention-worthy fault scenarios. Specifically, tickets are business objects that are 
created by Prime Network. A ticket can consist of one event, an event sequence (alarm), or a hierarchy 
of events and alarms that all correlate to a single root cause. A ticket uses the name of its root cause 
event—for example, a ticket with a Card Out root cause event would be named a Card Out ticket. When 
Prime Network receives an event—external events like traps and syslogs, or generated events that Prime 
Network detects when it polls the network—it verifies whether the new event can be correlated to 
(caused by) any existing alarms. If it can be correlated to an existing alarm and ticket, the alarm and 
ticket information is updated. If not, and the event is ticketable, Prime Network creates a new ticket. A 
ticket’s severity is equal to the highest-severity event associated with the root cause. A complete 
explanation of how Prime Network handles incoming events is provided in How Prime Network 
Correlates Incoming Events, page 10-4.
When you open a map, the tickets that apply to devices in the map are displayed at the bottom of the 
Vision client window under a Tickets tab. In addition, a Latest Events tab displays the most recent 
incoming events for devices in the map. For an example of this view, see Viewing Tickets and Latest 
Events for All Devices in a Map, page 11-3. 
When you double-click a device in a map, the Vision client opens the device inventory view, and the view 
changes to display tickets only for the device. Next to the Tickets tab is a Network Events tab (for device 
Trap, Syslog, and Service events) and a Provisioning events tab (for changes made to the device). For an  
						

							  
11-2
Cisco Prime Network 4.3.2 User Guide
Chapter 11      Managing Tickets with the Vision Client
  Ways You Can View Tickets and Events
example of this view, see Viewing Tickets and Events for a Specific Device, page 11-4.
To view a ticket, double-click it, and the Vision client provides extensive details about the ticket. A series 
of tabs provide the ticket history, root cause and events correlated to the root cause, notes attached to the 
ticket, number of devices affected by the ticket, and more. 
The following table provides some basic ways you can view tickets (and events), depending on what you 
are looking for. You can only view a device’s tickets if you have permission to view the device.
Once a ticket is cleared (its root cause and all of the associated events are cleared), if no new events are 
associated to it for 1 hour, it is archived, which means it is no longer considered active. Only a subset of 
archived events can be viewed from the Vision client as described in these topics:
Viewing Tickets and Latest Events for All Devices in a Map, page 11-3
Viewing Tickets and Events for a Specific Device, page 11-4
For more information on archiving, see Clearing, Archiving, and Purging and the Oracle Database, 
page 10-12. For: To view: Use this method in the Vision client:
All devices in a 
mapTickets 
Syslogs and traps 
Service events generated by 
Prime NetworkOpen a map or list view in the Vision client and 
check the tabs at the bottom of the window. 
See Viewing Tickets and Latest Events for All 
Devices in a Map, page 11-3.
The above information filtered 
according to location, 
description, last modification 
time, and many other variablesOpen a map in Vision client and, in the tickets 
table, create a filter.
See The following table describes how regular 
and resynced events detail are displayed in 
Prime Network:, page 11-6.
A specific device 
and its 
componentsTickets
Incoming traps and syslogs, 
and Service events generated 
by Prime Network (Network 
events)
Changes to the device 
(Provisioning events)Double-click a device in Vision client and check 
the tabs at the bottom of the inventory window.
See Viewing Tickets and Events for a Specific 
Device, page 11-4. 
						

							  
11-3
Cisco Prime Network 4.3.2 User Guide
Chapter 11      Managing Tickets with the Vision Client
  Ways You Can View Tickets and Events
Viewing Tickets and Latest Events for All Devices in a Map
When you open a map, Prime Network displays a view similar to Figure 11-1. Note the Tickets tab and 
Latest Events tab at the bottom of the window (these tabs are also displayed in the List view). 
Figure 11-1 Events Tabs for NEs in a Map
By default, the Vision client displays tickets and events from the past 6 hours. The Tickets tab lists the 
tickets for all devices in the map. You can find specific tickets using the robust ticket filter mechanism; 
see The following table describes how regular and resynced events detail are displayed in Prime 
Network:, page 11-6.
Tickets are listed according to their modification time, with the most recently modified ticket listed first. 
Events are stored in the database in Greenwich Mean Time (GMT) and are converted to match the time 
zone of the client location. The ticket table provides this information:
Ticket Pane Column Description
Location Provides a hyperlink to the entity that triggered the root-cause alarm. If you do 
not have permission to view the entity, the Vision client will not provide the 
hyperlink.
Root Event Time When the root-cause event was detected.
Creation Time When the ticket was created.
Open Alarms Number of alarms that are associated with the ticket that are not cleared. For 
example, 3/4 means three of the ticket’s four associated alarms are still not 
cleared. 
						

							  
11-4
Cisco Prime Network 4.3.2 User Guide
Chapter 11      Managing Tickets with the Vision Client
  Ways You Can View Tickets and Events
The Latest Events tab displays upgraded events (traps, syslogs, and Service events generated by Prime 
Network) as they occur. If an event is associated with a ticket, a hyperlink to the ticket properties is 
provided. If enabled (from the Administration client), the tab may also include standard events, which 
are events for which Prime Network only performs basic parsing; they are not processed for correlation. 
The Detection Type column tells you what kind of event it is (trap, syslog, and so forth). For information 
on those kinds of events, see Viewing Network Events (Service, Trap, and Syslog Events), page 12-13.
Viewing Tickets and Events for a Specific Device
To display the tickets related to a device and its components, double-click a device to open its inventory 
window, as shown in Figure 11-2. As you expand the inventory, colors and badges indicate any problems. 
The tickets listed at the bottom of the window changes as you choose items from the navigation tree. For 
example, to view all of the device’s tickets, select the top-level device entry. If you select Physical 
Inventory, the Vision client only lists the tickets for any NEs in the physical inventory.
The Vision client also displays a Tickets, Network Events, and Provisioning Events tab at the bottom of 
the inventory window. Provisioning events reflect any device configuration operations or transactions 
(activation workflows) that have been executed on the device. The Network Events tab shows all traps, 
syslogs, and Service events for the device. For information on these other event types, see Viewing All 
Event Types in Prime Network, page 12-1.
In some cases, if an internal Prime Network component is stopped, or a device Prime Network is 
managing becomes unreachable, Prime Network will perform a resync when the component starts (or 
the device becomes reachable). The resync will capture the events that occurred during the down time 
and will include them in an Informational ticket. This behavior is currently supported for specific devices 
(for example, the Cisco ASR 5000 series running StarOS). For more information about the correlation 
and View/Access property for Resync alarm feature see, Viewing Resync Alarm Details in Prime 
Network, page 11-5Acknowledged Whether someone is aware of the ticket.
Yes—Ticket has been acknowledged. The user name of the person who 
acknowledged it is also listed.
No—The ticket has not been acknowledged, or it was acknowledged then 
de-acknowledged.
Modified—The ticket was acknowledged, but a new event has been 
associated to it.
Double-click the ticket and check the User Audit tab for a history of who 
acknowledged/deacknowledge a ticket, and when these actions occurred.
Nature Indicates whether the event is a type that can or cannot clear itself.
ADAC (Automatically Detected Automatically Cleared)—Clearing is 
automatically detected and performed by the system (for example, Link 
Down). 
ADMC (Automatically Detected Manually Cleared)—Clearing requires 
manual intervention (for example, a fatal error). Ticket Pane Column Description