ICM7 Install - RouterA process on RoggerB

Unanswered Question
May 11th, 2010

I'm having an issue for an ICM upgrade from 6 through 7.0c SR4 to 7.5.x. As part of the upgrade process a RoggerA and RoggerB are built based on ICM7.0c using an EDMT import of the 6.0 database and a copyof the ICM registry key tree from each respective source Rogger i.e. apply RoggerA 6.0 registry tree to new tech refresh RoggerA 7.0 and apply RoggerB 6.0 registry tree to RoggerB 7.0. This is the process described in the upgrade guide.

However, when RoggerB is installed and rebooted after the ICM7.0c install, it attempts to run both RouterB AND RouterA on the same server. It suddenly seems to think it is now RouterA as well as RouterB. The registry now shows a new tree for RouterA, icmsetup shows RouterA and the process attempt to run RouterA. The real RouterA has already been installed, is running and is connected via bopth public and private network.

I've trawled the release notes for ICM 7.0c through to SR4 but can't see a mention of this issue which would be a pretty major problem.

We have fixed the issue by deleting the RouterA registry tree before rebooting the server and also deleting the entry via icmsetup, which should mean we can then move on to upgrade to ICM7.5. However, I'm concerned that this isn't a good starting point for a new 7.5 build so would like to understand why this issue is occuring.

Is there a patch that I am missing here?

Jed

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.

It's hard to believe the export of the registry from RouterB could have entries for RouterA - and it's hard to believe it could have been corrupted during the process. But obviously this did happen. I've never seen this occur, but I think your solution is adequate and effective, and you can go forward.

Regards,

Geoff

jedellerby Tue, 05/11/2010 - 03:26

The registry import was checked prior to the build and no sign of RouterA in there so no corruption prior to the startup. I struggle to think there is any step missing in the process performed here so this sounds very much like a bug, but how an earth it could be impacting this specific config is beyond me. This would be a really major bug and hence fixed a long time ago, so it must be something peculiar to this setup ... which shouldn't be anything special at all.

The only thing that is new is that these are the latest DL380 G6 servers.

Could issues with comms to the primary Router have any kind of impact?

Jed

jedellerby Thu, 06/10/2010 - 02:42

Thought it worth a follow up on this.

The custonmer has been running fine with the fix process they went through, however I still wanted to understand why this happened. After some TAC assistance they pointed me at the following bug which is exactly this issue ... dman annoying that I couldn't find this bug with standard search terms.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsh70013

At least the problem is understood and I know the ICM build is fine to work from,

Jed

david.macias Thu, 06/10/2010 - 04:37

Jed,

Thank you very much for following up, I wish everyone would do the same.

david

Actions

This Discussion

Related Content