[cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

Thu Dec 1 23:04:32 EST 2016

I forgot to put a smiley face in that email, I wasn't trying to be a jerk
with my Trivial File Transfer Protocol jab :)

On Thu, Dec 1, 2016 at 9:54 PM, Nick Barnett <nicksbarnett at gmail.com> wrote:

> By definition, TFTP is trivial.
>
> The service either needed deactivated or the server needed to restart.
> Either way, the TFTP server is going down to regenerate the certs.
>
> On Thu, Dec 1, 2016 at 4:41 PM, Ryan Huff <ryanhuff at outlook.com> wrote:
>
>> Anthony and James have highlighted one of the greater weaknesses of
>> thinking like an engineer.
>>
>> As an engineer, we look at TFTP service interruption and see all the
>> potential outcomes and things that could happen. We think about a firmware
>> download being interrupted on an endpoint and realize that it's simply a
>> phone reset to fix.
>>
>> That's great, if your end-users think like engineers and know what you
>> know.
>>
>> Although a nuclear power plant sitting in Japan or China is an extreme
>> example in my opinion, it is right on point. There are many, many
>> situations beyond a nuclear power plant where something as minor as a phone
>> firmware download being interrupted would be completely unacceptable to the
>> customer.
>>
>> In an SMB scenario with clearly defined maintenance windows, I can see
>> this not being such a big deal potentially. However if you're dealing with
>> a customer that counts endpoints in the tens of thousands (or even
>> thousands), it stands to reason that more than a few endpoints might be
>> impacted by something as, "trivial" as a TFTP service reset.
>>
>> It may be trivial in the permanency of the impact it could have on an
>> endpoint, but it is not trivial a enough to assume that it would not have
>> any impact to end-user performance, expectations or usability.
>>
>> -Ryan
>>
>> On Dec 1, 2016, at 5:26 PM, James Buchanan <james.buchanan2 at gmail.com>
>> wrote:
>>
>> If the endpoint is 8000 miles away from you and located in a nuclear
>> power plant, that TFTP interruption wasn't so trivial.
>>
>> On Thu, Dec 1, 2016 at 5:10 PM, Ben Amick <bamick at humanarc.com> wrote:
>>
>>> An endpoint in the middle of an upgrade has already entirely downloaded
>>> the firmware into memory, and would not be affected. If it is mid-download
>>> then it would have no affect other than breaking the operation and perhaps
>>> requiring a manual restart if it is coming off a factory reset
>>>
>>>
>>>
>>> *Ben Amick*
>>>
>>> Telecom Analyst
>>>
>>>
>>>
>>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>>> Behalf Of *Anthony Holloway
>>> *Sent:* Thursday, December 01, 2016 5:08 PM
>>> *To:* Nick Barnett <nicksbarnett at gmail.com>
>>> *Cc:* Cisco VoIP Group <cisco-voip at puck.nether.net>
>>> *Subject:* Re: [cisco-voip] Are there any gotchas to watch out for
>>> switching to FQDN server names from IP address server names?
>>>
>>>
>>>
>>> Is TFTP really that trivial?  What would happen to an endpoint, which is
>>> in the middle of a firmware upgrade, when you deactivate TFTP?
>>>
>>>
>>>
>>> On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett <nicksbarnett at gmail.com>
>>> wrote:
>>>
>>> I figured that a reboot would work, but TAC told me it wouldn't... and
>>> rather than experimenting, I just did what they said to do :)   Besides,
>>> deactivating TFTP is trivial and in a properly laid out deployment should
>>> have 0 impact.
>>>
>>>
>>>
>>> On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE <nateccie at gmail.com> wrote:
>>>
>>> A reboot does work. What the deal is the new https version of tftp (port
>>> 6972) does not restart with the service restart.  So it continues to use
>>> the old cert. But it does stop and start with a service deactivation and
>>> reactivation.  Before cucm 11 the tftp over http was only plain text (port
>>> 6970)
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>>
>>> On Nov 30, 2016, at 1:12 AM, James Buchanan <james.buchanan2 at gmail.com>
>>> wrote:
>>>
>>> Hello,
>>>
>>> If I remember right, it actually has to be deactivated under Service
>>> Management. It's not just restarting the service.
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>
>>>
>>> On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew <Derek.Andrew at usask.ca>
>>> wrote:
>>>
>>> Would a simple reboot accomplish the same as deactivating and activating?
>>>
>>>
>>>
>>> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett <nicksbarnett at gmail.com>
>>> wrote:
>>>
>>> I just thought I would share what happened with this, even though it is
>>> super old. Changing the node names to FQDN was mostly painless. The one
>>> thing that bit me was bug CSCuy13916. After changing the names of the
>>> nodes, the TFTP service needs to be DEACTIVATED and then re-activated in
>>> order to fully update the certificates.  Before taking those steps, I kept
>>> getting certificate errors from CuciLync, but afterwards, everything worked
>>> as designed.
>>>
>>>
>>>
>>> Other than that, any CTI route points (and any other device as well)
>>> that exist will fall to another node in the CMG. Not a big deal, just
>>> something to be aware of.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Nick
>>>
>>>
>>>
>>> On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett <nicksbarnett at gmail.com>
>>> wrote:
>>>
>>> We are on 10.0 and this cluster has been upgraded over the years from
>>> 8.0 to 8.6 to 10.0.  I know it used to be common practice to rip the host
>>> name out of a new node and put in the IP address. That's how we are set
>>> up... but now that I need to do some work with certs so that jabber and
>>> cucilync work properly, it's time to fix this.
>>>
>>>
>>>
>>> Is there anything I should watch out for? Anything that may bite me in
>>> rare cases? We have CER, CVP, CUC, UCCE and a rarely used IMP.
>>>
>>>
>>>
>>> I checked that each node has DNS enabled by looking at "show network
>>> eth0" on each sub. I also then looked up each FQDN from each node and they
>>> all resolve properly. As far as I know, that's about it.
>>>
>>>
>>>
>>> Thanks in advance!
>>>
>>>
>>> nick
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Copyright 2016 Derek Andrew (excluding quotations)
>>>
>>> +1 306 966 4808 <(306)%20966-4808>
>>>
>>> Communication and Network Services
>>>
>>> Information and Communications Technology
>>>
>>> Infrastructure Services
>>>
>>> *University of Saskatchewan *Peterson 120; 54 Innovation Boulevard
>>> Saskatoon,Saskatchewan,Canada. S7N 2V3
>>> Timezone GMT-6
>>>
>>> Typed but not read.
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <http://cp.mcafee.com/d/2DRPoQd6Qm7HKcThKOrKrhhpvpj73AjhOrhhpvpj7ffICQkmnTDNPPXxJ55MQsCzCZXETdAdlBoG2yrqKMSdKndASRtxIrsKr7fKCzCX3P_nUsOCqenSn-LsKCOYNObbXyr3bDbnhIyyHuWvaxVZicHs3jq9JwTvHEEzD61RTPhOrKr9PCJhbcmrIlU6A_zMdMjlS67OFek7qVqlblbCqOmdSBiRiVCIByV2Hsbvg5bdSaY3ivNU6CQhObb1I5-Aq83iTqlblbCqOmdbFEw48-q89A_zVEwS1oQg4qPIjSxEwDkQg6dDoCq8aJPd43JoCy2xykX4Vg8Cy2tjh0bwe70MQgk-9DUCy26G_gQgeNGGq80Qb6y3k48_ixEwFYjfNd44dl-x8SyyUrAd9z>
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <http://cp.mcafee.com/d/avndy0O921J5xWXzdQrICXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCNPXFEVKMY_R-7cFCzBZB_HTbFILcsyO-UCMOVORQr8EGTKDOEuvkzaT0QSCrodTWWa8VNwttYQsCXCOsVHkiP5CX5u1FfUY3s4RtxxYGjB1SKmBiRiVCIBztFkJkKpH9oKgGT2TQ1iPtyL0QDYu1FJ4syOMr1vF6y0QJSBiRiVCIBziWq812fCy2pfU-q8dwmd416IX4ZEq89Rd41zpS9Cy2HsPh0Xm9EwEoBeNek29EwDkQg2U3xMcd45fyp-9EwxGLQd43IqGCy0d2NEwR12fQEq8av4PYjh13lvEidEEK6XK0r>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <http://cp.mcafee.com/d/avndy0Od2hJ5xWXzdQrICXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCNPXFEVKMY_R-7cFCzBZB_HTbFILcsyO-UCMOVORQr8EGTKDOEuvkzaT0QSOrodTWWa8VNwttYQsCXCOsVHkiP5CX5u1FfUY3s4RtxxYGjB1SKmBiRiVCIBztFkJkKpH9oKgGT2TQ1iPtyL0QDYu1FJ4syOMr1vF6y0QJSBiRiVCIBziWq812fCy2pfU-q8dwmd416IX4ZEq89Rd41zpS9Cy2HsPh0Xm9EwEoBeNek29EwDkQg2U3xMcd45fyp-9EwxGLQd43IqGCy0d2NEwR12fQEq8av4PYjh13lvEidEEK6POOZMMU65W2U>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <http://cp.mcafee.com/d/avndz9J5xWXzdQrICXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCNPXFEVKMY_R-7cFCzBZB_HTbFILcsyO-UCMOVORQr8EGTKDOEuvkzaT0QSMrodTWWa8VNwttYQsCXCOsVHkiP5CX5u1FfUY3s4RtxxYGjB1SKmBiRiVCIBztFkJkKpH9oKgGT2TQ1iPtyL0QDYu1FJ4syOMr1vF6y0QJSBiRiVCIBziWq812fCy2pfU-q8dwmd416IX4ZEq89Rd41zpS9Cy2HsPh0Xm9EwEoBeNek29EwDkQg2U3xMcd45fyp-9EwxGLQd43IqGCy0d2NEwR12fQEq8av4PYjh13lvEidEEK6_xY9sPpEZtBt>
>>>
>>>
>>>
>>> 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
>>
>>
>> _______________________________________________
>> 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/20161201/439bfd9e/attachment.html>