CUCM 4.1 Sql database Issues

[Ayodeji Okanlawon]

Guys,

came across this one on a project i am working on migrating the users to a new cucm 8.6 cluster..

Here is the description,

We have multi site users on a cluster running cucm 4.1.

We have deployed a new cucm 8.6 cluster and doing a phased site migration of users from old to new cluster.

Before a site is migrated, we run a BAT job to move all the devices in that site into a hidden partition.

We then create a route pattern for that site DN to route calls to that DN range to a GK which then routes the call to the new cucm8.6 cluster.

Here is the weird problem we are facing....

When users still on this old cluster who are yet to be migrated dials users on the new cluster, they get a busy tone. Debugs on the GK showed that the call didnot come to the gatekeeper..

CUCM traces showed the starngest thing of all. the call was been routed to the phones in their old Partition. I.e CUCM still sees the phone as they were before moving them to a new partiton..

Eg..before migration, DN=4444, PT=Internal_PT,

after migration, DN=4444, PT=Hidden_PT

a RP of 44XX is configured.

Now when a user dials the dn=4444, cucm traces shows the call been sent to DN=4444 in Internal_PT

Its as though CUCM has not seen the devices been migrated to the new PT.

U have run dblhelper tool to re-innitialize and re-publsih the database and no luck. The interesting hting is that dblhelper reports a database state as good with green smiley faces..

Another interesting thing is this..when I create a route pattern with excact pattern of 4444, the call works fine and even after I delete that RP. WHich shows that its at that point that CUCM updates the dialplan in its database..

Is there a way to fix this guys?

[Jaime Valencia · Accepted solution]

Have you gone directly to the DB and see what's in there??

What I've seen in the past is that the routing information is not really taken from the DB but it's loaded into memory or a cache (not exactly sure which) but it might be different from what you expect.

i.e. you get the right outcome using DNA (because DNA does goes to the DB directly to get you the result), but if you call from the actual phone/DN the outcome is different.

The info should be updated to reflect the same as the DB but I've seen  many times in the past configurations that should work and they just  didn't, you go into something you're working with, check a checkbox,  save, uncheck the checkbox, save, and voila, now it works.

You might want to try restarting the CCM service or worst case scenario the whole server.

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Ayodeji Okanlawon]

Jamie,

You just helped made things much clearer. Yes you are spot on on DNA. When I run DNA is showed the call matched the right Route Pattern. Hence the databse is not the problem. Which also explains why performing a re-publish of the sql database didnt resolve the issue.

I tried to look into the sql databse directly but coudlnt get around to be able to run the sql query needed to see the dn and pt. Can you pleae help with this..I.e what syntax do i use on the query analyzer to be able to see the DN on the device in the sql database.

A reboot is planned for the whole cluster. Its not an easy cluster to reboot as it has 8 Servers on  it..

If I can run sql query, this should help see clearly that the database is intact

[Ayodeji Okanlawon]

Jamie,

I have looked at the sql database. Yes the databse has the correct configuration. The phones are in the right partition. So its the Cached information that is the problem. I am sure the reboot will fix it.

Many thanks. Will update you once the reboot is done

[Ayodeji Okanlawon]

Jamie,

The reboot solved it. Many thanks. So do we have the same cached information type on cucm 6.x and above? Is there a documentation that you can send to me on this..Many thanks

[Jaime Valencia]

Yeah, AFAIK it still works in a similar fashion in which to make things faster, the routing is loaded in some sort of cache and ideally it should be updated when you do any update to the DB.

But as I've told you, I've seen that fail many times.

I found that out just like you, looking at what I have in the DB and what really happens when I dial. I don't think we have any documentation on that.

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Ayodeji Okanlawon]

Ok. Thanks. What is AFAIK?? Never heard of it before

[Jaime Valencia]

As

Far

As

I

Know

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Tim Smith]

Ive had exactly the same issue with a 4.1 migration. Was extension mobility involved? BAT updating them in 4.1 while still logged in definitely makes it worse.

So as already mentioned it seems DB updates occur but dont get loaded into actual CM routing tables. CM restart way to go.

Ive also had issues with large BAT updates where the DBL service would ens up getting stuck. We used to limit updates to 50 devices at a time. On 4.1 Some BAT functions just peg cpus at 100 percent. Even on 7845.

Cheers,

Tim

Sent from Cisco Technical Support iPhone App

[Ayodeji Okanlawon]

Tim,

You are spot on. We do have the same issue with BAT. You will have to leave it and go and have multiple cup  of cofee once you submit the BAT job. Sometimes we leave it running through the night...Yes the servers are 7845s..Its a nightmare working on that 4.1 version.

Wonder if there is a way to see what is on CUCM routing tables..Is there any tool to use to do that?