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 <nicksbarn...@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 <ryanh...@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.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> 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] *On >>> Behalf Of *Anthony Holloway >>> *Sent:* Thursday, December 01, 2016 5:08 PM >>> *To:* Nick Barnett <nicksbarn...@gmail.com> >>> *Cc:* Cisco VoIP Group <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> >>> 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> 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> >>> 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> >>> 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> >>> 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> >>> 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@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 >>> 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 >>> 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 >>> 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 >>> 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 >> >> >> _______________________________________________ >> cisco-voip mailing list >> 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