Determining Device Status and NNMi Incident Generation using a Global Manager

NNMi management server global1 listens for state changes coming from regional managers regional1 and regional2 and updates the states in its local database.

The NNMi StatePoller services on NNMi management servers regional1 and regional2 calculate state values for the devices it monitors. global1 receives state value updates from regional1 and regional2. global1 polls nodes that it discovers, and does not poll nodes being managed by regional1 and regional2.

After you change the management mode of a node being managed by regional1, you see that management mode change on global1 as well. As network administrators add, remove, or modify network equipment being managed by regional1 or regional2, regional1 or regional2 updates global1 of these network device changes.

global1 generates incidents using its own causal engine and topology, including the node object data forwarded to it by regional1 and regional2. This means that the incidents it generates might be slightly different from the regional1 and regional2 incidents if there are differences in topology.

It is better to avoid using a forwarding filter on regional1 or regional2, as filtering might affect the connectivity on global1.The result could be a difference in the root cause analysis between global1 and the two regionals (regional1 and regional2). In most cases, if you choose to avoid using forwarding filters, a global NNMi management server will have a larger topology. This helps it draw more accurate root cause analysis conclusions.

Without additional configuration, regional1 does not forward traps to global1. To do this, you must configure regional1 to forward specific traps to global1. recommends you only configure regional managers to forward low-volume, important traps to avoid excessive burden on the global manager. NNMi drops forwarded traps if the forwarded traps result in a TrapStorm incident. See the TrapStorm Management Event details in the NNMi console.