Troubleshooting: Jabber cannot communicate with the server when using MRA via Expressway

Mike Spooner · ‎01-20-2017

More and more companies these days have mobile workforces: teams that work on the road or who have the ability to work from home. To help maximize efficiency and to make this mobility seamless to the individuals and the rest of the team Mobile and Remote Access (MRA) via Cisco Expressway is the key. Being able to use Cisco Jabber and IM&P help bring mobile collaboration to another level. However, there are times when this seamless mobility runs into a snag and an error occurs; one of the most common errors while using Jabber in MRA mode via Cisco Expressway is "cannot communicate with the server". Today's tip is about how to effectively troubleshoot this problem.

PROBLEM

Cisco Jabber login error when trying to communicate using Mobile and Remote Access via Cisco Expressway: "cannot communicate with the server".''

SOLUTION

The following will outline three areas to explore when troubleshooting your Cisco Jabber login error: " cannot communicate with server" when trying to communicate using Mobile and Remote Access via Cisco Expressway. In this scenario, we will assume that the user is able to login to Jabber from inside the corporate LAN and focus our troubleshooting efforts on Expressway pair servers.

STEP 1. Verify the DNS and firewall related configurations.

Verify that the collab-edge.tls.company.com SRV type DNS record is present.
Please note that it is important to set the type to SRV. In this example below, we use a well known public DNS server.

b) Verify that the returned FQDN of the Expressway-Edge server from the SRV record is resolving to an IP address.

c) Verify that the Cisco Expressway-Edge server's FQDN name matches exactly the value created in the collab-edge SRV record.

Defect CSCuo82526: MRA Jabber does not send cookie x-auth token with login request.

d) Verify that the corporate firewall has a rule for port 8443 that forwards traffic to the DMZ LAN interface of the Expressway-Edge server.

STEP2. Verify that the traversal-zone between Cisco Expressway Edge and Core servers are <<Active>>.

Verify the Expressway-Edge server.

b) Verify the Cisco Expressway-Core server.

c) Verify that Unified Communications status on Cisco Expressway-Core is enabled and configured

If both the main configuration and the Cisco Expressway-Edge and Core servers are active then proceed to step 3 and start digging into the log files.

STEP 3. Dig into the log files of Expressway.

Start by digging into the Network logs and filter using <<trafficserver>>.
This will help you see how the get_edge_config process between the Edge and Core servers is happening.

b) Now begin a dignostic log and reproduce your problem.
Make sure to check <<take tcpdump while logging>> which will generate a pcap file as well.
Note: there is an alarm active once you start your diagnostic log and it will disappear automatically when you stop the diagnostics. There is also a <<download>> option available after diagnostic logging is complete. These logs are the first thing that the Cisco TAC will require from you if you open a case with Cisco in regards to Expressway.

Analyze the logs.
The following identify the two most common errors to look for in your diagnostic logs.
1. Error: <<SIP/2.0 405 Method Not Allowed>>
  If this error is found in the Core logs, it is in response to SIP registration request failure.
  
  Resolution: The error is usually due to an existing SIP trunk between Expressway-C and CUCM using port 5060/5061 (the trunk is not used for MRA, but usually is created for another feature of Expressway – B2B dialing). In order to correct the issue, you will have to change the SIP port on the SIP Trunk Security Profile that is applied to the existing SIP trunk configured in CUCM. You can use 5065 instead.
2. Error: <<edgeconfigprovisioning: Level="WARNING" Service="UDSManager" Detail="User cluster not found">>
  If this error is found and you have multiple Unifed CM clusters defined in Expressway-Core.
  
  Resolution: In this case ILS (Intercluster Lookup Service) must be set up on all of the clusters. This is because the Expressway has to authenticate a client against its home Unified CM cluster and to discover the home cluster it sends a UDS (User Data Service) query to any one of the Unified CM nodes over ILS.

After you have completed the above three steps you should have been able to identify and resolve your Jabber "cannot communicate with the server" error. If you need occasional or ongoing additional support please feel free to contact us at Stack8.

Gpetroski1 · ‎10-16-2018

Also,

1. Validate PTR for E is configured on public and private DNS.

2. Internal DNS should resolve External IP for E's FQDN.

3. C needs to be able to resolve E's IP to FQDN and FQDN back to IP. You can use DNS utility in both C and E to perform these checks.

If not, users can't login through Expressways, but can internally. Errors in C show

Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=ExpressWay_E_Public_IP, additional info: Invalid Hostname somehost.domain.com"

Module="Jabber" Level="WARN " CodeLocation="ssl.c:507" Detail="The SSL Handshake failed for fd (26). SSL Error code: 1"
2018-10-16T22:20:12.361-05:00 USCOLO-EXPW-C XCP_JABBERD[11062]: UTCTime="2018-10-17 03:20:12,361" ThreadID="140530467735296" Module="Jabber" Level="ERROR" CodeLocation="ConnectComponent.cpp:246" Detail="(null _comp_id): XMPPStream Error(xml-stream-error): not well-formed (invalid token), bytes: "

Module="Jabber" Level="INFO " CodeLocation="base_connection.cpp:244" Detail="Component jabberd-port-1.expressway_C_FQDN-com is GONE: errno not set"

Hope this helps. This became apparent on x8.11. I haven't seen this issue on x8.9 and previous versions.