Cluster over WAN for ICM version 8

[bilalghayad]

Hi All;

Now I built side A (RGR, HDS, CVP PG and CUCM PG) and I got a new servers to build side B. I am going to install the ICM on side B. Regarding to the databases (HDS, AW, logger), just I have to create them on side B, and connect side B and it will synch with side A? Or there is something else I have to do?

Side A and side B linked by WAN, but it is a reliable fiber link of 1 Gbps bandwidth and very stable.

Thanks for the help in advance.

Regards

Bilal

[geoff]

By the way, looking at the screen shot above, it's indicating that the PG is not in the same timezone as the central controller. All your nodes should be in the same timezone.

One thing I tried to change it in the configuration is the Peripheral ID (not the logical and not the physical), so I tried to use same Peripheral ID for VRU PG side B and A, also I tried to use another Peripheral ID for side B than this for side A (already there are 4 Peripheral IDs under the same VRU PG configured in the configuration manager, because in the production there are 4 CVP Call Servers). 

The IDs must be the same on A and B. In fact the exported registry of PGA and PGB will be near identical. I would compare with a registry diff tool to see if there is a mistake.

What about if you do this? Shutdown the Call Server so neither PIM can bind. Now start them up - shutdown each in turn, bring them back up, change order and so on. Is the MDS OK?

Now start the Call Server. If this causes a problem, get the trace using dumplog and show us.

From what you are saying it appears that there is a problem with MDS - and this means the config is not right.

Is the binding order on each PG correct - public before private?

Regards,

Geoff

[bilalghayad]

Dear Geoff;

The Time Zone fixed as I found a difference time zone at CUCM PG at side A. Thanks.

I did serverals attempts for VRU PG A and B while CVP Call Server is down but the same result (the VRU PG that start firstly is going fine while the second one is causing the error and the restart message).

At the RGR, I see the below picture:

About the installation at the PGs, I reviewed the values that I gave for VRU PGA and VRU PGB and they are the same and the public IPs, private IPs, high value and low value IPs are all correct. Also the Peripheral IDs and Logical and Physical are both same and correct. At side A, I determined it is side A and at side B I determined it is side B and I selected to be duplex (in both sides).

About ur sentence:

Is the binding order on each PG correct - public before private?

* I did not get what do u mean exactly by it. But if you mean when I did the installation for the PGs, when it ask for the IPs for the private and public, actually the menu it self is asking for private before public as shown below:

One thing, is the configuration at the Configuration Manager (at the AW), what could be the configuration that causing this problem and it is effecting? I am attaching also below a snap shot.

At the RGR, I enabled at the registry the PG03 and PG02 and PG01 (where PG01 for CUCM, PG02 for VRU and PG03 for MR), and the only thing that I have a problem with the VRU PG

One question please: the side that will not be active, should I see in the services IDLE or Standby?

Regards

Bilal

[geoff]

I did serverals attempts for VRU PG A and B while CVP Call Server is down but the same result (the VRU PG that start firstly is going fine while the second one is causing the error and the restart message).

OK then. We know it has nothing to do with the Call Server. You need to solve this problem.

By the "binding order" I mean the two NICs on the server itself. Examine the network binding order in Windows and make sure, on both PG A and PG B that the public NIC is first in the binding order.

The MDS process is going to provide the best info about what is wrong. Increase the trace to 0xffff and run the test again and gather the trace. Examine the trace and you will see the problem - for sure. Once you fix it, remember to put the trace back.

The Router is trying to tell you what's wrong. It can't see that PGB at the address 172.30.9.8 specified.

Regards,

Geoff

[bilalghayad]

Dear Geoff;

Still the problem the same, kindly find below the result of ipconfig /all and how it look like (same thing on both VRU PGs):

Also this is the MDS log at both VRU PGs:

By the way, I need to post rar files contains the snap shot of the configuration for the VRUPGA and VRUPGB, but not able to know how to insert this rar files.

Regards

Bilal

[bilalghayad]

I am also adding a snap shots of the configurations that I did for VRUPGA and VRUPGB to see if there is anything wrong:

VRUPG - Side A:

VRUPG - Side B:

Configuration at the configuration manager:

Registry at the RGR and RGRB:

PG01, PG02 and PG03 are enabled, and only the PG3Enabled is enabled.

I hope that those can help to discover the problem reason.

Regards

Bilal

[bilalghayad]

Any help?

I need to say that the gatekeeper license is terminated. But I am assuming that this is not the reason for the problem because one VRU PG side is able to work fine but both sides togethor is causing the problem. Also, as we said that if the CVP is stopped, the problem should not be related.

So, what could be the reason?

Regards

Bilal

[bilalghayad]

Dear Geoff;

The problem resolved. One side was patched and ther side was not patched. Sorry for this.

But I would like to know, is it really important that visible IP to be before private IP when doing ipconfig /all? Why?

Regards

Bilal