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

Strange CM behaviour on failover.

Hi,

I have a cluster of 2 CM servers. One primary/Active i.e subscriber and the other is a secondary/Backup i.e publisher. This is a test lab with 3 IP Phones. The TFTP services is only activated on the Publisher server. Under normal conditions, with the Subcriber server active, all works well. I see that all phones registered with the subscriber. However when I manually shutdown the Subscriber or remove the network connectivity of the sub server, I get some strange issues.

The 3 IP Phones now register with the backup server i.e the Publisher but I can only call 1 IP Phone from the other 2 IP Phones. Also when I try to call back the other two IP Phones from the same Ip Phone I get a busy tone.

Can someone tell how to troubleshoot this ??

Thanks

Brgds

renzil

1 ACCEPTED SOLUTION

Accepted Solutions
Bronze

Re: Strange CM behaviour on failover.

Well, the trace doesn't show anything obvious (at least to me). I can't find what "deleteTransGivenCiTrans" means on cisco.com.

"NO ENTRY FOUND IN TABLE" looks like database error.

You can ignore MOH errors.

Try this: remove phones from CCM and add them back with different DN. What happens now?

10 REPLIES
Bronze

Re: Strange CM behaviour on failover.

Try resetting phones from CM. Can you ping phones IP from CM? Also if you are using partitions and css make sure phones are not restricted to call each other.

Community Member

Re: Strange CM behaviour on failover.

Hi,

Thanks for your suggestions.

I can reset all the 3 IP Phones from the CM ( Backup mode ) Ping too work fine. I do not have any partitions or css configured yet.

Any more suggestions ?

Brgds

renzil

Bronze

Re: Strange CM behaviour on failover.

Turn on tracing. That should tell what's going on.

This url shows how to configure tracing (for 4.12).

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00802de951.html

Community Member

Re: Strange CM behaviour on failover.

Hi,

Following is the output of the trace

09/30/2005 14:05:45.396 CCM|DeviceUnregistered - Device unregistered. Device name.:MOH_10.1.1.2 Device IP address.:10.1.1.2 Device type. [Optional]:70 Reason Code [Optional].:8 App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:HH_PUB|<:STANDALONECLUSTER><:HH_PUB><:ALARMMOH_10.1.1.2><:MOH_10.1.1.2>

09/30/2005 14:14:29.331 CCM|MRM::waiting_MrmAllocateAnnResourceErr - ERROR - no resources are available -- ci = 16777421|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.12><:SEP001319149D08>

09/30/2005 14:14:31.706 CCM|Cc::deleteTransGivenCiTrans, cannot find the transaction with CI 0|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.12><:SEP001319149D08>

09/30/2005 14:14:52.988 CCM|MRM::waiting_MrmAllocateAnnResourceErr - ERROR - no resources are available -- ci = 16777426|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.10><:SEP0013191F48AC>

09/30/2005 14:14:56.800 CCM|Cc::deleteTransGivenCiTrans, cannot find the transaction with CI 0|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.10><:SEP0013191F48AC>

09/30/2005 14:15:00.894 CCM|MRM::waiting_MrmAllocateAnnResourceErr - ERROR - no resources are available -- ci = 16777429|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.10><:SEP0013191F48AC>

09/30/2005 14:15:03.535 CCM|Cc::deleteTransGivenCiTrans, cannot find the transaction with CI 0|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.10><:SEP0013191F48AC>

09/30/2005 14:15:18.676 CCM|ConnectionManager - wait_AuDisconnectRequest(16777430,16777431): NO ENTRY FOUND IN TABLE|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.11><:SEP00131982150F>

09/30/2005 14:15:23.895 CCM|MRM::waiting_MrmAllocateAnnResourceErr - ERROR - no resources are available -- ci = 16777434|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.11><:SEP00131982150F>

09/30/2005 14:15:26.786 CCM|Cc::deleteTransGivenCiTrans, cannot find the transaction with CI 0|<:STANDALONECLUSTER><:HH_PUB><:1><:10.1.1.11><:SEP00131982150F>

Any suggestions ?

Thanks

brgds

Renzil

Bronze

Re: Strange CM behaviour on failover.

Well, the trace doesn't show anything obvious (at least to me). I can't find what "deleteTransGivenCiTrans" means on cisco.com.

"NO ENTRY FOUND IN TABLE" looks like database error.

You can ignore MOH errors.

Try this: remove phones from CCM and add them back with different DN. What happens now?

Community Member

Re: Strange CM behaviour on failover.

I have seen these types of issues when the DB replication between the Pub and Sub is broken.

You can use the DBHelper utility on the pub to verify the status of your replication. This is the best way to verify and fix SQL replication issues.

If you don't have the utility, you can go to Enterprise Manager in SQL and verify your Publication and Subscription replication is active and running.

Cisco Employee

Re: Strange CM behaviour on failover.

All the trace shows is an MoH server unregistering and a problem with allocating a resource to play the annunciator message. There is not enough trace here to see what is happening. Is this from the Sub (primary) or Pub (secondary)?

We will want to see more of the trace. Starting with where the failed call starts.

Kevin

Community Member

Re: Strange CM behaviour on failover.

hey that worked !!!

I deleted the dn's and added new dn's. Now it works.

Thats very very strange. what made u suggest this option ????

Thanks a lot. I was to open a tac case today, if things did not work out.

Brgds

Renzil

Bronze

Re: Strange CM behaviour on failover.

Well, I'm not sure what happend but sometimes SQL table has bogus entries that don't make sense. So CM web interface shows the configuration is OK when in fact it is not. I've seen it before where a device info was missing for a particular DN. It's always a good idea to have TAC involved before manually changing SQL table entries.

Community Member

Re: Strange CM behaviour on failover.

Dear Renzil, As I remember the publisher is always to be on if it fails then one cannot add or modify the IP phones, though the subscriber has the database with it just to support the IP phones. Publisher is supposed to be the primary.So when you shut the publisher Callmanager should not be able to do any modifications.

Regards,

Ivan

233
Views
0
Helpful
10
Replies
CreatePlease to create content