Router 3640 on Layer 2 View but not on Topology Groups

[rgomes]

I have an interesting problem: a 3640 router is discovered and collected, showing up on the Layer 2 View. On the

Topology groups, either CM and RME it does not appear. I have already deleted

and rediscovered, by the way its a seed.

I tried also deleting and created by hand. Still the same. Tried also force it on the user group it should belong, but it never shows up.

Versions are:

CiscoWorks Common Services 3.0.5

Campus Manager 4.0.7

CiscoView 6.1.5

Device Fault Manager 2.0.7

Internetwork Performance Monitor 2.6.0

Resource Manager Essentials 4.0.5

Thanks for any help

[Joe Clarke]

This could indicate a problem with the CampusOGSServer. You might try running the NMSROOT/MDC/tomcat/webapps/campus/WEB-INF/classes/rmcampusogstable.pl script, then restart the CampusOGSServer process.

[rgomes]

Hi

I am attaching the CampusOGSServer.log

I have done what you said, but still the same:

D:\Program Files\CSCOpx\MDC\tomcat\webapps\campus\WEB-INF\classes>perl rmcampuso

gstable.pl

Getting the Database User Id and Password

Getting the Database Table Version Information

Campus OGS Schema version in Database: 1.0

Dropping existing tables

Writing to Database ---> set option blocking = 'off'

Writing to Database ---> set option delayed_commits = 'on'

Writing to Database ---> set option PUBLIC.nearest_century = 70

Writing to Database ---> DROP TABLE CampusOgsGroupPropertiesTable

Writing to Database ---> DROP TABLE CampusOgsTagTable

Writing to Database ---> DROP TABLE CampusOgsGroupCacheTable

Writing to Database ---> DROP TABLE CampusUserGroupAssociationTable

Writing to Database ---> DELETE FROM DbVersionHistory WHERE SubComponent = 'OGS'

Writing to Database ---> DELETE FROM DbVersion WHERE SubComponent = 'OGS'

Closing File: d:\PROGRA~1\CSCOpx/MDC/tomcat/webapps/campus/WEB-INF/classes/Campu

sOgsDbRemove.sql

Commiting dropped tables to Database:

Database handle destroyed without explicit disconnect, chunk 19.

D:\Program Files\CSCOpx\MDC\tomcat\webapps\campus\WEB-INF\classes>

[Joe Clarke]

It's not clear if you restarted CampusOGSServer after running this script. Make sure you do:

pdterm CampusOGSServer

pdexec CampusOGSServer

[rgomes]

After running the pl script I have restarted the OGSServer using the GUI, CS>Server>Admin>Process.

I have lost all user defined groups configured before.

[Joe Clarke]

Yes, you would. Clearing out the OGS tables removes all custom groups in the underlying application (Campus in this case). Is the missing 3640 now visible under the Campus System Defined groups?

[rgomes]

No it?s not visible. I can not create the groups any more. I have repeated the CampusOGSServer.pl and restarted the CampusOGSServer process, stillthe same 360 not showing and ca not create the groups.

I see database error on the CampusOGSServer.log that was not there before. I am attaching the current log.

[ Mon Aug 20 14:57:43 BRT 2007 ]ERROR com.cisco.nm.xms.ogs.cm33.TopoChangePoller checkForChanges Exception instantiating OGSServerProxy: Database error while modifying group: /Campus@plutonio/System Defined Groups: Exception caught in getGroupId: com.sybase.jdbc2.jdbc.SybSQLException: ASA Error -141: Table 'CampusOgsGroupPropertiesTable' not found

[Joe Clarke]

This error is not fatal, and you should still be able to create groups. I ran the same script here, and while I see the same error in the log, grouping in Campus is still working correctly.

As for the 3640 not showing up, I wonder if this device may have a null DCR ID in the ANI database. If you enable core and corex debugging under Campus Manager > Admin > Campus Data Collection > Debugging Options, then run a new Data Collection, the resulting ani.log should have the relevant information to determine if you're seeing this bug.

[rgomes]

I made a collection with the core and corex debug enabled and the ani.log is attached.

I am not able to identify the null DCR ID on the log.

I could recreate the groups, but sometimes the create group app crashes when selecting objects on the INCLUDE list pane.

Thanks

Robson

[Joe Clarke · Accepted solution]

I see two devices that are affected by a bug that is fixed in CM 4.0.9:

10.201.46.83

10.200.200.3

I'm not sure if either or these are your missing 3640, but in any event, you should upgrade to CM 4.0.9 as Campus will no longer process any changes for either of these two devices (as they have null DCR IDs). When you do upgrade, you will notice all links turn red on the map. This is another bug, CSCsk08540. The workaround for this bug is reinitializing the ANI database, but a fix is available by calling the TAC.

As for your grouping problem, what do you mean when you say that the app crashes on the INCLUDE pane? What symptoms do you see?

[rgomes]

Bingo. The missing 3640 is really the 10.201.46.83. The 10.200.200.3 is not showing up in Campus but its on RME. I have deleted 10.200.200.3 from the DCR and made a discover.

It is discovered but not collected to campus.

After upgrading to 4.0.9, how do I reinitialize the ANI database? Will I lose the groups again?

Regarding to the group app, the window closes sudddenly after select one or more objects, and the group is still there with the last saved contents.

Thanks

Robson

[Joe Clarke]

To reinitialize the ANI database, run the command:

NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=ani dmprefix=ANI

You will not lose any of the Campus groups, but you will lose all of your topology and User Tracking information.

[rgomes]

Do we need to stop/start any proccess to reinit the ANI database?

[Joe Clarke]

Daemon Management will need to be shutdown to do it. It will let you know if you run the command with dmgtd running.

[rgomes]

It took a while after upgrading to 4.0.9 for the ANIServer process to initialize. I could recompute the groups membership and the offending 3640 and the other object now show on both the Layer 3 View and on the cm group section.

After the upgrade I see restarts of the FHDbMonitor process:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

FHDbMonitor {Tue Aug 21 15:53:09 2007} Running DbMonitor version 2.1

FHDbMonitor {Tue Aug 21 15:53:09 2007} Sending Initial OK Message to process manager.

FHDbMonitor ERROR {Tue Aug 21 15:58:09 2007} Get reply for process failed

FHDbMonitor WARNING {Tue Aug 21 15:58:09 2007} Unable to obtain process id for 'FHDbEngine'.

FHDbMonitor WARNING {Tue Aug 21 15:58:09 2007} Failed to check processes on Daemon Manager.

FHDbMonitor WARNING {Tue Aug 21 16:38:09 2007} Process ids do not match for 'FHDbEngine'. Previous process id = 2552. Current process id = 13212.

FHDbMonitor WARNING {Tue Aug 21 16:38:09 2007} The process 'FHDbEngine' has been restarted.

FHDbMonitor WARNING {Tue Aug 21 16:58:09 2007} Process ids do not match for 'FHDbEngine'. Previous process id = 13212. Current process id = 11504.

FHDbMonitor WARNING {Tue Aug 21 16:58:09 2007} The process 'FHDbEngine' has been restarted.