cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1411
Views
0
Helpful
1
Replies

Upgrading a Mixed Mode Cluster considering roll-back

andrea_spo
Level 1
Level 1

I'm planning an upgrade of a CUCM 8.6.2(2a) to the 8.6.2(2 SU2) and I have some doubt about the roll-back procedure since the cluster is in Mixed Mode.

Since we had a lot of problem with the installation of the first sub and now we adding anoter sub to the cluster, I would use the scheduled downtime to re-install the first sub and then add the second one using just one token to update the ctl.

The environment is described below:

-     Two servers cluster with one Pub and one Sub upgraded them to a bugfix version

-     Cluster is in Mixed Mode and SIP IP Phones have the CTL uploaded to them

-     TFTP is NOT encrypted

My action plan:

-     Remove Security Profile from IP Phones

-     Clone the VMs

-     Shutdown SUB 1 and PUB 1 OLD

-     Power up cloned VMs

-     Destroy SUB 1 (cloned)

-     Upgrade PUB (cloned)

-     Re-install SUB1 and add SUB2 with upgrade to 8.6.2(2 SU2)

-     Test and eventually roll-back to OLD VMs

I've choose to act this way because I want to have an easy way to roll back to previous version, my concern is about the IP Phones registration on the Cloned Cluster and eventually on the rolled back infrastructure. As per my understanding, IP Phones Thate have not the CTL File uploaded to them will register to other clusters, I never tryed but I got to test, do you have any experience on this topic? In your opinion, will this procedure work using just one token?

Can I remove and re-use a token that I've already added to a CTL, but not used to sign any CTL yet?

Thanks in advance for you answers

Andrea

1 Accepted Solution

Accepted Solutions

Akhil Behl
Level 1
Level 1

Hi Andrea,

So, if I understand you correctly, you wish to upgrade to an SU from the current release of CUCM on 8.6, which is in mixed mode.

Cloning of VM's for backup doesn't seem to be a supported method. There's new identity which can be utilized to deploy subscribers to reduce the deployment time

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm-on-virtualized-servers_chapter_00.html#CUCM_RF_NED43337_00

Moreover, the right approach in the VM world will be to create a new cluster with identical IP's and FQDN (has to be offline from production network) and take a backup from production cluster and then restore it on new cluster. Bring new cluster online in maintenance window and take off old cluster from production network. You could of course have some phones registered with new cluster to see if its working ok before rolling over the others to it. Since, certificates are carried as part of DRS you should not have to worry about that part. This way, you can preserve the identity of earlier cluster and need not worry about creating or removing VM's within that cluster.

Also, if you wish to use just 1 etoken ensure that it was used when CTL was generated as with a new token which isn't defined previously, CTL will not go through. This is crucial when you install second Sub.

Regards,


Akhil Behl
Senior Network Consultant
akbehl@cisco.com

Author of “Securing Cisco IP Telephony Networks”
http://www.ciscopress.com/title/1587142953

Akhil Behl Solutions Architect akbehl@cisco.com Author of “Securing Cisco IP Telephony Networks” http://www.ciscopress.com/title/1587142953

View solution in original post

1 Reply 1

Akhil Behl
Level 1
Level 1

Hi Andrea,

So, if I understand you correctly, you wish to upgrade to an SU from the current release of CUCM on 8.6, which is in mixed mode.

Cloning of VM's for backup doesn't seem to be a supported method. There's new identity which can be utilized to deploy subscribers to reduce the deployment time

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/virtual/CUCM_BK_CA526319_00_cucm-on-virtualized-servers_chapter_00.html#CUCM_RF_NED43337_00

Moreover, the right approach in the VM world will be to create a new cluster with identical IP's and FQDN (has to be offline from production network) and take a backup from production cluster and then restore it on new cluster. Bring new cluster online in maintenance window and take off old cluster from production network. You could of course have some phones registered with new cluster to see if its working ok before rolling over the others to it. Since, certificates are carried as part of DRS you should not have to worry about that part. This way, you can preserve the identity of earlier cluster and need not worry about creating or removing VM's within that cluster.

Also, if you wish to use just 1 etoken ensure that it was used when CTL was generated as with a new token which isn't defined previously, CTL will not go through. This is crucial when you install second Sub.

Regards,


Akhil Behl
Senior Network Consultant
akbehl@cisco.com

Author of “Securing Cisco IP Telephony Networks”
http://www.ciscopress.com/title/1587142953

Akhil Behl Solutions Architect akbehl@cisco.com Author of “Securing Cisco IP Telephony Networks” http://www.ciscopress.com/title/1587142953