IP Readdressing of CallManager 3.3(4) Servers

[calmichael]

I have recently had to readdress a two server

CallManager 3.3(4) cluster and ran into a very

interesting issue.

After reviewing and then following information found

on CCO on IP readdressing of CCMs, IP Phones and

MGCP gateways now only show connectivity to the

CCM Publisher and not the Subscriber since the IP

readdressing event.

IP connectivity is good. We have even deployed an

IP Phone into the CCM Cluster subnet just to make

sure an ACL was the cause.

SQL replication looks good. Changes to existing

data on the publisher or adding new information on

the CCM Publisher almost instantly appears on the

Subscriber.

DNS/name resolution also looks good. It was thought

that changing the CCMs from using a hostname to the

new IP address might help, but it did not.

Both CCM servers have identical services enabled.

These services have been restarted, the servers

rebooted, but to no avail.

The single CallManager group that has the CCM

Subscriber listed first and then the Publisher

has been recreated without affect.

Has anyone else ran into this problem? TAC's

solution thus far is to rebuild the subscriber.

I am concerned that there is something larger at

fault here.

--- Thanks ---

[jasyoung]

"After reviewing and then following information found on CCO on IP readdressing of CCMs, IP Phones and MGCP gateways now only show connectivity to the CCM Publisher and not the Subscriber since the IP readdressing event."

Can you clarify this? Specifically, I would like to know exactly what appears on a 7940/7960 IP phone when you go to the Settings menu, hit 3, and then scroll down to options 21 and 22, which are your first and second CallManager slots, respectively. I'd also like to see the output of 'show ccm-manager' from your MGCP gateway (assuming it's IOS and not a WS-X6608).

You mention that all services are 'enabled' on the Subscriber. Can you confirm that they're running using the Services control panel on the machine itself? Specifically the 'Cisco CallManager' service needs to be running, but you should have lots of others, at a minimum, the RIS Data Collector service and the Database Layer Monitor. You imply that they are in your post, but it's really important that at least those three be confirmed alive.

Try to telnet to the Subscriber on port 2000, which is the IP phone SCCP port. You should get an open connection but nothing back. If you hang trying to connect or get a connection-refused response, then it would indicate it can't take SCCP connections.

Is there anything interesting in the Subscriber's Event Log? Any error messages would be interesting, but I'm particularly interested if you see errors about "transient" registrations or "device unregistered" messages. Those would help us split up the potential problem domain if they were present.

[calmichael]

The IP Phones were showing accurate information

for fields 21 and 22, though 22 was "Active" which

was the CCM Publisher.

The event log is showing several "Anonymous Alarms"

and the occasional IPMA not started (it's not

supposed to).

What has been found since earlier this morning is

that even though Call Control showed everything as

expected on the Subscriber, CallManager was shown

as "Starting" not "Started" in Services.

A manual "Stop" "Start" does allow the Subscriber to

come online. But after a reboot, it's back to

"Starting" and stays that way until some manual

intervention is performed.

So, with that, a scan of the Subsriber's registry

did find several instances of the original IP

address, and a couple of the new. The instances

of the old seemed to correspond with entries made

for use by Extended Services.

Changing the registry entries that has the old IP

address to the new IP address seems to have done

the trick.

I think that this is the root cause of the issue,

which while taking twice as long as the "rebuild it"

advice from TAC seems so much more satisfying. (grin)