DCR default credentials error

Answered Question

Internal error in communication channel.


Already have CSCsu84143 installed.


I have a multiserver environment with 2 servers (DCR master = CM & IPM; DCR slave = RME & DFM)





Attachment: 
Correct Answer by Joe Clarke about 7 years 8 months ago

I always recommend using short hostnames for certs and multi-server trust. However, if you must use FQDN, then the cert must use the FQDN, and the slave needs to be registered to the server using FQDN.


In the case of my local servers, the IP had been changed while keeping the servers' hostnames the same. Only problem was, DNS was pointing the current hostname to the old IP addresses. The fix was to change the servers' hostnames to match the new DNS entries for the corresponding IP addresses. I then regenerated the certs for the new short hostnames, and re-established the peer relationship using the short hostnames. Everything has worked fine since.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Joe Clarke Wed, 10/07/2009 - 08:38
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Make sure you do not have on-access anti-virus scanning running on NMSROOT. If you do, disable it, then restart Daemon Manager.

Joe Clarke Wed, 10/07/2009 - 08:55
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Unfortunately, the logs don't provide all the details needed to see why the method lookup is failing. Typically this is triggered by AV scanning, but in this case, I cannot say why it's happening. Restarting Daemon Manager on the DCR master should workaround this, but without knowing the root cause, it could return. If you open a TAC service request, it should be possible to get to the bottom of this.

Joe Clarke Wed, 10/07/2009 - 11:32
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

I saw this exact problem on a pair of local servers. The problem there was hostname weirdness. Were the hostnames of these servers ever changed?

Ok...so I think you may be on to something here...


The hostname hasn't been changed...


However, I am still having issues with shortname vs. FQDN and certificates.


This is more relevant in a multiserver environment.


The certificates has changed from FQDN to shortname only...


Please advise best practice with FQDN and certificates...especially when device center doesn't use FQDN for its links.

Correct Answer
Joe Clarke Wed, 10/07/2009 - 11:51
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

I always recommend using short hostnames for certs and multi-server trust. However, if you must use FQDN, then the cert must use the FQDN, and the slave needs to be registered to the server using FQDN.


In the case of my local servers, the IP had been changed while keeping the servers' hostnames the same. Only problem was, DNS was pointing the current hostname to the old IP addresses. The fix was to change the servers' hostnames to match the new DNS entries for the corresponding IP addresses. I then regenerated the certs for the new short hostnames, and re-established the peer relationship using the short hostnames. Everything has worked fine since.

Actions

This Discussion