[cisco-voip] CUCM 8.6(2) cluster slowness and UCCX issues when Subscriber goes offline

[Wes Sisk]

A few things sound slightly off here. First and foremost running CUCM 8.6.2 base.  8.6.2 included a CTI re-architecture that significantly impacted UCCE and UCCX integrations. The good news was increased CTI performance but with the clause "when it worked". There are numerous discussions on this mailer about those defects. Best to get to the latest 8.6.2SU at least.

I'm fuzzy on cluster over the WAN details but when last I looked the supported RTT was insufficient to go coast to coast. Is this within spec?

And finally logins when one node is offline. That should generally work. I believe UCCX has a dependency to primarily point to the publisher CUCM server and if that goes offline or becomes unreachable then trouble ensues.

Great job testing before deployment. Best to open a TAC case and work through this pre-production.

Regards,
Wes

On Dec 5, 2012, at 10:52 PM, Linsemier, Matthew wrote:


All,
 
We have implemented a new CUCM 8.6(2) Cluster (1 pub, 2 subs), UCCX 8.5(1)SU3, and CUPS 8.5(4) cluster for a greenfield move from an old CUCM 6.1(2) setup.  One publisher and subscriber are located at our HQ (West Coast) office and the second subscriber is located in our DR (East Coast) office.  The new cluster is configured for Active Directory LDAP integration and everything is working fantastic….
 
… until we took the subscriber in our DR location (East Coast) offline to do DR testing.  Phones that were registered to this subscriber re-registered with our HQ (West Coast) office without problem.  However, we have run into a few issues.
 
1.       UCCX Agents are having issues logging into the UCCX server even when they are in the same physical location.  I found a few bugs relating to slow LDAP login however they show as resolved.  Eventually some agents are able to log in, however there have been a few that still cannot get logged in.  Those UCCX agents that were logged in when the subscriber went down are working fine and didn’t notice anything
2.       All of the servers seem to be sluggish in regards to login’s.  It is taking upwards of 20-30 seconds to log into the administration pages and browse between functions.
 
I suspect that when we bring the Subscriber server back online the problem will be resolved.  This is a clean cluster, all current on patches, very clean configuration, running on physically MCS servers that are properly sized. However, we can’t have the inability for agents to log in as well as lose the ability to administer the system if this was to happen.  In this situation it’s controlled, but I’m worried about ones that are not (hardware failure, software crash, etc.).
 
Can someone provide some insight into what might be going on?
 
Sincerely,
 
<image001.gif>
 
 

Matthew M. Linsemier, CCNP / CCDP
Senior Network Engineer
The Doctors Company

( 517.324.6695
* mlinsemier at thedoctors.com
 


 
Confidentiality Notice: This message and any attachments hereto may contain confidential and privileged communications or information and/or attorney client communications or work-product protected by law. The information contained herein is transmitted for the sole use of the intended recipient(s). If you are not the intended recipient or designated agent of the recipient of such information, you are hereby notified that any use, dissemination, copying or retention of this e-mail or the information contained herein is strictly prohibited and may subject you to penalties under federal and/or state law. If you received this e-mail in error, please notify the sender immediately and permanently delete this e-mail.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121210/22cb0825/attachment.html>