Cisco CUPS High Availability Issue

[osama_abdo]

Hello,

Any one please could help with the below error i'm facing on CUPS 8.5.2

It's always in Initialization mode

And notification tells nothing

[Youssef Aoufi]

Hi Osama,

We are facing the exact same problem.

Did you found a solution ?

Thanks in advance

[Todd Volz]

Did you get any resolution or direction on this issue as I have run into the same problem.  I am running CUPS 8.6.4 with my CUPS servers in different subnets across a 1 ms "wan" (in different parts of the same city over dwdm fiber ring).

[roboliveira]

Was there any update on this?  I am running into something similar with CUPS 8.6.4 where all my services on the secondary node are in STARTING.  I have given time for replication, but it's been like this for days.

[Jason Newman]

All,

Being stuck in the "initializing" state typically has to do with name resolution of the other server (especially in different subnets).  I haven't narrowed down the EXACT requirements, but I believe it to be one of the following is required:

1) @domain.com

2) @SIPProxydomain.com

Where domain is the domain configured on the underlying linux system and can be found via the command "show network eth0 detailed".  SIPProxy domain is the instant message domain that all the users have.  This can be found under System -> Cluster topology -> Settings.  While you are in this menu and your CUPS nodes are in different subnets please ensure the routing mechanism is changed to "router to router" and restart the XCP Router.

You can verify the 2 lines above can be resolved from the CUPS node CLI by the command:  "utils network host "

Regards,

Jason

[roboliveira]

Thanks for the response. 

I tried all of this.  Also made sure to put both servers in the same domain (They were in seperate domains, seperate subnets) and also tried changing the server names in the cluster to IP only.  No luck with any of it. I am able to do forward and reverse lookups from both servers and both dns servers that I have specified.  The proxy domain is the same as the domain set on the servers.

[Christos Georgiadis]

Set the server recovery manager service to debug tracing level, bounce the service and collect the logs.

That should give you some clues as to what the issue is. As Jason said, more often than not it's a name resolution issue (or reverse)

HTH,

Christos

[philippe.cousineau]

Anyone have an update on this issue ? I have the same problem here

[Christos Georgiadis]

Hi Philippe,

You can set the logs as per my post above

That should normally tell you what's wrong

Thanks,

Christos

[roboliveira · Accepted solution]

I was able to resolve this issue.  I rebuilt the Subscriber on recommendation from TAC and I ran a utils dbreplication dropadmindb and a utils dbreplication reset and this fixed it.

Thanks for the suggestions.

[philippe.cousineau · Accepted solution]

1

I rebuilt the subscriber

I still had the issue... then..

2 I  Disable HA

Then Reboot the servers(starting with the Publisher, wait until this server is completely up and running before the restart of the Sub)

Then re-enable HA

And everything was fine after.

[Coty Condry]

For reference, the CUPS high availibility settings in 10 and 10.5 are in CUCM Admin, under System > Presence Redundancy Groups.

Reference: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/configAdminGuide/10_5_1/CUP0_BK_CE43108E_00_config-admin-guide-imp-105/CUP0_BK_CE43108E_00_config-admin-guide-imp-105_chapter_00.html#CUP0_RF_P97794C4_00