PCD error defining cluster

[pcanters]

I am having an issue with PCD

I am migrating from 9.1 to 12.0 and using PCD to do this

When I define the 9.1 cluster in PCD it gives me a "failed to discover cluster" error

In other words, it can't find the cluster.

However, the PCD is on the same subnet as the cluster I am looking to discover and I am able to log into the OS administration page of the 9.1 cluster validating the credentials I am using for PCD

I am also able to ping from the 9.1 call manager to the PCD server

So network connectivity and credentials do not appear to be the issue

I cant seem to find any other reasons that would stop me from discovering this cluster

Other comments have included issues with timezones matching (they do)

I have done migrations in the past with PCD and have never run into not being able to discover a cluster

Is this possibly a DNS issue, does PCD need to resolve to the cluster that we will migrate from ?

Not sure...anyone else seen this ?

TIA

[Chris Deren]

My suggestion would be to review PCD logs for clues.

Also, by any chance does PCD or any of the CUCM servers use password longer than 16 characters as that is a know issue?

[pcanters]

Passwords are not longer then 16...wish that was it.

I have since upgraded PCD to the latest and greatest version and I still get the same issue

I validated DNS

I rebooted PCD multiple times but still no joy !!

TAC case also currently pending but thought I would attempt the collective brain trust of the support community also 

Thanks for the response

[Chris Deren]

Post the PCD log.

[pcanters]

These are yesterdays PCD logs

Same issue,  so errors should be the same

I cant see anything here that jumps out at me

[Chris Deren]

So, I see:

2018-07-25 15:15:12,044 INFO  [http-bio-443-exec-102] resources.RestMessage.setDisplay - display = [CLI command timed out for node 130.1.252.10.Please verify the PCD logs to see what is causing for time-out.Also please check if the UC application node is reachable.]

sounds like some communication errors between PCD and your CUCM. 

Does "utils network host" on PCD and CUCM resolve the other properly? 

[pcanters]

The host name shown on "show status" on both PCD and call manager publisher resolves correctly on both PCD server and the call manager publisher at this time

Perhaps it is time to pull a new log

New log forthcoming as I think we might not see that error again

[pcanters]

Reran the PCD Discover cluster

Error is

Cli command for node

Please verify the logs to see what is causing the time-out

Also please check to see if the UC application node is reachable

Unable to contact the specified cluster node

verify the Hostname/ip address and credentials

Then pulled logs from PCD

Nothing that I can really see and network connectivity seems to check out

Log attached

[Chris Deren]

Seeing the following:

expect: set expect_out(buffer) "ssh: connect to host 130.252.1.10 port 22: Connection timed out"
FAILED ucmapLib::adminLogin, could not login to the node 130.252.1.10 within 2 minutes. Hence timed out
ucmapLib::adminLogin was not successful 143, so could not process for getCluster
ucmapLib::getCluster result 143

2018-07-26 12:46:46,754 INFO  [http-bio-443-exec-48] resources.RestMessage.setDisplay - display = [Could not to login to the node 130.252.1.10.Please check the provided credentials were proper or the UC application node is on or not.]

2018-07-26 16:30:45,151 INFO  [http-bio-443-exec-271] resources.RestMessage.setDisplay - display = [CLI command timed out for node 130.1.252.10.Please verify the PCD logs to see what is causing for time-out.Also please check if the UC application node is reachable.]

[pcanters]

Kind of strange because it seems to indicate that credentials are not correct but yet I can log into O S Administration of the call manager with same credentials that I am using for the PCD cluster discovery

Very curious

[pcanters · Accepted solution]

To close the loop on this post

Issue was DNS !

Primary DNS was not responding, Secondary was

PCD is picky enough so that it times out and does not do it's thing correctly unless it finds the primary DNS

By the time it hits the secondary DNS server, it times out and fails.

Not really sure why we bother with a secondary DNS if this is the case

In any event, this was the issue