Cisco Support Community
Community Member

CUCM8.5, Trust lists, EM resillience & RAGE!!

Guys... I hope you can help me, im going insane.

I believe we are looking at a trust list issue with the IP phones, supported by the below.  Ive replaced some IP Addresses and hostnames with x's or PUBLISHER or SUBSCRIBER in the interests of security.

Essentially our setup is that ALL phone services point to CUCM01 - which is a DNS A record that points to all four subscriber servers (Note, the publisher is NOT included in this A record)

The long and short of it is that when you shut down the publisher server and try to use extension mobility (As we did during pre-migration failover testing) it fails, with an error code of "208 log in not available", despite the fact that the A record does not point at the publisher to use extension mobility.  When the publisher is online, extension mobility works fine.

Looking at a combination of packet captures, extension mobility logs and phone console logs I can see that regardless of the fact that the DNS Record does NOT point to the publisher, the publisher is still being used for extension mobility operations - due to the fact that the phones do not seem to "Trust" the subscribers.  They run through each subscriber, discover they do not "Trust" them, and move on to the next - until they finally reach the publisher which they do trust and then the service becomes active.  When the publisher is down, the service cannot be used as no other servers are trusted. Example below, from the extension mobility logs we retrieved when we tried to login with the publisher offline:

2011-11-23 18:26:18,492 ERROR [http-8443-3         ] EMX509TrustManager        - checkServerTrusted: xxxx.local Certificate not found in the keystore : PKIX path building failed: unable to find certificate chain

2011-11-23 18:26:18,496 INFO  [http-8443-3         ] EMUtil                    - sendNodeNotTrustedAlarm:Alarm NodeNotTrusted sent successfully

2011-11-23 18:26:18,525 INFO  [http-8443-3         ] EMServiceCommunicator     - Trying alternate URL for ->https://localhost:8443/emservice/EMServiceServlet

2011-11-23 18:26:18,527 INFO  [http-8443-3         ] EMServiceCommunicator     - Alternate URL found : https://PUBLISHER:8443/emservice/EMServiceServlet

2011-11-23 18:27:04,015 ERROR [http-8443-3         ] EMServiceCommunicator     - No route to host

2011-11-23 18:27:04,015 INFO  [http-8443-3         ] EMServiceCommunicator     - Alternate URL found : https://SUBSCRIBER:8443/emservice/EMServiceServlet

2011-11-23 18:27:04,309 INFO  [http-8443-3         ] EMServiceCommunicator     - Resetting Service URL and Query URL to:https://SUBSCRIBER:8443/emservice/EMServiceServlet


I believe we are looking at a certificates issue with the phones trust files, but I do not know what issue.  If you look at the ITL file on the phones, it has a TVS entry against all the hostnames in the cluster, but it wont work.  I have already deleted the phones ITL file manually also which did not work.  I also tried restarting the TFTP, extension mobility app, extension mobility service and TVS service on all nodes followed by a tomcat restart on all nodes followed by deleting the ITL file on the phone manually but it still did not work.

Any help appreciated!

Super Bronze

CUCM8.5, Trust lists, EM resillience & RAGE!!

Hi Carl

That looks like the error is communication between the EM web service and the 'servlet' which is basically the back-end API. It looks like the trust issue is between the front-end web service used by phones, and the back-end API service used by the front-end service (on the same server).

In other words = phone --> server OK

EM Web site ---> EM API not so good

So the question would be why one website doesn't trust the other - could be another certificate distribution issue?


Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
CreatePlease to create content