Search this Blog

Friday, December 11, 2009

CMSUB-ISL-IPT Error Cisco CallManager. Phones registered to different subscriber cannot communicate


We have 4 CUCM in PUB-SUB scenario. PUB and 3 SUBs with cucm 6.0

Everything was working fine but from last few days we are facing an issue, Phones registered with Subscriber A can communicate with phones on Subscriber B and C both Phones registered to Subscriber B can communicate with subscriber A but not Subscriber C Phones registered to Subscriber C cannot communicate with subscriber B but they can communicate with subscriber A There are times when subscriber C phones can communicate with Subscriber B phones but it’s very rare. I have verified DB replication status and its 2 I have tried to insert phones from subscriber C Admin page and it works. There no latency or packet drops issues between Subscriber to Subscriber and Publisher to subscriber.

Error message in application logs
CMSUB-ISL-IPT Error Cisco CallManager : 26: Dec 10 18:04:19.6 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-SDLLinkOOS: SDL link to remote application out of service. Local node ID:12 Local Application ID.:100 Remote IP address of remote application:10.100.200.12 RemoteNodeID:1 Remote application ID.:100 Unique Link ID.:12:100:1:100 Cluster ID:StandAloneCluster Node ID:CMSUB-ISL-IPT

Debugging options

  1. To rule out any SDL issues, perform a cluster reboot to resync the SDL
  2. If replication is fine look at SDL layers to find out the issue
  3. Look for version mismatches or errors in the app log
  4. There might be a DB replication issue within the cluster. Basically, while the SDL link to that node is out of service - the replication for the entire cluster is considered bad. With the Linux appliance, a reboot typically works but depending on how long the issue has been going on and the trigger for problem, it may not. Look at the utils dbreplication commands. There are some that you run on each server first, see what happens, and then if that doesn't work then you can initiate a repair operation from the publisher server. This is all done via CLI. Note that the repair operation may (and likely will) take quite a while to complete. Once you start it, let it run and wait for it to complete. Then use RTMT to verify DB replication. You can also use command line operation on each server or the Unified Reporting.
  5. Run tests to verify that you don’t have an issue at the network - either logical or physical. For some reason, the Pub either might think it can't communicate at the SDL layer to this particular subscriber.
  6. You may also have a bad NIC or failed teaming configuration - there are lots of possibilities
  7. Verify and confirm that there is nothing wrong with the NIC, packet loss over the network, QoS, etc. Other factors could be if this is a subscriber that was recently added to the cluster or if there was a recent upgrade on the nodes that may be causing an issue.
Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

 
/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */