Thanks Anthony.

By setting the parameter, the phones reset automatically. Are you saying that I 
have to reset the TFTP server before setting the parameter?

Our previous scenario, which was pretty much just an upgrade using new hardware 
required this. We couldn’t get it to work without it. Feedback from the list 
way back way confirmed this requirement. We were installing new servers and 
restoring from DRS in the backup and that was enough to modify the certificates 
enough.

Our current scenario will be not only upgrading, but moving from IP address 
defined server to hostname defined servers and public certificates, so, I’m 
guessing we totally need this.





---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | le...@uoguelph.ca<mailto:le...@uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: Anthony Holloway [mailto:avholloway+cisco-v...@gmail.com]
Sent: Wednesday, February 28, 2018 12:16 PM
To: Lelio Fulgenzi <le...@uoguelph.ca>
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 
<cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Prepare Cluster for Rollback to pre 8.0 Parameter - 
still valid for moving to different hardware?

Your first step is incorrect.  You need to restart TFTP and TVS first, then 
reset phones.

Now, the scenario you described, you wouldn't even need this, would you?  
Because your servers and more importantly, certificates, are staying the same, 
you're just upgrading the application.  Unless of course you were planning on 
regenerating certs before moving phones over, but you didn't say that, and you 
might as well just wait until the phones are moved, then regenerating certs is 
actually easy, and doesn't require special considerations like cert combo and 
rollback.  You just regen one server at a time, resetting the phones so they 
learn about the new server identity, while still trusting one or more servers 
in the cluster.

But, yes, this is the main go to method for me when migrating phones from one 
cluster to another (not hardware).  Keep in mind, that if the old cluster is 
staying around, and phones need to move between them, then sharing/combining 
certs would be the answer.

I think I said everything correct...  Brian Meade seems to be the Chief 
Security Office around these parts, so let's see what he says.


On Wed, Feb 28, 2018 at 10:58 AM Lelio Fulgenzi 
<le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote:

In the past, we used this parameter to prepare phones to be homed to a 
different set of hardware.

For example:


  *   Set parameter to true, reset phones.
  *   In an offline network, restore from DRS and upgrade servers
  *   During a maintenance window, turn off version A servers and turn on 
version B servers
  *   Wait for TFTP timeout/reset for phones to begin talking with new TFTP 
server
  *   Once all phones are registered, set parameter to false, reset phones

Just wondering if this is still the way to get phones registered to different 
cluster hardware.

Lelio


---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354<tel:(519)%20824-4120> | 
le...@uoguelph.ca<mailto:le...@uoguelph.ca><mailto:le...@uoguelph.ca<mailto:le...@uoguelph.ca>>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs><http://www.uoguelph.ca/ccs> | 
@UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to