[cisco-voip] FQDN removal

[Ryan Huff]

David,


There will always be a hostname/domain name in the node. If you wish the node not to use DNS resolution, then delete the DNS entries from the node. Simply deleting the DNS entries will not cause a node reboot but it will restart the eth0 network interface of the node, I would do this in a maintenance window.


Prior to doing that and as a safety check, I would also run run sql select name,nodeid from ProcessNode from the node CLI FIRST and verify that all nodes are listed by IP address. The last item I would consider before deleting DNS is if the NTP server of the node is using a FQDN vs. IP Address; you'd need to change it first before deleting the DNS server if it is.


Once you've completed all your changes I would wait about 15 minutes (then again at 30 minutes) and issue, util dbreplication runtimestate from the publisher CLI and verify each node shows (2) Setup Completed. If not, you'll need to investigate why and possibly reset DB replication.


Again, if you are changing the hostname or domain name of the node; that is a horse of a different color (http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/8_6_1/ipchange/ipchg861.html).


Thanks,


= Ryan =



Email: ryanthomashuff at outlook.com

Spark: ryanthomashuff at outlook.com

Twitter: @ryanthomashuff<http://twitter.com/ryanthomashuff>

LinkedIn: ryanthomashuff<http://linkedin.com/in/ryanthomashuff>

Web ryanthomashuff.com<http://ryanthomashuff.com>


________________________________
From: David Jengan <davidjengan at gmail.com>
Sent: Thursday, January 28, 2016 9:56 PM
To: Ryan Huff
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] FQDN removal

Hi Ryan,

Thanks for the detailed explanation. Sorry I may not have been completely clear in the ask, what I'm after is to remove the DNS pointers from this Node, and additionally domain-name and Alias it was built with. So removing all DNS entries would take care of removing these as well and your suggestion for removing DNS without reboot still hold valid?

I'm cognizant of the points you raised regarding the server being listed by hostname instead of IP which isn't the case, and also the URLs are by IP instead of hostname.
So with this being clear, I can remove the DNS pri/sec pointers from CLI on the desired node, and not worry about restarting it or the cluster. From what you've pointed out, it appears that this will trigger db replication to break and then re-establish? Can you please confirm.

Regarding your query, I agree but at this time I want consistency, while at a later time implementing DNS would be planned for all nodes together.

In case it helps, listing the hosts on cli shows:
x.x.x.x sub1.domain.com<http://sub1.domain.com> sub1
x.x.x.x sub2
x.x.x.x sub3
x.x.x.x pub


On sub1 node: network details shows DNS entries and domain name.


Best,
David


On Thu, Jan 28, 2016 at 8:55 PM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:

Hi David,


Removing the DNS server entries alone from the cluster nodes, would not require a restart. Removing/changing the hostname/domain name of the nodes would; this carries its own set of risks and considerations with SBD and db replication. If you are doing that, please 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_011.html first.


If you are just removing the DNS entries from the node then what you'll want to be uniquely aware of and cautious with is; any node listed in the CM ProccessNode table (Cisco Unified CM Administration -> System -> Server) with a hostname or FQDN (Vs. an IP Address). If you have any nodes in the CM Server section listed by either hostname or FQDN, you'll need to first change those to IP addresses BEFORE removing the DNS server entries in the CLI.


Additionally, you'll want to take stock of any 3rd party applications/integrations that you might have which requires the CUCM nodes to perform DNS queries/lookups. You will also likely want to verify that the the Phone URL Parameters under Enterprise Parameters are using IP addresses and not hostnames/FQDNs.


After you're done with your changes, you'll want to verify good DB Replication in the cluster (from the CLI of the publisher, issue utils dbreplication runtimestate and verify Setup Completed for each node).


This is more just a question out of my own curiosity, is there a specific reason you do not want to use DNS? In modern versions of CUCM such as 10, DNS is generally recommended. Additionally, several UC applications that could be used with CUCM are enhanced with DNS (IM&P, CUC) not to mention the UCCX would consider it a requirement. While you may not be using those products now, you never know what you may do in the future, always best to bake in the scalability early on, IMO.


= Ryan =



Email: ryanthomashuff at outlook.com<mailto:ryanthomashuff at outlook.com>

Spark: ryanthomashuff at outlook.com<mailto:ryanthomashuff at outlook.com>

Twitter: @ryanthomashuff<http://twitter.com/ryanthomashuff>

LinkedIn: ryanthomashuff<http://linkedin.com/in/ryanthomashuff>

Web ryanthomashuff.com<http://ryanthomashuff.com>


________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> on behalf of David Jengan <davidjengan at gmail.com<mailto:davidjengan at gmail.com>>
Sent: Thursday, January 28, 2016 8:27 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] FQDN removal

Hi All,

My CUCM 10 cluster doesn't have DNS dependency, but one of the nodes has got the DNS/FQDN setup which I'd like to remove. I can do dns removal from CLI, but not able to find clear instructions on whether the entire cluster would needs to be rebooted. If yes, any recommended sequence/steps to follow?, if not, the node undergoing the change needs to be restarted?

Thanks
David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160129/b4eebd68/attachment.html>