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.buchan...@gmail.com<mailto:james.buchan...@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 
<bam...@humanarc.com<mailto:bam...@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-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>]
 On Behalf Of Anthony Holloway
Sent: Thursday, December 01, 2016 5:08 PM
To: Nick Barnett <nicksbarn...@gmail.com<mailto:nicksbarn...@gmail.com>>
Cc: Cisco VoIP Group 
<cisco-voip@puck.nether.net<mailto:cisco-voip@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 
<nicksbarn...@gmail.com<mailto:nicksbarn...@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 
<natec...@gmail.com<mailto:natec...@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.buchan...@gmail.com<mailto:james.buchan...@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.and...@usask.ca<mailto:derek.and...@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 
<nicksbarn...@gmail.com<mailto:nicksbarn...@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 
<nicksbarn...@gmail.com<mailto:nicksbarn...@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<tel:(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.

[http://homepage.usask.ca/dfa878/uofs.gif]

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@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@puck.nether.net<mailto:cisco-voip@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@puck.nether.net<mailto:cisco-voip@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@puck.nether.net<mailto:cisco-voip@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@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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

Reply via email to