Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

CUCM 9.1.1a IDS Engine Attention alarm for CDR files

Has anyone seen this error before?

Is the IDS engine preventing CDR files from being written to database or similar?

Machine Name: CUCM1

Severity: Error

App ID: Cisco Database Layer Monitor

Message: : 24120:

CUCM1: Jul 10 2013 04:00:29.233 UTC : %UC_-3-UNKNOWN_ALARM:IDSEngineAttention: %[class_id=cucm1_ccm9_1_1_20000_5--1][class_msg=CDR][specific_msg= :ATTENTION:-1:CDR: ATS and/or RIS files spooled to disk.:/var/log/active/cm/log/informix/ris/ris.g_sscm1_ccm9_1_1_20000_5.g_sscm][ClusterID=StandAloneCluster][NodeID=CUCM1]:

10 REPLIES
VIP Purple

CUCM 9.1.1a IDS Engine Attention alarm for CDR files

Hi,

I was just checking the bugs related to the problem but could not find any.

Just to cross-check is DBReplication fine if there is PUB and SUB.

regds,

aman

New Member

Hi All, Has anyone managed to

Hi All,

 

Has anyone managed to resolve this and if yes can you please share how it was resolved?

 

Thanks and Regards,

 

Kanes.R

CUCM 9.1.1a IDS Engine Attention alarm for CDR files

I'm seeing the same error message on multiple clusters with 8.6.2-22900.  DB Replication is good. 

I'm puzzled how, if an error is unknown, is the alarm being triggered? 

New Member

CUCM 9.1.1a IDS Engine Attention alarm for CDR files

Hello,

Did you ever find what this alert is? I've seen it in 9.1.1 as well as 9.1.2. And it's not in the definitions catalog. Doesn't seem to be impacting though.

thx

J

New Member

++ Sometimes the I/O wait

This can be caused due to replication issue:

++ Correct any misspelled server group names or incorrectly formatted sqlhosts entries & check dbreplication status

++ if issue found with db, perform dbreplication reset

==========================================

++ Sometimes the I/O wait time (in VMware deployment when storage is remote SAN) could cause such issues

++ Restarting Cisco Tomcat service might resolve the above issue

++ On UCS server, needs further investigation to identify firmware updates and any detected hardware component issues.

++ Also verify the SAN Connectivity, UCS & VMware issues if any 

++ Try restart the server and check

===================================

New Member

Hi, Anyone have the

Hi,

 

Anyone have the resolution ? We are getting it intermittantly . No DB replication issue . Storage is remote SAN and we did not have any issue on the SAN.

Thanks.

 

Cisco Employee

Hi Kelvin,Most of the cases

Hi Kelvin,

Most of the cases related to this alert have been fixed by running 'utils dbreplication repair' on the node where the alert is generated. Even though you may see the replication status as 2, can you try running the above command and see if the issue still persists.

HTH

Manish

New Member

Hi , Thanks.Since it is the

Hi ,

 

Thanks.

Since it is the production and no issue on the user end , i will not take the risk to run it . At the moment it just intermittant getting the alert . It has stop since the last 3 occur and clean for 24 hour . From the ESX , we could see there is little spike during the time we received alert .

 

Definately will try the db repair if it keep happening.

New Member

Hi Manish, Thank you for

Hi Manish,

 

Thank you for suggesting the fix. We had same issue on one of the subscriber(11 server cluster). We are supporting contact center(UCCE)  with outbound dialing as well. The subscriber in question was one of our main serve talking to CVP's and PG's.

I was confident about the fix after reading your post but we ended up going to TAC as we needed a fallback plan.

TAC implemented same solution. Following are steps in sequence:

1.  Try dbreplication repair [affected server name] >> from publisher server.

2. It will take close to 1 hour for a cluster supporting approx 6000 phones. The step 1 command wil stop the alarms. However, there may still be table mismatches found by repair process.

3. If there are table mismatches found by repair process >> Next steps is to do utils dbreplication repair all >> on publisher. 

I know it looks scary.. as I was  a bit nervous to run this while agents were taking calls in UCCE environment(24x7) but we needed to fix the mismatch.

4. It took another 1 hour but it fixed the table mismatches and the alarms. No more alarms received and DB looks good.

 

Thank you for suggesting the fix. I ended up showing this thread to  TAC engineer. :)

Regards,

Amarjeet

 

Cisco Employee

That's great Amar, thanks for

That's great Amar, thanks for sharing.

Manish

 

1582
Views
5
Helpful
10
Replies
CreatePlease login to create content