11-17-2010 11:50 AM
Pardon me for being a rookie CSC user. We've got a Active/Standby server setup and had a failover but the standby never came back up. We've power cycled (since didn't have root passwd handy at first) and then reinstalled SW. Seems there's some good procedures at: http://www.cisco.com/en/US/products/hw/vcallcon/ps2027/products_tech_note09186a008010ff0a.shtml#prov_fail
which we've followed but trying prov-sync & dply from active didn't work. Also messing with /etc/init.d/CiscoMGC stop/start with pom.dataSync=yes or no didn't seem to matter. Anyone get this "stuck" state in their paired systems. Attached are the gory details of the debugs via standby when active did it's prov-sync & dply. I did a diff of XECfgParm.dat and things look good there. I also tried loading in new active into our VSPT GUI but that failed; I was hoping the VSPT backdoor approach would sync things back to proper ACT/STBY config. Also pings work fine from/to both servers. Any help would be appreciated.Thanks
godiva mml> rtrv-ne
MGC-01 - Media Gateway Controller 2010-11-17 14:42:57.585 EST
M RTRV
"Type:MGC"
"Hardware platform:sun4u sparc SUNW,Netra-240"
"Vendor:"Cisco Systems, Inc.""
"Location:MGC-01 - Media Gateway Controller"
"Version:"9.3(2)""
"Platform State:OOS"
rover mml> rtrv-ne
MGC-02 - Media Gateway Controller 2010-11-17 14:43:45.213 EST
M RTRV
"Type:MGC"
"Hardware platform:sun4u sparc SUNW,Netra-240"
"Vendor:"Cisco Systems, Inc.""
"Location:MGC-02 - Media Gateway Controller"
"Version:"9.3(2)""
"Platform State:ACTIVE"
;
11-22-2010 02:31 AM
Try using this procedure to recover the standby side:
11-22-2010 10:48 AM
Thanks much! We ended up getting a Cisco Engineer involved but this doc would of got us back on target to previous config by these means. Part of the original problem was the standby that turned active did_not have the /opt/CiscoMGC/etc/CONFIG_LIB/new directory at all. I copied over from other side which did allow VSPT to pull configs in or prov-sta to be accepted. Though logs and core files are being looked at, I think assigning a TG to the new OPC caused the crash and also pointer mismatches for trying to update/pull in other configs. Our SS7 links we down or bouncing after the failover. I now there are docs for new OPC provisioning which included caveats so I'll have to go back and review. Again thanks, you nailed it with a quick revert back to sain db via the manual method.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide