[cisco-voip] Migrating IP space

James Buchanan james.buchanan2 at gmail.com
Sun Apr 30 14:05:42 EDT 2017


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170430/5326c52b/attachment.html>


More information about the cisco-voip mailing list