ICM B side CM PG, VRU PG's opc and PIM restart

[HYEONJIN PARK]

Hi~

Guys~

In my configure ICM

A Side(Active)

Rogger A

CM PG A(CTI & CTI OS)

VRU PG A

DAW

B Side(Idle)

Rogger B

CM PG B(CTI & CTI OS)

VRU PG B

Sometimes ICM B side opc and PIM restart of CM PG, VRU PG and CTIsvr

They have other uptime to pgagent, mdsproc, jtapigw etc.

ICM A side have same uptime all process.

What is problem? or Is it normal?

[Ramamoorthy Shanmugam]

Hi ,

 Please verify the Private and Public connectivity status .Also follow the below check list for UCCE and PCCE deployment.

http://docwiki.cisco.com/wiki/Contact_Center_Networking:_Offload,_Receive_Side_Scaling_and_Chimney

collect mds logs from Router and PG verify the heartbeat and connectivity. Other way you will find in event viewer logs.

Thanks,

S.Ram

[HYEONJIN PARK]

I've checked windows event.

event ID : 32770, 126, 211, 49218

and If when fail-over to B Side it was not restart opc, PIMs and CTIsvr also.

I want know why idle side PG's opc, PIMs and CTIsvr change state. 

[Ayodeji Okanlawon]

Pull the logs for each process and you should see what is going on. Without the logs there is nothing we can do. If you need help with the logs attach them here. Ensure you collect logs for the time frame these events occur

[geoff]

---

@HYEONJIN PARK wrote:

I want know why idle side PG's opc, PIMs and CTIsvr change state.

---

The facts are that you have made a mistake.

You have to go over this carefully. At the network level, make sure each side can ping the peer both using the public hostnames and the private hostnames. Run nacp.cpl and look at Advanced settings and check the binding order (public before private). Check that your persistent static routes are correct. tracert the private hostname of the peer and ensure it's going out the correct private NIC and not the public interface.

Now run PG Setup on both the A and B sides and step through each screen in lock step and compare A and B. When you get to the Connections screen these must be identical.

It is not uncommon to have errors like you are experiencing - we have all seen it. But it is due to a misconfiguration and you must find the problem.

Regards,

Geoff

[geoff · Accepted solution]

One thing I forgot to say. If all the above does not fix the issue, ask yourself if this was a totally clean install. If a PG is installed and then removed, then a PG is installed again, unless the original was totally cleaned out of the registry, when the second installation occurs it generates all the port numbers "incorrectly". It thinks it is doing it correctly, but the PG will not match the other side. 

The best thing to do is export the registry under the PG A side and export the registry under the PG B side, put the files into Notepad++ and compare. You expect to find differences, but not as many as you might think. Check the port numbers and compare with what you expect looking at the Port Utilization Guide, which describes the algorithm.

This happened to a colleague recently. Just remove the PG from the side that is wrong, check the registry that it's really gone, then add it again. Won't take long.

Regards,

Geoff