09-03-2010 04:56 AM - edited 03-19-2019 01:31 AM
Hello,
I have recently rebuild my CUCM subscriber, it was installed normally but now the device pool with that subscriber as their first node is not getting registered.
I am getting Error message Registration Rejected: Error DBconn..
I know it is only this call manager because when i move my phone to other device pool which is using seperate call manager it get registered.
The call manager in question is not showing any problem. when i login to that call manager and search for any particular phone it just brings that phone.
it has exactly the same configuration as other subscribers but this one is having issue with it.
I personally think it is a database replication problem but can any body tell me how to make sure that it is database issue and how to fix it?
Note. I am not using auto-registration for phones so don't consider it while answering.
Thanks in advance.
Solved! Go to Solution.
09-03-2010 09:04 AM
Amjad,
No, you don't need to re-install. Here is a link to the CUCM troubleshooting guide for 7.1 (reference link to DB Replication issues):
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1172876
You have already established you have an issue so I am providing the link for future reference. To resolve the issue I would first try the procedures in Step 6 (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1184419).
Only do Step 6 if one of the servers showed an RTMT status of 4, or had a status of 0 for more than four hours.
(NOTE: I think you have a subscriber with the "status of 0 for more than four hours")
Step 6 Generate and view the Unified CM Database Status report, which provides debugging information for database replication. For each subscriber server that has a bad RTMT status, check that the hosts, rhosts, sqlhosts, and services files have the appropriate information.
Generate and view the Unified CM Cluster Overview report. Verify that the subscriber servers have the same version, verify that connectivity is good, and verify that time delay is within tolerances.
If the preceding conditions are acceptable, do the following to reset replication on that subscriber server:
a. At the subscriber server, perform the CLI command utils dbreplication stop
Do this for all subscriber servers that have an RTMT value of 4
b. At the publisher server, perform the CLI command utils dbreplication stop
c. At the publisher server, perform the CLI command utils dbreplication reset
HTH.
Regards,
Bill
Please remember to rate helpful posts.
Please remember to rate helpful responses and identify
09-03-2010 06:04 AM
That most definitely sounds like a replication issue to me.
Do the following on each node in the cluster:
1. ssh to the node
2. Execute commands:
*example*
admin:show network cluster
10.3.4.24 iecups01.cnclab.com iecups01 Subscriber
10.3.4.20 iecucm01.cnclab.com iecucm01 Publisher
10.3.4.21 iecucm02.cnclab.com iecucm02 Subscriber
admin:utils diagnose module validate_network
Log file: platform/log/diag2.log
Starting diagnostic test(s)
===========================
test - validate_network : Pass
Diagnostics Completed
admin:*show perf query class "Number of Replicates Created and State of
Replication"*
==>query class :
- Perf class (Number of Replicates Created and State of Replication) has
instances and values:
ReplicateCount -> Number of Replicates Created = 427
ReplicateCount -> Replicate_State = 2
admin:
For the "show network cluster" command you are looking at the output to
ensure that names and addresses are correct for your environment and
consistent on each cluster node.
The "utils diagnose" command is actually running the validation routine
which a cluster node runs before starting services and coming on line.
Resets to the db replication will fail if there are any problems reported by
this validation module. Just an extra/easy check.
The "show perf" command is giving you a replication state. Ensure that the
replicates created are the same on each node and that the replicate state is
2. If it is something other than 2 you have a replication problem.
It is also prudent to do the following:
1. Create a device (or pick one of your devices that isn't registering)
2. on each node:
2a. Ssh to the cluster node
2b. Execute command:
admin:*run sql select name,description from device where name =
'SEPAAAABBBBCCCC'*
(note: substitute AAAABBBBCCCC with the correct mac of phone or test phone)
Do this on the publisher first and then the subscribers. If you have a
subscriber that isn't showing the info then you have a replication issue.
On the appliance model I have yet to see an inconsistent result with the
"show perf query class" command and the "create a device and check" method.
But on the Windows platforms I have seen where the replication test tools
are happy while db replication is busted. So, that is why I use the last
method.
There are other ways to check replication. You can do this instead or in
addition to the above:
1. You can use the "utils dbreplication status" on the publisher node. This
runs for a few minutes and creates a log file that you would need to view
(with the "file view" command). This can be handy if you see something wrong
in previous steps and want to get a table-by-table view.
2. Cisco Unified Reporting. This is a web portal (like ccmadmin) that you
can use to access reports on your system. Pretty handy. I document it
here:
http://www.netcraftsmen.net/resources/blogs/cucm-checking-replication-status
.html
HTH.
Regards,
Bill
Please remember to rate helpful posts.
On 9/3/10 7:56 AM, "Amjadhashim"
Please remember to rate helpful responses and identify
09-03-2010 07:43 AM
Hello William,
Really appreciate your reply, it is really very helpful in finding out the problem. The problem is with database replication as u stated, following is the information of the perf query class command for publisher and affected subscriber.
Publisher
admin:show perf query class "Number of Replicates Created and State of Replicati==>query class :
- Perf class (Number of Replicates Created and State of Replication) has instances and values:
ReplicateCount -> Number of Replicates Created = 412
ReplicateCount -> Replicate_State = 3
Subscriber
admin:show perf query class "Number of Replicates Created and State of Replication"
==>query class :
- Perf class (Number of Replicates Created and State of Replication) has instances and values:
ReplicateCount -> Number of Replicates Created = 412
ReplicateCount -> Replicate_State = 0
Above mentioned subscriber has the problem as visible now, but all other working subscriber and publisher has replicate_state of 3. I am not sure what it is, will you be able to give me any solution or reinstall is the only way?
Regards,
09-03-2010 09:04 AM
Amjad,
No, you don't need to re-install. Here is a link to the CUCM troubleshooting guide for 7.1 (reference link to DB Replication issues):
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1172876
You have already established you have an issue so I am providing the link for future reference. To resolve the issue I would first try the procedures in Step 6 (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/trouble/7_1_2/tbsystem.html#wp1184419).
Only do Step 6 if one of the servers showed an RTMT status of 4, or had a status of 0 for more than four hours.
(NOTE: I think you have a subscriber with the "status of 0 for more than four hours")
Step 6 Generate and view the Unified CM Database Status report, which provides debugging information for database replication. For each subscriber server that has a bad RTMT status, check that the hosts, rhosts, sqlhosts, and services files have the appropriate information.
Generate and view the Unified CM Cluster Overview report. Verify that the subscriber servers have the same version, verify that connectivity is good, and verify that time delay is within tolerances.
If the preceding conditions are acceptable, do the following to reset replication on that subscriber server:
a. At the subscriber server, perform the CLI command utils dbreplication stop
Do this for all subscriber servers that have an RTMT value of 4
b. At the publisher server, perform the CLI command utils dbreplication stop
c. At the publisher server, perform the CLI command utils dbreplication reset
HTH.
Regards,
Bill
Please remember to rate helpful posts.
Please remember to rate helpful responses and identify
09-04-2010 07:01 PM
Hello William,
Thanks for reply and help, this is great information. i don't know what was the problem but as it was friday afternoon and after replying to your post with Replication status value from my call managers i thought it might be worth shutting down the interface of the faulty call manager so i did it. After an hour i checked the status of my other call managers it was still 3 so i thought this problem might be there for long but i only noticed it after this problem so i un shut the port of the faulty server.
Today after checking your reply to post i logged in remotely to do the remedy but surprisingly when i checked the status it was all turned to 2. it was just amazing so i tested it by moving my own desk phone to different device pool with faulty call manager as first node and it got registered with that faulty unit.
Really it was surprising to me, is it possible that disabling and enabling an interface has resolved the problem?
I am really thankful for the help and all the information you provided is a new chunk of knowledge for me. i hope u will keep the good work up.
Regards,
Amjad Hashim.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide