Administer > Configure NNMi to Work in a GNM Environment > Verify the Global Network Management Configuration

Verify the Global Network Management Configuration

Perform the tasks listed in this topic to troubleshoot global network management configuration.

Check Clock Synchronization Status

All NNMi management servers in your network environment that participate in global network management (global managers and regional managers) or single sign-on (SSO) must have their internal time clocks synchronized in universal time. Use a Time Synchronization program, for example, Linux tool Network Time Protocol Daemon (NTPD) or one of the available Windows operating system tools.

If you see the following message at the bottom of the NNMi console:

NNMi is not connected to 1 Regional Manager(s). See Help ? System Information, Global Network Management. 

Check the nnm.0.0.log file on the Global Manager for the following message:

WARNING: Not connecting to system <serverName> due to clock difference of <number of seconds>. Remote time is <date/time>.  

Perhaps the clocks have drifted apart and need to be resynchronized. Check the nnm.0.0.log file on the Global Manager for the following message:

WARNING: Not connecting to system <serverName> due to clock difference of <number of seconds>. Remote time is <date/time>. 

Within a few minutes of this warning, NNMi disconnects the Regional Manager Connection. And the following message appears at the bottom of the NNMi console:

NNMi is not connected to 1 Regional Manager(s). See Help ? System Information, 
Global Network Management.  

View System Information

On the global manager, log on to the NNMi console, select Help > System Information, and then click the Global Network Management tab to view information about your global network management connections.

Synchronize Regional Manager Discovery from a Global Manager

If you notice an information inconsistency between global1 and regional2, run the nnmnoderediscover.ovpl script from global1, causing global1 and regional2 to synchronize. This also results in the regional2 updating global1 with any new discovery results.

This example uses the network shown in the following diagram.

Run the following command to synchronize nodes X, Y, and Z with global1:

nnmnoderediscover.ovpl -u username -p password -rm regional2.

You can use the -fullsync flag with the nnmnoderediscover.ovpl command to synchronize all polled object states and status (although this takes more time and causes a greater load on the systems). For more information, see the nnmnoderediscover.ovpl reference page, or the Linux manpage.

  • NNMi automatically resynchronizes topology, state, and status following a manual resynchronization.
  • Avoid stopping NNMi during the resynchronization. To help ensure resynchronization has completed, NNMi should remain running for several hours following the manual resynchronization. The actual time required depends on the number of nodes and the volume of state changes and trap data received while performing the resynchronization.
  • If NNMi must be stopped before the resynchronization is finished, the resynchronization should be run again and allowed to complete.
  • To perform a manual resynchronization of the entire management server, run: nnmnoderediscover.ovpl –all –fullsync

Recover a Destroyed Database on global1

If you take global1 out of service and need to restore its database, you face several scenarios:

  1. If you restore global1’s database successfully, regional1 and regional2 synchronize their cached information with global1. There are no manual steps to perform after bringing global1 back online.
  2. If global1 is out of service for an extended period of time, step 1 might not work successfully. To remedy this, run the nnmnoderediscover.ovpl script on global1 to initiate a new discovery on global1, regional1 and regional2. In this case you could run status polls on key devices to more quickly get updated status information.
  3. If you cannot recover global1’s database then you should submit a support call to clear out the old global1 data from the regional1 and regional2 databases using the nnmsubscription.ovpl script.