Hello, This is expected behavior if I read this correctly: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/9_0_1/ipchange/CUCM_BK_C936116C_00_changing-ipaddress-hostname-cucm-90.html#wp69916%0A .
Thanks, James On Sun, Apr 30, 2017 at 6:54 PM, Ben Amick <bam...@humanarc.com> wrote: > V9.1.2, yeah, just IP change, along with DNS and NTP change as well > because we were migrating entire IP scopes, but no hostname or cluster > changes, no. > > > > *Ben Amick* > > Telecom Analyst > > > > *From:* Ryan Huff [mailto:ryanh...@outlook.com] > *Sent:* Sunday, April 30, 2017 7:04 AM > *To:* Gary Bates_Command Solutions <gba...@commandsolutions.com.au> > *Cc:* Ben Amick <bam...@humanarc.com>; cisco-voip@puck.nether.net > *Subject:* Re: [cisco-voip] Migrating IP space > > > > Ben, > > > > The "Prepare Cluster for Rollback to Pre 8.0" parameter in part, is used > to empty out the ITL and CTL files on each phone (the process to do that > involves more than just setting that parameter though). > > > > As I recall, you enable the parameter, bounce TVS on each server to clear > out all entries in the ITL/CTL files of each phone in TFTP, then bounce > TFTP on all nodes to refresh the cache list; lastly, reboot all phones to > trigger an ITL/CTL download from TFTP. You would check a the phones and > ITL/CTL should be empty. > > > > This allows the phone to "blindly" trust new ITL/CTL connections without > verification. This is what you typically did when moving SBD phones between > clusters when the certs were different. > > > > Now why an IP change ONLY caused that, I'm not sure specifically without > seeming the files per-change compared to post-change. Other than to say > given the way ITL/CTL works; it suggests something changed with how the > ITL/CTL files on TFTP were signed and when the phones downloaded them after > the change, they couldn't verify ("trust") them with what they already had. > > > All you changed was the IP address of CUCM correct, nothing else? What > version of CUCM? > > > > Thanks, > > > > Ryan > > > > > > On Apr 30, 2017, at 6:20 AM, Gary Bates_Command Solutions < > gba...@commandsolutions.com.au> wrote: > > Very odd bug fix > > I not encountered this before, > > > > I thout the idea of named hostnames for the server wod alleviate the need > for any IP address dependency > > > > Did it resolve the phone connection bug ? > > > > Gary > > Sent from my iPhone > > > On 30 Apr 2017, at 3:19 pm, Ben Amick <bam...@humanarc.com> wrote: > > So I was performing an IP migration of systems tonight, and ran into an > issue where the ITL files on every system refused to connect to the new > IPs, despite the fact that the ITLs were based on the hostname of the > systems. I was instructed by TAC afterwards while trying to fix it that the > proper method, regardless of version change or not, if changing any > attributes of the CM, is to enable the enterprise parameter of something > along the lines of “Prepare for rollback for pre 8.0 migration” > > > > Anyone else familiar with this procedure? I find that to be a strange name > for something that needs to be turned on for so many different pieces of > work. > > > > *Ben Amick* > > Telecom Analyst > > > > > Confidentiality Note: This message is intended for use only by the > individual or entity to which it is addressed and may contain information > that is privileged, confidential, and exempt from disclosure under > applicable law. If the reader of this message is not the intended recipient > or the employee or agent responsible for delivering the message to the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If > you have received this communication in error, please contact the sender > immediately and destroy the material in its entirety, whether electronic or > hard copy. Thank you > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > <http://cp.mcafee.com/d/5fHCN0g40USyMqemnTXFK8CXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCS235DXCzB_HYCUU-PtDHTbFIFIsM--Ozt_G8EHnjlLtPBgY-F6lK1FJ4SCrLO8VZZdZV5dMTsSjDdqymoIToHMd9_7wrwCHIcfBisEeROQGmGncRAIrymS1dJRQ5lrCvmFnBPq9EVuvsdwLQzh0qmXiFqFsPmiNFtd40T8z7pOwhd40q5zh1hrrurpvdLEsL112s1OIs> > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > <http://cp.mcafee.com/d/k-Kr6wUg6h0SyMqemnTXFK8CXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCS235DXCzB_HYCUU-PtDHTbFIFIsM--Ozt_G8EHnjlLtPBgY-F6lK1FJcSCrLO8VZZdZV5dMTsSjDdqymoIToHMd9_7wrwCHIcfBisEeROQGmGncRAIrymS1dJRQ5lrCvmFnBPq9EVuvsdwLQzh0qmXiFqFsPmiNFtd40T8z7pOwhd40q5zh1hrrurpvdXHbE> > > > Confidentiality Note: This message is intended for use only by the > individual or entity to which it is addressed and may contain information > that is privileged, confidential, and exempt from disclosure under > applicable law. If the reader of this message is not the intended recipient > or the employee or agent responsible for delivering the message to the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If > you have received this communication in error, please contact the sender > immediately and destroy the material in its entirety, whether electronic or > hard copy. Thank you > _______________________________________________ > cisco-voip mailing list > 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