-
Cisco Unified Communications Manager Managed Services Guide, Release 7.1
-
Preface
-
Overview
-
New and Changed Information
-
Managing and Monitoring the Health of Cisco Unified Communications Manager Systems
-
Simple Network Management Protocol
-
Cisco Unified Real-Time Monitoring Tool Tracing, PerfMon Counters, and Alerts
-
Cisco Unified Serviceability Alarms and CiscoLog Messages
-
Cisco Management Information Base
-
Industry-Standard Management Information Base
-
Vendor-Specific Management Information Base
-
Index
-
Table Of Contents
Cisco Unified Serviceability Alarms and CiscoLog Messages
Cisco Unified Serviceability Alarms and CiscoLog Messages
Standard Syslog Server Implementations
Preconfigured System Alarm Notifications
LogPartitionHighWaterMarkExceeded
LogPartitionLowWaterMarkExceeded
LowActivePartitionAvailableDiskSpace
LowInactivePartitionAvailableDiskSpace
LowSwapPartitionAvailableDiskSpace
SparePartitionHighWaterMarkExceeded
SparePartitionLowWaterMarkExceeded
TotalProcessesAndThreadsExceededThreshold
Preconfigured CallManager Alarm Notifications
BeginThrottlingCallListBLFSubscriptions
LowAttendantConsoleServerHeartbeatRate
NumberOfRegisteredDevicesExceeded
NumberOfRegisteredGatewaysDecreased
NumberOfRegisteredGatewaysIncreased
NumberOfRegisteredMediaDevicesDecreased
NumberOfRegisteredMediaDevicesIncreased
NumberOfRegisteredPhonesDropped
HuntGroupControllerCreationError
ExcceptionInInitSDIConfiguration
TFTPServerListenSetSockOptFailed
CiscoDirSyncProcessFailToStart
ConferenceNoMoreResourcesAvailable
AnnunciatorNoMoreResourcesAvailable
CDRFileDeliveryFailureContinues
CDRAgentSendFileFailureContinues
kReadCfgUserLocaleEnterpriseSvcParm
kReadCfgANNListUnknownException
kChangeNotifyServiceCreationFailed
kChangeNotifyServiceGetEventFailed
kChangeNotifyServiceRestartFailed
kDeviceMgrExitEventCreationFailed
kDeviceMgrLockoutWithCallManager
kDeviceMgrOpenReceiveFailedOutOfStreams
kDeviceMgrRegisterKeepAliveResponseError
kDeviceMgrRegisterWithCallManagerError
kDeviceMgrSocketDrvNotifyEvtCreateFailed
kDeviceMgrSocketNotifyEventCreateFailed
kDeviceMgrStartTransmissionOutOfStreams
kFixedInputAddAudioCaptureDeviceFailed
kFixedInputAddG711AlawIpVmsRenderFailed
kFixedInputAddG711UlawIpVmsRenderFailed
kFixedInputAddG729IpVmsRenderFailed
kFixedInputAddMOHEncoderFailed
kFixedInputAddWideBandIpVmsRenderFailed
kFixedInputAudioCapMOHEncoderConnFailed
kFixedInputAudioCaptureCreateFailed
kFixedInputClassEnumeratorCreateFailed
kFixedInputCreateControlFailed
kFixedInputCreateSoundCardFailed
kFixedInputInitSoundCardFailed
kFixedInputCreateGraphManagerFailed
kFixedInputFindAudioCaptureDeviceFailed
kFixedInputGetEventNotificationFailed
kFixedInputGetG711AlawIpVmsRenderFailed
kFixedInputGetG711AlawIpVmsRendInfFailed
kFixedInputGetG711UlawIpVmsRenderFailed
kFixedInputGetG711UlawIpVmsRendInfFailed
kFixedInputGetG729IpVmsRenderFailed
kFixedInputGetG729IpVmsRendInfFailed
kFixedInputGetMediaControlFailed
kFixedInputGetMediaPositionFailed
kFixedInputGetMOHEncoderFailed
kFixedInputGetWideBandIpVmsRenderFailed
kFixedInputGetWideBandIpVmsRendInfFailed
kFixedInputMOHEncG711AlawRenderConnFail
kFixedInputMOHEncG711UlawRenderConnFail
kFixedInputMOHEncG729RenderConnFailed
kFixedInputMOHEncWidebandRenderConnFail
kFixedInputSetNotifyWindowFailed
kGetIpVmsRenderInterfaceFailed
kMOHMgrExitEventCreationFailed
kMOHMgrThreadCreateWindowExFailed
kMOHPlayStreamMediaControlObjectNull
kMOHRewindStreamMediaPositionObjectNull
kReadCfgCFBListUnknownException
kReadCfgMOHAudioSourceComException
kReadCfgMOHAudioSourceDblException
kReadCfgMOHAudioSourceUnknownException
kReadCfgEnterpriseComException
kReadCfgEnterpriseDblException
kReadCfgEnterpriseUnknownException
kReadCfgMOHListUnknownException
kReadCfgMOHServerUnknownException
kReadCfgMOHTFTIPAddressNotFound
kReadCfgMTPListUnknownException
kCtiProviderOpenInvalidUserNameSize
kCtiIncompatibleProtocolVersion
ErrorChangeNotifyClientTimeout
CiscoDirSyncProcessFailedRetry
CiscoDirSyncProcessFailedNoRetry
CiscoDirSyncProcessConnectionFailed
DirSyncSchedulerFailedToGetDBSchedules
DirSyncSchedulerInvalidEventReceived
DirSyncSchedulerFailedToRegisterDBEvents
DirSyncSchedulerEngineFailedToStart
CiscoDRFMasterAgentStartFailure
CiscoDRFLocalAgentStartFailure
CiscoDRFInternalProcessFailure
CiscoDRFMABackupComponentFailure
CiscoDRFMARestoreComponentFailure
CiscoDRFMABackupNodeDisconnect
CiscoDRFMARestoreNodeDisconnect
CiscoDRFBackupCancelInternalError
DirSyncSchedulerFailedToUpdateNextExecTime
LogPartitionLowWaterMarkExceeded
LogPartitionHighWaterMarkExceeded
SparePartitionLowWaterMarkExceeded
SparePartitionHighWaterMarkExceeded
ConfigThreadChangeNotifyServerInstanceFailed
ConfigThreadChangeNotifyServerSingleFailed
ConfigThreadChangeNotifyServerStartFailed
ConfigThreadUnknownExceptionCaught
ReadConfigurationUnknownException
ThreadPoolProxyUnknownException
MultipleSIPTrunksToSamePeerAndLocalPort
kCtiExistingCallNotifyArrayOverflow
kCtiLineCallInfoResArrayOverflow
kCtiProviderCloseHeartbeatTimeout
kCtiDeviceOpenFailAccessDenied
kCtiMaxDevicesPerProviderExceeded
DirSyncScheduledTaskTimeoutOccurred
TotalProcessesAndThreadsExceededThresholdStart
BeginThrottlingCallListBLFSubscriptions
EndThrottlingCallListBLFSubscriptions
CUCMTotalInitializationStateTime
kReadCfgIpTosMediaResourceToCmNotFound
kDeviceMgrMoreThan50SocketEvents
kDeviceMgrRegisterWithCallManager
kDeviceMgrUnregisterWithCallManager
kMOHMgrIsAudioSourceInUseThisIsNULL
kReadCfgMOHEnabledCodecsNotFound
CiscoDirSyncProcessStoppedManually
CiscoDirSyncProcessStoppedAuto
TotalProcessesAndThreadsExceededThresholdEnd
ConfigThreadReadConfigurationFailed
ConfigThreadCNCMGrpBuildFileFailed
ConfigThreadCNGrpBuildFileFailed
ConfigItAllReadConfigurationFailed
CNFFBuffWriteToFilefopenfailed
CNFFBuffWriteToFilefwritefailed
Removed Alarms in Cisco Unified Communications Manager Release 7.0(1)
Inactive Alarms in Cisco Unified Communications Manager Release 6.1 and Release 7.0(1)
Cisco Unified Serviceability Alarms and CiscoLog Messages
This chapter describes the Cisco Unified Serviceability alarms and error messages and CiscoLog message format. Network alarms tracked by Cisco Unified Serviceability for Cisco Unified Communications Manager generate the error messages.
Note
A History table lists Cisco Unified Serviceability error messages that have been added, changed, or removed beginning in Cisco Unified Communications Manager Release 7.0(1).
This chapter contains the following sections:
•
•
•
•
•
Cisco Unified Serviceability Alarms and CiscoLog Messages
Cisco Unified Serviceability alarms provide information on runtime status and the state of the system, so you can troubleshoot problems that are associated with your system. The alarm or error message information includes the application name, machine name, and recommended action and other critical information to help you troubleshoot.
You configure the alarm interface to send alarm information to multiple locations, and each location can have its own alarm event level (from debug to emergency). You can direct alarms to the Syslog Viewer (local syslog), SNMP traps, Syslog file (remote syslog), SDI trace log file, SDL trace log file (for Cisco Unified CM and CTIManager services only), or to all destinations.
You use the Trace and Log Central option in the Cisco Unified Real-Time Monitoring Tool (RTMT) to collect alarms that get sent to an SDI or SDL trace log file. To view the alarm information sent to the local syslog, use the SysLog Viewer in RTMT.
CiscoLog Format
CiscoLog, a specification for unified logging in Cisco software applications, gets used in the Cisco Unified RTMT. It defines the message format when messages are logged into file or by using the syslog protocol. The output that is provided by Cisco software applications gets used for auditing, fault-management, and troubleshooting of the services that are provided by these applications.
Be aware that CiscoLog message format is compatible with one of the message formats that is produced by Cisco IOS Release 12.3 by using the syslog protocol when Cisco IOS Software is configured with the following commands:
•
•
•
Note
The following topics are described in this section:
•
Log File and Syslog Outputs
When CiscoLog messages are written directly into a log file by an application, each message is on a separate line. The line separator should be a standard line separator used on a given platform. On Windows, the line separator must be the sequence of carriage return and line feed characters (ASCII decimal values 13 and 10; often designated as "\r\n" in programming languages). On Solaris and Linux, the line separator is a single line feed character (ASCII decimal value 10 and in programming languages typically "\n"). Two line separators must never appear one after another, for example, you cannot have "\r\n\r\n" on Windows, but "\r\n" is fine because these two characters are a single line separator.
In practical terms, this means that applications should be careful when appending data to an existing log. In some cases an initial line break is required and in others not. For example, if application crashes when writing CiscoLog message, but before it wrote a line break to file, then when the application starts up, it should print an initial line break before printing the next message. An application can determine if an initial line break is necessary during startup by checking the last character sequence in the log file that will be used for appending.
CiscoLog message format is identical for messages written directly to a log file or those generated by using the syslog protocol with two minor exceptions. When CiscoLog messages are written directly into to a file they must be appended with line separators. When CiscoLog messages are sent by using the syslog protocol then the syslog RFC 3164 protocol PRI header must be prepended to each CiscoLog message.
The syslog PRI field encodes syslog message severity and syslog facility. The severity encoded in the PRI field must match the value of the CiscoLog SEVERITY field. Any syslog facility can be used regardless of the content of the message. Typically, a given application is configured to send all its messages to a single syslog facility (usually RFC 3164 facilities local 0 through local 7). Refer to RFC 3164 for details about how to encode the PRI field. Below is an example of a CiscoLog message with the syslog protocol PRI field <165> which encodes the severity level of notice (5) and facility value local4.
<165>11: host.cisco.com: Jun 13 2003 12:11:52.454 UTC: %BACC-5-CONFIG: Configured from console by vty0 [10.0.0.0]Messages as shown in the example above can be sent to UDP port 514 if using RFC 3164 logging mechanism.
Syslog RFC 3164 provides additional guidelines for message content formatting beyond the PRI field. However, RFC 3164 is purely information (not on IETF standards track) and actually allows messages in any format to be generated to the syslog UDP port 514 (see section 4.2 of RFC 3164). The RFC provides observation about content structure often encountered in implementations, but does not dictate or recommend its use. CiscoLog format does not follow these observations due to practical limitations of the format defined in the RFC. For example, the time stamp is specified without a year, time zone or milliseconds while the hostname can only be provided without the domain name.
CiscoLog messages must remain unaltered when relayed. The PRI field is not part of a CiscoLog message, but rather a protocol header. It can be stripped or replaced if necessary. Additional headers or footers can be added to and stripped from the CiscoLog message for transport purposes.
Standard Syslog Server Implementations
Standard syslog server implementations can be configured to forward received log messages or to store the messages locally. Most syslog server implementations strip the PRI field from the received messages and prefix additional information to the message before storage. This additional information typically includes two extra fields: the local time stamp and the host identifier (IP or DNS name) of the server, which generated or relayed the message.
The following example of a CiscoLog message shown the output after being logged by the Solaris 8 syslog server:
Jun 13 12:12:09 host.cisco.com 11: host.cisco.com: Jun 13 2003 12:11:52.454 UTC: %BACC-5-CONFIG: Configured from console by vty0 [10.0.0.0]There is no standard that defines how syslog servers must store messages. Implementations vary greatly. CiscoLog only addresses the format in which messages are sent to the syslog server, not how they are stored by the server that receives them. Specifically, the format and presence of any additional header fields in syslog log files is outside of the scope of this specification.
Note
Clock Synchronization
It is important that the clocks of all hosts of a distributed application be synchronized with one authoritative clock. This can be accomplished by using protocols such as NTP. Clock synchronization is recommended because the time stamps in log messages are required in order to be able to re-construct the correct sequence of events based on messages originating from multiple processes or multiple hosts. Clock drifts can still occur, but ongoing synchronization should reduce this issue to a minimum.
Multipart Messages
ASCII control characters are not permitted in any of the fields of CiscoLog message format. Control characters include characters such as line feed, form feed and carriage returns. This means that multi-line messages are not allowed unless to allow:
•
•
Multi-part CiscoLog message consists of a set of multiple valid CiscoLog messages. Messages are grouped together using a special tag key "part", which identifies the part number and the sequence number of the original message.
All messages which are part of a multi-part message must have a "part" tag as well as identical values for the HOST, TIMESTAMP, APPNAME, SEVERITY fields and other TAG values. However, the sequence number of each message has to be incremented as usual.
Example of a multi-part message:
16: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-3-UNEXPECTED_EXCEPTION: %[pname.orig=rdu][part=16.1/3]: Null pointer exception17: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-3-UNEXPECTED_EXCEPTION: %[pname.orig=rdu][part=16.2/3]: com.cisco.Source:12318: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-3-UNEXPECTED_EXCEPTION: %[pname.orig=rdu][part=16.3/3]: com.cisco.Main:1112In this example, the first message has part number 1 and its sequence number, 16, embedded in the part tag. Subsequent messages embed the sequence number of the first message part and provide their own part number. The trailing "/3" in each part tag value means that the message consists of three parts.
CiscoLog Message Format
The CiscoLog message format follows:
<SEQNUM>: <HOST>: <TIMESTAMP>: %<HEADER>: [TAGS: ]<MESSAGE>
All fields gets separated by a single colon character (ASCII decimal value 58) and a single space character (ASCII decimal value 32). The HEADER field is also preceded by a percent character (ASCII decimal value 37).
The TIMESTAMP, HEADER and TAGS fields have internal formatting. Below is a complete format with details for TIMESTAMP and HEADER fields:
<SEQNUM>: <HOST>: [ACCURACY]<MONTH> <DAY> <YEAR> <HOUR>:<MINUTES>:<SECONDS>.<MILLISECONDS> <TIMEZONE>: %<APPNAME>-<SEVERITY>-<MSGNAME>: [TAGS: ]<MESSAGE>
All fields except for ACCURACY and TAGS are required.
The following example shows a CiscoLog message:
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-5-CONFIG: Configured from console by vty0 [10.10.10.0]The following example shows the optional TAGS and ACCURACY fields in a CiscoLog message:
12: host.cisco.com: *Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST: %[pname.orig=rdu][comp=parser][mac=1,6,aa:bb:cc:11:22:33][txn=mytxn123]: Bad request received from device [1,6,aa:bb:cc:11:22:33]. Header missing.The values of the specific fields in the above example are as follows:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Message Length Limit
The maximum length of a complete CiscoLog message must not exceed 800 octets.The term octet is used for 8-bit data type instead of byte because byte is not 8 bits on some platforms. The words "character" and "octet" are not synonyms in parts of this specification because in places were internationalization is supported a single character may need to be represented with multiple octets. This limit is dictated by RFC 3164. The limit of 1024 octets reserves some extra space for syslog forwarding headers and/or fields that may be formalized in later specifications.
When CiscoLog message includes the syslog PRI field, then the combined CiscoLog messages and PRI field length must not exceed 805 octets.
SEQNUM Field
The SEQNUM field contains a sequence number, which can be used to order messages in the time sequence order when multiple messages are produced with the same time stamp by the same process. The sequence number begins at 0 for the first message fired by a process since the last startup and is incremented by 1 for every subsequent logging message originated by the same process. Every time the application process is restarted, its sequence number is reset back to 0. The sequence number of each message must be in the exact order in which messages are fired/logged by the application.
This may mean that in a multi-threaded application there must be some kind of synchronization to ensure this and another consideration may have to be made for Java applications that have some native (C) code in JNI. If log messages originate in both native and Java parts of the same process, the implementation needs to be synchronized to use the same sequence number counter across the two process parts and to fire messages in the order of sequence numbers.
The maximum numeric value of the SEQNUM field is 4,294,967,295 at which point the counter must be reset back to 0. The maximum positive value of a 32-bit unsigned integer as used in Cisco IOS. Cisco IOS uses ulong for the sequence number counter and ulong is a 32-bit unsigned integer on all current Cisco IOS platforms including mips, ppc, and 68k.
Sequence numbers are process specific. If application architecture has multiple application processes on a single host, which share a single logging daemon, the sequence number still has to be process-specific. Thus, each process has it is own sequence number which it increments.
Sequence numbers also help detect lost messages. Therefore, sequence numbers cannot be skipped. In other words, a message must be produced for every number in the sequence order.
HOST Field
The HOST field identifies the system originating the message with a Fully Qualified DNS Name (FQDN), hostname or an IPv4/IPv6 address. If the FQDN or hostname is known, one of the two has to appear in the HOST field. It is expected that in most deployments the hostname is sufficient. However, if a deployment spans multiple domains, then using FQDNs is recommend. If an application is expected to be deployed in both scenarios, then it is recommended that the application default to the FQDNs, but make it a configurable option.
If neither FQDN nor hostname can be identified, then the IP address of the host must be used. If the IP address cannot be identified, then a constant "0.0.0.0" (without quotes) must appear in place of the HOST field.
Note
The length of the HOST field must not exceed 255 octets.
FQDN & Hostname
If multiple FQDNs or hostnames are known for a given system, applications must use the primary FQDN/hostname or an arbitrary one if no primary is designated. However, applications must use the same HOST field value until some relevant configuration change takes place. In other words, the FQDN/hostname value should not arbitrarily change from message to message if system is configured with multiple FQDNs/hostnames.
Only printable US ASCII characters (those with decimal values 32-126) and foreign language characters are allowed in the HOST field when encoding an FQDN or hostname. The appropriate character set and encoding for HOST should be compliant with RFC 1123 / STD-3.
The acceptable character set per these standards includes US ASCII letters, numbers, dash and dot separator characters (although not starting or ending with a dash). The reason that these are only recommendations of adhering to these standards is that, in practice, many hosts do not follow the convention and use characters such as underscore in the hostname. However, the HOST field cannot contain a character sequence of ": " (colon and space) as this sequence is used as a field delimiter in the CiscoLog format.
Foreign language characters outside of the printable US ASCII characters have to be encoded according to internationalization rules.
Use of non-printable (control) ASCII characters is not allowed in the HOST field. Control characters include characters with ASCII decimal values 0-31 and 127. If an application provides a CiscoLog-compliant library with a host string, which includes one or more control characters, the logging library must do the following. If the horizontal tab character (ASCII decimal value 9) is encountered, it must be replaced with one or more space characters (ASCII decimal value 32). Eight spaces per tab are recommended because this is a convention on most Unix and Windows platforms. Other control characters must each be replaced with a question mark character (ASCII decimal value 63).
While DNS is letter-case agnostic, CiscoLog places an additional recommendation of using only lower-case characters in the HOST field for ease of readability. The use of the trailing dot at the end of the FQDN is optional. The following examples are valid HOST fields:
•
•
•
•
IP Addresses
The IP address value used in the HOST field can be either an IPv4 or IPv6 address. If a device has multiple IP addresses, the primary IP address of the device must be used regardless of the interface through which the CiscoLog message is sent to syslog server. If no primary IP address is designated, a fixed/static IP address is preferred to a dynamically assigned one. If multiple static IP addresses exist, any one can be used, but it must be used consistently in all messages until a relevant configuration event occurs on the system.
•
Below is an example of a message with an IPv4 address in the HOST field:
11: 212.1.122.11: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST: Bad request received from device [1.2.3.4]. Missing header.Below is an example of a CiscoLog message when FQDN, hostname or IP are all unknown:
11: 0.0.0.0: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST: Bad request received from device [1.2.3.4]. Missing header.•
–
–
–
–
Below is an example of a message with an IPv6 address in the HOST field:
11: 1080:0:0:800:ba98:3210:11aa:12dd: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST: Bad request received from device [1.2.3.4]. Missing header.TIMESTAMP Field
The TIMESTAMP field provides date with year, time with milliseconds and a time zone identifier in the following format:
[ACCURACY]<MONTH> <DAY> <YEAR> <HOUR>:<MINUTES>:<SECONDS>.<MILLISECONDS> <TIMEZONE>
Below are several examples of valid time stamps:
Jun 13 2003 23:11:52.454 UTCJun 3 2003 23:11:52.454 UTCJun 22 2003 05:11:52.525 -0300*Feb 14 2003 01:02:03.005 ESTIn some cases, it is possible that a device may not have the knowledge of the date and/or time due to hardware or software limitations. In such circumstances, the following string must be produced in the TIMESTAMP field: "--- 00 0000 00:00:00.000 ---". Below is an example of a CiscoLog message from a device which has no knowledge of date and/or time:
11: host.domain.com: --- 00 0000 00:00:00.000 ---: %BACC-3-BAD_REQUEST: Bad request received from device [1.2.3.4]. Missing header.Devices which are not aware of their clock, may choose to provide an uptime as a relative measure of time. If device is capable of providing uptime, it is recommended that does so as a substitute for unavailable time stamp. If uptime is provided it must be provided with a standard uptime tag as outlined in the CiscoLog Standard Tags specification.
Table 6-1 details each field specification.
Table 6-1 TIMESTAMP Field Specifications
ACCURACY
This is an optional field. If present, it must be either a single asterisk character (ASCII decimal value 42), or a single dot character (ASCII decimal value 46). No separator character is used after this field. This field indicates the status of clock synchronization.
Cisco IOS uses a special convention for time prefixes to indicate the accuracy of the time stamp. If dot character appears before the date, it means that the local time was synchronized at some point via NTP, but currently no NTP servers are available. The asterisk character in front of the date means that the local time is not authoritative, i.e. NTP servers are not setup.
CiscoLog supports the use of this convention, but does not require it. If an application is integrated with NTP client software, and knows that its time is out of sync, then it can optionally prefix the message with asterisk character. However, because applications may choose not to use this scheme, the lack of "." or "*" in CiscoLog messages should not be interpreted to mean that the local time is synchronized.
MONTH
Must be one of the following three-character month designations followed by a single space (ASCII decimal value 32) as a delimiter character: Jan, Feb, Mar, Apr, May, Jun, Jul, Sep, Oct, Nov or Dec.
DAY
Must consist of two characters. If day is a single digit, it must be prefixed with a single space character. The acceptable range of values is from 1 to 31. The day value must be followed by a single space as a delimiter character.
YEAR
Must consist of exactly 4 digit characters followed by a space as a delimiter character.
HOUR
Must consist of exactly two number characters. The hour value is based on a 24-hour clock. Values range from 00 to 23. If hour value is a single digit, it must be prefixed with a single zero character. The hour value must be followed by a single colon as a delimiter character.
MINUTES
Must consist of exactly two number characters. Values range from 00 to 59. If minute value is a single digit, it must be prefixed with a single zero character. The minutes value must be followed by a single colon as a delimiter character
SECONDS
Must consist of exactly two number characters. Values range from 00 to 59. If seconds value is a single digit, it must be prefixed with a single zero character. The seconds value must be followed by a period as a delimiter character.
MILLISECONDS
Must consist of exactly 3 digit characters. Values range from 000 to 999. If milliseconds value is less then 3 digits in length it must be prefixed with extra zeros to make it a 3-character field. The milliseconds value is followed by a space as a delimiter character.
TIMEZONE
Must consist of at least one, but no more than 7 characters in the following ASCII decimal value range: 32-126. The value must not include a combination of colon-space-percent of characters - ": %" (ASCII decimal values 58, 32, 37) - as this character combination is reserved as a field delimiter that follows the time stamp.
There is no standard set of acronyms for time zones1 . A list of common time zone acronyms and corresponding time offsets from UTC is provided in the UTC specification.
Uppercase letters are recommended for time zone acronym values. CiscoLog recommends the use of time offset instead of time zone identifier in this field. The offset, if provided, must follow the following format "-hhmm" or "+hhmm" to indicate hour and minute offset from UTC.
In this format time zone field must always contain 5 characters, with the last 4 characters being constrained to numbers only. Unlike a textual time zone identifier, this format provides a specific time offset from universal standard time.
Cisco IOS Release 12.3 supports any 7-character string as a time zone identifier, so it can be configured in a way which is compatible with this recommendation. Multiple messages may and sometimes must be produced with exactly the same time stamp. This can happen naturally on a non-preemptive operating system or may need to be deliberately induced as in the case of multi-part messages. Sequence numbers then become helpful for establishing message order. Time stamp should always be accurate to the millisecond unless it can significantly hinder performance of the application.
In either case, applications must always provide the administrator with an option to output messages with exact time stamp in milliseconds. If an application uses time stamp with accuracy to the second (instead of a millisecond), it must put the last known milliseconds value or 000 in place of the milliseconds. Whatever convention is chosen by the application, it should be followed consistently.
1 Neither Cisco IOS nor CiscoLog define a standard set of time zone acronyms because there is no single established standard.
HEADER Field
The HEADER field has the following format:
<APPNAME>-<SEVERITY>-<MSGNAME>
A single dash character (ASCII decimal value 45) serves a separator for the three fields.
APPNAME Field
The APPNAME field in the HEADER defines the name of the application producing the message. Cisco IOS uses FACILITY in place of APPNAME that names the logical component producing the message. Cisco IOS 12.3 defines approximately 287 facilities for 3950 messages. Example of some easily recognizable facilities: AAAA, SYS, ATM, BGP, CRYPTO, ETHERNET, FTPSERVER, CONFIG_I, IP, ISDN, RADIUS, SNMP, SYS, TCP, UBR7200, X25. A complete list of defined facilities is available in Cisco IOS documentation at http://.
Outside of the Cisco IOS, there can be multiple applications on the same host originating log messages. Therefore, it is necessary that APPNAME field identify the specific application. Additional source identifiers are available in the HOST field as well as various standard TAGS field values (pname, pid, comp, etc).
The APPNAME field must consist of at least two uppercase letters or digits and may include underscore characters. More precisely, the acceptable character set is limited to characters with the following ASCII decimal values: 48-57 (numbers), 65-90 (upper-case letters) and 95 (underscore).
The length of the APPNAME field must not exceed 24 characters.
Application names cannot conflict with other Cisco software applications and with Cisco IOS facilities.
On the Solaris platform, it is recommended (not required) that the application name values used in the APPNAME field be consistent with those used for the application installation package name, only in upper case and without the CSCO prefix. For example, an application registering as "CSCObacc" on Solaris should use "BACC" as the value of the APPNAME field.
Some applications may choose to specify a version as part of the APPNAME field. This is acceptable and may be useful in cases where the meaning of certain messages is re-defined from one release to another. For example, an APPNAME value could be "BACC_2_5" for BACC version 2.5. The use the version within an application name is optional and may be introduced by applications in any release.
SEVERITY Field
The SEVERITY field is a numeric value from 0 to 7, providing eight different severities. The severities defined below match Cisco IOS severity levels. They are also standard syslog severities.
It is important that messages use the correct severity. An error in a certain component may be severe as far as the component is concerned, but if the overall application handles it gracefully, then the severity may be lower for the application as a whole. Table 6-2 lists guidelines that should be followed in determining the severity of a message.
If an application uses a default severity level to determine which messages should be logged, then it is recommended that this level be set at 5 (notice). This ensures that all messages of severity 5 or higher are logged by default.
MSGNAME Field
The MSGNAME field of the HEADER uniquely identifies the message within the context of a given APPNAME. A fixed severity and logical meaning is associated with a specific MSGNAME within a specific APPNAME. In other words, the same message name cannot appear with different severity or a completely different logical meaning for the same APPNAME value even if the message is originated by a different process.
Message names are only unique within a given application (a given APPNAME value) unless the message is one of the standard messages. Thus, applications interpreting CiscoLog messages should be careful not to assume that a message with a given name has the same meaning for all applications that may use this message name. Indeed, if the message is not one of the standard messages, it may have a different severity and meaning in a different application.
The MSGNAME field must consist of at least two characters. Acceptable characters are limited to the following ASCII decimal values: 48-57 (numbers), 65-90 (upper-case letters) and 95 (underscore). While IOS allows lower-case letters as well, the vast majority of IOS messages use only the upper-case letters. In order to be consistent with established conventions we opted to restrict the character set to upper-case letters, numbers and underscore characters.
Both numeric-only or alphanumeric message names are acceptable. However, per IOS convention, it is recommended that a user-friendly alphanumeric label be preferred to a numeric-only label. For example, "NO_MEMORY" message name is preferred to a "341234" identifier.
A special tag mid is defined in the CiscoLog Standard Tags specification for identifying a numeric id corresponding to a message name. This tag can be used to provide a numeric message is in addition to the MSGNAME. When this tag is used, a given MSGNAME must always correspond to a single message id value. CiscoLog defines mid tag values for each standard message.
The length of the MSGNAME field must not exceed 30 characters, but most message names should be more concise. MSGNAME value may not conflict with the names defined in this standard.
A separate message name must be defined for each logically different message. In other words, while the message text for a given message name can vary by virtue of some substitutable parameters, logically different messages must have different message names.
The following is an example of correct use of message name:
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-CONNECTION_LOST: %[pname.orig=rdu]: Server lost connection to host [1.1.1.1]12: host.cisco.com: Jun 13 2003 23:11:52.458 UTC: %BACC-4-CONNECTION_LOST: %[pname.orig=rdu]: Server lost connection to host [2.2.2.2]Notice that while the IP address of the host changes, it is still logically the same type of message. The following is an example of an INCORRECT use of the message name:
15: host.cisco.com: Jun 13 2003 23:11:52.458 UTC: %BACC-4-CONNECTION: %[pname.orig=rdu]: Server lost connection to host [2.2.2.2]16: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-4-CONNECTION: %[pname.orig=rdu]: Server re-established connection to host [2.2.2.2]The use of a single message name for two different events in the above example is wrong and unacceptable. This is referred to as a "catch-all" message name and they must be avoided. Another extreme example is defining a message named "ERROR" and providing all error log messages under the same message name. This defeats the purpose of having the message name field, which is to enable external filtering of messages or easily trigger actions.
The only exception to the "no-catch-all" rule is when message cannot be identified ahead of time with anything better than a generic description or the users will not benefit from distinguishing the various subtypes of the message.
Although some applications may choose to do so, there is generally no need to define a separate message name for all debugging messages because debugging messages are not intended for automated filtering and action triggering based on message name. The sheer number of debugging messages and the highly dynamic nature of what is produced in them makes it very hard to define separate messages.
This specification proposes establishing a mailing list that could be used by groups for consulting purposes when in doubt about how to define certain messages. Currently, the mailing list alias used for this purpose is "cmn-logging".
TAGS Field
The TAGS field is optional in the message format. It provides a standard mechanism for applications to provide structured content in the form of key-value pairs which can be used to categorize or filter a set of messages externally.
Tags can be used to identify virtual logging channels. A set of messages flagged with the same tag can later be grouped together. For example, an application may flag messages belonging to a particular thread by supplying the corresponding tag. This would then allow filtering and viewing messages based on threads.
Virtual logging channels can also be established across multiple applications. For example, if all applications could tag requests from a device with device id (mac, ip, etc), then it would be easy to filter all messages related to that device even thought it communicates with multiple components.
Each application may define its own set of supported tags. A single tag consists of key and value pair separated by the equals sign and surrounded by square bracket characters as in the following format: [KEY=VALUE]. This is an example of a valid tag key-value pair [ip=123.23.22.22].
The TAGS field is prefixed with a percent character (ASCII decimal value 37) and ends with a sequence of colon and space characters (ASCII decimal values 58 and 32). When multiple tags are assembled together, no characters should appear between the tags as separators. The following example has a complete CiscoLog message with four tags:
12: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST: %[pname.orig=rdu][comp=parser][mac=1,6,aa:bb:cc:11:22:33][txn=mytxn123]: Bad request received from device [1,6,aa:bb:cc:11:22:33]. Missing header.If TAGS field is missing, the percent character prefix and the trailing colon and space must be omitted. Thus, when the TAGS field is missing, the HEADER and MESSAGE fields must be separated by just a single colon and a space which follows the HEADER field. For example:
12: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST: Bad request received from device [1,6,aa:bb:cc:11:22:33]. Missing header.Multiple tags with the same tag key can be provided in the same message. This essentially provides the capability for handling multi-valued keys. Below is an example of a message produced from a device which has two IP addresses where the application chose to provide both IP addresses in the TAGS field as well as the process name:
12: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST: %[pname.orig=rdu][ip.orig=1.1.1.1][ip.orig=1.1.1.2]: Bad request received from device [1,6,aa:bb:cc:11:22:33]. Missing header.Any number of tags can be provided in a given message. The only limit is the overall length limit of the CiscoLog message of 800 octets.
If multiple tags are present, it is recommended that they appear in the alphanumeric order of the keys. This insures that tags are always produced in the same order. However, a different order may be chosen by an application if the order of tags is used to communicate some semantic value.
Tag Keys
Tag key must contain at least one character. The characters are limited to ASCII characters with decimal values 48-57 (numbers), 65-90 (upper-case letters), 95 (underscore), 97-122 (lower case letters). Use of lower-case letters is recommended. There is no strict limit on tag key length, although a general message limit of 800 octets applies and dictates that one should attempt to define short tag key names.
Tag Semantic Extensions
In some cases, a tag can have a standard value syntax, but different meaning depending on the content in which it is used. Tag semantic extensions are used to differentiate the contextual meaning of tags.
The semantic extension tags are created by appending the tag key with a single dot character (ASCII decimal value 46) and a text string consisting of characters from a proper character set.
For example, an "ip" tag defines syntax for an IP address representation, but no semantic value. An "ip" tag found in a CiscoLog message generally means only that this IP address is somehow related to the message. In some cases, such vague association is sufficient. However, sometimes, communicating semantic value could be useful.
A message may have two IP address tags associated with it, for example, from and to IP addresses. In this case, using tags "ip.from" and "ip.to" would communicate both the syntax of the tags and some semantic value. Another example, is a standard tag "ip.orig", which specifies the IP address of the host which originated the message. The following is an example of all three tags appearing together:
[ip.from=1.1.1.1][ip.to=2.2.2.2][ip.orig=123.12.111.1]Multiple levels of semantic extension tags are allowed with each extension providing meaning that is more specific. For example, tag key "ip.to.primary" is valid and could mean the primary IP address of the destination host.
The semantic value is much harder to standardize than the syntax because there can an infinite number of meanings for a given value depending on the context. Thus, it is anticipated that defining tag semantics extensions will be largely application specific.
Tag Values
Tag values may contain zero or more characters. The empty (zero characters) value is interpreted as unknown or undetermined value. The value must only include printable US ASCII characters (those in the ASCII decimal value range 32-126) and foreign language characters
There is a restriction on the use of three characters: "[", "]" and "\". The bracket characters (ASCII decimal values 91 & 93) must be escaped with a back slash character (ASCII decimal value 92) . This helps to avoid confusion with the brackets that signify the start/end of the tag. Thus, when the tag value needs to represent characters "[" or "]", a sequence of "\[" or "\]" is used instead respectively. When the escape character itself needs to be represented in the tag value, then instead of the "\" character a sequence of "\\" is used.
Use of non-printable (control) ASCII characters is not allowed in the TAG value field. Control characters include characters with ASCII decimal values 0-31 and 127. If application provides to a CiscoLog-compliant library a tag value string, which includes one or more control characters, the logging library must do the following. If the horizontal tab character (ASCII decimal value 9) is encountered, it must be replaced with one or more space characters (ASCII decimal value 32). Eight spaces per tab are recommended because this is a convention on most Unix and Windows platforms. Other control characters must each be replaced with a question mark character (ASCII decimal value 63). Technically, we only need to require escaping a closing bracket. However, requiring escaping both open and closing brackets simplifies parser code and provides for a more consistent display in raw form.
There is no strict limit on tag value length; although a general message length limit of 800 octets applies and dictates that one must be conservative.
Tag Guidelines
The TAGS field is optional in the CiscoLog message format. Tags do not replace substitutable parameters in the message body. Tags merely provide an additional way to identify and categorize messages.
Since tags are optional, they can be enabled or disabled by the application/user as required. There is no requirement for the same message to always be produced with the same set of tags. If the application supports a given tag, it does not necessarily mean that it must always produce it. This can be configurable. Indeed, it is recommended that applications provide the administrator with at least limited control over which tags get produces.
Application developers have a choice as to what information to make available in the tags and what in the message body. In some cases, the information may be duplicated between the two. This is acceptable.
The general guideline is to put all required information in the message body and make appropriate information available via tags. In other words, the message should provide sufficient meaning even when all tags are disabled. Tags merely provide additional useful information and a way to present it in a standard, easily filtered, form.
The following are two valid examples of a message where both the message and the message tags contain a MAC address. Example with tags disabled:
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST: Bad request received from device [1,6,aa:bb:11:22:33:aa]. Missing header.In the above example, the MAC address appears as part of the message field - it is not a tag. In the following example, the tags are enabled. Even though MAC address is duplicated between the tag and the message, it is acceptable.
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST: %[mac=1,6,aa:bb:11:22:33:aa][tid=thread1][txn=mytxn123]: Bad request received from device [1,6,aa:bb:11:22:33:aa]. Missing header.Process Identification Tag
One of the standard tags, pname.orig, is used to identify the logical process name which originates the message. Any application that seeks to provide originating process information must do so using the "pname.orig" tag.
This tag is extremely valuable in addition to information in the APPNAME field because some applications consist of multiple processes, each of which may originate logging messages. It is recommended that any application which consists of multiple processes always provide the "pname.orig" tag.
MESSAGE Field
The MESSAGE field provides a descriptive message about the logging event. This field may consist of one or more characters. The character set is limited to printable US ASCII characters (ASCII decimal values 32-126) and foreign language characters.
Use of non-printable (control) ASCII characters is not permitted in the MESSAGE field. Control characters include characters with ASCII decimal values 0-31 and 127. If application provides a CiscoLog-compliant library with message string, which includes one or more control characters, the logging library must do the following. If the horizontal tab character (ASCII decimal value 9) is encountered, it must be replaced with one or more space characters (ASCII decimal value 32). Eight spaces per tab are recommended because this is a convention on most Unix and Windows platforms. Other control characters must each be replaced with a question mark character (ASCII decimal value 63).
The maximum length of the MESSAGE field is constrained only by the maximum length of the entire message. The maximum length of the CiscoLog message must not exceed 800 octets. Another practical limitation is a potentially highly variable length of the TAGS field.
Message text may contain substitutable parameters, which provide necessary details about the message. For example, the IP address in the following example is a substitutable parameter.
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-3-INVALID_REQUEST: Invalid request received from device [1.22.111.222]. Missing header.It is recommended (but not required) that substitutable parameters be surrounded by bracket characters "[" and "]" as in the above example. It is further recommended that the message text and values of substitutable parameters do not include bracket characters. When it is not possible to avoid brackets characters in the values of substitutable parameters, it is recommended that the value at least does not include unbalances brackets (like an opening bracket without a closing one). When these recommendations are followed, it would be possible to programmatically extract substitutable parameter values out of a CiscoLog message. However, this recommendation is not a strict requirement.
Message text should be spell-checked. Editorial review is recommended. This includes all messages that can be seen by the customers, even debugging messages.
If the first word of the message is an English word, the first letter should be capitalized. Single sentence messages do not require a period at the end.
Internationalization
Foreign language characters are defined as characters with ASCII decimal values 0-126. Foreign language characters are supported in the HOST field, the value part of the TAGS field and the MESSAGE field.
Foreign language characters must be encoded using the Unicode standard UTF-8. UTF-8 provides encoding for any language without requiring the application to know local encoding/decoding rules for a particular language. In fact, the application encoding the message does not even need to know the language of the message. UTF-8 can encode any Unicode character.
UTF-8 encodes US ASCII characters exactly as they would normally be encoded in a 7-bit ASCII convention. This means that applications interpreting CiscoLog messages can assume that entire messages are encoded in UTF-8. On the other hand, applications producing CiscoLog messages can encode the entire message using US-ASCII 7-bit convention if they are known not to support foreign languages in their products.
Since UTF-8 can encode characters in any language, it is possible to mix and match languages. For example, it is anticipated that a one use-case would be the inclusion of just some parameters in foreign language in an otherwise English message. For example, an English message about user authentication could have a username in Japanese. Similarly, any number of languages can be combined in a CiscoLog message.
In order to take advantage of messages, which include a foreign language, a log viewer capable of interpreting UTF-8 would be necessary. Most likely, the log viewer would also require that the appropriate language fonts be installed on a given system. In a US-ASCII only editor, the user will see garbage for non-US-ASCII characters encoded in UTF-8, but should be able to see all US-ASCII text.
Internationalization support can be readily used with CiscoLog messages written to a local file. Syslog RFC 3164, however, does not currently define foreign language support. Thus, in order to take advantage of internationalization with a syslog server, one would need to use a server implementation, which was tested to correctly relay or store all 8-bits of each octet unchanged. This would ensure that UTF-8 encoded parts of the message retain all their information when foreign languages are used.
In UTF-8, a single character is encoded with one or more octets. The CiscoLog message length limit is specified as 800 octets. Developers must be aware that with foreign languages, the 800-octet length limit may mean fewer than 800 characters. When a message is split into a multi-part message using guidelines provided in Multipart Messages, octets belonging to a single character must never be split into separate lines.
Versioning
CiscoLog does not provide any versioning information in the message format. Extensions to the format must be made within the restrictions of the format. CiscoLog message formats provides for extensions by way of defining additional tags.
If applications require changes to existing messages, the value of APPNAME can redefine message within the new space. For example, the application version can be appended to the application name as BACC_2_5 for BACC 2.5.
Preconfigured System Alarm Notifications
The following list contains the preconfigured system alerts in RTMT. Refer to the Real-Time Monitoring Tool Administration Guide for information on configuration.
•
•
•
•
•
•
•
•
AuthenticationFailed
Authentication validates the user ID and password that are submitted during log in. An alarm gets raised when an invalid user ID and/or the password gets used.
CiscoDRFFailure
This alert occurs when the DRF backup or restore process encounters errors.
CoreDumpFileFound
This alert occurs when the CoreDumpFileFound event gets generated. This indicates that a core dump file exists in the system.
CpuPegging
CPU usage gets monitored based on configured thresholds. If the usage goes above the configured threshold, this alert gets generated.
CriticalServiceDown
The CriticalServiceDown alert gets generated when the service status equals down (not for other states).
HardwareFailure
This alert occurs when a hardware failure event (disk drive failure, power supply failure, and others) triggers.
LogFileSearchStringFound
This alert occurs when the LogFileSearchStringFound event gets generated. This indicates that the search string was found in the log file.
LogPartitionHighWaterMarkExceeded
This alert occurs when the percentage of used disk space in the log partition exceeds the configured high water mark. When this alert gets generated, LPM deletes files in the log partition (down to low water mark) to avoid running out of disk space.
Note
LogPartitionLowWaterMarkExceeded
This alert occurs when the LogPartitionLowWaterMarkExceeded event gets generated. This indicates that the percentage of used disk space in the log partition exceeded the configured low water mark.
Note
LowActivePartitionAvailableDiskSpace
This alert occurs when the percentage of available disk space on the active partition is lower than the configured value.
LowAvailableVirtualMemory
RTMT monitors virtual memory usage. When memory runs low, a LowAvailableVirtualMemory alert gets generated.
LowInactivePartitionAvailableDiskSpace
This alert occurs when the percentage of available disk space of the inactive partition equals less than the configured value.
LowSwapPartitionAvailableDiskSpace
This alert indicates that the available disk space on the swap partition is low.
Note
ServerDown
This alert occurs when a remote node cannot be reached.
Note
SparePartitionHighWaterMarkExceeded
This alert occurs when the SparePartitionHighWaterMarkExceeded event gets generated. It indicates that the percentage of used disk space in the spare partition exceeds the configured high water mark. Some core file or log files are purged until the percentage of used disk space in the spare partition is below the configured low water mark. Check if the configured high water mark for used disk space in the spare partition is too low.
Cisco Log Partition Monitoring Tool (LPM) starts purging trace log files in the spare partition and keeps deleting trace log files in the spare partition until spare partition disk usage is just below the low water mark.
Name of the service generating this alarm is Cisco Log Partition Monitoring Tool.
Check if the configured high water mark for used disk space in the spare partition is too low; if it is, change the high water mark setting to a higher value. Also examine each application trace log files under spare partition and delete those trace log files that are too old or too big.
SparePartitionLowWaterMarkExceeded
This alert occurs when the SparePartitionLowWaterMarkExceeded event gets generated. It indicates that the percentage of used disk space in the spare partition has exceeded the configured low water mark threshold. There are files to be purged by Cisco Log Partition Monitoring Tool (LPM). If the spare partition disk usage keeps increasing until it exceeded the configured high water mark, Cisco LPM starts purging the trace log files in the spare partition. Cisco LPM sends the alarm periodically if the spare partition disk usage has not changed.
Name of the service generating this alarm is Cisco Log Partition Monitoring Tool.
Check if the configured low water mark for used disk space in the spare partition is too low; if , change the low/high water mark settings to the higher values. Also examine each application trace log files under spare partition and clean up those trace log files that are too old or too big before the used disk space exceeds the high water mark.
SyslogSeverityMatchFound
This alert occurs when the SyslogSeverityMatchFound event gets generated. This indicates that a syslog message with the matching severity level exists.
SyslogStringMatchFound
This alert occurs when the SyslogStringMatchFound event gets generated. The alert indicates that a syslog message with the matching search string exists.
SystemVersionMismatched
This alert occurs when a mismatch in system version exists.
TotalProcessesAndThreadsExceededThreshold
This alert occurs when the TotalProcessesAndThreadsExceededThreshold event gets generated. The alert indicates that the current total number of processes and threads exceeds the maximum number of tasks that are configured for the Cisco RIS Data Collector Service Parameter. This situation could indicate that a process is leaking or that a process has thread leaking.
Preconfigured CallManager Alarm Notifications
The following list comprises the preconfigured CallManager alerts in RTMT. Refer to the Real-Time Monitoring Tool Administration Guide for information on configuration.
•
•
•
•
•
•
•
•
BeginThrottlingCallListBLFSubscriptions
This alert occurs when the BeginThrottlingCallListBLFSubscriptions event gets generated. This indicates that the Cisco Unified Communications Manager initiated a throttling of the CallList BLF Subscriptions to prevent a system overload.
CallProcessingNodeCpuPegging
This alert occurs when the percentage of CPU load on a call processing server exceeds the configured percentage for the configured time.
Note
The CallProcessingNodeCpuPegging alert gives you time to work proactively to avoid a Cisco Unified Communications Manager crash.
CDRAgentSendFileFailed
This alert gets raised when the CDR Agent cannot send CDR files from a Cisco Unified Communications Manager node to a CDR repository node within the Cisco Unified Communications Manager cluster.
CDRFileDeliveryFailed
This alert gets raised when FTP delivery of CDR files to the outside billing server fails.
CDRHighWaterMarkExceeded
This alert gets raised when the high water mark for CDR files gets exceeded. It also indicates that some successfully delivered CDR files got deleted.
CDRMaximumDiskSpaceExceeded
This alarm gets raised when the CDR files disk usage exceeds the maximum disk allocation. It also indicates that some undeliverable files got deleted.
CodeYellow
The AverageExpectedDelay counter represents the current average expected delay to handle any incoming message. If the value exceeds the value that is specified in Code Yellow Entry Latency service parameter, the CodeYellow alarm gets generated. You can configure the CodeYellow alert to download trace files for troubleshooting purposes.
DBChangeNotifyFailure
This alert occurs when the Cisco Database Notification Service experiences problems and might stop. This condition indicates change notification requests that are queued in the database got stuck and changes made to the system will not take effect. Ensure that the Cisco Database Layer Monitor is running on the node where the alert exists. If it is, restart the service. If that does not return this alert to safe range, collect the output of show tech notify and show tech dbstateinfo and contact TAC for information about how to proceed.
DBReplicationFailure
This alarm indicates a failure in IDS replication and requires database administrator intervention.
Note
DDRBlockPrevention
This alert gets triggered when the IDSReplicationFailure alarm with alarm number 31 occurs, which invokes a proactive procedure to avoid denial of service. This procedure does not impact call processing; you can ignore replication alarms during this process.
The procedure takes up to 60 minutes to finish. Check that RTMT replication status equals 2 on each node to make sure that the procedure is complete. Do not perform a system reboot during this process.
DDRDown
This alert gets triggered when the IDSReplicationFailure alarm with alarm number 32 occurs. An auto recover procedure runs in the background, and no action is needed.
The procedure takes about 15 minutes to finish. Check that RTMT replication status equals 2 on each node to make sure the procedure is complete.
ExcessiveVoiceQualityReports
This alert gets generated when the number of QRT problems that are reported during the configured time interval exceed the configured value. The default threshold specifies 0 within 60 minutes.
LowAttendantConsoleServerHeartbeatRate
This alert occurs when attendant console server heartbeat rate equals less than the configured value.
LowCallManagerHeartbeatRate
This alert occurs when the CallManager heartbeat rate equals less than the configured value.
LowTFTPServerHeartbeatRate
This alert occurs when TFTP server heartbeat rate equals less than the configured value.
MaliciousCallTrace
This indicates that a malicious call exists in Cisco Unified Communications Manager. The malicious call identification (MCID) feature gets invoked.
MediaListExhausted
This alert occurs when the number of MediaListExhausted events exceeds the configured threshold during the configured time interval. This indicates that all available media resources that are defined in the media list are busy. The default specifies 0 within 60 minutes.
MgcpDChannelOutOfService
This alert gets triggered when the MGCP D-Channel remains out of service.
NumberOfRegisteredDevicesExceeded
This alert occurs when the NumberOfRegisteredDevicesExceeded event gets generated.
NumberOfRegisteredGatewaysDecreased
This alert occurs when the number of registered gateways in a cluster decreases between consecutive polls.
NumberOfRegisteredGatewaysIncreased
This alert occurs when the number of registered gateways in the cluster increased between consecutive polls.
NumberOfRegisteredMediaDevicesDecreased
This alert occurs when the number of registered media devices in a cluster decreases between consecutive polls.
NumberOfRegisteredMediaDevicesIncreased
This alert occurs when the number of registered media devices in a cluster increases between consecutive polls.
NumberOfRegisteredPhonesDropped
This alert occurs when the number of registered phones in a cluster drops more than the configured percentage between consecutive polls.
RouteListExhausted
This alert occurs when the number of RouteListExhausted events exceeds the configured threshold during the configured time. This indicates that all available channels that are defined in the route list are busy. The default specifies 0 within 60 minutes.
SDLLinkOutOfService
This alert occurs when the SDLLinkOutOfService event gets generated. This event indicates that the local Cisco Unified Communications Manager cannot communicate with the remote Cisco Unified Communications Manager. This event usually indicates network errors or a nonrunning, remote Cisco Unified Communications Manager.
Emergency-Level Alarms
The emergency-level alarm equals zero (0) and means that your system or service is unusable. These alarms generally indicate platform failures. Examples follow:
•
•
•
•
This level is not suitable for events associated with an individual end point.
IPAddressResolveError
The host IP address was not resolved.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
HostName [String]
Recommended Action
None
NoCMEntriesInDB
There are no CallManager entries in the database.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
LineStateSrvEngCreationError
There was an error during the LineStateSrvEng creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
GlobalSPUtilsCreationError
There was an error during the GlobalSPUtils creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
TapiLinesTableCreationError
There was an error during the TapiLinesTable creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
HuntGroupControllerCreationError
There was an error during the HuntGroupController creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
HuntGroupCreationError
There was an error during the Hunt Group creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
CallDirectorCreationError
There was an error during the CallDirector creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
SysControllerCreationError
There was an error during the SysController creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
TimerServicesCreationError
There was an error during the TimerServices creation.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
ExcceptionInInitSDIConfiguration
Exception occured in InitSDIConfiguration function.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
SyncDBCreationError
There was an error during the SyncDB creation in SysController.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
LostConnectionToCM
TCD connection to CallManager was lost.
Facility/Sub-Facility
CCM_TCD-TCD
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/TCD SRV
Severity
Emergency (0)
Parameters
None
Recommended Action
None
EMAppNotStarted
EM application not started because of an error.
Facility/Sub-Facility
CCM_JAVA_APPS-TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Emergency (0)
Parameters
Servlet Name [String]
Recommended Action
See application logs for error.
IPMANotStarted
IPMA application not started because of an error.
Facility/Sub-Facility
CCM_JAVA_APPS-TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Emergency (0)
Parameters
Servlet Name [String] Reason [String]
Recommended Action
See application logs for error
BDINotStarted
BDI application not started because of an error.
Facility/Sub-Facility
CCM_JAVA_APPS-TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Emergency (0)
Parameters
Reason [String]
Recommended Action
See application logs for error.
WDNotStarted
Failed to startup WebDialer application because of an error.
Facility/Sub-Facility
CCM_JAVA_APPS-TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Emergency (0)
Parameters
Servlet Name [String] Reason [String]
Recommended Action
See application logs for error
CiscoDirSyncStartFailure
Cisco DirSymc application failed to start successfully. Error occurred while starting application
Facility/Sub-Facility
CCM_JAVA_APPS-TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Emergency (0)
Recommended Action
See application logs for error, may require restarting the application
TestAlarmEmergency
Testing emergency alarm.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
System/Test
Severity
Emergency (0)
Recommended Action
None
CertExpiryEmergency
The alarm is generated when any certificate generated by the system or uploaded into the system expires. Cisco Unified CM uses certificates for Tomcat (Web Server), CallManager, IPSEc and Directory.The default validity of a self-signed Cisco Unified CM generated certificate is 5 years.
In case the certificates are signed by a CA, the validity is dependent on the expiry date set by CA while issuing the certificate. Once a certificate is ready to expire, the Cisco Certificate Expiry Monitor service generates an alarm. The severity of the alarm is dependent on how much time is left for the certificate to expire.
The impact to system operation depends on the which certificate expired. This information is contained in the alarm. If a Tomcat certificate expired while connecting to Cisco Unified CM web pages, the browser will display an error stating that the certificate has expired. You can ignore the warning and continue to connect to Cisco Unified CM web pages. If a directory trust certificate uploaded to Cisco Unified CM expires, Cisco Unified CM may not be able to establish an SSL connection with an external LDAP server. The overall impact is that an SSL connection between Cisco Unified CM and other external servers will fail.
Facility/Sub-Facility
/CERT
Cisco Unified Serviceability Alarm Definition Catalog
System/Cert Monitor
Severity
Emergency (0)
Parameters
None
Recommended Action
Regenerate or reimport certificate. Login to CUOS page. Go to Security > Certificate Management and re-generate the certificate that has expired (based on the information in alarm). This will generate a new self-signed certificate with a new expiry date. In case the certificate is signed by a CA, Generate a new CSR, send it to the CA, get the certificate signed by CA and upload the new certificate.
OutOfMemory
The process has requested memory from the operating system, and there was not enough memory available.
Cisco Unified Serviceability Alarm Definition Catalog
System/Generic
Severity
Emergency (0)
Parameters
None
Recommended ActionNone
ServiceNotInstalled
An executable is trying to start but cannot because it is not configured as a service in the service control manager. The service is %s. Service is not installed.
Cisco Unified Serviceability Alarm Definition Catalog
System/Generic
Severity
Emergency (0)
Parameters
Service (String)
Recommended Action
Reinstall the service.
FileWriteError
Cannot write into a file. Failed to write into the primary file path.
Cisco Unified Serviceability Alarm Definition Catalog
System/Generic
Severity
Emergency (0)
Parameters
Primary File Path(String)
Recommended Action
Ensure that the primary file path is valid and the corresponding drive has sufficient disk space. Also, make sure that the path has security permissions similar to default log file path.
Alert-Level Alarms
The alert-level alarm equals 1 and action must take place immediately. A system error occurred and will not recover without manual intervention. Examples follow:
•
•
•
•
Be aware that this level is not suitable for events that are associated with an individual end point.
kCOMException
COM exception caught. When CMI initializes COM, it catches an exception.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Alert (1)
Parameters
COM Exception [String]
Recommended Action
Report to Customer Service representative.
kCMIException
CMI exception thrown. When CMI runs, it throws an exception.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Alert (1)
Parameters
CMI Exception [String]
Recommended Action
The exception may be caused by wrong process configuration parameters or bad USB port status. Refer to the associated alarm for further information.
kUnknownException
CMI unknown exception caught. When CMI runs, it catches an unknown exception.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Alert (1)
Recommended Action
Report to Customer Service representative.
NoDbConnectionAvailable
No database connection available. Database layer could not find any working database connection.
Facility/Sub-Facility
CCM_DB_LAYER-DB
Cisco Unified Serviceability Alarm Definition Catalog
System/DB
Severity
Alert (1)
Recommended Action
In Cisco Unified Serviceability, enable Detailed level traces in the Trace Configuration window for the Cisco Database Layer Monitor service. Check network connectivity and operation of SQL Server services.
ErrorChangeNotifyReconcile
A change notification shared memory reconciliation has occurred. The change notification buffers in shared memory have been rebuilt due to conflicts.
Facility/Sub-Facility
CCM_DB_LAYER-DB
Cisco Unified Serviceability Alarm Definition Catalog
System/DB
Severity
Alert (1)
Recommended Action
This problem may have been already corrected. If unexpected behavior is observed, restart all Cisco services in the cluster.
WDStopped
WebDialer application stopped and was unloaded from Tomcat.
Facility/Sub-Facility
CCM_JAVA_APPS_TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Alert (1)
Parameters
Servlet Name [String] Reason [String]
Recommended Action
None
CiscoLicenseOverDraft
Overdraft licenses in use.
Facility/Sub-Facility
CCM_JAVA_APPS_TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Alert (1)
Parameters
Reason [String]
Recommended Action
None
CiscoLicenseApproachingLimit
License units consumption approaching its authorized limit.
Facility/Sub-Facility
CCM_JAVA_APPS_TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Alert (1)
Parameters
Reason [String]
Recommended Action
None
SocketError
Failed to open network connection for receiving file requests. This usually happens when the IP address that the TFTP service uses to open the network connection is invalid.
Facility/Sub-Facility
CCM_TFTP-TFTP
Cisco Unified Serviceability Alarm Definition Catalog
System/TFTP
Severity
Alert (1)
Parameters
Error [Int] Reason [String]
Recommended Action
Verify that the TFTP service parameter, TFTP IP Address, accurately specifies the IP address of the NIC card to use for serving files via TFTP. See the help for the (advanced) TFTP IP Address service parameter for more information. If the problem persists, go to Cisco Unified Serviceability and enable Detailed level traces in the Trace Configuration window for the TFTP service and contact the Cisco Technical Assistance Center (TAC).
TFTPServerListenSetSockOptFailed
Failed to increase the size of the network buffer for receiving file requests. This usually indicates a lack of memory when there is a system issue such as running out of resources.
Release7.0(1)
Name changed from kTFTPServerListenSetSockOptFailed.
Facility/Sub-Facility
CCM_TFTP-TFTP
Cisco Unified Serviceability Alarm Definition Catalog
System/TFTP
Severity
Alert (1)
Parameters
Error [Int] IPAddress [String] Port [Int]
Recommended Action
Use RTMT to monitor the system memory resources and consumption and correct any system issues that might be contributing to a reduced amount of system resources.
TFTPServerListenBindFailed
Fail to connect to the network port through which file requests are received. This usually happens if the network port is being used by other applications on the system or if the port was not closed properly in the last execution of TFTP server.
Release7.0(1)
Name changed from kTFTPServerListenBindFailed.
Facility/Sub-Facility
CCM_TFTP-TFTP
Cisco Unified Serviceability Alarm Definition Catalog
System/TFTP
Severity
Alert (1)
Parameters
Error [Int] IPAddress [String] Port [Int]
Recommended Action
Verify that the port is not in use by other application. After stopping the TFTP server, at the command line interface (CLI) on the TFTP server, execute the following command—show network status listen. If the port number specified in this alarm is shown in this CLI command output, the port is being used. Restart the Cisco Unified Communications Manager system, which may help to release the port. If the problem persists, go to Cisco Unified Serviceability and enable Detailed level traces in the Trace configuration window for the TFTP service and contact the Cisco Technical Assistance Center (TAC).
TestAlarmAlert
Testing alert alarm.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
System/Test
Severity
Alert (1)
Recommended Action
None
CertExpiryAlert
A certificate is about to expire in 1 day. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. The alarms are generated when any certificate generated by the system or uploaded into the system expires. CUCM uses certificates for Tomcat (Web Server), CallManager, IPSEc and Directory. Refer Security guide for more details on various certificates. When a certificate generated by CUCM, the default validity of the self-signed certificate is for 5 years. In case of Certificates signed by a CA, the validity is dependent on the Expiry date set by CA while issuing the certificate. Once a certificate is about to expire "Cisco Certificate Expiry Monitor"" service generates alarms. The severity of the alarm is dependent on how much time is left for the certificate to expire.
The impact to system operation depends on the which certificate expired. This information is contained in the alarm. If Tomcat certificate expired, while connecting to CUCM web pages, browser will throw an error stating certificate has expired. One can still ignore the warning and continue to connect to CUCM pages.
In case of Directory-trust, if Directory trust certificate uploaded to CUCM expires, CUCM may not be able to establish SSL connection with external LDAP server. The overall impact is that SSL connection between CUCM and other external Servers will fail.
Facility/Sub-Facility
/CERT
Cisco Unified Serviceability Alarm Definition Catalog
System/Cert Monitor
Severity
Alert (1)
Parameters
None
Recommended Action
Login to CUOS page. Go to Security->Certificate Management and regenerate the certificate that has expired (based on the information in alarm). This will generate a new self-signed certificate with a new expiry date. In case the certificate is signed by a CA, Generate a new CSR, send it to the CA, get the certificate signed by CA and upload the new certificate.
Critical-Level Alarms
The critical-level alarm equals 2 and action may need to be taken immediately; auto-recovery is expected, but monitor the condition.
This alarm acts similar to the alert-level alarm but not necessarily requiring an immediate action. A system-affecting service had a failure but recovered without intervention. Examples follow:
•
–
–
–
•
MGCPGatewayLostComm
The MGCP gateway is no longer in communication with Cisco Unified Communications Manager (Cisco Unified CM). This could occur because Cisco Unified CM receives an MGCP unregister signal from the gateway such as RSIP graceful/forced; Cisco Unified CM doesn't receive the MGCP KeepAlive signal from the gateway; the MGCP gateway doesn't response to an MGCP command sent by Cisco Unified CM three times; a speed and duplex mismatch exists on the Ethernet port between Cisco Unified CM and the MGCP gateway; the gateway has reset.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Critical (2)
Parameters
Device Name [String]
Recommended Action
Reset the MGCP gateway in an attempt to restore communication with Cisco Unified CM; check the speed and duplex settings on the Ethernet port. In the case of an unwanted reset of the gateway which caused communication to be lost, take precautions to ensure that no unauthorized personnel resets the gateway from Cisco Unified CM Administration or via the gateway terminal.
CISCO-CCM-MIB
See Chapter 7, "Cisco Management Information Base."
CDRMaximumDiskSpaceExceeded
The CDR files disk usage exceeded maximum disk allocation. Some undeliverable files may have been deleted to bring disk usage down. The CDR files disk usage has exceeded the maximum allocated disk space. CDRM may have deleted some CDR files that have not been sent to the outside billing servers yet, in order to bring the disk usage down to below High Water Mark. The decision whether to delete undeliverable files or not depends on how deletionDisable flag is configured at CDRM Configuration page. E-mail alert will be sent to the admin.
Facility/Sub-Facility
CCM_CDR_REP-CDRREP
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CDR Rep
Severity
Critical (2)
Parameters
DiskUsageInMB [String]
Recommended Action
1.
2.
3.
4.
5.
6.
7.
kStopBitConfigurationError
Process configuration parameter StopBit for CMI invalid. CMI cannot work properly because of the invalid StopBit configuration for USB port.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
Illegal Stop Bit [String]
Recommended Action
Check the process configuration parameter StopBit for CMI.
kParityConfigurationError
Process configuration parameter parity for CMI invalid. CMI cannot work properly because of the invalid parity configuration for USB port.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
Illegal Parity [String]
Recommended Action
Check the process configuration parameter parity for CMI.
kWSAStartupFailed
Windows socket startup failure. WinSock could not be started.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
Error Information [String]
Recommended Action
Ensure Windows 2000 service pack 1 is installed because it might obstruct Winsock creation. Then try to restart CMI. If this alarm keeps appearing, report to Customer Service representative.
kSerialPortOpeningError
Error when CMI tries to open the operating system USB port.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
USB Port Opening Error [String]
Recommended Action
Make sure the USB port is available.
kSerialPortGetStatusError
Error when CMI tries to get the status of operating system USB port.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
USB Port Getting Status Error [String]
Recommended Action
Make sure the USB port available.
kSerialPortSetStatusError
Error when CMI tries to set the status of operating system USB port.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
USB Port Setting Status Error [String]
Recommended Action
Make sure the USB port is available.
kReadingFileFailure
CMI failure reading SMDI messages from the USB port.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
Error Information [String]
Recommended Action
Make sure the USB port is available. If this alarm keeps appearing, report to Customer Service representative.
kVMDNConfigurationError
Voice mail DN for CMI invalid. CMI cannot register with Cisco CallManager because of the invalid voice mail DN.
Facility/Sub-Facility
CCM_SUMI-CMI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CMI
Severity
Critical (2)
Parameters
Invalid Voice-mail DN [String]
Recommended Action
Check the process configuration parameter Voice-mailDn for CMI.
kCtiSdlErrorvException
Failed to create an internal process that is required to service CTI applications. An unexpected internal SDL error caused a failure in creating CTIManager or CTIHandler process.
Facility/Sub-Facility
CCM_CTI-CTI
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CtiManager
Severity
Critical (2)
Recommended Action
An internal CTIManager error has occurred. Restart the CTIManager service to resolve this problem.
IDSEngineCritical
This alarm does not compromise data or prevent the use of the system but need to be monitored by the Administrator.
Facility/Sub-Facility
CCM_DB_LAYER-DB
Cisco Unified Serviceability Alarm Definition Catalog
System/DB
Severity
Critical (2)
Parameters
Event Class ID [String] Event class message [String] Event Specific Message [String]
Recommended Action
This alarm needs monitoring by the db admin
CiscoDirSyncProcessFailToStart
LDAPSync process failed to start on particular sync agreement.
Facility/Sub-Facility
CCM_JAVA_APPS-TOMCATAPPLICATIONS
Cisco Unified Serviceability Alarm Definition Catalog
System/Java Applications
Severity
Critical (2)
Parameters
AgreementId [String]
Recommended Action
See application logs for error
CoreDumpFileFound
The new core dump files have been found in the system.
Facility/Sub-Facility
CCM_TCT-LPMTCT
Cisco Unified Serviceability Alarm Definition Catalog
System/LpmTct
Severity
Critical (2)
Parameters
TotalCoresFound [String] CoreDetails [String] Core1 [String] Core2 [String] Core3 [String] Core4 [String] Core5 [String] Core6 [String]
Recommended Action
Use Trace and Log Central to collect the new core files and the corresponding service last trace log files, run gdb to get the back trace of each core file for further debugging.
SDIControlLayerFailed
Failed to update trace logging or alarm subsystem for new settings. This usually indicates a lack of system resources or a failure in database access by the trace logging or alarm subsystem.
Facility/Sub-Facility
CCM_TFTP_TFTP
Cisco Unified Serviceability Alarm Definition Catalog
System/TFTP
Severity
Critical (2)
Parameters
Error [Int] Reason [String]
Recommended Action
In Cisco Unified Serviceability, enable Detailed level traces in the Trace Configuration window for TFTP and Cisco Database Layer Monitor services. Also, use RTMT to look for errors that may have occurred around the time of the alarm. Ensure that the database server is running, and that the Cisco Database Layer Monitor service is running without problems. If this alarm persists, contact the Cisco Technical Assistance Center (TAC) with TFTP service and database trace files.
TestAlarmCritical
Testing critical alarm.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
System/Test
Severity
Critical (2)
Recommended Action
None
DUPLEX_MISMATCH
This alarm is generated by Cisco CDP whenever there is a duplex mismatch between local interface and switch interface.
Release7.1
Added DUPLEX_MISMATCH to the CDPAlarmCatalog.
Facility/Sub-Facility
CCM_CDP/CDP
Cisco Unified Serviceability Alarm Definition Catalog
System/CDP
Severity
Critical (2)
Parameters
Switch Duplex Settings(String)
Local Interface Duplex Settings(String)
Recommended Action
Ensure that duplex settings are set to auto or full on local interface as well as switch interface.
CertExpiryCritical
Certificate is about to expire in less than 7 days. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. The alarms are generated when any certificate generated by the system or uploaded into the system expires. CUCM uses certificates for Tomcat (Web Server), CallManager, IPSEc and Directory. Refer Security guide for more details on various certificates. When a certificate generated by CUCM, the default validity of the self-signed certificate is for 5 years. In case of Certificates signed by a CA, the validity is dependent on the Expiry date set by CA while issuing the certificate. Once a certificate is about to expire "Cisco Certificate Expiry Monitor"" service generates alarms. The severity of the alarm is dependent on how much time is left for the certificate to expire.
The impact to system operation depends on the which certificate expired. This information is contained in the alarm. If Tomcat certificate expired, while connecting to CUCM web pages, browser will throw an error stating certificate has expired. One can still ignore the warning and continue to connect to CUCM pages.
In case of Directory-trust, if Directory trust certificate uploaded to CUCM expires, CUCM may not be able to establish SSL connection with external LDAP server. The overall impact is that SSL connection between CUCM and other external Servers will fail.
Facility/Sub-Facility
/CERT
Cisco Unified Serviceability Alarm Definition Catalog
System/Cert Monitor
Severity
Critical (2)
Parameters
None
Recommended Action
Login to CUOS page. Go to Security->Certificate Management and re-generate the certificate that has expired (based on the information in alarm). This will generate a new self-signed certificate with a new expiry date. In case the certificate is signed by a CA, Generate a new CSR, send it to the CA, get the certificate signed by CA and upload the new certificate.
DeviceTypeMismatch
Device type passed on by the indicated device does not match the database configuration.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Critical (2)
Parameters
Database device type [Enum]Device type. [Enum]Name of device. [String]
Enum Definitions for DBDeviceType
Enum Definitions for DeviceType
Recommended Action
Verify database configuration for the indicated device.
CoreDumpFileFound
The new core dump files have been found in the system.
Facility/Sub-Facility
CCM_TCT_LPMTCT
Cisco Unified Serviceability Alarm Definition Catalog
System/LpmTct
Severity
Critical (2)
Parameters
TotalCoresFound [String] CoreDetails [String] Core1 [String] Core2 [String] Core3 [String] Core4 [String] Core5 [String] Core6 [String]
Recommended Action
Use Trace and Log Central to collect the new core files and the corresponding service last trace log files, run gdb to get the back trace of each core file for further debugging.
Error-Level Alarms
The error-level alarm is 3 and you should investigate important devices or subsystems and determine if immediate action is needed. Errors that do not necessarily impact the ability of the service to continue to function and do not create a system outage. More related to device or subsystems.
An example would be a device or subsystem failing for an unexpected reason.
CallManagerFailure
Indicates a failure in the Cisco Unified Communications system.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Additional Text [Optional] [String] Host name of hosting node. [String] IP address of hosting node. [String] Reason code. [Enum]
Enum Definitions
Recommended Action
Monitor for other alarms and restart the Cisco CallManager service, if necessary.
CISCO-CCM-MIB
Part of ccmCallManagerAlarmEnable. See CISCO-CCM-MIB, page 7-1 in Chapter 7, "Cisco Management Information Base."
SDLLinkOOS
SDL link to remote application out of service.This alarm indicates that the local Cisco CallManager has lost communication with the remote Cisco CallManager. This alarm indicates network errors or a nonrunning remote Cisco CallManager.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Remote IP address of remote application [String] Unique Link ID. [String] Local node ID [UInt] Local Application ID. [Enum]RemoteNodeID [UInt] Remote application ID. [Enum]
Enum Definitions for LocalApplicationID and RemoteApplicationID
Recommended Action
Investigate why the remote Cisco CallManager is not running or whether a network problem exists.
SDLLinkAppProtocol
SDL link connection was refused. This alarm indicates that the local Cisco CallManager is unable to establish communication with the remote Cisco CallManager due to a protocol version mismatch.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Remote Application Link Protocol Version [String] Local Application Link Protocol Version [String] Remote Node ID [UInt] Remote Application ID [Enum]Remote Application Version [String]
Enum Definitions for RemoteAppId
Recommended Action
Determine the release numbers of the local and remote Cisco CallManager servers. If the releases do not match, it is possible that the local and remote Cisco CallManager servers cannot communicate due to protocol changes. To correct the problem, upgrade the appropriate Cisco CallManager so that the versions of the local and remote Cisco CallManager servers match.
BChannelOOS
The B-channel is out of service. The B-channel indicated by this alarm has gone out of service. Some of the more common reasons for a B-channel to go out of service include are as follows:
•
•
•
•
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Unique channel Id [String] Device Name. [String] Reason. [Enum]Channel Id. [UInt]
Enum Definitions
•
Recommended Action
Check the Cisco Unified CM advanced service parameter, Change B-channel Maintenance Status to determine if the B-channel has been taken out of service intentionally; Check the Q.931 trace for PRI SERVICE message to determine whether a PSTN provider has taken the B-channel out of service; Reset the MGCP gateway; Check the speed and duplex settings on the Ethernet port.
DChannelOOS
The D-channel is out of service. D-channel indicated by this alarm has gone out of service. Common reasons for a D-channel going out of service include losing T1/E1 cable connectivity; losing the gateway data link (Layer 2) due to an internal or external problem; or gateway reset.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Channel Id. [UInt] Unique channel Id [String] Device Name. [String] Device IP address [String] Reason. [Enum]
Enum Definitions
•
Recommended Action
Check the connection of the T1/E1 cable; reset the gateway to restore Layer 2 connectivity; investigate whether the gateway reset was intentional. If the reset was not intentional, take steps to restrict access to the Gateway Configuration window in Cisco Unified Communications Manager Administration and the gateway terminal.
DeviceTransientConnection
There was a transient connection attempt. A connection was established and immediately dropped before completing registration. Incomplete registration may indicate a device is rehoming in the middle of registration. The alarm could also indicate a device misconfiguration, database error, or an illegal/unknown device trying to attempt a connection.
Release7.1
IPv6 parameters added: IPV6Address[Optional][String], IPAddrAttributes[Optional][Enum], and IPV6AddrAttributes[Optional][Enum].
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Device IP address [Optional].[String]
Device name [Optional].[String]
Device MAC address [Optional].[String]
Protocol.[String]
Device type. [Optional][Enum]
Reason Code [Optional].[Enum]
Connecting Port [UInt]
Registering SIP User. [Optional].[String]
IPV6Address [Optional].[String]
IPAddressAttributes [Optional].[Enum]
IPV6AddressAttributes [Optional].[Enum]
Enum Definitions for DeviceType
Enum Definitions
Enum Definitions for IPAddrAttributes
Enum Definitions for IPV6AddrAttributes
Recommended Action
No action is required if this event was issued as a result of a normal device rehome.
DeviceUnregistered
A device that was previously registered with Cisco CallManager has unregistered. This event may be issued as part of normal unregistration event or due to some other reason such as loss of keepalives. In cases of normal unregistration if the Reason Code is CallManagerReset, CallManagerRestart, or DeviceInitiatedReset, the alarm severity is lowered to Informational (6).
Release7.1
Parameters added: IPV6Address,IPAddrAttributes, and IPV6AddrAttributes.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Device name. [String]
Device MAC address [Optional]. [String]
Device IP address [Optional]. [String]
Protocol. [String]
Device type. [Optional] [Enum]
Device description [Optional]. [String]
Reason Code [Optional]. [Enum]
IPV6Address [Optional]. [String]
IPAddressAttributes [Optional]. [Enum]
IPV6AddressAttributes [Optional]. [Enum]
Enum Definitions for DeviceType
Enum Definition
Enum Definitions for IPAddrAttributes
Enum Definitions for IPV6AddrAttributes
Recommended Action
No action is required if unregistration of this device was expected. If the Reason is ConfigurationMismatch, go to the Device configuration page, make a change to the Description field, save, then reset the device.
SIPLineRegistrationError
A SIP line attempted to register with CallManager and failed due to the error indicated in the Reason Code parameter. The alarm could indicate a device misconfiguration, database error, or an illegal/unknown device trying to attempt a connection.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Device IP address. [String] Device Port. [UInt] Device name [Optional]. [String] Device MAC address [Optional]. [String] Device type. [Optional] [Enum]Reason Code [Optional]. [Enum]Connecting Port [UInt] Configured DNs. [String] Registering SIP User. [String]
Enum Definitions for DeviceType
Enum Reason
1
Unknown
2
MisconfiguredDirectoryNumber
3
MalformedRegisterMessage
4
AuthenticationError
5
InitializationError
6
MaxLinesExceeded
Recommended Action
Verify the directory numbers on the device itself match the directory numbers configured in the CCM database.
ConnectionFailure
Cisco CallManager failed to open TLS connection for the indicated device.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Device Name. [String] IP Address [String] Device type. [Optional] [Enum]Device description [Optional]. [String] Reason code [Enum]
Enum Definitions for DeviceType
•
Enum Reasons
Recommended Action
Check the Security profile of the indicated device.
StationEventAlert
Station device sent an alert to Cisco CallManager.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Protocol [String] TCP ProcessID [String] Device Text [String] Param1 [UInt] Param2 [UInt]
Recommended Action
Ensure that the configuration for identified device is proper.
StationTCPInitError
A socket error or IP address error occurred during Station TCP initialization.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Error Number [String] ErrorCode [Int]
Recommended Action
Check the network to ensure it is up and running; check IP address configuration.
TspError
TSP database configuration error was encountered.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Port IsoEthPort [UInt] Port DSL [UInt] Name of Device [String]
Recommended Action
Investigate configuration for identified device.
TspTimeout
TSP timeout was encountered while trying to read database configuration.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Port IsoEthPort [UInt] Port DSL [UInt] Name of Device [String]
Recommended Action
Investigate configuration for identified device.
TspCorrupt
TSP database configuration error was encountered.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Port IsoEthPort [UInt] Port DSL [UInt]
Recommended Action
Investigate configuration for identified device.
DnTimeout
Timeout was encountered while trying to read pattern or directory number configuration.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Port IsoEthPort [UInt] Port DSL [UInt]
Recommended Action
Investigate configuration for identified device.
NotEnoughChans
Call attempt was rejected because requested gateway channels could not be allocated.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Port IsoEthPort [UInt] Port DSL [UInt]
Recommended Action
Add more gateway resources.
DaTimeOut
The digit analysis component in Cisco Unified Communications Manager has timed out. This can occur because Cisco Unified Communications Manager is busy and the resulting delay in processing request and response messages caused the digit analysis component to time out.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Recommended Action
In the Service Parameter Configuration window in Cisco Unified CM Administration, check the Cisco CallManager service parameter, Digit Analysis Timer, to confirm that the default value is in use. Use RTMT to monitor the system resources and correct any system issues that might be contributing to high CPU utilization on Cisco Unified CM.
DeviceInitTimeout
Device initialization timeout occurred.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Device Name [String] Protocol [String] Side Number [UInt]
Recommended Action
Investigate the identified device.
NumDevRegExceeded
Number of registered devices exceeded.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Maximum Devices [Int]
Recommended Action
Investigate the number of registered devices.
MtpNoMoreResourcesAvailable
No more MTP resources available.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Recommended Action
Install additional MTP or transcoder resources.
MohNoMoreResourcesAvailable
No more MOH resources available.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Recommended Action
Install additional MOH resources.
ConferenceNoMoreResourcesAvailable
No more Conference resources available.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Recommended Action
Install additional Conference resources.
AnnunciatorNoMoreResourcesAvailable
No more Annunciator resources available.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Recommended Action
Install additional annunciator resources.
RsvpNoMoreResourcesAvailable
No more RSVP resources available.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Recommended Action
Install additional RSVP resources.
MaxCallsReached
Maximum calls reached. Maximum number of simultaneous connections in a Cisco CallManager node has been reached.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Description [Int]
Recommended Action
Investigate number of active calls in the Cisco CallManager node.
DBLException
An error occurred while performing database activities. A severe database layer interface error occurred. Possible causes for this include the database being unreachable or down or a DNS error.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
ErrorCode [Int] ExceptionString [String]
Recommended Action
Review the System Reports provided in the Cisco Unified Reporting tool, specifically the Cisco Unified CM Database Status report, for any anomalous activity. Check network connectivity to the server that is running the database. If your system uses DNS, check the DNS configuration for any errors.
ICTCallThrottlingStart
Cisco CallManager stops handling calls for the indicated H323 device due to route loop over H323 Trunk Device Name. Cisco CallManager has detected a route loop over H323 Trunk. As a result it has temporarily stops accepting calls for the indicated H323 device.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
H323 Trunk Device Name [String] IP Address [String] Device type. [Optional] [Enum]Device description [Optional]. [String]
Recommended Action
Administrator needs to remove route loop.
Enum Definitions for DeviceType
125—TRUNK
ICTCallThrottlingEnd
Cisco CallManager starts handling calls for the indicated H323 device which was stopped due to route loop. Cisco CallManager has resumed normal state and starts accepting calls for indicated H323 device.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
H323 TrunkDevice Name. [String] IP Address [String] Device type. [Optional] [Enum]Device description [Optional]. [String]
Recommended Action
Administrator needs to remove route loop.
Enum Definitions for DeviceType
•
CodeYellowEntry
CallManager has initiated call throttling due to unacceptably high delay in handling incoming calls.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Expected Average Delay [UInt] Entry Latency [UInt] Exit Latency [UInt] Sample Size [UInt] Total Code Yellow Entry [UInt] High Priority Queue Depth [Long] Normal Priority Queue Depth [Long] Low Priority Queue Depth [Long]
Recommended Action
Determine the reason for high CPU usage in the High priority and Normal priority queues (Cisco CallManager System Performance object).
CodeYellowExit
CodeYellowExit. CCM Call throttling terminates when the delay in handling incoming calls falls below the exit latency.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Expected Average Delay [UInt] Entry Latency [UInt] Exit Latency [UInt] Sample Size [UInt] Time Spent in Code Yellow [UInt] Number of Calls Rejected Due to Call Throttling [UInt] Total Code Yellow Exit [UInt] High Priority Queue Depth [Long] Normal Priority Queue Depth [Long] Low Priority Queue Depth [Long]
Recommended Action
Determine the reason for high CPU usage in the High priority and Normal priority queues (Cisco CallManager System Performance object).
CodeRedEntry
CallManager is not able to recover, even after attempting call throttling. The CallManager service is shut down.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Expected Average Delay [UInt] Entry Latency [UInt] Exit Latency [UInt] Sample Size [UInt] Code Yellow Duration [UInt] Number of Calls Rejected Due to Call Throttling [UInt] Total Code Yellow Entry [UInt] Total Code Yellow Exit [UInt] High Priority Queue Depth [Long] Normal Priority Queue Depth [Long] Low Priority Queue Depth [Long]
Recommended Action
Determine the reason for high CPU usage in the High priority and Normal priority queues (Cisco CallManager System Performance object).
DeviceCloseMaxEventsExceeded
Due to receiving an unacceptably high number of events from this Skinny device, it is forced to close and reregister.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
DeviceCloseMaxEventsExceededTotal Events Received [UInt] IP Address [String] TCP Handle [String] Max Events Allowed [UInt] Number Of Skinny Device Throttled [UInt]
Recommended Action
Check the Skinny device to determine the reason for the high number of events.
TotalCodeYellowEntry
CallManager has initiated call throttling due to unacceptably high delay in handling incoming calls.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
TotalCodeYellowEntryTotal Code Yellow Entry [Int]
Recommended Action
Determine the reason for high CPU usage in the High priority and Normal priority queues (Cisco CallManager System Performance object).
ThrottlingSampleActivity
ThrottlingSampleActivity. CallManager has initiated call throttling due to unacceptably high delay in handling incoming calls.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
CallManager/CallManager
Severity
Error (3)
Parameters
Throttling Sample Activity [Int]
Recommended Action
Determine the reason for high CPU usage in the High priority and Normal priority queues (Cisco CallManager System Performance object). This indicates that a malicious call is detected in Cisco CallManager and Malicious Call Identification (MCID) feature is invoked.
PktCapLoginFailed
Login failed for getting captured packet or key file. Indicated the user cannot get the packet or key file.
Facility/Sub-Facility
CCM_CALLMANAGER-CALLMANAGER
Cisco Unified Serviceability Alarm Definition Catalog
