[cisco-voip] ITL issue - incomplete ITL files cached on TFTP ?

[Justin Steinberg]

Restarting TFTP on all nodes ended up fixing the issue.  I had to reset
phones afterwards and they basically did a reset, downloaded the new ITL
file, did another reset and then came back up.

All cluster nodes now have a TVS entry in the Trust List as viewed from the
phone LCD where before the TFTP restart they did not.

Wes - Thanks for checking and giving me some confidence. :)

On Fri, Mar 2, 2012 at 11:46 AM, Wes Sisk <wsisk at cisco.com> wrote:

> So far we have not seen any instance where just restarting TFTP triggers
> the need to delete ITLs.
>
> /wes
>
> On Mar 2, 2012, at 11:18 AM, Justin Steinberg wrote:
>
> Looks like a couple of bugs are describing my problem:
>
> CSCth63321 - Incomplete ITL built after Sub is upgraded-TFTP service
> running on Sub
> CSCte58709 - Upgrading subscriber from pre 8.0 to 8.0+ requires restart
> TFTP, CUCM
>
> I am just unsure whether restarting the TFTP service as the notes describe
> will cause me to need to delete ITLs from the phones.
>
> On Fri, Mar 2, 2012 at 11:08 AM, Justin Steinberg <jsteinberg at gmail.com>wrote:
>
>> Worked on an upgrade last night from CM 7.1 to 8.5.
>>
>> After the upgrade I am having some ITL issues and think I have a couple
>> ways to work this out but wanted to run this past the group as I haven't
>> seen anyone with a specific issue like this.
>>
>> CM 8.5.1su2 with three CUCMs running CallManager & TFTP service
>>
>> What is not working:
>> -Corporate Directory - I am receiving host not found.  I verified on the
>> phone console logs that I am having a TVS/ITL issue.
>> -When I look at the contents of the ITL file on the phone LCD, I am only
>> seeing entries for TFTP and TVS on the server that TFTP is pointing to.  I
>> do not see any entries for other cluster nodes
>>
>> What is working:
>> -TFTP downloads (ring tones, etc) and TFTP config changes
>> -'show itl' from CLI is showing verification is ok on all nodes
>>
>> When I do a TFTP get and download the ITL file from CUCM and compare the
>> Md5 with the phone things match.  Show ITL on the CLI shows verification is
>> ok.   However, if I open the ITLSEPxxxxx.tlv file in notepad, I am not
>> seeing all of my servers listed in the ITL file.   However, when I do a
>> 'show ITL' from the CLI, all the servers show up in there.  It is almost
>> like the TFTP server has old versions of the ITL file (based on
>> switch-version times? etc) and was not updated as other subs went through
>> the switch-version from 7.1 to 8.5.
>>
>> On a hunch, I restarted the TFTP service on a sub that no phones actually
>> use for TFTP.  After restarting the TFTP service, if I download the
>> ITLSEPxxxx.tlv file and do a MD5, the value changed from pre-TFTP service
>> restart.  Now when I open the file in notepad, I see all of my CUCMs listed
>> in the ITL file.
>>
>> My question is, can I just restart the TFTP service on the sub that my
>> phones are actually using for TFTP?    I am thinking the TFTP restart will
>> cause the ITL to update (and include the other cluster nodes) but I am not
>> sure whether the phones will then fail with ITL mismatch or whether the
>> phones will update their ITL file and now include the other servers.
>>
>> I am also thinking of implementing the rollback to PRE 8.0 service
>> parameter, resetting the phones to clear the ITL and then restart the TFTP
>> service.
>>
>> Any thoughts on whether restarting the TFTP service on the node that
>> phones are using for TFTP will just update the existing ITL the phones use
>> with the other CM nodes or whether that will in effect create an entirely
>> new ITL which would then require manually deleting the ITL files ?
>>
>> Thanks
>>
>> Justin
>>
>>
>>
>>
> _______________________________________________
> 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/20120302/3df043d3/attachment.html>