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

2016-12-01 Thread Nick Barnett 
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
>>>
>>>
>>>
>>&

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

2016-12-01 Thread Nick Barnett 
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 i

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

2016-12-01 Thread Ben Amick 
The question I pose in response to that line of thinking is: Why is a client 
pulling TFTP from the server while you're deactivating the services, and why do 
you not have redundant TFTP?

The scenario I mentioned regarding the phone needing a restart would only be 
necessary if the phone was in a factory reset, which would mean an engineer 
would be hands-on with the phone and/or the user at that point in time, in 
which case why would you also be deactivating TFTP at that point in time, and 
even if you do, you already have a contact to resolve the issue with.
In the case of phone configuration files delivered via TFTP - if those fail to 
download, the phone falls back to the last stored configuration, if memory 
serves. In the case of a phone delivering a new update while operational, it 
waits until it finishes downloading (alleviating need for TFTP) before 
executing an upgrade, meaning it should once again be irrelevant to the TFTP 
deactivation.

I mean, there's plenty of "what ifs" but TFTP downloads only ever happen during 
changes - new firmware installation, or new configuration to the phone. Even if 
you don't have clearly defined maintenance windows, I believe you shouldn't be 
making a change as serious as migrating from IP to FQDN at the same time as you 
would be deploying a new firmware image to all your 7900 handsets, for example.

Ben Amick
Telecom Analyst

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Thursday, December 01, 2016 5:41 PM
To: James Buchanan <james.buchan...@gmail.com>
Cc: Ben Amick <bam...@humanarc.com>; 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?

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 th

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

2016-12-01 Thread Ryan Huff 
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

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

2016-12-01 Thread James Buchanan 
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/2DRPoQd6Qm7HKcThKOrKrhhpvpj73AjhOrhhpvpj7ffICQkmnTDNPPXxJ55MQs

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

2016-12-01 Thread Ben Amick 
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<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/avndy0O92

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

2016-12-01 Thread Anthony Holloway 
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  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  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 
>> 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 
>> wrote:
>>
>>> Would a simple reboot accomplish the same as deactivating and activating?
>>>
>>> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
>>> 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 
 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
>>>
>>>
>> ___
>> 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

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

2016-11-30 Thread NateCCIE 
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  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  wrote:
>> Would a simple reboot accomplish the same as deactivating and activating?
>> 
>>> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett  
>>> 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  
 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
>> 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
>> 
> 
> ___
> 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

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

2016-11-29 Thread Derek Andrew 
Would a simple reboot accomplish the same as deactivating and activating?

On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
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 
> 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
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

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

2016-11-28 Thread Nick Barnett 
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 
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
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2016-08-31 Thread Nick Barnett 
awesome info, thank you! I'm pretty sure our gateways have DNS, but I'll be
making sure... and I've dealt with enough dbreplication issues lately that
I'll be vigilant on that as well. It may take me 8 hours to do it that way
though blech. I just had to do a cluster reboot earlier this week and
it took just under an hour with 9 nodes.

On Wed, Aug 31, 2016 at 4:15 PM, <dan...@ohnesorge.me> wrote:

> One of the most important points that people tend to forget when changing
> the processnode (System>Server) entries is that MGCP and SCCP gateways will
> download a config file (like a phone) and will need to resolve these
> entries. For what ever reason I've seen so many customers not add any ip
> name server to their routers so this one can bite you in the ass.
>
> Now with regards to actually changing the entries, I have done this way
> too many times. What you REALLY need to do is change the entry one by one,
> then restart all the nodes in the cluster one by one. Then change the next
> entry and repeat! I know this sounds totally unnecessary but the
> processnode has the ability to stuff up your dbreplication to the point
> where TAC will suggest a rebuild.
>
> Thanks,
> Daniel
>
> Sent from my iPhone
>
> On 1 Sep 2016, at 06:39, Ryan Huff <ryanh...@outlook.com> wrote:
>
> Nick,
>
>
> If the UC servers already have DNS entries (means they already have a
> domain name too); then the servers are already using FQDNs, at least for
> internal referencing. If you're saying the you want to change the
> processNode names (the CM Server references) then as long as the FQDNs are
> resolvable in the forward and reverse direction, it should be fine.
>
>
> If you need to change the hostname or domain names of the servers to
> something more palatable (a crossroads often encountered when dealing with
> Jabber and end users and UC servers that were IP addresses first); that is
> a horse of a much different color; please *carefully *consult
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/
> install/10_0_1/ipchange/CUCM_BK_C3782AAB_00_change-
> ipaddress-hostname-100/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100_
> chapter_0100.html (especially in the case of IM & Presence HA)
>
>
> If you are also talking about changing the IP Phone URL references under
> Enterprise Parameters (from IP address to FQDN); your phone networks will
> need DNS capabilities to resolve those FQDNs as well. As a matter of
> practice, I always ensure IP phone networks have DNS capabilities, but it
> can be uncommonly found out in the wild.
>
>
> Beyond that, if you are simply just changing the processNode references
> for IP addresses to FQDNs (presumably, so CUCM requests come from an FQDN
> and not an IP address) and everything is already resolving correctly, you
> should be g2g.
>
>
> Thanks,
>
>
> = Ryan =
>
>
>
>
> ------
> *From:* cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Nick
> Barnett <nicksbarn...@gmail.com>
> *Sent:* Wednesday, August 31, 2016 4:13 PM
> *To:* Cisco VoIP Group
> *Subject:* [cisco-voip] Are there any gotchas to watch out for switching
> to FQDN server names from IP address server names?
>
> 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
>
> ___
> 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

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

