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

[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,  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  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  on behalf of Nick
> Barnett 
> *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?

[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  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  on behalf of Nick
> Barnett 
> *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?

[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  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  on behalf of Nick 
> Barnett 
> 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

[cisco-voip] UCCX and TLS versions

[Damisch, Kevin]

Customer is running UCCX 10.6(1).  We have some "HTTP Request" actions within a 
Finesse workflow that points to one of the customer's internal web servers.  
Looking at the packet capture taken from UCCX when this workflow runs, we can 
see UCCX sending the https request with a TLS 1.0 hello packet.  The customer's 
web server then replies with a TLS handshake error because it only supports TLS 
1.1 or higher.  We also noticed the same thing occurring with a custom gadget 
in the Finesse desktop layout, which points to a web server handled by an F5 
load balancer.  The F5 rejects it with the same TLS handshake error.

Other than having the customer enable TLS 1.0 on their servers, what options do 
we have on the UCCX side?  Does UCCX 11.x still send TLS 1.0 on http requests?  
I've had a TAC case open for a while and don't have an answer yet.  Just to be 
clear, I'm aware of the forum posts out there about verifying the TLS version 
with IE and Firefox.  That isn't what I'm talking about.  I'm not talking about 
using a browser to get *to* UCCX.  I'm talking about UCCX *sourcing* the https 
request, such as in a workflow action, destined for another web server.  That 
is the direction where we are seeing UCCX send TLS 1.0 hello packets that we 
want and need to be TLS 1.1 or higher to satisfy the customer's security 
requirements.

Thanks!
Kevin Damisch

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip