MGC Registration issue

[srcvh1]

Has anyone ever seen this before? I started looking into a GR backup issue when I ran into this issue:

=> stat ucm sys
MGC 192.168.5.26 UNKNOWN
MGC 192.168.167.21 UNKNOWN
MGC 10.255.253.34 UNKNOWN
MGC 192.168.5.23 UNKNOWN
MGC 192.168.47.21 UNKNOWN
MGC 192.168.5.27 UNKNOWN
MGC 192.168.5.24 UNKNOWN
MGC 192.168.5.28 UNKNOWN
MGC 192.168.157.21 UNKNOWN
MGC 192.168.5.25 UNKNOWN
MGC 192.168.107.21 UNKNOWN
MGC 10.255.253.21 UNKNOWN
MGC 192.168.5.22 UNKNOWN
MGC 192.168.107.22 UNKNOWN
MGC 10.255.253.35 UNKNOWN
MGC 192.168.5.21 UNKNOWN

=> reg ucm sys
IP address of the Primary Security Server [192.168.5.29].
User Name (UCM): XXXXXX
Password (XXXXXX):

These elements are registered with the Call Server
MGC 192.168.5.26
MGC 192.168.167.21
MGC 10.255.253.34
MGC 192.168.5.23
MGC 192.168.47.21
MGC 192.168.5.27
MGC 192.168.5.24
MGC 192.168.5.28
MGC 192.168.157.21
MGC 192.168.5.25
MGC 192.168.107.21
MGC 10.255.253.21
MGC 192.168.5.22
MGC 192.168.107.22
MGC 10.255.253.35
MGC 192.168.5.21
MGC 10.252.8.5
Register these 17 elements to the security domain using your credentials if not
already registered? (Y/N)y
Sending messages to 17 elements authorizing them request security domain members
hip.
Waiting for status updates from each of the elements...
..............
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.26; Reason: 3; De

tails: )
................................................................................
.......
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.23; Reason: 3; De

tails: )
................................................................
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.27; Reason: 3; De

tails: )
...............................
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.24; Reason: 3; De

tails: )
.........................
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.28; Reason: 3; De

tails: )
.......................................................
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.25; Reason: 3; De

tails: )
..................................................16/06/2014 09:39:27 LOG0006 VG
W: vgwQoSAlarmGenerate: QoS Alarm is suppressed because alarm notification is tu
rned off
.........................................
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.22; Reason: 3; De

tails: )
................................................................................
..............
SRPT316 Internal communications message transmission failed.
(Transport: AFS; Subject: SDM; Action: PUBLISH; IP: 192.168.5.21; Reason: 3; De

tails: )
................................................................................
................................................................................
................................................................................
...........................
TIM000 09:46 16/6/2014 CPU 0

PRI009 DCH: 130 DATA: 00000004
................................................................................
...................................................................No new elemen
ts were registered to the security domain.
17 element(s) failed to request security domain registration.

It says that SMGs are registered yet they all have UNKNOWN next to their status. I tried to re register them and had the results documented. I'm sure whatever this is is causing my GR backup issue. Obviously this is a much bigger issue. Has anyone ever run into this and found the cause?

Thank you,

Scott C

 

[KCFLHRC]

You will need to go into the command line of the MGC card and register it that way with the joinsecdomain. Very common problem with the MGC cards.

 

[srcvh1]

KCFLHRC,

Do you think this is the cause of my GR Backup issue?

Is there any other way to do this from the central location? All of these SMGs are scattered with a 300 mile radius!

 

[KCFLHRC]

I doubt the 2 issues are related. You will need to telnet to the MGC cards or do it locally.

 

[srcvh1]

Thanks KCFLHRC. What is the procedure for doing the joinsecdomain? Do I just login with the admin/admin user/password, then simply input joinsecdomain?

 

[KCFLHRC]

You just log into the MGC card and type that command. Then it will come back and ask you for the primary security server IP address, user name and password. You can also do a statsecdomain and leavesecdomain from that command oline also

 

[srcvh1]

Thank you much, I will give it a go!

 

[KCFLHRC]

After you get each MGC card registered do a stat ucm sys refresh in ld 117 and see if they show registered. Did this occur after an upgrade or something you just stumbled across?

 

[srcvh1]

Just stumbled across. It would seem to me that the GR backup would be affected by this. If these elements are showing not registered, how could the main push out the database to the SMGs?

 

[KCFLHRC]

The database replication is done to the Call Servers, not to the MGC cards. I would look in Element Manager and make sure you have the database replication configured right. Are you getting a particular error during replication? Can you ping the SMG Call Server from the Primary?

 

[srcvh1]

Yes, I'm pinging fine. This is something that was working then suddenly stopped. I haven't looked into it much deeper then seeing this issue with the MGCs

 

[KCFLHRC]

I would get the MGC's registered and then work on the replication. What happens if you do a stat gr in ld 135?

 

[srcvh1]

Get this:

OVL000
>ld 135
CCED000
.stat gr
Geographic Redundancy Status
----------------------------
Primary Call Server
Automatic Replication Backup defined: SCHD
Last Successful Replication Backup to 192.168.167.20
mode: Automatic
Backup Rule number: 1
Secondary Call Server name: XXXXXX_CS
performed at: 06:13 on 04 13, 2014
Failed Backup attempts: 312, last one at: 06:19 on 06 16, 2014, to 192.168.167.
20
Test activated: None
Internet phones registered locally: 1007
Media Gateways registered locally: 16

 

[KCFLHRC]

So it appears this quit working back in April.

 

[srcvh1]

Correct, I was just brought into this today. I have no idea how long the MGCs have been in this state

 

[KCFLHRC]

Can you log into the SMG Call Server and see if it is up? Maybe a reboot of the alternate call server?

 

[srcvh1]

Actually, I did do that on Friday working on another issue for that site (I had to replace the Chassis). It didn't help resolve this issue

 

[KCFLHRC]

I really think they are unrelated issues. The database replication really has nothing to do with the MGC cards. Are these CPPM VxWorks Call servers or CoRes Linux POS's

 

[srcvh1]

They are CPPM VxWorks

 

[KCFLHRC]

That's a plus that they are VxWorks. You might also want to make sure that the alternate Call Server is registered to your Primary UCM.