2016-08-31 Thread Nick Barnett 
Thanks Ryan. Yes, I'm just trying to change the process node names. Right
now, when someone logs in with cucilync, it prompts them for several
certificates. Those certs are references a CN that is an IP address. I'm
thinking that if I change the node name to an FQDN, and assuming I have my
cert chain signed properly and deployed, hopefully the end user will NOT
see these cert warnings any more. Does that sound about right?

On Wed, Aug 31, 2016 at 3:39 PM, Ryan Huff <ryanh...@outlook.com> wrote:

> Nick,
>
>
> If the UC servers already have DNS entries (means they already have a
> domain name too); then the servers are already using FQDNs, at least for
> internal referencing. If you're saying the you want to change the
> processNode names (the CM Server references) then as long as the FQDNs are
> resolvable in the forward and reverse direction, it should be fine.
>
>
> If you need to change the hostname or domain names of the servers to
> something more palatable (a crossroads often encountered when dealing with
> Jabber and end users and UC servers that were IP addresses first); that is
> a horse of a much different color; please *carefully *consult
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/
> install/10_0_1/ipchange/CUCM_BK_C3782AAB_00_change-
> ipaddress-hostname-100/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100_
> chapter_0100.html (especially in the case of IM & Presence HA)
>
>
> If you are also talking about changing the IP Phone URL references under
> Enterprise Parameters (from IP address to FQDN); your phone networks will
> need DNS capabilities to resolve those FQDNs as well. As a matter of
> practice, I always ensure IP phone networks have DNS capabilities, but it
> can be uncommonly found out in the wild.
>
>
> Beyond that, if you are simply just changing the processNode references
> for IP addresses to FQDNs (presumably, so CUCM requests come from an FQDN
> and not an IP address) and everything is already resolving correctly, you
> should be g2g.
>
>
> Thanks,
>
>
> = Ryan =
>
>
>
>
> --
> *From:* cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Nick
> Barnett <nicksbarn...@gmail.com>
> *Sent:* Wednesday, August 31, 2016 4:13 PM
> *To:* Cisco VoIP Group
> *Subject:* [cisco-voip] Are there any gotchas to watch out for switching
> to FQDN server names from IP address server names?
>
> 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
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2016-08-31 Thread Daniel Ohnesorge via cisco-voip 
One of the most important points that people tend to forget when changing the 
processnode (System>Server) entries is that MGCP and SCCP gateways will 
download a config file (like a phone) and will need to resolve these entries. 
For what ever reason I've seen so many customers not add any ip name server to 
their routers so this one can bite you in the ass.

Now with regards to actually changing the entries, I have done this way too 
many times. What you REALLY need to do is change the entry one by one, then 
restart all the nodes in the cluster one by one. Then change the next entry and 
repeat! I know this sounds totally unnecessary but the processnode has the 
ability to stuff up your dbreplication to the point where TAC will suggest a 
rebuild.

Thanks,
Daniel

Sent from my iPhone

> On 1 Sep 2016, at 06:39, Ryan Huff <ryanh...@outlook.com> wrote:
> 
> Nick,
> 
> 
> If the UC servers already have DNS entries (means they already have a domain 
> name too); then the servers are already using FQDNs, at least for internal 
> referencing. If you're saying the you want to change the processNode names 
> (the CM Server references) then as long as the FQDNs are resolvable in the 
> forward and reverse direction, it should be fine.
> 
> 
> If you need to change the hostname or domain names of the servers to 
> something more palatable (a crossroads often encountered when dealing with 
> Jabber and end users and UC servers that were IP addresses first); that is a 
> horse of a much different color; please carefully consult 
> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/10_0_1/ipchange/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100_chapter_0100.html
>  (especially in the case of IM & Presence HA) 
> 
> If you are also talking about changing the IP Phone URL references under 
> Enterprise Parameters (from IP address to FQDN); your phone networks will 
> need DNS capabilities to resolve those FQDNs as well. As a matter of 
> practice, I always ensure IP phone networks have DNS capabilities, but it can 
> be uncommonly found out in the wild.
> 
> 
> Beyond that, if you are simply just changing the processNode references for 
> IP addresses to FQDNs (presumably, so CUCM requests come from an FQDN and not 
> an IP address) and everything is already resolving correctly, you should be 
> g2g.
> 
> Thanks,
> 
> = Ryan =
> 
> 
> 
> From: cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Nick 
> Barnett <nicksbarn...@gmail.com>
> Sent: Wednesday, August 31, 2016 4:13 PM
> To: Cisco VoIP Group
> Subject: [cisco-voip] Are there any gotchas to watch out for switching to 
> FQDN server names from IP address server names?
>  
> 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
> ___
> 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