[cisco-voip] Migrating IP space

[Anthony Holloway]

Nice find.  I agree with how you read that.  ITL will be regenerated and
will not be the same as pre-change ITL.

On Sun, Apr 30, 2017 at 2:06 PM James Buchanan <james.buchanan2 at gmail.com>
wrote:

> 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 <bamick at 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:ryanhuff at outlook.com]
>> *Sent:* Sunday, April 30, 2017 7:04 AM
>> *To:* Gary Bates_Command Solutions <gbates at commandsolutions.com.au>
>> *Cc:* Ben Amick <bamick at HumanArc.com>; cisco-voip at 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 <
>> gbates at 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 <bamick at 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 at 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 at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> 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/20170501/b269f74d/attachment.html>